W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2016

Re: [SecureContext] - throw or hide

From: Olli Pettay <olli@pettay.fi>
Date: Mon, 21 Mar 2016 16:53:30 +0200
To: Jonathan Watt <jwatt@jwatt.org>, public-script-coord@w3.org
Message-ID: <56F00AEA.6000109@pettay.fi>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC