Intent to Remove: Insecure origin usage of getUserMedia()

Skip to first unread message

Joel Weinberger

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

Link to “Intent to Deprecate” thread


We want to start applying the concepts in 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.


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):

On secure origins (to remain):

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

Entry on the feature dashboard

I believe this fits under the already existing getUserMedia entry:

Philip Jägenstedt

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

To unsubscribe from this group and stop receiving emails from it, send an email to

Mike West

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

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


Philip Rogers

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



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.


Joel Weinberger

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

Sep 2, 2015, 1:51:19 AM9/2/15
to blink-dev,,,,,, 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.

Sep 2, 2015, 2:48:49 AM9/2/15
to blink-dev,,
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

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.



Serge Lachapelle

Sep 2, 2015, 5:45:49 AM9/2/15
to Justin Uberti, blink-dev,,,, Mike West, Philip Jägenstedt, Tommi, Sam Dutton
Serge Lachapelle | PM Director | Eng Site Lead Sthlm | | +46 732 01 22 32

Joel Weinberger

Sep 2, 2015, 1:31:48 PM9/2/15
to Serge Lachapelle, Justin Uberti, blink-dev,,,, 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.
Reply all
Reply to author
0 new messages