See also: IRC log
<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
<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
<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
<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
<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.
<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].
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
<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
<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?
+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
s/UNKNOWN_SPEAKER: need/paulc: need/
trackbot-ng, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/excution/execution/ Succeeded: s/don;t/don't/ Succeeded: s/makr/mark/ Succeeded: s/your are/you are/ Succeeded: s/can;t/can't/ Succeeded: s/so key/some key/ Succeeded: s/an there/and there/ Succeeded: s/2219/2119/ Succeeded: s/.. say/... say/ Succeeded: s/doe we/do we/ Succeeded: s/reaonable/reasonable/ Succeeded: s/that as done/that as done?/ Succeeded: s/tehcnical/technical/ Succeeded: s/manfucturer/manufacturer/ Succeeded: s/that mfr/that manufacturer/ Succeeded: s/supposed to register/supposed to register?/ Succeeded: s/say we/says we/ Succeeded: s/without the proprietary/without working with the proprietary/ Succeeded: s/not enforce -/not enforce restrictions -/ FAILED: s/UNKNOWN_SPEAKER: need/paulc: need/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: +1.925.984.aaaa, davide, glenn, ddorwin, paulc, markw_, joesteele, [Microsoft], adrianba, johnsim Present: +1.925.984.aaaa davide glenn ddorwin paulc markw_ joesteele [Microsoft] adrianba johnsim Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0027.html Found Date: 13 Aug 2013 Guessing minutes URL: http://www.w3.org/2013/08/13-html-media-minutes.html People with action items: adrianba markw paulc[End of scribe.perl diagnostic output]