Re: [Bug 22354] Security and Privacy Considerations section needed

This does indeed look like a good start and should be included in the editors draft.

the section should probably be titled “Security and Privacy Considerations”

It might be worth sharing with PING for review via the PING list ( http://www.w3.org/Privacy/ )

Are there any confidentiality issues to call out (e.g. " a secure channel should be used to protect confidentiality from passive monitoring"?)


regards, frederick

Frederick Hirsch, Nokia
@fjhirsch

On Apr 25, 2014, at 3:14 AM, ext bugzilla@jessica.w3.org <bugzilla@jessica.w3.org> wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22354
> 
> --- Comment #4 from Harald Alvestrand <harald@alvestrand.no> ---
> Proposed text, based on a proposal from April 23 and subsequent discussion:
> 
> Security considerations
> 
> This section is non-normative; it specifies no new behaviour, but instead
> summarizes information already present in other parts of the specification.
> 
> 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.
> 
> Authorization may be given on a case-by-case basis, or be persistent. In the
> case of a case-by-case authorization, it is important that the user be able to
> say “no” in a way that prevents the UI from blocking user interaction until
> permission is given - either by offering a way to say a “persistent NO” or by
> not using a modal permissions dialog.
> 
> In the case of persistent authorization, it is important that it’s easy to find
> the list of granted permissions and revoke permissions that the user wishes to
> revoke.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

Received on Friday, 2 May 2014 15:02:50 UTC