Re: Following Up on WebRTC MediaStream Recording API

Thanks for the follow-up/prompt here, Jason.

> On Jan 11, 2018, at 10:39 AM, Jason A. Novak <jnovak@apple.com> wrote:
> 
> Folks -
> 
> In the January 4th meeting, I took the action to review the MIME types, videoBitsPerSecond, and audioBitsPerSecond portion of the WebRTC MediaStream Recording API <https://w3c.github.io/mediacapture-record/> and review if they were properties from the UA or set by the website using the API.
> 
> Looking at the MediaRecorder Members <https://w3c.github.io/mediacapture-record/#mediarecorderoptions-members> portion of the spec, I can confirm that videoBitsPerSecond and audioBitsPerSecond are both hints for the application using the API passed to the UA, and that they’re “hint[s] for the encoder and the value might be surpassed, not achieved, or only be achieved over a long period of time.”
> 
> The mimeType property is interesting and may have fingerprinting impact as it "specifies the media type and container format for the recording via a type/subtype combination” and “[if] the UA does not support the format or any of the parameters specified, it MUST throw a NotSupportedError DOMException”.  As a result, a malicious website could try to enumerate what codecs a UA does and does not support and if there are any user-installed codecs (a la font detection).  Perhaps this is mitigated by the fact that my understanding is that this API relies on MediaStreamTrack <https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack> which collects user consent via getUserMedia() <https://www.w3.org/TR/mediacapture-streams/#dom-mediadevices-getusermedia()> so a website cannot silently query the codecs supported by a UA.  That said, the additional fingerprinting surface may be worth calling out in the privacy considerations section.

MediaRecorder also has an isTypeSupported method, which returns true or false when called with a contentType. The example code snippet in the spec is, explicitly, enumerating a list of codec/container combinations and testing whether the client supports each.
https://w3c.github.io/mediacapture-record/#example1

In this code pen, you can see this run without any user permission/intervention and enumerate the supported codecs on your particular browser/device:
https://codepen.io/miguelao/pen/edqNab?editors=0010

So it seems like there is a very direct increased fingerprinting surface here, which isn't mitigated by needing permission or user interaction.

It is noted in some existing issues that there are alternatives that would be worse in terms of increasing the fingerprinting surface more significantly, like providing an enumerated list to any site. Increased fingerprinting surface is described as an implementer concern for those approaches.
https://github.com/w3c/mediacapture-record/issues/59

—Nick