Google has been working on an updated version of the Chrome extension API, named ‘Manifest V3,’ for over two years at this point. After extension developers rallied against some of the proposed changes, Google went back to the drawing board, and now the final documentation for Manifest V3 is available to developers.
The first key change in Manifest V3 is that the webRequest API, used by every content blocking extension, has been replaced with the declarativeNetRequest API. Instead of Chrome passing every network request to an extension for them to be filtered, which isn’t the safest option for privacy/security, the new API allows extensions to provide Chrome with a filter list that Chrome itself parses.
Many developers initially spoke out against the declarativeNetRequest API, saying it was too limited, but Google has been improving it. It now supports more types of wildcard operators, similar to how most content blockers formatted their own lists. However, Google is still keeping a relatively-low cap on the number of rules an extension can have. Extensions can only apply a maximum of 30,000 rules, which sounds like a high number, but EasyList (one of the more common blocklists) alone has over 60,000 rules. Google told 9to5Google that the limit will be raised to 300,000 in Chrome 89, which is better, but still not enough to have more than a few common blocklists activated at once.
Extension developers are still split on the changes. A tech lead for AdBlock Plus said in a statement, “We’ve been very pleased with the close collaboration established between Google’s Chrome Extensions Team and our own engineering team to ensure that ad-blocking extensions will still be available after Manifest V3 takes effect.” However, AdBlock Plus has so many exemptions that it likely doesn’t come close to reaching the upper limit of blocking rules. Raymond Hill, the developer behind uBlock Origin, previously said “it’s really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs.”
Most of the other changes will likely go unnoticed by non-developers. Remotely-hosted code is no longer allowed, so extensions can only run code that is included within its package (allowing Google to evaluate all code during the review process). This was already required by Firefox and others, but now it will become the standard across all Chromium-based browsers. Google is also replacing background pages with service workers and updating some APIs to function as Promises, making extension development more similar to modern web development.
The new Manifest V3 API is already shipping as part of Chrome Beta 88, and Google will begin accepting V3 extensions once Chrome 88 reaches the stable branch in mid-January. There’s not yet a shutdown date for V2 extensions, but Google says “developers can expect the migration period to last at least a year from when Manifest V3 lands in the stable channel.”
Microsoft has already stated that Microsoft Edge will fully support the Manifest V3 standard, including the new limits on content blockers. “The decision to embrace Manifest V3 changes,” the company said in a blog post, “is based on our dedication to enhancing privacy, security & performance for the benefit of our end-users as well as to allow developers to extend & provide rich experiences in Microsoft Edge.” Opera, Vivaldi, and some other Chromium-based browsers previously said they would continue supporting the older webRequest API that all current content blockers use. Firefox has its own extension API implementation, and as of 2019, has “no immediate plans to remove blocking webRequest.”