Intent to Remove : Nonsecure usage of MediaDevices, getUserMedia(), getDisplayMedia(), enumerateDevices() and related types.

[Guido Urdaneta]

Primary eng (and PM) emails

gui...@chromium.org, hu...@chromium.org

Summary

Make the following SecureContext:

• MediaDevices interface

• mediaDevices attribute of the Navigator interface

• getUserMedia method of the Navigator interface

• MediaDeviceInfo interface

Motivation

getDisplayMedia() and the getUserMedia() variants in Chrome only work on secure origins. The other important function affected by this change is enumerateDevices(), which currently works on insecure contexts, but is only useful (for its intended purpose) in combination with getUserMedia() or setSinkId(), which require secure origins. We have observed that enumerateDevices() usage has spiked recently and we suspect that it is being used to track users. The change proposed in this intent would be a first (though not the only) mitigation to address this issue.

Since M47, usage of getUserMedia() on insecure origins produces a deprecation warning (see https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ). So does usage of getDisplayMedia() on insecure origins.

Interoperability and Compatibility Risk

With regards to getUserMedia() and getDisplayMedia(), the only risk is that it will fail differently on insecure origins. Instead of a rejected promise, users will get an error due to the function not existing.

With regards to enumerateDevices(), it will start failing for domains that use it on insecure origins. However, we believe that these usages are not legitimate since the data obtained from enumerateDevices() is useful only in combination with getUserMedia() (does not work on insecure origins) or setSinkId() (SecureContext according to spec and in practice requires a secure origin to get permission to use devices).

In terms of interoperability, Edge and Firefox support calling all these APIs on insecure contexts, but Firefox has agreed to restrict these APIs to secure origins, and Edge is moving to Chromium. On Safari, getUserMedia() works only on secure origins.

Edge: No known signals

Firefox: Positive signals

Safari: Supported

Alternative implementation suggestion for web developers

The recommendation is to use these APIs only on secure origins.

Usage information from UseCounter

We have no counters for usage of enumerateDevices() on insecure origins, but general usage has spiked recently. Prior to the spike, usage was around 0.06% including secure origins, which is the only use case we are interested in supporting. For reference, the counter for getUserMedia() in secure origins is also 0.06%, which supports the idea that the spike is due to attempts to use enumerateDevices() for tracking users.

As stated above, getUserMedia() on insecure origins does not work on Chrome since M47. Nevertheless, according to our counters, insecure usage is around 0.0005%.

We have no counters for getDisplayMedia() on insecure origins, but this is a new API with relatively low usage. The counter for all origins  is around 0.00012%.

Entry on the feature dashboard

https://www.chromestatus.com/feature/4924861776396288

Requesting approval to remove too?

Yes. We are requesting removal as soon as possible.

[Daniel Bratell]

It doesn't seem web developer friendly to make the existence of the functions depend on how you loaded the page. It seems to be what the WebIDL dictates for [SecureContext] attributes, but is this actually implemented that way anywhere else?

/Daniel

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ab8771b-09c3-49a3-9bbc-860d9b8f0315%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Guido Urdaneta]

There are plenty of features that are restricted to secure contexts. See https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts.

All browsers have some/all of those features.

The Media Capture and Streams spec mandates the change proposed on this intent, which has already been implemented in practice for the most part (getUserMedia() and getDisplayMedia()). We just want to do it in the way specified by the standard, which includes extending it to enumerateDevices() and using [SecureContext].

As for developer friendliness, I think SecureContext is actually friendlier than the way we currently restrict getUserMedia()/getDisplayMedia() because it makes it easy to detect if the feature is supported by just inspecting if the right attributes/methods.

[Daniel Bratell]

For getUserMedia in particular, adding one more thing that can go wrong will not make it easier for web developers. With this change you'd first have to check if the function exists and then check the returned promise while before you would only have to check the returned promise. Not checking that it exists will result in the script crashing which is an error condition that couldn't before happen.

So it will hurt compatibility, but I see that the working group agreed on this change a couple of months back, and maybe attempts to use these functions on http are few enough to accept those site scripts crashing. I think this is what the counter at 0.0005% is counting. 0.0005% is not a lot (once every 200k page loads) and supposedly those sites would still not be functional though it's hard to be sure.

That said, it makes sense to move in tandem with other browsers here (Mozilla's change was reverted yesterday but it will supposedly land again soon).

A bit strange that Chromium has different errors than the others on https://wpt.fyi/results/mediacapture-streams/MediaDevices-SecureContext.html but I assume that will all be cleared up here.

LGTM1 to move enumerateDevices to be https only and to hide it and getUserMedia/getDisplayMedia from http loaded pages per spec.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxayY0Ysexnk4YJnFXTeRSS_%3DZFq76RUmkhpvJZYP90FbA%40mail.gmail.com.

[Thomas Steiner]

Not directly related, but FYI: The latest iOS 12.2 Beta 3 just silently removed the legacy API `navigator.getUserMedia` in favor of the new `navigator.mediaDevices.getUserMedia`. If this goes out in stable, a ton of media apps will break [citation needed]. The new API is HTTPS only.

[Philipp Hancke]

Due to the more than half a decade long process of getting WebRTC + getUserMedia everywhere most sites that want to use getUserMedia are already using existence checks like navigator.mediaDevices && 'getUserMedia' in navigator.mediaDevices (hopefully; checking for navigator.webkitGetUserMedia is worse)

Not doing such a check would for example already break in Chrome on iOS due to crbug.com/752458

[Chris Harrelson]

LGTM2

On Thu, Feb 28, 2019 at 3:28 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:

Due to the more than half a decade long process of getting WebRTC + getUserMedia everywhere most sites that want to use getUserMedia are already using existence checks like navigator.mediaDevices && 'getUserMedia' in navigator.mediaDevices (hopefully; checking for navigator.webkitGetUserMedia is worse)

Not doing such a check would for example already break in Chrome on iOS due to crbug.com/752458

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2Bk-sQs2tNY_xJQBvaD0K8h8GPtfboTke8UPkANxAxJrw%40mail.gmail.com.

[Alex Russell]

LGTM3