Re: Submitted new I-D: Cache Digests for HTTP/2

[Kazuho Oku <[e-mail]>]

2016-01-11 19:42 GMT+09:00 Chris Bentzel <[e-mail]>:
> The draft does cover some privacy concerns (such as clearing the digest when
> cookies are cleared).
>
> One concern not covered is how to deal with cases where a client may have
> cached content from an origin with a mix of cookies. For example, if a user
> has enabled third-party cookie blocking in a browser and has visited an
> origin in both a first-party and third-party context there may be a mix of
> cached content with a session identifier cookie and no cookie.
>
> If the user re-visits that origin in a first-party context, the digest may
> reveal content retrieved in a third-party context.

Thank you for raising the concern.

My understanding is that it is already possible to track users that
reject third-party cookies using cache-based fingerprint.  The change
in this draft that such tracking becomes passive.

> One option is to treat cached content as if there is an implicit Vary:
> Cookie header and only include in the digest if it matches. The draft
> already requires only including fresh cached entries in the digest so a
> selection process for cached entries already will need to exist.

Interesting.

IMO, web browsers configured to reject third-party cookies should
ideally set implicit `Vary: host` for every entry it caches.  Doing so
not only solves passive fingerprinting (which becomes possible with
this draft), but also will prevent active fingerprinting as well
(which is already possible).

If such change cannot be made within the web browsers, then we should
look for a workaround...

> On Mon, Jan 11, 2016 at 3:16 AM, Cory Benfield <[e-mail]> wrote:
>>
>>
>> > On 10 Jan 2016, at 17:11, Alcides Viamontes E <[e-mail]>
>> > wrote:
>> >
>> > Can we embed the cache digest in a header?
>> > ——————————————————————————————
>> >
>>
>> On a personal level I am extremely nervous about shoving 24kB of data into
>> a header value. The practice of doing this for Kerberos tokens already
>> caused us to require the CONTINUATION frame unpleasantness in RFC 7540.
>> Generally speaking it seems like smuggling long strings in HTTP headers is a
>> bit of an anti-pattern, and given that HTTP/2 gives us much nicer methods of
>> transporting this kind of data it seems a shame not to use them.
>>
>> Cory
>>
>



-- 
Kazuho Oku