This week, Google revealed exactly how it plans to phase out Manifest V2, which defines the capabilities and limitations for extensions in Chrome. The developers also shared their plans to bring the infamous Manifest V3 to full functionality, which became available in the beta version of Chrome 88.
Background
Let me remind you that for the first time they started talking about Manifest V3 back in 2018. Then the developers of Google announced that they intend to limit the work of the webRequest API, instead of which content blockers and other extensions will use declarativeNetRequest. Of course, these improvements have been reported to improve security and performance, as well as give users more control over what extensions do and which sites they interact with.
The problem was that extension developers quickly discovered that switching to a different API that was very different from webRequest and in many ways inferior to it, in essence, would be the “death” of their products. In particular, this concerned ad blockers, antiviruses, parental control solutions and various products that increase privacy.
The fact is that the webRequest API allows extensions not only to block advertising content on pages, but also to intercept network requests in order to be able to block, modify and redirect them. But, according to Google developers, this affected the page loading speed too much, so it was planned that in the future the webRequest API would only be allowed to read requests, but not interfere.
In turn, declarativeNetRequest allows Chrome (but not the extension itself) to decide how to handle network requests, while eliminating the bottleneck and increasing security. Google developers were confident that using the declarativeNetRequest API would be better for user privacy, since extensions would no longer be able to read network requests made on behalf of the user.
As mentioned above, Google’s design has been heavily criticized. One of the first to express his point of view was the developer of the popular blockers uBlock Origin and uMatrix Raymond Hill. For example, he explained that declarativeNetRequest offers developers a single implementation of a filter engine, and besides, it is limited to only 30,000 filters, which could not stand comparison even with EasyList .
Hill warned that abandoning webRequest would be a “death” for his products, and expressed concern that switching to the declarativeNetRequest API could adversely affect other solutions, a view supported by many other developers.
As a result, under pressure from the public, Google developers were forced to abandon some updates from the Manifest V3, and then revised their plans even more, canceling a number of changes.
Since then, Manifest V3 changes have already started rolling out to Chrome, and the frustration has gradually subsided, although some ad blocker developers seem to have simply resigned themselves to the fact that their products will not be able to reliably block ads once the changes reach stable versions of Chrome.
Manifest V3 Implementation Plans
As David Li, Product Manager for Chrome Extensions and the Chrome Web Store, now writes :
“Developed over the years, Manifest V3 is more secure and performant than its predecessor, and offers better privacy. This is an evolution of the plug-in platform to accommodate the changing web landscape and the future of browser plug-ins. ”
Lee says Google is phasing out Manifest V2, with two key dates already set in the process:
- January 17, 2022 : New extensions with Manifest V2 support will no longer be accepted in the Chrome Web Store. Developers will still be able to update existing Manifest V2 extensions.
- January 2023 : Chrome browser will stop using Manifest V2 extensions. Developers will no longer be able to update existing Manifest V2 extensions.
A more detailed timetable for the rejection of the second version manifesto can be seen here .
Until January 2023, Google developers promise to continue to refine the new manifest in order to take into account all the wishes and criticism of the extension developers, as well as introduce all the desired functions into it. In particular, Google says it has already added additional mechanisms to the new Scripting API and extended the Declarative Net Request API to support multiple static rulesets, session rules, and tab ID-based filtering.
“In the coming months, we will launch support for dynamically configurable content scripts and in-memory storage, among other new features. These changes are based on community feedback, and we will continue to build more powerful extension APIs as developers share more information with us about migration issues and their business needs, ”says Lee.
The journalists Bleeping Computer asked Lee whether considered the last wishes of the developers, who explained that Google’s innovations actually ruin their products. Lee responded that “changes are in the design process,” and stressed that the company is considering feedback from developers and users.