See also: IRC log
discussing the proposal from Microsoft, Google and Netflix
Mark: please walk us through the proposal
-- wait until I am in front of my computer
clark: Adrian -- how about you
having some feedback
clark: have been anticipating
this proposal -- submitted to HTML group and our group for our
... any comments on this proposal?
ph: since this was submitted to HTML group -- this is intended for HTML5
kilroy: yes to make it available
to HTML -- but not part of the monolithic document
... could be a parallel document
MarkW: could be published as a
separate spec -- kind of an extension
... what do we do with features that don't make the HTML5 cut?
... not resolved where this would go yet
<Clarke> Actual proposal: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
ph: not clear when HTML5 would repsond -- just wanted to double check on the planning
<inserted> (HTML issue-179)
MarkW: this was meant to respond to this issue: (what issue#?)
<ph> markw: was submitted on this specific issue since content protection was mentioned in this issue - but expect longer discussion, not
glenn: this is an orthogonal proposal not related to 179 except for parameter expression
MarkW: should I give an overview?
based in part on the Netflix proposal -- incorporates work others were also doing -- not complete
hopefully there will be some discussion
-- giving an overview of the doc now
MarkW: application is in charge
of passing the authentication to the backend
... user agent is just passing the data through
... clearKey is basic encryption
... not part of the proposal how the CDM gets embedded or whether it is software or hardware
... could also include coding and/or rendering of the media
... represents the secure media pipeline on the device
MarkW: not returning the
decrypted frame to the browser
... the rest is the details of key exchange
-- discussion of the key exchange
MarkW: the keymessage is sent to
the license server and received back to hand to the CDM
... may be multiple key exchanges
... also an extension to the canPlayType()
clarke: concern I have seen raised -- belief that the frames would be available unencrypted
MarkW: the diagram is a little
misleading here -- looks like it comes back to the browser but
is dependent on the CDM
... you can imagine a system where it would come back but the frames would not be well protected then
... a CDM like that would be useful for some content -- not all
... some content would not fall into this category - where decoder is tied closer to the CDM
... decrypted frames do not come back to the user agent there
... that is an unsolved problem right now
... if decrypted frames are not coming back -- overlay would be the simplest implementation
... would prefer if frames could be properly composited
... would need for user agent to be able to talk to the graphics hardware to do the compositing properly
... can imagine this never happening for strongly protected content
Jason: is this akin to the hardware accellerated video tag?
mav: some questions about
comparisons with the previous proposal
... previous proposal has been removed -- that is not good
... would like to see it put back
MarkW: should be able to see it in the history
mav: should have a label to make
it more accessible
... the keys did not pass thru JS in the old proposal, now they do?
MarkW: in both proposals the
messages pass through JS
... perhaps the name is wrong - is not necessarily a "key"
... for clearKey the message is actually a key
mav: would suggest that this should be further clarified
<adrianba> here is the old proposal: http://www.w3.org/2011/webtv/wiki/index.php?title=MPTF/Netflix_Content_Protection&oldid=1870
mav: description of the hardware support is brought in would be good with diagrams
joesteele says +1
jasonlewis: is the clearkey meant to be like HLS?
MarkW: is it akin to that in that
the message is just the key
... how key is applied depends on the container format
... different from HLS in that the user agent is sending the request in HLS - with clearKey it is the JS application sending the request
joesteele: sending control messages to the CDM?
MarkW: not in this proposal
except for key release in section 4
... the main reason for not having generic messages, it does not describe how the system works
... should be possible to have a JS app which just knows the message passing bit
... some preference has been expressed for exposing more features
... key release facilitates managing the key life cycle
... you may need to know how may keys are extant, or charge for the content on a rental basis
... could be managed from the JS app layer, but could be gamed by modifying the JS
... key release mechanism allows for a secure mechanism for managing the keys
... this is outside the purview of the HTML media element
joesteele: what about birth of life?
MarkW: could call the
generateKeyReq early on to help this
... it is assumed that the CDM needs some data about the media to be initialized
... possible you could do this
joesteele: will send these notes to the HTML list
Clarke: procedural note -- how should we best handle comments like this?
MarkW: since it was proposed to that group -- send comments to that group
Clarke: : maybe we could come to agreement in this group and submit one set of comments
MarkW: this should get included in the formal system
Clarke: encourage people to participate in the HTML WG as well on this
glenn: note that the proposal was
in response to ISSUE-179 -- not clear that it is proposed as an
extension to HTML5
... not clear we are chartered to propose specs yet
... how is this work being done?
MarkW: proposal is submitted to the HTML WG
Clarke: we are chartered to provide comments
<adrianba> the html wg made a call for html.next proposals - this was discussed at TPAC too
<adrianba> right now we've simply submitted an informal proposal document for discussion
glenn: not following procedure currently - who did this come from?
<adrianba> i hope that this will be adopted as an editor's draft in the group
MarkW: came in as a proposal from Google
glenn: not clear as a reader of the proposal
MarkW: some behind the scenes coordination going on
glenn: does this IG need to bless this proposal or provide input?
mav: do not need to bless but should provide input
kaz: thought we had our own
ISSUE-40 for this?
... should this IG continue discussion on ISSUE-40 and bring the conclusion to HTML WG?
... or should we discuss ISSUE-179 and bring that discussion to HTML WG?
Clarke: should address, likely to
be other issues we do not directly raise with HTML WG
... we have an opportunity to provide feedback
kaz: clarifying our scope would be fine
glenn: I am possibly ok with that
-- a little concerned still with connection between ISSUE-179
and this proposal
... some confusion in the WG still
... led people to believe that 179 is concerned with content protection and it is not
kaz: if you have a concern with 179 it should be raised in the HTML WG -- we should focus on 40
glenn: expected actions from us on this proposal?
Clarke: we hope so - asked Mark to present to this group
<adrianba> HTML WG chairs review of ISSUE-179 is here: http://lists.w3.org/Archives/Public/public-html/2012Feb/0298.html
jasonlewis: re: the issue in the draft spec -- how do we add our own issues to this draft?
clarke: raise issues on the wiki
- which may not match those in the proposal
... if authors then want to bring back to the proposal -- that would be great
clarke: any other comments?
... closing the call
... add any issues to the wiki
... thanks everyone