W3C home > Mailing lists > Public > public-webrtc-editors@w3.org > February 2019

Fwd: Making progress on media capture privacy issues

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 7 Feb 2019 16:57:51 +0100
To: "public-webrtc-editors@w3.org" <public-webrtc-editors@w3.org>
Message-ID: <532a4c6c-9a7a-8a3d-3c55-e7059737b898@alvestrand.no>
Forwarding to public-webrtc-editors (which is the true name of the list).

-------- Videresendt melding --------
Emne: Re: Making progress on media capture privacy issues
Dato: Thu, 07 Feb 2019 07:53:58 -0800
Fra: youenn fablet <yfablet@apple.com>
Til: webrtc-editors@w3.org
CC: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand

As suggested by Harald, I am forwarding this email to webrtc-editors.

> On Jan 31, 2019, at 12:24 PM, youenn fablet <yfablet@apple.com> wrote:
> Hi,
> I would like to follow up on the discussions we had today on the getUserMedia/enumerateDevices issues.
> The first step seems to reach consensus amongst WebRTC editors and I am wondering what would be the best way to get there.
> Should we try making progress by email or GitHub? Should we allocate more time during next week VC?
> Here is a summary of my thoughts and some questions that might help bring this subject forward.
> I think the specification should allow implementations to not leak any information as long as a prompt is not shown to the user, while allowing to provide all information once getUserMedia is granted. Can we agree on that goal?
> If we agree, this leads to some additional requirements:
> - The spec should allow filtering non default capture device information from enumerateDevices and expose them later on during the lifetime of a page.
> - The spec should allow to not implement state ‘b’ (i.e. expose information for pages of an origin that was granted getUserMedia access in the past).
> - The spec should allow to not use getUserMedia as a silent oracle.
> Would it be something Chrome or Firefox could try implementing at some point?
> This has some trade-offs. Here is the list I got from your feedback:
> - Provide a capture picker with all devices listed before getUserMedia is granted (one can still generate a picker with default devices information guessed from user agent, CSS...)
> - Compute some capture setup stats before the user is prompted (this one is difficult to split from fingerprinting though)
> Given this list, it makes sense to me that the spec recommends the above behavior.
> An additional issue is the handling of output devices, their use being not conditional on getUserMedia.
> Maybe this use case would best be served by a complementary solution/API (I have some vague ideas), in addition to enumerateDevices/getUserMedia.
> Thanks,
> 	Y
Received on Thursday, 7 February 2019 15:58:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:07 UTC