webRequest API alignment and support in MV3

[bradcush]

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 #148 as this is specific to MV3 and the future of webRequest 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.

• Performance (Google, Mozilla, and Apple have all communicated the impact of performance in supporting this API as it is heavy and would inherently mean the service worker is kept alive indefinitely. Mozilla has the intention to not have an arbitrary limit on service workers, Google is intent on having this limit which is currently around 5 minutes.)
• Non-blocking (Not supported in any MV3 implementation currently available, there is the short-term support of this API that seems to be agreed on by Google and Mozilla, but it's uncertain where Apple stands on this subject and overall what the future will look like as all are pushing for DNR to replace it but is incomplete)
• Blocking (Only Mozilla has voiced their intention to keep supporting blocking webRequest, Google has specifically said this wont be supported but there are use cases that aren't yet handled by Declarative Net Request)
• Declarative Net Request (DNR currently doesn't cover all of the use cases that are supported by 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

• Basic access authentication (To fill a credential in a form requiring basic access authentication we rely on "Provide credentials asynchronously" which uses blocking webRequest.onAuthRequired and which DNR does not replace.)
• Iframe Id extraction (Using non-blocking web requests is the only way we have found at the moment to get both the frame id and the parent frame id of a given frame. This is something we absolutely need for the page analysis, as it allows us to build a full structure of the page, iframes included. We may not need this anymore in the future, if this other proposal is implemented in Chrome and Safari. This has already been implemented in Firefox but I believe there were reservations on the Chrome side for unknown reasons. Because we don't have direct access to the request and subsequently the frame ids via DNR it's not an option for replacing.)

[ghostwords]

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.

[ghostwords]

There are more use cases in #110.

[chrmod]

use case for non-blocking webRequest #157