{minutes} HTML WG media telecon 2013-08-13 - EME status and bugs discussion

http://www.w3.org/2013/08/13-html-media-minutes.html

Joe Steele
steele@adobe.com


HTML Media Task Force Teleconference

13 Aug 2013

Agenda

See also: IRC log

Attendees

Present
davide, glenn, ddorwin, paulc, markw_, joesteele, [Microsoft], adrianba, johnsim
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
new bugs
bug#22901
bug#22909
bug#22910
previously discussed bugs
bug#18515
bug#20944
heartbeat publication
Media Task Force August meeting schedule
Summary of Action Items
<trackbot> Date: 13 August 2013
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<scribe> scribe: joesteele
new bugs

bug#22901

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22901
paulc: at the top of the agenda to see if anything has been done
ddorwin: I think we should not be executing arbitrary code
paulc: glenn, your reply #6 needs to be corrected to point to the bug
glenn: it depends on 22909
... on your list for today
paulc: so you want to process the new bug and come back?
glenn: yes -- need that to address this one
bug#22909

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909
glenn: my proposal is to add appropriate language to the security consideration sections that points out issues with interpretation of code in initialization data
<paulc> Glenn's proposal is at: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909#c1
joesteele: re: bug#22901 -- I was wondering if the argument for this is the application of BD+ to DASH content, BD+ would require interpreted code I believe
paulc: assume folks need time to respond
glenn: proposal is just an outline - needs more discussion
... experts should fill this in
... would like to document these issues and wrap this up
ddorwin: proposal seems to be related to content and key security rather than content execution
... should not confuse DRM with client security
glenn: intent was to address security concerns for implementors and secondly users of the EME funcionality
paulc: why is your comment about client not covered by x.2 section
ddorwin: the other things like don't run initData are to protect the client, different kinds of security
... one is protecting the content provider, one is protecting the user
paulc: do we need an x.3?
ddorwin: two examples given are not inline with other security related bugs
... don't need to specify how to protect keys to the DRM providers
glenn: not an expert in this subject, just listed some of the language from WebCrypto similarly named section
... seemed potentially applicable
... I suggest David comment in the bug and we capture other security considerations here as well
ddorwin: ok
bug#22910

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910
<paulc> Glenn's proposal is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910#c1
glenn: proposal in comment #1 applies just like previous bugs comments
paulc: any comments? otherwise people need to review the proposal and comment
glenn: happy to take the lead on editing as people submit comments
... high level concern to whether adding two sections is a reaonable approach
adrianba: just a reminder we had a discussion with the Privacy Interest group about EME
... if there is a Privacy Consideration section being constructed should be communicated to them to ask for participation
<paulc> ACTION: paulc to inform Privacy IG who we spoke to in Feb about bug 22910 [recorded in http://www.w3.org/2013/08/13-html-media-minutes.html#action01]
<trackbot> Created ACTION-35 - Inform privacy ig who we spoke to in feb about bug 22910 [on Paul Cotton - due 2013-08-20].
adrianba: this was in the middle of February - Feb 17th
paulc: I will follow up on that
<paulc> ACTION-34?
<trackbot> ACTION-34 -- Glenn Adams to Draft language on potential privacy considerations for bug 20965 -- due 2013-08-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/34
paulc: Glenn - you had an action to draft privacy considerations - can we mark that as done?
?
<glenn> close ACTION-34
<trackbot> Closed ACTION-34.
paulc: point to this bug if it is not already there
previously discussed bugs

<glenn> ACTION-34: see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910
<trackbot> Notes added to ACTION-34 Draft language on potential privacy considerations for bug 20965.
bug#18515

<paulc> test
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c12
paulc: David this is your comment
ddorwin: comment is whether we should actually modify the readyState
joesteele: can't comment as I don't own a browser
glenn: changing the readyState seems more correct, but you are correct it is more work
adrianba: haven't looked in detail yet, but Jerry and I would be ok taking an action to review and add comments
<paulc> David's comment: Before we can work on proposed text, we need to decide whether we want to behave like certain readyStates, as in comment 7, or actually change the readyState, as in comment 8.
<paulc> ACTION: adrianba to review David comment 12 on bug 18515 and provide feedback [recorded in http://www.w3.org/2013/08/13-html-media-minutes.html#action02]
<trackbot> Created ACTION-36 - Review david comment 12 on bug 18515 and provide feedback [on Adrian Bateman - due 2013-08-20].
bug#20944

ACTION-32?
<trackbot> ACTION-32 -- Glenn Adams to Draft wiki page to register CDM key system names for bug 20944 -- due 2013-08-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/32
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
paulc: any progress?
glenn: yes -- pointing to the draft
<glenn> http://www.w3.org/html/wg/wiki/KeySystemRegistry
<paulc> see comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c22
glenn: just a draft - not endorsed yet
... see that Mark has already commented
<paulc> mark's comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c23
markw: I think we could do more than is proposed, especially when the DRM is supported by the operating system
... using public APIs for the OS, should be a specification somewhere saying how this is built using the public APIs
... so we don't end up with incompatible implementations
paulc: how would you modify?
markw: could add additional registration requirements
glenn: tried to make the reqs as minimum as possible, like to see the new reqs first
ddorwin: technical note - some key systems may be in front of the platform APIs in different ways -- needs to be accounted for
markw: I can take an action
... something to also consider is that if someone built a key system using APIs that are not public, can we encourage folks to use the public APIs
<paulc> ACTION: markw to update wiki provided for bug 20944 to cover the case where the DRM is supporting by the OS [recorded inhttp://www.w3.org/2013/08/13-html-media-minutes.html#action03]
<trackbot> Created ACTION-37 - Update wiki provided for bug 20944 to cover the case where the drm is supporting by the os [on Mark Watson - due 2013-08-20].
markw: to avoid the interop issue again
glenn: I did not use the term CDM in the draft - just key system
... I wanted to make th registrant the determiner as to whether the system is open or not open without oversight from the W3C
... like to get agreement on whether that is a good approach
... and whether we should make judgement calls on this issue
markw: it is something we would like to encourage browser to be able to access the functionality in the OS
... not sure there is anything that W3C can do to dictate this
... but could encourage the outcomes we are looking for
... there are capabilities that some browsers can access that others can not
<johnsim> +q
markw: but would like to avoid the interop issue
johnsim: question about this bug - when you say "open" - do you mean a published API?
... what about embedded environments (e.g. a TV) and there is no way to install a second browser, why would want to be discouraged?
paulc: you are asking - does that manufacturer have to register on the wiki?
johnsim: yes -- is every manufacturer supposed to register?
glenn: I called out the "openness" with some text in the bug
... if someone registered something as open it is up to them to decide the standards openness - must be prepared to defend that decision
johnsim: just trying to understand what you meant when you used the term
... from a programming perspective, thought we were talking about a published API
... other point is that all key systems are proprietary
glenn: but these are key systems - not DRM systems
... second part of the question - should implementers be required? I think not
<paulc> The wiki is covered by ACTION-32
<paulc> ACTION-32
<trackbot> ACTION-32 -- Glenn Adams to Draft wiki page to register CDM key system names for bug 20944 -- due 2013-08-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/32
glenn: have another action to write text about the registration being recommended
paulc: believe this action can be closed as well
close ACTION-32
<trackbot> Closed ACTION-32.
paulc: please add a comment pointing to the comment on the bug
<paulc> ACTION-33?
<trackbot> ACTION-33 -- Glenn Adams to Draft spec language for inclusions as note to address comment #15 of bug 20944 -- due 2013-08-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/33
paulc: is this still pending?
glenn: in the action item, I added a note about key systems being registered and a link to the registry
paulc: in action 33
... recommend you put that in the bug as a comment
glenn: will do
<paulc> Under 1.2.2 Key System add: "Note: It is recommended that Key Systems by registered at http://www.w3.org/html/wg/wiki/KeySystemRegistry."
<paulc> The above text proposed by Glenn will be copied to bug 20944 to resolve comment #15
<glenn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c24
close action-33
<trackbot> Closed action-33.
markw: I think that the open section of this came from the original proposal by Robert Callahan
... that was a much higher standard proposing implementation was opened so could be reimplemented
... in case of end-of-life for the key system
... to avoid losing the content
... within the non-open section, gave an example of a TV,
... I was more concerned about browsers that have OS access other browsers do not
... don't need separate key system registrations for key systems that cross multiple devices, platfors
johnsim: very helpful
adrianba: question for glenn
... recommended that key systems be registered, in RFC 2119 recommended are SHOULD - was that your intent
glenn: I used that phrase, because it appeared elsewhere
... a couple of lines above
... "It is recommended that key systems use simple lower case ascii strings"
adrianba: that language really is a SHOULD, 2119 is explicit that SHOULD means recommended
paulc: should do it unless you can give a reason not to
glenn: ok with changing to SHOULD
paulc: so key system just has to give a reason why
<paulc> See thread at: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0011.html
glenn: this issue of having a way to refer to specific key systems was something I considered, but this might come back in the future
... if we do something like the registration, we should have some explicit language that
... says we don't want multiple registrations of the same key system
paulc: question from Rob Callahan on the minutes thread - should we address?
glenn: he wished to mandate openness for all registrations - no closed registrations
... don't think that is a viable option but would like comments
<paulc> See thread at: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0011.html
<johnsim> +q
johnsim: the issue here goes back to the definition of openness we are exploring
... seems like it may only be acheivable depending on how you define opennesss
... if you require the internal functioning of the CDM to be published, that is overly intrusive
... like to know more about the actual requirements, what problem it solves
paulc: more compatibility with open source
johnsim: in the sense that someone could implement the CDM without working with the proprietary key system provider
... could provide a bogus DRM that would not enforce restrictions - not reliable
markw: that question is exactly what I asked Robert before, he gave a detailed answer with information about security and privacy reviews
... think it is reasonable to ask, it is up to the DRMs to determine whether this would compromise the DRM system
johnsim: will review what he said, but not clear precisely what you would document
heartbeat publication

<paulc> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0039.html
<adrianba> yes
paulc: need an EME editor to respond to this thread about arranging for a heartbeat publication
paulc: ok
<markw> there were other reasons Robert gave for why publication of CDM specifications would be useful even if CDMs built from that documentation wouldn't work with license servers from the original DRM vendor
Media Task Force August meeting schedule

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0023.html
paulc: mtg after this was TBD
<paulc> Who meets on Aug 20?
paulc: propose EME meets next week as MSE is almost LC
... does this make sense? any objections?
joesteele: +1
<markw> +1
paulc: hearing no objections -- I will respond and make it explicit
... have a week to get the last call out as there is a publication moratorium coming
... will meet again next Tuesday
... adjourned
Summary of Action Items

[NEW] ACTION: adrianba to review David comment 12 on bug 18515 and provide feedback [recorded in http://www.w3.org/2013/08/13-html-media-minutes.html#action02]
[NEW] ACTION: markw to update wiki provided for bug 20944 to cover the case where the DRM is supporting by the OS [recorded in http://www.w3.org/2013/08/13-html-media-minutes.html#action03]
[NEW] ACTION: paulc to inform Privacy IG who we spoke to in Feb about bug 22910 [recorded in http://www.w3.org/2013/08/13-html-media-minutes.html#action01]
 
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-08-13 16:07:40 $