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

[SecureContext] - throw or hide

From: Jonathan Watt <jwatt@jwatt.org>
Date: Fri, 18 Mar 2016 16:01:07 +0000
To: public-script-coord@w3.org
Message-ID: <56EC2643.4040502@jwatt.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.


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

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