{minutes} HTML WG media telecon 2015-09-22 - EME bug status

http://www.w3.org/2015/09/22-html-media-minutes.html <http://www.w3.org/2015/09/22-html-media-minutes.html>

— Courtesy of jdsmith


 <http://www.w3.org/>
HTML Media Task Force Teleconference

22 Sep 2015

Agenda <https://lists.w3.org/Archives/Public/public-html-media/2015Sep/0021.html>
See also: IRC log <http://www.w3.org/2015/09/22-html-media-irc>
Attendees <>
Present
joesteele, BobLund, jdsmith, davide, ddorwin, markw, jdsmith, plh, slightlyoff, cwilso, robink, Travis, adrianba
Regrets
Chair
plh
Scribe
jdsmith
Contents

Topics <http://www.w3.org/2015/09/22-html-media-minutes.html#agenda>
Discussion on ISSUE-85 with TAG members <http://www.w3.org/2015/09/22-html-media-minutes.html#item01>
Media Task Force F2F meeting <http://www.w3.org/2015/09/22-html-media-minutes.html#item02>
MSE and EME heartbeat publications <http://www.w3.org/2015/09/22-html-media-minutes.html#item03>
ISSUE-41, ISSUE-52 and ISSUE-53 <http://www.w3.org/2015/09/22-html-media-minutes.html#item04>
Recent EME issues with outstanding pull requests <http://www.w3.org/2015/09/22-html-media-minutes.html#item05>
Issue-63 <http://www.w3.org/2015/09/22-html-media-minutes.html#item06>
ISSUE-17 - Replace "fire a simple event" with "fire an event" for non-simple Events <http://www.w3.org/2015/09/22-html-media-minutes.html#item07>
ISSUE-71 - Be explicit about aborting steps when resolving a promise early <http://www.w3.org/2015/09/22-html-media-minutes.html#item08>
Summary of Action Items <http://www.w3.org/2015/09/22-html-media-minutes.html#ActionSummary>
<trackbot> Date: 22 September 2015
<slightlyoff> I only have 30-ish minutes
First topic: https://github.com/w3c/encrypted-media/issues/85 <https://github.com/w3c/encrypted-media/issues/85>
Discussion on ISSUE-85 with TAG members

davide has briefed TAG last week on topic.
<ddorwin> not me jdsmith
markw: Don't believe this is an architectural issue, but implementation options. Takes place entirely within the UA.
<slightlyoff> is this something that's going to be an interop hazard?
markw: Can understand some browsers may not want to implement, and it's optional for that reason.
Travis: The choice to do some extra cleanup outside the browser session seems strange to TAG.
<slightlyoff> Travis: <a ping>
markw: It's understood that there will be cases where messages are lost. Experience has shown with current implementations that it can be reliable enough.
... Closed systems like TVs can write as they go and there's no issue with writing data as they go.
... On PCs, some implementations may not be able to sufficiently protect stored data and for them writing data on session close may be more appropriate.
<slightlyoff> I'd like to understand what % of failure is being experienced and is seen as acceptable
ddorwin: Two options: Have secure storage, can write periodically. If not, write the data at the end of session.
slightlyoff: Would like to know more about what level of robustness is secure enough?
markw: Robustness is distinct from frequency of success. If you have protections against alteration, but not rollback, then write as you go isn't robust enough.
Travis: Is there a way the user agent can regularly ping the server to report that playback is ongoing?
markw: That's been a topic of discussion, and license renewal is one way to implement that.
... Have for a long time had a goal that playback will continue with loss of server connectivity.
... Secure release is designed to do that.
Travis: I was asking about a heartbeat that would indicate ongoing playback, but would still work with loss of connectivity.
markw: Use those now.
slightlyoff It seems that ping suppression could be detected, if it was commonly detected from specific accounts.
markw: We don't believe that pattern would be significantly different from normal users playing content for short duration.
slightlyoff: What's the enforcement mechanism you would use on accounts that show mis-use?
Travis: I'd like to ask about client robustness requirements again.
... Secure tamper proof storage for keys seems necessary in some scenarios.
<ddorwin> I was dropped
<ddorwin> dialing back in
markw: We don't have offline scenarios that might require this. Robustness requirements depend greatly on the features provided by the particular DRM.
... If licenses are stored, then it needs to be protected.
<slightlyoff> I have to go, but I'd like to understand why this feature would be "optional"?
markw: Rollback protection could be important for limited duration licenses.
<slightlyoff> thanks BobLund
<Zakim> ddorwin, you wanted to answer offline question
BobLund: There are cable companies that also want this features.
slightlyoff: This feature was mentioned earlier as optional. Why would it be optional?
<slightlyoff> thanks markw
markw: There are some members that believe implementation is difficult.
... Circumstances would determine what we might do in response, and license renewal would perhaps be considered.
ddorwin: There is an offline option that requires key and state storage. Secure release also requires secure storarge that should be tamperproof or tamper evident.
plh: If the feature is optional, you might consider other means. Are these other means inadequate?
markw: There are no other means that we feel are sufficient.
... There are insecure alternatives (e.g. page JS reporting activity). What we are interested in here is having a solution that brings some of the robustness from the DRM component to the problem.
Travis: It sounds like you want secure release to be spec'd and available on implementations somewhere.
... I'm a little dubious of optional features based on past descriptions.
jdsmith: Would prefer not optional, but we've not resolved implementation issues.
Travis: Is the ask of TAG to make architectural decision on the secure release feature?
ddorwin: Yes.
Travis: If the spec requires data storage on shutdown, that would be a stretch. That may not be decisive here, since there are options for implementation.
markw: If writing data on session close is an issue, we should probably spend some more time discussing it. Clearly code is executed when browsers are closed today, and it's not clear how this is different.
Travis: Some native app models have no guarantees about shutdown, and are required to incrementally save state. It is correct that some app models run code on shutdown.
Media Task Force F2F meeting

MSE and EME heartbeat publications

<joesteele> +1
jdsmith: Want to confirm that we want to publish on every commit (auto publish).
+1
<ddorwin> +1
plh: A PR is ready that will turn this on.
ISSUE-41, ISSUE-52 and ISSUE-53

jdsmith: I will approve it today.
<plh> https://github.com/w3c/encrypted-media/pull/88 <https://github.com/w3c/encrypted-media/pull/88>
<plh> https://github.com/w3c/encrypted-media/pull/92 <https://github.com/w3c/encrypted-media/pull/92>
jdsmith: I'd like to review these today.
Recent EME issues with outstanding pull requests

plh: ddorwin, if you don't hear from jdsmith today, consider it approved.
<plh> https://github.com/w3c/encrypted-media/pull/87 <https://github.com/w3c/encrypted-media/pull/87>
Issue-63

<plh> https://github.com/w3c/encrypted-media/pull/66 <https://github.com/w3c/encrypted-media/pull/66>
ISSUE-17 - Replace "fire a simple event" with "fire an event" for non-simple Events

<plh> https://github.com/w3c/encrypted-media/issues/17 <https://github.com/w3c/encrypted-media/issues/17>
<joesteele> Looks good to me
ISSUE-71 - Be explicit about aborting steps when resolving a promise early

jdsmith: I'll proceed with implementation.
<plh> https://github.com/w3c/encrypted-media/issues/71#issuecomment-136507577 <https://github.com/w3c/encrypted-media/issues/71#issuecomment-136507577>
<joesteele> s/slightlyoff It seems/slightlyoff: It seems/
Summary of Action Items <>[End of minutes]
Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015/09/22 16:05:48 $