W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2014

Re: Security considerations section - a proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 23 Apr 2014 18:07:04 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFD8C6A@ESESSMB209.ericsson.se>
One thing that should probably be added is something about preventing selection looping as in the File API [1].

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

[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.
Received on Wednesday, 23 April 2014 18:07:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:26 UTC