Google relents slightly on blocking ad-blockers for enterprise Chrome users
Google relents slightly in ad-blocker crackdown – for paid-up enterprise Chrome users, everyone else not so much

Google Chrome users will continue to have access to the full content blocking power of the webRequest API in their browser extensions, but only if they're paying enterprise customers.
Everyone else will have to settle for extensions that use the neutered declarativeNetRequest API, which is being developed as part of a pending change to the way Chrome Extensions work. And chances are Chrome users will have fewer extensions to choose from because some developers won't be able to rework their extensions so they function under the new regime, or won't want to do so.

  Behind the scenes

Manifest files provide a way for developers to declare that their apps will use specific resources, such as files and APIs. Google has revised its Chrome extension manifest specification over the years to accommodate changes in Chrome features and capabilities. Manifest v1 was phased out in January 2014. Manifest v2, the current version, is headed for a similar fate, once Manifest v3 gels later this year.
The v3 draft, announced last October and still in flux, alarmed developers of Chrome extensions earlier this year when people began to understand that Google's plan to deprecate the webRequest API and other proposed changes would break content and ad blockers, privacy extensions, and other browser add-ons that rely on intercepting content before it gets displayed in the browser.
In response to concerns raised last month by the developers of the EFF's Privacy Badger extension, Simeon Vincent, developer advocate for Chrome extensions at Google, last week published an update on the company's Manifest v3 plan.

  Good news! Sort of

There's some good news: Various APIs will get more support for dynamic modification of web requests, request headers and URL parameters. This will make content blocking a bit less bad than the initial Manifest v3 draft suggested. But the basic problem remains: Manifest v3 will make extensions less effective at blocking unwanted content.
In his update, Vincent clarified that the original flavor of webRequest isn't going away for paying customers and that the API will continue to exist for the masses in amputated form.

    

"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)," he wrote.

        


        

Vincent said appropriately permissioned extensions will still be able to observe network requests using the webRequest API, which he insisted is "foundational for extensions that modify their behavior based on the patterns they observe at runtime."
But developer Raymond Hill, who created popular content control extension uBlock Origin, contends blocking capabilities matter more than observing. Losing the ability to block content with the webRequest API is his main concern.

        

"This breaks uBlock Origin and uMatrix, [which] are incompatible with the basic matching algorithm [Google] 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."
Hands off Brock! EFF pleads with Google not to kill its Privacy Badger with its Manifest destiny
READ MORE
Google did not respond to a request for comment. The ad biz previously said its aim with Manifest v3 is "to create stronger security, privacy, and performance guarantees."
But Hill, in a note posted over the weekend to GitHub, observes that performance problems arise more from bloated web pages stuffed with tracking code than from extensions intercepting and processing content. And he argues that if the blocking nature of the webRequest API really represents a performance concern, Google could just adopt Firefox's approach which uses a technique called Promises to return a non-blocking/asynchronous response.
Hill says he believes Google's technical changes represent an attempt to deal with the revenue threat posed by ad blocking. He points to a 2018 10-K financial filing by the company as evidence of its concern:

Hill said that the blocking ability of the webRequest API disempowered Google by putting control of content blocking in the hands of developers. With Chrome now the dominant browser, he contends, the company has a chance to re-insert itself into the mix.
"The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further now instrument and report how web pages are filtered since now the exact filters which are applied to web page is information which will be collectable by Google Chrome," he said.
In his email to The Register, Hill said, "Google's primary business is incompatible with unimpeded content blocking. Now that Google Chrome product has achieve high market share, the content blocking concerns as stated in its 10-K filing are being tackled." ®                                
                    