Re: gUM and persistent permissions

Speaking of timeouts, what happens multiple requests come down the same 
socket? This could correspond to the case where the user grants camera 
access, and proceeds to the next page (using the same connection). In 
such a case, should the UA really be forced to re-prompt?

Gili

On 29/04/2014 9:18 AM, Jim Barnett wrote:
> I think we need a separate section on permissions in gUM, which would  
> include Martin's text.  It should also include some discussion of how 
> permission is requested/presented.   Does the UA ask for permission 
> only for the best device as selected by the constraints, or can the UA 
> display other devices for him to select? Maybe it's completely up to 
> the UA, but then we should say so.   How long does permission 
> persist?  Until the tab is closed? Can there be an inactivity 
> timeout?  Finally, if we're going to say that the UA must not rely on 
> persisted permissions in some cases, we probably also should say that 
> the may do so in other cases.
>
> - Jim
> On 4/29/2014 3:29 AM, Harald Alvestrand wrote:
>> On 04/28/2014 09:00 PM, Martin Thomson wrote:
>>> On 28 April 2014 11:52, Martin Thomson <martin.thomson@gmail.com> 
>>> wrote:
>>>> We talked in the past about forbidding the persistence of permissions
>>>> for non-secure origins (e.g., http://example.com).
>>>>
>>>> I know that we've talked about this on numerous occasions and we seem
>>>> to have had agreement, but I can't find any record of it in the spec.
>>> In the interests of forward progress, how about:
>>>
>>> User agents MUST NOT rely on persisted permissions for origins that
>>> are not strongly authenticated, such as "http" origins.  Such origins
>>> can be trivially spoofed by a network attacker, which could be
>>> exploited to gain access to media devices.
>>>
>>> Throw in there anywhere.  Maybe in with Harald's newly proposed
>>> security/privacy considerations.
>>>
>> Actually it's in an IETF document.
>>
>> draft-ietf-rtcweb-security-arch-09 section 5.2
>>
>>    Because HTTP origins cannot be securely established against network
>>    attackers, implementations MUST NOT allow the setting of permanent
>>    access permissions for HTTP origins.  Implementations MAY also opt to
>>    refuse all permissions grants for HTTP origins, but it is RECOMMENDED
>>    that currently they support one-time camera/microphone access.
>>
>> Should we repeat the requirement here in the W3C document?
>>
>> If so, I think it should be in section 10, "Obtaining local 
>> multimedia content".
>> There's a "Best Practice 1: Resource reservation" that is relevant, 
>> but I think we should have a hard requirement in a section that's not 
>> labelled "Implementation Suggestions", so I suggest we add a new 
>> section here.
>>
>>          Harald
>>
>>
>>
>

Received on Tuesday, 29 April 2014 15:36:22 UTC