Re: [Wpack] On double-hashing (was: Re: About content-based origins)

[Martin Thomson <[e-mail]>]

On Tue, Mar 31, 2020, at 10:34, Devin Mullins wrote:
> > I don't think that a site would be particularly put off by the cost of transferring hashes to the sites that they link to. 32 bytes per user per target isn't that much data to save or transfer. You can then rely on post-facto linkage.
> 
> Good point. This is mitigated by martinthomson/wpack-content#1, yes?

Not really.  The push can include the H(Content) and the site can calculate H(H(C)).  So the truncated hash only really limits the information the client has to include, trading it for more from the server.  Since opening that issue, I'm not convinced that it is worth pursuing for anything other than that trade-off (which is only a maybe-optimization at best).

> But AFAICT, this + //publisher.example/this-is-my-hash is not mitigated by #1. 

Right.  What *might* do that is the fact that a publisher willing to accept *any* bundle ends up being exposed to a broad spectrum of cross site forgery attacks.  It allows an attacker to supplant any script that the site might reference on its own origin.  You might be able to avoid that with a really strong CSP, but I'm not sure that would be a strong guarantee.

But as I mentioned before, there are ways to partition resources such that a site can validate a bundle without taking on that risk.  And signing doesn't help significantly, except to add a signature to the 64+ bytes per user per target cost.

> That said, I guess the solution is that, for 
> anti-fingerprinting, the state transfer request and any previous 
> subresource requests should be considered in different buckets.

One thing that we are seeing in some contexts is not just completely different connections for credentialed vs. uncredentialed requests, but proxying of uncredentialed requests, so that the amount of fingerprinting information is limited.

> The state transfer itself doesn't affect the feasibility of the attack. The 
> unverified bundle can make a fetch to 
> //publisher.example/distributor-id?foo, and even if the Sec-CO request 
> fails, the publisher can join foo with a subsequent credentialled 
> fetch, in order to inform future responses. The UA could consider this 
> ~isomorphic to the linking page making that same fetch to 
> /distributor-id?foo.

Right.  That's where this gets really hairy.  But this all goes to challenging the feasibility of the goal of preventing information transfer across origins.  The fact that this is a content-based origin doesn't change the dynamics at all.  If origins are willing to cooperate in the exchange of information, then I don't know how to prevent that.  It might be possible to make things sufficiently unlinkable, but even for something with protections as restrictive as Tor Browser I doubt that you can prevent transfer.

(That's a challenge, BTW, because I would be very happy to be shown to be wrong.)