HTML Media Task Force Teleconference -- 18 Jun 2013

<trackbot> Date: 18 June 2013

<scribe> scribe: joesteele

Previous Minutes

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

Review ACTION items

adrianba: skip issue 1
... dive into action 19

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

<trackbot> http://www.w3.org/html/wg/media/track/actions/19

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854

adrianba: this is about bug#21854

<adrianba> https://www.w3.org/Bugs/Public/attachment.cgi?id=1374

adrianba: this morning copied in the proposal -- can describe
... 2nd link is a link to an attachment with the state transition diagram
... for this proposal
... this bug is about the lifetime of the session
... we propose that there will be a state attribute associated with the session
... when session is first created starts in the "created" state
... can move into the "error" state
... example is CDM initialization
... or could move directly into the "ready" state
... goal is to indicate that should an encrypted block be encountered
... the CDM does not expect to wait for more key information
... typical pattern is that from "created" you get a key msg to move into "pending" state
... get a key msg event - then transition to the "ready" state
... possible to move from "ready" to "pending" by firing a key msg
... some implementations may want to fire additional key msgs later (e.g. key rotation)
... to continue the conversation

markw: looks good -- same as F2F discussion
... like to see a "closed" state

adrianba: is there a separate bug on "closed"?

markw: bug for additional material on key release

ddorwin: think I own that

<ddorwin1> close bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750

markw: does this address what caused the key to be destroyed?

adrianba: wanted to ask for feedback on this bug - does it really address the lifetime issue?
... not sure what the behavior for "closed" should be
... key release scenario is a slightly different flow
... still need to do communication to the license server
... but even in the absence of key release information were not quite sure how to manage close
... calling close on a session, finding the keys to map to that session, but may have been provided by a paralell session
... were not sure how to deal with this

<adrianba> joesteele: how is this exposed to the app and what actions might an app take to seeing a step

adrianba: exposed in two ways
... attribute on the session -- like an enum of states
... two additions this proposal makes:
... adding the ready state - distinct between acquiring keys and not acquiring keys
... possible for apps to show a message to the user while acquiring keys

<adrianba> joesteele: if i'm in pending, is there a way for the app to say i'm never going to respond

<adrianba> ... i think we said before the only way for the app to not respond is to close the session

adrianba: the signal state that you are in implies that "unless you respond you may not be able to continue playback"
... till we figure out what close means hard to be sure what the cost is

ddorwin: you mentioned key ready event, when heartbeat is being used key ready will be fired frequently
... is that ok?
... are there other interesting use cases for the key ready event?

adrianba: think is is the case that you would be moving back and forth between pending and ready
... you should expect playback to stall if no response
... likely that the app will show a msg but not required
... should know whether license service is dealing with heartbeat
... could use that information to determine that pending heartbeat made playback stop
... might not want to show a msg every time, but if taking a long time might be approproate to show

ddorwin: if different DRMs use heartbeat, app might have to behave differently
... was not the case before

adrianba: potentially

markw: re: close thing -- seems clear there will be keys that are not removed when the session is closed
... isn't it up to the CDM when the session is closed?
... might not be removed if in use by another session or the system

adrianba: that might be sufficient
... will anyone take action on close?
... might be better not to add close

markw: might make sense to have keys removed that are not in use by any sessions
... secure proof of key release might require this

<adrianba> joesteele: i'm concerned - i would not want a situation where anyone but the CDM is in control of releasing the CDMs keys

<adrianba> ... that could mess up our system

<adrianba> ... i thought i heard an implication that the browser or app could release keys

markw: that is what I said

adrianba: I heard that close would not require that but might allow it
... is there a CDM or CDM scenario where the app might have more knowledge than the CDM whether a key would be used again?
... so app could signal to the CDM that those keys could be released
... does that or something like that ever happen?
... might want close in that case for the future

johnsim: agree with joe that the CDMs should be in control, central to how the key systems are designed
... rules about when the presentation ends that determine when kesy can be released
... sounds like the behavior should be not key system specific

<adrianba> i think the CDM _is_ in control - the question is whether the app might have knowledge to add information to help the CDM decide?

johnsim: simplest way to accomplish that is to allow the CDM to be in control according to its rules for key management
... apps can rely on that taking places under the hood
... concerned about apps doing anything other than "this session has ended"
... this is a "presentation stop" event -- though that is what close should accomplish

<Zakim> ddorwin, you wanted to ask about multiple sessions

johnsim: what happens should be CDM specific

ddorwin: off-topic but related
... does anyone have concrete use cases for multiple sessions?

adrianba: yes -- the use case we have is multiple tracks being fed in with MSE into same media source
... each has init data which fired
... might have a different key for each tracks (one from many audio tracks)
... might get a needkey fired from each track
... storing those separately so might play in different combinations

<adrianba> joesteele: multiple streams in the same browser window

<adrianba> ... have a family of channels - not playing yet but queueing up ready for switching to that channel

<adrianba> ... another is the different videos in the same window

<adrianba> ... for example ad coming from different system alongside rather than embedded

joesteele: different media elements in both those cases

ddorwin: the question was about supporting multiple sessions with the same decoder
... we allow that currently, but we may be allowing more than one is needed

markw: we have a use case where the user knows the content has finished playing and keys are destroyed
... also need to be told when that time is (app)
... so that keys are released when they are supposed to be at the end of the session

