Hey Tim, The only questions I have about this our are difference in implementation over Chrome the more we increase the use of [SecureContext] the greater risk we put on compat bugs.
Our implementation differs in that we actually abide to the specification on window.opener insecure contexts making the openee insecure. This may for example cause breakage on payment sites that want to use crypto. Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at least for the time being? The difference is somewhat a technicality anyway as the inverse isn't true a SecureContext that opens an !SecureContext is not then treated as insecure despite the risk being pretty much the same. On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert <ttaub...@mozilla.com> wrote: > Summary: The WebCrypto spec [1] states that window.crypto.subtle > should only be usable from a secure origin (i.e. on a domain being > served over HTTPS). Currently Gecko's implementation works on insecure > origins (i.e. sites served over unencrypted HTTP). To bring our > implementation in line with the spec, we're going to remove access to > crypto.subtle on non-secure origins. > > Sites using the WebCrypto API's crypto.subtle interface on a > non-secure origin should switch to HTTPS as soon as possible. > > Chrome too is planning to remove access to crypto.subtle on non-secure > origins [2]. Edge seems positive about implementing those restrictions > as well [3]. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140 > > Standard: https://w3c.github.io/webcrypto/Overview.html > > Platform coverage: This will affect Windows, MacOS, Linux, and Android. > > Estimated target date: This could land as early as Firefox 56, but > should in Firefox 57. We probably want to coordinate with Chrome, they > seem as ready as we are. > > Our telemetry [4] indicates that about 9% of crypto.subtle use is > still on insecure origins. This was at around 1-2% - that's not the > percentage of all users, but only of those that visit pages that use > crypto.subtle - but became inflated around two weeks after we started > measuring. The blink-dev thread [2] has a good summary and indicates > that this is caused by Twitter launching AMP support serving from > origins which may be insecure. AMP has a fallback that is lazy-loaded > in case crypto.subtle isn't available, so no one's Twitter would break > when we ship this. > > > [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface > [2] https://groups.google.com/a/chromium.org/forum/#!topic/ > blink-dev/ZD3NWqkk-bo/discussion > [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989 > [4] https://mzl.la/2ttx8aV > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
