See also: IRC log
<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
<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
jernobie: 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
jernobie: 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
jernobie: 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
jernobie: 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?
jernobie: 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
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?
<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?
<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
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!
rrsagent: draft minutes
rrsagent: draft minutes
rrsagent: draft minutes
rrsagent: draft minutes
rrsagent: draft minutes
rrsagent: draft minutes
rrsagent: draft minutes
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wa sincredualuous/was incredulous/ Succeeded: s/medial/media/ Succeeded: s/just allow/just not allow/ Succeeded: s/commnets/comments/ Succeeded: s/paulc;/paulc:/ Succeeded: s/whic /which / Succeeded: s/no be/not be/ Succeeded: s/may/many/ FAILED: s/how may/how many/ Succeeded: s/Bug19009/Bug 19009/ Succeeded: s/seperating/separating/ Succeeded: s/jernobie/jernoble/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: glenn, joesteele, pal, markw, Bin, +1.613.287.aaaa, ddorwin, MartinSoukup, paulc, johnsim, jernoble, jdsmith, [Microsoft], adrianba, BobLund Present: BobLund MartinSoukup adrianba ddorwin glenn hsivonen jdsmith jernoble joesteele john johnsim markw pal paulc wseltzer Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0000.html Found Date: 02 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/02-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]