From 31e4015607832bc4be376f1ae8807047dee8974b Mon Sep 17 00:00:00 2001 From: David Dorwin Date: Thu, 2 Jun 2016 17:37:44 -0700 Subject: [PATCH 01/10] Fix two very minor editorial issues --- encrypted-media-respec.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html index 818ba850..f686e241 100644 --- a/encrypted-media-respec.html +++ b/encrypted-media-respec.html @@ -1417,7 +1417,7 @@

CDM Unavailable

-

Storage and persistence

+

Storage and Persistence

This section describes general requirements related to storage and persistence.

@@ -2344,8 +2344,8 @@

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. -

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:

From 3b73f31e0c59c4715fef57874deea8267d68d5b2 Mon Sep 17 00:00:00 2001 From: mwatson2 Date: Fri, 3 Jun 2016 11:25:05 +0100 Subject: [PATCH 02/10] Fix #171: Clarify destruction of licenses and keys on MediaKeySession destruction --- encrypted-media-respec.html | 34 ++++++++- encrypted-media.js | 1 + index.html | 143 ++++++++++++++++++++++-------------- 3 files changed, 121 insertions(+), 57 deletions(-) diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html index f686e241..0a686e33 100644 --- a/encrypted-media-respec.html +++ b/encrypted-media-respec.html @@ -1229,7 +1229,7 @@

MediaKeys Interface

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. @@ -1240,7 +1240,7 @@

MediaKeys Interface

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:

@@ -1449,6 +1449,13 @@

MediaKeySession Interface

The 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 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, @@ -2337,7 +2344,28 @@

