RE: {minutes} HTML WG media telecon 2013-04-02 - EME

Joe,

I was there listening too, though I kept silent. Zakim captured me. :)

Thanks
Bin

From: Joe Steele [mailto:steele@adobe.com]
Sent: Tuesday, April 02, 2013 9:16 AM
To: public-html-media@w3.org
Subject: {minutes} HTML WG media telecon 2013-04-02 - EME


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

________________________________
HTML Media Task Force Teleconference
02 Apr 2013

Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0000.html>

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

Attendees
Present
BobLund, MartinSoukup, adrianba, ddorwin, glenn, hsivonen, jdsmith, jernoble, joesteele, john, johnsim, markw, pal, paulc, wseltzer
Regrets
Chair
paulc
Scribe
joesteele
Contents

  *   Topics<http://www.w3.org/2013/04/02-html-media-minutes.html#agenda>
     *   Bug 19009<http://www.w3.org/2013/04/02-html-media-minutes.html#item01>
     *   Bug 21203<http://www.w3.org/2013/04/02-html-media-minutes.html#item02>
     *   Bug 20991<http://www.w3.org/2013/04/02-html-media-minutes.html#item03>
     *   Introducing remaining bugs<http://www.w3.org/2013/04/02-html-media-minutes.html#item04>
     *   F2F<http://www.w3.org/2013/04/02-html-media-minutes.html#item05>
  *   Summary of Action Items<http://www.w3.org/2013/04/02-html-media-minutes.html#ActionSummary>

