Subject: Re: [httpwg/http-extensions] Cache digest and scoping (#216)

From: HTTP issue updates <[email-masked]>
Date: Thu, 30 Mar 2017 13:56:36 -0700

@tombergan 
> Cache digests should not worsen the privacy problem compared to current H2. If cache digests are reducible to cookies, and managed as cookies, then we can argue that the privacy problem hasn't worsened.

I agree that cache digests should not worsen the privacy problem.

However, I will also argue that cache digests _in current form_ does not worsen the privacy problem since it is something that can be and is implemented using existing technology (stated below), and that there is no need to try to adopt the cookie model which would have issues as @mnot points out.

Cache digest can be (and already is) implemented using Service Worker. The only differences between a Service Worker-based implementation and the HTTP/2 frame-based implementation is that the frame-based implementation is more efficient (in HTTP/2 frame-based approach, the digest needs to be sent only once per connection, whereas for Service Worker-based or cookie-based implementation, a client needs to send a digest per every request), and that the digest more accurately reflects the state of the cache (Service Worker cache is located in front of the web browser cache, so a digest of Service Worker cache does not reflect what exists in the browser's cache).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/216#issuecomment-290542538

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 30 Mar 2017 17:26:36 -0700

We completely agree. I was making a writing suggestion: if you can write the RFC in such a way that it's obvious that the proposed cache digest frame is equivalent to cookies, then you can more easily argue that you're not introducing any privacy concerns. [1] My specific suggestion is for the browser to create a "cookie" each time it caches a response, where that cookie is treated like any other cookie with a few small changes (see the list of six items in my prior comment).

Rephrasing the explanation in terms of cookies also makes it obvious where privacy holes may arise. For example, if a browser supports "normal" and "incognito" modes that use different cookie jars but the same cache, the browser needs to attach the "cache cookies" to the appropriate cookie jar rather than to the cache, otherwise there may be information leakage across browser modes.

Does that sound reasonable? Contrast this to [Section 4](https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-01#section-4), which is currently kind of hand-wavy.

[1] Even if you rephrase the explanation in terms of cookies, privacy concerns are still likely to arise since the cookies are created automatically by the browser rather than manually by the server, but that is a separate issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/216#issuecomment-290582254

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 31 Mar 2017 04:57:43 -0700

@tombergan 
> I realize cookies are kind of weird because they don't exactly follow the same-origin policy. Maybe a better analogy would be local storage?

Thank you for the suggestion.

I agree that it would be worthwhile to suggest similarity to existing mechanism in Security Considerations. Having that would help the readers understand the issues.

I assume that the existing mechanism we would refer to to be Service Worker (and its cache). That is natural since we are likely to have an appendix explaining how to implement Cache Digests using Service Workers (see #256).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/216#issuecomment-290693285