Intent to Remove: non-secure usage of WebCrypto

[Andy Paicu]

This is a change in accordance with

https://w3c.github.io/webcrypto/Overview.html#crypto-interface

Primary eng (and PM) emails

mk...@chromium.org

andy...@chromium.org

maksim...@chromium.org

Summary

Following the corresponding intent to deprecate, the introduced UseCounter is now in beta and it has 0% hits https://www.chromestatus.com/metrics/feature/timeline/popularity/1829.

Motivation

Make the implementation to match the PR spec.

https://github.com/w3c/webcrypto/pull/131

Compatibility Risk

crypto.subtle will no longer be visible on insecure contexts

Usage information from UseCounter

0% of page visits

OWP launch tracking bug

crbug.com/641526

Entry on the feature dashboard

https://www.chromestatus.com/features/5030265697075200

Requesting approval to remove.

Yes

[Philip Jägenstedt]

LGTM1.

FWIW, now that we try to decide on a removal date early on, it's fine to sent an Intent to Deprecate and Remove with a removal date far in the future, and to follow up on that thread only if something unexpected happens.

[Dimitri Glazkov]

LGTM2

[Chris Harrelson]

LGTM3

LGTM2

--
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.

[Malte Ubl]

I just wanted to highlight that the UseCounter is jumping up in the last days: https://www.chromestatus.com/metrics/feature/timeline/popularity/1829

This lines up with Twitter launching AMP support serving from origins which may be insecure.

All AMP pages are using crypto subtle for hashing. It should be noted that while crypto.subtle should not be used on insecure origins for encryption for obvious reasons, it is still quite useful for non-cryptographic use cases of cryptographic hashes.

[Rick Byers]

Thanks Malte.  So what's the implication to AMP if this removal goes through?  Is there a reasonable replacement for crypto.subtle for your hashing use case?  Were these use cases debated when the spec was changed?

Andy, what's the status for other browsers (looks like that section was missing from the intent thread)? The usage is now high enough (0.01%) that we'd normally want to be pretty careful before breaking it (when usage was ~zero, matching the spec is nearly a rubber-stamp approval).  But in general we don't let any single site (no matter how popular) dictate web compat constraints.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdPJif3Uuy7F5Hkj8zo0ZyEWzhkCmL%3D_3_EK3NqaiVymzp4kQ%40mail.gmail.com.

[PhistucK]

I am really surprised that AMP does not mandate HTTPS for the content(?!), if I understand this discussion correctly...

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9smFq_e%2BXzi2XPuBttGVG9upjf3i0UxcwuxSwXCmti-g%40mail.gmail.com.

[Malte Ubl]

AMP does not mandate HTTPS for content that can be served from AMP caches. The AMP caches themselves are always HTTPS.

To answer Rick's question: Since we have a polyfill in place, the removal of the feature should not break anything; just add latency since the polyfill is lazy loaded. I sent a PR that removes the cypto.subtle dependency for the cases where the connection might be HTTPS

https://github.com/ampproject/amphtml/pull/10210

[Rick Byers]

Thanks Malte.  If there's consensus from most of the other browsers to make this change too, then it sounds like we should continue as planned.  But if we're on our own here in matching the spec then I'd be more concerned (we don't want Chrome to suffer a polyfill/latency penalty that other browsers do not).  Andy/Mike?

[Jochen Eisinger]

I'd vote for sticking with the spec. I don't see the usefulness of crypto.subtle as an argument for allowing it on insecure contexts. We're not going to just mandate secure transport for useless features after all...

☆PhistucK

LGTM3

LGTM2

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

--
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+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdPJif3Uuy7F5Hkj8zo0ZyEWzhkCmL%3D_3_EK3NqaiVymzp4kQ%40mail.gmail.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9smFq_e%2BXzi2XPuBttGVG9upjf3i0UxcwuxSwXCmti-g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9t1TDgPy-eT00fwX5Q3a8LpSBAyhQZ0ZHqpSKXwgAB%3DA%40mail.gmail.com.

[Mike West]

Hi, sorry! I tweeted about this, but apparently never followed that up with an email. :)

As Malte noted, I don't believe we're going to break any sites by locking `crypto.subtle` behind `[SecureContext]`. The AMP code in question falls back to a polyfill in cases where the API isn't natively available: it will be slower, but not broken. When Malte's patch lands, the dependency will be removed entirely. I would prefer to continue with the deprecation as planned.

To the point about other vendors: Vijay from Microsoft was positive on the GitHub discussion (https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989), but I don't know how other vendors have reacted. Perhaps eroman@ or rsleevi@ have insights/links to bugs?

-mike

☆PhistucK

LGTM3

LGTM2

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

--
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.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdPJif3Uuy7F5Hkj8zo0ZyEWzhkCmL%3D_3_EK3NqaiVymzp4kQ%40mail.gmail.com.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9smFq_e%2BXzi2XPuBttGVG9upjf3i0UxcwuxSwXCmti-g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Ryan Sleevi]

Mozilla bug for restricting to [SecureContext] is
https://bugzilla.mozilla.org/show_bug.cgi?id=1333140

It was initially gated on bindings issues, and then they wanted to
measure compat issues. I believe, like you mentioned, an uptick
related to AMP was noticed. Tim Taubert was last looking into the
measurements to assess impact. Note that Mike's proposal is to
properly implement the ancestry check, while Mozilla does not yet
restrict it at all. Mozilla's measurements about secure vs non-secure
does, however, implement the ancestry check - so the actual impact is
most likely aligned somewhere around those Chrome numbers.

>>>>>>>>> send an email to blink-dev+...@chromium.org.

>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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+...@chromium.org.

>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "blink-dev" group.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdPJif3Uuy7F5Hkj8zo0ZyEWzhkCmL%3D_3_EK3NqaiVymzp4kQ%40mail.gmail.com.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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+...@chromium.org.

[Tim Taubert]

Sorry for the late response, I just sent our "intent to remove" email
[1] to Mozilla's dev-platform mailing list.

We looked at the telemetry data and the discussion in this thread and
decided to move forward with the restriction.

- Tim


[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/55t-Uyx1TxI