See also: IRC log
<trackbot> Date: 04 June 2013
<scribe> scribe: joesteele
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Jun/0010.html
http://www.w3.org/2013/05/21-html-media-minutes.html
paulc: discussed EME at the May
21st mtg
... lots of action items
<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.
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
<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
<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?
<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.
+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
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.
ok
<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/
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Eme status/EME status/ Succeeded: s/AGENDA-12/ACTION-12/ Succeeded: s/coments/comments/ Succeeded: s/make sense/see if makes sense/ Succeeded: s/mitigiations/mitigations/ FAILED: s/UNKNOWN_SPEAKER: count/paulc: count/ Succeeded: s/Henris/Henri's/ Succeeded: s/or with appropriate /or with an appropriate header / Succeeded: s/thrad/thread/ Succeeded: s/is about keys/is about key key storage for cached keys/ Succeeded: s/connectivity:/connectivity. It was a recording of the discussion we were having./ Succeeded: s/key key/key/ Succeeded: s/yo uarguing/you arguing/ Succeeded: s/the app builder./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./ Succeeded: s/existing storage APIs./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./ Succeeded: s/abou twhat/about what/ Succeeded: s/failrly/fairly/ Succeeded: s/additinal works/additional work/ Succeeded: s/cognicent/cognizant/ Succeeded: s/applicaiton/application/ Succeeded: s/commnicate/communicate/ Succeeded: s/acocomodate/accomodate/ FAILED: s/UNKNOWN_SPEAKER: listed /paulc: listed/ FAILED: s/UNKNOWN_SPEAKER\: listed /paulc\: listed/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: +1.425.269.aaaa, davide, ddorwin, pladd, pal, adrianba, paulc, BobLund, joesteele, [Microsoft], +1.714.338.aabb Present: +1.425.269.aaaa davide ddorwin pladd pal adrianba paulc BobLund joesteele [Microsoft] +1.714.338.aabb Found Date: 04 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/04-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]