Following Up on WebRTC MediaStream Recording API

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.

Best,
Jason