Improving Security and Privacy for Extensions Users | Hacker News Reader

Improving Security and Privacy for Extensions Users

security.googleblog.com

31 pointshuntermeyer11 comments

I really think whoever approves these to go on the Google blog needs to cut the Newspeak titles of these announcements, as it seems like they are almost always saying the exact opposite of the title in the article.

Nerfing adblockers does not "improve security and privacy for extension users" in any meaningful way, and it is, IMO, a revealing glimpse at the attitude Google has if they think it actually does.

The article's subtitle is also amazing.

> No, Chrome isn’t killing ad blockers -- we’re making them safer

Lately I'm skeptical of anything purporting to be "secure" or "safe" due to the prevalence of such doublespeak. More often than not these products or "improvements" are secured against the user instead of in their favor.

If Google actually cared about the safety of non-technical users, they would ban (or prominently flag) extensions that use the "dangerous" APIs from the centralized distribution channels that they control, similar to what they do with Google Play for Android.

Rebuttal from the author of uBlock Origin: https://twitter.com/gorhill/status/1139186208049905664

Edit: Not necessarily endorsing either side here; just thought it would be valuable to link to the response.

Twitter thread mirror: https://threadreaderapp.com/thread/1139186208049905664.html

One of Raymond's comments on the Chromium forum paints a different picture than the official Google blog here.

> From the description of the declarativeNetRequest API[1], I understand that its purpose is to merely enforce Adblock Plus ("ABP")-compatible filtering capabilities[2]. (snip)

> If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist.

> (snip) It's really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).

> Key portions of uBlock Origin[3] and all of uMatrix[4] use a different matching algorithm than that of the declarativeNetRequest API. (snip)

> There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. (snip)

> Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium (snip)

Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=896897...

Raymond also commented on the topic on news.yc:

> The most concise summary I can come up with is in the article:

> Google's primary business is incompatible with unimpeded content blocking.

Ref: https://news.ycombinator.com/item?id=20038872

One of the comments Raymond made I felt was kind of missing the point ““to cut substantial overhead in the browser": I already commented that performance of well-crafted content blocker is not an issue.”

Assuming that third party code is well crafted is not how you build a secure API.

I think many of the comments about how it doesn’t protect users because extensions can still see the request but just can’t act on it also misses a point. If the interfaces are split you can enable the block lists without enabling the extension seeing your content.

Fixes an issue where malicious extension authors could prevent users from hearing about valuable products and services.

Disclaimer: I'm a Googler, but don't work on anything related.

This seems like probably a good thing for casual users. Safari adblockers have shown that declarative lists can work well enough. The people who will suffer, I fear, are those of us who run more flexible and powerful tools, like [uMatrix](https://github.com/gorhill/uMatrix).

Not a fan of ad blockers myself. Though this still seems like a step backwards. There's no escape hatch for informed users.

Why are you not a fan of adblockers, if I may ask?

You can enable the enterprise features which will allow this.

> Safari adblockers have shown that declarative lists can work well enough

I've written my own Safari blocker based on https://someonewhocares.org/hosts/ and found the declarative rules to fit my needs.

I've also had the displeasure of removing malicious extensions from my dad's laptop, so I get why they want to remove an API that allows data exfiltration.

Reply on news.ycombinator.com