W3C home > Mailing lists > Public > public-html-media@w3.org > March 2015

[encrypted-media] Remove "persistent-release-message" MediaKeySessionType

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Tue, 31 Mar 2015 23:07:44 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-65565847-1427843263-sysbot+gh@w3.org>
ddorwin has just created a new issue for 

== Remove "persistent-release-message" MediaKeySessionType ==
**Summary:** It does not make sense to include a feature in the spec 
that is not a common or accepted practice, is not widely supported, 
and is fundamentally flawed. In addition, doing so will lead to an 
unsustainable series of requests for unimplementable features in the 
spec and/or implementations.

There is only one 
 content provider planning to use the _secure proof of key release for
 non-persistent licenses_ feature represented by 
 It is **not a common practice, nor is there accepted consensus** on 
its utility or effectiveness. Widely-accepted and supported 
alternatives are already supported by the spec and implementations. 
Including this optional feature in the spec unnecessarily increases 
the likelihood of platform fragmentation/segmentation: This feature is
 unrelated to content protection or robustness, yet a content provider
 reliant on it (and subsequent requirements) may deny content to 
clients that otherwise support the relevant levels of robustness.

In the [March 17 
 Mark said "the system is very much dependent on getting these 
messages", including after the application has been closed (something 
that browsers and most user agents cannot support). He also said they 
(Netflix) "don't know what the frequency of these messages will be in 
the field" or how important the reliability of receiving the messages 
is to its effectiveness. He also hinted they may find more cases where
 they would want to report such messages. The mechanism is 
fundamentally unreliable - placing server responsibilities on every 
client yet expecting the reliability of the server - and thus begets 
additional troublesome feature to mitigate that.

Additional technical issues:
* The mechanism is unreliable in a browser or other multitasking 
* This may significantly reduce its effectiveness and introduce user 
friction not present with the alternative solutions.^^
* This has led to repeated requests (as recent as [March 17, 
2015](http://www.w3.org/2015/03/17-html-media-minutes.html#item08)) to
 ensure or allow implementations to send messages after the 
window/tab/user agent have been closed by the user. This is not 
something we can specify, and any attempt to make such behavior 
optional would likely lead to segmentation.
* This session type is essentially a `“persistent-license”` session 
with a short expiration time. It introduces a requirement that CDMs be
 able to persist state even for [“simple [online] 
 This raises the bar of entry for new implementations and/or may 
preclude some implementations/devices (including private browsing 

Note: This session type specifically relates to **persisting** a 
secure proof of key/license release of non-persistent licenses for 
later retrieval. It does **not** apply to release messages related to 
persistent licenses 
 sessions) or even release messages from `“temporary”` sessions that 
do not need to be persisted.

^ Examples include the user closing the tab or browser, especially for
 clients that implement quick shutdown; the user closing a laptop lid;
 tab eviction (for limited resources, especially - but not limited to 
- on mobile devices); crashes.
^^ For example, if a user watching a video closes the laptop lid then 
goes to a TV to resume, the proof of key release will not have been 
sent and the user will be unable to resume until some timer expires or
 they open the laptop and stop the video there. This is **not** a 
problem with alternative mechanisms, which can gracefully handle the 
transition, or at least limit the duration of the problem.

See https://github.com/w3c/encrypted-media/issues/45
Received on Tuesday, 31 March 2015 23:07:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 31 March 2015 23:07:46 UTC