5 ms·

Firefox no longer allows extensions to have full control over requests in Manifest V3, despite their repeated public statements. https://bugzilla.mozilla.org/s

Firefox no longer allows extensions to have full control over requests in Manifest V3, despite their repeated public statements. https://bugzilla.mozilla.org/show_bug.cgi?id=1786919 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.

tommica 4y ago
No fucking way - I guess its time to setup pihole again
- evilpie 4y ago
  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.
- NegativeLatency 4y ago
  FWIW I switched to adguard home and it's been much more reliable for me
RobotToaster 4y ago
Once again they ruin the extension API to please their overlord google.
- tannhaeuser 4y ago
  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. [1]: https://assets.mozilla.net/annualreport/2021/mozilla-fdn-2021-fs-final-1010.pdf https://assets.mozilla.net/annualreport/2021/mozilla-fdn-202...
- ipaddr 4y ago
  Rare to see a company so over funded but can't work on it's core mission because the money tap will slow.
rom-antics 4y ago
Is the content-blocking model tied to the manifest version, or can you mix and match? Or, rephrased: could gorhill conceivably upgrade uBlock Origin's manifest.json to v3, while still using the v2 content blocking APIs?
- cmeacham98 4y ago
  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).
Vinnl 4y ago
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).
- dessant 4y ago
  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.
  - Vinnl 4y ago
    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.
- chrismorgan 4y ago
  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.)
deleted 4y ago
[deleted]
evilpie 4y ago
Did you ever get around to communicating your use-case to the developers?
deleted 4y ago
[deleted]
jcranmer 4y ago
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/ 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".
- dessant 4y ago
  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.

tommica 4y ago

No fucking way - I guess its time to setup pihole again

evilpie 4y ago
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.
NegativeLatency 4y ago
FWIW I switched to adguard home and it's been much more reliable for me

RobotToaster 4y ago

Once again they ruin the extension API to please their overlord google.

tannhaeuser 4y ago
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. [1]: https://assets.mozilla.net/annualreport/2021/mozilla-fdn-2021-fs-final-1010.pdf https://assets.mozilla.net/annualreport/2021/mozilla-fdn-202...
ipaddr 4y ago
Rare to see a company so over funded but can't work on it's core mission because the money tap will slow.

rom-antics 4y ago

Is the content-blocking model tied to the manifest version, or can you mix and match? Or, rephrased: could gorhill conceivably upgrade uBlock Origin's manifest.json to v3, while still using the v2 content blocking APIs?

cmeacham98 4y ago
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).

Vinnl 4y ago

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).

dessant 4y ago
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.
- Vinnl 4y ago
  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.
chrismorgan 4y ago
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.)

deleted 4y ago

[deleted]

evilpie 4y ago

Did you ever get around to communicating your use-case to the developers?

deleted 4y ago

[deleted]

jcranmer 4y ago

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/ 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".

dessant 4y ago
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.