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

[Devin Mullins <[e-mail]>]

On Sun, Mar 29, 2020 at 9:28 PM Martin Thomson <[e-mail]> wrote:

> Separately, I'm about your stated desire to provide diversification of
> content for the purposes of experimentation here.  It seems to be in direct
> tension with this privacy requirement.  I'm interested in knowing how you
> might choose to trade the two off; I don't have any reference here as we
> haven't spent a whole lot of time looking at this specific problem.
>

 If you haven't seen it yet, my longer email has one proposal, but I
haven't thought about it too much; it may have holes. This is an area I
need to learn a lot more about.


> This particular threat model is a really difficult one for me to get my
> head around properly, I have to admit.
>

Only my guess, but it seems to be at least as much about re-balancing the
costs/benefits of bad actions as it is about blocking them (i.e. making the
costs infinite).

I don't mean to imply stake in any particular threat model; I think UA
vendors are in a better position to do so. (I will do my best to help
inform that decision with feasibility estimates for one use case.) Mostly
I'm trying to ensure there is rough consensus on this part. As a consumer
of the signed exchanges spec, I'm obviously interested in a successor spec
that has properties that most or all are satisfied with.

Let's say that we had a system that was able to detect and maybe block
> information transfer in URL or Referer[2].  Is the contention that this
> system would be unable to detect this sort of information transfer when it
> was general purpose content?
>

I don't know. It seems like there'd be a lot of ways to evade detection and
hide things in the URL that don't even require server changes. (For
example, many servers don't validate the URL slug, so it could be
steganographically altered and then inspected client-side.)

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?

But AFAICT, this + //publisher.example/this-is-my-hash is not mitigated by
#1. 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. 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.