3 ms·

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 o

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