Intent to Implement: EME persistent-usage-record session

221 views
Skip to first unread message

Xiaohan Wang (王消寒)

unread,
Aug 17, 2018, 12:49:09 PM8/17/18
to blink-dev

Contact Emails

xhw...@chromium.org, hben...@chromium.org


Proposed Spec Change


Summary

Support a new MediaKeySessionType “persistent-usage-record 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. See the proposed spec change for more details.


Motivation

Certain content/service providers require this feature in order to deliver content at higher quality levels.


Interoperability and Compatibility Risk

Interoperability risk: we have received some public support:


Compatibility risk is the likelihood that a change will break existing web content loaded in Chromium. Since this feature adds a new session type to the Encrypted Media Extensions spec that nobody is currently using, there should be no compatibility risks. Use of this API is entirely optional, so there is no impact on existing applications.


Privacy Risk

See section 11.4.1 on updated privacy concerns and mitigations on user tracking related to records of key usage. In summary, records of key usage stored by or on behalf of the CDM can be used to track a user across multiple sessions. This is because content providers can choose the key IDs used in a record of key usage, which in the worst case can be chosen and used to uniquely identify the user. The implementation will use the techniques described in section 11.4.2 to mitigate the risks of tracking, including using per-origin, per-profile storage (to avoid cross origin tracking), providing users the ability to clear the storage easily, etc.


Ongoing technical constraints

Content/service providers typically have robustness requirements on the quality of implementation beyond what’s described in the spec text. For example, record of key usage  may require tamper-evident-storage or even hardware support to prevent easy tampering.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. This is an optional feature in the spec and will only be supported on selected platforms, e.g. where tamper-evident-storage or platform support is available.


OWP launch tracking bug

TBD


Link to entry on the feature dashboard

TBD


Requesting approval to ship?

No

K. York

unread,
Aug 19, 2018, 5:13:43 PM8/19/18
to blink-dev
I think you missed a privacy risk there - because feature availability depends on more than just the platform type but also whether certain hardware is present, the availability / unavailability of the feature is an extra cross domain tracking risk.

Alex Russell

unread,
Aug 21, 2018, 12:40:48 PM8/21/18
to blink-dev
+1 to the privacy question. I'm also concerned that this appears to be the return of Secure Stop, a feature which consumed more than a year of debate at the TAG and was eventually prevented from shipping due to the broad incompatibility with the way HTML context lifetimes are described in existing specs.


Is this proposal substantially different? And have you requested TAG review?

Xiaohan Wang (王消寒)

unread,
Sep 10, 2018, 3:58:47 PM9/10/18
to Alex Russell, blink-dev
Sorry for the delayed reply.


On Privacy Concern:

This is a legit point. By itself, the availability/unavailability of this feature could add some entropy to the tracking vector. However, I would argue that given the presence of other stronger APIs (e.g. GPU info detection), the conditional entropy it adds is much less, if not minimal.


On Return of Secure Stop:

Yes, on the spec land, this is a direct revert of the previously removed sections on persistent-usage-record session. As described in the motivation section, we intend to implement this feature because it is required by certain content/service providers in order to deliver content at higher quality levels.


Given the history of this feature in EME, I fully agree a new round of TAG review is needed. We’ll start the TAG review process separately. For those who are not familiar with the background, these two threads have a lot of context on previous discussions:

  1. https://github.com/w3ctag/design-reviews/issues/73

  2. https://github.com/w3c/encrypted-media/issues/85

Earlier discussion can also be found here, and especially this summary provides additional background.


That being said, the implementation we are currently planning on does not require the CDM to do any special work around shutdown time. It relies on tamper-evident-storage so that it can save record of key usage periodically (subject to key usage accuracy, e.g. every minute) throughout the playback. This will achieve the same observable behavior as proposed by the spec change. The requirement of tamper-evident-storage is part of why we are only planning to implement this feature on selected platforms.


This raises the question of whether we should update the proposed spec change on persistent-usage-record session to better reflect what’s actually being implemented by browsers. I’ll leave that to the TAG review and spec discussion.


Best,

Xiaohan


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0696a8e6-8a5e-41c4-804a-99535a21a24e%40chromium.org.

Mark Watson

unread,
Sep 20, 2018, 5:36:40 PM9/20/18
to blink-dev
Hi Alex,

Regarding the historical record, the feature was removed from the original specification because there were not two interoperable implementations. There was never consensus that there was a "broad incompatibility with the way HTML context lifetimes are described in existing specs" or agreement that it could not be shipped for this or similar reasons.

Xiaohan,

Regarding the implementation approach of periodically saving the record of key usage, the specification was explicitly written to admit this approach as well as others. In Section 5, it says "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." There shouldn't be anything in the specification which skews it to one implementation approach or another. If you think there is, please file an issue.

...Mark

Xiaohan Wang

unread,
Feb 11, 2020, 6:51:01 PM2/11/20
to blink-dev, Mark Watson
Hello Alex,

Reviving this old thread after >1 year!

Did my reply address the privacy concern you had? I wonder what's the next step if we want to move this forward. Shall I request the TAG review?

Best,
Xiaohan
Reply all
Reply to author
Forward
0 new messages