This seems more like a functional issue than a security issue.

I was under the impression that the CacheAPI deliberately ignored Cache-Control headers[1].


[1] https://stackoverflow.com/a/35152817/126229

It sounds like this works as expected:

https://github.com/w3c/ServiceWorker/blob/master/explainer.md
"Matching within the cache is similar to the browser cache. Method, URL and vary headers are taken into account, but freshness headers are ignored. Things are only removed from caches when you remove them."

>It sounds like this works as expected:
>https://github.com/w3c/ServiceWorker/blob/master/explainer.md
>"Matching within the cache is similar to the browser cache. Method, URL and vary headers
>are taken into account, but freshness headers are ignored. Things are only removed from
>caches when you remove them."
I haven't looked at whole explainer but the referred part seems to be talking about Cache matching and deletion. But I want to know if adding cache itself is appropriate in this case.

>This seems more like a functional issue than a security issue.
You are most probably right. I think it depends on what's the threat model is. In fact, I started checking Cache-Control because I saw following bug.
https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/#CVE-2018-5131

So I would like to know what other browser's thoughts are on these issues.  

storage-dev@, could you help weigh in on this issue?  Thanks!

This very much sounds like it is working as intended/spec'ed? The mozilla advisory is about a bug that has nothing to do with the cache API afaict.

Either way, https://github.com/w3c/ServiceWorker/issues/ would be the place to bring up questions like this, since there doesn't seem to be anything chrome specific about it.

Not sure why we'd want to prevent a website from storing its own data though. Cache-Control controls the http cache, not the script controlled cache; after all, no need to use headers for that since the site is already fully in control of that through its scripts.

>The mozilla advisory is about a bug that has nothing to do with the cache API
>afaict.
It was an issue of Fetch API, but this bug can bring the same result since cross-origin resources are cachable (Cache can respond to script, CSS, Media resources, Fetch API, etc).

>Either way, https://github.com/w3c/ServiceWorker/issues/ would be the place
>to bring up questions like this, since there doesn't seem to be anything
>chrome specific about it.
Got it! I will wait for Mozilla's response and then file a spec bug accordingly (if needed).

For what its worth, the Mozilla issue is not something that we would consider a Security Bug. Chrome's security guarantees specifically exclude "local" attackers, and attempting to isolate multiple users within a single user profile is a fool's errand.

If we keep this Issue around at all, I think we should change it away from Bug-Security.

I guess the interesting question is indeed what to do about CacheControl headers on opaque responses, as arguably there it was the intention of the server that it shouldn't be stored. For non opaque responses storing the response in the cache API of course is no different than storing it in indexeddb or some other storage mechanism.

I'm not sure why we wouldn't consider the mozilla issue a security bug though? At least from what I understand from the brief description in that security advisory their bug was more or less a violation of the same-origin-policy. I.e. I'm reading "users" as "users of the fetch API", not "users of firefox". So it doesn't seem to have anything to do with "local" attackers/multiple users within a single user profile.

But yes, agree that nothing in this particular issue seems like a security issue, and the correct place to discuss this would be on the spec side.

Re #9: "At least from what I understand from the brief description in that security advisory their bug was more or less a violation of the same-origin-policy."

Nah. Here's what it says: "This can result in previously stored, locally cached data of a website being accessible to users if they share a common profile while browsing."

Re #10: Yes? Quoting myself "I'm reading "users" as "users of the fetch API", not "users of firefox"." So I interpret that to read that different origins calling fetch() for the same resource could in some situations result in returning the same response that should not have been cached/shared.
But anyway, it doesn't really matter what that firefox bug was about since it doesn't have anything to do with this issue (if there even is an issue here) anyway.

Based on #8 and #9, remove Bug-security label. 

Able to reproduce this issue from M-60. i.e; After step-4 alert message is seen. Hence considering this issue as Non-Regression and marking as Untriaged.

Please remove if not the case

I filed https://github.com/w3c/ServiceWorker/issues/1299 to track the concern in #9 about opaque responses.