Also domain or URL blocking isn't the only thing you can do. You can also ban scripts from the page, or monkey patch JavaScript to change behavior that ad networks rely on. And you can also do cosmetic ads blocking, to hide elements from the page, via user stylesheets.
It's no wonder that Google is deprecating the APIs uBlock Origin relies on, in Manifest v3 ;-)
Fact of the matter is Google is now engaged in war against ad-blocking.
Again I don't get it. If a site wants to they can serve ads inline right now, without making client side requests to ad servers and ublock can't do anything about it. And first party cookies don't do any good for tracking so it doesn't matter if they come in the bundle. The ad trackers want to see where you go across multiple sites and there's no simple way to do that w/out 3rd party cookies (although you can use browser fingerprinting)
Browsers like Safari are increasingly enabling privacy features that, among other techniques, block third party cookies by default. So this could be Google’s way of reacting to this change.
I don't see how. Web bundles don't affect whether a cookie is considered third-party or not. Either the content is provided and signed by the actual website, which cannot place cookies for the advertiser's domain, or it's provided and signed by the advertiser, at which point it would be subject to blocking just like normal web traffic from the advertiser. Is this any different with bundles?
The third-party cookie will be blocked, but when both sites are served via the same proxy server, over the same TLS/QUIC connection, the third-party can get similar tracking information they would have had with a cookie, without needing a cookie. It's not exact, but it's good enough for inference.
Assuming that the third party in this scenario is distinct from the party serving the bundle, they wouldn't be involved in the TLS/QUIC connection, right?
So it seems like a third party wouldn't even know that their resource was delivered, unless the party delivering the bundle notified them, or their script makes a separate request to their own server. (And those are options already, so AFAIK bundles wouldn't give third parties any new capabilities.)
Yeah, I think this is a compelling argument, but also, it's a decent argument against using Google Search itself, is it not? They can almost certainly already correlate a click on a search result on google.com with the Google Ads subrequest from the target page.
And, on the other hand, the fact that web bundles are signed and can be delivered by any origin means that a privacy-focused user agent could try to fetch the bundle indirectly via some privacy-preserving CDN - essentially DoH for web bundles. If you are about to load a site via some known web-bundle host (like https://www.google.com/amp/ probably), try sending a request to some Cloudflare Workers setup or something first.
Hm okay, but then wouldn't Google get the same fingerprinting data (IP, headers, TLS params) in either scenario, whether they're serving a bundle or just a script?
Normally, if you load a page from Party A which pulls in content from Party B, it's hard for them to correlate who you are because they have separate cookies. That's not a problem if they're served from the same host, probably even on the same QUIC connection.
In Firefox, uBO can block first party domains: https://github.com/uBlockOrigin/uBlock-issues/issues/780
Also domain or URL blocking isn't the only thing you can do. You can also ban scripts from the page, or monkey patch JavaScript to change behavior that ad networks rely on. And you can also do cosmetic ads blocking, to hide elements from the page, via user stylesheets.
It's no wonder that Google is deprecating the APIs uBlock Origin relies on, in Manifest v3 ;-)
Fact of the matter is Google is now engaged in war against ad-blocking.