8 ms·

Mozilla’s Manifest v3 FAQ

266 points by Findus23 7y ago

danShumway 7y ago
> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. About as close as Mozilla can come to outright saying, "Chrome is big enough and we're small enough that what they do _is_ the standard." Still, it's encouraging to see that they're not removing the blocking API for now. I kind of hope this does push a few adblocker extensions to abandon Chrome.
- zzzcpan 7y ago
  I find it rather discouraging to hear they are not removing the blocking API for now. It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.
  - wtallis 7y ago
    It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.
    - Jonnax 7y ago
      A rewrite that is faster than Chrome for Android.
      - hajile 7y ago
        It may be faster than Chrome on Android, but it's certainly not faster than Firefox on Android with adblockers. Not loading/parsing multi-megabytes of Javascript and images is huge. Loads of ads these days incorporate entire JS framework toolchains resulting in a binary bigger than the page they're being injected into. Eliminating a few ads and the rest of your browser could be a lot less efficient and still perform well. That's all before discussing how adblockers also reduce who is tracking you everywhere.
        Jonnax 7y ago
        It certainly is faster than Firefox for Android. There are benefits to adblocking of course. But there's no point lying.
        tgsovlerkhgsel 7y ago
        In my experience and limited testing, even with warmed-up caches, Chrome (without Adblocker) was faster than Firefox (with or without Adblocker), sadly. I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).
      - bscphil 7y ago
        Eh. That may be the intent but they aren't there yet. I tested Firefox Preview on Speedometer 2.0 and got the same result I did with Firefox for Android 68. Chrome gets double the score (runs per minute) on my device.
    - lol768 7y ago
      And the other point of view, directly from Mozilla: > We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now. > We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months. Source: https://news.ycombinator.com/item?id=20298143 https://news.ycombinator.com/item?id=20298143 This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?
      - mjw1007 7y ago
        In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ». They very visibly didn't take the opportunity to do so. From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
        lol768 7y ago
        Thanks for this. >From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix. Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?
        deleted 7y ago
        [deleted]
        mjw1007 7y ago
        https://blog.mozilla.org/futurereleases/2019/06/27/reinventing-firefox-for-android-a-preview/ https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall". https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019. The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant). https://github.com/mozilla-mobile/fenix/issues/574 https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say: « Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. » The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are. It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete. https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.
  - Allower 7y ago
    And the alternative is an even more ridiculous claim to NEVER remove this API. Committing to your users needs and priorities is understanding that THEY MIGHT CHANGE.
- Ygg2 7y ago
  > adblocker extensions to abandon Chrome. Ha. As if that will ever happen. They'll probably just pivot to something else. The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.
  - Iolaum 7y ago
    Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.
    - jefftk 7y ago
      > Chrome has already ditched adblockers on mobile nit: chrome has never had extensions (or ad blockers) on mobile (Disclosure: I work for Google)
      - SquareWheel 7y ago
        That's not even a nitpick. The parent got it completely wrong. If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.
        michaelmrose 7y ago
        They being an ad company were smart enough not to ever allow the camel to get its nose under the tent.
        awalton 7y ago
        From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features. Thus, not "completely wrong."
    - Ygg2 7y ago
- Endy 7y ago
  What they should be saying is, "No, what Google is doing is Wrong with a capital WRONG and we're not going to accept their wishes in closing off what's left of the open Web." But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.
  - tomComb 7y ago
    > "closing off what's left of the open Web." Seems a little over the top to me! Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.
    - hu3 7y ago
      > rust is arguably supplanting go Two very different languages with very different goals. Neither want nor ever will suplant the other.
      - sjwright 7y ago
        Rust is challenging C++ fairly head-on. Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...
    - atroche 7y ago
      How did Mozilla kill web components?
ocdtrekkie 7y ago
This points to the disturbing truth of how incredibly complete Google's monopoly is: Even browsers not based on Chrome are strongly pushed to implement Chrome's platform changes anyways.
- badsectoracula 7y ago
  Mozilla abandoning their much more powerful XUL-based extension system for Chrome's inferior WebExtensions wasn't already an indicator towards that?
  - Ygg2 7y ago
    > more powerful XUL-based At the time of conception, it was pretty great. However, that much customizability came at two expenses. 1) Web devs can't use XUL, because it's its own little cosmos, you as Web dev couldn't mod Firefox UI 2) The XUL was legacy software and super hard to optimize.
    - pessimizer 7y ago
      Repeal and replace would have been fine, but instead we got repeal and here's a mobile OS. And new extensions can't mess with our look and feel.
  - sp332 7y ago
    Firefox is faster and more secure now that they don't have to maintain compatibility with a bunch of old extensions that touch a bunch of internal stuff. Firefox's WebExtension API goes well beyond Chrome's at this point and is still adding features.
    - pessimizer 7y ago
      Firefox is a clone of Chrome now, that google makes a little bit janky when you browse google sites.
  - cptskippy 7y ago
