Re: [heycam/webidl] Using [SecureContext] when it's implied? (#420)

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 https://github.com/heycam/webidl/issues/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 https://github.com/heycam/webidl/issues/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 sopes which aren't defautl secure contexts.
Editors are therefore encouraged to mark security or privacy sensitive APIs as [SC],
even if they're initially only exposed in SW. 
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/420#issuecomment-323809053