Re: Security considerations section - a proposal

On 04/23/2014 08:07 PM, Stefan Håkansson LK wrote:
> One thing that should probably be added is something about preventing 
> selection looping as in the File API [1].
Not in the same form - the current advice doesn't mandate that a picker 
be part of the UI. (It isn't for Chrome). In Chrome's UI, I think we by 
default persist "no" as well as "yes" selections.

>
> We should probably also add something about stored permissions being 
> revocable as in geolocation API [2].

Yep.

Added some language for the next version.

>
> [1] http://www.w3.org/TR/FileAPI/#security-discussion
>
> [2] http://www.w3.org/TR/geolocation-API/#security
>
> On 23/04/14 13:51, Harald Alvestrand wrote:
>> I've tried to draft a security considerations section for the media 
>> capture and streams document.
>> I've been working from the idea that a security considerations 
>> section should not specify any new technology or features, but give 
>> an overview of the security issues that are involved in using the 
>> functionality, and mentioning the features that are particularly 
>> important in mitigating the risks involved.
>>
>> Here's my proposed text. Let's do a round of discussion on the list 
>> before I enter this into the buganizer and from there into the document.
>>
>>
>> Security considerations
>>
>> This section is non-normative.
>>
>> *
>>
>> This document extends the Web platform with the ability to manage 
>> input devices for media - in this iteration, microphones and cameras.
>>
>> It also allows the manipulation of audio output devices (speakers and 
>> headphones).
>>
>>
>> Without authorization (to the “drive-by web”), it offers the ability 
>> to tell how many devices there are of each class. The identifiers for 
>> the devices are designed to not be useful for a fingerprint that can 
>> track the user between origins, but the number of devices adds to the 
>> fingerprint surface.
>>
>>
>> When authorization is given, this document describes how to get 
>> access to, and use, media data from the devices mentioned. This data 
>> may be sensitive; advice is given that indicators should be supplied 
>> to indicate that devices are in use, but both the nature of 
>> authorization and the indicators of in-use devices are platform 
>> decisions.
>>
>>
>> A mechanism, PeerIdentity, is provided that gives Javascript the 
>> option of requesting media that the Javascript cannot access, but can 
>> only be sent to certain other entities.
>>
>> *
>>
>