https://blog.chromium.org/2018/02/how-chromes-ad-filtering-works.html … is going to be awesome. Brave maintains native ad-blocking support for Chromium but we've been reluctant to use it because needing to port substantial changes to new releases with lots of time pressure (security updates) is already hard enough for AOSP.
-
-
We're interested in it as a filtering engine, not how they're using it. See the other tweet in this thread and the others.
-
It will be trivial to disable their usage of a blacklist to use it everywhere. It only needs to be a proper implementation of applying EasyList-style filters at a network level. Not clear if they're doing content hiding but that's higher level and not relevant to attack surface.
-
See https://github.com/copperhead/bugtracker/issues/511 …. Brave's implementation looks good but it's too much code to maintain out-of-tree. They take too long to move to the new stable releases so we'd end up needing to deal with it on our own. If this works as well, it will be perfect.
-
Using the extension API to intercept each network request is far from ideal, and not currently an option on mobile anyway. It adds overhead per connection (uBlock Origin tends to provide more performance than it loses, but still...) and more importantly it's soft-fail / fragile.
-
'Filtering on sites at the network level' and 'What this looks like in Chrome' are the relevant sections there. It looks like the UI might be a bit too annoying but we'll need to see what they ship before we can decide if it needs to be made more subtle.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.