ryuukk_ 7y ago
hacker news is run by mozilla employees, it shows too much time to leave that website
muddi900 7y ago
This is disappointing. Mozilla can't seem to make up their mind if they want to offer a different product from google or just "Chrome, but for nerds"
sorenjan 7y ago
> Cross-origin communication: In Manifest v3, content scripts will have the same permissions as the page they are injected in. We are planning to implement this change. What will this mean for GM.xmlHttpRequest in userscripts? Adding content from several different sites with userscripts can be very powerful.
- input_sh 7y ago
  Stylus (Stylish without the tracking) sure is a nice interface, but you don't really need an add-on for that functionality. Create "chrome/userContent.css" within your Firefox profile directory and populate it with something like: @-moz-document domain(example.com) { img { opacity: 0.05 !important; } } Note that there's some about:config flag that needs to be switched since the version that got released today.
- xg15 7y ago
  Was wondering about that too - but this seems to be just a Spectre defense, not a change in what extensions can do. The change[1] only affects content scripts because they run in the same process as the website. You're still able to fetch arbitrary origins in a background page. So GM has to move the fetch to the background page, then send the content to the script via message passing. [1] https://www.chromium.org/Home/chromium-security/extension-content-script-fetches https://www.chromium.org/Home/chromium-security/extension-co... .
WhatIsDukkha 7y ago
The tone of this post concerns me. What comes across is that Google is not collaborating with Mozilla over the Manifest v3 changes. Instead of using and appreciating the engaged Firefox developer ecosystem we have PM conference rooms in Google mandating huge changes based on... well they've been shady so far about their choices on Manifest v3. The other thing that keeps bugging me about this is - We need a tiered App store for browsers. Part of the lockdown Google wants to do isn't wrong but its driven by having WAY too many bad actors and shoddy developers in their Chrome store. If you have an opensource web extension, a reasonable community and with reproducible builds? You can use more powerful API versions. If you are jrando bizplan #2000283 you get the kinda trusted tier. Frankly if Debian had a web browser extension "store" with 20 things in it, I'd use that exclusively and turn off both the Chrome and the Firefox store 100%.
- derefr 7y ago
  > a tiered App store We kinda have one; the tiers are "the public app store" and "your enterprise's private collection of apps, whitelisted by GSuite policy on your GSuite users." Things are in equilibrium because no big player is complaining; and no big players are complaining because they have all their needs met by just 1. getting custom extension builds from vendors, 2. signing them with their enterprise cert, 3. pushing them to some object store, and 4. telling GSuite to allow them (https://docs.google.com/document/d/1pT0ZSbGdrbGvuCsVD2jjxrw-GVz-80rMS2dgkkquhTY/edit#heading=h.ojow7ntunwpx https://docs.google.com/document/d/1pT0ZSbGdrbGvuCsVD2jjxrw-...).
- beacker 7y ago
  > Frankly if Debian had a web browser extension "store" with 20 things in it, I'd use that exclusively and turn off both the Chrome and the Firefox store 100%. There are a handful of extensions for Firefox and Chrome in the Debian repositories: https://packages.debian.org/search?keywords=webext-&searchon=names&suite=stable&section=all https://packages.debian.org/search?keywords=webext-&searchon...
  - WhatIsDukkha 7y ago
    WOW that's awesome! It's actually pretty close... no Vimium but ublock origin/matrix, tree style tab, privacy badger, browserpass <3 Here is what's in Sid - https://packages.debian.org/search?suite=sid&searchon=names&keywords=webext- https://packages.debian.org/search?suite=sid&searchon=names&...
purple_ducks 7y ago
Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!): https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...
- Ajedi32 7y ago
  Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking? Given the level of cynicism directed at Google by the HN community, is it even possible for Chrome to lock down extension permissions in a way which wouldn't be seen as some sort of aggressive move against ad blocking? Keep in mind that secure, user-friendly permissions systems do have to be somewhat restrictive in order to be effective (see Android, iOS, etc), and that ad blocking extensions will necessarily be impacted as a result.
  - purple_ducks 7y ago
    Maybe make this step after discussing & listening to the other browser makers who support extensions. Maybe listen to the people who actually write the ad blockers. >"I think they've been trying to give the impression that they’re working with the developer community, when in fact they’re pretty entrenched in what they want to do," says Jeremy Tillman, president of the privacy and security-focused ad blocker Ghostery." https://www.wired.com/story/google-chrome-ad-blockers-extensions-api/ https://www.wired.com/story/google-chrome-ad-blockers-extens...
  - michaelmrose 7y ago
    It doesn't lock down the ability of extensions to inspect and spy on all your traffic just block it. This in and of itself demonstrates the purpose. Also lets be real there are only a handful of adblocking extensions that have most of the market share run by legit players they could trivially vet and whitelist a small number of extensions that are allowed this privilege. It's not about security its clearly about ruining adblocking. A tiny blocklist that can only be updated with the extensions ensures that it is always trivial to work around blockers. One can simply ask which which version of the extension one has and load ads from a url/host created since.