Session Closed

  • Resolve promise.

    • - +
    +

    MediaKeySession Destroyed

    +

    + 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:

    +
      +

    1. Let session be the associated MediaKeySession object.

      2. +

    2. Let cdm be the CDM instance represented by session's cdm instance value.

      3. +

    3. Use cdm to close the session associated with session.

      +
    4. +

      + If session's session type is , + store the 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. +

      +
      5. +
    +

    Monitor for CDM State Changes

    diff --git a/encrypted-media.js b/encrypted-media.js index bc2df015..7f343ff7 100644 --- a/encrypted-media.js +++ b/encrypted-media.js @@ -243,6 +243,7 @@ 'update-expiration-algorithm': { func: term_helper, fragment: 'update-expiration', link_text: 'Update Expiration', }, 'resume-playback-algorithm': { func: term_helper, fragment: 'resume-playback', link_text: 'Attempt to Resume Playback If Necessary', }, 'queue-waitingforkey-algorithm': { func: term_helper, fragment: 'queue-waitingforkey', link_text: 'Queue a "waitingforkey" Event', }, + 'media-key-session-destroyed-algorithm' : { func: term_helper, fragment: 'media-key-session-destroyed', link_text: 'MediaKeySession destroyed', }, 'media-keys-storage': { func: term_helper, fragment: 'media-keys-storage', link_text: 'Storage and Persistence', }, 'session-storage': { func: term_helper, fragment: 'session-storage', link_text: 'Session Storage and Persistence', }, diff --git a/index.html b/index.html index ff7b1c60..4bea8712 100644 --- a/index.html +++ b/index.html @@ -905,13 +905,13 @@ } - +

    - 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:

    • @@ -2945,7 +2946,7 @@

      -

      5.3 Storage and persistence

      +

      5.3 Storage and Persistence

      This section describes general requirements related to storage and persistence.

      @@ -2973,6 +2974,11 @@

      The User Agent SHALL execute the Monitor for CDM Changes algorithm continuously for each 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.

      @@ -4339,17 +4345,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:

    +
      +
    1. +

      Let session be the associated MediaKeySession object.

      +
      2. +
    2. +

      Let cdm be the CDM instance represented by session's cdm instance value.

      +
      3. +
    3. +

      Use cdm to close the session associated with session.

      +
      4. +
    4. +

      + If session's session type is "persistent-usage-record", store the 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. +

      +
      +
      5. +
    +
    +
    -

    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:

    @@ -4516,7 +4551,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.

    @@ -4553,11 +4588,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().

    @@ -4618,7 +4653,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.

    @@ -4775,7 +4810,7 @@

    The user agent encounters Initialization Data in the media data. The element's readyState is equal to HAVE_METADATA or greater.
    -
    Note
    +
    Note

    It is possible that the element is playing or has played.

    @@ -4815,7 +4850,7 @@

    -
    Note
    +
    Note

    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.

    @@ -4830,11 +4865,11 @@

    -
    Note
    +
    Note

    readyState is not changed and no algorithms are aborted. This event merely provides information.

    -
    Note
    +
    Note

    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.

    @@ -4842,7 +4877,7 @@

    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:

    -
    Note
    +
    Note

    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().

    @@ -4897,7 +4932,7 @@

    -
    Note
    +
    Note

    These steps are intended to be run on unrecoverable failures of the CDM.

      @@ -4915,7 +4950,7 @@

      MediaKeySession created by the media keys on which the Session Closed algorithm has not been run, run the following steps:

      -
      Note
      +
      Note

      This check ensures the cdm has finished loading and is a prerequisite for a matching key being available.

        @@ -4925,7 +4960,7 @@

        -
        Note
        +
        Note

        The key ID is generally specified by the container.

        @@ -4942,7 +4977,7 @@

        usable for decryption, let session be a MediaKeySession object containing that key and let block key be that key.

        -
        Note
        +
        Note

        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.

        @@ -4973,7 +5008,7 @@

        -
        Note
        +
        Note

        Implementations MAY optimize the times at which this step is executed provided the recorded key usage times remain accurate to within key usage accuracy.

        @@ -5009,7 +5044,7 @@

        -
        Note
        +
        Note

        In other words, decode the block.

        @@ -5021,13 +5056,13 @@

        -
        Note
        +
        Note

        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.

      -
      Note
      +
      Note

      Otherwise, there is no key for the block key ID in any session so continue.

      @@ -5040,7 +5075,7 @@

      -
      Note
      +
      Note

      These steps are reached when there is no key that is usable for decryption for block.

        @@ -5052,7 +5087,7 @@

        -
        Note
        +
        Note

        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:

          @@ -5095,7 +5130,7 @@

          Set the media element's waiting for key value to true.

          -
          Note
          +
          Note

          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.

          @@ -5133,7 +5168,7 @@

          -
          Note
          +
          Note

          As a result of the above step, the media element may no longer be a blocked media element and thus playback may resume.

        @@ -5143,7 +5178,7 @@

        HAVE_ENOUGH_DATA as appropriate.

        -
        Note
        +
        Note

        States beyond HAVE_CURRENT_DATA and the canplaythrough event do not (or are unlikely to) consider key availability beyond the current key. @@ -5205,14 +5240,14 @@

        SHOULD avoid use of Distinctive Identifiers.

        -
        Note
        +
        Note

        For example, use keys or identifiers that apply to a group of clients or devices rather than individual clients.

      1. Implementations SHOULD only use Distinctive Identifiers when necessary to enforce the policies related to the specific CDM instance and session.

        -
        Note
        +
        Note

        For example, "temporary" and "persistent-license" sessions may have different requirements.

        2. @@ -5234,12 +5269,12 @@

        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.

        -
        Note
        +
        Note

        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.

        -
        Note
        +
        Note

        Among other things, this means that:

          @@ -5289,7 +5324,7 @@

          8.3 Support Multiple Keys

          Implementations MUST support multiple keys in each MediaKeySession object.

          -
          Note
          +
          Note

          The mechanics of how multiple keys are supported is an implementation detail, but it MUST be transparent to the application and these APIs.

          @@ -5304,7 +5339,7 @@

          8.4.1 Licenses Generated are Independent of Content Type

          Implementations SHOULD allow licenses generated with any Initialization Data Type they support to be used with any content type.

          -
          Note
          +
          Note

          Otherwise, the requestMediaKeySystemAccess() algorithm might, for example, reject a MediaKeySystemConfiguration because one of the initDataTypes is not supported with one of the videoCapabilities.

    @@ -5313,7 +5348,7 @@

    8.4.2 Support Extraction From Media Data

    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.

    -
    Note
    +
    Note

    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.

    @@ -5337,7 +5372,7 @@

    Media resources, including all tracks, MUST be encrypted and packaged per a container-specific "common encryption" specification that allows the content to be decrypted in a fully specified and compatible way when a key or keys are provided.

    -
    Note
    +
    Note

    The Encrypted Media Extensions Stream Format and Initialization Data Format Registry [EME-STREAM-REGISTRY] provides references to such stream formats.

    @@ -5350,7 +5385,7 @@

    SHOULD NOT be encrypted.

    -
    Note
    +
    Note

    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.

    @@ -5370,7 +5405,7 @@

    -
    Note
    +
    Note

    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.

    @@ -5619,13 +5654,13 @@

    User Agent and Key System implementations MUST consider media data, Initialization Data, data passed to 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.

    -
    Note
    +
    Note

    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.

    -
    Note
    +
    Note

    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.

    @@ -5638,7 +5673,7 @@

    Exploiting a CDM implementation that is not fully sandboxed and/or uses platform features may allow an attacker to access OS or platform features, elevate privilege (e.g. to run as system or root), and/or access drivers, kernel, firmware, hardware, etc. Such features, software, and hardware may not be written to be robust against hostile software or web-based attacks and may not be updated with security fixes, especially compared to the user agent. Lack of, infrequent, or slow updates for fixes to security vulnerabilities in CDM implementations increases the risk. Such CDM implementations and UAs that expose them MUST be especially careful in all areas of security, including parsing of all data.

    -
    Note
    +
    Note

    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.

    @@ -5646,7 +5681,7 @@

    If a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured, the user agent SHOULD ensure that users are fully informed and/or give explicit consent before loading or invoking it. Such implementations SHOULD only be supported on secure contexts to mitigate the potential for Network Attacks.

    -
    Note
    +
    Note

    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.

    @@ -5710,7 +5745,7 @@

    User Agents SHOULD ensure that users are fully informed and/or give explicit consent before a Key System that presents security concerns that are greater than other user agent features (e.g. DOM content) may be accessed by an origin. Such alerts and consent SHOULD be per origin to avoid valid uses enabling subsequent malicious access. (A full origin MUST be used rather than just the domain because the protocol is important for security as described above.) User agents SHOULD only persist consent for secure origins (see Secure Origin and Transport), to mitigate the potential for future abuse via Network Attacks.

    -
    Note
    +
    Note

    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).

    @@ -5746,7 +5781,7 @@

    Using these APIs on shared hosts compromises origin-based security and privacy mitigations implemented by user agents. For example, per-origin Distinctive Identifiers are shared by all authors on one host name, and peristed data may be accessed and manipulated by any author on the host. The latter is especially important if, for example, modification or deletion of such data could erase a user's right to specific content.

    -
    Note
    +
    Note

    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.

    @@ -5814,7 +5849,7 @@

    -
    Note
    +
    Note

    The type of information covered by this requirement includes but is not limited to:

      @@ -5936,7 +5971,7 @@

      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.

      -
      Note
      +
      Note

      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).

      @@ -5969,13 +6004,13 @@

      User agents MUST prompt or otherwise inform the user before allowing use of a Distinctive Identifier that is not unique per-origin and/or not clearable is used. User agents SHOULD prompt or otherwise inform the user before allowing use of all other Distinctive Identifier.

      -
      Note
      +
      Note

      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.

      -
      Note
      +
      Note

      Granting permissions to unauthenticated origins is equivalent to granting the permissions to any origin in the presence of a network attacker.

      @@ -5988,7 +6023,7 @@

      -
      Note
      +
      Note

      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.

      @@ -6010,7 +6045,7 @@
      Origin-independent individualization is performed between the CDM and an origin- and application-independent server. The process MUST be performed by the user agent and MUST NOT use these APIs.

      -
      Note
      +
      Note

      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.

      From ba2af45f6111c638191fcf756c51ef33c5632632 Mon Sep 17 00:00:00 2001 From: mwatson2 Date: Fri, 3 Jun 2016 11:30:10 +0100 Subject: [PATCH 03/10] Fix #75: Remove explicit forEach declaration on MediaKeyStatusMap (#209) --- encrypted-media-respec.html | 31 ++++------------ index.html | 73 +++++++++---------------------------- 2 files changed, 25 insertions(+), 79 deletions(-) diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html index 0a686e33..a3b6d7be 100644 --- a/encrypted-media-respec.html +++ b/encrypted-media-respec.html @@ -2055,16 +2055,17 @@

      MediaKeyStatusMap Interface

      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.

      iterable <BufferSource, MediaKeyStatus>
      - 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. +

      + 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. +

      readonly attribute unsigned long size
      @@ -2089,22 +2090,6 @@

      MediaKeyStatusMap Interface

      The of the key.
      - -
      void forEach()
      -
      -

      Calls callback once for each key-value pair present in the MediaKeyStatus map.

      -
      -
      ForEachCallback callback
      -
      A callback function
      -
      -
      - - -
      -
      BufferSource keyId
      -
      The .
      -
      MediaKeyStatus status
      -
      The key status.
      @@ -4151,7 +4136,7 @@

      Using All Events

      // Evaluate the current state using one of the map-like methods exposed by // event.target.. // For example: - event.target..forEach(function(keyId, status, map) { + event.target..forEach(function(status, keyId) { switch (status) { case : break; diff --git a/index.html b/index.html index 4bea8712..8d1bcdbb 100644 --- a/index.html +++ b/index.html @@ -1079,7 +1079,6 @@

    • 6.3.1 Attributes
    • 6.3.2 Methods
      • -
    • 6.3.3 Callback ForEachCallback Parameters

  • 6.4 MediaKeyMessageEvent @@ -3880,20 +3879,17 @@

    Note

    • 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 7
    -

    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);
