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

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

Received on Tuesday, 10 December 2013 01:27:14 UTC