Intent to Remove: Insecure origin usage of getUserMedia()

[Joel Weinberger]

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]

LGTM

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

[Mike West]

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]

lgtm2

[Philip Rogers]

Privacy++

LGTM

[PhistucK]

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]

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]

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]

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]

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]

+sam

--

Serge Lachapelle | PM Director | Eng Site Lead Sthlm | ser...@google.com | +46 732 01 22 32

[Joel Weinberger]

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