4 ms·
> It's safer for an ad blocker to read and modify a page if it has no method of exfiltrating the content. The problem is that being able to modify the page is
by ytpete 10y ago
> It's safer for an ad blocker to read and modify a page if it has no method of exfiltrating the content.
The problem is that being able to modify the page is a method of exfiltrating information - e.g. you can add an img tag triggering a GET to an arbitrary URL. I suspect it would be surprisingly tricky to try restricting page modification in such a way that information can't be sent anywhere the page wouldn't have sent it originally.
But +1 on deferring permissions prompts until the moment the app actually needs the privilege, though. It's worked pretty well on iOS, and it's finally coming to Android - maybe it'll come to Chrome or Firefox next.
- kalleboo 10y agoThat's a good point about modifying the page. It could probably be done but there are a LOT of edge cases in there that will be easy to overlook and it would become a constant source of security bugs. edit: since content blockers in particular are so popular, it might even make sense for them to create a security-conscious content blocker specific API like Apple did
- deno 10y agoAnd Opera, which is based on Chromium: https://www.opera.com/computer/features/ad-blocker https://www.opera.com/computer/features/ad-blocker Google’s not rushing to implement this for obvious reasons. They will most likely continue to push AMP and at some point decide to block “malicious ads” or whatever, so that in one move they can both cut out the competition (by being the de facto arbiter of acceptable ad technology) and make sure they don’t negatively affect their business. It’s still a net positive for the user, at least in the short term.
- deno 10y agoYou could, in theory, filter those sort of things. Adding, or modifying any DOM node, to the effect that it includes third-party resources could be denied. If you also deny adding inline <script> blocks and enforce any injected javascript to run in strict CSP mode it could potentially work.
- robryk 10y agoThe original page's JS might depend on the DOM tree of the page. Thus a change that doesn't obviously cause any information to be emitted to third parties can cause that JS to do that (e.g. if the JS uses attributed of DOM tree nodes as URLs of data sources or data sinks).
- deno 10y agoThat’s valid. I still feel it would eliminate at least most of the abuse, like injecting ads though. Unless there’s something very widely deployed (say jQuery etc.) that’s vulnerable.
- dgoldstein0 10y agocouldn't we just give adblockers an api for filtering network requests, that they could just decide to allow or deny requests? And then give them no other internet access? This seems like an API failure that common jobs for extensions can't be done without scary permissions.
- roblabla 10y agoThe problem is, many adblockers also have a feature to disable certain DOM nodes inside websites, to avoid embedded ads or remove anti-adblockers. So you'd also need an API to filter out certain selectors... And the list of specialized APIs could continue on and on.
- madeofpalk 10y agoApple kind of solved this problem with the Content Blocker API - all of this is defined in a 'static' list which is used by Safari to block certain things.
- DougBTX 10y agoThat's close to the content blocker api in Safari: https://webkit.org/blog/3476/content-blockers-first-look/ https://webkit.org/blog/3476/content-blockers-first-look/
- robryk 10y agoIt could still exfilter information if it could share any state between domains: the evil adblocker is associated with a site that many users visit. The site makes a lot of requests when it's loaded and adblocker exfiltrates information by selectively blocking those requests.
- iancarroll 10y agoChrome has an API for this, IIRC. They still need to connect to the internet to update their rule lists, though.