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 <> and review if they were properties from the UA or set by the website using the API.  

Looking at the MediaRecorder 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 <> which collects user consent via 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.


Received on Thursday, 11 January 2018 18:39:42 UTC