- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Jun 2014 18:51:40 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 --- Comment #3 from Ryan Sleevi <sleevi@google.com> --- (In reply to Boris Zbarsky from comment #1) > Some implementations want to do this. Not all. > Right. And we want to find a suitable way of expressing that policy. > > Secure origin is defined by https://w3c.github.io/webappsec/specs/mixedcontent/ > > Fwiw, this doesn't match Blink's definition at > <http://www.chromium.org/Home/chromium-security/security-faq#TOC-Which- > origins-are-secure-> in various ways. Are they willing to change their > behavior? Should this spec change? As Mike notes, the spec is super-drafty. There's also a clear set of implementation-specific secure origin considerations. For example, Netflix described a scenario where resources were loaded over HTTP, except the scripts themselves were baked into the device. Does that represent a secure origin? (Maybe, maybe not - depends on if the HTTP origin is allowed to inject non-baked scripts into the execution context) What about situations where a UA (device) may communicate with a server using an alternatively 'comparable' secure means. For example, consider device with a host of http://foo.local, that communicates with a series of other devices at http://bar.local and http://baz.local. The device-specific implementation establishes a secure tunnel between foo.local and bar/baz, using 'out of bands' means. Should this be considered a secure origin? My inclination - and response to Anne during the Blink intent to implement - is that I believe the spec already provides suitable flexibility for this. As noted, no algorithms are normative requirements - only the API surface. Algorithms which are not implemented by a UA have a defined behaviour (raising "NotImplementedError"). I believe that UAs that wish to restrict the availability of Web Crypto to secure origins - or to restrict the set of operations (for example, perhaps only allowing digest() operations, but no keyed operations) - seem to have a valid path for doing so. I think the only question is what the spec would need to say regarding this - that the set of algorithms supported by a UA may differ based upon (country of operation, local laws, configuration by administrator, origin of the document, optional components installed, etc) -- You are receiving this mail because: You are on the CC list for the bug.
Received on Wednesday, 4 June 2014 18:51:44 UTC