6 ms·

Improving Security and Privacy for Extensions Users

31 points by huntermeyer 7y ago

mwest217 7y ago
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).
- deleted 7y ago
  [deleted]
- paulryanrogers 7y ago
  Not a fan of ad blockers myself. Though this still seems like a step backwards. There's no escape hatch for informed users.
  - gear54rus 7y ago
    Why are you not a fan of adblockers, if I may ask?
  - qtplatypus 7y ago
    You can enable the enterprise features which will allow this.
- conroy 7y ago
  > Safari adblockers have shown that declarative lists can work well enough I've written my own Safari blocker based on https://someonewhocares.org/hosts/ 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.
idlewords 7y ago
Fixes an issue where malicious extension authors could prevent users from hearing about valuable products and services.
pcwalton 7y ago
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 7y ago
  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&desc=2#c23 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 https://news.ycombinator.com/item?id=20038872
  - 7y ago
gergles 7y ago
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 7y ago
  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.

31 points by huntermeyer 7y ago

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).

deleted 7y ago
[deleted]
paulryanrogers 7y ago
Not a fan of ad blockers myself. Though this still seems like a step backwards. There's no escape hatch for informed users.
- gear54rus 7y ago
  Why are you not a fan of adblockers, if I may ask?
- qtplatypus 7y ago
  You can enable the enterprise features which will allow this.
conroy 7y ago
> Safari adblockers have shown that declarative lists can work well enough I've written my own Safari blocker based on https://someonewhocares.org/hosts/ 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.

idlewords 7y ago

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

pcwalton 7y ago

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 7y ago
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&desc=2#c23 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 https://news.ycombinator.com/item?id=20038872
- 7y ago

gergles 7y ago

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 7y ago
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.