Cache mode: security review

[annevk]

It seems to some extent the new cache mode feature can be emulated using timing information. However, it is unclear whether that is sufficient justification to expose the information with more certainty.

Sharing whether the user has an entry in its HTTP cache does allow for fingerprinting and figuring out what sites a user visits. (Note that CORS doesn't really change this as far as I can tell.)

[mfalken]

Cache control options are tracked in https://crbug.com/453190

[igrigorik]

Have we made any progress on this one?

FWIW, I agree with @mnot's assessment in w3c/ServiceWorker#585 (comment).

A slight tangent, but related to this issue: I hear a lot of requests from developers for being able to (a) observe if fetched resources came from HTTP cache, and (b) the size of the fetched resources. The primary use cases are typically for monitoring and enforcing data budgets, bandwidth-estimation, and diagnostics (e.g. detect resources that were, for whatever reason, delivered without compression; estimating and improving cache hit rates, etc).

To address the above both Nav and Resource Timing added {transfer, encodedBody, decodedBody}size (see RT), but implementations are blocked on similar concerns as discussed here.

I'd love to come to a resolution on this.

[KenjiBaheux]

I think same-origin is too restrictive.
Would it make sense if we were to allow probing for the assets an origin was already aware of?

• assets that were potentially* placed in the cache by the origin in the past

In other words, if there is nothing new to learn from specific requests, it should be fine to allow them.

*effectively placed or merely requested.

[annevk]

@igrigorik came from is #40.

[annevk]

As for progress, no security folks have chimed in so no progress.

[mikewest]

Hi! My initial reaction is that is a pretty terrible idea. I'm willing to be convinced otherwise, but I don't think that the assumptions being made here hold.

In short, timing attacks are different in kind from the kinds of attacks this API would enable. That is, there is a qualitative difference between a 100% effective API that would enable rapid brute-forcing of recently visited URLs/GET parameters, and a mostly effective hack that gave a certain probability of success with a large amount of slop and network traffic (and associated latency).

[annevk]

@mikewest do you mean any cache mode would be bad to expose to JavaScript? Or only certain modes?

[annevk]

Per http://krijnhoetmer.nl/irc-logs/whatwg/20151105#l-310 I should remove "only-if-cached" and keep the rest. No origin restrictions for now. This still allows for timing attacks and might make some of them more precise, but that was not considered problematic.

[mnot]

@mikewest Is it necessary to get rid of only-if-cached completely, or only make it same-origin?

[annevk]

I suspect same-origin might be okay, let's track that as a new issue and address it once implementations have shipped the current cache feature. That might already be tricky enough as-is.