A few months ago, Google announced changes were coming to improve privacy, security, and performance with regard to Chrome extensions. In particular, one change didn’t sit well with ad blocker developers, who claimed Google was looking to diminish their efficacy. At the time, at least one company threatened to pursue filing an antitrust complaint.
Yesterday, Google hit back with a blog that basically says, “Nuh uh. We’re not trying to kill ad blockers, we just want to make them safer.” At the core of the issue is the Web Request API. Google announced it was replacing some parts of that particular API with what it calls the Declarative Net Request API. In Google’s words, the change means an extension “does not need access to all a user’s sensitive data in order to block content.”
It goes on to explain the current Web Request API requires users to grant permission for Chrome to pass along all information in a network request, and that can include private data such as emails and photos. However, the company claims the new API will allow extensions to block content without requiring users to give access to private data.
“There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers,” Google writes in a separate blog detailing the differences between the two APIs. “This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers.”
There are some numbers to back up Google’s claim. The company says that while many good actors, like ad blockers, use the Web Request API, it’s also been abused—42 per cent of malicious extensions have apparently used the Web Request API since January 2018, according to Google.
At least on the surface, this looks like a good thing. But there are a few niggling details that call that into question. Back in January, the Register reported that Adblock Plus and similar plugins relying on basic filtering would still be able to function, while more sophisticated ones like uBlock Origin and uMatrix would be completely borked. The site also noted that well, Google had conveniently paid Adblock Plus to let their own ads pass unblocked in the software. In a statement, Ghostery, another popular adblocker, pointed out the Declarative Net Request API was limited, and that it wouldn’t be possible to “modify or kill potentially dangerous or privacy-invading requests.”
To Google’s credit, it’s since worked with outside developers on some the issues. Google ended its blog hedging that Declarative Net Request is “still very much in design and development” and that it welcomes feedback from the community. Since its proposal in January, it now plans to raise the number of rules extensions that are used to identify content from 30,000 to 150,000.
Still, developers aren’t buying it. In a statement to Wired, Ghostery President Jeremy Tillman said, “I think they’ve been trying to give the impression that they’re working with the developer community, when in fact they’re pretty entrenched with what they want to do. The new API is not in itself a bad thing, but it becomes a bad thing when it’s the only option because it lacks the flexibility that the Web Requests API provides.”
Ultimately, it boils down to whether you believe Google isn’t trying to slowly squeeze the life out of ad blockers and create its own version. Google makes a big chunk of moolah off its ad business, so cynically speaking, it doesn’t have a huge incentive to make things easy for third-party ad blockers. Google hasn’t said when Manifest V3—the name for all the upcoming changes, including Declarative Net Request, will be live. It’s more than likely Google and third-party ad blockers will come to some sort of working solution by then—but how effective it is for end users will depend on whose version of the story you trust more.