Pi-hole wont protect you here, they will send the entire page, ads and all as an encrypted binary blob. Decrypting it is illegal, and since the data is coming from a single source Pi-hole can't block it.

Pi-hole (and ad-blocking) days are numbered. Hopefully that day is further out than I dread.

It has to be decrypted at some point to be viewable, so if you have system administrator access to the OS and device your browser is running on, someone will figure out how to identify which pixels and which audio bits are ads and block them from making it to the frame buffer (and whatever the equivalent is for a sound card). Where there's a will there's a way. There has just not been a need for that yet.

It's just an arms race, and the makers of uBlock Origin will need to level up and figure out how to do some serious computer vision and heuristic anomaly detection.

When ad blocking on web becomes impossible/nonviable, I will retreat from using it, as I have retreated from using most popular sites, unless absolutely.

I already don't have a TV, don't have any news apps on my phone, don't have any newspaper subscription, and I find that all the important news find their way to me no problem. I will add large degree of WWW to it and be mostly fine.

Its already possible to have server side rendering bake in ads on web pages, but just about nobody does it. I think the percent of people who know about pi-Hole vs the cost of server side rendering will always make client-side rendering the optimal choice for the people running the websites. They can block adblocking browser extensions, and that will be enough for them.

That's because the ad networks require a level of validation of their views that they prefer to have control over with javascript snippets or pixels.

But it's technically a bit different, since an ad-blocker could still block those baked in advertisements while it's traditional web technology. If it's a binary blob rendered with canvas, that won't be true anymore, which I think was what the parent comment was getting at.

> If it's a binary blob rendered with canvas, that won't be true anymore.

The request for the ads will either happen server side or client side. If it happens client side, it can be blocked at the network level by the pihole regardless of whether a blob or js script is making the request. The request happening server side is unlikely per my previous comment.

Your previous comment doesn't explain a reason why it would be unlikely, just that it isn't. The reason it's currently unlikely is because ad-networks need to validate their views. Because you can ad-block on HTML alone, it isn't worth it to risk webmasters falsifying serverside views in order to try and get around ad-blockers because it wouldn't work. But add the ability to get around ad-blockers entirely and it becomes worth it to solve for server-side view validation.

This is the landscape as I see it:

HTML, ads loaded by user network: Can be blocked at network or in HTML.

Binary blob, ads loaded by user network: Can be blocked at network level

Serverside ads, HTML : Can be blocked by removing the ads in the HTML, and ad-networks don't like it because their views can't be validated and they could be scammed by webmasters.

Serverside ads, binary blob: Can not be blocked by network or by hiding things in the HTML, ad-networks and webmasters would want this because they can get around ad-blockers, but will need to solve view validation, the tradeoff becomes worth it.

> The reason it's currently unlikely is because ad-networks need to validate their views.

Ad-networks also want to validate views because they don't trust the hosting website. They don't need to trust the hosting website's server when they can receive a direct connection from the client.

However, there is an alternative that fits "serverside ads, binary blob" scenario: the ad-network hosts the website. Obviously the website owner wouldn't want to turn over control to the ad-network, but they don't get a choice when they depend on the ad-network for revenue. Even worse: this isn't a hypothetical concern. Google already tried to implement ad-network hosted websites with "AMP".

Wait, how is decrypting the WASM blob illegal?

I should have chosen my words more carefully, but the blobs with ads will have some sort of DRM on them, which is technically illegal to decrypt and cut out.

Seems the choice would be not to execute the DRM-protected blobs at all.

Removing DRM on something you own for personal use is perfectly legal.

> Removing DRM on something you own for personal use is perfectly legal.

Perhaps some places. In the US, it is perfectly legal to "violate" copyright restrictions for purposes like fair use. But if the data is protected by any kind of security, it is a felony to bypass that security (even for fully legal purposes).[1]

[1] https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...

What does security mean when there is no ad unless it is shepherded out of the blob? Once it's out of the blob, there is no security to bypass.

You don't own the Google Docs service, nor will you own any webpage you are served.

I fail to see how DRM is related to WASM

Decryption is illegal? Lol what?

I think they're implying DRM laws associated with the data-streaming.

I have faith that that's only a matter of time before somebody makes a patch that just does the decryption without fuss.

There’s a place for DNS based ad blocking like Pi-hole or NextDNS and a place for first party ad blocking and element blocking (and even script blocking) using uBlock Origin, NoScript, etc. They’re complementary in certain ways.

How does it help here? They can trivially include ads server-side, pi-hole would see nothing at all.

You can do it, but it’s not done commonly. The most common way ads get onto the page is by including a third party script which is easily blocked.

Today, but this entire discussion is about how things will work tomorrow.

It would be easy to implement server-side rendering, but it carries significant cost in processing time and networking. If they can block all adblocking browser extensions by abusing WASM, the cost of server-side rendering will outweigh the 0.0001% of people that have a pihole set up.

A proxy can do very little to actually block ads compared to what a web browser can do. Web browser _is_ the right place, or at least it is the only place where you can actually do something intelligent to block ads. For example, if you are blocking ads at a proxy, it is trivial for site owners to detect it and then your filtering proxy can literally do nothing to compensate. A huge chunk of all the filters in adblocking lists are basically to defeat anti-adblocking functionality...

DNS over HTTPS and, eventually, certificate pinning in the WASM-based DoH client running inside your browser will render your Pi Hole useless. It'll all just be opaque TLS to your network gear. Network operators who legitimately need to control traffic on their networks are lumped in with human rights-violating nation states. That includes you on your network.

Can you substantiate any of that? DoH is a feature of the browser that can be configured or disabled. Firefox even disabled DoH automatically if it detects you are using a custom DNS server which blocks "potentially malicious content"[1].

[1] https://support.mozilla.org/en-US/kb/firefox-dns-over-https

I'm not talking about the browser doing the name resolution. I'm talking about the opaque binary running inside the browser doing name resolution (either by way of DoH with a pinned certificate, or a custom name resolution protocol running over TLS). You won't get a say in what that opaque binary does (w/o modifying it).

Is anybody doing this now? I doubt it. Will somebody do it? Yeah. Definitely.

When the "browser" is an embedded device (like Google Chromecast devices hard-coded to use 8.8.8.8 for DNS) you'll have no configurability there either.

Can you target "opaque binary blobs of code" with a pie-hole?