[jlokier]

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.

[dlubarov]

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.)

[jlokier]

In the scenario, the third party is the advertising broker, Google, who are also the entity serving the signed bundle.

[geofft]

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.

[joshuamorton]

This would be like opera turbo (and similar from other browsers), but with fewer privacy concerns, so it's not even new design space.

[dlubarov]

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?