Intent to Remove: Insecure origin usage of getUserMedia()

2207 views
Skip to first unread message

Joel Weinberger

unread,
Aug 13, 2015, 9:05:25 PM8/13/15
to blink-dev, Mike West, Jochen Eisinger

Intent to Remove: Insecure origin usage of getUserMedia()

(security-dev@ to BCC as an FYI; discussion should remain on blink-dev@)


Primary eng (and PM) emails

j...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ


Summary

We want to start applying the concepts in https://w3c.github.io/webappsec/specs/powerfulfeatures/ to features that have already shipped and which do not meet the (new, not present at the time) requirements. This is an intent to remove specifically for getUserMedia() on insecure origins.


Motivation

It is of very low use.


Compatibility Risk

Describe the degree of compatibility risk you believe this change poses. Please indicate how long the API has been supported by Chrome and the feature’s status in other browsers.


Usage information from UseCounter

On insecure origins (to remove): https://www.chromestatus.com/metrics/feature/popularity#GetUserMediaInsecureOrigin

On secure origins (to remain):

https://www.chromestatus.com/metrics/feature/popularity#GetUserMediaSecureOrigin

getUserMedia() on insecure origins is used on 0.0009%, below the 0.03% deprecation level. Given that it is used on secure origins on 0.0212% of page loads, that means that it accounts for ~%4 of page loads that use getUserMedia(). Given the rather large privacy risks of video and sound from the client over insecure channels, this seems to us to be well worth the compatibility risk.


OWP launch tracking bug

https://crbug.com/520765


Entry on the feature dashboard

I believe this fits under the already existing getUserMedia entry: https://www.chromestatus.com/features/6067380039974912

Philip Jägenstedt

unread,
Aug 14, 2015, 4:14:11 AM8/14/15
to Joel Weinberger, blink-dev, Mike West, Jochen Eisinger
LGTM

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

Mike West

unread,
Aug 14, 2015, 4:19:37 AM8/14/15
to Philip Jägenstedt, Jochen Eisinger, Joel Weinberger, blink-dev

Non-OWNER's LGTM. Thanks for moving this forward, Joel. Looking forward to the steady drumbeat of deprecations and removals that you're surely planning.

Jochen Eisinger

unread,
Aug 14, 2015, 7:40:39 AM8/14/15
to Mike West, Philip Jägenstedt, Joel Weinberger, blink-dev

lgtm2

Philip Rogers

unread,
Aug 17, 2015, 7:43:46 PM8/17/15
to Jochen Eisinger, Mike West, Philip Jägenstedt, Joel Weinberger, blink-dev
Privacy++

LGTM

PhistucK

unread,
Aug 18, 2015, 1:35:13 AM8/18/15
to Philip Rogers, Jochen Eisinger, Mike West, Philip Jägenstedt, Joel Weinberger, blink-dev
Will this block the usage in file:// URLs?
I am not sure it even matters (and I really wish file:// URLs not to work, because they make people think it is fine to just double click an HTML file and expect it to work when it does not really work), but, just to clarify.


PhistucK

Joel Weinberger

unread,
Aug 18, 2015, 12:37:58 PM8/18/15
to PhistucK, Philip Rogers, Jochen Eisinger, Mike West, Philip Jägenstedt, blink-dev
Yes, it should allow file:/// URLs. Ultimately, this does the "Is origin potentially trustworthy?" check from http://www.w3.org/TR/powerful-features/#is-origin-trustworthy. Implementation-wise, this boils down to a call to isPotentiallyTrustworthy(), which returns |true| for local schemes, including file:/// schemes.

In short, files from the local filesystem are "transported" via a secure mechanism, so they're treated as secure.
--Joel

jub...@google.com

unread,
Sep 2, 2015, 1:51:19 AM9/2/15
to blink-dev, phis...@gmail.com, p...@chromium.org, joc...@chromium.org, mk...@google.com, phi...@opera.com, Serge Lachapelle, Tommi
Hey folks,

We (WebRTC team) are getting customer complaints of gUM being shut off unexpectedly for HTTP origins. 

Last time we discussed this, the projection was for an end-of-2016 window for turndown of this functionality and that's what was communicated to customers. This was also supported by our security audit, which reached the conclusion that the security risk here was quite limited due to the gUM consent mechanism, and so a gradual turndown was acceptable.

to...@google.com

unread,
Sep 2, 2015, 2:48:49 AM9/2/15
to blink-dev, mk...@chromium.org, joc...@chromium.org
The change was landed just before 46 was cut, so there was almost no time where it was disabled on Dev.
We should start by reverting for 46.

Mike West

unread,
Sep 2, 2015, 2:59:10 AM9/2/15
to Tomas Gunnarsson, blink-dev, Jochen Eisinger, Joel Weinberger, Justin Uberti
Given the usage numbers Joel posted at the top of this thread (0.0009% of page views), I'm a bit surprised that you're getting complaints. Can you share some of the sites that are broken?

I wouldn't mind delaying the removal until M47, but waiting until the end of next year would be unfortunate given the nature of the data and the low usage numbers.

-mike

-Mike

Serge Lachapelle

unread,
Sep 2, 2015, 5:45:49 AM9/2/15
to Justin Uberti, blink-dev, phis...@gmail.com, p...@chromium.org, joc...@chromium.org, Mike West, Philip Jägenstedt, Tommi, Sam Dutton
+sam
--
Serge Lachapelle | PM Director | Eng Site Lead Sthlm | ser...@google.com | +46 732 01 22 32

Joel Weinberger

unread,
Sep 2, 2015, 1:31:48 PM9/2/15
to Serge Lachapelle, Justin Uberti, blink-dev, phis...@gmail.com, p...@chromium.org, joc...@chromium.org, Mike West, Philip Jägenstedt, Tommi, Sam Dutton
Hi everyone.  As Mike said, pushing it back to M47 certainly makes sense to me, but given the extraordinarily low usage, I'm surprised to hear about the complaints. As per Mike's request, would you mind shooting us some example origins where this is a problem? Feel free to do so off list if you'd rather not publicly discuss them.
--Joel
Reply all
Reply to author
Forward
0 new messages