Re: Bug 23934 - Proposal: Always launch permission prompt to avoid leakage

I think our point is that you could protect *all* of WebRTC's methods 
and it wouldn't make a difference. There is already more than enough 
fingerprinting data available from other APIs.

Gili

On 10/12/2013 9:13 AM, Jan-Ivar Bruaroey wrote:
> I would tie this together with another question: Do we expect to leave 
> getMediaDevices() open and without any permissions? Otherwise we're 
> patching only half of the hull and the boat still sinks.
>
> .: Jan-Ivar :.
>
> On 12/9/13 8:26 PM, Eric Rescorla wrote:
>> For the record, I am opposed to this entire piece of Jan-Ivar's proposal.
>>
>> As has been observed many times, there are plenty of opportunities
>> for fingerprinting and so going through these gyrations to make
>> it fractionally more difficult is silly.
>>
>> -Ekr
>>
>>
>> On Sun, Dec 8, 2013 at 8:38 PM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com>  wrote:
>>> On 2013-12-05 16:05, Jim Barnett wrote:
>>>> Stefan, My concern is whether the UA will know enough about the
>>>> unsatisfied mandatory constraints to prompt the user intelligibly.
>>>> Martin says that he doesn't think that the UA will be able to explain
>>>> what the constraints mean.  If that's the case, won't the user
>>>> experience be pretty bad?  "You do not have a device that satisfies
>>>> this application's requirements.  Please insert random objects into
>>>> your USB slot and maybe something will work".
>>> As others have said, the app would get the same info as today. The
>>> difference would be that the user would know that the app asked to use
>>> the camera.
>>>
>>> That said, I still think we have some experimenting to do to get to the
>>> right models. The UA could for example display info in the doorhanger
>>> ("no camera with sufficient resolution found"). That's why I think we
>>> could consider leaving out the exact definition of the dialogue from the
>>> spec (just put something like "in a UA specific way" in).
>>>
>>>> If we say that it's the app's job to explain what it needs, it will
>>>> need to know which constraints weren't satisfied.  That brings us
>>>> back to the current definition of gUM (where the app finds out which
>>>> constraints failed and then can decide whether to remove them and try
>>>> again.)
>>> Agreed, but it could do the same here, the difference would be that the
>>> user would have been informed of the first attempt already.
>>>
>>> This also brings us back to the discussion on when the app should use
>>> mandatory constraints with gUM: only when the app would rather skip
>>> video (and/or audio) than not having those constraints met. This is what
>>> we have been saying all along, and we've even said that using mandatory
>>> constraints would be made more difficult.
>>>
>>> Always launching a permission prompt would perhaps enforce this - the
>>> app developer would know that a prompt is launched even if there is a
>>> mandatory constraint that can't be met, so the developer would likely be
>>> careful and not put things that are not really mandatory as mandatory.
>>>
>>> I would agree to that we have some experimenting left to do in terms of
>>> how to prompt, but perhaps that can be left to implementations? In the
>>> same way as the current consent prompting is.
>>>
>>>> - Jim
>>>>
>>>> -----Original Message----- From: Stefan Håkansson LK
>>>> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Thursday, December
>>>> 05, 2013 4:48 AM To: Jim Barnett; Martin Thomson; Cullen Jennings
>>>> (fluffy) Cc: Silvia Pfeiffer;public-media-capture@w3.org; Adam
>>>> Bergkvist Subject: Re: Bug 23934 - Proposal: Always launch permission
>>>> prompt to avoid leakage
>>>>
>>>> I think my views are quite similar to Martin's.
>>>>
>>>> I think that perhaps we could leave a lot of this up to
>>>> implementations (e.g. what kind of info is displayed if no device
>>>> that meets the mandatory constraints is available). For the case were
>>>> suitable devices are found, the current draft says "Prompt the user
>>>> in a user agent specific manner for permission...". We can use
>>>> similar phrasing for cases when no devices that meet mandatory
>>>> constraints are found.
>>>>
>>>> On 2013-12-03 18:11, Jim Barnett wrote:
>>>>> I'm trying to understand the proposal better, and have a couple of
>>>>> questions:
>>>>>
>>>>> 1. In the case where one or more devices meet the mandatory
>>>>> constraints, are they the only ones that are presented to the
>>>>> user?
>>>> This question is not related to the "Always launch permission
>>>> prompt" proposal per se, it is related to mandatory constraints used
>>>> with gUM.
>>>>
>>>> It is something we need to agree on; and the first level we need to
>>>> agree on is whether this must be specified or can be left to the UA
>>>> to decide.
>>>>
>>>>
>>>>> 2. In the case where no device meets the mandatory constraints, do
>>>>> we assume that the UA can explain the constraints clearly enough so
>>>>> that the user can tell what sort of device is needed?
>>>> Perhaps we do not need to spec this, perhaps something like "Inform
>>>> the user in a user agent specific manner that the page asked for
>>>> access to cameras/microphones but that no devices that met the
>>>> requirements were found." is enough.
>>>>
>>>>> 3. In the case where no device meets the constraints, do we present
>>>>> a list of all attached devices to the user?  Would we let him
>>>>> select a microphone when the app has asked for a camera?
>>>> Of course not. The first level of constraints with gUM is "audio" or
>>>> "video", and you can't use one in place of the other.
>>>>
>>>>> - Jim
>>>>>
>>>>> -----Original Message----- From: Martin Thomson
>>>>> [mailto:martin.thomson@gmail.com] Sent: Tuesday, December 03, 2013
>>>>> 12:01 PM To: Cullen Jennings (fluffy) Cc: Silvia Pfeiffer; Stefan
>>>>> Hakansson LK;public-media-capture@w3.org; Jim Barnett; Adam
>>>>> Bergkvist Subject: Re: Bug 23934 - Proposal: Always launch
>>>>> permission prompt to avoid leakage
>>>>>
>>>>> On 3 December 2013 08:57, Cullen Jennings (fluffy)
>>>>> <fluffy@cisco.com>  wrote:
>>>>>> The question is what happened when none of the devices meet the
>>>>>> constraints. Do you pop a dialog up to the user that says "Hey,
>>>>>> your web page wanted to something that they can not have. Wait
>>>>>> some random amount of time before deciding to click OK to dismiss
>>>>>> this dialog".
>>>>> You are right, that is the question.
>>>>>
>>>>> That's an implementation choice as far as I'm concerned.  The site
>>>>> isn't going to get an answer, so I'm not sure that there is much
>>>>> point in asking a user, but I'm of the opinion that a user should
>>>>> be able to make the choice still.  Maybe the "choice" involves
>>>>> plugging a device in that does meet constraints.
>