Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

uBlock Origin CNAME uncloaking now supports filtering by IP address

github.com

Post reply on HN
Print view View original

91–100 of 133 posts

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#91

Post by madeofpalk »

tyingq wrote: post #48

This a good example of why manifest v3 sucks. By definition, it can't do anything like this...no live code hueristics are possible. It's a war of escalation with advertisers. Google is the arms dealer to both sides. They won't give you what you would need to win.

There's no reason why a declarative manifest v3 API couldn't offer this. If I'm reading the commit details correctly, it could work even better by being better integrated into the request flow to block the request on the actual IP address used before anything is sent to the servers.

Of course, this all relies on browser vendor (Google) wanting to add this API. Doing this imperatively with "live code" allows for innovations in userland before browser makers add built in support for it.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#92

Post by lelandbatey »

ndriscoll wrote: post #50
lelandbatey wrote: post #10

As an example of what CNAME cloaking is, let's say that a SAAS provider A wants to provide you, company Q, with fancy ad tracking software. In the olden days, they'd tell you to embed a script at e.g. https://A-ads-tracking.example into your website at address https://q-company.example To block those ads, blocklists that uBlock Origin use have rules then that say "block requests being made to the domain name A-ads-tr…

That's not quite right; as the name suggests, it uses CNAMEs (which point to other records), not A records (which point to IPs). So you would have something like `media.q-company.example` as a CNAME to `q-company.ads-tracking.example` which then has an A record to give an IP. Browsers might not offer intermediate DNS names to extensions (I don't know), so something like uBlock might need to rely on IP lists, but DNS-…

Gah, it's all right there! Amazing what you can forget/mistake due to what you've been working on lately.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#93

Post by Dwedit »

Exuma wrote: post #9

Is chrome going to block uBO im never up to date on the latest. I do know theyre allowing 3rd party cookies now... so maybe theres a chance

For right now, uBlock Origin is still on the Chrome Web Store for Chromium browsers which support Manifest V2. If you use a Manifest V3 only version of Chromium, it is hidden.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#94

Post by OkayPhysicist »

xelamonster wrote: post #77
jajko wrote: post #12

Earlier quoted context omitted.

I moved many years ago to this combo, and never saw a single reason to switch away. Same for android phone, the only usable mobile web experience I've seen. Those few sites over a decade that had some display issues had issues also under chrome. Plus I personally consider ads a cancer of modern society. White and not so white lies, manipulation... nothing respectable regardless (or because ) of tremendous money circu…

I really wish I could agree but sadly this has not been my experience with Firefox, and I have so many issues I've started to switch away recently. Wasting way too much time fighting with websites that turn out to work perfectly fine on Chrome, and the captchas I get on Firefox are becoming genuinely impossible for me to solve. I'm with you on the ads though, and glad it's working out for someone at least!

Try Firefox serving Chrome's UserAgent. You'll be shocked how many issues disappear.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#95

Post by nine_k »

takeda wrote: post #89
gruez wrote: post #76

Earlier quoted context omitted.

>This a good example of why manifest v3 sucks. By definition, it can't do anything like this... Technically manifest v3 has nothing to do with APIs that the browser makes available to extensions. On firefox manifest v3 is supported with blocking web request[1], which is the filtering api prior to "manifest v3". Therefore the statement that it certain functionality "by definition" is false. [1] https://blog.mozilla.or…

I'm confused, isn't the Manifest V3 essentially just API spec?

Yes. The point is which APIs Google exposes through it.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#96

Post by dang »

vifon wrote: post #4

The title seems to be wrong, uBlock Origin supported it for many years at this point (only on Firefox). This seems to be a refactor of that code, not a whole new feature.

Ok, I've reverted the title to that of the page. Submitted title was "uBlock Origin supports filtering CNAME cloaking sites on Firefox now". If someone wants to suggest a more accurate and neutral title, we can change it again. Github commits without additional context don't usually make for great HN threads though...

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#97

Post by grotorea »

debit-freak wrote: post #29
hypeatei wrote: post #24

Earlier quoted context omitted.

What are the implications?

Presumably that adblockers (or rather their users) would object to blocking domains that folks might actually want to load content from. I can’t imagine “domain” is the only signal one could use to identify ads, though. To truly befuddle them you’d make advertisements truly indistinguishable from content. This is not trivial.

I think what we're asking is what are the implications for the advertisement company.

And yeah, I can trivially block stuff in uBO by using CSS rules for example, so that's still on the table.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#98

Post by capitainenemo »

xelamonster wrote: post #86
WD-42 wrote: post #70

Earlier quoted context omitted.

Is that going to help? Brave is still blink. They might have some filtering baked in but I’m not sure if it’s as powerful (or can be) as UBO.

I don't think the new manifest rules are because of any actual restriction or the engine, maybe I'm wrong but it was my impression that the change is mostly just Google wanting to control what users can do with their browsers even more (and always in ways that make them profit of course). So they should be able to keep V2 support if they're willing to be on the hook for keeping it maintained themselves.

And if the removal of manifest v2 allows google to abandon/remove/refactor code exposed through it (and google could even be inclined to do so deliberately)? At some point Brave would end up having to maintain its own fork, which they probably don't have the resources to do.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#99

Post by tyingq »

takeda wrote: post #89
gruez wrote: post #76

Earlier quoted context omitted.

>This a good example of why manifest v3 sucks. By definition, it can't do anything like this... Technically manifest v3 has nothing to do with APIs that the browser makes available to extensions. On firefox manifest v3 is supported with blocking web request[1], which is the filtering api prior to "manifest v3". Therefore the statement that it certain functionality "by definition" is false. [1] https://blog.mozilla.or…

I'm confused, isn't the Manifest V3 essentially just API spec?

They trojan horsed hobbling webRequest.onBeforeRequest into their manifest v3 design doc and rollout. Which is part of what would give you request time cloak detection.

Re: uBlock Origin CNAME uncloaking now supports filtering by IP address

#100

Post by tyingq »

madeofpalk wrote: post #91
tyingq wrote: post #48

This a good example of why manifest v3 sucks. By definition, it can't do anything like this...no live code hueristics are possible. It's a war of escalation with advertisers. Google is the arms dealer to both sides. They won't give you what you would need to win.

There's no reason why a declarative manifest v3 API couldn't offer this. If I'm reading the commit details correctly, it could work even better by being better integrated into the request flow to block the request on the actual IP address used before anything is sent to the servers. Of course, this all relies on browser vendor (Google) wanting to add this API. Doing this imperatively with "live code" allows for innov…

It could. Google won't do that for chrome.

Had they not taken away onBeforeRequest with manifest V3, plugins could implement it themselves. Which is the thing you're suggesting...before the request goes.

Post reply on HN