[Bug 22910] Needs non-normative Privacy Consideration section

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910

--- Comment #6 from Mark Watson <watsonm@netflix.com> ---
Here is a detailed proposal for the privacy section. It is modeled on material
in the WebCrypto Key Discovery draft which is in turn modelled on material for
from IndexedDB / Web Storage, modified appropriately and taking into account
the comments made above.

I'm open to suggestions for a better way to share this (e.g. with formatting
etc.)

"8. Privacy considerations

The presence or use of Key Systems on a user’s device raises a number of
privacy issues, falling into two categories: (a) user-specific information that
may be disclosed by the EME interface itself, or within messages from Key
Systems and (b) user-specific information that may be persistently stored on
the users device.

User Agents should take responsibility for providing users with adequate
control over their own privacy. Since User Agents may integrate with third
party CDM implementations, CDM implementors must provide sufficient information
and controls to user agent implementors to enable them to implement appropriate
techniques to ensure users have control over their privacy, including but not
limited to the techniques described below.

8.1. Information disclosed by EME and Key Systems

Concerns regarding information disclosed by EME and Key Systems fall into two
categories, concerns about non-specific information that may nevertheless
contribute to the possibility of fingerprinting a user agent or device and
user-specific information that may be used directly for user tracking.

8.1.1 Fingerprinting

Malicious applications may be able to fingerprint users or user agents by
detecting or enumerating the list of key systems that are supported and related
information. If proper origin protections are not provided this could include
detection of sites that have been visited and information stored for those
sites. In particular, Key Systems should not share key or other data between
sites that are not CORS-same-origin.

8.1.2 Tracking

User-specific information may be obtained over the EME API in two ways: through
detection of stored keys and through Key System messages.

Key Systems may access or create persistent or semi-persistent identifiers for
a device or user of a device. In some cases these identifiers may be bound to a
specific device in a secure manner. If these identifiers are present in Key
System messages, then devices and/or users may be tracked. If the mitigations
below are applied this could include both tracking of users / devices over time
and associating multiple users of a given device. If not mitigated, such
tracking may take three forms depending on the design of the Key System:
- in all cases, such identifiers are expected to be available to sites and/or
servers that fully support the Key System (and thus can interpret Key System
messages) enabling tracking by such sites.
- if identifiers exposed by Key Systems are not origin-specific, then two sites
and/or servers that fully support the Key System may collude to track the user
- if a Key System messages contains information derived from a user identifier
in a consistent manner, for example such that a portion of the initial Key
System message for a specific content item does not change over time and is
dependent on the user identifier, then this information could be used by any
application to track the device or user over time.

If a Key System permits keys to be stored and to be re-used between origins,
then it may be possible for two origins to collude and track a unique user by
recording their ability to access a common key.

Finally, if any user interface for user control of Key Systems presents data
separately from data in HTTP session cookies or persistent storage, then users
are likely to modify site authorization or delete data in one and not the
others. This would allow sites to use the various features as redundant backup
for each other, defeating a user's attempts to protect his privacy.

There are a number of techniques that can be used to mitigate these risks of
tracking without user consent:

User deletion of persistent identifiers

User agents could provide users with the ability to clear any persistent
identifiers maintained by Key Systems.

Use of (non-reversible) per-origin identifiers

The user / device identifier exposed by a Key System may be different for each
origin, either by allocation of different identifiers for different origins or
by use of a non-reversible origin-specific mapping from an origin-independent
identifier.

Encryption of user identfiiers

User identifiers in Key System messages could be encrypted, together with a
timestamp or nonce, such that the Key System messages are always different.
This would prevent the use of Key System messages for tracking except by
applications fully supporting the Key System.

Site-specific white-listing of access to each Key System

User agents could require the user to explicitly authorize access by each site
to each Key System. User agents should enable users to revoke this
authorization either temporarily or permanently.

Treating Key System persistent identifiers as cookies

User agents should present the presence of persistent identifiers stored by Key
Systems to the user in a way that associates them strongly with HTTP session
cookies. This might encourage users to view such identifiers with healthy
suspicion.

Shared blacklists

User agents may allow users to share their Key System domain blacklists. This
would allow communities to act together to protect their privacy.

User alerts / prompts

User Agents could ensure that users are fully informed and / or give explicit
consent before identifiers are exposed in messages from Key Systems.

User controls to disable Key Systems or Key System use of identifiers

User Agents could provide users with a global control of whether a Key System
is enabled / disabled and / or whether Key System use of user / device
identifiers is enabled or disabled (if supported by the Key System).

While these suggestions prevent trivial use of this feature for user tracking,
they do not block it altogether. Within a single domain, a site can continue to
track the user during a session, and can then pass all this information to a
third party along with any identifying information (names, credit card numbers,
addresses) obtained by the site. If a third party cooperates with multiple
sites to obtain such information, and if identifiers are not per-origin, then a
profile can still be created.

It is important to note that identifiers that are non-clearable,
non-origin-specific or hardware-bound exceed the tracking impact of existing
techniques such as Cookies or session identifiers embedded in URLs.

Thus, in addition to the various mitigations described above, if a browser
supports a mode of operation intended to preserve user anonymity, then User
Agent implementers should carefully consider whether access to Key Systems
should be disabled in this mode.

8.2. Information stored on user devices

Key Systems may store information on a user’s device, or user agents may store
information on behalf of Key Systems. Potentially, this could reveal
information about a user to another user of the same device, including
potentially the origins that have used a particular Key System (i.e. sites
visited) or even the content that has been decrypted using a Key System.

If information stored by one origin affects the operation of the Key System for
another origin, then potentially the sites visited or content viewed by a user
on one site may be revealed to another, potentially malicious, site.

There are a number of techniques that can be used to mitigate these privacy
risk to users:

Origin-specific Key System storage

User agents may require that some or all of the Key System’s persistently
stored data is stored in an origin-specific way.

User deletion of Key System storage

User agents may present the user with a way to delete Key System storage for a
specific origin or all origins.

Treating Key System stored data like cookies / Web Storage

User agents should present the presence of persistent data stored by Key
Systems to the user in a way that associates it strongly with HTTP session
cookies and/or Web Storage. This might encourage users to view such data with
healthy suspicion.

Encryption or obfuscation of Key System stored data

User agents should treat data stored by Key Systems as potentially sensitive;
it is quite possible for user privacy to be compromised by the release of this
information. To this end, user agents should ensure that such data is securely
stored and when deleting data, it is promptly deleted from the underlying
storage."

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 5 November 2013 20:24:34 UTC