Web sites

Manifest V3: an open Web policy disguised as a sheep

When Google introduced Manifest V3 in 2019, web extension developers were alarmed at the amount of functionality that would be removed for the functionality they provide to users. In particular features such as blocking trackers and providing secure connections. This new iteration of Google Chrome’s Web Extensions interface still has flaws that could be fixed by thoughtful consensus from the Web Extensions developer community. However, two and more years of discussion and contention over Manifest V3 has finally revealed Google’s problematic power over how millions of people use the web. With more recent announcement With the official transition to Manifest V3 and the deprecation of Manifest V2 in 2023, many privacy-based web extensions will be diminished in their ability 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 delayed if the current proposal goes ahead. A move that has been touted as user-centric, actually takes away the user’s power to block unwanted tracking for their security and privacy needs.

Big influence, small challenge

First, a little history lesson. In 2015, Mozilla announced its decision to adopt the webRequest API, already used by Chrome, in an effort to synchronize the landscape for web extension developers. Fast forward to announcing Manifest V3 in 2019, Google put Mozilla in the position of choosing to split or sync with its Firefox browser. Splitting would mean taking a strong stand against Manifest V3 as an alternative and supporting web extension developers’ innovation in user privacy controls. Synchronization would mean following Google’s plan so as not to further divide the development of web extensions.

Mozilla has decided to support Manifest V2’s blocking webRequest API and MV3’s declarativeNetRequest API for the time being. A decision heavily influenced by Google’s desire to make MV3 the standard, support for 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 acknowledgment that MV3 does not meet the needs of web extension developers shows that MV3 is not yet ready for prime time. Still, there is a push for stable and reliable 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 advancements have been made in browser security and privacy, web extensions such as privacy badger, No scriptsand uBlock Origin have filled the void by providing the granular control that users want. One of the biggest changes described 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 webRequest API blocking, the declarativeNetRequest APIs includes low ceilings on the number of sites these extensions could cover. Another mandate is to move from Background Pages, a context that allows web extension developers to properly evaluate and debug, to a less powerful alternate context called Background Service Workers. This context was not originally built with web extension development in mind, which led to to his own conversation in many forums.

In short, Service Workers were intended for a sleep/wake cycle of delivering web assets to the user, for example, caching consistent images and information so that the user doesn’t don’t need to use a lot of resources when reconnecting to this website with a metered connection. Web extensions require persistent communication between the extension and the browser, often based on user interaction, such as the ability to detect and block ad trackers as they load on the web page in real time. This resulted in a significant list of issues that will need to be resolved to cover many valid use cases. These discussions, however, are taking place as web extension developers are urged to port to MV3 next year without a stable workflow available with outstanding issues such as the lack of a defined service worker context for web extensions, pending WebAssembly supportand lack of coherence and directness support from the Chrome Extensions team itself.

SandStorm Privacy

Since the announcement of Manifest V3, Google has announced several controversial “Privacy Sandbox” proposals for Chrome’s privacy mechanisms. The most important discussions on these proposals take place within the World Wide Web Consortium, or W3C. While technically “anyone” can listen to open meetings, only W3C members can submit formal specification documentation and hold leadership positions. Being a member has its own overhead and time commitment. This is something a large multinational can easily overcome, but it can be an obstacle for user-focused groups. Unless these power dynamics are directly addressed, a participant’s voice becomes stronger with market share.

Recently this year, after many Based on Google forum discussions around Manifest V3, a WebExtensions Community Group was formed in the W3C. Participation in community groups does not require W3C membership, but they do not produce standards. Chaired by employees from Google and Apple, this group says that “by specifying the APIs, features, and permissions of WebExtensions, we can make it even easier for extension developers to improve the WebExtension experience. end user, while directing them to APIs that improve performance and prevent abuse.”

But this movement towards more democracy would have been more powerful and more effective before Google’s unilateral push to impose Manifest V3. This story is unfortunately similar to what happened with Google AMP technology: more democratic discussions and open governance were only proposed after AMP had become ubiquitous.

With the planned deprecation of the Manifest V2 extensions, the decision has already been made. The rest of the web extensions community is forced to conform, step aside, or leave a vast ecosystem of browser extensions that doesn’t include Chrome. And it’s harder than it looks: Chromium, the open-source Chromium-based browser engine, powers Microsoft Edge, Opera, Vivaldi, and Brave. Statements were made by Vivaldi, Brave and Opera over MV3 and their plans to preserve MV2’s ad blockers and privacy-preserving features, but the ripple effects are clear when Chrome makes a major change.

What does a better MV3 look like?

Some very valid concerns and requests have been raised with the W3C Web Extensions Community Group that would help propel the web extensions field to a better place.

  1. Make the declarativeNetRequest API optional in Chrome, as it is now. The API provides a path for extensions that have more static and simplistic functionality without the need to implement more powerful APIs. Extensions that use the webRequest blocking API, with its added power, may be subject to further scrutiny during submission review.
  2. In an effort to assuage the technical issues surrounding Background Service Workers, Mozilla has proposed to the W3C group an alternative to Service Workers for web extensions, dubbed “Limited Event Pages”. Where this approach restores much of the standard website APIs and support lost with background service workers. Safari Express support, but Chrome expressed lack of support with reasons pending but not explicitly stated at the time of this post.
  3. No other introduction of regressions in important features of MV2. For example, being able to inject scripts before the page loads. This is broken with pending edits in MV3.

While the changes between Web Extensions API changes and proposed privacy mechanisms can be viewed as two separate efforts, it speaks to the expansive power of how a company can impact the ecosystem. from the web; both when they do great things and when they make bad decisions. The question that needs to be asked is who is in charge of enforcing what is fair: the standardization bodies that engage in big business proposals or the businesses themselves? Second, who has more power if one constituency says “no” and another says “yes”? Community partners, advocates and small businesses are allowed to say no and not work with companies that frequently walk into the room with troubling proposals, but then that company can claim silence means consensus when deciding to move forward with a plan. Similar dynamics have already occurred when the The W3C struggles with Do Not Track (DNT) where proponents of weaker privacy mechanisms pretended to worry about privacy and user choice. So in this case, big companies like Google can make harmful or largely helpful decisions with little incentive to say no to themselves. In the case of MV3, they gave space and time to discuss issues with the web extensions community. This is the minimum standard for making such a big change, so praising a powerful entity for making room for many more voices would only add to the feeling that it should be standard in open web politics.

No matter how well-intentioned a proposal may be, the reality is that the experiences of millions of people on the Internet are often left to the ethics of the few in corporations and standards bodies.

More information