{minutes} HTML WG media telecom 2013-06-04 - EME status and bugs

http://www.w3.org/2013/06/04-html-media-minutes.html

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

________________________________

[http://www.w3.org/Icons/w3c_home]<http://www.w3.org/>

HTML Media Task Force Teleconference
04 Jun 2013

See also: IRC log<http://www.w3.org/2013/06/04-html-media-irc>

Attendees

Present
+1.425.269.aaaa, davide, ddorwin, pladd, pal, adrianba, paulc, BobLund, joesteele, [Microsoft], +1.714.338.aabb
Regrets
Chair
Paul Cotton
Scribe
joesteele
Contents

 *   Topics<http://www.w3.org/2013/06/04-html-media-minutes.html#agenda>
    *   Agenda<http://www.w3.org/2013/06/04-html-media-minutes.html#item01>
    *   Previous minutes<http://www.w3.org/2013/06/04-html-media-minutes.html#item02>
    *   Action items and issues<http://www.w3.org/2013/06/04-html-media-minutes.html#item03>
    *   EME status and bugs<http://www.w3.org/2013/06/04-html-media-minutes.html#item04>
    *   Outstanding bugs<http://www.w3.org/2013/06/04-html-media-minutes.html#item05>
    *   ACTION-12<http://www.w3.org/2013/06/04-html-media-minutes.html#item06>
    *   ACTION-10<http://www.w3.org/2013/06/04-html-media-minutes.html#item07>
 *   Summary of Action Items<http://www.w3.org/2013/06/04-html-media-minutes.html#ActionSummary>

________________________________

<trackbot> Date: 04 June 2013
<scribe> scribe: joesteele
Agenda
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Jun/0010.html
Previous minutes
http://www.w3.org/2013/05/21-html-media-minutes.html
paulc: discussed EME at the May 21st mtg
... lots of action items
Action items and issues
<paulc> ISSUE-1: Consider moving the Clear Key definition into a separate specification
<trackbot> Notes added to ISSUE-1 Consider moving the Clear Key definition into a separate specification.
paulc: listed as if dealing with individual bugs -- most of them are
<paulc> Still outstanding today - will be worked on in the future.
EME status and bugs
paulc: last updated May 28th
<paulc> Status update: http://lists.w3.org/Archives/Public/public-html-media/2013May/0125.html
paulc: Davids email explaining that update is above
... several actions and editorials in there
Outstanding bugs
<paulc> http://tinyurl.com/7tfambo
UNKNOWN_SPEAKER: count was 23
paulc: now 22 -- one has been dealt with
... rest of agenda is actions
... believe others are done
... let's step through the agenda
ACTION-12
<paulc> ACTION-12?
<trackbot> ACTION-12 -- Mark Watson to add text to Editor's Draft for bug 21155 -- due 2013-05-28 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/12
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013May/0126.html
paulc: for Mark -- is Mark here?
... don't believe so
... (reading Marks update to the bug)
... has anyone looked at the bug?
ddorwin: read it and no comments
bug: 21155
paulc: resolved as fixed
ACTION-10
ACTION-10?
<trackbot> ACTION-10 -- Adrian Bateman to discuss bug 21855 with johnsim -- due 2013-04-22 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/10
paulc: still open -- our oldest action
adrianba: we met and went through all the actions and outstanding bugs. should have something on the list in the next day or so
<paulc> ACTION-10 is due on Jun 11
<adrianba> ACTION-10: due jun 11
<trackbot> Notes added to ACTION-10 Discuss bug 21855 with johnsim.
paulc: moving the due date to June 11
<adrianba> ACTION-10 due jun 11
<trackbot> Set ACTION-10 Discuss bug 21855 with johnsim due date to jun 11.
paulc: anticipating we will have the same with some other items
ACTION-13?
<trackbot> ACTION-13 -- Adrian Bateman to review comments and add text to editor's draft for bug 19009 -- due 2013-05-28 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/13
paulc: can you confirm you want a due date of next week for these?
<adrianba> ACTION-13 due jun 11
<trackbot> Set ACTION-13 Review comments and add text to editor's draft for bug 19009 due date to jun 11.
ACTION-15?
<trackbot> ACTION-15 -- Adrian Bateman to add text based on henri's comment to the spec for bug 21203 -- due 2013-05-28 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/15
adrianba: this is pending review -- made changes based on Henri's proposal
... means that if the media data is not coming from CORS same origin or with an appropriate header -- needKey won't fire and instead get error
... bug was resolved as fixed
... please read through and see if makes sense
ACTION-17?
<trackbot> ACTION-17 -- Adrian Bateman to provide feedback on keySystem string bugs 16540 and 20798 -- due 2013-05-28 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/17
ACTION-17 due on june 11th
<trackbot> Set ACTION-17 Provide feedback on keySystem string bugs 16540 and 20798 due date to on june 11th.
ACTION-19?
<trackbot> ACTION-19 -- John Simmons to will work with adrianba and jdsmith to make a proposal for bug 21854 -- due 2013-06-04 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/19
paulc: due date to set out?
... this is for john
johnsim: these are all related to life cycle of sessions
ACTION-19 due on june 11th
<trackbot> Set ACTION-19 Will work with adrianba and jdsmith to make a proposal for bug 21854 due date to on june 11th.
paulc: other bugs for discussion -- there are 22 other bugs
... went from recent to older last time
... where do we go today?
joesteele: I nominate 21869 for discussion
joesteele: my main concern in this thread is about key storage for cached keys
johnsim: I feel that what a key system is doing is out of scope of EME -- spec is specifying events and methods
... in the CDM under the hood whether it stores keys or not does not seem to be something we want to spec
... that said there is the issue of when a CDM has a key that fulfills initialization data that does affect the flow
... that is a cirucumstance we need to know whether to accomodate
... MarkW has stated in some cases he does not want the stored key to be used
... might need a way to indicated this from the applicaiton
... but don't think EME should say one way or the other whether EME should store keys
adrianba: think this falls into the privacy bug we have open -- called out in the document
... storage is within the scope of the CDM
... point Henri is making is that can't use this storage for tracking across sites -- CORS does not completely address
... want to make sure can't use data storage of a CDM as third party cookies storage when cookies are disabled
... will be guidance we need to add to the spec to draw out this privacy concern
... talke about the mitigiations CDMs should make as well
paulc: proposing to add more material to the docs?
adrianba: yes and there is a bug for that
<ddorwin> We should add this item to the privacy bug and add something like "UAs should ensure any CDM storage respects origin, etc."
ddorwin: concur with adrian that we should add the privacy bits to the doc
<ddorwin> I think it's preferable not to have the CDM store data, whether it be keys, key releases, or something else. It adds a lot of complexity, especially when trying to respect privacy, origin, etc.
<adrianba> Privacy Concern Bug<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965>
ddorwin: trying to do what is in the privacy bug adds complexity.
<ddorwin> Are there use cases where having the _app_ store the (encrypted) key. Browsers will have a much better chance of providing the appropriate controls and expected behaviors if storage is handled by the application using existing APIs.
ddorwin: not saying that the CDM could not store data -- but app could cache it
johnsim: are you arguing that key systems should not be allowed to store keys?
ddorwin: I would prefer, but might not be enforceable
johnsim: we have multiple existing DRM systems and want to take that functionality and move to the browser model
... if we don't support things like stored keys we are breaking a large number of existing DRMs
... seems like an undesirable thing
ddorwin: would like to solve this in a web-compatible way
... might not always be possible
paulc: dumb question -- we have said CDM is out of scope -- why would we say anything about the CDM?
adrianba: we have to say something about CDMs
... goal is to provide an abstract model for interaction with CDMs - but CDMs are required to provide some common functionality
... so we can interact with the API
... the way that it is implemented is conformant to that conceptual model
... but we do define certain restrictions, need to give guidance and explanation of the reason behind the guidance
... in the past specs have not done a good job of explaining the rationale here
... we are not saying you can't do anything else, but providing guidance
paulc: do you believe we have adequate bugs to drive this new content to be added?
adrianba: think the answer is yes -- but in the context of this bug
<paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869
adrianba: for this bug the answer is we don't need to say anything additional beyond general privacy mitigations
... everything else is out of scope
johnsim: think Adrian said it well, we do have to say some things about what the CDM does
... when the CDM is doing something that matters to the application it should be speciifed
... everything else is out of scope
... question is whether we have identified everything that matters
<johnsim_> +q
joesteele: I am ok with the privacy text solution. However if there is a desire within the group to not allow the CDM to store data directly, and instead force the app to do that work
scribe: then additional APIs to allow the CDM to communicate which key message should be retained back to the applicaiton. This is a fairly common use case and one I think we should support without requiring lots of additinal works from the app builder.
<ddorwin> I don't think the instructions to store a key (i.e from a key hierarchy) need to be in a key message or come from the CDM. If there is a key hierarchy (or an app wants to support this), the application could be responsible for knowing about key hierarchies, obtaining the higher level key and storing it to the client using one of the existing storage APIs." but was lost because I lost connectivity. It was a recording of the discussion we were having.
<ddorwin> Yes, this might require some knowledge of key hierarchies or the key system in the app, but I think that is better than trying to solve the origin and privacy issues inside the CDM.
pal: my read is that the CDM is completely opaque -- needs a key and returns the key into the CDM (from the app)
... are we suggesting that this will change?
... if we are changing the basic assumptions that would be big
johnsim: I don't think that solutions where the application has to be cognizant of key acqusition systems is a good thing. I think all key systems in use today have the ability to cache keys.
... the issue is whether the application allows the CDM to use a cached key as opposed to making a key request
... if the application could say this in a way that is CDM independent -- that is a requirement from MarkW
... definitely use case where we want the cached key to be used
... not just for performance, but restarting playback, etc.
... just need the assertion about whether a stored key can be used
pal: what does cached key mean in this context?
... in particular does it mean pre-provisioned keys
... ?
johnsim: those are not DRM keys
... there are two different bugs here -- the privacy, trackability issues exist regardless of whether we allow keys to be cached
... we are also trying to create a set of methods and events inside the browser allowing existing types if apps to use the browser without a lot of changes
... if we disable that, we will hurt the effort. My opinion is that we should support cached keys in a way that is not "key system aware"
... We also need to respect the privacy issues
pal: spec as currently written does not prevent this right?
johnsim: yes
... however if it does cache a key does it fire a key message or not?
joesteele: And where does it store that key?
johnsim: there are cases where we want to force a key request but there is no mechanism today
paulc: are the use cases you described covered by other bugs?
johnsim: yes
paulc: 5 till -- what are the next steps?
<paulc_> Bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869
<ddorwin> No one is throwing out the capability to cache keys. It's just a matter of who/what is caching them. In the spec, the application is in control of key exchange, error handling, etc. While DRM systems may have supported caching keys in the past, it was also responsible for key exchange and in some cases network, display, etc.
<paulc_> Can John add his specific use cases to this bug?
ddorwin: everyone is in agreement on the privacy issue
... rest seems philosophical -- might not need to be addressed as a bug
<paulc_> Conclusions: deal with privacy items in bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965 Privacy Concern Bug
ddorwin: just because existing key systems do things does not say CDM needs to do them
<paulc_> Should we make 21869 depend on 20965, Resolved 21869 and then revisit 20965 to decide if it can be closed.
joesteele: +1
paulc: any objections?
<paulc_> No objections to paul's plan.
paulc: we have a bunch of items queued up -- we will have some progress on them. I could use help on determining which other bugs we should queue up in two weeks
ddorwin: still waiting on feedback for some
paulc: I will be in Alaska in two weeks so I won't be able to chair. Any volunteers?
... will send a note to the editors
... Thanks everyone
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.138 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-06-04 16:16:58 $
________________________________