When should [SecureContext] be used and why?

[slightlyoff]

Via an issue from @sleevi and @mikewest, it seems we should have uniform advice for spec authors (and an IDL recipe) for how to handle cases where an API is only partially usable, as is the case for Secure Context-only APIs.

@mikewest notes that the platform's behavior is not uniform today. We should catalog and attempt to drive uniformity.

/cc @domenic @torgo

[annevk]

Didn't we already reach agreement some time ago on hiding for new APIs with "whatever works" for old APIs? That took quite a long time to get to and landed in IDL and such...

[mikewest]

Right, I think this is basically already done: see the (really quite long) discussion in whatwg/webidl#65.

In a nutshell, WebIDL defines a [SecureContext] attribute that can be applied to various interfaces, methods, etc. The secure contexts spec notes that folks should use that attribute when appropriate, or throw if they can't: https://w3c.github.io/webappsec-secure-contexts/#new.

Reading over that section again, I think it can be written more clearly; I'll take a pass on it tomorrow to emphasize that hiding the interface is the right thing to do for new features, and that folks should fall back on throwing only in cases where non-secure contexts implies only partial support (I don't know if there are actually any examples of that for upcoming features?).

With regard to non-uniformity:

• No one has implemented the [SecureContexts] attribute yet. I have half a patch put together for Chrome that I'll try to clean up this week, and I believe @jwatt is working on the same for Firefox. So, we're uniformly not doing what the spec suggests we should. :)
• WebCrypto is an outlier, as Chrome restricts that to HTTPS origins, but doesn't do the full set of checks that we ended up codifying in Secure Contexts. There's ongoing discussion about whether we ought to align its behavior with other APIs; I think we should, we just need to ensure that we don't break backwards compatibility to too great an extent while doing so.

[slightlyoff]

So it looks like [SecureContexts] is implemented in Chrome today.

@mikewest, @sleevi: did we unify these behaviors?

[sleevi]

No, WebCrypto has not been unified in a way to use [SecureContexts] - that would be an Intent to Deprecate

[slightlyoff]

Is that something we're looking to do?

[sleevi]

@slightlyoff
Is that something we (Chrome) think is right? Yes, it seems so.
Is that something we (Chrome engineers) have prioritized relative to other efforts and time commitments to draw the necessary consensus among user agents and site authors? No.

[sleevi]

@slightlyoff To be clear, Chrome supports the guidance recommended (using [SecureContext] - as @mikewest mentioned in #32 (comment) and as you found), but we simply have legacy outliers that would need to be brought into the fold as part of a consensus process. But I don't think examples of divergence is itself a reason to block formalizing and normalizing the [SecureContext] advice for new stuff.

[slightlyoff]

Great. Thanks for the context!

[mikewest]

Note that the WebCrypto WG did indeed move to [SecureContext] for things like navigator.crypto.subtle as part of their transition to CR/PR: https://w3c.github.io/webcrypto/Overview.html#crypto-interface. The existing checks are on my list of Things to Deprecate When I Have Time.

For the design principles document y'all are working on, [SecureContext] for interesting (all?) new features seems like the right recommendation.

[annevk]

Make it all! Let's get this HTTPS cemented.

[travisleithead]

Closing, as this seems to have been resolved!

[annevk]

@travisleithead euhm, the design principles document still says nothing about it?

[travisleithead]

Yes, we should provide guidance as noted in #32 (comment). The title and previous content threw me off...

[torgo]

@dbaron yes the doc should say something about when you should use secure contexts. We probably don't want it on very fine-grained additions. We want to put it on big new things. Where do we draw the line? Bunch of stuff we can agree on and should write down.

@hadleybeeman bunch of stuff on this in the security questionnaire

[hadleybeeman]

Worth a look... Long-term, we should make sure these messages are joined up.

https://www.w3.org/TR/security-privacy-questionnaire/#secure-contexts

[dbaron]

Should probably also mention that other entry points where we frequently add new features should have the ability to limit to secure contexts. For example, CSS should have the ability to say that certain new properties are limited to secure contexts.

[torgo]

#89

[mikewest]

The patch that actually landed (15e5c17) is somewhat watered-down from the PR (#75) we'd been discussing at length, pointing to yesterday's TAG discussion as simply hitting an impasse. The face-to-face minutes noted read as follows:

Reviewing Pros/Cons of existing PR.

Can't seem to get consensus on whether using SecureContext as a carrot for HTTPS is something everyone in the room can get behind.

Is there any more detail you could provide around that discussion? It would be helpful to know what points y'all found (un)convincing, as that might help us focus discussions in the future.