Don't require Cache API to have a secure context

[aerik]

It seems to only require a secure context due to being bundled with Service Workers, but Service Workers are not required for the cache API to be used or have utility. Firefox does not require them to have a secure context, and the discrepancy results in a note on the MDN page (https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage) and a bug report to Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1026063) which in turn points back to the spec.

Splitting the cache API into it's own spec (#879) would remove the conceptual bundling and reflect the fact that the cache API doesn't need Service Workers.

Further, indexedDB does not require a secure context and has it's own spec (https://w3c.github.io/IndexedDB/) so treating Cache API similarly makes sense.

[wanderview]

Firefox definitely requires a secure context for the cache API.

[aerik]

Ah - thanks. I only went as far as reading the MDN note and trying

after seeing that Chrome doesn't even present window.caches as a valid object

Funny that the MDN page specifically calls out Chrome and Safari.

However, my other points remain.

[asutherland]

The confusion for Firefox is probably due to the interfaces being exposed but throwing; https://bugzilla.mozilla.org/show_bug.cgi?id=1112134 covers attempts to change the interfaces to not be exposed when they're not supported, but there have been complications as a lot of tests break.

From Firefox/Gecko's perspective, if IndexedDB was introduced today it would require SecureContext.

Aside: I assume it's accidental this issue is filed against background-fetch?

[aerik]

@asutherland Re:

From Firefox/Gecko's perspective, if IndexedDB was introduced today it would require SecureContext.

I'm don't know you, so I'm confused: Are you actually speaking on behalf of Firefox/Gecko ?

I don't know why it's against background-fetch - I searched for an issue with the same subject, found none, and created an issue.

Let me add a couple other notes, for background:

1. I'm not sure how exactly having IndexedDB or the Cache API allowed on an HTTP page creates any security concerns - but I would love to learn if they do, perhaps someone can enlighten me?

2. There is absolutely value in allowing IndexedDB and Cache API on HTTP served pages - and many other things, but I understand the security concerns around features that actually send data over the network. I got onto this because I had to disable a client side cache feature for software that is sometimes installed on the local networks of corporations and universities. Setting up HTTPS in those environments can be unwieldy and is not something they all want to tackle. So I wrote conditional code to disable the caching feature, then chased the topic through the Chromium bug report and to the specification.

[EDIT]
Regarding my note number 1 - either there is no security issue, in which case there is no reason to restrict it, or there is a security issue, in which case I would also wonder whether the same issue isn't relevant to localStorage, and I also I would think that one would not simply accept the risks in using IndexedDB.

[EDIT 2]
I read https://w3c.github.io/IndexedDB/#security so I would guess those are the risks? Is the Cache API more vulnerable than IndexedDB for some reason? I understand that reason for service workers requiring a secure context, but I am only discussing the cache api.

[EDIT 3]
Directly related: w3c/webappsec-secure-contexts#60

[youennf]

Should this issue be either closed or moved to service worker spec?

[jakearchibald]

Agreed. This is unrelated to background fetch.