HTML Media Task Force Teleconference -- 13 Aug 2013

<trackbot> Date: 13 August 2013

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 13 August 2013

<paulc> Trackbot seems to be a little slow today.

<trackbot> Sorry, paulc, I don't understand 'Trackbot seems to be a little slow today.'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

and the link does not work

<glenn> zakim doesn't seem to be answering in IpCaller either

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 13 August 2013

<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 in http://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

UNKNOWN_SPEAKER: 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

august task force 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?

<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

s/UNKNOWN_SPEAKER: need/paulc: need/

trackbot-ng, end meeting

- DRAFT -

HTML Media Task Force Teleconference

13 Aug 2013

Attendees

Contents

new bugs

bug#22901

bug#22909

bug#22910

previously discussed bugs

bug#18515

bug#20944

heartbeat publication

Media Task Force August meeting schedule

august task force schedule

Summary of Action Items

Scribe.perl diagnostic output