HTML Media Task Force Teleconference -- 04 Jun 2013

<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.

UNKNOWN_SPEAKER: 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?

I nominate 21869 for discussion

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

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

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.

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?

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.

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

s/UNKNOWN_SPEAKER: count/paulc: count/

<ddorwin> The following was supposed to come after "additional work from the app builder. 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> 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. 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.

<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.

s/UNKNOWN_SPEAKER: listed /paulc: listed/

s/UNKNOWN_SPEAKER\: listed /paulc\: listed/

- DRAFT -

HTML Media Task Force Teleconference

04 Jun 2013

Attendees

Contents