And if requests are blocked then content publishers can very easily detect ad-blockers and intentionally degrade the user-experience or add nag screens that aren't part of the usual ad network code. If it's an SPA then it'd be almost impossible to untangle easily when the site's developers can add their "is-adblock-detected?" checks anywhere in their SPA codebase and mess with the UX at-will.

Ok, so of all the replies here, this is the first I've read that's actually raised a really good point. Simply blocking requests will make ad block detection easier for Websites. Then again, this seems to be pretty prevalent already (as in lots of sites I visit already detect this).

Most adblocking scripts I’ve seen work by detecting if an ad loaded into its ad-placeholder. If you disable JavaScript completely then you don’t get the nag-screen. Some variants use CSS to show the nag screen by default and only removes it if it sees the ad loaded fine.

But server-side connection-blocking or request-blocking detection works even when JS is disabled, but it requires a lot of infrastructure and cooperation between publishers, ad-networks, and more - both technical and political/business cooperation.

Eventually in the future, web-browsers will render a page twice: one fully-loaded page, hidden from the user, that the ad code will think is what the user sees, while a network-sandboxed version is shown to the user with the already-loaded ad images replaced with white boxes or so. The client scripts can’t tell the ads haven’t loaded and even if they did they can’t phone-home to snitch on the user, while the browser still made those HTTP requests for the ads so the ad-network is satisfied it made an impression.

Perhaps we could get fake ad-loading working without wasting downstream bandwidth by spoofing the IP source address field?