
Improving Security and Privacy for Extensions Users - huntermeyer
https://security.googleblog.com/2019/06/improving-security-and-privacy-for.html
======
gergles
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.

~~~
Reelin
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.

------
pcwalton
Rebuttal from the author of uBlock Origin:
[https://twitter.com/gorhill/status/1139186208049905664](https://twitter.com/gorhill/status/1139186208049905664)

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

~~~
ignoramous
Twitter thread mirror:
[https://threadreaderapp.com/thread/1139186208049905664.html](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...](https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23)

\--

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](https://news.ycombinator.com/item?id=20038872)

~~~
qtplatypus
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.

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

------
mwest217
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](https://github.com/gorhill/uMatrix)).

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

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

