Re: Formalizing our permissions model using the Permissions API

On 30/11/15 09:51, Harald Alvestrand wrote:
> Den 30. nov. 2015 09:27, skrev Stefan Håkansson LK:
>> On 30/11/15 08:54, Harald Alvestrand wrote:
>>> Den 30. nov. 2015 08:48, skrev Stefan Håkansson LK:
>>>> This looks quite good IMO.
>>>>
>>>> But, for microphone and camera permissions, would it not make sense to
>>>> have a list of devideIds? For the situation where the UA has stored
>>>> permissions (for this origin) to use camera A and B but not C?
>>>>
>>>> (Slightly different from all-cameras).
>>>
>>> My reading of the permissions model is that if a permission is qualified
>>> by an ID, each different ID value turns the permisison into a different
>>> permission.
>>
>> I think you are right.
>>
>>>
>>> So if there existed 3 cameras A, B and C, I have permissions to camera A
>>> and B, I would have the permissions "camera A" and "camera B", and there
>>> would exist a permission "camera C" that I did not have.
>>
>> What would happen if you called navigator.permissions.query without
>> supplying a deviceId? E.g.
>>
>> navigator.permissions.query({name:'camera'})
>
> I think this is supposed to return "undefined", since no such permission
> exists.

You're basically proposing

dictionary DevicePermissionDescriptor: PermissionDescriptor {
     required DOMString deviceId;
}

("required" added).

After some thinking, I think that would work. I was after allowing to 
check for "camera" only to see if _any_ camera is available for use, but 
the application could just as well loop over the deviceId:s.


>
> It would also be possible to interpret this as permissions for the
> default device, if one exists - that would make sense for the speaker
> permission, since one has a default device in that case, but wouldn't
> make sense for video cameras, where we don't.
>
> Perhaps simplest to say that "if you care about checking permissions,
> you have to enumerate devices first".

Exactly.

>

Received on Monday, 30 November 2015 14:32:28 UTC