Re: Leakage (Re: Requirements on mandatory constraints (ACTION-27))

Martin,

Even if we don't need any extra flexibility, my proposal (allowing 
developers to pass in a filter function) would provide you as much 
flexibility as you'll ever need without the risk of fingerprinting. 
Isn't it better to tackle fingerprinting in a more consistent manner as 
I have described? You could reuse this same functionality across all of 
WebRTC.

Gili

On 25/11/2013 12:50 PM, Martin Thomson wrote:
> Rethreading this bit.
>
> On 25 November 2013 00:52, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 2. Can someone come up with a requirement on information leakage?
> I honestly do not believe it to be possible to prevent information
> leakage while maintaining the ability to influence device selection.
> That is a mathematical impossibility.
>
> However, we can limit the damage by:
>
> 1) reducing the amount of information that can be obtained to either
>     a) got the device
>     b) no device
> 2) requiring that every probe request user consent, thereby attaching
> a significant penalty to each request
>
> Given that 1) is also non-modal and ignorable, I think that this is
> completely manageable.
>
> Jan-Ivar's suggestion that we remove the short-circuit on "device not
> present" errors achieves this.  Noting that applications can already
> enumerate and therefore determine whether a camera or microphone is
> even present, I'm comfortable with this.  Almost.
>
> The nasty corner case is where I only have an environment-facing
> camera and the application requires a user-facing camera.  The
> application sees that I have a camera and asks, applying a mandatory
> constraint.  I cannot comply with this, so the only real option we are
> left with is the application timing out.
>
> There are two options here:
> i) I know that Harald suggested that facing mode be put in the
> enumeration set.  That would solve this problem at a cost of a small
> fingerprinting surface increase.
>
> ii) The alternative is to put the user back in control, present the
> dialog and list of sources, noting that certain devices do not meet
> application constraints.  The application potentially gets something
> it didn't want.
>
> I'm somewhat ambivalent about these options.  I suspect that we can
> manage with either.  Applications will be happier with i), users with
> ii).
>

Received on Monday, 25 November 2013 19:08:11 UTC