4 ms·

I like declarativeNetRequest and think that the tradeoffs are reasonable, especially after the last revision[2]. Ad blocker extensions are a major security risk

by lima 6y ago

I like declarativeNetRequest and think that the tradeoffs are reasonable, especially after the last revision[2]. Ad blocker extensions are a major security risk, and this fully eliminates the risk without breaking most of the functionality. Adblocker extensions need full access to all network traffic and all it takes is a single person's account or machine to be compromised to get access to millions of browsers. Chrome extension compromises are a somewhat common occurrence - see [1] for a recent example. I want ad blocking without giving the extension access to my cloud accounts, bank statements or company intranet. My current solution is to use the ExtensionSettings[3] Chrome policy to blacklist extensions from particularly sensitive domains like accounts.google.com, my bank and the company intranet, but it's a clunky solution - I still want tracking and ad scripts blocked on those! [1]: https://news.ycombinator.com/item?id=24803740 https://news.ycombinator.com/item?id=24803740 [2]: https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ... [3]: https://support.google.com/chrome/a/answer/9867568?hl=en https://support.google.com/chrome/a/answer/9867568?hl=en

deleted 6y ago
[deleted]
kudu 6y ago
> Ad blocker extensions are a major security risk This is only true in the sense that an all-purpose browser is "a major security risk". That is to say, it's not true in any coherent sense. Yes, the ad blocker needs to be trustworthy, and there are a variety of approaches for furthering that goal. > Adblocker extensions need full access to all network traffic and all it takes is a single person's account or machine to be compromised to get access to millions of browsers. Again, you could say the same about the browser itself. Even if it were infeasible for extension developers to implement more security safeguards, that would be a flaw in the Chrome Web Store, not in the concept of web extensions.
stefan_ 6y ago
A trivial "backspace to go back" extension needs access to all sites. Fraudsters buy semi-popular extensions and load them up with tracking and link rewriting malware, unhindered by Google. Their continued "refinement" of the core ad blocker APIs while all these abuses and deficiencies go unaddressed is extremely suspicious.
- lima 6y ago
  > A trivial "backspace to go back" extension needs access to all sites. Yes, this is bad and a big security risk. I don't use any extensions that request this permission. My company even pushes a Chrome policy that outright blocks them. Manifest v3 fixes this by taking away blanket <all_urls> permissions. This would break ad blockers, so they add declarativeWebRequest and remove the blocking webRequest API that would be useless anyway.
PoignardAzur 6y ago
There's a lot of hyperbole and exaggeration thrown around the subject of manifest v3 and declarativeNetRequest, but everything we've seen so far suggests that it really is an attempt to restrict ad blockers to a level Google is comfortable with (the level of Google's existing partner, AdBlockPlus). Some relevant points: - Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too) - Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest. - Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical. - Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd. Overall I have the same view of adblockers as I have of pirate sites: they're very convenient for me and I like to have them, but I don't begrudge corporations for doing everything they can to get rid of them. In a world where most of the internet is funded by ads, I understand why Google would want to find ways to make adblockers just a little less powerful. But Google's insistence that it isn't doing exactly that, and that its API is technically motivated, reads as corporate nonsense. They haven't responded at all how I'd expect them to if the whole controversy was just a misunderstanding.
- lima 6y ago
  > - Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too) Manifest v3 is still in development, so I'm assuming that this simply hasn't happened yet. It definitely needs to fit uBlock Origin's default rule set and I don't see them backtracking on the 150k announcement. > - Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest. This is the explicit trade-off that is being made. I'll gladly accept this limitation in exchange for not having to trust the ad blocker extension. > - Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd. The blog post explains this - the issue isn't the (in the case of uBlock, carefully written and very fast) extension code, but the IPC overhead in routing all requests through the extension. The Chromium teams loves metrics and they wouldn't make this claim without having substantial data to back it up - it's not a matter of opinion, but objectively quantifiable. > - Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical. The blocking version sits in the critical path, the non-blocking one can be called asynchronously. This is consistent with their reasoning. With Manifest v3, blanket host permissions are going away, which addresses data mining extensions and would make the existing blocking webRequest API impractical: https://twitter.com/justinschuh/status/1138889508512866304 https://twitter.com/justinschuh/status/1138889508512866304
throwaway189262 6y ago
Chrome is a security risk. Blocking extensions because "security" is just taking away control from the user. Why should Google be the arbiter of whether something I install is secure or not?
codedokode 6y ago
Almost any browser extension is a security risk, because it can inject JS code into web pages.
blibble 6y ago
the other way to keep extensions away is to use chrome's profile feature I have one for banking, for example, with zero extensions
anoncake 6y ago
If the tradeoffs were reasonable, ad blocker developers would voluntarily use the new API without Google forcing them.

