- From: Eric Roman <ericroman@google.com>
- Date: Fri, 22 Apr 2016 12:55:21 -0700
- To: Charles Engelke <w3c@engelke.com>
- Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAFswn4k0kzoOy6wLjBhmxRbsUtyc81L4+v3+rGWNrFCBuvQ2sA@mail.gmail.com>
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). 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 19:55:49 UTC