________________________________
<trackbot> Date: 02 April 2013
<paulc> Good morning
<scribe> scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0000.html
Bug 19009
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009
<paulc> Web interface: http://irc.w3.org/
<paulc> Bug 19009: Bug 19009: A MediaKeys should belong to a single HTMLMediaElement
paulc: talking about bug 19009
jernoble: this bug resulted from a discussion with our JavaScript manager
... he was incredulous that a single DOM object could belong to multiple DOM objects
... would change it to a diamond instead of a tree
... the CDM implementation will have to live in the media object itself in our implementation
... but when single media keys object can belong to multiple media objects this will be hairy
... that is the basic problem
paulc: do you want to respond David?
adrianba: my comments are in the bug, don't see this as an ownership question
... don't have strong feelings about this bug
... can see where this would be useful - if you wanted a presentation where you see a screen and a presenter and use the same keys for protection
... or a sign language interpretation of the presentation
... using the same keys
... we did not have a problem with allowing sharing, but we did not necessarily suppor tit
... noticed that Jer talked about Media Controller solution we could talk about that
jernoble: probably not exactly what people are going to want to use this for, any other way to implement this?
... can you just add the keys to both media elements so they are there when queried?
markw: don't think we can just add the keys as you get different challenges and need different responses
... question I had was - media keys can have a seperate existence from media elements as they can get message prior to media element existing
glenn: my question was - is it just separating the underlying state from the DOM instance?
<Zakim> adrianba, you wanted to talk about standalone MediaKeys
adrianba: comment on point about standalone media keys objects - possible for media keys to be standalone, but probably that some implementations will need the media engine to tie back to it
... don't think that we need to change the API surface, but key acquisition messages might not fire until when you tie the media keys to a media element
... one question might be -- is there a use case for the standalone media keys? may be some related to secure key release
... have not investigated this much yet
markw: if that is the case, we should be clear about that in the spec (tying together)
... otherwise folks will not support it
jernoble: saying the same thing as adrian - current way that we approach this won't fire the messages until the media keys are added to the media element
... don't have access to the internal bits of the CDM
... if we want to make this explicit in the spec I am ok with that
paulc: David, do you have enough information?
ddorwin: sounds like people want to add to the spec that media keys must be added to the element before message are fired.
... mot sure whether they can then be connected to multiple media elements
... little concerned that apps would try to share media keys when the implementations may not support it
jernoble: suggest that if this is a use case (sharing) making an explicit API that can be queried would be preferable as opposed to it being a side effect
paulc: then app would know it is supported?
jernoble: exactly
<adrianba> you might not know until you try
paulc: plausible design? any comment or objections?
ddorwin: exceptions is generally the feature detection capability
markw: do we have this as a requirement?
... we could just not allow it
paulc: Adrian mentioned some use cases that might require it
+q
adrianba: I described a couple of use cases, trying to avoid this being hard in the future
paulc: forbidding it and then allowing it later is possible
adrianba: that might be fine as long as we don't modify the API to make it harder later
... especially since we still have open issue of using existing keys
... somewhat related
<ddorwin> If we define an exception for setKeys() now, we can allow UAs to not throw it later. Also, we could note in the exception text that it is likely that UAs will not support this and will throw the exception.
I am echoing Adrians comments. I think the issue of existing keys is similar and would like to avoid the overhead of requesting the same key multiple times
<paulc> Bug 21203: EME leaks information cross-origin https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203
paulc: moving on to next bug
Bug 21203
adrianba: general principle that web platform should not be able to read information from a different origin within firm indication that that origin is sharing the content
... example of image sharing image data from another page
... script cannot access without additional permissions
... prevents situations where page can embed resource from your social network and get access using your logged in context
... e.g. stealing an image
... when we provide init data from the media file might be from a different origin
... bug asked that we explicitly document what information is shared across origins
... call out if a problem
... needkey could provide something the app wouldn't normally have access to
paulc: looking for explicit ask for text in this bug
ddorwin: original report has suggestions
<paulc> See comment 6: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203#c6
paulc: any objections to these proposed changes?
adrianba: do we believe that exposing init data cross origin is a problem?
... if so - then something like Henris proposal is a good solution
markw: point I made in the bug is that this is analogous to text track cues
... could contain arbitrary information
... similar problem
... Henri point out text tracks must adhere to CORS
... don't have a problem with that
paulc: any other comments?
adrianba: if we do add something like this, must scope to where the media element is doing the network request
... so if using MSE that is out of scope
... already need to do CORS
... once data is available to app is should already be considered same origin
paulc: is this different to what Henri proposed?
markw: don't think so for EME, raises questions for MSE
... I will open that bug
paulc: moving on?
Bug 20991
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991
ddorwin: started as reference to something that doesn't exist in algorithm
... now how do we report errors during loading of the CDM
... synchronous or asynchronous behaviors
... what do we want to say about a partially initialized media keys
adrianba: interesting timing, we were about to file the same bug last week after thinking about this.
... mark outlined this in his comments for the bug
... when you create an instance of the media keys you can start asynchronously initializing
... not until you need to fire a needkeys that the presence or absence matters to the app
... could change the API to allow for a pending state on the media keys objects, or an error saying "could not initialize"
... in the end probably not that much different to the app
... chose not to raise as a bug
<markw> MSE bug mentioned above: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
adrianba: considered the privacy issue raised in the intro - related to comments Henri made
... CDM will do some kind of initialization, at what point could the UA prompt the user to accept the initialization? does the API support a way to do this without blocking the UI?
... need to provide a way to initialize asynchronously
paulc: are you suggesting this is not actually a problem since you did not file?
adrianba: yes
ddorwin: original bug still exists in the spec -- text is incorrect
... error reporting text should be change to something else
<adrianba> +1 to the change to tidy up the language is needed anyway
ddorwin: this is a downside of Adrians proposal, hard to word this text
... other than that I am fine
paulc: any other comments?
Introducing remaining bugs
<paulc> Bug 16617: Consider more granular error reporting https://www.w3.org/Bugs/Public/show_bug.cgi?id=16617
<markw> Just to confirm (21536), we will tidy up the text, but there will be no new MediaKeys state - errors are reported asynchronously on the MediaKeySession
ddorwin: all related to error reporting
<paulc> Bug 16737: Should MEDIA_KEYERR_CLIENT be two separate errors? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16737
ddorwin: talking about the client err and what that means
<paulc> Bug 16857: MEDIA_ERR_ENCRYPTED should exclude decrypt failure https://www.w3.org/Bugs/Public/show_bug.cgi?id=16857
ddorwin: then detection of decrypt errors
... please take a look before next time especially MEDIA_KEYERR_CLIENT
... like to discuss how detailed we want to get
adrianba: this group is assigned to me for a long time, as we have been experimenting, thoughs about error reporting continue to change
... don't have a complete proposal yet
... but will throw this out --
... we think folks will want to try to avoid an error situation preventing playback
... may be that instead of firing a fatal error, will tell app that it can't guarantee protection and allow fallback to lower quality media
... second issue is that in PlayReady implementation lots of ways things can generate errors
... we have been wrestling with how granular errors in the spec should be or rely on system specific errors
... when people try to debug, more specific is helpful, but might not be able to describe all the errors in an implementation independent way
... might not be useful for interop
... could add more errors and not get any closer
<ddorwin> We should define error codes that the production application should handle.
ddorwin: want detailed errors for debugging, e.g. configuration errors
... general issue with no feature detection, how does application provide that
... still going to be some interruption if fallback is required
adrianba: emphasize we want detailed error codes even in production apps, common to want diagnostic codes on the server
... allow finding common issues and errors, should show up in the API somewhere
markw: agreed with that
... often the license to the CDM will include the policy/rules about when media can be played, e.g. output protection
... if app cannot there are various callbacks. Need to distinguish between this case (which is normal) and things which are actually problems (bad key, bad file)
paulc: these are all assigned to you Adrian and you are continuing to work on them, any ETA?
adrianba: if folks have specific proposals that would be welcome
<paulc> F2F meeting agenda wiki location: http://www.w3.org/wiki/HTML/wg/2013-04-Agenda#Potential_Topics
F2F
paulc: sent email about whether we should have time on the agenda
... need to have critical mass
... do we want to request an agenda slot? some people have indicated they would like to attend any sessions like this
... TPAC sessions seemed to push us along quite a bit
<glenn> glenn: +1
adrianba: assuming we have enough people think its a good idea, TPAC was effective
... for MSE we are down to last few issues for v1 spec. Would be useful to set resolving them as a goal.
... for EME we were able to identify issues we could make most progress on
... I will try to attend and make progress
ddorwin: we should figure out what we want to discuss
... technical stuff might not be interesting for the whole group
... any general issues we could talk about wwould be good
john: do we have a sense of how many are attending?
s/how may/how many/
<paulc> Attendance survey: https://www.w3.org/2002/09/wbs/40318/html-april-2013/results
<pal> in addition to the WG plenary, did you have in mind MSE- and EME-specific breakout sessions?
<markw> I will be there, but may be in WebCrypto some of the time
paulc: glenn, joesteele, markvickers, johnsim, acolwell, ddorwin, boblund
adrianba: I will register
<pal> I am considering attending
pal: in additional to the working group sessions - any other breakouts?
paulc: might not have a breakout room
... can follow up on that, but assume that we only have a single meeting room
pal: can see value in having a whiteboard
<pal> thank you
paulc: will follow up on this
... sounds like we have concensus that something would be useful - 90 min an appropriate target?
... could divide topics into general interest and more detailed
... heard the concenr that we should have an MSE session as well will bring up next week
... done for today!
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.137 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-04-02 16:09:30 $
________________________________
Joe Steele
steele@adobe.com<mailto:steele@adobe.com>