Nicksil 7y ago
> We have no immediate plans to remove blocking webRequest > immediate We know exactly what this kind of talk means. Don't blow smoke up our ass, Mozilla, just give it to use straight: We'll have `blocking webRequest` for as long as Google allows it.
- derefr 7y ago
  Or, potentially, it's an equivocation because they want to give Google the appearance of maybe caving later (or at least the inability for Google to claim that they had the opposite appearance), while secretly hoping something changes such that they don't have to cave (and also, possibly, applying pressure below the radar to achieve that end.) Politics!
- apazzolini 7y ago
  I switched from Chrome to Firefox a couple of months ago when the Chrome adblocking changes were announced. I'll happily find something other than Firefox if it goes down the same route.
  - Endy 7y ago
    Try out Pale Moon or Waterfox.
- jerf 7y ago
  I understand Google's motivation for nuking ad blockers, as well as their motivations for denying every which way that that is what they want to do under whatever security justifications they can bring up, even true ones. I don't see Mozilla's motivation to remove that at the moment. I mean, speaking for myself, I'd drop them both and follow a fork of the browser that lets uMatrix work, and that's not something I've considered very many times in the past 20 years. Control over what my browser actually connects to has become a top-3 feature concern for me. I was going to say "I suppose 'working' is technically more important to me", but then I mentally wargamed out whether I'd be willing to use a slightly nonfunctional browser to have uMatrix and noticed that I actually already put up with a slightly nonfunctional browser to use it, because uMatrix already breaks a number of sites until I do some whitelisting. Even if there's a security impact to extensions having too much access to the web request cycle, there's a security impact to them not having enough access to the web request, too.
ohazi 7y ago
I hope the ad blockers completely abandon Chrome when this change gets pushed through, rather than attempting to work around it. Google is using a slow-frog-boil approach to re-desensitize their users to ads, and it's working. The only thing that will work here is a big splash of cold water to the face. Maybe Chrome losing all of its ad-blockers overnight will finally start making a dent.
- cptskippy 7y ago
  Unfortunately the owners of the most popular adblocker have successfully created a revenue generating business out of adblocking and aren't about to abandon Chrome.
- pvg 7y ago
  Chrome launched without any support for extensions. chrome.webRequest didn't appear until the end of 2013.
- hnaccy 7y ago
  Outside of uBlock Origin the popular ad blockers are business (see pay for acceptable adds), there's no way they abandon chrome.
malicioususer11 7y ago
Bro if u still wana block javascript just use Ecosia. :)
feanaro 7y ago
In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. It's also quite disappointing how there is seemingly no one from Mozilla here, engaging with us on this topic. Instead, the only communication we get is one-sided corporate speak, with no real ability to respond. If anyone from Mozilla is reading, who do you think will spread Firefox among non-technical users if not the type of crowd that frequents HN?
- chucksmash 7y ago
  > In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. That's exactly what they've tried to do. Firefox exposes a `chrome` namespace object to extensions which is intended to be more or less API compatible with what Chrome provides and added the `browser` namespace object where improvements to the base compatibility are added (e.g. switching from callback based APIs to Promise based APIs). See the bit from the wiki below and the link to the browserext spec: > Mozilla has worked with Microsoft and Opera to implement browser extensions so that developers can write extensions that work across multiple browsers. The preliminary specification[1] matches what Google has implemented in Chrome so that extensions will work on Chrome, Edge, Opera and Firefox.[2] [1]: https://browserext.github.io/browserext/ https://browserext.github.io/browserext/ [2]: https://wiki.mozilla.org/WebExtensions/Spec https://wiki.mozilla.org/WebExtensions/Spec
  - feanaro 7y ago
    Well, it's not enough to try, unfortunately. They have to persist and this talk about the importance of keeping compatibility with Chrome in the context of blocking webRequest removal is not very encouraging.
