KHS Notes for PING Review: MediaStream Recording Draft

All,

 

In preparation for my contribution to the PING Review: MediaStream Recording
Draft, I first reviewed:



*         WebRTC Security Architecture - Protocols for real-time
communications between Web browsers

http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_tex
t=1 

*         Security Considerations for WebRTC

http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1%2
0[2
<http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1%
20%5b2> ] 

*         Media Capture and Streams - W3C Working Draft 03 September 2013 -
which defines a set of JavaScript APIs that allow local media, including
audio and video, to be requested from a platform.

http://www.w3.org/TR/mediacapture-streams/ 

 

My recommendations for this draft (can be found below): 

*         MediaStream Recording - W3C Editor's Draft 20 August 2014 - a
recording API for use with MediaStreams
http://w3c.github.io/mediacapture-record/MediaRecorder.html 

 

 

NOTE: I am unaware if there was a PING review of Media Capture and Streams
draft itself. If so, I would love to get a chance to review that before
providing my final recommendations for PING to consider.

 

The Media Capture Task Force is asking for a Privacy review but it is
unclear whether that request is specifically related to the spec itself - or
- around the broader idea of privacy consideration as it relates to
capturing media via webcam recordings in general (does the device have
permission to capture an individual, etc), and for surveillance purposes. I
have chosen only to address the privacy/security related to the draft
technical spec.

 

 

Introduction: 
Media Streams. Access to multimedia streams (video, audio, or both) from
local devices (video cameras, microphones, Web cams) can have a number of
uses, such as real-time communication, recording, and surveillance. The
Media Capture and Streams draft defines the APIs used to get access to local
devices that can generate multimedia stream data. It also defines the stream
API by which JavaScript is able to manipulate the stream data or otherwise
process it. The draft defines conformance criteria that apply to a single
product: the user agent (browser) that implements the interfaces that it
contains.

 

The RTCPeerConnection object acts simultaneously as both a sink (image,
audio, video) and a source for over-the-network streams. As a sink, it has
source transformational capabilities (e.g., lowering bit-rates, scaling-up
or down resolutions, adjusting frame-rates), and as a source it could have
its own states changed by a track source (though in this specification
sources with the remote
<http://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack-remote>
attribute set to true do not consider the current constraints applied to a
track). 

 

This review of MediaStream Recording is related to the recording API for
that draft spec, that uses JavaScript or ECMAScript. The Event Handlers are
specific to HTML5. The terms event handlers
<http://dev.w3.org/html5/spec/webappapis.html#event-handlers>  and event
handler event types
<http://dev.w3.org/html5/spec/webappapis.html#event-handler-event-type>  are
defined in [ <http://www.w3.org/TR/mediacapture-streams/#bib-HTML5> HTML5].

 

 

Recommendations:

 

We would want to see a standard W3C Privacy/Security Considerations section
included, which has additional language specific to the vulnerabilities
presented by the use of scripting.

 

IF, a media stream recording from a local device is distributed, shared or
accessed over the web:

*         We would want to see that Implementations can ensure that only
Authenticated Entities can have access to the data and preferences of the
user - and - only have/maintain it for a single session.

 

*         We would want to see that services and media are delivered only
from trusted entities via HTTPS (or other similarly secure method - such as
peers whose origin can be verify cryptographically -optimally via
DTLS-SRTP.). And perhaps somehow check that the servers are also
authenticated by an external identity service, using the SSL/TLS certificate
infrastructure.

 

*         We would want the spec to allow for support of Identity Provider
(IdP) use that supports protocols (such as OpenID, OAuth, or BrowserID) that
can be used to demonstrate identity to other parties. Ideally, we would want
to see that a persistent separation of identity provision and signaling
service [maybe: in the communication stream].

 

*         We would want the PeerConnection (RTCPeerConnection) assertion to
allow binding other information to the identity besides a fingerprint but at
minimum it needs to bind a fingerprint (which uses the fingerprinting
surface of the UA). Or allow for anonymous communication. Allows users to
share a set of secure data and/or media channels with keys which are not
known to any third-party, and exchange data protected by those keys
negotiated by DTLS. Must allow for sending/receiving keepalive signals.

 

*         We would want to see that any associated clients MUST treat HTTP
and HTTPS origins as different permissions domains.

 

*         We would want to see that implementations MUST obtain explicit
user consent prior to providing access to media, media streams and services.
implementations MUST NOT allow the setting of permanent access permissions
for HTTP origins.

 

*         We would want to see that implementations allow for IP Location
Privacy functions. Users should be able to participate in communications
without revealing their location.

 

*         We would want to see that personal identifier are not persist when
a session ends.

 

*         Implementations should allow for Individual Consent or
Cryptographic Consent.

o   Individual Consent: Ask the user for permission for media recording.

o   Cryptographic Consent: Only allow media recording to a given set of peer
keying material or to a cryptographically established identity.

 

 

IF, a media stream recording is distributed or accessed only locally through
the users private peer devices - and - without using the web outside a
secure firewall:

 

I am not sure that there are any privacy considerations.

 

* katie *

 

Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton,
VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile |
Office: 703-371-5545