Intent to Implement: EME persistent-usage-record session
Xiaohan Wang (王消寒)
Contact Emails
xhw...@chromium.org, hben...@chromium.org
Proposed Spec Change
Diff against current EME spec: https://github.com/WICG/encrypted-media/pull/1
Preview of EME spec with the diff applied: https://htmlpreview.github.io/?https://github.com/WICG/encrypted-media/blob/master/index.html#dom-mediakeysessiontype-persistent-usage-record
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:
Firefox: No signals
Safari: No signals
Web developers:
No signals from other web developers
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
Alex Russell
Xiaohan Wang (王消寒)
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:
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.