eh78ssxv2f 7y ago
It seems I'm in a minority here, but I was never comfortable installing any adblock extension because the existing request blocking API means that the extension would see all web traffic generated by me (including private URLs that are otherwise not known to anybody but me). I personally feel that now with manifest 3, I can actually install adblockers since the newer APIs do not share all my web traffic with the extensions. Can somebody explain why removing blocking API was overall a bad decision by Chrome?
- kuzimoto 7y ago
  > Extensions would still be able to use webRequest but only to observe requests, not to modify or block them. What's the point of an ad blocker if it doesn't block ads?
- gorhill 7y ago
  > the newer APIs do not share all my web traffic with the extensions The webRequest API can observe the URLs you visit without needing blocking permission. And so does the webNavigation API, the tabs API, history API, content scripts, possibly cookies API and whatever else does not come to my mind.
  - SquareWheel 7y ago
    Shouldn't those be visible in the permissions prompt, prior to installing the extension?
- amluto 7y ago
  I’d like to see this done along the lines of how iOS handles keyboards: allow full web request reading and modification, but only in a sandbox that is per-origin.
- zaarn 7y ago
  uBlock is open source, you can verify that the extension in your browser is the same that is published in the github repository. The blocking API being removed is an issue because the replacement does not cover all use cases and severely limits what ad blockers can do to intercept filtered content. Google is obviously aiming to boil the frog slowly and make ad blockers a such terrible experience that Chrome users will not use them.
michaelmrose 7y ago
A humble proposal: A build of firefox that initially differs from Mozillas in that - it has a different default search engine selection that can be sold in the same way that Mozilla sells this same feature to google presently - no ads on new tab page - bundled with ublock origin The goal being to increase the value of selling the search engine selection while decreasing the value of mozillas in effect siphoning off some of the value of mozillas primary revenue stream. Such funds could be donated back to Mozilla or used to maintain a fork that doesn't ruin adblocking. Their choice.
phkahler 7y ago
I dont like the idea of extensions being able to inject data in either direction. On top of that, I'm not in favor of extensions doing anything to improve security - I want that in the base browser.
SirensOfTitan 7y ago
Mozilla really needs to get that if they compete with Google on Google’s terms, they’re rapidly heading toward extinction. Mozilla ought to be the browser for a private and usable web, but it seems they have occasional sneezes where you question what they’re doing (this, pocket in recent memory).
- echelon 7y ago
  I'm extremely worried that once Google disables ad blockers in Chrome, websites will wholesale block any and all non-Chrome browsers. Be it through user agent sniffing, feature detection, or fingerprinting, Firefox simply won't work anymore. The future of the web where Google is in complete control is straight up nightmare fuel. Microsoft in the early 2000s never scared me as much as the future we're headed into does. This won't be IE versus Netscape since websites are no longer served as plain old HTML. They're messy, thick, and impenetrable javascript blobs--not documents. We're not arguing about websites simply not rendering correctly in the less popular browser. This is a battle for the absolute control over information distribution. What do we do to prevent what's happening? Google already shot down XHTML, which was rich with semantics. That was a web written for documents and tools that could query those documents for meaning. Whatever Google has become needs to be dismantled. The ad company can't be the browser company and phone company. It's a perverse alignment of incentives.
  - tomComb 7y ago
    > This won't be IE versus Netscape since... Well, also since Chrome if open source, cross platform, and standards compliant, and IE was none of those. And Google (unlike Apple) allows competing browsers, based on modified Chrome code, or entirely different engines. Soon we will have a good, cross platform Edge browser, thanks to Google, and a menu of browser options in Europe thanks to the EU. (Maybe other countries should push for the same.) But Chrome if no IE. And I believe that in Europe they will soon be
levani 7y ago
Really interesting what the new Edge is going to do in this regard...
rrix2 7y ago
perhaps a more optimistic take on "no immediate plans": there could eventually be an alternate standard for webrequest that addresses Chrome Devs' (perhaps legitimate) privacy concerns around most extensions being able to sniff, modify, and log all of your traffic on the entire web with a single, unobtrusive modal click. There is room to make the web platform more secure without stripping power from the user-agent, surely, or giving bad actors a trivial foothold. Frankly, my concerns around the webrequest API are numerous, the only reason IMO that Chrome isn't deprecating webrequest in Enterprise builds is for corporate spyware. At the very least a new webrequest spec that is more ergonomic and more safe than the webrequest API (without neuturing adblock) could show whether the emperor has no clothes, vis a vis "Google Adtech is directly influencing Chrome and web platform development" plots
kup0 7y ago
"no immediate plans to remove blocking webRequest" ... yikes

