Manifest V3: Open Web Politics in Sheep's Clothing

When Google introduced Manifest V3 in 2019, web extension developers were alarmed at the amount of functionality that would be taken away for features they provide users. Especially features like blocking trackers and providing secure connections. This new iteration of Google Chrome’s web extensions interface still has flaws that might be addressed through thoughtful consensus of the web extension developer community. However, two years and counting of discussion and conflict around Manifest V3 have ultimately exposed the problematic power Google holds over how millions of people experience the web. With the more recent announcement of the official transition to Manifest V3 and the deprecation of Manifest V2 in 2023, many privacy based web extensions will be mitigated in how they are able to protect users.

The security and privacy claims that Google has made about web extensions may or may not be addressed with Manifest V3. But the fact remains that the extensions that users have relied on for privacy will be heavily stunted if the current proposal moves forward. A move that was presented as user-focused, actually takes away the user’s power to block unwanted tracking for their security and privacy needs.

Large Influence, Little Challenge

First, a short history lesson. In 2015, Mozilla announced its move to adopt the webRequest API, already used by Chrome, in an effort to synchronize the landscape for web extension developers. Fast forwarding to the Manifest V3 announcement in 2019, Google put Mozilla in the position of choosing to split or sync with their Firefox browser. Splitting would mean taking a strong stand against Manifest V3 as an alternative and supporting web extensions developers’ innovation in user privacy controls. Syncing would mean going along with Google’s plan for the sake of not splitting up web extension development any further.

Mozilla has decided to support Manifest V2’s blocking webRequest API and MV3’s declarativeNetRequest API for now. A move that is very much shaped by Google’s push to make MV3 the standard, supporting both APIs is only half the battle. MV3 dictates an ecosystem change that limits MV2 extensions and would likely force MV2 based extensions to conform to MV3 in the near future. Mozilla’s acknowledgement that MV3 doesn’t meet web extension developers’ needs shows that MV3 is not yet ready for prime time. Yet, there is pressure to get stable, trusted extensions to allocate resources to port their extensions to more limited versions of themselves with a less stable API.

Manifest V3 Technical Issues

Even though strides have been made in browser security and privacy, web extensions like Privacy Badger, NoScript, and uBlock Origin have filled the gap of providing the granular control users want. One of the most significant changes outlined in Manifest V3 is the removal of blocking webRequest API and the flexibility it gave developers to programmatically handle network requests on behalf of the user. Queued to replace blocking webRequest API, the declarativeNetRequest API includes low caps on how many sites these extensions could cover. Another mandate is moving from Background Pages, a context that allows web extension developers to properly assess and debug, to an alternative, less powerful context called Background Service Workers. This context wasn’t originally built with web extension development in mind, which has led to its own conversation in many forums.

In short, Service Workers were meant for a sleep/wake cycle of web asset-to-user delivery—for example, caching consistent images and information so the user won’t need to use a lot of resources when reconnecting to that website again with a limited connection. Web extensions need persistent communication between the extension and the browser, often