> For instance, they're also able to apply cosmetic rules.
How does this happen? Do you inject the thousands of CSS rules from EasyList in each page? Doesn't this require AdGuard to be able to have access to the response body for secure connections? Doesn't this mean that web pages can easily override injected cosmetic filters since these are not injected as user styles?
1. Yes, it basically injects a CSS stylesheet into every page + a JS script that does additional filtering.
2. Yes, in order for this to work, AG will need to access response body.
3. Yes, and in this case we'll need to use JS-based filtering (so-called extended CSS rules or scriptlets).
And here's an answer to the question you didn't ask: yes, this would be slower than doing the same with a browser extension. To make it faster, a different approach to filter rules is required - fewer generic cosmetic rules, more HTML filtering and removing elements from the page content.
The end goal is to completely get rid of any app or extension. Ideally, I'd like to see all the filtering moved to a server-side application like AdGuard Home.
If all pages were static this would’ve worked beautifully.
But they aren’t, and uBO approach also implies that there is a mutation observer constantly monitoring DOM changes and adding new rules when they are needed. In a browser extension it uses browser’s own RPC to pass DOM nodes to the background page, check them, and apply new rules when needed.
In our case we would’ve needed to use something like a websocket to do it, but WS may be quite problematic. And the overall performance gain from this DOM-survey approach is milliseconds, it’s not something that a person can notice.
How does this happen? Do you inject the thousands of CSS rules from EasyList in each page? Doesn't this require AdGuard to be able to have access to the response body for secure connections? Doesn't this mean that web pages can easily override injected cosmetic filters since these are not injected as user styles?