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

Re: [SecureContext] - throw or hide

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 21 Mar 2016 09:53:15 +0100
Message-ID: <CADnb78h8+00f8PERAZpK_9m7wmevUyqSfemAud_g0P9hKJqyGQ@mail.gmail.com>
To: Jonathan Watt <jwatt@jwatt.org>, Richard Barnes <rbarnes@mozilla.com>, Martin Thomson <mt@mozilla.com>
Cc: public-script-coord <public-script-coord@w3.org>
On Fri, Mar 18, 2016 at 5:01 PM, Jonathan Watt <jwatt@jwatt.org> 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]. Notet
> 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

I think it's mostly Richard and Martin that favor tying this to exposure.

I think that only works well for new APIs. We'd then still need
something for legacy APIs we want to limit to secure contexts (maybe
just prose).

I tend to think we should just do whatever is least complicated, since
if the goal to remove insecure HTTP is a serious one, it doesn't
matter long term what we do here. We just need to make HTTPS as
attractive as we can. Whether that is through exposing more APIs or
throwing for less, doesn't really matter I think.

Received on Monday, 21 March 2016 08:53:41 UTC

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