Hacker News Reader

Comment by antonok | Hacker News Reader

Brave's adblocker is all native code, so it's a bit more memory/CPU friendly than uBlock Origin. There's also some enhancements like CNAME uncloaking[1], which only otherwise works in uBlock Origin on Firefox because Chromium doesn't expose the required DNS API support for extensions.

[1] https://brave.com/privacy-updates-6/

View on HN

Yeah, what I do now on my ff fork is just use no script by default… would be great if i decided to add a function in the dom module that just stripped out all script tags, indexed them in a list, displayed that list in the UI, then another function to process a whitelist to allow specific script tags for… just haven't implemented it yet cause no script is enough for me but im perpetually tempted just from the performance boost.

Same for ad blocking but I have native mitigations with browser meta data spoofing on every http request (which of course gets unmasked if you log into sites, but its always funny to get a warning email from google when I check gmail occasionally).

CNAME cloaking is only the first of many possible mitigations. CNAME flattening would be the next likely angle of attack.

Advertisers can very well get websites to run "cloud functions" at the edge (with Fastly, Cloudflare, Netlify, Vercel, AWS Lambda etc) under the first-party domain, and the content blockers (native or not) will be none the wiser. This is similar to how content blockers struggle to block ads served from first-party domains on YouTube and other Facebook properties.

Exhibit A: https://github.com/samkelleher/cloudflare-worker-google-anal...

Of course, adblocking has always been and will always be a game of cat-and-mouse.

Interesting link. I will say though, Brave's been aggressively pushing for an end to third-party cookies, and if websites are increasingly forced to run first-party analytics as a counter-measure, that is still a major win for the internet as a whole.

Reply on news.ycombinator.com