4 ms·

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

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

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

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