Google still plans to cripple ad-blocking in Chrome, but enterprises will be exempt
Google has clarified proposed changes to the Chrome browser that some developers fear will cripple ad blockers, revealing there will be an exemption for enterprise users.
Back in January, Google angered developers of ad blocker Chrome extensions over planned changes to Chrome's webRequest API that could harm existing extensions. The proposal, outlined in a draft of Google's Manifest V3 document about the future of Chrome extensions, potentially affects ad blockers, security extensions, parental control enforcement, and various privacy-enhancing services.
Google planned to change the webRequest API in a way that would stop existing permitted behavior that allowed ad-blocker extensions to "intercept network requests to modify, redirect, or block" API requests. Instead, the webRequest API would be reduced to an "observational" role, making it a tool for passive, rather than active, interaction by extensions.
SEE: How to build a successful developer career (free PDF)
In a message on a Google Groups page about Manifest V3, Google staffer Simeon Vincent explained the motivation for the deprecation and mentioned an exception for enterprise instances of Chrome.
"Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments)," wrote Vincent.
"Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime."
Vincent's further descriptions illustrate the Manifest V3 document is still subject to change.
"Chrome is not deprecating <all_urls> in Manifest V3, but we are changing how it works. Our primary motivation here is to give end-users more control over where extensions can inject themselves. The current extension installation flow allows developers to declare that they require access to a given set of hosts and the user must choose whether to grant all required permissions or cancel the installation. We are planning to modify the install flow so the user will be able to choose whether or not they want to grant the extension the ambient host permissions it requested. We're still iterating on the updated UI and will share additional details once this lands in Canary [the experimental build of Chrome where Google tests new features]."
techrepublic cheat sheet
Raymond Hill, the developer of uBlock Origin and uMatrix who raised concerns about the changes in Manifest V3, still has some objections to the revised proposal, in particular with Google's claim that it can't provide a definitive answer on the status of the webRequest API until it runs further performance tests.
"The blocking ability of the webRequest API is still deprecated, and Google Chrome's limited matching algorithm will be the only one possible, and with limits dictated by Google employees," wrote Hill.
"It's annoying that they keep saying "the webRequest API is not deprecated" as if developers have been worried about this -- and as if they want to drown the real issue in a fabricated one nobody made."
In his view, sluggish web page loading is due to Chrome "bloat" rather than the performance of the API itself for "well crafted extensions".
Hill also argues that to improve performance, Google should just follow Mozilla's approach in its Firefox browser.
"If performance concerns due to the blocking nature of the webRequest API was their real motive, they would just adopt Firefox's approach and give the ability to return a Promise on just the three methods which can be used in a blocking manner."