--- a/encrypted-media/encrypted-media.html Thu Nov 14 11:49:29 2013 +0800
+++ b/encrypted-media/encrypted-media.html Thu Nov 14 12:11:32 2013 +0800
@@ -116,7 +116,7 @@
replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
</p>
<p class="non-normative">Note: It is an open issue whether and how the spec should do more to encourage/ensure CDM-level interop. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944">Bug 20944</a>.</p>
- <p class="non-normative">Note: This specification contains sections for describing <a href="#security">security</a> and <a href="#privacy">privacy</a> considerations. These sections are not final and are tracked in <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a> and <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910">Bug 22910</a>.</p>
+ <p class="non-normative">Note: This specification contains sections for describing <a href="#security">security</a> and <a href="#privacy">privacy</a> considerations. These sections are not final and review is welcome.</p>
<p>
This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>.
W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/40318/status" rel="disclosure">public list of any patent disclosures</a> made in connection with
@@ -1082,16 +1082,23 @@
</div>
<h2 id="security">7. Security Considerations</h2>
- <p><i>This section is non-normative.</i></p>
-
+ <div class="nonnormative">
+
+ <div class="issue">
+<div class="issue-title"><span>Issue 2</span></div>Note: This section is not final and review is welcome.</div>
+
<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>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>
<h2 id="privacy">8. Privacy Considerations</h2>
- <p><i>This section is non-normative.</i></p>
+ <div class="nonnormative">
+ <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>
@@ -1144,7 +1151,7 @@
<p>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.</p>
<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>8.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>
@@ -1164,6 +1171,7 @@
<dd>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.</dd>
</dl>
+ </div>
<h2 id="containers">9. Container Guidelines</h2>
<p>This document describes behavior independent of specific media containers.
The following sections provide container-specific details for implementations that choose to support those containers.
--- a/encrypted-media/encrypted-media.xml Thu Nov 14 11:49:29 2013 +0800
+++ b/encrypted-media/encrypted-media.xml Thu Nov 14 12:11:32 2013 +0800
@@ -113,7 +113,7 @@
replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
</p>
<p class="non-normative">Note: It is an open issue whether and how the spec should do more to encourage/ensure CDM-level interop. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944">Bug 20944</a>.</p>
- <p class="non-normative">Note: This specification contains sections for describing <a href="#security">security</a> and <a href="#privacy">privacy</a> considerations. These sections are not final and are tracked in <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a> and <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910">Bug 22910</a>.</p>
+ <p class="non-normative">Note: This specification contains sections for describing <a href="#security">security</a> and <a href="#privacy">privacy</a> considerations. These sections are not final and review is welcome.</p>
<p>
This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>.
W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/40318/status" rel="disclosure">public list of any patent disclosures</a> made in connection with
@@ -1021,16 +1021,21 @@
</div>
<h2 id="security">7. Security Considerations</h2>
- <non-normative-section/>
-
+ <div class="nonnormative">
+
+ <div class="issue"><div class="issue-title"><span>Issue 2</span></div>Note: This section is not final and review is welcome.</div>
+
<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>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>
<h2 id="privacy">8. Privacy Considerations</h2>
- <non-normative-section/>
+ <div class="nonnormative">
+ <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>
@@ -1083,7 +1088,7 @@
<p>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.</p>
<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>8.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>
@@ -1103,6 +1108,7 @@
<dd>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.</dd>
</dl>
+ </div>
<h2 id="containers">9. Container Guidelines</h2>
<p>This document describes behavior independent of specific media containers.
The following sections provide container-specific details for implementations that choose to support those containers.