Subject: Clearing cache digests

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 08:31:53 +0200

The draft says:

   As a result, clients MUST mitigate for this threat when the user
   attempts to remove identifiers (e.g., "clearing cookies").  This
   could be achieved in a number of ways; for example: by clearing the
   cache, by changing one or both of N and P, or by adding new,
   synthetic entries to the digest to change its contents.

   TODO: discuss how effective the suggested mitigations actually would
   be.

Except for "clearing the cache", my initial impression is that the answer
to "how effective" is "not very", except for very naive uses of the cache
as an identifier.

Consider that the general structure of this mechanism is that the client
gives the server an oracle which answers the question "do you have document
X" with false positive rate 2^-P. This implies that the server can use the
cache as a cookie B of length N bits by creating N resources R_1, R_1 ...
R_N and then to store the cookie:

- If B_i == 1 then store R_i
- Otherwise don't

You then query for the cookie in the cache the same way. This has an
epsilon error probability but you can correct for that by storing N + delta
bits and using an error correcting code.

So, my claim is that any mechanism that retains the information in the
cache digest will allow for tracking, even if you change the way it is
encoded (e.g., changing N, P).

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Jul 2016 10:29:42 +0200

Why are we concerned about this at all?  Can't we put this stuff into
the same bucket as cookies?

On 18 July 2016 at 08:31, Eric Rescorla <[email-masked]> wrote:
> Except for "clearing the cache", my initial impression is that the answer to
> "how effective" is "not very", except for very naive uses of the cache as an
> identifier.
>
> You then query for the cookie in the cache the same way. This has an epsilon
> error probability but you can correct for that by storing N + delta bits and
> using an error correcting code.
>
> So, my claim is that any mechanism that retains the information in the cache
> digest will allow for tracking, even if you change the way it is encoded
> (e.g., changing N, P).
>
> -Ekr
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 10:44:04 +0200

Yes, that seems like the obvious answer.

-Ekr

On Mon, Jul 18, 2016 at 10:29 AM, Martin Thomson <[email-masked]>
wrote:

> epsilon
> cache

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Jul 2016 08:51:16 +0000

If you clear the cache, it's simple.  If you want to keep your cache intact but only discard tracking properties, that's more complicated.  At that point, you either have to tag resources in the cache so that they're excluded from the digest (pretending you don't have the resource), or change properties such that the server can't identify the resources from before.  I understand EKR's point to be that the latter option doesn't really work, because the server can necessarily recalculate around any change the client can make.

Are you proposing that the cache be cleared whenever cookies are cleared?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, July 18, 2016 10:30 AM
To: Eric Rescorla <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Clearing cache digests

Why are we concerned about this at all?  Can't we put this stuff into the same bucket as cookies?

On 18 July 2016 at 08:31, Eric Rescorla <[email-masked]> wrote:
> Except for "clearing the cache", my initial impression is that the 
> answer to "how effective" is "not very", except for very naive uses of 
> the cache as an identifier.
>
> Consider that the general structure of this mechanism is that the 
> client gives the server an oracle which answers the question "do you 
> have document X" with false positive rate 2^-P. This implies that the 
> server can use the cache as a cookie B of length N bits by creating N resources R_1, R_1 ...
> epsilon error probability but you can correct for that by storing N + 
> delta bits and using an error correcting code.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Jul 2016 10:52:40 +0200

> Are you proposing that the cache be cleared whenever cookies are cleared?

It probably should be.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2016 10:57:38 +0200

> On 18 Jul 2016, at 10:52 AM, Martin Thomson <[email-masked]> wrote:
> 

SGTM.

--
Mark Nottingham   https://www.mnot.net/

---

From: Mike West <[email-masked]>
Date: Mon, 18 Jul 2016 10:58:20 +0200

> the same bucket as cookies?

Chrome currently separates the actions of clearing cookies and cache. I
believe Firefox does the same.

If we ship this feature, I think we'd need to start treating them as the
same thing, clearing the one along with the other.

+Martin, who was looking into this for Chrome.

-mike

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 18 Jul 2016 18:07:25 +0900

>> Are you proposing that the cache be cleared whenever cookies are cleared?

Should this be limited to cache digests?

Even without cache digests, it is possible to track users by setting
different etags. Considering that, it might be better to recommend
clearing the cache when the user clears the cookie regardless of if
cache-digests is used.

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Jul 2016 11:09:34 +0200

> Should this be limited to cache digests?

No.  You are right that this is a more general problem.