Re: gUM and persistent permissions

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

-- 
Jim Barnett
Genesys

Received on Tuesday, 29 April 2014 13:19:45 UTC