The working group maintains a list of all bug reports that the editors have not yet tried to address; there are also open bugs in the previous bug tracker. This draft highlights some of the pending issues that are still to be discussed in the working group. No decision has been taken on the outcome of these issues including whether they are valid.
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. 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.
-Bug 20944 - The specification should do more to encourage/ensure CDM-level interoperability.
-This specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
+Issue 192 - The specification should do more to encourage/ensure CDM-level interoperability.
+Issue 221 - This specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
- - +Two identifiers or other values are said to be non-associable if they are not identical AND it is not possible - with a reasonable amount of time and effort - to correlate or associate them. + Otherwise, two values are associable. +
+Implementation MUST NOT expose identifiers to applications, even in encrypted form, across origins or across clearing of identifiers.
+ +For example, two values that are completely unrelated or cryptographically distinct, such as via a cryptographically strong non-reversible hash function, are .
+As counter examples, values created in the following ways are :
+Using a trivially-reversible hash function.
Sharing a prefix or other subset
Replacing random value N with N+10
XORing the origin with a fixed value (because it is trivially reversible)
Issue 117 - The definition of Distinctive Identifier needs to be refined and will likely change.
++ A distinctive identifier is a value for which it is possible to associate the values outside the device across a) origins or b) browsing sessions even after the user has attempted to protect his or her privacy by clearing browsing data or it is not easy for a user to break such association. + In particular, a value is a distinctive identifier if it is possible for a central server, such as an individualization server, to associate values across origins, such as because the individualization requests contained a common value, or because values provided in individualization requests are even after attempts to clear browsing data. + Possible causes of this include use of hardware or other indelible IDs in the individualization process. +
A distinctive identifier is a piece of data, implication of the possession of a piece of data, or an observable behavior or timing for which all of the following criteria hold:
It is not shared across a large population of users or devices.
It is exposed outside the client device or exposed to the application such that the application has the opportunity to send it (even if in encrypted form if decryptable outside the device) or information about it outside the client device.
It is used in more than one session or is potentially used in one persistent session across the point of persistence.
It, information about it, or values derived or otherwise related to it are exposed, even in encrypted form, outside the client. + This includes but is not limited to providing it to the application and/or license, individualization, or other server. +
+It has one or more the following properties:
+It is derived from a value that is indelible in some way, including but not limited to hardware, operating system installation instance, or client or other user account values.
The generation, individualization, provisioning or other process that produced the value involved, used, provided, derived from, or similarly involved such an indelible value or another distinctive identifier.
It is clearable but not along with cookies and other site data.
+For example, via some mechanism external to the user agent, such as an OS-level mechanism.
+Other properties of concern that are normatively prohibited include:
+It is indelible in some way.
It is not clearable.
Value(s) created after clearing identifier(s) are with previous value(s).
Values are not unique per-origin.
A distinctive identifier is typically unique to a user or device, but an identifier does not need to be strictly unique to be distinctive. +
While a distinctive identifier is typically unique to a user or device, an identifier does not need to be strictly unique to be distinctive. For example, an identifier shared among a small number of users could still be distinctive.
Examples of distinctive identifiers include but are not limited to:
A string of bytes that is included in key requests and that is different from the string included by other devices.
A public key included in key requests that is different from the public keys included in the requests by other devices.
Demonstration of possession of a private key (e.g. by signing some data) that other devices do not have.
A series of bytes that is included in key requests, different from the series of bytes included by other devices, and based on or was acquired directly or indirectly using an indelible identifier.
A public key included in key requests that is different from the public keys included in the requests by other devices and is based on or was acquired directly or indirectly using an indelible identifier.
Demonstration of possession of a private key (e.g. by signing some data) that other devices do not have and is based on or was acquired directly or indirectly using an indelible identifier.
An identifier for such a key.
Such a value used to derive another value that is exposed even though the first value is not directly exposed.
A value derived from another distinctive identifier.
Examples of things that are not distinctive identifiers:
+Examples of things that are not distinctive identifiers:
A public key shared among all copies of a given CDM version if the installed base is large.
A nonce or ephemeral key that is unique but used in only one session.
A nonce or ephemeral key that is unique but used in only one session.
A value that is not exposed, even in derived or similar ways, outside the client, including via individualization or similar.
Device-unique keys used in attestations between, for example, the video pipeline and the CDM when the CDM does not let these attestations further flow to the application and instead makes a new attestation on its own using a key that does not constitute a distinctive identifier.
A value that is fully cleared/clearable along with browsing data, such as cookies, after which it will be replaced by a value AND one or more of the following:
+No indelible value or distinctive identifier was involved in the generation of the value.
It is a random value generated without inputs from the system.
It is a value provided by a server without the use of or knowledge of another distinctive identifier.
The source of the identifier does not affect whether it is distinctive. @@ -611,7 +668,7 @@
If the implementation requires a in combination with accumulated configuration and restrictions, return NotSupported.
If the implementation requires use of a in combination with accumulated configuration and restrictions, return NotSupported.
If accumulated configuration's value is , follow the steps for the first matching condition from the following list:
The member of accumulated configuration is not and any of the recommendations of - Allow Identifiers to be Cleared are not supported by the combination of the - User Agent, implementation and accumulated configuration. + Allow Identifiers to Be Cleared or Allow Persistent Data to Be Cleared + are not supported by the combination of the User Agent, implementation and accumulated configuration.
Messages from the CDM, such as events, MUST NOT contain a , even in an encrypted form, when this member is . + Whether use of a is required. +
when this member is , the implementation MUST NOT use or expose a for any operations associated with any object created from this configuration. + This includes but is not limited to the following: +
+- A session for which the license and record of or data related to the session MUST NOT be persisted. + A session for which the license, key(s) and record of or data related to the session are not persisted.
The application need not worry about managing such storage. @@ -1240,7 +1303,7 @@
Issue 85 - There are concerns about the architectural implications of "persistent-usage-record" sessions that are pending a TAG discussion. The outcome of this discussion could result in modification (including removal) of the feature.
- A session for which the license and any key(s) it contains SHALL NOT be persisted and for which a SHALL be persisted when + A session for which the license and key(s) are not persisted and for which a is persisted when the keys available within the session are destroyed. The record of key usage consists of:
@@ -1411,13 +1474,13 @@The following step is run:
For each MediaKeySession created by the media keys on which the algorithm has not been run, run the algorithm.
+For each MediaKeySession created by the media keys on which the algorithm has not been run, to run the algorithm.
This section describes general requirements related to storage and persistence.
@@ -1449,6 +1512,13 @@
+ If a MediaKeySession object becomes inaccessible to the page + and the algorithm has not already been run, the User Agent + MUST run the algorithm before User Agent state + associated with the session is deleted. +
+A MediaKeySession object SHALL NOT be destroyed and SHALL continue to receive events if it has not been closed and the MediaKeys object that created it remains accessible. Otherwise, @@ -1833,7 +1903,7 @@
- Close the session and clear all stored session data associated with this object, + Close the session and clear all stored session data associated with this object, including the and license destruction record.
A subsequent call to with the value of this object's would fail because there is no data stored for that session ID.
@@ -1847,7 +1917,7 @@- Close the session and clear all stored session data associated with this object, + Close the session and clear all stored session data associated with this object, including the and the .
A subsequent call to with the value of this object's would fail because there is no data stored for that session ID.
@@ -2058,16 +2128,17 @@The MediaKeyStatusMap object is a read-only map of key IDs to the current status of the associated key.
A key's status is independent of whether the key is currently being used and of media data.
For example, if a key has output requirements that cannot currently be met, the key's status should be or , as appropriate, regardless of whether that key has been or is currently needed to decrypt media data.
-Issue 75 - The exact behavior of the iterable declaration is still being determined and may change in incompatible ways. This includes the definition of the value pairs and the ForEachCallback parameters.
+ The value pairs to iterate over are a snapshot of the set of pairs formed from the and + associated MediaKeyStatus value for all known keys, sorted by , + where for Key IDs A and B, of lengths n and m respectively, with n <= m, then we + define A < B if and only if the n octets of A are less in lexicographical + order than the first n octets of B or those octets are equal and n < m. +
Calls callback once for each key-value pair present in the MediaKeyStatus map.
-The Update Key Statuses algorithm updates the set of known keys for a MediaKeySession or the status of one or more of the keys. Requests to run this algorithm include a target MediaKeySession object and a sequence of and associated MediaKeyStatus pairs.
+The algorithm is always run in a task.
The following steps are run:
Let the session be the associated MediaKeySession object.
The Update Expiration algorithm updates the expiration time of a MediaKeySession.
Requests to run this algorithm include a target MediaKeySession object and the new expiration time, which may be NaN.
The algorithm is always run in a task.
The following steps are run:
Let the session be the associated MediaKeySession object.
The Session Closed algorithm updates the MediaKeySession state after a session has been closed.
+The algorithm is always run in a task.
Closing a session means that the license(s) and key(s) associated with it are no longer available to decrypt . All MediaKeySession methods will fail and no further events will be queued for this object @@ -2334,7 +2392,7 @@
If session's session type is , - store the record of key usage, if it exists. + store session's record of key usage, if it exists.
The record of key usage may not exist if no keys have been used in the session or if it has been deleted as @@ -2347,15 +2405,36 @@
Resolve promise.
+ This algorithm performs steps that are necessary when a MediaKeySession is destroyed and + the algorithm has not been run. +
+The following steps are run in parallel to the main event loop:
+Let session be the associated MediaKeySession object.
Let cdm be the CDM instance represented by session's cdm instance value.
Use cdm to close the session associated with session.
++ If session's session type is , + store session's record of key usage, if it exists. +
++ Since it has no effects observable to the document, this step may be run asynchronously, including after the document has unloaded. +
+The Monitor for CDM State Changes algorithm executes steps required when various aspects of CDM state change. It is run for each MediaKeySession object in parallel to the main event loop but not in parallel to other procedures defined in this specification that are run in parallel to the main event loop. -
This algorithm only applies to CDM state changes that are not covered by other algorithms. For example, may result in messages, key status changes and/or expiration changes, but those are all handled within that algorithm.
+This algorithm only applies to CDM state changes that are not covered by other algorithms. For example, may result in messages, key status changes and/or expiration changes, but those are all handled within that algorithm.
The following steps are run:
@@ -2497,6 +2576,9 @@All data associated with a session MUST be cleared when the session is cleared, such as in when processing a license destruction acknowledgement or key usage record acknowledgement. + See Persistent Data. +
The CDM MUST ensure that data for a given session is only present in one active unclosed session in any . In other words, MUST fail when there is already a MediaKeySession representing the session specified by the sessionId parameter, either because the object that created it via is still active or it has been loaded into another object via . A session MAY only be loaded again after the algorithm has not been run on the object representing it. @@ -2788,7 +2870,7 @@
If multiple sessions contain a key that is for the block key ID, which session and key to use is -dependent.
If the status of any of the available keys changed as the result of running the preceding step, run the algorithm on each affected session, providing all key ID(s) in the session along with the appropriate MediaKeyStatus value(s) for each. +
If the status of any of the available keys changed as the result of running the preceding step, to run the algorithm on each affected session, providing all key ID(s) in the session along with the appropriate MediaKeyStatus value(s) for each.
If block key is not null, run the following steps:
Implementations that use persistent data MUST allow the user to clear that data such that it is no longer retrievable both outside, such as via the APIs defined in this specification, and on the client device.
-+
@@ -3007,7 +3089,7 @@Add more specific text about ensuring the desired privacy properties when encrypting identifiers.
+Issue 219 - Add more specific text about ensuring the desired privacy properties when encrypting identifiers.
This MAY be implemented using a server certificate.
The license server MUST NOT expose a to any entity other than the CDM that sent it.
Specifically, it should not be provided to the application or included unencrypted in messages to the CDM. @@ -3030,19 +3112,19 @@
Issue 101 - It has been suggested that the be distinctive for the combination of top-level origin and the origin using these APIs.
-- It MUST NOT be possible (with a reasonable amount of time and effort) to correlate identifiers from multiple origins, such as to determine that they came from the same client or user. +
+ Values across origins MUST be , meaning it MUST NOT be possible to correlate identifiers from multiple origins, such as to determine that they came from the same client or user. Specifically, implementations that derive per-origin identifiers from an origin-independent identifier, MUST do so in a non-reversible way.
-Add more specific text about ensuring the desired non-reversible properties.
+Issue 219 - Add more specific text about ensuring the desired non-reversible properties.
As a consequence of the requirements in Allow Persistent Data to Be Cleared, implementations that use Distinctive Identifier(s) MUST allow the user to clear those identifiers such that they are no longer retrievable both outside, such as via the APIs defined in this specification, and on the client device. +
As a consequence of the requirements in Allow Persistent Data to Be Cleared, implementations that use Distinctive Identifier(s) MUST allow the user to clear those identifiers such that they are no longer retrievable both outside, such as via the APIs defined in this specification, and on the client device.
- Once cleared, new different values MUST be generated when Distinctive Identifier(s) are subsequently needed. + Once cleared, new values MUST be generated when Distinctive Identifier(s) are subsequently needed.
In addition, 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 [[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. + This would allow sites to use the various features as redundant backup for each other, defeating a user's attempts to protect his or her privacy.
The following section describes techniques that may mitigate the risks of tracking without user consent.
@@ -3593,11 +3675,11 @@Implementations that use MUST use a different value for each , either by allocation of different identifiers for different origins or by use of a non-reversible origin-specific mapping from an origin-independent identifier. - See Use Per-Origin Identifiers and non-reversible identifiers. + +
Implementations that use MUST use a different value for each . + See Use Per-Origin Identifiers.
User agents MAY restrict access to Key Systems and/or features to scripts originating at the of the top-level of the browsing context.
For example, may deny requests for certain configurations for pages from other origins running in iframes.
While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single origin, 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 unique per-origin, then a profile can still be created. + If a third party cooperates with multiple sites to obtain such information, and if identifiers are not unique per-origin, then a profile can still be created.
@@ -3698,7 +3780,7 @@The resulting identifier MUST be origin- and application-independent. Such identifiers MUST NOT be provided to applications (see Use Per-Origin Identifiers), even encrypted. - Implementations MAY derive non-reversible per-origin identifiers from such identifiers and provide those to the application (encrypted) + Implementations MAY derive per-origin identifiers from such identifiers and provide those to the application (encrypted).
For such individualization, all message exchanges:
Bug 20944 - The specification should do more to encourage/ensure CDM-level interoperability.
+Issue 192 - The specification should do more to encourage/ensure CDM-level interoperability.
This specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
+Issue 221 - This specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
The following features are at risk and may be removed:
+The "persistent-usage-record" session type.
The MediaKeySession destroyed algorithm.
+Setting the media element's readyState value based on key availability in the Queue a "waitingforkey" Event and Attempt to Resume Playback If Necessary algorithms.
Support for insecure contexts, including the Are insecure contexts allowed? algorithm and steps that call it.
+This document was published by the HTML Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to @@ -1068,7 +1083,7 @@
MediaKeySession Interface
@@ -1079,7 +1094,6 @@ ForEachCallback ParametersMediaKeyMessageEvent
@@ -1100,7 +1114,8 @@ Two identifiers or other values are said to be non-associable if they are not identical AND it is not possible - with a reasonable amount of time and effort - to correlate or associate them. Otherwise, two values are associable. +
+Implementation MUST NOT expose associable identifiers to applications, even in encrypted form, across origins or across clearing of identifiers.
+ +For example, two values that are completely unrelated or cryptographically distinct, such as via a cryptographically strong non-reversible hash function, are non-associable.
+As counter examples, values created in the following ways are associable:
+Using a trivially-reversible hash function.
+Sharing a prefix or other subset
+Replacing random value N with N+10
+XORing the origin with a fixed value (because it is trivially reversible)
+Issue 117 - The definition of Distinctive Identifier needs to be refined and will likely change.
++ A distinctive identifier is a value for which it is possible to associate the values outside the device across a) origins or b) browsing sessions even after the user has attempted to protect his or her privacy by clearing browsing data or it is not easy for a user to break such association. In particular, a value is a distinctive identifier if it is possible for a central server, such as an individualization server, to associate values across origins, such as because the individualization requests contained a common value, or because values provided in individualization requests are associable even after attempts to clear browsing data. Possible causes of this include use of hardware or other indelible IDs in the individualization process. +
A distinctive identifier is a piece of data, implication of the possession of a piece of data, or an observable behavior or timing for which all of the following criteria hold:
It is exposed outside the client device or exposed to the application such that the application has the opportunity to send it (even if in encrypted form if decryptable outside the device) or information about it outside the client device.
+It, information about it, or values derived or otherwise related to it are exposed, even in encrypted form, outside the client. This includes but is not limited to providing it to the application and/or license, individualization, or other server. +
It is used in more than one session or - is potentially used in one persistent session across the point of persistence.
+It has one or more the following properties:
+It is derived from a value that is indelible in some way, including but not limited to hardware, operating system installation instance, or client or other user account values.
+The generation, individualization, provisioning or other process that produced the value involved, used, provided, derived from, or similarly involved such an indelible value or another distinctive identifier.
+It is clearable but not along with cookies and other site data.
+For example, via some mechanism external to the user agent, such as an OS-level mechanism.
+Other properties of concern that are normatively prohibited include:
+It is indelible in some way.
+It is not clearable.
+Value(s) created after clearing identifier(s) are associable with previous value(s).
+Values are not unique per-origin.
+Values for different origins may be associable.
+A distinctive identifier is typically unique to a user or device, but an identifier does not need to be strictly unique to be distinctive. For example, an identifier shared among a small number of users could still be distinctive. +
While a distinctive identifier is typically unique to a user or device, an identifier does not need to be strictly unique to be distinctive. For example, an identifier shared among a small number of users could still be distinctive.
Examples of distinctive identifiers include but are not limited to:
A string of bytes that is included in key requests and that is different from the string included by other devices.
+A series of bytes that is included in key requests, different from the series of bytes included by other devices, and based on or was acquired directly or indirectly using an indelible identifier.
A public key included in key requests that is different from the public keys included in the requests by other devices.
+A public key included in key requests that is different from the public keys included in the requests by other devices and is based on or was acquired directly or indirectly using an indelible identifier.
Demonstration of possession of a private key (e.g. by signing some data) that other devices do not have.
+Demonstration of possession of a private key (e.g. by signing some data) that other devices do not have and is based on or was acquired directly or indirectly using an indelible identifier.
An identifier for such a key.
Such a value used to derive another value that is exposed even though the first value is not directly exposed.
+A value derived from another distinctive identifier.
+Examples of things that are not distinctive identifiers:
+Examples of things that are not distinctive identifiers:
A public key shared among all copies of a given CDM version if the installed base is large.
A nonce or ephemeral key that is unique but used in only one - session.
+A nonce or ephemeral key that is unique but used in only one session.
+A value that is not exposed, even in derived or similar ways, outside the client, including via individualization or similar.
Device-unique keys used in attestations between, for example, the video pipeline and the CDM when the CDM does not let these attestations further flow to the application and instead makes a new attestation on its own using a key that does not constitute a distinctive identifier.
A value that is fully cleared/clearable along with browsing data, such as cookies, after which it will be replaced by a non-associable value AND one or more of the following:
+No indelible value or distinctive identifier was involved in the generation of the value.
+It is a random value generated without inputs from the system.
+It is a value provided by a server without the use of or knowledge of another distinctive identifier.
+The source of the identifier does not affect whether it is distinctive. For example, an identifier that is permanently part of the client device, contained in the CDM, generated on the client, or generated as part of some individualization or other provisioning process is considered distinctive if it meets the criteria above.
requestMediaKeySystemAccessCalling this method may have user-visible effects, including requests for user consent. This method should only be called when the author intends to create and use a MediaKeys object with the provided configuration.
Support for communication from Secure Contexts to devices on a private network is an open issue. A bug will be filed with the Web Application Security Working Group and referenced here.
If the result of running the Are insecure contexts allowed? algorithm is Allowed, skip the next step.
This step is DEPRECATED. It is expected that removal of this step will be evaluated during Candidate Recommendation (CR). Authors are advised that implementations MAY remove it before then.
Requiring Secure Contexts is not a replacement for other security- and privacy-related requirements and recommendations. Implementations MUST meet all related requirements and SHOULD follow related recommendations such that the risks on in an secure context would be similar.
@@ -1693,7 +1798,7 @@keySystem was not supported/allowed or none of the configurations in supportedConfigurations were supported/allowed.
Given a Key Systems implementation implementation, MediaKeySystemConfiguration candidate configuration, and origin, this algorithm returns a supported configuration or NotSupported as appropriate.
Unrecognized dictionary members in candidate configuration are ignored per [WebIDL] and will never reach this algorithm. Thus, they cannot be considered as part of the configuration.
For certain configurations, it may be required to obtain user consent or inform the user. User Agents have some flexibility to determine whether consent is required for a specific configuration and whether such consent may also apply to other configurations. For example, consent to one configuration may also imply consent for less powerful, more restricted configurations. Equally, a denial of consent for one configuration may imply denial of consent for more powerful, less restricted configurations. @@ -1793,7 +1898,7 @@
The initDataType MUST be supported independent of content types in order to avoid unexpectedly rejecting the configuration in later steps. Support for initDataType includes both license generation and, when appropriate, extraction from media data. See Initialization Data Type Support requirements.
If the implementation requires a Distinctive Identifier in combination with accumulated configuration and restrictions, return NotSupported.
If the implementation requires use of a Distinctive Identifier in combination with accumulated configuration and restrictions, return NotSupported.
The combination of accumulated configuration and restrictions means all the possible configurations that include everything in accumulated configuration and that are not denied according to restrictions. @@ -1995,7 +2100,7 @@
"optional", follow the steps for the first matching condition from the following list:
Change accumulated configuration's distinctiveIdentifier value to "required".
In this step, "supported" includes the implementation being available for use when this algorithm returns, not just user agent support for such an implementation.
The "unique per-origin" and "clearable" conditions cannot be false in a compliant implementation because implementations MUST use per-origin identifiers and allow the user to clear identifier. @@ -2116,7 +2221,7 @@
Per RFC 6838 [RFC6838], "Both top-level type and subtype names are case-insensitive."
Case-sensitive string comparison is RECOMMENDED because RFC 6381 [RFC6381] says, "Values are case sensitive" for some formats.
For example, if audio/video type is Video and the top-level type is not "video" or media types contains non-video codecs.
requested media capability (content type and robustness) must be supported with all previously added requested media capabilities.
This step ensures that the values of the members of entries in supported media capabilities are exactly the strings supplied in requested media capability without modification by the User Agent. @@ -2198,7 +2303,7 @@
This step ensures that configurations are always checked with configurations from previous iterations, including from previous calls to this algorithm. Otherwise, only configurations from previous calls to this algorithm would be checked in subsequent calls.
@@ -2211,7 +2316,7 @@None of the MediaKeySystemMediaCapability elements in requested media capabilities is supported in combination with partial configuration.
Consent status for accumulated configuration depends at least on the value of the distinctiveIdentifier member of
@@ -2273,7 +2378,7 @@
"not-allowed" and any of the recommendations of
- Allow Identifiers to be Cleared are not supported by the combination of the User Agent, implementation and accumulated configuration.
+ Allow Identifiers to Be Cleared or Allow Persistent Data to Be Cleared are not supported by the combination of the User Agent, implementation and accumulated configuration.
Another reason for requiring explicit user consent may be due to the security properties of the CDM implementation.
@@ -2299,7 +2404,7 @@"required".
User consent to use accumulated configuration is specific to the origin and may be limited to configurations sharing certain properties with accumulated configuration.
@@ -2402,9 +2507,17 @@distinctiveIdentifier of type MediaKeysRequirement, defaulting to "optional"Messages from the CDM, such as message events, MUST NOT contain a Distinctive Identifier, even in an encrypted form, when this member is "not-allowed".
+ Whether use of a Distinctive Identifier is required.
+
when this member is "not-allowed", the implementation MUST NOT use or expose a Distinctive Identifier for any operations associated with any object created from this configuration. This includes but is not limited to the following:
Any individualization process MUST NOT use and messages involved MUST NOT contain a Distinctive Identifier.
+Messages from the CDM, such as message events, MUST NOT contain a Distinctive Identifier, even in an encrypted form.
initDataTypes of type sequence<DOMString>, defaulting to [ ]"not-allowed".
For the purposes of this member, persistent state does not include persistent unique identifiers (Distinctive Identifiers) controlled by the Key System implementation. distinctiveIdentifier independently reflects this requirement.
Only "temporary" sessions may be created when persistent state is not supported.
For "temporary" sessions, the need and ability to store state is Key System implementation-specific and may vary by feature used.
Applications intending to create non-"temporary" sessions, should set this member to "required" when calling requestMediaKeySystemAccess().
sessionTypes of type sequence<DOMString>MediaKeysRequirement, and it is RECOMMENDED that they have default values of "optional" to support the widest range of application and client combinations.
Dictionary members not recognized by a user agent implementation are ignored per [WebIDL] and will not be considered in the requestMediaKeySystemAccess() algorithm. Should an application use non-standard dictionary member(s), it MUST NOT rely on user agent implementations rejecting a configuration that includes such dictionary members.
robustness.
If any of a set of codecs is acceptable, use a separate instances of this dictionary for each codec.
This results in a new JavaScript object being created and initialized from configuration each time this method is called.
@@ -2662,7 +2775,7 @@temporary
- A session for which the license and record of or data related to the session MUST NOT be persisted. + A session for which the license, key(s) and record of or data related to the session are not persisted.
The application need not worry about managing such storage. Support for this session type is REQUIRED. @@ -2672,12 +2785,12 @@
persistent-usage-recordIssue 85 - There are concerns about the architectural implications of "persistent-usage-record" sessions that are pending a TAG discussion. The outcome of this discussion could result in modification (including removal) of the feature.
- A session for which the license and any key(s) it contains SHALL NOT be persisted and for which a record of key usage SHALL be persisted when the keys available within the session are destroyed. The record of key usage consists of: + A session for which the license and key(s) are not persisted and for which a record of key usage is persisted when the keys available within the session are destroyed. The record of key usage consists of:
Because the license and keys are not persisted, this record implicitly proves that the keys are no longer available in the session.
User agents MAY implement this mechanism by means other than persisting data on key destruction - for example by persisting data during playback which is later used to infer the fact of key destruction - provided the observable behavior is compliant to this specification.
@@ -2777,14 +2890,14 @@If this object's supported session types value does not contain sessionType, throw a NotSupportedError.
sessionType values for which the Is persistent session type? algorithm returns true will fail if this object's persistent state allowed value is false.
If the implementation does not support MediaKeySession operations in the current state, throw an InvalidStateError.
Some implementations are unable to execute MediaKeySession algorithms until this MediaKeys object is associated with a media element using setMediaKeys(). This step enables applications to detect this uncommon behavior before attempting to perform such operations.
Key Systems that use such certificates MUST also support requesting the certificate from the server via the Queue a "message" Event algorithm.
This method allows an application to proactively provide a server certificate to implementations that support it to avoid the additional round trip should the CDM request it. It is intended as an optimization, and applications are not required to use it.
MediaKeySession created by the media keys on which the Session Closed algorithm has not been run, run the Session Closed algorithm.
+ For each MediaKeySession created by the media keys on which the Session Closed algorithm has not been run, queue a task to run the Session Closed algorithm.
This section describes general requirements related to storage and persistence.
@@ -2973,11 +3086,16 @@
MediaKeySession object until the sooner of the Session Closed algorithm being run or the destruction of the MediaKeySession. The Monitor for CDM Changes algorithm MUST be run in parallel to the main event loop, but not in parallel to other procedures defined in this specification that are also defined to be run in parallel.
+
+ If a MediaKeySession object becomes inaccessible to the page and the Session Closed algorithm has not already been run, the User Agent
+ MUST run the MediaKeySession destroyed algorithm before User Agent state associated with the session is deleted.
+
A MediaKeySession object SHALL NOT be destroyed and SHALL continue to receive events if it has not been closed and the MediaKeys object that created it remains accessible. Otherwise, a MediaKeySession object that is no longer accessible to JavaScript SHALL NOT receive further events and MAY be destroyed.
The above rule implies that the CDM instance must not be destroyed until all MediaKeys objects and all MediaKeySession objects associated with the CDM instance are destroyed.
The time after which the key(s) in the session will no longer be usable for decryption, or NaN if no such time exists or if the license explicitly never expires, as determined by the CDM.
This value MAY change during the session lifetime, such as when an action triggers the start of a window.
keyStatuses of type MediaKeyStatusMap, readonly The map entries and their values may be updated whenever the event loop spins. The map MUST NOT ever be inconsistent or partially updated, but it may change between accesses if the event loop spins in between the accesses. Key IDs may be added as the result of a load() or update() call. Key IDs may be removed as the result of a update() call that removes knowledge of existing keys (or replaces the existing set of keys with a new set). Key IDs MUST NOT be removed because they became unusable, such as due to expiration. Instead, such keys MUST be given an appropriate status, such as "expired".
Some older platforms may contain Key System implementations that do not expose key IDs, making it impossible to provide a compliant user agent implementation. To maximize interoperability, user agent implementations exposing such CDMs SHOULD implement this member as follows: Whenever a non-empty list is appropriate, such as when the key session represented by this object may contain key(s), populate the map with a single pair containing the one-byte key ID 0 and the MediaKeyStatus most appropriate for the aggregated status of this object.
Indicates that the application no longer needs the session and the CDM should release any resources associated with the session and close it. Persisted data should not be released or cleared.
The returned promise is resolved when the request has been processed, and the closed attribute promise is resolved when the session is closed.
Use cdm to close the session associated with session.
Closing the key session results in the destruction of any license(s) and key(s) that have not been explicitly stored.
Resolve promise.
Since promise handlers are queued as microtasks, these will be executed ahead of any events queued by the preceding steps.
Let requested license type be a temporary non-persistable license.
The returned license must not be persistable or require persisting information related to it.
update() the CDM MUST generate a license request for the requested license type based on the sanitized init data, which is interpreted per initDataType.
-
Issue 207 proposes that the above requirement be formally described in terms of CDM state that will trigger the generation of a license request in a future call to update().
Resolve promise.
Since promise handlers are queued as microtasks, these will be executed ahead of any events queued by the preceding steps.
Let sanitized session ID be a validated and/or sanitized version of sessionId.
The user agent should thoroughly validate the sessionId value before passing it to the CDM. At a minimum, this should include checking that the length and value (e.g. alphanumeric) are reasonable.
If there is an unclosed session in this object's Document whose sessionId attribute is sanitized session ID, reject promise with a QuotaExceededError.
In other words, do not create a session if a non-closed session, regardless of type, already exists for this sanitized session ID in this browsing context.
If there is an unclosed session in any Document representing the session data, reject promise with a QuotaExceededError.
In other words, do not create a session if a non-closed persistent session already exists for this sanitized session ID in any browsing context.
true.
Since promise handlers are queued as microtasks, these will be executed ahead of any events queued by the preceding steps.
This implies destruction of the license(s) and/or keys(s) whether they are in memory, persistent store or both.
@@ -3621,7 +3739,7 @@Resolve promise.
Since promise handlers are queued as microtasks, these will be executed ahead of any events queued by the preceding steps.
Let sanitized response be a validated and/or sanitized version of response copy.
The user agent should thoroughly validate the response before passing it to the CDM. This may include verifying values are within reasonable limits, stripping irrelevant data or fields, pre-parsing it, sanitizing it, and/or generating a fully sanitized version. The user agent should check that the length and values of fields are reasonable. Unknown fields should be rejected or removed.
This includes an initial license, an updated license, and a license renewal message.
Process sanitized response, following the stipulation for the first matching condition from the following list:
@@ -3749,15 +3867,15 @@State information, including keys, for each session MUST be stored in such a way that closing one session does not affect the observable state in other session(s), even if they contain overlapping key IDs.
When sanitized response contains key(s) and/or related data, cdm will likely store (in memory) the key and related data indexed by key ID.
It is RECOMMENDED that CDM implementations support a standard and reasonably high minimum number of keys per MediaKeySession object, including a standard replacement algorithm, and a standard and reasonably high minimum number of MediaKeySession objects. This enables a reasonable number of key rotation algorithms to be implemented across user agents and may reduce the likelihood of playback interruptions in use cases that involve various streams in the same element (i.e. adaptive streams, various audio and video tracks) using different keys.
- Close the session and clear all stored session data associated with this object, including the sessionId and license destruction record.
+ Close the session and clear all stored session data associated with this object, including the sessionId and license destruction record.
- Close the session and clear all stored session data associated with this object, including the sessionId and the record of key usage.
+ Close the session and clear all stored session data associated with this object, including the sessionId and the record of key usage.
For example, sanitized response may contain information that will be used to generate another message event. In this case, there is no need to verify the contents against the sessionType.
Resolve promise.
Since promise handlers are queued as microtasks, these will be executed ahead of any events queued by the preceding steps.
A key's status is independent of whether the key is currently being used and of media data.
For example, if a key has output requirements that cannot currently be met, the key's status should be "output-downscaled" or "output-restricted", as appropriate, regardless of whether that key has been or is currently needed to decrypt media data.
Issue 75 - The exact behavior of the iterable declaration is still being determined and may change in incompatible ways. This includes the definition of the value pairs and the ForEachCallback parameters.
-interface MediaKeyStatusMap {
iterable<BufferSource,MediaKeyStatus>;
readonly attribute unsigned long size;
boolean has (BufferSource keyId);
MediaKeyStatus get (BufferSource keyId);
- void forEach (ForEachCallback callback);
};
This interface has "entries", "keys", "values", "forEach" and @@iterator methods brought by iterable.
- The value pairs to iterate over are a snapshot of the set of pairs formed from the key ID and associated MediaKeyStatus value for all known keys, sorted by key ID, where for Key IDs A and B, of lengths n and m respectively, with n <= m, then we define A < B if and only if the n octets of A are less in lexicographical order than the first n octets of B or those octets are equal and n < m.
+
+ The value pairs to iterate over are a snapshot of the set of pairs formed from the key ID and associated MediaKeyStatus value for all known keys, sorted by key ID, where for Key IDs A and B, of lengths n and m respectively, with n <= m, then we define A < B if and only if the n octets of A are less in lexicographical order than the first n octets of B or those octets are equal and n < m.
+
forEachCalls callback once for each key-value pair present in the MediaKeyStatus map.
- -| Parameter | -Type | -Nullable | -Optional | -Description | -
|---|---|---|---|---|
| callback | - |
- ✘ | -✘ | -A callback function | -
voidgetgetReturns the MediaKeyStatus of the key identified by keyId or undefined if the status of the key identified by keyId is not known.
callback ForEachCallback = void (BufferSource keyId, MediaKeyStatus status);
-
- ForEachCallback ParameterskeyId of type BufferSourcestatus of type MediaKeyStatusenum MediaKeyStatus {
"usable",
"expired",
@@ -4146,7 +4226,7 @@ Implementations MUST NOT require applications to handle message types. Implementations MUST support applications that do not differentiate messages and MUST NOT require that applications handle message types. Specifically, Key Systems MUST support passing all types of messages to a single URL.
- Note
+ Note
This attribute allows an application to differentiate messages without parsing the message. It is intended to enable optional application and/or server optimizations, but applications are not required to use it.
@@ -4232,6 +4312,10 @@ 6.6.2 Update Key Statuses
The Update Key Statuses algorithm updates the set of known keys for a MediaKeySession or the status of one or more of the keys. Requests to run this algorithm include a target MediaKeySession object and a sequence of key ID and associated MediaKeyStatus pairs.
+
+ Note
+ The algorithm is always run in a task.
+
The following steps are run:
-
@@ -4262,7 +4346,7 @@
- Note
+ Note
The effect of this steps is that the contents of session's keyStatuses attribute are replaced without invalidating existing references to the attribute. This replacement is atomic from a script perspective. That is, script MUST NOT ever see a partially populated sequence.
@@ -4280,6 +4364,10 @@ 6.6.3 Update Expiration
The Update Expiration algorithm updates the expiration time of a MediaKeySession. Requests to run this algorithm include a target MediaKeySession object and the new expiration time, which may be NaN.
+
+ Note
+ The algorithm is always run in a task.
+
The following steps are run:
-
@@ -4300,11 +4388,15 @@
6.6.4 Session Closed
The Session Closed algorithm updates the MediaKeySession state after a session has been closed.
+
+ Note
+ The algorithm is always run in a task.
+
Closing a session means that the license(s) and key(s) associated with it are no longer available to decrypt media data. All MediaKeySession methods will fail and no further events will be queued for this object after this algorithm is run.
- Note
+ Note
The CDM may close a session at any point, such as when the session is no longer needed or when system resources are lost. In that case, the Monitor for CDM Changes algorithm detects the change and runs this algorithm.
@@ -4323,10 +4415,10 @@
-
- If session's session type is "persistent-usage-record", store the record of key usage, if it exists.
+ If session's session type is "persistent-usage-record", store session's record of key usage, if it exists.
- Note
+ Note
The record of key usage may not exist if no keys have been used in the session or if it has been deleted as a result of the update() method processing an acknowledgement of the record of key usage.
@@ -4347,17 +4439,46 @@
+
+ 6.6.5 MediaKeySession Destroyed
+
+ This algorithm performs steps that are necessary when a MediaKeySession is destroyed and the Session Closed algorithm has not been run.
+
+ The following steps are run in parallel to the main event loop:
+
+ -
+
Let session be the associated MediaKeySession object.
+
+ -
+
Let cdm be the CDM instance represented by session's cdm instance value.
+
+ -
+
Use cdm to close the session associated with session.
+
+ -
+
+ If session's session type is "persistent-usage-record", store session's record of key usage, if it exists.
+
+
+ Note
+
+ Since it has no effects observable to the document, this step may be run asynchronously, including after the document has unloaded.
+
+
+
+
+
+
- 6.6.5 Monitor for CDM State Changes
+ 6.6.6 Monitor for CDM State Changes
The Monitor for CDM State Changes algorithm executes steps required when various aspects of CDM state change. It is run for each
MediaKeySession object in parallel to the main event loop but not in parallel to other procedures defined in this specification that are run in parallel to the main event loop.
- Note
+ Note
This algorithm only applies to CDM state changes that are not covered by other algorithms. For example, update() may result in messages, key status changes and/or expiration changes, but those are all handled within that algorithm.
-
The following steps are run:
@@ -4483,6 +4604,8 @@ Is persistent session type? algorithm returns true.
The CDM SHOULD NOT store session data, including the Session ID, until update() is called the first time. Specifically, the CDM SHOULD NOT store session data during the generateRequest() algorithm. This ensures that the application is aware of the session and knows it needs to eventually remove it.
+ All data associated with a session MUST be cleared when the session is cleared, such as in update() when processing a license destruction acknowledgement or key usage record acknowledgement. See Persistent Data.
+
The CDM MUST ensure that data for a given session is only present in one active unclosed session in any Document. In other words, load() MUST fail when there is already a MediaKeySession representing the session specified by the sessionId parameter, either because the object that created it via generateRequest() is still active or it has been loaded into another object via load(). A session MAY only be loaded again after the Session Closed algorithm has not been run on the object representing it.
An application that creates a session using a type for which the Is persistent session type? algorithm returns true SHOULD later remove the stored data using remove(). The CDM MAY also remove sessions as appropriate, but applications SHOULD NOT rely on this.
@@ -4524,7 +4647,7 @@
For each block of encrypted media data encountered during the resource fetch algorithm, the user agent shall run the Encrypted Block Encountered algorithm in the order the encrypted blocks were encountered.
- Note
+ Note
The above step provides flexibility for user agent implementations to perform decryption at any time after an encrypted block is encountered before it is needed for playback.
@@ -4565,11 +4688,11 @@ Provides the MediaKeys to use when decrypting media data during playback.
- Note
+ Note
Support for clearing or replacing the associated MediaKeys object during playback is a quality of implementation issue. In many cases it will result in a bad user experience or rejected promise.
- Note
+ Note
Some implementations may only support decrypting media data provided via Media Source Extensions [MEDIA-SOURCE]. This is not reflected in the results of calling requestMediaKeySystemAccess().
@@ -4630,7 +4753,7 @@
If the association cannot currently be removed, let this object's attaching media keys value be false and reject promise with an InvalidStateError.
- Note
+ Note
For example, some implementations may not allow removal during playback.
@@ -4787,7 +4910,7 @@ The user agent encounters Initialization Data in the media data.
readyState is equal to HAVE_METADATA or greater.
It is possible that the element is playing or has played.
While the media element may allow loading of "Optionally-blockable Content" [MIXED-CONTENT], the user agent MUST NOT expose Initialization Data from such media data to the application.
readyState is not changed and no algorithms are aborted. This event merely provides information.
The initData attribute will be null if the media data is not CORS-same-origin or is mixed content. Applications may retrieve the Initialization Data from an alternate source.
If the media element's mediaKeys attribute is null and the implementation requires specification of a MediaKeys object before decoding potentially-encrypted media data, run the following steps:
These steps may be reached when the application provides media data before calling setMediaKeys() to provide a MediaKeys object. Selecting a CDM may affect the pipeline and/or decoders used, so some implementations may delay playback of media data that may contain encrypted blocks until a CDM is specified by passing a MediaKeys object to setMediaKeys().
These steps are intended to be run on unrecoverable failures of the CDM.
MediaKeySession created by the media keys on which the Session Closed algorithm has not been run, run the following steps:
This check ensures the cdm has finished loading and is a prerequisite for a matching key being available.
The key ID is generally specified by the container.
@@ -4954,12 +5077,12 @@MediaKeySession object containing that key and let block key be that key.
If multiple sessions contain a key that is usable for decryption for the block key ID, which session and key to use is Key System-dependent.
If the status of any of the available keys changed as the result of running the preceding step, run the Update Key Statuses algorithm on each affected session, providing all key ID(s) in the session along with the appropriate MediaKeyStatus value(s) for each.
+
If the status of any of the available keys changed as the result of running the preceding step, queue a task to run the Update Key Statuses algorithm on each affected session, providing all key ID(s) in the session along with the appropriate MediaKeyStatus value(s) for each.
Implementations MAY optimize the times at which this step is executed provided the recorded key usage times remain accurate to within key usage accuracy.
@@ -5021,7 +5144,7 @@In other words, decode the block.
Not all decryption problems (i.e. using the wrong key) will result in a decryption failure. In such cases, no error is fired here but one may be fired during decode.
Otherwise, there is no key for the block key ID in any session so continue.
These steps are reached when there is no key that is usable for decryption for block.
For frame-based encryption, this may be implemented as follows when the media element attempts to decode a frame as part of the resource fetch algorithm:
Set the media element's waiting for key value to true.
As a result of the above step, the media element will become a blocked media element if it wasn't already. In that case, the media element will stop playback.
As a result of the above step, the media element may no longer be a blocked media element and thus playback may resume.
appropriate.
States beyond HAVE_CURRENT_DATA and the canplaythrough event do not (or are unlikely to) consider key availability beyond the current key.
@@ -5197,7 +5320,7 @@
+
@@ -5217,14 +5340,14 @@
For example, use keys or identifiers that apply to a group of clients or devices rather than individual clients.
Implementations SHOULD only use Distinctive Identifiers when necessary to enforce the policies related to the specific CDM instance and session.
For example, "temporary" and "persistent-license" sessions may have different requirements.
When exposed to the application - either from a message event or a message from the server, such as one that is passed to update() - Distinctive Identifiers MUST be encrypted at the message exchange level. The encryption MUST ensure that the ciphertext cannot be used as a proxy for the actual identifier, even given the same plaintext. The CDM MUST verify that the encryption key belongs to a valid license server for its Key System.
Add more specific text about ensuring the desired privacy properties when encrypting identifiers.
+Issue 219 - Add more specific text about ensuring the desired privacy properties when encrypting identifiers.
This MAY be implemented using a server certificate.
The license server MUST NOT expose a Distinctive Identifier to any entity other than the CDM that sent it.
Specifically, it should not be provided to the application or included unencrypted in messages to the CDM. This can be accomplished by encrypting the identifier or message with the identifier or such that it is only decryptable by that specific CDM.
Among other things, this means that:
All Distinctive Identifiers MUST be distinctive per origin. That is, the Distinctive Identifier(s) used for one origin using these APIs MUST be different from those used for any other origin using the APIs.
-Issue 101 - It has been suggested that the Distinctive Identifiers be distinctive for the combination of top-level origin and the origin using these APIs.
- It MUST NOT be possible (with a reasonable amount of time and effort) to correlate identifiers from multiple origins, such as to determine that they came from the same client or user. Specifically, implementations that derive per-origin identifiers from an origin-independent identifier, MUST do so in a non-reversible way. +
+ Values across origins MUST be non-associable, meaning it MUST NOT be possible to correlate identifiers from multiple origins, such as to determine that they came from the same client or user. Specifically, implementations that derive per-origin identifiers from an origin-independent identifier, MUST do so in a non-reversible way.
-Add more specific text about ensuring the desired non-reversible properties.
+Issue 219 - Add more specific text about ensuring the desired non-reversible properties.
As a consequence of the requirements in Allow Persistent Data to Be Cleared, implementations that use Distinctive Identifier(s) MUST allow the user to clear those identifiers such that they are no longer retrievable both outside, such as via the APIs defined in this specification, and on the client device. +
As a consequence of the requirements in Allow Persistent Data to Be Cleared, implementations that use Distinctive Identifier(s) MUST allow the user to clear those identifiers such that they are no longer retrievable both outside, such as via the APIs defined in this specification, and on the client device.
- Once cleared, new different values MUST be generated when Distinctive Identifier(s) are subsequently needed. + Once cleared, new non-associable values MUST be generated when Distinctive Identifier(s) are subsequently needed.
Implementations MUST support multiple keys in each MediaKeySession object.
The mechanics of how multiple keys are supported is an implementation detail, but it MUST be transparent to the application and these APIs.
Implementations SHOULD allow licenses generated with any Initialization Data Type they support to be used with any content type.
Otherwise, the requestMediaKeySystemAccess() algorithm might, for example, reject a MediaKeySystemConfiguration because one of the initDataTypes is not supported with one of the videoCapabilities.
For any supported Initialization Data Type that may appear in a supported container, the user agents MUST support extracting that type of Initialization Data from each such supported container.
In other words, indicating support for an Initialization Data Type implies both CDM support for generating license requests and, for container-specific types, user agent support for extracting it from the container. This does not mean that implementations must be able to parse any supported Initialization Data from any supported content type.
The Encrypted Media Extensions Stream Format and Initialization Data Format Registry [EME-STREAM-REGISTRY] provides references to such stream formats.
@@ -5362,7 +5485,7 @@Decryption of such tracks - especially such that they can be provided back the user agent - is not generally supported by implementations. Thus, encrypting such tracks would prevent them from being widely available for use with accessibility features in user agent implementations.
@@ -5382,7 +5505,7 @@This ensures that there is a common baseline level of functionality that is guaranteed to be supported in all user agents, including those that are entirely open source. Thus, content providers that need only basic decryption can build simple applications that will work on all platforms without needing to work with any content protection providers.
update(), licenses, key data, and all other data provided by the application as untrusted content and potential attack vectors. They MUST use appropriate safeguards to mitigate any associated threats and take care to safely parse, decrypt, etc. such data. User Agents SHOULD validate data before passing it to the CDM.
Such validation is especially important if the CDM does not run in the same (sandboxed) context as, for example, the DOM.
Implementations MUST NOT return active content or passive content that affects program control flow to the application.
For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the Initialization Data passed to generateRequest(). Applications must determine the URLs to use. The messageType attribute of the message event can be used by the application to select among a set of URLs if applicable.
User agents should be especially diligent when using a CDM or underlying mechanism that is part of or provided by the client OS, platform and/or hardware.
Granting permissions to unauthenticated origins is equivalent to granting the permissions to any origin in the presence of a network attacker. See also User Alerts / Prompts and Use Secure Origin and Transport.
Granting permissions to unauthenticated origins is equivalent to granting the permissions to any origin in the presence of a network attacker. Alerting or prompting the user for consent on insecure origins without persisting the choice provides at least a minimum level of security because the user would be alerted to unexpected use (e.g. on a site that does not use encrypted media).
Even if a path-restriction feature was made available by user agents, the usual DOM scripting security model would make it trivial to bypass this protection and access the data from any path.
Authors on shared hosts are therefore RECOMMENDED to avoid using these APIs because doing so compromises origin-based security and privacy mitigations in user agents.
@@ -5826,7 +5949,7 @@The type of information covered by this requirement includes but is not limited to:
In addition, 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 [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. +
Finally, if any user interface for user control of Key Systems presents data separately from data in HTTP session cookies [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 or her privacy.
The following section describes techniques that may mitigate the risks of tracking without user consent.
@@ -5924,10 +6047,10 @@Implementations that use Distinctive Identifiers MUST use a different value 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. See Use Per-Origin Identifiers and non-reversible identifiers. + +
Implementations that use Distinctive Identifiers MUST use a different non-associable value for each origin. See Use Per-Origin Identifiers.
User agents MAY restrict access to Key Systems and/or features to scripts originating at the origin of the top-level Document of the browsing context. For example, requestMediaKeySystemAccess() may deny requests for certain configurations for pages from other origins running in iframes.
User agents MAY, possibly in a manner configured by the user, automatically delete Distinctive Identifiers and/or other Key System data after a period of time.
For example, a user agent could be configured to such data as session-only storage, deleting the data once the user had closed all the browsing contexts that could access it.
This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).
@@ -5981,13 +6104,13 @@The "not unique per-origin" and "not clearable" conditions cannot be true in a compliant implementation because implementations MUST use per-origin identifiers and allow the user to clear identifiers.
Such alerts and consent SHOULD be per origin to avoid valid uses enabling subsequent malicious access. User agent implementers that consider such alerts or consent appropriate for a Key System implementation SHOULD only support such Key Systems on secure origins (see Secure Origin and Transport), especially if they allow such consent to be persisted.
Granting permissions to unauthenticated origins is equivalent to granting the permissions to any origin in the presence of a network attacker.
While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single origin, 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 - unique per-origin, then a profile can still be created. + unique per-origin, then a profile can still be created.
For example, such a process may initialize a client device by communicating with a pre-determined server hosted by the user agent or CDM vendor, possibly using identifiers from the client device. Such communication would not involve providing application- or origin-specific information.
The resulting identifier MUST be origin- and application-independent. Such identifiers MUST NOT be provided to applications (see Use Per-Origin Identifiers), even encrypted. Implementations MAY derive non-reversible per-origin identifiers from such identifiers and provide those to the application (encrypted) +
The resulting identifier MUST be origin- and application-independent. Such identifiers MUST NOT be provided to applications (see Use Per-Origin Identifiers), even encrypted. Implementations MAY derive non-associable per-origin identifiers from such identifiers and provide those to the application (encrypted).
For such individualization, all message exchanges:
keyStatuses.
// For example:
- event.target.keyStatuses.forEach(function(keyId, status, map) {
+ event.target.keyStatuses.forEach(function(status, keyId) {
switch (status) {
case "usable":
break;