Ah so this is why they messed up the overflow menu.
Kind of hoping I can actually order the extensions at some point though, it's a bit messy if you can no longer control which extensions are in the overflow menu or what order they're in.
That lack of sorting in the new extension-menu makes question whether the developers are even using their own work. This seems like an obvious problem one would realize early when using it.
It allows you to disable extensions only on specific sites. (And presumably, that's also the reason you need to dive into about:config to remove it: if you remove it, it's pretty hard for casual users to find out why an extension isn't working. By gating it behind about:config, people who are able to deal with that can still remove it without rendering casual users helpless. That's my personal interpretation though.)
Does this allow whitelisting as well as blacklisting? Chrome has offered both for a long time, and I remember being surprised to learn that FF didn't offer either. It's a welcome change!
I was checking this new extension button, I think is useful to give more light to extensions, but what I don't like it at all is that it only shows the extensions that are not present on the nav bar, not all your installed extensions. I think is confusing, it should be the list of all your extensions, and the user can pick which extension also appears more handy on the nav bar.
Need we play such language games? It's "ad blocking". People use those extensions to block ads.
If you asked the average user about their privacy preserving add-on, or their content blocker they would probably be confused.
Yes, obviously I understand the privacy dimensions of advertising, and I realize that this is all in the service of the good guys and against the bad guys, but that shouldn't affect our response to what seems to me to be unnecessary spin.
I see it as a good rhetorical move: Say it's ad blocking, and you get people coming in all po-faced about the need for platforms to make money and how horrible it is to have freeloaders blocking honest, legitimate adtech. Frame it as defense of privacy and malware-blocking and those adtech boosters are on the defensive, to the point they probably don't comment at all for fear of drawing attention to the correlation.
I completely agree: it is a good rhetorical move. aka good spin. But I don't think we should celebrate that sort of thing in tech blog posts, or in any writing actually unless your work in marketing.
> It's "ad blocking". People use those extensions to block ads.
I use them, and DNS filters, to block stalking. They just happen to block adverts too because it is practically impossible to separate the two ATM. I'll accept ads based on the page I'm looking at and my rough geographical position, but I don't see why I should put up with being followed and profiled everywhere I go.
Yes, but you are not the typical user, and that is my point. I wasn't denying that cases could be found that would support the language that Mozilla is using.
Exactly. I didn't even use adblockers before I had kids and thought about them being tracked. Now I use a pihole and bend myself in knots trying to figure out how to pay sites I visit.
If there's any spin, it's in characterizing ads as neutral "content". While something like uBlock can block general content, it's primarily a web malware blocker. That includes adware, spyware, crypto miners, etc. It's a necessary security feature preventing the extremely common practice of websites hijacking people's computers to run software they don't approve of.
They have merged a change that makes it impossible to access and download certain website content the user is viewing and wants to process. Now that Firefox has introduced this limitation without offering an alternative, it is now much easier to port some of my extensions to Manifest V3 on Chrome, despite Chrome not supporting the blocking webRequest API.
It's disheartening to see how these changes are introduced without any planning or care for how it affects extensions that are being ported to Manifest V3, and the general lack of respect towards extension developers.
This doesn't really affect blocking requests in any way, actually it's the opposite: This change doesn't allow extensions to bypass builtin security features.
Firefox is going to continue to have more powerful blocking features compared to what a DNS based approach like pihole can provide.
Sad but true. FF devs and fans will complain, but a look over the Mozilla Foundation's balance sheet/annual report [1], and in particular the share of revenue that royalties received from "search engines" have, is all you need to know.
The linked change doesn't affect addons like uBlock Origin. GP is being unnecessarily alarmist about a relatively minor change, where the FF devs have even expressed they'd be willing to add back in support for their usecase (they just don't want to allow it by default).
That bug reads to me like that functionality is not yet implemented, because they're still figuring out how to securely add that back in. However, since MV2 is still supported, I don't see the problem here — this is just the first public release of some MV3 functionality, but full feature parity is still being worked on (Service Workers aren't supported yet either, for an example that affects my extension).
You think it's fine to invite developers to begin porting extensions to Manifest V3, and then kneecap their work a couple of months later as they port their extensions, while also telling them to open new bug reports in which they need to spend time defending general-purpose computing? This is not a missing feature, but a limitation that has been added only to Firefox.
As long as it's clear that it's an initial exploration and that not everything is possible yet, sure. It was clear to me, though admittedly I'm probably paying closer attention than most, so I'm not representative — it might indeed be that communication could have been better.
I regret to say I no longer trust Mozilla in this specific sort of case. As an occasional-but-regular filer of bugs and user of Nightly for my daily driver for over ten of the last twelve years, the feeling I have is that where a decade ago they generally wouldn’t ship a thing until it was done, increasingly often in the last few years they have been shipping things despite known significant problems, only finishing things months later, but leaving users in the lurch in the mean time.
(Most recent example that I have in mind: they switched content dark mode from matching OS theme to matching browser theme in 95, despite quite a few immediate and detailed objections as soon as the patch landed on Nightly—and yes, I’m willing to admit that the change will match what some, perhaps more, users want—but didn’t expose it in about:preferences until 100; to my eye, they should fairly obviously have reverted the change until they had that setting, or at the very least mentioned the about:config pref to restore the old behaviour in the release notes. At least in that case there was still a pref for it.)
Having looked at that bug, and seen your reaction to somebody else asking about why you are so concerned about this, I am now of the opinion that your worrying here is a manifestation of https://xkcd.com/1172/.
For reference for people who haven't read the linked bug: the change makes it forbidden to alter CORS and related security headers via extensions, and invites developers to provide use cases where it is necessary so that proper permissions can be designed to permit this. OP complains that this is unreasonable, because... well, "the use case [is] already obvious to your team".
I have taken the time to comment on the pull request before it was merged. I have mentioned several use cases, and offered an explanation for why the feature is important. If that is not enough for you and for Mozilla engineers, then perhaps the correct response is to simply abandon their platform. I've done my part, and I'm not going to further sacrifice my free time because some people have no concern about how their actions affect other people's lives.
It's certain that 2 years from now extension developers will still be getting support requests and receive negative reviews because of that commit, even if an alternative API is released in the next few months. But who cares, it's not you who has to find a solution and deal with users.
All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented. There was no pressing need to immediately restrict the API.
> Disallowing the modification of Access-Control-Allow-* response headers will impact extensions that need to download page content.
> Search by Image sets CORS headers for some images in order to download them from the content script before uploading to a search engine. In many cases an asset will only be served if the request contains the correct origin, referrer and cookies. Reproducing such a fetch request was impossible from a background page last time I tested, and even if configuring all aspects of a request becomes possible, it could still open up extensions to security issues, because it's difficult to figure out if certain data types would be sent by the browser if the request would be made from the page context, such as the referrer. We would also need to request additional permissions, such as access to HTTP cookies.
> Extensions used for archiving pages would no longer be able to create faithful representations of the tab content. Advanced ad blockers such as uBlock Origin would be impacted as well. There is a general issue of extensions not being able to access certain parts of the page, such as a tainted canvas in Chrome, or a closed shadow DOM in Safari, and this restriction would make the problem worse.
I will admit, I did miss your first message. But it was already responded to, with links to the bugs tracking the things that would have provided the functionality you requested.
> All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented.
You mean like manifests v2, which wasn't affected?
I will also note, it was this comment in particular that set me off:
> It must be possible to prevent a patch from being released in the stable version of Firefox. You must be aware that this change will make it difficult to port extensions that need to access arbitrary page content. Extension developers have enough work on their hands already, and we shouldn't need to spend more time submitting feature requests and then defending use cases that are already obvious to your team.
This kind of "I demand you do what I want, and I'm going to refuse any attempt to answer why you should" comment is one that I believe it reasonable for a developer to ignore.
It will affect cross-platform extensions that need to migrate to Manifest V3 this year. Some projects will be forced to stay on Manifest V2 just for Firefox, substantially increasing development cost because of the need to maintain both MV2 and MV3 versions across platforms, or abandon a substantial part of Firefox users and only support the most recent browser version, assuming that a fix is even implemented in the browser.
Regarding your edit, I have not demanded anything, but asked if it would be possible to delay the release, for all the discussed reasons. For which I have received a non-answer, "it has already been merged" is not a valid reason for not correcting a mistake, and asking people to invest even more of their time in this and repeat what has already been discussed in a new bug report was just the last drop that made the lack of respect for other people's time obvious.
Is it Mozilla's fault Google marches on with MV3 with no regard to standards?
Mozilla will continue to support V2 and working towards V3 support. Expecting a fully compatible implementation on the first go is a lot. Especially since Mozilla has a fraction of the budget and other priorities besides aping Chrome.
The issue is not compatibility with Chrome. Projects that were otherwise ready for the Manifest V3 migration and have worked towards that goal in the last few months can no longer proceed with the migration, their work has been made obsolete. The code we wrote no longer works, and we don't even know how or if the issue will be addressed before the next major Firefox ESR release. If a solution is not released in the next few months, this issue will prevent some projects from migrating until the end of 2024, or they will have to contend with dropping support for Firefox ESR.
I hope reading the linked pull request thread and the comments here will make it easier to see what went wrong, and why listening to the people that work with these extension APIs is important.
It is Apple’s fault, but the EU’s DMA will force Apple to allow alternative engines. However this raises many doubts:
- Will Apple just allow every browser in the App Store or they’ll manage to use side load (which they’ll also be forced to allow) as the only way to comply? (Probably not legal but i expect them to try, would vastly limit an App’s user base as demonstrated by Android).
- In the best scenario, wich is Apple letting Mozilla put the full Firefox in the App Store, would they be interested at all to port Gecko to iOS?
You can create your own "extension collection", and change the default one used by FF on Android. I use the Fennec build of FF from F-droid (Playstore build doesn't support this).
Okay, but that's not am acceptable trade off. There is zero reason why letting the user use arbitrary extensions and the unstable version should be connected.
There's still no way to change the User Agent in Firefox Mobile. I switched to Vivaldi because at least there when I tell it to show me the desktop site it shows me the goddamn desktop site.
We'll, that's something. 5 new extensions will bring the total up to 23. I still don't get why they make it so difficult to use any of the thousands of other extensions that are available.
This article seems in search of an audience. It discusses Manifest V3, names uBlock origin, but ends with “don’t worry, you can take your passwords with you if you switch from Chrome!”
I had to chuckle from mentally constructing a character that would fit all of this.
It's upsetting to see all this corporate double-speak when Firefox fails to support the most basic extension functionally: the User Agent should allow the User to run their own code on their own machine without any requirement of phoning home to the manufacturer.
This is currently impossible on Firefox as they forget extension loaded from local files to be removed after. The force everyone who wants to run their own code on their own machine persistently to file for a developer code signing certificate, essentially copying Apple's approach to marketplace management.
Further, this limitation makes auditing the code of extensions you install from third party sources effectively impossible: I don't see any way to stop automatic updates in settings, so at any point the third party code you've installed and enabled to execute on any website you visit can just change out from under you workout warning.
This is all trivial in Edge.
It is difficult to understand where the HN vulpephillia comes from.
> It is difficult to understand where the HN vulpephillia comes from.
I imagine it is in part backlash, fueled by political impulse. Mozilla's appointment of Mitchell Baker and subsequent course of Firefox development have taken on unmistakable political valence in the US culture war (especially seeing how its drift could be uncharitably glossed as "coddling non-technical users at the expense of power users"), which resulted in criticism invariably sounding like, and, I guess, even really somewhat functioning* as an attack on the political group that Mozilla is associated with. This, in turn, makes those who support said political group, or simply are exasperated with its most vocal opponents, instinctively oppose the criticism.
>This is currently impossible on Firefox as they forget extension loaded from local files to be removed after. The force everyone who wants to run their own code on their own machine persistently to file for a developer code signing certificate, essentially copying Apple's approach to marketplace management.
My distro's firefox package loads extensions I zip'd and placed in /usr/lib64/firefox/browser/extensions , probably because it's compiled with `--with-unsigned-addon-scopes=app --allow-addon-sideload`
FOSS authors are catching on to all the tricks that Windows etc closed source authors have been doing - locking down their software, phoning home with telemetry, bundling in closed-source components with non-free licenses and what not. Distro maintainers are the last line of defence against this shit. Don't use upstream binaries.
The official branded releases only require signatures because everything else they tried to stop malware hijacking the browser ultimately failed. Mozilla are not trying to copy iOS, they don't stop you leaving the walled garden if you want to.
When I download the Unbranded/"Nightly" build, it says it's v107.0.1, versus Stable is v109.0. You seemed to be of the impression the declared version string was incorrect, so I dug a bit deeper. The security fixes mentioned in the changelog for v109, such as CVE-2023-23601 [1] are not present in the latest Unbranded/"Nightly" release.
So basically Mozilla telling developers: want to be able to run your own code? Fine. But only if you use a months-old browser subject to a bunch of security vulnerabilities we keep a list of on our website for any would-be attacker to consult.
… then I get a “Nightly” build reporting version 109.0.1.
The direct links to the latest releases should be better maintained for sure, and it did take me longer than I'd like to figure out the build interface.
> Hit the gear and uncheck "Update Add-ons Automatically".
Thanks, my bad for looking for settings in Settings.
> Is it? I can't find the toggle for extension autoupdates in Edge, and a search only turns up hacky methods for Chrome, nothing specific to Edge.
I can't speak to extensions downloaded from the store, as I only sideload. But when sideloaded, the extensions of course do not update unless you explicitly pull changes in or make changes yourself. Sideloading itself is trivial, even Stable builds provide a "Developer Mode" toggle that allows loading unsigned unpacked extensions from local directories.
> The panel shows the user’s installed and enabled extensions and their current permissions. Users are free to grant ongoing access to a website or to make that decision per visit and can remove, report, and manage extensions and their permissions directly from the toolbar.
Does anybody know whether this change allows me (the user) to grant an extension permission to a specific, arbitrary domain only? That is, to take an extension which wants permission to read and write every website, and sandbox it to only a particular set of user-defined domains? Have wanted this for a while.
We build a browser extension for people to demo their own SaaS ( https://www.demogorilla.com ) and while it's never explicitly blocked us, we definitely feel the friction in development from design choices because browsers are being used both as business tools (GSuite) and viewers of webpages funded by ads.
We don't touch anything but the websites a customer already owns, but there are a lot of design choices that really seem to focus on making adblockers (or cookie blockers, JS blockers etc) harder to make (in addition to some very reasonable cross-domain security choices that are annoying but 100% legit).
80 comments
[ 3.9 ms ] story [ 140 ms ] threadI guess I'm getting old and grouchy.
Kind of hoping I can actually order the extensions at some point though, it's a bit messy if you can no longer control which extensions are in the overflow menu or what order they're in.
It allows you to disable extensions only on specific sites. (And presumably, that's also the reason you need to dive into about:config to remove it: if you remove it, it's pretty hard for casual users to find out why an extension isn't working. By gating it behind about:config, people who are able to deal with that can still remove it without rendering casual users helpless. That's my personal interpretation though.)
Hopefully that can be addressed at some point in the near future :)
If you asked the average user about their privacy preserving add-on, or their content blocker they would probably be confused.
Yes, obviously I understand the privacy dimensions of advertising, and I realize that this is all in the service of the good guys and against the bad guys, but that shouldn't affect our response to what seems to me to be unnecessary spin.
I completely agree: it is a good rhetorical move. aka good spin. But I don't think we should celebrate that sort of thing in tech blog posts, or in any writing actually unless your work in marketing.
I use them, and DNS filters, to block stalking. They just happen to block adverts too because it is practically impossible to separate the two ATM. I'll accept ads based on the page I'm looking at and my rough geographical position, but I don't see why I should put up with being followed and profiled everywhere I go.
But crucially, not just ads — they block trackers, known malware source, etc. "Content blockers" encompasses everything that these tools do.
If ads give you the ick, then one distinction we’ve made around ad blockers has been especially crucial to privacy-lovers everywhere.
> If ads give you the ick, then one distinction we’ve made around ad blockers has been especially crucial to privacy-lovers everywhere.
https://bugzilla.mozilla.org/show_bug.cgi?id=1786919
They have merged a change that makes it impossible to access and download certain website content the user is viewing and wants to process. Now that Firefox has introduced this limitation without offering an alternative, it is now much easier to port some of my extensions to Manifest V3 on Chrome, despite Chrome not supporting the blocking webRequest API.
It's disheartening to see how these changes are introduced without any planning or care for how it affects extensions that are being ported to Manifest V3, and the general lack of respect towards extension developers.
Firefox is going to continue to have more powerful blocking features compared to what a DNS based approach like pihole can provide.
[1]: https://assets.mozilla.net/annualreport/2021/mozilla-fdn-202...
Or, rephrased: could gorhill conceivably upgrade uBlock Origin's manifest.json to v3, while still using the v2 content blocking APIs?
(Most recent example that I have in mind: they switched content dark mode from matching OS theme to matching browser theme in 95, despite quite a few immediate and detailed objections as soon as the patch landed on Nightly—and yes, I’m willing to admit that the change will match what some, perhaps more, users want—but didn’t expose it in about:preferences until 100; to my eye, they should fairly obviously have reverted the change until they had that setting, or at the very least mentioned the about:config pref to restore the old behaviour in the release notes. At least in that case there was still a pref for it.)
For reference for people who haven't read the linked bug: the change makes it forbidden to alter CORS and related security headers via extensions, and invites developers to provide use cases where it is necessary so that proper permissions can be designed to permit this. OP complains that this is unreasonable, because... well, "the use case [is] already obvious to your team".
It's certain that 2 years from now extension developers will still be getting support requests and receive negative reviews because of that commit, even if an alternative API is released in the next few months. But who cares, it's not you who has to find a solution and deal with users.
All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented. There was no pressing need to immediately restrict the API.
> Disallowing the modification of Access-Control-Allow-* response headers will impact extensions that need to download page content.
> Search by Image sets CORS headers for some images in order to download them from the content script before uploading to a search engine. In many cases an asset will only be served if the request contains the correct origin, referrer and cookies. Reproducing such a fetch request was impossible from a background page last time I tested, and even if configuring all aspects of a request becomes possible, it could still open up extensions to security issues, because it's difficult to figure out if certain data types would be sent by the browser if the request would be made from the page context, such as the referrer. We would also need to request additional permissions, such as access to HTTP cookies.
> Extensions used for archiving pages would no longer be able to create faithful representations of the tab content. Advanced ad blockers such as uBlock Origin would be impacted as well. There is a general issue of extensions not being able to access certain parts of the page, such as a tainted canvas in Chrome, or a closed shadow DOM in Safari, and this restriction would make the problem worse.
> All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented.
You mean like manifests v2, which wasn't affected?
I will also note, it was this comment in particular that set me off:
> It must be possible to prevent a patch from being released in the stable version of Firefox. You must be aware that this change will make it difficult to port extensions that need to access arbitrary page content. Extension developers have enough work on their hands already, and we shouldn't need to spend more time submitting feature requests and then defending use cases that are already obvious to your team.
This kind of "I demand you do what I want, and I'm going to refuse any attempt to answer why you should" comment is one that I believe it reasonable for a developer to ignore.
Regarding your edit, I have not demanded anything, but asked if it would be possible to delay the release, for all the discussed reasons. For which I have received a non-answer, "it has already been merged" is not a valid reason for not correcting a mistake, and asking people to invest even more of their time in this and repeat what has already been discussed in a new bug report was just the last drop that made the lack of respect for other people's time obvious.
Mozilla will continue to support V2 and working towards V3 support. Expecting a fully compatible implementation on the first go is a lot. Especially since Mozilla has a fraction of the budget and other priorities besides aping Chrome.
I hope reading the linked pull request thread and the comments here will make it easier to see what went wrong, and why listening to the people that work with these extension APIs is important.
I'd rather use the version of Firefox that doesn't crash more frequently, but that's the trade-off I gotta make at the moment.
You can create your own "extension collection", and change the default one used by FF on Android. I use the Fennec build of FF from F-droid (Playstore build doesn't support this).
Currently I'm using Iceraven which is essentially just Firefox with about a thousand extensions enabled instead of 17.
https://blog.mozilla.org/addons/2022/12/15/new-extensions-av...
I had to chuckle from mentally constructing a character that would fit all of this.
This is currently impossible on Firefox as they forget extension loaded from local files to be removed after. The force everyone who wants to run their own code on their own machine persistently to file for a developer code signing certificate, essentially copying Apple's approach to marketplace management.
Further, this limitation makes auditing the code of extensions you install from third party sources effectively impossible: I don't see any way to stop automatic updates in settings, so at any point the third party code you've installed and enabled to execute on any website you visit can just change out from under you workout warning.
This is all trivial in Edge.
It is difficult to understand where the HN vulpephillia comes from.
I imagine it is in part backlash, fueled by political impulse. Mozilla's appointment of Mitchell Baker and subsequent course of Firefox development have taken on unmistakable political valence in the US culture war (especially seeing how its drift could be uncharitably glossed as "coddling non-technical users at the expense of power users"), which resulted in criticism invariably sounding like, and, I guess, even really somewhat functioning* as an attack on the political group that Mozilla is associated with. This, in turn, makes those who support said political group, or simply are exasperated with its most vocal opponents, instinctively oppose the criticism.
*I'm thinking of something like the affect-loading concept in https://slatestarcodex.com/2014/11/04/ethnic-tension-and-mea....
My distro's firefox package loads extensions I zip'd and placed in /usr/lib64/firefox/browser/extensions , probably because it's compiled with `--with-unsigned-addon-scopes=app --allow-addon-sideload`
FOSS authors are catching on to all the tricks that Windows etc closed source authors have been doing - locking down their software, phoning home with telemetry, bundling in closed-source components with non-free licenses and what not. Distro maintainers are the last line of defence against this shit. Don't use upstream binaries.
xpinstall.signatures.required
At least I think thats the one. Also extension updating can be disabled globally or on a per extension basis in the addons setting page.
Edit: note that you have to package (zip) the extension. You can't keep an unpacked extension loaded.
The official branded releases only require signatures because everything else they tried to stop malware hijacking the browser ultimately failed. Mozilla are not trying to copy iOS, they don't stop you leaving the walled garden if you want to.
So basically Mozilla telling developers: want to be able to run your own code? Fine. But only if you use a months-old browser subject to a bunch of security vulnerabilities we keep a list of on our website for any would-be attacker to consult.
[1] https://www.mozilla.org/en-US/security/advisories/mfsa2023-0...
• https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded... (click “release”)
• https://treeherder.mozilla.org/jobs?repo=mozilla-release&sea... (click the date of the most recent complete build)
• https://treeherder.mozilla.org/jobs?repo=mozilla-release&sea... (click “B” next to your desired platform, OS X in my case)
• https://treeherder.mozilla.org/jobs?repo=mozilla-release&sea... (click “Artifacts and Debugging”, then “target.dmg”/“target.zip”)
• https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task...
… then I get a “Nightly” build reporting version 109.0.1.
The direct links to the latest releases should be better maintained for sure, and it did take me longer than I'd like to figure out the build interface.
Hit the gear and uncheck "Update Add-ons Automatically".
>This is all trivial in Edge.
Is it? I can't find the toggle for extension autoupdates in Edge, and a search only turns up hacky methods for Chrome, nothing specific to Edge.
Thanks, my bad for looking for settings in Settings.
> Is it? I can't find the toggle for extension autoupdates in Edge, and a search only turns up hacky methods for Chrome, nothing specific to Edge.
I can't speak to extensions downloaded from the store, as I only sideload. But when sideloaded, the extensions of course do not update unless you explicitly pull changes in or make changes yourself. Sideloading itself is trivial, even Stable builds provide a "Developer Mode" toggle that allows loading unsigned unpacked extensions from local directories.
Does anybody know whether this change allows me (the user) to grant an extension permission to a specific, arbitrary domain only? That is, to take an extension which wants permission to read and write every website, and sandbox it to only a particular set of user-defined domains? Have wanted this for a while.
We don't touch anything but the websites a customer already owns, but there are a lot of design choices that really seem to focus on making adblockers (or cookie blockers, JS blockers etc) harder to make (in addition to some very reasonable cross-domain security choices that are annoying but 100% legit).