Intent to Deprecate: non-secure usage of WebCrypto

[Sisov, Maksim]

This is a change in accordance with
https://w3c.github.io/webcrypto/Overview.html#crypto-interface

Primary eng (and PM) emails
maksim...@chromium.org
mk...@chromium.org

Summary
Inform Web Developers that WebCrypto requires secure origin by showing
a deprecation message.


Motivation
Make the implementation to match the PR spec.
https://github.com/w3c/webcrypto/pull/131

Compatibility Risk
crypto.subtle will no be longer visible on insecure contexts

Usage information from UseCounter
~0.024% of page views. https://www.chromestatus.com/metrics/feature/timeline/popularity/715
However, we do not distinguish between non-secure and secure usage.
https://codereview.chromium.org/2639593002 will provide concrete numbers
during the deprecation period.

OWP launch tracking bug
crbug.com/641526

Entry on the feature dashboard
https://www.chromestatus.com/features/5030265697075200

Requesting approval to remove too?
No

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Jochen Eisinger]

lgtm to deprecate

[Mike West]

On Tue, Feb 21, 2017 at 2:01 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Tue, Feb 21, 2017 at 1:45 PM Sisov, Maksim <maksim...@intel.com> wrote:

Summary
Inform Web Developers that WebCrypto requires secure origin by showing
a deprecation message.

Note: we're already throwing a SecurityError today if `crypto.subtle` methods are called from `http` origins. This change simply aligns WebCrypto's definition of "secure" with the secure context spec, by, for example, walking the entire ancestor chain.

 

Motivation
Make the implementation to match the PR spec.
https://github.com/w3c/webcrypto/pull/131

Which is valuable because it's the only API that locks itself to a secure context but doesn't walk the ancestor chain, so we have a special WebCrypto carveout in Blink. Since the working group (which includes the major API clients) has agreed that tightening the restriction makes sense, we should follow suit.

Usage information from UseCounter
~0.024% of page views. https://www.chromestatus.com/metrics/feature/timeline/popularity/715
However, we do not distinguish between non-secure and secure usage.
https://codereview.chromium.org/2639593002 will provide concrete numbers
during the deprecation period.

For clarity, the API whose checks we're talking about tightening is used on 0.024% of page views. We expect that the majority of that usage is Netflix, which migrated to HTTPS a while ago, so the number of pages on which this deprecation will cause a warning should be significantly lower then 0.024%.

-mike

[Philip Jägenstedt]

It sounds like only secure origins embedded in insecure origins will be affected by the change in policy, and it makes sense that this would be a fraction of the 0.024%.

The fact that window.crypto.subtle will disappear on insecure origins seems like a potentially larger source of breakage, if there exists any window.crypto feature detection that then just assumes that crypto.subtle.encrypt() can be called. No use counter could estimate this risk, however.

Can we commit to a milestone for the [SecureContext] change, and include it in the deprecation message? (If we can't, then I think we also shouldn't deprecate yet.)

[PhistucK]

Sounds like there are two deprecations here -

1. Deprecate using WebCrypto in an HTTPS iFrame under an HTTP top frame.

2. Deprecate crypto.subtle from any insecure origin (including the case described in 1.).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

I suppose one could do it in two steps like that, and IIUC the use counter is a good proxy for the risk of the first step. But going directly to the the [SecureContext] change would solve the whole problem, so isn't it nicer to web developers to have just one change to understand? It would be sad if anyone would have to adapt to these changes twice. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

I agree, though it is a much bigger change (though the consequences are probably not severe at all, since no one can actually use it anyway, outside of that corner case).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

On Tue, Feb 21, 2017 at 9:47 PM Philip Jägenstedt <foo...@chromium.org> wrote:

It sounds like only secure origins embedded in insecure origins will be affected by the change in policy, and it makes sense that this would be a fraction of the 0.024%.

The fact that window.crypto.subtle will disappear on insecure origins seems like a potentially larger source of breakage, if there exists any window.crypto feature detection that then just assumes that crypto.subtle.encrypt() can be called. No use counter could estimate this risk, however.

Can we commit to a milestone for the [SecureContext] change, and include it in the deprecation message? (If we can't, then I think we also shouldn't deprecate yet.)

This was sorted out in the review: https://codereview.chromium.org/2709613009

Removal (the [SecureContext] change) is set for M59.