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