266 points by Findus23 7y ago

> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. About as close as Mozilla can come to outright saying, "Chrome is big enough and we're small enough that what they do _is_ the standard." Still, it's encouraging to see that they're not removing the blocking API for now. I kind of hope this does push a few adblocker extensions to abandon Chrome.

zzzcpan 7y ago
I find it rather discouraging to hear they are not removing the blocking API for now. It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.
- wtallis 7y ago
  It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.
  - Jonnax 7y ago
    A rewrite that is faster than Chrome for Android.
    - hajile 7y ago
      It may be faster than Chrome on Android, but it's certainly not faster than Firefox on Android with adblockers. Not loading/parsing multi-megabytes of Javascript and images is huge. Loads of ads these days incorporate entire JS framework toolchains resulting in a binary bigger than the page they're being injected into. Eliminating a few ads and the rest of your browser could be a lot less efficient and still perform well. That's all before discussing how adblockers also reduce who is tracking you everywhere.
      - Jonnax 7y ago
        It certainly is faster than Firefox for Android. There are benefits to adblocking of course. But there's no point lying.
      - tgsovlerkhgsel 7y ago
        In my experience and limited testing, even with warmed-up caches, Chrome (without Adblocker) was faster than Firefox (with or without Adblocker), sadly. I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).
    - bscphil 7y ago
      Eh. That may be the intent but they aren't there yet. I tested Firefox Preview on Speedometer 2.0 and got the same result I did with Firefox for Android 68. Chrome gets double the score (runs per minute) on my device.
  - lol768 7y ago
    And the other point of view, directly from Mozilla: > We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now. > We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months. Source: https://news.ycombinator.com/item?id=20298143 https://news.ycombinator.com/item?id=20298143 This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?
    - mjw1007 7y ago
      In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ». They very visibly didn't take the opportunity to do so. From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
      - lol768 7y ago
        Thanks for this. >From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix. Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?
        deleted 7y ago
        [deleted]
        mjw1007 7y ago
        https://blog.mozilla.org/futurereleases/2019/06/27/reinventing-firefox-for-android-a-preview/ https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall". https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019. The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant). https://github.com/mozilla-mobile/fenix/issues/574 https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say: « Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. » The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are. It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete. https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.
- Allower 7y ago
  And the alternative is an even more ridiculous claim to NEVER remove this API. Committing to your users needs and priorities is understanding that THEY MIGHT CHANGE.
Ygg2 7y ago
> adblocker extensions to abandon Chrome. Ha. As if that will ever happen. They'll probably just pivot to something else. The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.
- Iolaum 7y ago
  Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.
  - jefftk 7y ago
    > Chrome has already ditched adblockers on mobile nit: chrome has never had extensions (or ad blockers) on mobile (Disclosure: I work for Google)
    - SquareWheel 7y ago
      That's not even a nitpick. The parent got it completely wrong. If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.
      - michaelmrose 7y ago
        They being an ad company were smart enough not to ever allow the camel to get its nose under the tent.
      - awalton 7y ago
        From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features. Thus, not "completely wrong."
  - Ygg2 7y ago
Endy 7y ago
What they should be saying is, "No, what Google is doing is Wrong with a capital WRONG and we're not going to accept their wishes in closing off what's left of the open Web." But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.
- tomComb 7y ago
  > "closing off what's left of the open Web." Seems a little over the top to me! Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.
  - hu3 7y ago
    > rust is arguably supplanting go Two very different languages with very different goals. Neither want nor ever will suplant the other.
    - sjwright 7y ago
      Rust is challenging C++ fairly head-on. Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...
  - atroche 7y ago
    How did Mozilla kill web components?

ocdtrekkie 7y ago

This points to the disturbing truth of how incredibly complete Google's monopoly is: Even browsers not based on Chrome are strongly pushed to implement Chrome's platform changes anyways.

badsectoracula 7y ago
Mozilla abandoning their much more powerful XUL-based extension system for Chrome's inferior WebExtensions wasn't already an indicator towards that?
- Ygg2 7y ago
  > more powerful XUL-based At the time of conception, it was pretty great. However, that much customizability came at two expenses. 1) Web devs can't use XUL, because it's its own little cosmos, you as Web dev couldn't mod Firefox UI 2) The XUL was legacy software and super hard to optimize.
  - pessimizer 7y ago
    Repeal and replace would have been fine, but instead we got repeal and here's a mobile OS. And new extensions can't mess with our look and feel.
