Chrome team is actively working on major changes proposed for their extension platform: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#
Should we expect same updates for Firefox?
Hey @avyrvich. We are watching Chrome’s proposals for manifest v3. We do anticipate that we will adopt some of their proposals to maintain compatibility, which we believe will benefit Firefox developers and users. However, we are not committing to implement all aspects of manifest v3, and in fact, we already depart from manifest v2 in several areas where we think it makes sense.
If we do decide to propose changes to our extension framework, we will announce them on the Add-ons Blog.
4 Likes
More to the point:
As they currently stand, Google’s proposals for manifest v3 would utterly cripple ad-blocking and other content-blocking extensions. It’s becoming increasingly clear that this is Google’s intended goal, and their final manifest v3 will not meaningfully deviate from that course. If/when Google finalizes a manifest v3 that cripples ad-blocking/content-blocking extensions, will Mozilla follow suit? Can we get an official commitment that Firefox will be retaining the v2 API functions that robust ad-blocking/content-blocking depend upon? (Mostly the fully-featured, blocking version of webRequest, but also several other things.)
1 Like
Like I mentioned earlier, we’re still monitoring Chrome’s manifest v3 proposals. Their recent post indicates that they are still iterating on some of the ideas they would like to implement, including changes that would impact content-blockers.
Regardless of what happens with Chrome’s manifest v3 proposals, we want to ensure that ad-blockers and other similarly powerful extensions that contribute to user safety and privacy remain part of Mozilla’s add-ons ecosystem while also making sure that users are not being exposed to extreme risks via malicious use of powerful APIs.
I find this reply disappointing, to say the least.
Google’s recent post can best be described as “fiddling around the edges” without addressing any of the fundamental problems with the manifest v3 proposal. It’s not a serious attempt to address those problems, and that lack of seriousness is one of the things that has led many people, myself included, to be deeply suspicious that Google’s stated rationales are entirely pretextual; that crippling ad-blockers is an intended goal for manifest v3. Your apparent willingness to take Google’s transparent window dressing at face value is troubling.
The notion that the user must be protected from extensions misusing powerful APIs is fundamentally misguided. First and foremost, it’s a betrayal of the principle of USER CHOICE. When I, the user, choose to install, say, uBlock Origin, I’m making a free and knowing choice about what functionality I care most about and about whom I trust. I am choosing to trust Raymond Hill. I trust him far more than the people drafting manifest v3 at Google, and infinitely more than the people behind the deluge of ads and trackers that will surge past the neutered version of webRequest that Google is proposing. And, because I’ve chosen to trust him, I want him to have an API powerful enough to do what he needs to do to serve my interests as reflected in the free choice I have made. Manifest v3 – as originally proposed, as currently proposed, and in any form resembling what’s currently proposed – would take that choice away from the user. Second, neutering the API, thereby crippling legitimate extensions, is not a principled solution to the problem of rogue extensions. The principled solution to the problem of rogue extensions is to do a better job of vetting extensions before admitting them (or updates to them) to the add-ons shop. (E.g., extra vetting for popular extensions, extra vetting for extensions that use powerful APIs, going fully open source as a requirement for using powerful APIs, vetting of updates, requiring an extension that changes ownership/authorship to restart the vetting process from zero.) The bottom line is this: Respect user choice. Users should be free to choose the pair {powerful content blocking, risk of trusting extension author} over crippled content-blocking if that’s their free and knowing decision.
It’s no doubt clear that I don’t believe this is really about rogue extensions. But I’m willing to pretend for a moment that it is. If that’s really, truly the concern here, then I propose this: (a) Retain the powerful v2 API functions that ad-blocking/content-blocking extensions depend on. (b) Implement Google’s neutered v3 functions in parallel with the v2 functions. (c ) Any time a user attempts to install or update an extension that uses the v2 functions, present her or him with the biggest, scariest pop-up warning in the history of pop-up warnings. Have big, bold, underlined, flashing text explaining that the extension is requesting unusually extensive powers that would enable it to totally compromise the user’s security and privacy, and that the user should only continue of they completely trust the extension. Maybe even suggest they stop and do some research before making the trust decision. Make them type “I understand the risk” before enabling the OK button. There. The user retains freedom of choice, while being pointedly informed of the gravity of that choice. User choice, and also user responsibility – it’s not Mozilla’s fault if we’re dumb enough to trust a dodgy extension after that warning. At the same time, the obnoxious pop-up will drive all legitimate extensions that don’t need the more powerful API over to the neutered v3 functions, leaving behind a smaller pool of targets for extra vetting.
2 Likes
Amen to the above post! Excellent suggestions as well. 
Firefox is all about having the choice to improve one’s user experience with powerful add-ons, contrary to other browsers which seem to have different goals. I also use uBlock Origin and uMatrix with GREAT satisfaction. These add-ons increase my safety and privacy on the web and have enough credibility for me to give them the necessary API permissions. In the same league: NoScript, Privacy Badger etc.
But from @caitlin’s latest post I am confident that Firefox will divert from Chrome’s v3 manifest when necessary to preserve the abilities of our beloved add-ons, as it has done in the past. Preserving the editing/blocking features of the webrequest API seems crucial to me (not only for adblockers but for other powerful add-ons as well), with a decent warning if needed.
2 Likes
896897 - Extensions: Implement Manifest V3 - chromium - Monorail (2018-11-17) 
Manifest V3: Web Request Changes - Google Groups (2019-01-23) 2019-05-25 – the recent response to feedback from Extensions Developer Advocate Simeon Vincent.
Google’s response raises a few eyebrows. This Forbes article, for example:
Rewind a little. Last month’s blog post Add-on Policy and Process Updates (highlights) was reassuring. I began watching the Blocklist Policy Requests component in Bugzilla@Mozilla … seeing https://blocked.cdn.mozilla.net/ in a new light … processes surrounding the numerous seriously troublesome add-ons.
Fast forward to Manifest V3, Google’s recent response to feedback. There is, in places, an expectation that Mozilla will stray from its principles (“85% of its funding from Google” and so on); that Mozilla will follow Google’s approach. Whilst I don’t share this pessimism, I do think that now will be a good time for Mozilla to draft/publish a policy statement, to address the concerns of end users and developers re: add-ons that are simply powerful; not troublesome.
A blog post by @jorgev, maybe?
TIA
Related
Feedback from the ad blocking community on the proposed changes to webRequest and declarativeNetRequest - Google Docs (2019-02-20)
Document contributors / supporters
(in alphabetical order)
- Ad Remover
- Adblock
- Adblock Plus
- AdGuard
- Cliqz / Ghostery
- Fanboy (Easylist author)
- MalwareBytes
- MonztA (Easylist author)
2 Likes
BTW, there was some discussion (and my point of view) about this before:
TL;DR: Sure, support the API for compatibility (possibly with higher limits), but don’t remove the real better blocking capabilities.
2 Likes
Note that the specific issue of deprecating the content blocking capabilities of the webRequest API is not a privacy-related issue, contrary to what some Google employees have claimed.
It’s true that the declarativeWebRequest API provides better privacy over the webRequest API, but the privacy risk of the webRequest API is not going away. They have explicitly chosen not to deprecate the observational capabilities of the webRequest API, which have exactly the same privacy risk as the content blocking capabilities. So clearly the deprecation of the content blocking capabilities provides no privacy improvement.
In the manifest document they actually claim the change is being done for performance – the blocking nature of the content blocking parts of the webRequest API leads to performance degradation when loading pages. However, here you can see a response from the Ghostery team which shows that degradation is milliseconds at worst: https://whotracks.me/blog/adblockers_performance_study.html
1 Like
As a developer, I appreciate Mozilla’s commitment to the webRequest API.
A dream I had for a number of years was to create an NSFW image filter that ran fully client side using machine learning. I have now created an extension that does just that. This was due to the Mozilla’s addition of the powerful filterResponseData in FF57; I don’t think a Chrome port will ever be possible. This seems to be exactly the type of usage Chrome would like to block: deeply integrated and relatively slow due to its use case. But it matters to me!
I can also tell that Mozilla is supportive through the addition of smaller features such as the recently announced private browsing filtering. The attention to detail makes my day.
To me these are heart-warming indicators that Mozilla has a different goal in mind. I think the most compelling statement is not one made against Manifest V3, but rather a forward-looking roadmap around webRequest. Has there been any official sharing of the current roadmap around webRequest that someone could point me to? (And of course, I might just be interested in any new features coming up. 
)
1 Like
Hi, I recently wrote an extension that inserts a cookie in a cross-origin request using the webRequest API. The extension helps users view moderator actions on content from quarantined groups on reddit, thus bringing back some transparency that was lost when the groups were given that classification. The code for that is here.
From what I’ve read of Chrome’s v3 proposal, including the changes made to accommodate ad blockers, inserting cookies will be disallowed. It would be great if this remains possible in future Firefox versions.
An actual announcement was released today, and there’s a new discussion threat:
2 Likes
Did folks here see that Safari announced support for the WebExtensions API a few days ago at WWDC (skip to 1:15)? Their implementation is currently missing a few javascript APIs and it doesn’t work on iOS, but if they do add support for iOS in the future it could be a whole new segment. Apple is soliciting feedback on their implementation of the WebExtensions API, so if you have an opinion, it may be worth sending feedback there (developer account required) or advocating for a more complete implementation in some other forum.
I mention this because people here seem interested in standardized extension APIs, and I noticed Apple did not implement webRequest blocking which was the major change Google proposed with manifest v3.
1 Like