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

On 2013-11-25 18:50, 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

I prefer this one since it reduces the cases where nothing happens 
because the app is more interested in the code path that involves the 
success callback. getUserMedia() is a request for sensitive information; 
I think always prompting for the *request* is OK. This option is also 
more friendly for "alternative devices" such as media files.

> 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.

I think the "facing" constraint is the most important one. I honestly 
think we would be fine with just that constraint (besides audio/video) 
at getUserMedia() time and then let the script do applyConstraint() with 
all the rest once it has access to a stream/tracks (and all the 
capabilities that comes with).

> 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.

"ignore constraints" browser extension. 10000+ downloads. :)

> I'm somewhat ambivalent about these options.  I suspect that we can
> manage with either.  Applications will be happier with i), users with
> ii).

Good summary. So what do we do?

/Adam

Received on Wednesday, 27 November 2013 08:15:38 UTC