3 ms·

> Chrome is trying to limit use-cases that require full access to every single site you visit That argument is always made and every single time there needs t

> Chrome is trying to limit use-cases that require full access to every single site you visit That argument is always made and every single time there needs to be a reminder that: The webRequest API -- used to observe all network requests -- will still be available, it just won't be able to be used to block or redirect network requests, but still can be used to observe all outgoing network requests and all incoming response headers. Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. So essentially content blockers such as the current crop of top content blockers will still need to see all the sites visited by users in order to meet what users expect from their blocker.

fastest963 6y ago
Previously the webRequest API was the only way to do content blocking but now that there's an alternate way to do it they can block extensions still using the old way or gate it behind a special scary warning. > Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. My OP was talking about a very real problem where extensions are being sold and nefariously used to sniff credentials because they have full control over the tab execution environment. How do you propose to solve that problem while still allowing adblocking?
- rasz 6y ago
  There is no alternative way. You need to manipulate headers to modify CSP. No control over CSP means no way to block js from running altogether (Content-Security-Policy: script-src http: https:), to block web fonts (Content-Security-Policy: font-src *), to block twitch ads (overriding origin and referrer).
- gorhill 6y ago
  Where did you get the idea that "blocking webRequest API" and "extensions being sold" are part of the same problem requiring to be solved by the removal of the blocking ability of the webRequest API? There are good examples out there of extensions exfiltrating browsing information and which didn't required a blocking webRequest to gather such information, and they were not content blockers. I am not the only person having an issue with the deprecation of the blocking ability in MV3, see this EFF article: https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...

fastest963 6y ago

Previously the webRequest API was the only way to do content blocking but now that there's an alternate way to do it they can block extensions still using the old way or gate it behind a special scary warning. > Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. My OP was talking about a very real problem where extensions are being sold and nefariously used to sniff credentials because they have full control over the tab execution environment. How do you propose to solve that problem while still allowing adblocking?

rasz 6y ago
There is no alternative way. You need to manipulate headers to modify CSP. No control over CSP means no way to block js from running altogether (Content-Security-Policy: script-src http: https:), to block web fonts (Content-Security-Policy: font-src *), to block twitch ads (overriding origin and referrer).
gorhill 6y ago
Where did you get the idea that "blocking webRequest API" and "extensions being sold" are part of the same problem requiring to be solved by the removal of the blocking ability of the webRequest API? There are good examples out there of extensions exfiltrating browsing information and which didn't required a blocking webRequest to gather such information, and they were not content blockers. I am not the only person having an issue with the deprecation of the blocking ability in MV3, see this EFF article: https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...