Using [SecureContext] when it's implied?

[beverloo]

In some situations [SecureContext] is implied through an object's exposure. Concretely, interfaces only exposed in Service Workers are per definition limited to secure contexts because Service Workers themselves are. Should we still specify [SecureContext] on such interfaces? It's clear, but redundant.

This came up in w3c/push-api#284 for the PushEvent and PushSubscriptionChangeEvent interfaces.

[tobie]

So after discussing this on irc a bit, here are a couple of thoughts:

1. The exposure set of an API isn't static. It evolves over time. A number of interfaces (e.g. fetch, caches, etc.) started their lives in the SW global scope, only to end up exposed in Window too. So you can't assume that an API will remain in a secure context just by specifying it for that context at first.
2. If WebIDL stated something along the lines of "interfaces who have SW in their exposure set can only be exposed in secure contexts", then it would prevent adding to SW apis that were previously in the global/worker scopes only. Adding those to SW would make them secure only everywhere as a side effect.
3. All of this would be a lot more obvious if [SecureContext] was flipped over to be [AllowInNonSecureContext] instead. Doing this would cause quite a bit of downstream churn, but it could be attempted at the same time as we fix Investigate removing [PrimaryGlobal] and requiring [Exposed] #365 (which has similar issues).
4. All in all, I think your best move forward is to either (a) mark all SW interfaces as [SecureContext] or (b) continue assessing the security and privacy risks of each API in SW and mark them as such. From our conversation on irc, it seems (a) is your best bet.

I've added a note to #365 about this.

Do you think this warrants a note in the spec in the meantime? E.g.:

Although APIs exposed only in SW are [SC] by default,
such APIs may later migrate to other global scopes which aren't default secure contexts.
Editors are therefore encouraged to mark security or privacy sensitive APIs as [SC],
even if they're initially only exposed in SW. 

[annevk]

security or privacy sensitive APIs

Mozilla would like as many new APIs as possible to be marked as such, so I'd rather this not go into specifics. Might give people the wrong idea.

[annevk]

To answer OP, you don't have to specify it on partial interfaces per the current text (though it's allowed), so closing this.

(I did spot a problem with partial interfaces though and filed #877 on that.)