by lima 6y ago

deleted 6y ago

[deleted]

kudu 6y ago

> Ad blocker extensions are a major security risk This is only true in the sense that an all-purpose browser is "a major security risk". That is to say, it's not true in any coherent sense. Yes, the ad blocker needs to be trustworthy, and there are a variety of approaches for furthering that goal. > Adblocker extensions need full access to all network traffic and all it takes is a single person's account or machine to be compromised to get access to millions of browsers. Again, you could say the same about the browser itself. Even if it were infeasible for extension developers to implement more security safeguards, that would be a flaw in the Chrome Web Store, not in the concept of web extensions.

stefan_ 6y ago

A trivial "backspace to go back" extension needs access to all sites. Fraudsters buy semi-popular extensions and load them up with tracking and link rewriting malware, unhindered by Google. Their continued "refinement" of the core ad blocker APIs while all these abuses and deficiencies go unaddressed is extremely suspicious.

lima 6y ago
> A trivial "backspace to go back" extension needs access to all sites. Yes, this is bad and a big security risk. I don't use any extensions that request this permission. My company even pushes a Chrome policy that outright blocks them. Manifest v3 fixes this by taking away blanket <all_urls> permissions. This would break ad blockers, so they add declarativeWebRequest and remove the blocking webRequest API that would be useless anyway.

PoignardAzur 6y ago

There's a lot of hyperbole and exaggeration thrown around the subject of manifest v3 and declarativeNetRequest, but everything we've seen so far suggests that it really is an attempt to restrict ad blockers to a level Google is comfortable with (the level of Google's existing partner, AdBlockPlus). Some relevant points: - Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too) - Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest. - Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical. - Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd. Overall I have the same view of adblockers as I have of pirate sites: they're very convenient for me and I like to have them, but I don't begrudge corporations for doing everything they can to get rid of them. In a world where most of the internet is funded by ads, I understand why Google would want to find ways to make adblockers just a little less powerful. But Google's insistence that it isn't doing exactly that, and that its API is technically motivated, reads as corporate nonsense. They haven't responded at all how I'd expect them to if the whole controversy was just a misunderstanding.

lima 6y ago
> - Google still hasn't raised the rules count like it announced last year in the blog post you linked. The current API is still limited to 30k rules. (the dynamic rule count is ridiculously low too) Manifest v3 is still in development, so I'm assuming that this simply hasn't happened yet. It definitely needs to fit uBlock Origin's default rule set and I don't see them backtracking on the 150k announcement. > - Even if the rule count were unlimited, having a static list of rules handicaps more complex algorithms like those used in uBlock Origin, that aren't limited to "if URL in URL_LIST then block". For instance, a Levenshtein-distance-based algorithm can't be implemented with declarativeNetRequest. This is the explicit trade-off that is being made. I'll gladly accept this limitation in exchange for not having to trust the ad blocker extension. > - Similarly, its stance that the proposed API is more efficient is extremely dubious. Modern WebAssembly has close-to-C++ performance, meanwhile ads and analytics are one of the biggest source of slowdowns of the modern net. The idea that restricting adblockers would improve performance in the general case is absurd. The blog post explains this - the issue isn't the (in the case of uBlock, carefully written and very fast) extension code, but the IPC overhead in routing all requests through the extension. The Chromium teams loves metrics and they wouldn't make this claim without having substantial data to back it up - it's not a matter of opinion, but objectively quantifiable. > - Manifest v3 doesn't seem to prevent extensions from examining traffic, just blocking it. So Google's stance that its API is against data mining, not ad blockers in particular seems hypocritical. The blocking version sits in the critical path, the non-blocking one can be called asynchronously. This is consistent with their reasoning. With Manifest v3, blanket host permissions are going away, which addresses data mining extensions and would make the existing blocking webRequest API impractical: https://twitter.com/justinschuh/status/1138889508512866304 https://twitter.com/justinschuh/status/1138889508512866304

throwaway189262 6y ago

Chrome is a security risk. Blocking extensions because "security" is just taking away control from the user. Why should Google be the arbiter of whether something I install is secure or not?

codedokode 6y ago

Almost any browser extension is a security risk, because it can inject JS code into web pages.

blibble 6y ago

the other way to keep extensions away is to use chrome's profile feature I have one for banking, for example, with zero extensions

anoncake 6y ago

If the tradeoffs were reasonable, ad blocker developers would voluntarily use the new API without Google forcing them.