Intent to Remove: non-secure usage of WebCrypto

瀏覽次數:366 次
跳到第一則未讀訊息

Andy Paicu

未讀,
2017年4月18日 上午4:13:262017/4/18
收件者: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

未讀,
2017年4月18日 上午4:20:172017/4/18
收件者: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

未讀,
2017年4月18日 上午11:32:332017/4/18
收件者:Philip Jägenstedt、Andy Paicu、blin...@chromium.org
LGTM2

Chris Harrelson

未讀,
2017年4月21日 下午6:00:562017/4/21
收件者: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

未讀,
2017年6月29日 下午5:39:572017/6/29
收件者: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

未讀,
2017年7月10日 下午12:03:182017/7/10
收件者: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

未讀,
2017年7月10日 下午12:17:432017/7/10
收件者: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

未讀,
2017年7月10日 下午12:36:162017/7/10
收件者: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

未讀,
2017年7月10日 下午12:44:582017/7/10
收件者: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

未讀,
2017年7月10日 下午12:51:192017/7/10
收件者: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

未讀,
2017年7月11日 上午9:52:432017/7/11
收件者: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

未讀,
2017年7月11日 上午10:58:342017/7/11
收件者: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

未讀,
2017年7月20日 上午10:53:512017/7/20
收件者: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
回覆所有人
回覆作者
轉寄
0 則新訊息