- sp332 7y ago
  Firefox is faster and more secure now that they don't have to maintain compatibility with a bunch of old extensions that touch a bunch of internal stuff. Firefox's WebExtension API goes well beyond Chrome's at this point and is still adding features.
  - pessimizer 7y ago
    Firefox is a clone of Chrome now, that google makes a little bit janky when you browse google sites.
- cptskippy 7y ago

ryuukk_ 7y ago

hacker news is run by mozilla employees, it shows too much time to leave that website

muddi900 7y ago

This is disappointing. Mozilla can't seem to make up their mind if they want to offer a different product from google or just "Chrome, but for nerds"

sorenjan 7y ago

> Cross-origin communication: In Manifest v3, content scripts will have the same permissions as the page they are injected in. We are planning to implement this change. What will this mean for GM.xmlHttpRequest in userscripts? Adding content from several different sites with userscripts can be very powerful.

input_sh 7y ago
Stylus (Stylish without the tracking) sure is a nice interface, but you don't really need an add-on for that functionality. Create "chrome/userContent.css" within your Firefox profile directory and populate it with something like: @-moz-document domain(example.com) { img { opacity: 0.05 !important; } } Note that there's some about:config flag that needs to be switched since the version that got released today.
xg15 7y ago
Was wondering about that too - but this seems to be just a Spectre defense, not a change in what extensions can do. The change[1] only affects content scripts because they run in the same process as the website. You're still able to fetch arbitrary origins in a background page. So GM has to move the fetch to the background page, then send the content to the script via message passing. [1] https://www.chromium.org/Home/chromium-security/extension-content-script-fetches https://www.chromium.org/Home/chromium-security/extension-co... .

WhatIsDukkha 7y ago

The tone of this post concerns me. What comes across is that Google is not collaborating with Mozilla over the Manifest v3 changes. Instead of using and appreciating the engaged Firefox developer ecosystem we have PM conference rooms in Google mandating huge changes based on... well they've been shady so far about their choices on Manifest v3. The other thing that keeps bugging me about this is - We need a tiered App store for browsers. Part of the lockdown Google wants to do isn't wrong but its driven by having WAY too many bad actors and shoddy developers in their Chrome store. If you have an opensource web extension, a reasonable community and with reproducible builds? You can use more powerful API versions. If you are jrando bizplan #2000283 you get the kinda trusted tier. Frankly if Debian had a web browser extension "store" with 20 things in it, I'd use that exclusively and turn off both the Chrome and the Firefox store 100%.

derefr 7y ago
> a tiered App store We kinda have one; the tiers are "the public app store" and "your enterprise's private collection of apps, whitelisted by GSuite policy on your GSuite users." Things are in equilibrium because no big player is complaining; and no big players are complaining because they have all their needs met by just 1. getting custom extension builds from vendors, 2. signing them with their enterprise cert, 3. pushing them to some object store, and 4. telling GSuite to allow them (https://docs.google.com/document/d/1pT0ZSbGdrbGvuCsVD2jjxrw-GVz-80rMS2dgkkquhTY/edit#heading=h.ojow7ntunwpx https://docs.google.com/document/d/1pT0ZSbGdrbGvuCsVD2jjxrw-...).
beacker 7y ago
> Frankly if Debian had a web browser extension "store" with 20 things in it, I'd use that exclusively and turn off both the Chrome and the Firefox store 100%. There are a handful of extensions for Firefox and Chrome in the Debian repositories: https://packages.debian.org/search?keywords=webext-&searchon=names&suite=stable&section=all https://packages.debian.org/search?keywords=webext-&searchon...
- WhatIsDukkha 7y ago
  WOW that's awesome! It's actually pretty close... no Vimium but ublock origin/matrix, tree style tab, privacy badger, browserpass <3 Here is what's in Sid - https://packages.debian.org/search?suite=sid&searchon=names&keywords=webext- https://packages.debian.org/search?suite=sid&searchon=names&...

purple_ducks 7y ago

Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!): https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...

Ajedi32 7y ago
Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking? Given the level of cynicism directed at Google by the HN community, is it even possible for Chrome to lock down extension permissions in a way which wouldn't be seen as some sort of aggressive move against ad blocking? Keep in mind that secure, user-friendly permissions systems do have to be somewhat restrictive in order to be effective (see Android, iOS, etc), and that ad blocking extensions will necessarily be impacted as a result.
- purple_ducks 7y ago
  Maybe make this step after discussing & listening to the other browser makers who support extensions. Maybe listen to the people who actually write the ad blockers. >"I think they've been trying to give the impression that they’re working with the developer community, when in fact they’re pretty entrenched in what they want to do," says Jeremy Tillman, president of the privacy and security-focused ad blocker Ghostery." https://www.wired.com/story/google-chrome-ad-blockers-extensions-api/ https://www.wired.com/story/google-chrome-ad-blockers-extens...
