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

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 17:50:29 UTC