--- a/encrypted-media/encrypted-media-wd.html Mon Feb 03 21:37:49 2014 -0800
+++ b/encrypted-media/encrypted-media-wd.html Mon Feb 03 21:48:13 2014 -0800
@@ -94,7 +94,7 @@
<h2 id="draft-date">W3C Working Draft 13 February 2014</h2>
<dl>
<dt>This Version:</dt>
- <dd><a href="http://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html">http://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html</a></dd>
+ <dd><a href="http://www.w3.org/TR/2013/WD-encrypted-media-20140213/">http://www.w3.org/TR/2013/WD-encrypted-media-20140213/</a></dd>
<dt>Latest Published Version:</dt>
<dd><a href="http://www.w3.org/TR/encrypted-media/">http://www.w3.org/TR/encrypted-media/</a></dd>
<dt>Latest editor's draft:</dt>
@@ -1144,13 +1144,13 @@
<p>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.</p>
<p>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 implementers must provide sufficient information and controls to user agent implementers to enable them to implement appropriate techniques to ensure users have control over their privacy, including but not limited to the techniques described below.</p>
- <h3>7.1. Information disclosed by EME and Key Systems</h3>
+ <h3 id="privacy-disclosure">7.1. Information disclosed by EME and Key Systems</h3>
<p>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.</p>
- <h4>7.1.1 Fingerprinting</h4>
+ <h4 id="privacy-fingerprinting">7.1.1 Fingerprinting</h4>
<p>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.</p>
- <h4>7.1.2 Tracking</h4>
+ <h4 id="privacy-tracking">7.1.2 Tracking</h4>
<p>User-specific information may be obtained over the EME API in two ways: through detection of stored keys and through Key System messages.</p>
<p>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 not 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:</p>
@@ -1194,7 +1194,7 @@
<p>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.</p>
<p>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.</p>
- <h3>7.2. Information stored on user devices</h3>
+ <h3 id="privacy-storedinfo">7.2. Information stored on user devices</h3>
<p>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.</p>
<p>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.</p>
<p>There are a number of techniques that can be used to mitigate these privacy risk to users:</p>
@@ -1292,7 +1292,7 @@
if (!video.<a href="#dom-attrmediakeys">mediaKeys</a>)
video.<a href="#dom-setmediakeys">setMediaKeys</a>(new <a href="#dom-mediakeys">MediaKeys</a>("org.w3.clearkey"));
- if (!video.<a href="#dom-keys">keys</a>)
+ if (!video.<a href="#dom-attrmediakeys">mediaKeys</a>)
throw "Could not create MediaKeys";
var keySession = video.<a href="#dom-attrmediakeys">mediaKeys</a>.<a href="#dom-createsession">createSession</a>();
--- a/encrypted-media/encrypted-media.html Mon Feb 03 21:37:49 2014 -0800
+++ b/encrypted-media/encrypted-media.html Mon Feb 03 21:48:13 2014 -0800
@@ -1144,13 +1144,13 @@
<p>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.</p>
<p>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 implementers must provide sufficient information and controls to user agent implementers to enable them to implement appropriate techniques to ensure users have control over their privacy, including but not limited to the techniques described below.</p>
- <h3>7.1. Information disclosed by EME and Key Systems</h3>
+ <h3 id="privacy-disclosure">7.1. Information disclosed by EME and Key Systems</h3>
<p>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.</p>
- <h4>7.1.1 Fingerprinting</h4>
+ <h4 id="privacy-fingerprinting">7.1.1 Fingerprinting</h4>
<p>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.</p>
- <h4>7.1.2 Tracking</h4>
+ <h4 id="privacy-tracking">7.1.2 Tracking</h4>
<p>User-specific information may be obtained over the EME API in two ways: through detection of stored keys and through Key System messages.</p>
<p>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 not 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:</p>
@@ -1194,7 +1194,7 @@
<p>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.</p>
<p>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.</p>
- <h3>7.2. Information stored on user devices</h3>
+ <h3 id="privacy-storedinfo">7.2. Information stored on user devices</h3>
<p>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.</p>
<p>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.</p>
<p>There are a number of techniques that can be used to mitigate these privacy risk to users:</p>
@@ -1292,7 +1292,7 @@
if (!video.<a href="#dom-attrmediakeys">mediaKeys</a>)
video.<a href="#dom-setmediakeys">setMediaKeys</a>(new <a href="#dom-mediakeys">MediaKeys</a>("org.w3.clearkey"));
- if (!video.<a href="#dom-keys">keys</a>)
+ if (!video.<a href="#dom-attrmediakeys">mediaKeys</a>)
throw "Could not create MediaKeys";
var keySession = video.<a href="#dom-attrmediakeys">mediaKeys</a>.<a href="#dom-createsession">createSession</a>();
--- a/encrypted-media/encrypted-media.xml Mon Feb 03 21:37:49 2014 -0800
+++ b/encrypted-media/encrypted-media.xml Mon Feb 03 21:48:13 2014 -0800
@@ -1093,13 +1093,13 @@
<p>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.</p>
<p>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 implementers must provide sufficient information and controls to user agent implementers to enable them to implement appropriate techniques to ensure users have control over their privacy, including but not limited to the techniques described below.</p>
- <h3>7.1. Information disclosed by EME and Key Systems</h3>
+ <h3 id="privacy-disclosure">7.1. Information disclosed by EME and Key Systems</h3>
<p>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.</p>
- <h4>7.1.1 Fingerprinting</h4>
+ <h4 id="privacy-fingerprinting">7.1.1 Fingerprinting</h4>
<p>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.</p>
- <h4>7.1.2 Tracking</h4>
+ <h4 id="privacy-tracking">7.1.2 Tracking</h4>
<p>User-specific information may be obtained over the EME API in two ways: through detection of stored keys and through Key System messages.</p>
<p>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 not 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:</p>
@@ -1143,7 +1143,7 @@
<p>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.</p>
<p>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.</p>
- <h3>7.2. Information stored on user devices</h3>
+ <h3 id="privacy-storedinfo">7.2. Information stored on user devices</h3>
<p>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.</p>
<p>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.</p>
<p>There are a number of techniques that can be used to mitigate these privacy risk to users:</p>
@@ -1240,7 +1240,7 @@
if (!video.<precoderef prefix="attr">mediaKeys</precoderef>)
video.<premethodref>setMediaKeys</premethodref>(new <precoderef>MediaKeys</precoderef>("org.w3.clearkey"));
- if (!video.<precoderef>keys</precoderef>)
+ if (!video.<precoderef prefix="attr">mediaKeys</precoderef>)
throw "Could not create MediaKeys";
var keySession = video.<precoderef prefix="attr">mediaKeys</precoderef>.<premethodref>createSession</premethodref>();