W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2016

Re: Secure context requirement?

From: Eric Roman <ericroman@google.com>
Date: Fri, 22 Apr 2016 13:09:46 -0700
Message-ID: <CAFswn4m4FTEd_z92fVGUDiJzMz7k37dOwuC-K6oFGs-YTR7U1Q@mail.gmail.com>
To: Charles Engelke <w3c@engelke.com>
Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Apr 22, 2016 at 12:55 PM, Eric Roman <ericroman@google.com> wrote:

> tl;dr: Chrome throws a NotSupportedError.
>
> Secure origins were discussed by the WG (largely in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972), however the
> current spec does not restrict implementations to secure origins, nor give
> guidance to implementations that do.
>
> Other specs, such as Encrypted Media, do make an attempt to describe a
> preference for secure origins and how that works. Also more description is
> available in the Secure Contexts spec.
>
> As far as I know, Chrome is currently the only browser that restricts
> WebCrypto to secure origins. (Haven't tested Microsoft Edge, perhaps it
> does too).
>

(Well Opera too, and Chromium derived browsers)

In Chrome the particular error used is *NotSupportedError*.
>
> Why NotSupportedError? I don't have a solid standards answer for this, but
> here is my thinking:
>
> Comment #3 of bug 25972 models this as an implementation-specific choice,
> analogous to a NotSupportedError for an implementation that chooses not to
> implement a particular algorithm. This was largely the inspiration for
> choosing NotSupportedError. Applications already need to test for
> NotSupportedError in case a particular key size or algorithm is not
> supported, and in some sense access from a non-secure origin could be
> though of similarly.
>
> Looking at other choices for exception: The WebCrypto Exceptions section
> (14.4.) lists other candidates: InvalidAccessError, and OperationError. If
> we understand that the exceptions listed in section 14.4 are the ONLY
> exceptions that an implementation may throw (again I am not super clear
> from the phrasing, but that is how I interpreted it), then we are limited
> to just this selection of error types.
>
> InvalidAccessError is currently described in terms of a keyed operation so
> as described has some issues. And similarly OperationError is more of an
> internal error to the algorithm, and also feels like a poor choice.
>
> The Secure Contexts spec (
> https://w3c.github.io/webappsec-secure-contexts/#new) mentions rejecting
> a promise with a *SecurityError* in section "7.3. Restricting New
> Features" -- however this is non-normative. Also based on my understanding
> of WebCrypto's Exceptions section 14.4, an implementation is not expected
> to throw a SecurityError anyway.
>
> On Fri, Apr 22, 2016 at 11:59 AM, Charles Engelke <w3c@engelke.com> wrote:
>
>> Oops, no, Firefox isn't enforcing the restriction (at least on Linux).
>> I don't have a Windows machine close to hand to check Edge, but I
>> believe it required a secure context when I tried it last.
>>
>> Charlie
>>
>> On Fri, Apr 22, 2016 at 2:52 PM, Charles Engelke <w3c@engelke.com> wrote:
>> > From what I've seen, both Firefox and Edge enforce the same
>> > restriction as Chrome.
>> >
>> > Charlie
>> >
>> > On Fri, Apr 22, 2016 at 2:50 PM, Mark Watson <watsonm@netflix.com>
>> wrote:
>> >> IIRC, it was never agreed in the Working Group that WebCrypto must be
>> >> restricted to secure contexts. Chrome have chosen to do so, but I
>> believe
>> >> this restriction does not apply in other browsers.
>> >>
>> >> ...Mark
>>
>>
>
Received on Friday, 22 April 2016 20:10:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 22 April 2016 20:10:14 UTC