W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2018

Following Up on WebRTC MediaStream Recording API

From: Jason A. Novak <jnovak@apple.com>
Date: Thu, 11 Jan 2018 12:39:17 -0600
Message-id: <53033EB1-28A3-4B25-8747-E0E066A35C2A@apple.com>
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:34 UTC