- michaelmrose 7y ago
  It doesn't lock down the ability of extensions to inspect and spy on all your traffic just block it. This in and of itself demonstrates the purpose. Also lets be real there are only a handful of adblocking extensions that have most of the market share run by legit players they could trivially vet and whitelist a small number of extensions that are allowed this privilege. It's not about security its clearly about ruining adblocking. A tiny blocklist that can only be updated with the extensions ensures that it is always trivial to work around blockers. One can simply ask which which version of the extension one has and load ads from a url/host created since.

Nicksil 7y ago

> We have no immediate plans to remove blocking webRequest > immediate We know exactly what this kind of talk means. Don't blow smoke up our ass, Mozilla, just give it to use straight: We'll have `blocking webRequest` for as long as Google allows it.

derefr 7y ago
Or, potentially, it's an equivocation because they want to give Google the appearance of maybe caving later (or at least the inability for Google to claim that they had the opposite appearance), while secretly hoping something changes such that they don't have to cave (and also, possibly, applying pressure below the radar to achieve that end.) Politics!
apazzolini 7y ago
I switched from Chrome to Firefox a couple of months ago when the Chrome adblocking changes were announced. I'll happily find something other than Firefox if it goes down the same route.
- Endy 7y ago
  Try out Pale Moon or Waterfox.
jerf 7y ago
I understand Google's motivation for nuking ad blockers, as well as their motivations for denying every which way that that is what they want to do under whatever security justifications they can bring up, even true ones. I don't see Mozilla's motivation to remove that at the moment. I mean, speaking for myself, I'd drop them both and follow a fork of the browser that lets uMatrix work, and that's not something I've considered very many times in the past 20 years. Control over what my browser actually connects to has become a top-3 feature concern for me. I was going to say "I suppose 'working' is technically more important to me", but then I mentally wargamed out whether I'd be willing to use a slightly nonfunctional browser to have uMatrix and noticed that I actually already put up with a slightly nonfunctional browser to use it, because uMatrix already breaks a number of sites until I do some whitelisting. Even if there's a security impact to extensions having too much access to the web request cycle, there's a security impact to them not having enough access to the web request, too.

ohazi 7y ago

I hope the ad blockers completely abandon Chrome when this change gets pushed through, rather than attempting to work around it. Google is using a slow-frog-boil approach to re-desensitize their users to ads, and it's working. The only thing that will work here is a big splash of cold water to the face. Maybe Chrome losing all of its ad-blockers overnight will finally start making a dent.

cptskippy 7y ago
Unfortunately the owners of the most popular adblocker have successfully created a revenue generating business out of adblocking and aren't about to abandon Chrome.
pvg 7y ago
Chrome launched without any support for extensions. chrome.webRequest didn't appear until the end of 2013.
hnaccy 7y ago
Outside of uBlock Origin the popular ad blockers are business (see pay for acceptable adds), there's no way they abandon chrome.

malicioususer11 7y ago

Bro if u still wana block javascript just use Ecosia. :)

feanaro 7y ago

In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. It's also quite disappointing how there is seemingly no one from Mozilla here, engaging with us on this topic. Instead, the only communication we get is one-sided corporate speak, with no real ability to respond. If anyone from Mozilla is reading, who do you think will spread Firefox among non-technical users if not the type of crowd that frequents HN?

chucksmash 7y ago
> In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. That's exactly what they've tried to do. Firefox exposes a `chrome` namespace object to extensions which is intended to be more or less API compatible with what Chrome provides and added the `browser` namespace object where improvements to the base compatibility are added (e.g. switching from callback based APIs to Promise based APIs). See the bit from the wiki below and the link to the browserext spec: > Mozilla has worked with Microsoft and Opera to implement browser extensions so that developers can write extensions that work across multiple browsers. The preliminary specification[1] matches what Google has implemented in Chrome so that extensions will work on Chrome, Edge, Opera and Firefox.[2] [1]: https://browserext.github.io/browserext/ https://browserext.github.io/browserext/ [2]: https://wiki.mozilla.org/WebExtensions/Spec https://wiki.mozilla.org/WebExtensions/Spec
- feanaro 7y ago
  Well, it's not enough to try, unfortunately. They have to persist and this talk about the importance of keeping compatibility with Chrome in the context of blocking webRequest removal is not very encouraging.

eh78ssxv2f 7y ago