johnsimm: once you acknowledge multiple sessions per CDM has use
... there are situations where an init data is acquired in one session to acquire a key from another session
... have discussed where you have a key ready need because you don't need a key msg in this case
... would be useful to discuss the additional scenarios between sessions for key release and make sure they are supported by the spec

<adrianba> ACTION-10?

<trackbot> ACTION-10 -- Adrian Bateman to discuss bug 21855 with johnsim -- due 2013-06-11 -- PENDINGREVIEW

<trackbot> http://www.w3.org/html/wg/media/track/actions/10

ACTION-10?

<trackbot> ACTION-10 -- Adrian Bateman to discuss bug 21855 with johnsim -- due 2013-06-11 -- PENDINGREVIEW

<trackbot> http://www.w3.org/html/wg/media/track/actions/10

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855

bug#21855

adrianba: this bug is about avoiding network traffic and duplicate sessions for the same key
... as part of the state transition proposal we are saying it is allowable for there to be duplicate sessions
... and allowable for CDMs to detect that there are other sessions and CDM can choose to keep that session in the created state
... and fire the corresponding events in the second session
... this is why we allow going directly from created to ready state
... example of audio and video tracks which share the same key
... create session for each key, CDM can decide to wait for first session before moving to the 2nd session

<markw> Looks good to me

joesteele: that works for me

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

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21155

adrianba: bug#21155

markw: this is finished

<adrianba> close action-12

<trackbot> Closed ACTION-12 Add text to Editor's Draft for bug 21155.

ACTION-13?

<trackbot> ACTION-13 -- Adrian Bateman to review comments and add text to editor's draft for bug 19009 -- due 2013-06-11 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/13

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009

adrianba: this is on me bug#19009
... have not done this one yet -- need one more week

<adrianba> action-13 due in 1 week

<trackbot> Set ACTION-13 Review comments and add text to editor's draft for bug 19009 due date to 1 week.

ACTION-17?

<trackbot> ACTION-17 -- Adrian Bateman to provide feedback on keySystem string bugs 16540 and 20798 -- due 2013-05-28 -- PENDINGREVIEW

<trackbot> http://www.w3.org/html/wg/media/track/actions/17

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16540

adrianba: bug#16540 and 20798

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20798

adrianba: about the keySystem string
... added a comment to the action agreeing with the most recent comments
... suggestion is that we remove the part of the spec that suggest prefix-matching of the keySystem string for versioning
... add a non-normative note about CDMs choosing a structure for their string
... second bug is about string-matching -- should be case-sensitive
... add a non-normative note saying lower case because we can always add later
... happy to close this now if no objections

<ddorwin1> +1

<adrianba> close ACTION-17

<trackbot> Closed ACTION-17 Provide feedback on keySystem string bugs 16540 and 20798.

<adrianba> ACTION: adrianba to implement bugs 16540 and 20798 per the suggestion in ACTION-17 [recorded in http://www.w3.org/2013/06/18-html-media-minutes.html#action01]

<trackbot> Created ACTION-20 - Implement bugs 16540 and 20798 per the suggestion in ACTION-17 [on Adrian Bateman - due 2013-06-25].

adrianba: that was all the outstanding actions -- any suggestions for bugs to discuss?

CDM storage question

<adrianba> joesteele: wanted to sound people out on whether CDMs should be allowed to store data

ddorwin: probably can't prevent it, but difficult to implement in some cases

markw: in practice CDMs do require it, open question as to whether browsers can provide this
... as far as understood not a requirement for arbitrary storage
... should be secure storage (anti-rollback, etc.)
... might not be sufficient to have just file system access
... but only a small amount of secure storage would be needed

johnsim: 2 things to consider here
... large world of DRM system being used for media consumption
... one of our goals was to see that modest effrot could migrate existing solutions to this specification
... if this would prevent it or make it difficult, we would do a disservice
... 2nd consideration is about retaining keys in the CDM
... important to distinguish the use by the user agent of a key from the possibility of the key being persisted by the CDM outside of the user agents
... the CDM is being told there is no longer a need to persist this key in memory to decode content, versus you are not to persist this key in any way
... doing the latter would be a problem for some use cases
... example is key storage on a hard drive versus the key in memory being used
... so I don't have to retrieve again
... these are reflective of how keys are used today
... want theses scenarios to all be supported, including the non-browser use cases

markw: with respect to storage, the apis that CDMs use to store are mediated by the browser that will address some of the issues that users are raising about untrusted CDMs

ddorwin: for this to happen, either the browser and the CDM have to be tightly coupled or it has to provide the APIs to do the storage
... in the latter it is not a black box scenario

<adrianba> joesteele: not sure i understand why providing file system access to CDM is difficult

ddorwin: if CDM can have a separate storage browser has no way to provide security

joesteele: is the concern the content or the location?

ddorwin: the location could be cleared by the browser, why not have the application store in this case?

adrianba: if the spec needs to say something -- need to file a bug?

joesteele: we have a bug should I just add to it?

adrianba: yes we could get Paul to add this to the next agenda
... please take a few minutes to review the proposal I added at the top of the call
... we can move those bugs forward
... meeting adjourned

s/johnsimm: simplest/johnsim: simplest/

s/johnsimm: what/johnsim: what/

- DRAFT -

HTML Media Task Force Teleconference

18 Jun 2013

Attendees

Contents

Previous Minutes

Review ACTION items

CDM storage question

Summary of Action Items

Scribe.perl diagnostic output