[EME] Updated Security and Privacy Considerations based on proposals in bugs 22909 and 22910
--- a/encrypted-media/encrypted-media.html Wed Nov 13 16:22:30 2013 -0800
+++ b/encrypted-media/encrypted-media.html Thu Nov 14 09:26:33 2013 +0800
@@ -1084,33 +1084,85 @@
<h2 id="security">7. Security Considerations</h2>
<p><i>This section is non-normative.</i></p>
- <div class="issue">
-<div class="issue-title"><span>Issue 2</span></div>
-<p class=""><a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a> - Needs non-normative Security Considerations section.</p>
-</div>
- <p><em>TODO: the task force has agreed that a security considerations section needs to be added but not what the contents should be. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a></em></p>
-
+ <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>
+
<h2 id="privacy">8. Privacy Considerations</h2>
<p><i>This section is non-normative.</i></p>
- <div class="issue">
-<div class="issue-title"><span>Issue 3</span></div>
-<p class=""><a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910">Bug 22910</a> - Needs non-normative Privacy Consideration section.</p>
-</div>
-
- <h3 id="privacy-fingerprinting">8.1. Fingerprinting</h3>
- <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of key systems that are supported.</p>
+ <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>
- <h3 id="privacy-tracking">8.2. Tracking</h3>
- <p>If user agents permit keys to be re-used between origins, without performing any secondary operations such as key derivation that includes the origin, then it may be possible for two origins to collude
- and track a unique user by recording their ability to access a common key.</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>
- <h3 id="privacy-supercookies">8.3. Super-cookies</h3>
- <p>With the exception of ephemeral keys, its often desirable for applications to strongly associate users with keys. These associations may be used to enhance the security of authenticating to the application,
- such as using a key stored in a secure element as a second factor, or may be used by users to assert some identity, such as an e-mail signing identity. As such, these keys often live longer than their counterparts
- such as usernames and passwords, and it may be undesirable or prohibitive for users to revoke these keys. Because of this, keys may exist longer than the lifetime of the browsing context and beyond the
- lifetime of items such as cookies, thus presenting a risk that a user may be tracked even after clearing such data. This is especially true for keys that were pre-provisioned for particular origins and for
- which no user interaction was provided.</p>
+ <h4>8.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>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>
+ <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>
+ <li>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.</li>
+ </ul>
+
+ <p>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.</p>
+ <p>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.</p>
+ <p>There are a number of techniques that can be used to mitigate these risks of tracking without user consent:</p>
+
+ <dl>
+ <dt>User deletion of persistent identifiers</dt>
+ <dd>User agents could provide users with the ability to clear any persistent identifiers maintained by Key Systems.</dd>
+
+ <dt>Use of (non-reversible) per-origin identifiers</dt>
+ <dd>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.</dd>
+
+ <dt>Encryption of user identifiers</dt>
+ <dd>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.</dd>
+
+ <dt>Site-specific white-listing of access to each Key System</dt>
+ <dd>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.</dd>
+
+ <dt>Treating Key System persistent identifiers as cookies</dt>
+ <dd>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.</dd>
+
+ <dt>Shared blacklists</dt>
+ <dd>User agents may allow users to share their Key System domain blacklists. This would allow communities to act together to protect their privacy.</dd>
+
+ <dt>User alerts / prompts</dt>
+ <dd>User Agents could ensure that users are fully informed and / or give explicit consent before identifiers are exposed in messages from Key Systems.</dd>
+
+ <dt>User controls to disable Key Systems or Key System use of identifiers</dt>
+ <dd>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).</dd>
+ </dl>
+
+ <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>
+ <p>There are a number of techniques that can be used to mitigate these privacy risk to users:</p>
+
+ <dl>
+ <dt>Origin-specific Key System storage</dt>
+ <dd>User agents may require that some or all of the Key System's persistently stored data is stored in an origin-specific way.</dd>
+
+ <dt>User deletion of Key System storage</dt>
+ <dd>User agents may present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
+
+ <dt>Treating Key System stored data like cookies / Web Storage</dt>
+ <dd>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.</dd>
+
+ <dt>Encryption or obfuscation of Key System stored data</dt>
+ <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>
<h2 id="containers">9. Container Guidelines</h2>
<p>This document describes behavior independent of specific media containers.
--- a/encrypted-media/encrypted-media.xml Wed Nov 13 16:22:30 2013 -0800
+++ b/encrypted-media/encrypted-media.xml Thu Nov 14 09:26:33 2013 +0800
@@ -1023,27 +1023,85 @@
<h2 id="security">7. Security Considerations</h2>
<non-normative-section/>
- <div class="issue"><div class="issue-title"><span>Issue 2</span></div><p class=""><a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a> - Needs non-normative Security Considerations section.</p></div>
- <p><em>TODO: the task force has agreed that a security considerations section needs to be added but not what the contents should be. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909">Bug 22909</a></em></p>
-
+ <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>
+
<h2 id="privacy">8. Privacy Considerations</h2>
<non-normative-section/>
- <div class="issue"><div class="issue-title"><span>Issue 3</span></div><p class=""><a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910">Bug 22910</a> - Needs non-normative Privacy Consideration section.</p></div>
-
- <h3 id="privacy-fingerprinting">8.1. Fingerprinting</h3>
- <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of key systems that are supported.</p>
+ <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>
- <h3 id="privacy-tracking">8.2. Tracking</h3>
- <p>If user agents permit keys to be re-used between origins, without performing any secondary operations such as key derivation that includes the origin, then it may be possible for two origins to collude
- and track a unique user by recording their ability to access a common key.</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>
- <h3 id="privacy-supercookies">8.3. Super-cookies</h3>
- <p>With the exception of ephemeral keys, its often desirable for applications to strongly associate users with keys. These associations may be used to enhance the security of authenticating to the application,
- such as using a key stored in a secure element as a second factor, or may be used by users to assert some identity, such as an e-mail signing identity. As such, these keys often live longer than their counterparts
- such as usernames and passwords, and it may be undesirable or prohibitive for users to revoke these keys. Because of this, keys may exist longer than the lifetime of the browsing context and beyond the
- lifetime of items such as cookies, thus presenting a risk that a user may be tracked even after clearing such data. This is especially true for keys that were pre-provisioned for particular origins and for
- which no user interaction was provided.</p>
+ <h4>8.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>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>
+ <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>
+ <li>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.</li>
+ </ul>
+
+ <p>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.</p>
+ <p>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.</p>
+ <p>There are a number of techniques that can be used to mitigate these risks of tracking without user consent:</p>
+
+ <dl>
+ <dt>User deletion of persistent identifiers</dt>
+ <dd>User agents could provide users with the ability to clear any persistent identifiers maintained by Key Systems.</dd>
+
+ <dt>Use of (non-reversible) per-origin identifiers</dt>
+ <dd>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.</dd>
+
+ <dt>Encryption of user identifiers</dt>
+ <dd>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.</dd>
+
+ <dt>Site-specific white-listing of access to each Key System</dt>
+ <dd>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.</dd>
+
+ <dt>Treating Key System persistent identifiers as cookies</dt>
+ <dd>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.</dd>
+
+ <dt>Shared blacklists</dt>
+ <dd>User agents may allow users to share their Key System domain blacklists. This would allow communities to act together to protect their privacy.</dd>
+
+ <dt>User alerts / prompts</dt>
+ <dd>User Agents could ensure that users are fully informed and / or give explicit consent before identifiers are exposed in messages from Key Systems.</dd>
+
+ <dt>User controls to disable Key Systems or Key System use of identifiers</dt>
+ <dd>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).</dd>
+ </dl>
+
+ <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>
+ <p>There are a number of techniques that can be used to mitigate these privacy risk to users:</p>
+
+ <dl>
+ <dt>Origin-specific Key System storage</dt>
+ <dd>User agents may require that some or all of the Key System's persistently stored data is stored in an origin-specific way.</dd>
+
+ <dt>User deletion of Key System storage</dt>
+ <dd>User agents may present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
+
+ <dt>Treating Key System stored data like cookies / Web Storage</dt>
+ <dd>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.</dd>
+
+ <dt>Encryption or obfuscation of Key System stored data</dt>
+ <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>
<h2 id="containers">9. Container Guidelines</h2>
<p>This document describes behavior independent of specific media containers.