Improvements to Privacy & Security Considerations

[dontcallmedom]

Availability (https://w3c.github.io/fingerprinting-guidance/#identifying-fingerprinting-surface-and-evaluating-severity) is a factor that might be worth considering in this section of the specification: can any embedded iframe or third-party JavaScript use these features without user interaction? (In #142 I explicitly described this as drive-by available fingerprinting surface, but I'm not sure if that's still the case.)

There are a few mitigations described at the end of the new section that use "should" language, but I'm not clear on whether that's intended to be normative or not. (It seems likely that it's not.) Are there any normative mitigations that could be described, so that sites can understand that the same protections apply in all user agents?

I wasn't clear on what the suggested mitigations were for "default values". Could you explain that further?

The first example, which immediately follows the privacy and security considerations section, is an example that explicitly shows how to enumerate the UA's supported types, which seems like an explicitly bad practice and isn't showing an example driven by functionality. Limiting the number of type supported checks might be a good mitigation to recommend to those UAs that are going to support a diversity of types.

Originally posted by @npdoty in https://github.com/w3c/mediacapture-record/pull/165#issuecomment-471229023

[guest271314]

The MediaRecorder.isTypeSupported() example described at https://github.com/w3c/mediacapture-record/issues/142 is negligible, if impactful at all. There are far simpler ways to "fingerprint" the user-agent, at least to determine if the user is operating a Chromium or Chrome browser or a Mozilla browser, or a Linux or other OS, which is all that vector exposes. Unless there are considerations other than exposing the encoding capabilities in this or #142 which are privacy and security related?

To determine if a user is at Chrome all they have to do is type chrome in the console. To determine if at Mozilla just check !!HTMLMediaElement.prototype.mozCaptureStream.

What is the privacy concern with isTypeSupported()?

[npdoty]

@guest271314 feel free to add to issue #142 if you have comments on the privacy impacts of isTypeSupported. As noted in that issue, it's possible that the surface exposed in current implementations would be limited to just revealing the user agent vendor, but there are currently no requirements or recommendations to maintain that limitation.

[jan-ivar]

there are currently no requirements or recommendations to maintain that limitation.

@npdoty https://github.com/w3c/mediacapture-record/pull/165 added the following: "The UAs should take measures to mitigate this fingerprinting surface increase by e.g. implementing broad support for a given codec or MIME type and not making it dependent on e.g. architecture or hardware revisions nor OS/ version support, to prevent device/hardware characteristics inference through browser functionality"

Is that not a "recommendation"? Would you like MUST?

I'm not clear on whether that's intended to be normative or not.

You're right, that section is non-normative. We would have to move it to make it normative. @yellowdoge

I wasn't clear on what the suggested mitigations were for "default values".

I'm not sure either actually, and I missed that in review. Apologies! @yellowdoge can you clarify what you meant here?

Availability

FWIW I can't think of a reason why a third-party iframe should have access to this API by default.

We could probably add a media-recorder permissions policy and make it SecureContext without much breakage.

Most sources worth recording (camera, microphone, screen-sharing) are already SecureContext and require iframe allow=.¹

---

_{1) The exceptions are element.captureStream() and canvas.captureStream().}

[guest271314]

FWIW I can't think of a reason why a third-party iframe should have access to this API by default.

Would that include jsfiddle and plnkr?

We could probably add a media-recorder permissions policy and make it SecureContext without much breakage.

Is that really necessary? Would that impact usage at file: protocol https://github.com/w3c/webappsec-secure-contexts/issues/66? file: protocol, though might be considered "insecure" per langauge in one or more specifications, is far more "secure" that any online protocol.

What primary source definition of SecureContext is being relied on?

[jan-ivar]

Would that include jsfiddle and plnkr?

Sites like that have long allow= lists already, and are usually quick to update. They're poor examples of the norm.

What primary source definition of SecureContext is being relied on?

For the purposes of this discussion, it probably only matters that it's the same one getUserMedia & getDisplayMedia uses. https://heycam.github.io/webidl/#SecureContext

file: is SecureContext in Firefox FWIW.

[youennf]

Most sources worth recording (camera, microphone, screen-sharing) are already SecureContext and require iframe allow=.¹

I am not sure why third-party iframes should be singled out here. If MediaRecorder needs to be fingerprinting mitigated, it should be done for first party as well as third party iframes. For instance, nothing prevents a User Agent to strongly limit the available codecs statically (origins) or dynamically (gum called).

As of SecureContext, MediaStreamTrack, MediaStream, WebAudio, Canvas, video elements are not SecureContext for instance.

[jan-ivar]

(gum called)

We know this pattern leads to permission escalation (e.g. sites asking for microphone just to select audio output devices or get local ip addresses)

[guest271314]

@jan-ivar

We know this pattern leads to permission escalation (e.g. sites asking for microphone just to select audio output devices or get local ip addresses)

Can you kindly explain what you mean?

Audio output devices can only currently be selected at Firefox, Nightly, AFAICT audio output devices are impossible to select at Chromium, Chrome by default whatsoever using getUserMedia() - only microphone input can be selected - as evidenced by the numerous bugs that have filed at specification and Chromium bug tracker to formally implement that capability.

How does getUserMedia() permissions being granted expose local IP addresses?

[jan-ivar]

Sure, I'm talking about setSinkId (output as output, not input) which wfm in Chrome, and RTCWeb ip mode.

[guest271314]

Am not gathering a security issue in the audio output example. The user or site can just attach the stream to an HTMLMediaElement or use Web Audio API to output the audio.

WebRTC exposes local IP addresses anyway https://www.ovpn.com/en/blog/webrtc-might-expose-your-ip-address-despite-vpn/, correct?

Input and output could be clarified tremendously. It is ironic that Chromium does not support capture of Monitor of <device> under the auspices that Media Capture and Streams specification only describes microphone input yet setSinkId() only works at Chrome, Chromium, which is using getUserMedia() to get permissions to output to speakers.

The getUserMedia() spec does not mandate capturing audio output or showing a UI prompt as part of the device selection procedure.

https://bugs.chromium.org/p/chromium/issues/detail?id=1013881#c9, https://bugs.chromium.org/p/chromium/issues/detail?id=1032815.

So, we have Chromium stating essentially getUserMedia() is only for microphone input yet implementing output to speakers via getUserMedia().

There appears to be a contradiction.

Either getUserMedia() needs to take the time to extending the scope of the specification - in clear language - or create a specification just to deal with selection of existing default or virtual devices - not just the default microphone or camera that was the origin of the specification - which getUserMedia() has clearly "outgrown", however, is simultaneously attempting and does massage all sorts of extensions into getUserMedia() vicariously; perhaps in an attempt to remain within narrow confines of original charter yet still extend beyond the charter using the original charter as a reference?

[guest271314]

@jan-ivar If we are really discussion security and transparency, following the setSinkId() example set forth, the question must be raised, if the original design pattern of getUserMedia() was only for microphone input how does Chromium select speakers given this prompt for microphone?

[guest271314]

Adding to the potential for confusion at the setSinkId() example the prompt does not even list audio as being captured.

The Media Capture and Stream specification should immediately fix this omission

The getUserMedia() spec does not mandate capturing audio output or showing a UI prompt as part of the device selection procedure.

since the description of requirement or non-requirement has not been refuted, make mandatory exactly what is described as being non-compulsory, to make sure the user is affirmatively selecting the devices they intend to select.

[guest271314]

Re " Open Improvements to Privacy & Security Considerations" can one of the Media Capture and Streams specification authors explain how do we get output to speakers by granting permission to access camera?

[jan-ivar]

@guest271314 I noted permission escalation patterns to avoid. They're well-documented if you search for "getUserMedia" in the spec links I gave. But unless you want to defend those patterns, discussing their rationale here is out of scope.

can one of the Media Capture and Streams specification authors explain how do we get output to speakers by granting permission to access camera?

We don't. Implementation bugs are out of scope (unless you're arguing to enshrine them in a spec)—though to save you some time, Chrome does not appear to grant speaker access from camera permission for me, so I suspect pilot error on your part. Click the 🔒 in the url bar to check the site's permissions.

[guest271314]

@jan-ivar What am conveying and what you illustrate is that due to the specification not mandating minimum UI requirements the UI can provide misleading prompts, as there is no prompt for "speakers" whatsoever, and require steps by the user to determine what permissions are in effect for which device or not, that are not documented anywhere resulting in inconsistency between UI and specification.