Effectively, not a lot. eBPF does have the capabilities to do more than a regular firewall, but this just seems to do an IP lookup in a blacklist file.
If you buy a fancy network card from a company like Nvidia, you could run the eBPF program on the card itself and the kernel wouldn't even see the packet come in. This use case doesn't seem like it'd need that kind of performance tweak, though.
It's useful as a fun project to experiment with eBPF, though!
Do you have a model number for an Nvidia offload card? I thought that only Netronome did them and that they were kinda long in the tooth now. I’d love to get my hands on one.
However, details are very hard to come by. Maybe the "offload" they offer isn't actually offloading anything and I've just misunderstood them when I last heard about them (and kernel XDP really is that fast).
It's one program that blocks everything everywhere, and doesn't rely on specific firewall configurations or DNS resolvers to be able to block requests.
And because it uses eBPF, technically (it probably doesn't support this yet but it could) you could block requests at the application level, even if it uses TLS, before it ever even gets to a resolver or firewall.
Taking that fact even further, this means that not only well-behaved resolv.conf-reading applications are blocked, but programs that use their own DoH/DoT could be as well. Your browser wouldn't even need an ad-blocker extension. Your local resolver and your VPN-specific resolver both continue to work normally while also blocking what you want.
> getting underneath TLS and DoH (which have both been effectively weaponized at this point).
Only to the extent you are running software you don't trust. If you're running a user agent (e.g. a browser), rather than an app, you can easily do full ad-blocking much more effectively.
Calling TLS and DoH a weapon because apps you don't trust can use them to maintain integrity of their connections is like calling secure coding practices a weapon because they make jailbreaking harder.
Yeah I'm just going to have to completely disagree at a militant volume. Keeping the contents of connections made on my behalf secure from my own inspection is fucked up and I want harm to befall those that do so.
I'm not a little angry about surveillance capitalism, I'm start a war angry about it.
I agree with your frustration, and just fundamentally disagree with your attribution of blame. Security is a feature. Software that works against its user is an awful thing. Security features that help secure software for the benefit of users do not become bad just because they also help secure software that works against the user. The solution there is not running software that works against its user.
Eliminating buffer overruns across the entire industry will also make it harder to e.g. jailbreak game consoles or iOS devices. That doesn't make it bad to eliminate buffer overruns; the problem is with devices requiring jailbreaking in the first place, rather than serving their users.
If you believe that TLS and DoH do more harm than good, you may be in a bubble where e.g. things like pihole are common, rather than being obscure tools used by highly technical users who tolerate and debug breakage.
I don't think there is any justification for shipping software with exploitable security problems on purpose, and it sounds like I maybe gave you the impression I do. I think all software should be as secure as it's feasible to make it.
But I don't think that security should ever operate against the person who bought the device and is sitting in front of it. I don't think anything on my device or anyone's should be able to phone home in a way that is secure from me: and so I am very happy with things like eBPF that make root mean root.
I think that there are certain things you do not do as a professional, as a moral person, as a person who wants to be proud of what you've done. And both TLS and DoH are now routinely used by vendors to do things that users don't know about, don't want, wouldn't consent to if they knew, and I think people should go to jail over it.
I worked in big consumer internet during the period when it was beloved, and during the period where it was starting to get sketchy, and at some point I walked away from millions in unvested stock because a line had been crossed.
Near as I can tell a lot of us with reservations left, and those that remain are those with few if any qualms of any kind.
If you buy a fancy network card from a company like Nvidia, you could run the eBPF program on the card itself and the kernel wouldn't even see the packet come in. This use case doesn't seem like it'd need that kind of performance tweak, though.
It's useful as a fun project to experiment with eBPF, though!