This article is more than 1 year old

Hands off Brock! EFF pleads with Google not to kill its Privacy Badger with its Manifest destiny

It's not hard, we just need some coding tweaks to make sure Privacy Badger stays sane

In an effort to discourage Google from breaking or hobbling content blocking and privacy Chrome Extensions, the Electronic Frontier Foundation on Wednesday presented the Chocolate Factory with a modest wish list [PDF] to guide the company's ongoing API revision.

The aptly named Bennett Cyphers, staff technologist for Electronic Frontier Foundation, and Andrés Arrieta, director of consumer privacy engineering, have identified two areas of ongoing unease for the advocacy group's Privacy Badger extension, which is designed to stymie privacy-plundering ad trackers.

Among the many contemplated changes in the Manifest v3 design specification, Google's plan to deprecate the webRequest API (WR) and offer the declarativeNetRequest (DNR) API as an alternative remains a sticking point. Though WR is a blocking API and DNR is asynchronous – meaning it doesn't hold other code up while processing requests – the problem for developers is that the former is more flexible than the latter, allowing filtering rules to be rewritten dynamically rather than declared and fixed in advance.

Cyphers and Arrieta remain concerned about this change, one singled out by many extension developers in the past few months as a problem. "We’ve listed a set of changes to the proposal that we believe are necessary to keep Privacy Badger functioning as it does now and to allow us to implement planned changes in the near future," they wrote in their letter to Google's Chromium team.

"However, we still believe that the proposed changes in Manifest v3 will hamper extension developers’ ability to innovate and adapt to a changing tracking landscape in the future, and continue to urge you to reconsider deprecating the blocking webRequest API."

Beyond that, the pair takes issue with the Chromium team's stated intention to get rid of a flag granting an extension access to all URLs (<all_urls>) and to replace it with a permission targeting only the active tab (activeTab) in the browser window.

"Privacy Badger, and other ad- and tracker-blockers, depend on blanket permissions like <all_urls> to function," the two said. "There is no practical way to build a blocking extension in the activeTab model; the burden on users to grant consent for each and every site they visit would be far too great, and all but the most privacy-conscious users would uninstall the extensions."

Forcing extension users to explicitly grant permission all the time, argue Cyphers and Arrieta, will reduce usage of Privacy Badger. They explain that the EFF saw the effect of changing defaults when it made a change to the HTTPS Everywhere in Firefox.

When the organization updated the extension to require permission for "ftp://*" URLs, users again had to grant access to the extension to access data on all sites, which they had already done. So rather than re-grant permission, a significant number of users chose not to update it and a few users even posted negative reviews that complained about nefarious data harvesting.

Firing squad

Chrome ad, content blockers beg Google: Don't execute our code! Wait, no, do execute our code – just don't kill us!


The EFF staffers also said that while promises by the Chromium team that the network traffic monitoring capabilities of the WR API will remain intact are heartening – because Privacy Badger depends on being able to inspect URLs, GET and POST parameters, headers and cookies – further changes are needed to make DNR suitable.

Basically, the new API needs to match the one on its way out. DNR should provide a way to "intercept, inspect, and modify requests with arbitrary code at runtime," as WR does, said Cyphers and Arrieta.

Privacy Badger needs to perform request header modification to protect privacy but DNR does not presently support this capability. It also needs to be able to modify URL parameters, ideally using regex pattern matching, to aid in the identification of sensitive information in parameter strings. And EFF developers want to implement contextual rewriting of request data, to allow for the removal of unnecessary redirects, for example. But DNR doesn't presently support this either.

Earlier this week, Chrome Extensions developer advocate Simeon Vincent said Google doesn't yet have a firm timeline for rolling out Manifest v3, but the extensions team is working on a developer preview that implements most of the changes, to facilitate transitioning and testing. "We don't have an exact date for this, but we're hoping to ship it in the next few months," he said. ®

More about


Send us news

Other stories you might like