- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Jul 2020 19:53:20 +0000
- To: public-webrtc-logs@w3.org
> there are currently no requirements or recommendations to maintain that limitation. @npdoty https://github.com/w3c/mediacapture-record/pull/165 added [the following](https://w3c.github.io/mediacapture-record/#fingerprinting): _"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](https://w3c.github.io/mediacapture-record/MediaRecorder.html#privacy-and-security) (camera, microphone, screen-sharing) are already `SecureContext` and require iframe `allow=`.ยน --- <sub>1) The exceptions are `element.captureStream()` and `canvas.captureStream()`.</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/196#issuecomment-652615402 using your GitHub account
Received on Wednesday, 1 July 2020 19:53:21 UTC