In spite of the overwhelmingly negative feedback on the Manifest V3 extension system, Google is standing firm on Chrome’s ad-blocking changes. Last month, the company announced that it has begun testing its upcoming extension manifest V3 in the latest Chrome Canary build. As of October 31st, the Manifest V3 developer preview has been made available in the Chrome 80 Canary build.
Manifest v3 has become a bone of contention for many ad-block companies. This is because Google developers have introduced an alternative to the webRequest API (earlier used for ad-blocking) named the declarativeRequest API, which limits the blocking version of the webRequest API. Chrome developers listed two reasons behind this new update, one was performance (although that was nullified in study by WhoTracks.me) and the other was a better privacy guarantee to users. Chrome currently imposes a limit of 30,000 rules. However, most popular ad-blocking rules lists use almost 75,000 rules. Although Google claimed that they’re looking to increase this number, they didn’t assure it.
Many ad blocker maintainers and developers felt that the introduction of the declarativeNetRequest API can lead to the crippling of many already existing ad blockers.
The lead developer of popular ad blocker uBlock Origin, which relies on the original functionality of the webRequest API, commented, “This breaks uBlock Origin and uMatrix, [which] are incompatible with the basic matching algorithm picked, ostensibly designed to enforce EasyList-like filter lists,” he explained in an email to The Register. “A blocking webRequest API allows open-ended content blocker designs, not restricted to a specific design and limits dictated by the same company which states that content blockers are a threat to its business.”
Many users also mentioned that Chrome is using its dominance in the browser market to dictate what type of extensions are developed and used. A user commented, “As Chrome is a dominant platform, our work is prevented from reaching users if it does not align with the business goals of Google, and extensions that users want on their devices are effectively censored out of existence.”
Others expressed that it is better to avoid all the drama by simply switching to some other browser, mainly Firefox. “Or you could cease contributing to the Blink monopoly on the web and join us of Firefox. Microsoft is no longer challenging Google in this space,” a user added.
As a part of Chrome 80 Canary build, the Chrome team is continuing to iterate on the declarativeNetRequest API and its capabilities. As a part of this release, background service workers (killing background page and scripts) are now available for testing in manifest version 2 and 3 extensions in Canary. Remotely-hosted code restrictions and host permissions changes are currently a work in progress. They are also working on combining page_action and browser_action APIs to single-action API.
The manifest v3 proposed changes are not finalized yet, and several features are currently works in progress. The MV3 stable release is expected in 2020. As part of this launch, Google has created a Migrating to Manifest V3 guide that developers can use to migrate their existing extensions. They have also built guide specifically for migrating from background pages to service workers.
Is it time to ditch Chrome? Ad blocking extensions will now only be for enterprise users
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…