Only-if-cached

[mnot]

As discussed in #39, it might be possible to bring back the only-if-cached mode if it's restricted to same-origin.

[tyoshino]

@KenjiBaheux said in #39 (comment) that same-origin would be too restrictive. The idea suggested by him that we attach some info to cache entries so that we don't reveal the fact the URL has been accessed by another origin would complicate cache logic much. So, the first step would be restricting it to same-origin only, and then let's hear what developers would say.

[annevk]

@ehsan, thoughts?

Do we want to require mode to be "same-origin" or do we want to enforce it in the same place where we enforce mode, but also support this feature when mode is "cors", but it just happens to be a same-origin fetch?

[ehsan]

krijnhoetmer.nl is currently inaccessible so I can't read the discussion that led to removing only-if-cached. I'm assuming the attack vector there was a privacy leak using this cache mode to see if an arbitrary URL has already been visited.

It's unclear to me what same-origin here means exactly, as @annevk mentioned. Also, if it's about the origin actually being fetched, how is a redirect from same-origin to cross-origin and back to same-origin supposed to be handled?

[annevk]

Yeah, "only-if-cached" would give extremely precise results whether the target URL has been visited at some point by the user.

I think we would not support cached redirects for this feature so that would return a network error. I guess we don't need to require a particular mode then, either the URL is same-origin and in the cache, or it's a network error. The advantage of requiring a particular mode though might be that we can then more easily expand this feature by allowing more modes going forward, that would now just throw when used. Thoughts?

[ehsan]

I have difficulty imagining what modes we'd want to allow this for in the future.

Not supporting cached redirects for this sounds good to me.

[tyoshino]

The advantage of requiring a particular mode though might be that we can then more easily expand this feature by allowing more modes going forward, that would now just throw when used. Thoughts?

+1

Not supporting cached redirects for this sounds good to me.

+1

[annevk]

It seems there is some implementer support for adding this. I will do so unless someone else wants to pick it up.

[ehsan]

https://bugzilla.mozilla.org/show_bug.cgi?id=1272436

[asutherland]

The spec change didn't address the "not supporting cached redirects" decision reached. Should this be accomplished by requiring that redirect mode be set to "error" like the requirement that the request mode be "same-origin"?

Specifically, line 22 of the Request constructor is currently If request's cache mode is "only-if-cached" and request's mode is not "same-origin", then throw a TypeError. but it could be augmented to be: If request's cache mode is "only-if-cached" and request's mode is not "same-origin" and request's redirect mode is not "error", then throw a TypeError.

This shares the advantage with the same-origin strategy that if the constraint is relaxed in the future then existing code will not observe a change in behavior until the code is changed. (And the code can somewhat detect the presence of the constraint or not by whether the request constructor throws.)

[annevk]

So the observable difference would be that if the redirect response and subsequent response are both cached, currently that would return something, whereas with this change that would result in an error?

I guess it's reasonable to require for now, although that does make this feature quite hard to use.

[asutherland]

@annevk I think you proposed the bit about not caching redirects. I'm not sure we actually need it with the choice of requiring mode "same-origin", but mayhemer has keen eyes and and it did seem like an explicit decision that was not explicitly handled or further discussed, so I've brought it up.

As I understand the threat model, the concern was that "only-if-cached" provided an attacker with a foolproof boolean means of identifying whether a given URL was in the cache whereas other means involve timing analysis that are potentially harder to reduce to a boolean.

Ehsan raised the issue of "a redirect from same-origin to cross-origin and back to same-origin supposed to be handled" which indeed seems like a scenario where an attacker could gain some entropy if we returned a value in that case. (Granting that it's a weird scenario since it effectively requires the other-origin server to be in cahoots. But it might be useful for super-cookie hacks where you store entropy in the local http cache states of other origins that can be convinced to generate redirects to your domain somehow, one bit per distinct redirect. That way the entropy would persist for a while even if the user cleared all state for the visited attacker origin.)

But by requiring a request mode of "same-origin", the spec already will cause a network error to occur when the HTTP-redirect fetch step 15 invokes main fetch and main fetch step 11's "same-origin" enforcement fires. (Because the basic fetch case above it will not fire because the current url origin and request's origin are not the same.)

So maybe there's nothing to do or we just want to add more detail to the "only-if-cached" note on request's "cache mode". So (Can only be used when request's mode is "same-origin".) might become (Can only be used when request's mode is "same-origin". Cached redirects within the origin will be followed, but any redirect out of the origin will result in a network error consistent with use of "same-origin".).

[annevk]

Thanks for the detailed reply, saves me some work. I'll go with updating the note.