IP level blocking for Tor Browser and Firefox

[iam-py-test]

There are a lot of cases where blocking on the IP level could be helpful (i.e. uBlockOrigin/uAssets@56da93d, although there's probably better)
I know AdGuard's App has $network for that, although I have not had a chance to figure out exactly how it works
I understand this would be a lot of work, but it could be very helpful when fighting malware, or even blocking ads/trackers
What does everyone think?
CCing @DandelionSprout

[spirillen]

IF, this idea get passed through the filter and end up as code I would recomment to set a requirement for the CIDR (subnet) value.

Why? It would add full cross project support between BlackList systems like uBlock adblock etc and RPZ (https://mypdns.org/mypdns/support/-/wikis/RPZ-record-types#the-client-ip-address-trigger-rpz-client-ip-anchor-clientip) and it will help ensuring only the relevant network will become blocked.

My initial 2 cents

[iam-py-test]

Maybe uBo could parse RPZ filters like what it does with HOSTs files

[spirillen]

That would be a bit hard I think... I would be a lot of code as RPZ is bind formatted zone file records (See RFC draft: https://datatracker.ietf.org/doc/html/draft-vixie-dns-rpz-04 and RFC:1034) and they are living within the DNS server. They can of curse be exported as zone files over AXFR as intended but I (currently) not seeing how these kind of blockers could integrate these zones in a elegant way.

This is one of many reasons why I keep my backup files in a clean structure, so they are easy to integrate for other in what way they prefer without a lot of decoding.

I'm at least very open for this suggestion.

NB: In case this idea are given birth (I do hope for everyone) we should remember to inform @funilrys about rewriting his awesome @PyFunceble --adblock

[gorhill]

IP addresses are not known before a server responds to a network request, and for Chromium-based browsers, it's even at response body time (if I remember correctly), at which point it's not possible to block. The dns.resolve API could be used on Firefox, but then you would end up with filters which work only for Firefox, not ideal. I don't see this as a feature worth the amount of work I would have to put into this.

[gorhill]

The CNAME blocking also only works in Tor/Firefox

Yes, and it was worth the amount of work I put in this. I don't feel this way so far with IP blocking. There was a more convincing case made with detecting/blocking local IP addresses, and even with this one this would have been a lot of work and in the end decided to go with @gwarser's list.

[iam-py-test]

Understood. Should I delete this or just leave it encase someone comes up with a reason

[gorhill]

Should I delete this

Of course not, we are here to discuss/debate, who knows what happen in the future, maybe I will feel differently. For now I don't see myself undertaking such amount of work for the given reasons.

[spirillen]

I don't have anything to add for now, gorhill kind a said it all 😃

[uBlock-user]

The CNAME blocking also only works in Tor/Firefox

cloaked CNAMEs have major privacy implications which Chromium already suffers from, you can't compare that to this.

uBO HTML filtering works only in Firefox as well.

That's one more tool in our arsenal against anti-user behaviour and the fact that race conditions is moot against HTML Filtering makes it a perfect tool against inline resources.

[DandelionSprout]

Okay, so I lack insider info on how AdGuard's $network actually works. I'm presuming AdGuard detects the outgoing IPs in the connections, without relying on CNAME.

[gorhill]

AdGuard has its own DNS server, so presumably this is how the IP addresses are looked up. AdGuard's documentation:

Only AdGuard for Windows, Mac, Android are technically capable of using this type of rules.

[ghost]

uBlock having a kind of like /etc/hosts to block IP/CIDR will be amazing! Its called uBlock after all, it should be thought of like firewall for browser.