Why does CacheStorage have [SecureContext] but not Cache?

[inexorabletash]

CC: @mikewest

The global caches attributes have [SecureContext] (link) which makes sense - hide the entry points except in secure contexts.

But the interfaces are inconsistent. CacheStorage has [SecureContext] but Cache does not. This seems inconsistent.

Is this just an oversight in applying a fix for #687 ?

[mkruisselbrink]

That does look a bit inconsistent indeed. I wonder what would be preferred though with regard to SecureContext on interfaces. For security it doesn't really matter if these interfaces have [SecureContext] or not, as the only way to get access to instances that do things is via methods that are SecureContext only. But maybe for consistency and/or feature detection it might make sense to hide all the interfaces as well? Not sure. Similarly ServiceWorker and ServiceWorkerRegistration currently don't have [SecureContext] but ServiceWorkerContainer does...

[inexorabletash]

I can see wanting [SecureContext] on the interface if there's a constructor and therefore we should be consistent for types without constructors. Although not a technical requirement (so maybe not in http://heycam.github.io/webidl/#SecureContext) we should probably be consistent in the platform and document it somewhere. Hence pestering @mikewest :)

So yeah, what @mkruisselbrink said.

[mikewest]

If the interface doesn't do anything at all without being inside a secure context, then yeah, mark it up with SecureContext. If there's value to your feature to being exposed, then do it that way. We don't really have rigid rules yet; we'll have to learn together what makes sense.

[mikewest]

I'd personally suggest erring on the side of putting the attribute on too many things; we can always remove it later if it turned out to be overzealous. :)

[jakearchibald]

Yeah this is just an oversight I think

[jungkees]

I can see wanting [SecureContext] on the interface if there's a constructor and therefore we should be consistent for types without constructors.

The reason was exactly that. I.e., the Cache, ServiceWorker and ServiceWorkerRegistration don't have a constructor and can be gotten only from the methods exposed with [SecureContext].

We don't really have rigid rules yet; we'll have to learn together what makes sense.

Are there any other such cases yet? I can do either way but would like to have some good rationale.

[annevk]

You can also get them from the global. Since that doesn't enable anything useful, you should prevent exposure there with [SecureContext].

[jungkees]

They can't be gotten from a non-secure context's global, either. But it seems all agreed on putting it. I'll address it in that way.

[annevk]

They can, e.g., window.Cache. You need [SecureContext] to prevent that.

[jungkees]

Ah.. didn't know it's exposed even without a constructor.