--- a/encrypted-media/encrypted-media.html Thu Nov 14 12:11:32 2013 +0800
+++ b/encrypted-media/encrypted-media.html Thu Nov 14 12:20:20 2013 +0800
@@ -101,7 +101,7 @@
A list of current W3C publications and the latest revision of this technical report can be found in the
<a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.
</em></p>
- <p>Implementors should be aware that this specification is not stable. <strong>Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.</strong> Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.</p>
+ <p>Implementers should be aware that this specification is not stable. <strong>Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.</strong> Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.</p>
<p>
This document was published by the <a href="http://www.w3.org/html/wg/">HTML working group</a> as an Editor's Draft.
Please submit comments regarding this document by using the W3C's (<a href="https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=Encrypted%20Media%20Extensions">public bug database</a>) with the product set to <kbd>HTML WG</kbd> and the component set to
@@ -1089,7 +1089,7 @@
<p>Key system implementations must consider initialization data, key data and media data as potential attack vectors and must take care to safely parse, decrypt etc. initialization data, key data and media data. User Agents may want to validate data before passing it to the CDM, especially if the CDM does not run in the same (sandboxed) context as the DOM (i.e. rendering). </p>
<p>It is STRONGLY RECOMMENDED that key data and media data do not contain active content [<a href="http://www.ietf.org/rfc/rfc4949.txt" title="Shirey, R., Internet Security Glossary, Version 2, RFC 4949, August 2007, IETF">SECURITY GLOSSARY</a>]. If a Key System implementation supports the interpretation or execution of such active content then it is STRONGLY RECOMMENDED that User Agents make use of sandbox techniques to restrict the scope of access that the CDM has to the user's device. In any case, User Agent and Key System implementers should consider the threats, risks, and safeguards described in [<span title="Jansen, W, et al., Guidelines on Active Content and Mobile Code, Special Publication 800-28, Version 2, 2008, National Institute of Standards and Technology (NIST)">ACTIVE CONTENT</span>].</p>
- <p>User Agents are responsible for providing users with a secure way to browse the web. 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 properly asses the security implications of integrating with the Key System.</p>
+ <p>User Agents are responsible for providing users with a secure way to browse the web. 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 properly asses the security implications of integrating with the Key System.</p>
<p>Note: unsandboxed CDMs (or CDMs that use platform features) and UAs that use them must be especially careful in all areas of security, including parsing of key and media data, etc. due to the potential for compromises to provide access to OS/platform features, interact with or run as root, access drivers, kernel, firmware, hardware, etc., all of which may not be written to be robust against hostile software or web-based attacks. Additionally, CDMs may not be updated with security fixes as frequently, especially when part of the OS, platform or hardware.</p>
</div>
@@ -1100,7 +1100,7 @@
<div class="issue-title"><span>Issue 3</span></div>Note: This section is not final and review is welcome.</div>
<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 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.</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>8.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>
@@ -1111,7 +1111,7 @@
<h4>8.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 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>
+ <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>
<ul>
<li>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.</li>
<li>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</li>
--- a/encrypted-media/encrypted-media.xml Thu Nov 14 12:11:32 2013 +0800
+++ b/encrypted-media/encrypted-media.xml Thu Nov 14 12:20:20 2013 +0800
@@ -98,7 +98,7 @@
A list of current W3C publications and the latest revision of this technical report can be found in the
<a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.
</em></p>
- <p>Implementors should be aware that this specification is not stable. <strong>Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.</strong> Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.</p>
+ <p>Implementers should be aware that this specification is not stable. <strong>Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.</strong> Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.</p>
<p>
This document was published by the <a href="http://www.w3.org/html/wg/">HTML working group</a> as an Editor's Draft.
Please submit comments regarding this document by using the W3C's (<a href="https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=Encrypted%20Media%20Extensions">public bug database</a>) with the product set to <kbd>HTML WG</kbd> and the component set to
@@ -1027,7 +1027,7 @@
<p>Key system implementations must consider initialization data, key data and media data as potential attack vectors and must take care to safely parse, decrypt etc. initialization data, key data and media data. User Agents may want to validate data before passing it to the CDM, especially if the CDM does not run in the same (sandboxed) context as the DOM (i.e. rendering). </p>
<p>It is STRONGLY RECOMMENDED that key data and media data do not contain active content [<a href="http://www.ietf.org/rfc/rfc4949.txt" title="Shirey, R., Internet Security Glossary, Version 2, RFC 4949, August 2007, IETF">SECURITY GLOSSARY</a>]. If a Key System implementation supports the interpretation or execution of such active content then it is STRONGLY RECOMMENDED that User Agents make use of sandbox techniques to restrict the scope of access that the CDM has to the user's device. In any case, User Agent and Key System implementers should consider the threats, risks, and safeguards described in [<span title="Jansen, W, et al., Guidelines on Active Content and Mobile Code, Special Publication 800-28, Version 2, 2008, National Institute of Standards and Technology (NIST)">ACTIVE CONTENT</span>].</p>
- <p>User Agents are responsible for providing users with a secure way to browse the web. 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 properly asses the security implications of integrating with the Key System.</p>
+ <p>User Agents are responsible for providing users with a secure way to browse the web. 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 properly asses the security implications of integrating with the Key System.</p>
<p>Note: unsandboxed CDMs (or CDMs that use platform features) and UAs that use them must be especially careful in all areas of security, including parsing of key and media data, etc. due to the potential for compromises to provide access to OS/platform features, interact with or run as root, access drivers, kernel, firmware, hardware, etc., all of which may not be written to be robust against hostile software or web-based attacks. Additionally, CDMs may not be updated with security fixes as frequently, especially when part of the OS, platform or hardware.</p>
</div>
@@ -1037,7 +1037,7 @@
<div class="issue"><div class="issue-title"><span>Issue 3</span></div>Note: This section is not final and review is welcome.</div>
<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 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.</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>8.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>
@@ -1048,7 +1048,7 @@
<h4>8.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 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>
+ <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>
<ul>
<li>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.</li>
<li>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</li>