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 based on user interaction, like being able to detect and block ad trackers as they load onto the web page in real time. This has resulted in a significant list of issues that will have to be addressed to cover many valid use cases. These discussions, however, are happening as web extension developers are being asked to port to MV3 in the next year without a stable workflow available with pending issues such as no defined service worker context for web extensions, pending WebAssembly support, and lack of consistent and direct support from the Chrome extensions team itself.
Privacy SandStorm
Since the announcement of Manifest V3, Google has announced several controversial “Privacy Sandbox” proposals for privacy mechanisms for Chrome. The highest-stakes discussions about these proposals are in the World Wide Web Consortium, or W3C. While technically “anyone” can listen into the open meetings, only W3C members can propose formal documentation on specifications and have leadership positions. Being a member has its own overhead of fees and time commitment. This is something a large multinational corporation can easily overcome, but it can be a barrier to user-focused groups. Unless these power dynamics are directly addressed, a participant’s voice gets louder with market share.
Recently this year, after the many Google forum-based discussions around Manifest V3, a WebExtensions Community Group has been formed in the W3C. Community group participation does not require W3C membership, but they do not produce standards. Chaired by employees from Google and Apple, this group states that by “specifying the APIs, functionality, and permissions of WebExtensions, we can make it even easier for extension developers to enhance end user experience, while moving them towards APIs that improve performance and prevent abuse.”
But this move for greater democracy would have been more powerful and effective before Google’s unilateral push to impose Manifest V3. This story is disappointingly similar to what occurred with Google’s AMP technology: more democratic discussions and open governance were offered only after AMP had become ubiquitous.
With the planned deprecation of Manifest V2 extensions, the decision has already been made. The rest of the web extensions community are forced to comply, deviate from, or leave a large browser extension ecosystem that doesn’t include Chrome. And that’s harder than it may sound: Chromium, the open-source browser engine based on Chrome, is the basis for Microsoft Edge, Opera, Vivaldi, and Brave. Statements have been made by Vivaldi, Brave, and Opera on MV3 and their plans to preserve ad-blockers and privacy preserving features of MV2, yet the ripple effects are clear when Chrome makes a major change.
What Does A Better MV3 Look Like?
Some very valid concerns and asks have been raised with the W3C Web Extensions Community Group that would help to propel the web extensions realm back to a better place.
- Make the declarativeNetRequest API optional in Chrome, as it is currently. The API provides a path for extensions that have more static and simplistic features without needing to implement more powerful APIs. Extensions that use the blocking webRequest API, with its added power can be given extra scrutiny upon submission review.
- In an effort to sooth the technical issues around Background Service Workers, Mozilla proposed in the W3C Group an alternative to Service Workers for web extensions, dubbed “Limited Event Pages”. Where this approach restores a lot of the standard website APIs and support lost with Background Service Workers. Safari expressed support, but Chrome has expressed lack of support with reasons pending but not explicitly stated at the time of this post.
- No further introduction of regressions in important functionality that MV2 has. For example, being able to inject scripts before page load. This is broken with pending amendments in MV3.
Even though one may see the moves between web extensions API changes and privacy mechanism proposals as two separate endeavors, it speaks to the expansive power of how one company can impact the ecosystem of the web; both when they do great things, and when they make bad decisions. The question that must be asked is who has the burden of enforcing what is fair: the standards organizations that engage with large company proposals or the companies themselves? Secondly, who has the most power if one constituency says “no” and another says “yes”? Community partners, advocates, and smaller companies are permitted to say no and not work with companies who enter the room frequently with worrying proposals, but then that company can claim that silence means consensus when they decide to go forward with a plan. Similar dynamics have occurred before when the W3C grappled with Do Not Track (DNT) where proponents of weaker privacy mechanisms feigned concern over user privacy and choice. So in this case, large companies like Google can make nefarious or widely useful decisions without much incentive to say no to themselves. In the case of MV3, they gave room and time to discuss issues with the web extensions community. That is the bare minimum standard for making such a big change, so to congratulate a powerful entity for making space for many other voices would only add to the sentiment that this should be the norm in open web politics.
No matter how well-meaning a proposal can be, the reality is millions of people’s experiences on the internet are often left up to the ethics of a few in companies and standards organizations.
