- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Fri, 18 Mar 2016 16:01:07 +0000
- To: public-script-coord@w3.org
The Secure Contexts spec[1] defines a [SecureContext] WebIDL extended attribute that is in the process of being added to WebIDL 2[2]. The main sticking point is whether accessing things marked as [SecureContext] in a non-secure context should throw a 'SecurityError', or whether those things should not be exposed. My personal view is that exposure of API is an indication of whether an implementation supports that API, not whether you are using it correctly (i.e. using it in a secure context in this case), so it would be weird to hide the API in non-secure contexts. I lean a bit more towards throwing. The main issue with throwing seems to be with attribute getters, because enumerating an object could throw. That said, there is Window.isSecureContext and WorkerGlobalScope.isSecureContext which can be used to determine whether a [SecureContext] attribute can be accessed (or consumers can use try-catch). There's also a bunch of discussion on the WebIDL 2 pull request[2]. Note that the discussion up to this point assumed that secure context status could change over the lifetime of the global, but that's no longer the case (since the document.domain requirement was removed from the Secure Contexts specification). I'd be interested to hear from others to try and figure out whether there is any consensus on this issue. Jonathan 1. https://w3c.github.io/webappsec-secure-contexts/ 2. https://github.com/heycam/webidl/pull/65
Received on Friday, 18 March 2016 16:01:42 UTC