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

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.