-};
    + 
    interface MediaKeyStatusMap {
+    iterable<BufferSource,MediaKeyStatus>;
+    readonly        attribute unsigned long size;
+    boolean        has (BufferSource keyId);
+    MediaKeyStatus get (BufferSource keyId);
+};

    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. +

    @@ -3907,32 +3903,7 @@

    6.3.2 Methods

    -
    forEach
    -
    -

    Calls callback once for each key-value pair present in the MediaKeyStatus map.

    - - - - - - - - - - - - - - - - - - -
    ParameterTypeNullableOptionalDescription
    callbackForEachCallback - - ✘✘A callback function
    -
    Return type: void
    -
    get
    +
    get

    Returns the MediaKeyStatus of the key identified by keyId or undefined if the status of the key identified by keyId is not known.

    @@ -3984,16 +3955,6 @@

    - 
    callback ForEachCallback = void (BufferSource keyId, MediaKeyStatus status);
    - -
    -

    6.3.3 Callback ForEachCallback Parameters

    -
    keyId of type BufferSource
    -
    The key ID.
    status of type MediaKeyStatus
    -
    The key status.
    -
    -
    - 
    enum MediaKeyStatus {
     "usable",
     "expired",
@@ -5262,8 +5223,8 @@ 
    8.2.2 Encrypt Identifiers
    
         
    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.
         
    
-        
    
-          
    Issue 8
    
+        
    
+          
    Issue 7
    
           
    Add more specific text about ensuring the desired privacy properties when encrypting identifiers.
    
         
    
         
    This MAY be implemented using a server certificate.
    
@@ -5296,16 +5257,16 @@ 
    8.2.3 Use Per-Origin Identifiers
    
         
    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 9
    
+        
    
+          
    Issue 8
    
           
    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.
         
    
-        
    
-          
    Issue 10
    
+        
    
+          
    Issue 9
    
           
    Add more specific text about ensuring the desired non-reversible properties.
    
         
    
       
@@ -6512,7 +6473,7 @@ 
    // Evaluate the current state using one of the map-like methods exposed by
     // event.target.keyStatuses.
     // For example:
-    event.target.keyStatuses.forEach(function(keyId, status, map) {
+    event.target.keyStatuses.forEach(function(status, keyId) {
       switch (status) {
         case "usable":
           break;

From 6ff0593df3c1d5e264fb18706860103a4d250a22 Mon Sep 17 00:00:00 2001
From: ddorwin 
Date: Mon, 6 Jun 2016 11:18:39 -0700
Subject: [PATCH 04/10] Issue #117: Refine the definition of Distinctive
 Identifier (#218)

---
 encrypted-media-respec.html | 107 ++++++++--
 encrypted-media.js          |   3 +-
 index.html                  | 401 +++++++++++++++++++++++-------------
 3 files changed, 340 insertions(+), 171 deletions(-)

diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html
index a3b6d7be..771978c0 100644
--- a/encrypted-media-respec.html
+++ b/encrypted-media-respec.html
@@ -327,33 +327,90 @@ 
    Definitions
    
           
    
         
 
+        
    Non-Associable Identifiers
    
+        
    
+          
    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)
      • 
+            
    
+          
    
+        
    
+
         
    Distinctive Identifier
    
         
    
-          
    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:
       
+                
+              
      
+            
      • 
           
    
 
-          
    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 @@ 
    Get Supported Configuration and Consent
    
                   
    
                   
    
                   
    
-                    
    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.
    
                   
    
                 
                 
    
@@ -735,7 +792,7 @@ 
    Get Supported Configuration and Consent
    
               
               
  • If accumulated configuration's  value is , follow the steps for the first matching condition from the following list:
    
                 
    
-                  
    If the implementation requires a  for any of the combinations in accumulated configuration
    
+                  
    If the implementation requires use of a  for any of the combinations in accumulated configuration
    
                   
    
                     
    Change accumulated configuration's  value to .
    
                   
    
@@ -1069,8 +1126,14 @@ 
    MediaKeySystemConfiguration dictionary
    
           
           
    MediaKeysRequirement distinctiveIdentifier = "optional"
    
           
    
-            Whether a persistent  is required.
-            
    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:
+            
    
+            
      
+              
    1. Any individualization process MUST NOT use and messages involved MUST NOT contain a Distinctive Identifier.
      2. 
+              
    2. Messages from the CDM, such as  events, MUST NOT contain a , even in an encrypted form.
      3. 
+            
    
           
    
           
    MediaKeysRequirement persistentState = "optional"
    
           
    
@@ -2963,7 +3026,7 @@ 
    Allow Persistent Data to Be Cleared
    
           
    
             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.
           
    
-          
    
+          
    
             Implementations SHOULD allow users to clear persistent data along with cookies [[!COOKIES]] and other site data.
             It is RECOMMENDED that users be offered the option to clear persistent data as part of user agent features to clear browsing history.
           
    
@@ -3028,8 +3091,8 @@ 
    Use Per-Origin Identifiers
    
           
    
           
    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.
    
@@ -3040,7 +3103,7 @@ 
    Allow Identifiers to Be Cleared
    
           
    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.
           
    
         
       
@@ -3569,7 +3632,7 @@ 
    Concerns
    
 
           
    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.
    
@@ -3591,11 +3654,11 @@ 
    Mitigations
    
               
    
             
    
 
-            
    Use of (non-reversible) per-origin identifiers
    
+            
    Use of non-associable per-origin identifiers
    
             
    
               
-              
    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.
               
    
             
    
 
@@ -3696,7 +3759,7 @@ 
    Origin-Independent Individualization
    
             
    
             
    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:
    
             
      
diff --git a/encrypted-media.js b/encrypted-media.js
index 7f343ff7..e22b25e2 100644
--- a/encrypted-media.js
+++ b/encrypted-media.js
@@ -162,6 +162,8 @@
     'initialization-data': { func: term_helper, fragment: 'initialization-data', link_text: 'Initialization Data'  },
     'initialization-data-type': { func: term_helper, fragment: 'initialization-data-type', link_text: 'Initialization Data Type'  },
     'session-id': { func: term_helper, fragment: 'session-id', link_text: 'Session ID'  },
+    'associable': { func: term_helper, fragment: 'associable', link_text: 'associable'  },
+    'non-associable': { func: term_helper, fragment: 'non-associable', link_text: 'non-associable'  },
     'distinctive-identifier': { func: term_helper, fragment: 'distinctive-identifier', link_text: 'Distinctive Identifier'  },
     'distinctive-identifiers': { func: term_helper, fragment: 'distinctive-identifier', link_text: 'Distinctive Identifiers'  },
     'record-of-key-usage': { func: term_helper, fragment: 'record-of-key-usage', link_text: 'record of key usage'  },
@@ -234,7 +236,6 @@
 
     'queue-message-algorithm': { func: term_helper, fragment: 'queue-message', link_text: 'Queue a "message" Event',  },
     'session-closed-algorithm': { func: term_helper, fragment: 'session-closed', link_text: 'Session Closed',  },
-    'close-session-algorithm': { func: term_helper, fragment: 'close-session', link_text: 'Close Session',  },
     'monitor-cdm-algorithm': { func: term_helper, fragment: 'monitor-cdm', link_text: 'Monitor for CDM Changes',  },
     'encrypted-block-encountered-algorithm': { func: term_helper, fragment: 'encrypted-block-encountered', link_text: 'Encrypted Block Encountered',  },
     'attempt-to-decrypt-algorithm': { func: term_helper, fragment: 'attempt-to-decrypt', link_text: 'Attempt to Decrypt',  },
diff --git a/index.html b/index.html
index 8d1bcdbb..f3ab8c5e 100644
--- a/index.html
+++ b/index.html
@@ -846,6 +846,12 @@
         "initialization data type": [
           "initialization-data-type"
         ],
+        "non-associable": [
+          "non-associable"
+        ],
+        "associable": [
+          "associable"
+        ],
         "record of key usage": [
           "record-of-key-usage"
         ],
@@ -1446,11 +1452,42 @@ 
      
       
 
+      
      Non-Associable Identifiers
      
+      
      
+        
      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.
      
+
+        
      
+          
      Note
      
+          
      
+            
      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)
        
+              
        • 
+            
      
+          
      
+        
      
+      
      
+
       
      Distinctive Identifier
      
       
      
-        
      
-          
      Issue 3
      
-          
      Issue 117 - The definition of Distinctive Identifier needs to be refined and will likely change.
      
+        
      
+          
      Note
      
+          
      
+            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:
      
         
        
@@ -1458,55 +1495,115 @@ 
        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, 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.
          
+                
          
+                  
          Note
          
+                  
          For example, via some mechanism external to the user agent, such as an OS-level mechanism.
          
+                
          
+              
          • 
+            
        
+            
        
+              
        Note
        
+              
        
+                
        Other properties of concern that are normatively prohibited include:
        
+                
+              
        
+            
        
           
        • 
         
      
 
         
      
-          
      Note
      
-          
      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.
+          
      Note
      
+          
      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.
           
      
         
      
 
         
      
-          
      Note
      
+          
      Note
      
           
      
             
      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.
          
+                  
          • 
+                
        
+              
        • 
             
      
           
      
         
      
         
      
-          
      Note
      
+          
      Note
      
           
      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.
           
      
         
      
@@ -1557,7 +1654,7 @@ 
      requestMediaKeySystemAccess
      
           
      
             
      
-              
      Note
      
+              
      Note
      
               
      Calling 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.
               
      
             
      
@@ -1617,15 +1714,15 @@ 
      incumbent settings object is not a secure context [POWERFUL-FEATURES], run the following steps:
      
 
-                
      
-                  
      Issue 4
      
+                
      
+                  
      Issue 3
      
                   
      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.
      
                 
      
                 
        
                   
      1. 
                     
        If the result of running the Are insecure contexts allowed? algorithm is Allowed, skip the next step.
        
                     
        
-                      
        Note
        
+                      
        Note
        
                       
        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.
                       
        
                     
        
@@ -1633,7 +1730,7 @@ 
        NotSupportedError.
        
                     
        
-                      
        Note
        
+                      
        Note
        
                       
        
                         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 +1790,7 @@ 
        NotSupportedError.
        
                     
        
-                      
        Note
        
+                      
        Note
        
                       
        keySystem was not supported/allowed or none of the configurations in supportedConfigurations were supported/allowed.
        
                     
        
                   
        2. 
@@ -1714,12 +1811,12 @@ 
        3.1.2.1 Get Supported Configuration
        
           
        Given a Key Systems implementation implementation, MediaKeySystemConfiguration candidate configuration, and origin, this algorithm returns a supported configuration or NotSupported as appropriate.
        
           
        
-            
        Note
        
+            
        Note
        
             
        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.
             
        
           
        
           
        
-            
        Note
        
+            
        Note
        
             
        
               
        
                 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 +1890,7 @@ 
        
@@ -1842,11 +1939,11 @@ 
    
               
    
-                
    Note
    
+                
    Note
    
                 
    
                   
    
                     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 +2092,7 @@ 
    
             
    • 
@@ -2044,7 +2141,7 @@ 
    
-                    
    Note
    
+                    
    Note
    
                     
    Case-sensitive string comparison is RECOMMENDED because RFC 6381 [RFC6381] says, "Values are case sensitive" for some formats.
    
                   
    
                 
@@ -2156,7 +2253,7 @@ 
    
-                    
    Note
    
+                    
    Note
    
                     
    For example, if audio/video type is Video and the top-level type is not "video" or media types contains non-video codecs.
    
                   
    
                 
@@ -2166,7 +2263,7 @@ 
    media data for the combination of container, media types, robustness and local accumulated configuration in combination with restrictions:
    
                   
    
-                    
    Note
    
+                    
    Note
    
                     
    requested media capability (content type and robustness) must be supported with all previously added requested media capabilities.
    
                   
    
                   
      
@@ -2175,7 +2272,7 @@ 
      
-                        
      Note
      
+                        
      Note
      
                         
      
                           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 +2295,7 @@ 
      
-                        
      Note
      
+                        
      Note
      
                         
      
                           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 +2308,7 @@ 
      
-                
      Note
      
+                
      Note
      
                 
      None of the MediaKeySystemMediaCapability elements in requested media capabilities is supported in combination with partial configuration.
      
               
    
             
@@ -2234,7 +2331,7 @@