Fwd: Making progress on media capture privacy issues

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
<harald@alvestrand.no>

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

> 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