Open bradcush opened 2 years ago
As I recently wrote elsewhere, the high-level problem with exclusively providing a declarative API is that
Advertising technology evolves rapidly, and privacy extension developers need to be able to change their approaches to it over time. To make matters worse, extension developers can't depend on Google browser engineers to react in any timely manner or at all. Google abandoned extension API development for years before Manifest V3. For example, while extensions have had the ability to “uncloak” CNAME domains in Firefox for over three years now, Chrome still lacks support for CNAME uncloaking. ...
... Making both [declarative and dynamic (webRequest) APIs] available can still fulfill Google’s stated goals of making extensions safer and more performant. Google could use Chrome Web Store to guide extensions that don’t actually need blocking webRequest towards the declarative API. Google could also provide extension developer tools that would automatically analyze your extension for potential improvements, like the audit tools provided to promote best practices to website developers. In addition, extensions that use webRequest should get flagged for additional review; this should be clearly communicated to extension developers.
While the above complaint is Google specific, it mostly applies to all browser vendors. It's a big mistake to gate innovation for crucial extensions functionality that needs to adapt to frequent developments in advertising and tracking techniques.
There are more use cases in #110.
use case for non-blocking webRequest https://github.com/w3c/webextensions/issues/157
The webRequest API future is uncertain and currently not aligned among browser vendors. It's been communicated that the non-blocking
webRequest
API would be supported for MV3 by Chrome as well as Firefox for MV3. Chrome currently has a bug ticket open related to fixing this issue, Firefox is yet to have an MV3 implementation, and Safari surfaces an error in Safari Technology Preview on extension install, "An extension with a non-persistent background page cannot listen to webRequest events". I believe this issue is separate from https://github.com/w3c/webextensions/issues/148 as this is specific to MV3 and the future ofwebRequest
and DNR as a replacement.I've listed specific points with use cases for some exposing either misalignment or lacking support which I'm hoping we can resolve and have clear communication about to clarify the current state and planned future of this API for MV3 to fit developers needs.
webRequest
, Google has specifically said this wont be supported but there are use cases that aren't yet handled by Declarative Net Request)webRequest
, both blocking and non-blocking. There are other limitations associated with DNR, an example being number of rulesets that can be declared.)Example of unsolved use cases
webRequest.onAuthRequired
and which DNR does not replace.)