It seems I'm in a minority here, but I was never comfortable installing any adblock extension because the existing request blocking API means that the extension would see all web traffic generated by me (including private URLs that are otherwise not known to anybody but me). I personally feel that now with manifest 3, I can actually install adblockers since the newer APIs do not share all my web traffic with the extensions. Can somebody explain why removing blocking API was overall a bad decision by Chrome?

kuzimoto 7y ago
> Extensions would still be able to use webRequest but only to observe requests, not to modify or block them. What's the point of an ad blocker if it doesn't block ads?
gorhill 7y ago
> the newer APIs do not share all my web traffic with the extensions The webRequest API can observe the URLs you visit without needing blocking permission. And so does the webNavigation API, the tabs API, history API, content scripts, possibly cookies API and whatever else does not come to my mind.
- SquareWheel 7y ago
  Shouldn't those be visible in the permissions prompt, prior to installing the extension?
amluto 7y ago
I’d like to see this done along the lines of how iOS handles keyboards: allow full web request reading and modification, but only in a sandbox that is per-origin.
zaarn 7y ago
uBlock is open source, you can verify that the extension in your browser is the same that is published in the github repository. The blocking API being removed is an issue because the replacement does not cover all use cases and severely limits what ad blockers can do to intercept filtered content. Google is obviously aiming to boil the frog slowly and make ad blockers a such terrible experience that Chrome users will not use them.

michaelmrose 7y ago

A humble proposal: A build of firefox that initially differs from Mozillas in that - it has a different default search engine selection that can be sold in the same way that Mozilla sells this same feature to google presently - no ads on new tab page - bundled with ublock origin The goal being to increase the value of selling the search engine selection while decreasing the value of mozillas in effect siphoning off some of the value of mozillas primary revenue stream. Such funds could be donated back to Mozilla or used to maintain a fork that doesn't ruin adblocking. Their choice.

phkahler 7y ago

I dont like the idea of extensions being able to inject data in either direction. On top of that, I'm not in favor of extensions doing anything to improve security - I want that in the base browser.

SirensOfTitan 7y ago

Mozilla really needs to get that if they compete with Google on Google’s terms, they’re rapidly heading toward extinction. Mozilla ought to be the browser for a private and usable web, but it seems they have occasional sneezes where you question what they’re doing (this, pocket in recent memory).

echelon 7y ago
I'm extremely worried that once Google disables ad blockers in Chrome, websites will wholesale block any and all non-Chrome browsers. Be it through user agent sniffing, feature detection, or fingerprinting, Firefox simply won't work anymore. The future of the web where Google is in complete control is straight up nightmare fuel. Microsoft in the early 2000s never scared me as much as the future we're headed into does. This won't be IE versus Netscape since websites are no longer served as plain old HTML. They're messy, thick, and impenetrable javascript blobs--not documents. We're not arguing about websites simply not rendering correctly in the less popular browser. This is a battle for the absolute control over information distribution. What do we do to prevent what's happening? Google already shot down XHTML, which was rich with semantics. That was a web written for documents and tools that could query those documents for meaning. Whatever Google has become needs to be dismantled. The ad company can't be the browser company and phone company. It's a perverse alignment of incentives.
- tomComb 7y ago
  > This won't be IE versus Netscape since... Well, also since Chrome if open source, cross platform, and standards compliant, and IE was none of those. And Google (unlike Apple) allows competing browsers, based on modified Chrome code, or entirely different engines. Soon we will have a good, cross platform Edge browser, thanks to Google, and a menu of browser options in Europe thanks to the EU. (Maybe other countries should push for the same.) But Chrome if no IE. And I believe that in Europe they will soon be

levani 7y ago

Really interesting what the new Edge is going to do in this regard...

rrix2 7y ago

perhaps a more optimistic take on "no immediate plans": there could eventually be an alternate standard for webrequest that addresses Chrome Devs' (perhaps legitimate) privacy concerns around most extensions being able to sniff, modify, and log all of your traffic on the entire web with a single, unobtrusive modal click. There is room to make the web platform more secure without stripping power from the user-agent, surely, or giving bad actors a trivial foothold. Frankly, my concerns around the webrequest API are numerous, the only reason IMO that Chrome isn't deprecating webrequest in Enterprise builds is for corporate spyware. At the very least a new webrequest spec that is more ergonomic and more safe than the webrequest API (without neuturing adblock) could show whether the emperor has no clothes, vis a vis "Google Adtech is directly influencing Chrome and web platform development" plots

kup0 7y ago

"no immediate plans to remove blocking webRequest" ... yikes