Intent to Remove: non-secure usage of WebCrypto

365 wyświetleń
Przejdź do pierwszej nieodczytanej wiadomości

Andy Paicu

nieprzeczytany,
18 kwi 2017, 04:13:2618.04.2017
do blin...@chromium.org
This is a change in accordance with

Primary eng (and PM) emails

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.

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

Usage information from UseCounter
0% of page visits

OWP launch tracking bug

Entry on the feature dashboard

Requesting approval to remove.
Yes

Philip Jägenstedt

nieprzeczytany,
18 kwi 2017, 04:20:1718.04.2017
do Andy Paicu, blin...@chromium.org
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

nieprzeczytany,
18 kwi 2017, 11:32:3318.04.2017
do Philip Jägenstedt, Andy Paicu, blin...@chromium.org
LGTM2

Chris Harrelson

nieprzeczytany,
21 kwi 2017, 18:00:5621.04.2017
do Dimitri Glazkov, Philip Jägenstedt, Andy Paicu, blin...@chromium.org
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

nieprzeczytany,
29 cze 2017, 17:39:5729.06.2017
do Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, Andy Paicu, blin...@chromium.org
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

nieprzeczytany,
10 lip 2017, 12:03:1810.07.2017
do Malte Ubl, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, blin...@chromium.org, Owen Campbell-Moore, Mike West
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.

PhistucK

nieprzeczytany,
10 lip 2017, 12:17:4310.07.2017
do Rick Byers, Malte Ubl, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, blin...@chromium.org, Owen Campbell-Moore, Mike West
I am really surprised that AMP does not mandate HTTPS for the content(?!), if I understand this discussion correctly...


PhistucK

Malte Ubl

nieprzeczytany,
10 lip 2017, 12:36:1610.07.2017
do PhistucK, Rick Byers, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, blin...@chromium.org, Owen Campbell-Moore, Mike West
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

Rick Byers

nieprzeczytany,
10 lip 2017, 12:44:5810.07.2017
do Malte Ubl, PhistucK, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, blin...@chromium.org, Owen Campbell-Moore, Mike West
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

nieprzeczytany,
10 lip 2017, 12:51:1910.07.2017
do Rick Byers, Malte Ubl, PhistucK, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, blin...@chromium.org, Owen Campbell-Moore, Mike West
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.

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

Mike West

nieprzeczytany,
11 lip 2017, 09:52:4311.07.2017
do Eric Roman, blin...@chromium.org, Ryan Sleevi, Rick Byers, Malte Ubl, PhistucK, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, Owen Campbell-Moore, Jochen Eisinger
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.

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

Ryan Sleevi

nieprzeczytany,
11 lip 2017, 10:58:3411.07.2017
do Mike West, Eric Roman, blin...@chromium.org, Ryan Sleevi, Rick Byers, Malte Ubl, PhistucK, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, Owen Campbell-Moore, Jochen Eisinger, Tim Taubert
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

nieprzeczytany,
20 lip 2017, 10:53:5120.07.2017
do rsl...@chromium.org, Mike West, Eric Roman, blin...@chromium.org, Rick Byers, Malte Ubl, PhistucK, Andy Paicu, Chris Harrelson, Dimitri Glazkov, Philip Jägenstedt, Owen Campbell-Moore, Jochen Eisinger
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
Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż dalej
Nowe wiadomości: 0