Re: [SecureContext] - throw or hide

On 03/18/2016 06:01 PM, Jonathan Watt wrote:
> 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
>

FWIW, I'm leaning towards hiding, partially because we might want to consider to use hiding approach also in other cases
(like .history API when iframe is used in shadow DOM.)
And also, why to expose non-working APIs to page? The implementation clearly doesn't support the API (in that particular context) if it was throwing 
all the time. But throwing is better than no-op.


-Olli

Received on Monday, 21 March 2016 14:53:59 UTC