MV3 Blog Part 2

[Giorgio Maone]

"Fixing" Manifest V3

In the previous installment of this series, What is Manifest v3 and how it affects JShelter, we've stressed the limitations of the new WebExtensions APIs, along with the challenges and the threats it poses to privacy and security extensions such as JShelter. 

As part of our strategy to mitigate these problems, we mentioned "actively participating in the ongoing browser extensions API design work of the Web Extensions Community Group, in order to steer the MV3 specification in the most favorable direction for security and privacy use cases".

Here we want to provide some updates about these design participation activities, and pointers to follow their progress.

Specifically, we prompted the W3C's WECG to resume the discussion of the two main issues "blocking" JShelter, which we had originally opened more than 2 years ago:

1. Scripting API minimum requirements to enable the reliable and pervasive script injection needed to enforce JShelter's _javascript_ Shield wrappers
   
2. LAN-aware Declarative Net Request filters, required for the Network Boundary Shield to operate in Chromium-derived browsers and Safari on MV3
   

Public notes of the meetings are available.

This time the response has been unanimously positive on #1, and generally positive on #2, with Google expressing a neutral position motivated by Chromium developers unsure if the Network Boundary Shield use case would be better served by a built-in browser UI around their (not ready for prime time yet and planned for quite a long time now) Private Network Access. 

The discussion continues on the specific followup proposals we've created afterwards,  covering all our _javascript_ Shield requirements:

1. Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection)
2. Proposal: RegisteredContentScript.workers property to inject WorkerScope(s)
3. Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection

Furthermore https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 (MAIN world support in Firefox) would greatly simplify our cross-browser story, allowing us to drop a complex and fragile compatibility layer working around Firefox's XRay vision approach to "safe" DOM / _javascript_ environment manipulation.

Browser vendors now signalling adequate understanding of our requirements and their will to implement our API proposals or equivalent alternatives before MV2 sunset, can finally induce some cautious optimism about a reasonably better MV3 for privacy and security extensions.

-- 
Giorgio Maone
https://maone.net