HTML Media Task Force Teleconference

16 Apr 2015

See also: IRC log


Paul_Cotton, Glenn_Eguchi, Cory_Heslip, Rustam_Khashimkhodjaev, Daniel_Davis, Joe_Steele, Mark_Vickers, Jeremy_LaCivita, Sahil, Mark_Watson, Matthew, Wolenetz, David_Dorwin, Chris_Wilson, Jerry_Smith


<paulc_> Last report on CR testing status: http://lists.w3.org/Archives/Public/public-html-media/2014Dec/0012.html

<paulc_> MikeSmith: Are you here?

<MikeSmith> where is here?

<MikeSmith> there's no zakim as far as I can see

<paulc_> See https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#IRC_and_Teleconference_facilities

<MikeSmith> how do I phone in

<MikeSmith> ok

<paulc_> Call +1.617.761.6200, conference 63342 ("media")

<MikeSmith> "the conference is restricted at this time"

<ddavis> scribenick: ddavis

<MikeSmith> maybe somebody can Skype me in

<MikeSmith> or better, https://appear.in/sideshowbarker

<paulc_> We are in a large room with good audio.

<paulc_> Too bad you cannot join. Maybe the call time was only to 5pm PT?

<MikeSmith> dunno

Mike, trying appear.in - can you see/hear me?

<scribe> scribe: Daniel

[MSE] Plan for getting MSE out of CR

<paulc_> CR testing status from Jan 2015: http://lists.w3.org/Archives/Public/public-html-media/2014Dec/0012.html

paulc_: We had a discussion at TPAC last year about MSE testing.
... What happened is that Cyril took an action item on CR testing to add to the existing test suite.

<joesteele> s/godo/good/

paulc_: The above link is his report from December. Since then he hasn't been able to make further progress.

<joesteele> s/conencus/consensus/

paulc_: So we've made a small amount of progress since Halloween.

<joesteele> s/does not occur i the/does not occur in the/

paulc_: The first topic is how to break out of this conundrum. We only have two editors.

<joesteele> s/of W3C spec for/of W3C specs for/

paulc_: We have bugs to deal with, we have a dependency on streams and we also need to figure out testing for MSE.
... I've been talking to the W3C team to say we don't have the resources from Members.
... Do you have any thing to update?

MikeSmith, can you hear us?

<MikeSmith> i csn hear you

MikeSmith, we can't hear you.

<joesteele> s/\@\@1:/cwilso:/

I'll reload the page.

<MikeSmith> Hi

<joesteele> s/Mixed COntent UX/Mixed Content UX/

<MikeSmith> theapp has me muted locally

<MikeSmith> hoedy

MikeSmith, can't hear you again.

<joesteele> s/reocmmendations/recommendations/

MikeSmith, shall we try Skype instead?

<joesteele> s/don;t/don't/

paulc_: Have you had any chance to look at MSE testing?

MikeSmith: No, because that's a key part and requires a significant amount of time. I'm hoping I personally won't have to.

<joesteele> s/concensus, if you insist upno/consensus, if you insist upon/

paulc_: I'm sceptical about whether I'll have people here to help.

MikeSmith: We need to plan for success!

paulc_: I'd like to find out who's interested in moving this forward.

MattWolenetz: I'm interested in pushing this forward.

paulc_: Matt is one of the new editors from Google replacing Aaron.
... He's interested in helping.

MikeSmith, can you hear us?

<MikeSmith> No, but following along on IRC

<MikeSmith> So please just keep going fire now

paulc_: It's hard for a single vendor to do this so I was hoping we could integrate e.g. with Microsoft to get new tests added to increase coverage.

paulc Is that something that you (Jerry) have time to work on?

<joesteele> s/and want a sanity/and we want a sanity/

<joesteele> s/assuem/assume/

Jerry: Not had the time in the past but it's a priority, although a challenge.

<joesteele> s/usuauly/usually/

paulc_: Anyone else willing to help with this?
... If we're going to get this done, the people in this room (or your companies) have to help.

joesteele: I can ask internally but I can't promise - we're going to implement a player.

paulc: We can get a small team together and have an ad-hoc meeting.
... I don't think it's worthwhile convening a large group.

<joesteele> s/mentioend/mentioned/

paulc: Maybe Jerry, Adobe, Mike, to figure out what the next steps are
... then go back to the Task Force to see where we can go from there.

MikeSmith: I want to explain the work that needs to be done.
... We have our test suite and a process for getting tests into that suite through submitting PRs.

MikeSmith, you've dropped out again - we can't hear you.

MikeSmith, can you hear us?

<MikeSmith> hang on

MikeSmith: Along with submitting PRs, we need someone to review those tests.
... Those people need to be familiar enough with the spec.
... For the actual writing of the tests, one possibility is to contract with an external test-writing company.
... We've done that for some tests in the past.
... The quality level was good, there in the test suite (for non-MSE tests).
... If that's the approach we take, we have to speak to the Google people to get their feedback.
... That costs money of course.
... The next part is we still need someone to review.
... It's possible to outsource that but I think we should have someone committed to do the review.
... That's at least as much work because someone has to evaluate the tests.
... I wanted to put on the table the option of paying for the remaining tests to be done.
... Some have already been done - they're done.
... The work that needs to be done is analysing the current coverage.

paulc_: Did someone do that already?

MattWolenetz: Cyril had already done that.
... Since then, internally we've added to those tests since last summer.
... The hope was that while Google was contributing those tests, we could get some help from other browser implementers.

MikeSmith: We know that Mozilla is trying to implement this.
... Seems like they're doing a good job but I've heard that it's hard for them to do anything other than Netflix and YouTube support.
... Part of the reason for having these tests is so that other implementers can have tests to work against.
... The purpose of the tests is not just to get through our exit criteria, they're to make sure we have interoperability.
... The level of commitment we have to that is the level of commitment we have to interoperability.

paulc_: We don't regularly see Mozilla here at all.
... To fix that, should I go to David Baron?

MikeSmith: Yes, or Chris Pearce.
... He's busy implementing it.
... He may be too busy to come back to the WG.

joesteele: The time difference is a problem too.

paulc_: We can fix that and arrange an ad-hoc meeting.

<MarkVickers> Mike: Is the Netflix issue that the only MSE sites available to test against are youtube & netflix or that there are many MSE sites, but only youtube & netflix work with their code?

paulc_: These issues are important so if we have to adjust our meeting times then maybe that's what we need to do.

MikeSmith: The people who feel the most pain at the moment are Mozilla and they can help us the most right now.
... I can help with reaching out to the them.

paulc: Do they're problems link to the need for sample files in the test suite?

MikeSmith: I don't know.

joesteele: I've heard that.

MikeSmith: To answer MarkVickers, the latter - they could only get their implementation to work with Netflix and YouTube.
... but this is just hearsay.

paulc: So we should ask Chris if they have a test that works here but doesn't work there and get that into the test suite.

MikeSmith: I want to help with the spec because I think it's important and underutilized.
... I'm also being pushed to get this done.
... I'd be happy to work with Matthew and we all know each other.

paulc: So let's get the coverage work that Cyril did, reach out to Mozilla and find out the problems they're having.
... I'll try to be the person that causes us to move forward so that a month from now we should have some progress to report back.
... I'll talk to Matt and Jerry and we'll figure out our go-forward plan.

MikeSmith: Good, please keep me in the loop.

paulc: Meeting adjourned. See you tomorrow at 9am.
... Please get here just before 9am so we can start on time.

Bug 27269 about partitioning identifiers and data by top-level *and* EME-using origin

<joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269

Bug 26332 Secure origin requirement.

<markw> https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/edit?usp=sharing

<joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

<joesteele> markw: this is what the spec says today

<joesteele> ... if you are on secure origin do this -- if not -- big gap

<joesteele> ... proposal is cut and paste largely from the privileged context document

<joesteele> ... if you are not on a secure origin, the media key system should reject access

<paulc> Where did the text come from?

<markw> Proposed text for checking secure origin is taken from https://w3c.github.io/webappsec/specs/powerfulfeatures/#new

<paulc> Incumbent settings object: http://www.w3.org/TR/html5/webappapis.html#incumbent-settings-object

<joesteele> jeremy: yesterday we were talking about "in the future" -- what is the range CR implies?

<joesteele> paulc: this doc is in working draft stage, Last Call is next, usually feature complete by then

<joesteele> .... working groups decision on when to exit

<joesteele> ... then comes call for implementations

<joesteele> ... Last Call will probably takes 6 weeks with written comments on the spec

<joesteele> ... then go into CR (Candidate Recommendation)

<joesteele> markw: different ways to do it, but should be a small number of months to get to Last Call

<joesteele> ... once in CR we will be there until test, interoperable implementations, etc are all done

<joesteele> ... potentially quite long

<joesteele> ... this could actually be the long pole

<joesteele> ... if implementations in the field still require HTTP

<joesteele> ... this gives us a clear goal and a process for getting there

<joesteele> ... without setting a date

<joesteele> ddorwin: this makes sense, we have to have the tests before exiting CR

<joesteele> paulc: would we put an informative reference?

<joesteele> markw: there would be a normative reference

<joesteele> ddorwin: we need to fix that line, but everyone knows that

<joesteele> paulc: where is that text?

<joesteele> ddorwin: section 3.1.1

<paulc> http://www.w3.org/TR/encrypted-media/#methods

<ddorwin> https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/edit?usp=sharing

<joesteele> paulc: we have a proposal on the table -- any changes

<joesteele> ddorwin: this is a slightly different approach to the same thing

<joesteele> ... first two lines are unchanged and must be changed to match the other spec

<joesteele> ... this allows us to keep the final step, and then reject of secure origin is not presnt

<joesteele> ... last box is the text about well behaved implementations regardless of secure origins

<joesteele> ... copied Marks comments about CR in the 2nd box

<joesteele> ... next slide -- 3rd algorithm in the process -- DEPRECATED, indicates what is not allowed

<joesteele> markw: this is then essentially saying the same thing then? with different words?

<joesteele> ddorwin: yes

<joesteele> paulc: this text looks more robust and is easier to modify

<joesteele> markw: if there were any other conditions to add, this could be done with David text

<joesteele> ddorwin: for better or worse

<joesteele> MarkVickers: I think we are making a mistake here -- want to make a fundamental point

<joesteele> ... we saw a bunch of data presented yesterday

<joesteele> ... I will grant that is all true, HTTPS everywhere is coming

<joesteele> ... folks are gathering a list of where it is needed for privacy for example

<joesteele> ddorwin: these are well understood

<joesteele> MarkVickers: I don;t think this one is well understood

<joesteele> ... we don't just want everything on this list, there is nothing particular that MSE does that makes it need to be on this list

<joesteele> ddorwin: are you saying the reasons for HTTPS are well understood? the specs that should have HTTPS are being collected

<joesteele> MarkVickers: one example is protecting the content of URLs which is visible otherwise

<joesteele> ... but on the other hand it does not help to put things on the list that do not need HTTPS it just makes it longer

<joesteele> ... nothing MSE does inherently makes it need HTTPS

<joesteele> ... I would argue EME also should not be on that list

<joesteele> ... it really adds a communcation channel down to the CDM up through user space

<joesteele> ... the information passed up can have private data that needs to be protected -- that is granted

<joesteele> ... however if we imagine that the data is not protected, ie in the clear into user space

<joesteele> ... HTTPS does not solve that problem

<joesteele> ... passing the data in the clear into user space, already cause the problem

<joesteele> ... for example extensions that strip ads, could sit quieltly and sniff any information like this that comes up into user space while the page ie being processed

<joesteele> ... also advertising companies could setup a site with video, just to give them access to the tracking data coming through the CDM

<joesteele> ... if the site is writing the code, they will get that data in the clear, regardless of where it gets captured since they control the site

<joesteele> ... basically HTTPS does not solve this problem. It must be encrypted before it comes up.

<paulc> chaals: Janina wants to join the A11Y meeting see http://lists.w3.org/Archives/Public/public-html-a11y/2015Apr/0042.html

<joesteele> ... there must be some secure are where that private data is, and before it comes into user space it must be encrypted already.

<joesteele> ... when that happens HTTPS is not adding anything

<joesteele> ... long list of reasons to do HTTPS which have nothing to do with this, but in this case it does not help

<joesteele> ... it is a terrible solution for this problem

<joesteele> ... other ways of solving the problem, do a blacbox test

<joesteele> .... look at the data coming back form the CDM

<joesteele> ... 2nd could have a 3rd party that qualifies the CDMs, might be a W3C requirement even

<ddorwin> Identifiers must be encrypted: https://w3c.github.io/encrypted-media/#encrypt-identifiers

<joesteele> ... 3rd you can have a contrac, this gives you a legal edge

<joesteele> ... 4th you can have a bilateral arrangement for the UA to look at the code

<joesteele> ... that is the only thing you have to do

<joesteele> ddorwin: the first two points argue for no security on the web platform, because an extension or virus could access the data

<joesteele> ... other comments were about contracts, registry which are outside the scope of this spec

<joesteele> ddorwin: so extensions can do anything include making their own identifiers

<MarkVickers> kyong, you can dial in now

<Kyong> Hi

<joesteele> Kyong: this is Kyong Park from Comcats, Director of Security, taking care of compliance and encryption issues, robustness

<joesteele> MarkVickers: <giving a recap of the last few minutes>

<paulc> Thanks to Joe and Daniel for scribing the meeting so far.

<joesteele> ddorwin: generally this in not intened to push the HTTPS everywhere initiative, this is just for EME

<joesteele> ... encrypted idenfitiers is required by the spec

<joesteele> ... you are not off the hook by requiring HTTPS

<joesteele> ... identifiers are one concern but not the only one

<joesteele> ... providing access to un-sandboxed CDMs (running as root) is another

<joesteele> ... don;t want to allow MiTM attacks especially with unsandboxed CMDs

<joesteele> ... if you have an extension you can write anything you want into the page, they are dangerous and come with warnings

<joesteele> ... they are outside the scope of this

<joesteele> ... doesn't make the general goodness that comes with HTTPS go away

<joesteele> markw: I had a 3rd slide that addresses this topic

<joesteele> ... we did not get to that

<paulc> See https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/edit#slide=id.g76d7a3737_0_34

<joesteele> ... we discussed defense in depth yesterday

<ddorwin> Correct link: https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/view#slide=id.g76d7a3737_0_51

<joesteele> ... MarkVs concern was also one of my concerns ... that HTTPS should not be considered to mitigate CDMs which are bad actors

<joesteele> ... CDMs should be safe and UAs should ensure CDMs are safe

<joesteele> ... because you are passing opaque data to the UA that cannot always be verified, we have some text that says it must be verified

<joesteele> ... we should remove the text that says you can mititgate thes problems with HTTPS

<joesteele> ... what we are left with as a justification is the defense in the depth argument -- not very strong but ok

<joesteele> Kyong: my issue with the solution is the implications to the problem statement

<joesteele> ... when protected identifiers are passed between the CDM and license servers, I would anticipate a stragtegy that covers the ntire problem

<joesteele> ... TLS only covers part of the problem

<joesteele> ... and introduces things that have nothing to do with that problem

<joesteele> ddorwin: the secure origin is required as well because that forces scripts to also be from the secure origin, general protection against other origins

<joesteele> ... I agree with MarkW slide #3, we all tried to address #1 in our slides, we can work on the other two to come up with text

<joesteele> ... reiterate that the reason is not to protect th identifiers in transit, there are other concerns

<joesteele> ... e.g. if a UA had other permissions-type protections, without TLS you could not enforce such restrictions

<Zakim> cwilso, you wanted to say (and no, I'm not physically/audibly available) simply to have it stated that CDMs *SHOULD* be safe. UAs should not be required to put their users at risk

<cwilso> no I am not.

<joesteele> joesteele: agreed

<cwilso> I can be q-, just wanted that statement made

<cwilso> (i.e. "defense in depth" is more than just a joke about me trusting no one. ;)

<joesteele> MarkVickers: one thing I heard I am happy about, this is not a replacement for encryption of the data, that that has to happen regardless of HTTPS. See some heads nodding

<joesteele> ... think we are agreed on that CDMs must do the right thing

<joesteele> ... re the argument about browser addons (because they could attack anything), CDMs are especially vulnerable. Other things browsers can get are things you type in -- passwords, banking information, etc. I need to think about addons in those cases.

<joesteele> ... in the CDM case folks are not thinking about that, so that means it must be encrytped. It happens automatically.

<joesteele> ... othe rthings is, protecting MITM and defense in depth, those are generic things that apply to the web platform in general. HTTPS would improve those everywhere, but is not particular to EME.

<ddorwin> EME is unique in that it relies on passing opaque blobs to an undefined (and often unsandboxed) entity.

<joesteele> ... Anything that says (this API specifically require HTTPS) should not be there, this is not unique. This API would benefit from HTTPS in the same way that any API would benefit from HTTPS.

<joesteele> Kyong: I agree with MarkV that is the main point I wanted to make. This is helping me to underrtsnad and get behind introducing TLS as a requirement. The requiement was not particulartly crisp before this.

<joesteele> ... should be the case that the solution covers the entire problem

<ddorwin> Kyong, I encourage you to read https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

<joesteele> ... want to be careful because TLS introduces lots of security benefits, but there are barriers to deployment and we have other mechanisms we would like to introduce which are more performant, TLS can be redundant in some cases and I am concerned that it might be used as a panacea.

<joesteele> ... this would increase costs significantly

<joesteele> ddorwin: EME is very unique from MSE. MSE can be entirely implemented in script. EME is unique in that we have this undefined CDM thing that is a blackbox and cannot be tested.

<joesteele> ... the fact is that they are often unsandboxed and running as root this is a concer

<joesteele> ... pasted a link above about this

<Kyong> All, thank you for the opportunity to participate. Will rejoin in an hour. Dropping for now.

<joesteele> ... we do not take this lightly and discuss a lot internally. There are good security reasons for this, not just "HTTPS is better"

<joesteele> markw: that is essentially the argumment we made yesterday. CDMs must be safe and UA must ensure they are safe. There are various ways they can ensure this, but we are also hearing it is not always easy for UA to firgure this out.

<joesteele> ... there is something to that and HTTPS might cover that slight difference there.

<joesteele> ... in order to get companies to move though, there needs to be a larger process not just the folks in this room.

<joesteele> ... need the browsers vendors, site operators, etc together to discuss this

<joesteele> ... we have made good progress so far

<joesteele> MarkVickers: think there is lot of agreement here

<joesteele> ... what David said about EME being different from MSE, totally agree with

<joesteele> ... problem that we do not have an open source DRM

<paulc> ddavis: Thanks for the rrsagent command

<joesteele> ... but HTTPS is not solving that problem (sandboxing on the client)

<joesteele> ... this is specifically talking about HTTPS which is just covering the communication to the server

<joesteele> ... the unique problem of EME with the key messages is not helped by HTTPS

<joesteele> ... agree there are other issues, but HTTPS does not address these

<ddorwin> HTTPS doesn't just protect the transmitting of data. It is also important for authentication of the source of code and prevention of, for example, MitM attacks that interact with the (unsandboxed) CDM.

<joesteele> ddorwin: think there is misunderstanding about what HTTPS provides

<joesteele> ... it also provides authentication of the source of the request

<joesteele> ... we know that the requester is who they say they are, so MITM cannot make requests

<joesteele> ... or introduce vulns

<joesteele> ... WebGL also talks to hardware directly, but they are well-formed and sanitized

<joesteele> ... we cannot do that with EME

<joesteele> ... would like to be able to do that but not yet

<joesteele> MarkVickers: I hear and understand that point

<joesteele> paulc: we have a proposal on the table, are you against that proposal MarkV?

<joesteele> MarkVickers: Don't know where the overall consensus is, but I would not be in favor of this. Don't feel that mandating HTTPS is justified in this case.

<joesteele> ... I will take my cue from Kyong then

<joesteele> paulc: straw poll

<joesteele> ... this will be a straw poll on Davids proposal -- slightly more robust and easier to modify

<ddorwin> Proposal: https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/preview

<joesteele> ... for, against, can live with

<joesteele> ... this will be David's proposal with MarkW 3rd slides added

<ddorwin> Straw poll on my spec text proposal (https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/preview) with Mark's third slide (https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/view#slide=id.g76d7a3737_0_51)

<joesteele> rustamk: Comcast, against this

<joesteele> ddavis: W3C, for the proposal

<joesteele> joesteele: Adobe, can live with it

<joesteele> BobLund: CableLabs, against it

<joesteele> MarkVickers: Comcast, we will live with it, but against

<joesteele> markw: Netflix, for

<joesteele> ddorwin: Google, for it

<joesteele> jdsmith: Microsoft, for it

<joesteele> paulc: don't think we have consensus yet

Staw poll result - For: 4; Can live with: 1; Against: 2

<joesteele> paulc: heard one new thing, that this would have other disadvantages

<joesteele> MarkVickers: yes, but Kyong would have to go over that

<joesteele> ... I agree with most of this

<joesteele> ... my only concern is that it will be made mandatory

<joesteele> markw: that would be my question, if this was SHOULD could we agree with it

<joesteele> ... ?

<joesteele> paulc: are you proposing we take this note out and then do the straw poll again?

<joesteele> markw; think we should add a requirement that whether it will turn from SHOULD to MUST is an open issue

<joesteele> ... don't want to just remove it

<joesteele> ddorwin: all we are saying is that long term this will change, there is no time line

<joesteele> paulc: don't want to put this into the doc if there is not consensus and then have it be used in the future as proof of consensus

<joesteele> ... could do the straw poll wider -- might have more of a spread in the numbers

<joesteele> ... we have the smart folks in the room that should let us get to text

<joesteele> MarkVickers: I could list the things that need to change

<joesteele> ... that secnd bullet

<joesteele> ... Mark had some recommendations yesterday that should be made mandatory

<joesteele> markw: link is in the IRC

<joesteele> BobLund: David, was your note made to capture that as well?

<joesteele> ddorwin: yes, but I expect to go through a iterate more on that piece

<joesteele> paulc: should we have a coffee break and discuss offline?

<joesteele> ddorwin: we will be at CR? will they formally object? they said they will live with it

<joesteele> markw: think we should have the spec be honest about the reality, to not have services write their services on HTTP when it will not be there in the future

<joesteele> ... folks need to include that in their costs

<joesteele> ... but folks don't want to put a stake in the ground when they don't have the data to support those plans

<joesteele> ... we need to fit the language to the gap

<joesteele> paulc: lets look at the proposed text.

<joesteele> ... What if it said -- it is expected that this requirement will be evaluated at CR?

<joesteele> MarkVickers: one issue is timing related, but it is more generic where it could be something other than HTTPS that meets the same goals

<joesteele> ... 2nd issue is that we have LAN devices (e.g. gateway, setopbox) in the home. We have introduced VidePath and the source will be inside the home for those devices.

<joesteele> BobLund: The problem is that getting a certificate for LAN devices is hard

<joesteele> ddorwin: there is another WG working on how to define this

<joesteele> ... this is why it is hard to discuss this we don't have the right words

<joesteele> ... we may not need a PKI for example, if we have something equivalent

<joesteele> BobLund: we can get certs that are not publicaly signed, but we don't want to have to train users that way

<joesteele> markw: we are saying that a "priviledged context" is needed but we have not described how to get there yet except for HTTPS. That is what the other group is working on.

<joesteele> BobLund: I agree with that - I would like to see the note strengthened to address that specific concern. The evolution to working with only secure contexts should be softened because we don't know that those problems will be solved

<joesteele> paulc: lets take a 20min break and we should have Kyong again.

<scribe> scribenick: ddavis

<scribe> scribe: Daniel

<scribe> Chair: Paul

<scribe> Meeting: HTML Media Task Force Teleconference

<MarkVickers> Kyong: can you dial in?

ddorwin: Comcast is more concerned about @@@ than the CDM issue.
... I have two proposals...

<MarkVickers> Kyong: are you there?

ddorwin: 1) Instead of expected to be mandatory will be re-evaluated.
... We want to avoid readers of the spec to implement it and then have to redo it soon after.
... We should be clear about what the long term plan is and that this is actually going to happen.
... I worry about delaying this and being not clear.
... One concern is the timeline.
... 2) The home network case, to add an issue box about how it should be enforced/how it works on internal networks.
... I offered to find out what's going on and we can reference that from the issue box.
... We should be clear about that and the known concerns.

paulc: [Typing a proposed change to ddorwin's proposal]
... Proposed change: "It is expected that the removal of this step will be evaluated during CR".
... Proposed change (continued): "Add an ISSUE box that would point to a bug concerning the security contents in private networks. This would be filed with the WebAppSec WG".

MarkVickers: We had a further discussion and summarized what are Comcast's three issues.
... 1) Making our network/CDNs efficient for sending video securely, similar to Netflix's issue.
... 2) With LAN devices (gateways, STBs) to be secure end points and a certificate issue.
... 3) The issue you talked about, regarding how to put in more hardened security in the network and the HTTPS requirement would be more expensive in an unnecessary way.
... Regarding 1), Rus is saying we're working on the efficiency of delivery of secure video. That's a matter of time - it's underway and we're not concerned.
... Regarding 2), what's being suggested is we put an issue box in the spec, and we (Comcast) will get in touch with WebAppSec WG about the "privileged context" which is more generic than saying HTTPS, etc.
... We can work with them for a solution to privileged context in a LAN.
... Are you OK with those two?

Kyong: Yes, I think so.

MarkVickers: I'd like you to address your concerns that our discussions are making things difficult.

Kyong: Every device that interacts with our service/content we track devices so we can understand whether a device has access to certain data.
... Access anywhere is predicated on being able to authenticate and get the authenticity of a client.
... We end up negotiating session keys with each client and they can be used within app layers to protect data and authenticate clients.
... This is equivalent to a TLS handshake.
... We share that state across enterprise across the country.
... There's a protracted sequence of steps to understand where a title can be source
... Because we've already negotiated the keys we're able to use algorithms to authenticate clients and protect data.
... What would be counter-productive would be to introduce a TLS handshake.
... It's redundant to what we've already defined for our security channels.
... Furthermore, the measure of security from TLS is less than what we have established by our current strategy.

<paulc> TAG Finding HTTPS: http://www.w3.org/2001/tag/doc/web-https

Kyong: In other words, we're added overhead unnecessarily.
... This would create additional latency while not added security.
... It would mean we've lost the right to choose the security for our infrastructure.

MarkVickers: So right now they're not referring to HTTPS/TLS - they referring more generically to privileged contexts.
... Does what you're doing qualify as privileged context?
... Also are you building the security using web browser tools or just for custom clients?

Kyong: It's a question of whether clients have credentials.
... Provided the client has the credentials we can use that to create a secure channel and exchange keys.
... On the first part, it sounds like we have some latitude to define what is secure so we may be able to qualify our solution.
... Second, we should be able to use security frameworks that are not proprietary to Comcast.

markw: We have a similar setup with an alternative security protocol using JavaScript.

<MarkVickers> http://techblog.netflix.com/2014/10/message-security-layer-modern-take-on.html

markw: The issue we have here is that it's the browser that's displaying the green padlock to the user. It's the UA that has to convince itself that all communication channels are secure.
... It doesn't mean that new tech can't be used in future.
... Anybody can go to the security groups to standardize their technology. Particularly for the LAN case that's what's going to be necessary.
... I don't think it should be a reason to influence our approach to EME.
... The security has to be implemented in the browser in order for the browser to tell the user that it's secure.

Kyong: One of the security effects is a secure channel between a CDM and exit point.

markw: Once you have a green padlock in the browser all other communication from that page has to be secure.
... It would be nice if there were other security protocols but there's a lot of work to get that to happen.
... It's not something that's excluded from future discussion.

ddorwin: The only thing browsers know is what they can enforce which is currently TLS or privileged context (e.g. local network maybe).
... If you want the green padlock, you must be on a secure page and your communications must be secure.
... Within that if you want to further secure a channel that's fine - that's separate to the security required for the browser to show the green padlock.

paulc: I believe our minutes reflect we have proposal to change the text. Is that enough of a change to get consensus?
... Proposed change: "It is expected that the removal of this step will be evaluated during CR".
... Proposed change (continued): "Add an ISSUE box that would point to a bug concerning the security contents in private networks. This would be filed with the WebAppSec WG".

<paulc> The first proposed change refers to the Note in https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/edit#slide=id.g76d8deff9_0_0

paulc: What we're saying is that the note saying this is deprecated also says "It is expected that..." (proposed change #1 above).
... In particular, it's common that when we have a problem in the text we use an ISSUE box.
... Around the proposed change we'd have an issue box pointing to the bug.

<Kyong> -q

paulc: Once that bug has been filed.

<Kyong> The privileged context language addresses my issue

MarkVickers: We had three issues - the first will be solved in time.
... The second issue (LAN context issue) is address by the issue box.
... We could be vague on that now because we haven't seen the bug.
... Kyong, do you think your third issue could be rolled in solving the privileged context for LAN issue?
... Since it's about an enterprise issue.
... Or do you think it's a separate issue that should have a separate bug.

Kyong: I don't know that it fully addresses the problem.
... It seems other security measures would be permitted but that's predicated on qualifying and having a security approach that's approved.

MarkVickers: Yes. What's the alternative? If the browser puts up a green lock guaranteeing that the user can feel safe, how can they tell unless they're implementing?
... We can still implement that protocol on top of JavaScript but that wouldn't be enough to allow us to use EME.

ddorwin: Today, you're not going to get any green lock.
... You're only options today are an HTTP page which doesn't change.
... For the browser, any connection like this is insecure.
... The importance of this is good to discuss with WebAppSec.
... The browser only knows about what it does.

paulc: It seems to me that it might come down to whether Mark can get browsers to adopt his protocol or just adopt TLS.
... The earlier you (Comcast) get engaged with WebAppSec the better.

MarkVickers: That would be addressing issue three.
... Issue two isn't solved by just using TLS.

<joesteele> joesteele: and doing that would solve more than just the EME problem -- you would get the green lock for other use cases as well

paulc: Getting involved with WebAppSec is good because that's the only place to ask this kind of question.

rsleevi: I work with ddorwin and the Chrome team.
... I'm interested in security.
... I want to explain the rationale.
... There's been a lot of talk about the protocol but that's not our biggest sticking point.
... One aspect of intent is what does the user expect?
... If they type HTTPS:// they expect to go to a secure, confidential page.
... The part mixed content tries to solve is identifying the intent of the author.
... If the page author says load this page over HTTP we don't know whether they intend for it to be secure or not.
... Mixed content and the privileged context specs look at intent.
... This is in browsers today, so e.g. Firefox will load HTTP content but say we can skip authentication, called "opportunistic encryption".
... There's another protocol called QUIC.
... There are two parts we're concerned about.
... 1) When you load a page we want to make sure that's what the author intended.

<markw> https://www.chromium.org/quic

rsleevi: 2) If the user types https:// that they're given the confidentially they expect.
... So with HTTP it's hard to know what the intent is.
... The scheme and the protocol are slightly distinct
... If there are other protocols that offer the same confidentiality and authenticity as TLS that's a conversation for the browser vendors.
... It sounds like there's some concern about how to communicate securely on a local network.
... There are some solutions currently and it's an area of great focus for browsers.
... Whatever device you're talking to, it's important to communicate securely on a local network, which is not inherently secure.

<markw> @rsleevi: can you give us some pointers to the work on secure local network communication ?

<MarkVickers> It's great to hear that the LAN secure endpoint issue is already an issue being worked on!

rsleevi: For those thinking that privileged context means TLS - that's not correct. It's supposed to be agnostic.
... As long as the intent is clear, it can be done securely.

paulc: That was very helpful, thank you.

Kyong: It's not necessarily an issue with secure origins or that other sessions are secure.
... I have no problem with maintaining security and privacy.
... Our issue is being able to opt out of the mandate for EME. We should be given the option to not necessarily secure the transaction.

ddorwin: The browsers are responsible for presenting the current state to the user.
... Whatever we say in the spec, it's likely that browsers will implement this some time in the future.
... This requirement is going to come.
... Hopefully we can solve the internal network thing.
... Regardless of what it says in the spec it's not going to change what's going to happen in some major browsers.

Kyong: My understanding is out of this concern for privacy of identifiers, I don't have a problem with this.
... If we don't have CDMs that are anonymous then if we're saying TLS is the answer, then we have client certificates with identifying information.

MarkVickers: Out of our three issues - 1) I'm happy with the language there.
... 2) Really happy hearing Ryan's information that this is already being considered an issue and being addressed.
... I'm saying that Comcast are going to join in that issue, with CableLabs, to find a standard way to bring LAN origins into this HTTPS world.
... It's a big problem that keeps coming up for us.
... 3) The disagreement can be put quick succinctly.
... The machinery of EME can, because of the fact the only secure protocol can be the one that's built into the browser, is the route we're going down.
... You could build your own system into the browser.
... That capability is being removed is the concern.

<ddorwin> Kyong: The motivation for the privileged contexts requirement is NOT just about encrypting or protecting identifiers. This was discussed several times between your calls and during the break. Please read https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 for more context on the issues. (It's lengthy, but it covers many of the issues.)

ddorwin: The reason for the privileged context is not just to protect the identifier.
... The bug goes into this.
... It's about authentication and trusting from man-in-the-middle attacks.

MarkVickers: Kyong, I'll try to relay it to you separately.

paulc: It's been suggested to me to get the widest possible input on this issue, not just in this room.
... So we have a change proposal. I'd like to ask the editors to put together a proposal for Bug 26332 and make that available widely.
... Comcast need to make sure that their third issue is also included.
... If we can find a pointer to where the LAN issue is being discussed maybe we don't need to file a new bug for that.
... I don't believe we should get more consensus within the room because we still need to get wider review.
... Any objections?

MarkVickers: Maybe we should split your proposal into two parts.
... A statement like regardless if HTTPS is being used the keys should be encrypted.
... and then isolate the only part that has some difference to get buy in.

paulc: There seems to be a lot of consensus on some points. MarkVickers is asking to divide it into where there is and isn't consensus.

ddorwin: There are many changes we can make.
... We still need to say what's going to happen and it's misleading if we don't say that privileged context are very likely to be required.
... That note is a problem but most of my text is irrelevant without that note.
... Even if we take out all the other stuff that's the message we're trying to get out.
... I'd like to consider that the new proposal is that we'll do this by PR.
... If we leave here without a concrete plan it'll be TPAC before we solve this.

MarkVickers: I'm OK with that language.

paulc: What changes do you want to make ddorwin?

ddorwin: We can work on markw's proposal.
... I don't want any change to your text.

paulc: Do I have unanimous support?

Yes from the participants in the room.

paulc: So we can resolve 26332.
... I'll handle this by highlighting this in an email to the Task Force.
... ddorwin, thank you to Ryan because his input was very useful.
... The subtlety that there are different requirements to satisfy the protocol is a revelation.
... Thank you. Lunchtime. Meeting back at 1:15pm

<Kyong> Gents, just dropped off

OK Kyong, we'll be back in an hour.

Issue 45

<paulc> https://github.com/w3c/encrypted-media/issues/45

<jdsmith> ddorwin: Summarize issue. We are interested in solving the issue, and want to enable content. Netflix has their reasons for preferring this solution.

<jdsmith> ... Issue is that access to Netflix content imposes requirements on user agents.

<jdsmith> ... Current solution would fragment the web, and enable content based on whether this requirement was supported or not.

<jdsmith> Rustamk: Need a secure way to know that a license has been removed from a system.

<jdsmith> ...Lacking this, you run into issues determining whether a license is still valid for a system.

<jdsmith> Ddorwin: That's the scenario for persistent licenses, where licenses can be accessd when you are not on the web, in an airplane, that sort of thing.

<jdsmith> Rustamk: Understand that, but outside of the persistent-release-message, haven't seen a way to know that a license has been deleted.

<jdsmith> ...We need a way to know that a license has been deleted from a system.

<jdsmith> Ddorwin: Persisted licenses do that now. They persist a license on a system until you delete it.

<jdsmith> Rustamk: Q: for Netflix: What's your use case for persisteed-release-message?

<jdsmith> Mwatson: Systemic attack using proxy servers could look like short term start of playing multiple content, but in fact are blocking messages and enabling ongoing concurrent playback of the media.

<jdsmith> ...using persistent-release-messages, this could be detected after the fact, and could be used to block these proxy servers.

<jdsmith> Rustank: Comcast has the same use case for stream counts and keeping track of concurrent streams.

<jdsmith> joesteele: Think that persistent-release-messages and persistent-licenses should work together.

<jdsmith> ....release message provides an assertion from the CDM so that the license cannot be transferred to other devices.

<jdsmith> ... don't think the current persistent-licenses support a secure message on license deletion.

<jdsmith> ddorwin: Please everyone read the language in the spec about persisted-licenses.

<jdsmith> ...concurrent stream limits are possible by other mechanisms transparent to EME. They are in the license. Release messages are also possible for persistent-licenses.

<paulc> Please don't argue for or against something because of how long has been in the spec.

<jdsmith> ... the persistent-release-message type hasn't been in the spec that long. Enum was added fairly recently.

<jdsmith> ...not a preexisting feature that's had consensus support.

<jdsmith> rustamk: reading through editor's draft and don't see the release message for persistent-licenses.

<jdsmith> ddorwin: Intent is to support release messages on persistent licenses, otherwise wouldn't be useful for use cases like content checkout.

<joesteele> https://w3c.github.io/encrypted-media/#update

<jdsmith> joesteele: "If sanitized response includes a license destruction acknowledgement..."

<jdsmith> ... language under "remove" describes the behavior.

<jdsmith> ... step 5.2.5 defines a license release message.

<paulc> https://w3c.github.io/encrypted-media/#remove step 5.2.5

<jdsmith> .... thought step 3 of "remove" related to persistent-release-message.

<jdsmith> markw: Can see that the messaging is pretty much the same between persistent-release-message and persistent-license.

<jdsmith> ...difference is that persistent-release-message can work on devices that don't have a provision for persisting licenses.

<jdsmith> ddorwin: While these share the release message part, they have very different offline properties.

<jdsmith> ...first of all, persistent-licenses are not supported by all clients, and there is a fallback behavior defined.

<jdsmith> ...temporary is required for all and supports online playback.

<jdsmith> ...persistent-licenses aren't required to access content at all, but allows offline playback as an additional experience.

<jdsmith> ...persistent-license also have an explicit action to remove them from the device and create a release message.

<jdsmith> ...the persistent-release-message behavior is not as explicit.

<jdsmith> ...having this undefined feature in the spec isn't desirable. I think we should remove it and move on the defining alternatives.

<jdsmith> markw: The feature is defined in the spec, and documents how and when release messages are sent.

<jdsmith> ...I hear the concern about generating release messages for other cases (e.g. browser close).

<jdsmith> ...We could describe more details about what's in the message and define behavior on how often active license information is stored.

<jdsmith> ...That should respond to concerns about behavior on system shutdown.

<jdsmith> ...The feature is further along than David's concerns express, and we don't have alternatives proposed.

<jdsmith> ddowin: We've not spent time defining alternatives.

<jdsmith> ...The other problem is that messages may ultimately be required for more cases than the spec itself requires.

<jdsmith> ...By including the feature in the spec, we are opening ourselves up for these kind of additions.

<jdsmith> joesteele: Some fragmentation across devices is to a certain extent unavoidable. I don't personally think this will happen that much.

<jdsmith> ddorwin: We need to avoid making problems worse, and fragementation exposure should be minimized.

<jdsmith> ...We should take steps to ensure that access to content is possible for every device.

<jdsmith> ...We should not require every device to support persistence to access content.

<jdsmith> markw: It's optional, not required.

<jdsmith> ddorwin: But it may be required to access Netflix.

<jdsmith> markw: Whether it's included in the spec isn't relevant to whether it's a requirement for access to our content.

<jdsmith> paulc: Do you have a concrete list of things in the spec here that could be improved.

<jdsmith> markw: We are working on improvements to this and could have more soon.

<jdsmith> paulc: As a comment, I'm always uncomfortable saying that a given requirement only meets the needs of one company. We'll learn that as the spec gets wider review through CR.

<jdsmith> ...It's too early to say what should or shouldn't be in the spec based on implementation experience.

<jdsmith> ...Mark says this can be improved in a single digit number of weeks, so it's too early to take it out of the spec now.

<jdsmith> ddorwin: Isn't CR based on browser/UA implementation rather than website implementations?

<jdsmith> paulc: We can set criteria for this to be what we want, and could require more than one implementation supports this feature.

<jdsmith> ddorwin: But that is browser implementation rather than website use of the feature.

<jdsmith> markw: It's true that there aren't that many certifiers here, and it shouldn't be surprising if Netflix uses a feature first.

<jdsmith> ...The CR criteria says multiple browsers and DRM providers support a feature, and if they support the feature, that should support its value.

<jdsmith> ddorwin: Any other supporters here for the feature?

<jdsmith> rustamk: I see possiblities for Comcast to use the feature, and think we have the same use case requirements.

<jdsmith> ddorwin: Then how do we address the concerns about the architecture and offline access, and what happens if only some UAs support the feature.

<jdsmith> MarkVickers: It appears that users would still get access, but some aspects of the service might be tied to this feature.

<jdsmith> ddorwin: I believe Netflix supports this features because it allows better up-time relative to other options.

<jdsmith> markw: Time is the main priority.

<jdsmith> ddorwin: There may be other solutions for insuring uptime. If license server access is dropped, perhaps playback can continue in some way.

<jdsmith> markw: We do have services now running without this feature. The question is what features are needed to get access to some levels of content.

<jdsmith> ...it's up to us if content is provided based on some UA feature or not.

<jdsmith> MarkVickers: It might be more than performance level, but access to features like download could be tied to an optional feature.

<jdsmith> paulc: MarkW: Can you take an action to provide more detail on updates for the spec here?

<jdsmith> markw: Yes.

<paulc> ACTION: markw to provide additional technical recommendations for persistent-release-message based on implementation experience [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action01]

<trackbot> Created ACTION-85 - Provide additional technical recommendations for persistent-release-message based on implementation experience [on Mark Watson - due 2015-04-23].

<paulc> ACTION-85 is due in two weeks

<paulc> ACTION-85: due in two weeks

<trackbot> Notes added to ACTION-85 Provide additional technical recommendations for persistent-release-message based on implementation experience.

<jdsmith> ddorwin: The main experiences of a site should be consistent if a UA supports all required features of a spec. In this case, that might require treating this feature as required.

Bug 27269

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269

<paulc> ACTION: ddorwin to send an update on Bug 27269 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action02]

<trackbot> Created ACTION-86 - Send an update on bug 27269 [on David Dorwin - due 2015-04-23].

bug 27093 and issue 41

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093

<scribe> scribenick: jdsmith

<paulc> https://github.com/w3c/encrypted-media/issues/41

<paulc> Bug 27093 Blocks: 20944 26838 27053

<paulc> See three use cases in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093#c11

<paulc> David's request to discuss use cases: https://github.com/w3c/encrypted-media/issues/41#issuecomment-93646287

ddorwin: Proposed we discuss the use cases today.

<paulc> https://w3c.github.io/encrypted-media/#definitions Initialization Data:

joesteele: Initialization Data section of spec says this must not contain application data, client data, user data, keys or code. All make sense to me except "keys".
... Others make sense from a security and privacy perspective, but not keys.

paulc: Your use cases require that keys be removed from here.
... Correct?

joesteele: Yes, that is correct. It is the minimum change and would be good enough for me.
... Given these use cases, should we describe them somehow in the spec?
... I don't want to introduce use cases, but don't want the spec to preclude them.

<Zakim> ddorwin, you wanted to say The reason it prohibits keys is that the algorithms don't support it. That's why we should discuss use cases.

ddorwin: The reason "keys" are there is because the algorithms support it, it was intended to require an algorithm update if these use cases are to be supported.
... If the use case is common and we want to support it, then we should make these updates.

joesteele: Advocating that the CDM may be able to get the content key without sending a message to the server.

ddorwin: If there's a way that's not through the web app, then it's application specific and we won't be able to have interoperable apps.

markw: I'm sensitive to the request to remove keys from that section. There are proprietary initDatas in the spec and we don't say what they contain. We do say that after the messages, there may be keys.
... We aren't explicit about how the keys are delivered. It's acceptable to allow differences with various key systems.

joesteele: The use case I'm most concerned about are ones where I get a large performance benefit by how the keys are delivered, and think that doesn't need to be the spec's business.

ddorwin: If performance is important, then application developers will want to make sure that those benefits are available on all systems.

joesteele: The current spec says that a proprietary pssh is supported/allowed.

<ddorwin> The last NOTE in http://w3c.github.io/encrypted-media/#initialization-data

<jdsmith_> joesteele: spec says that initiData should not (not must not) include keys

<jdsmith_> ...I tried to call out where algorithms need to be changed to allow this.

<jdsmith_> markw: It seems clear to me that it's part of the spec for CDM messages to be opaque.

<jdsmith_> ...More complicated question is should we change our procedures to allow for this?

<jdsmith_> ...Possible principles: If we encounter a use case that requires slightly different message flow, then we should try to accommodate that.

<Zakim> ddorwin, you wanted to ask How does one write an interoperable application if how the keys are obtained is key system specific?

<jdsmith_> ...Or, we should only support the message flows that are defined in the spec, and modify it if necessary to support a use case.

<ddorwin> How does one write an interoperable application if how the keys are obtained is key system specific? For example, keys known a priori for some reason.

<jdsmith_> ddorwin: Prefer the second principle so that we explain how things would work.

<jdsmith_> ...If we allowed alternative key deliveries (some magic), how would the application deal with these differences?

<jdsmith_> joesteele: Some CDMs would send more or less key messages than others.

<jdsmith_> ...if you allow for applications to accept zero through N key messages, then this should just work.

<jdsmith_> ddorwin: Mostly concerned about the zero case and how it was created.

<jdsmith_> ...Without understanding this, it seems like it could affect availability of content.

<jdsmith_> paulc: Was a use case the zero key exchange?

<paulc> See the use cases in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093#c11

joesteele: Case 1: key already available locally, passed through hidden means, and usable to play other related content.

ddorwin: It's been suggested before that we should suppress messages if a key is locally available. I would like to see in detail examples of this.
... Diving into the use cases can help us understand this. Reuse is common to all systems, so making it consistent means we should specify it.

joesteele: Case 2: Keys are baked into the client. There don't need to be key requests in this case because the key will always be available.

ddorwin: So basically, all implementations have the same key?

joesteele: Yes. This works for scenarios where content over the channel should be encrypted, but having a unique key isn't important.

ddorwin: That doesn't sound like a common use case.

joesteele: Goes back to a fundamental question: Do I want every client to support this? Probably not.
... We have this problem today. We'd have to send a bogus message back even though it's not necessary.
... I understand that not all key systems may want to support this. I'd like to know what the group thinks the bar is for supporting use cases that not all CDMs may support.

ddorwin: You could break down case 2 to use a master key of some kind. A key in the pssh is separate.
... There are other reasons to support keys in the pssh.
... Then there is the key alreay exists. It seems like that is a corner case and should mess up the spec to support it.
... shouldn't mess up...

MarkVickers: There are other use cases beyond the ones Joe has defined.
... There are similarities between key system access and MIME types.
... Not all key system models have to be supported by all browsers. Once we know the key system supported, you can adjust to use it.

ddorwin: Goal of EME should be to enable content that work across browsers.

MarkVickers: To be clear, we want to use the model here of CENC, CDMs, etc...

ddorwin: We've discussed out of band license acquisition before and it's not supported because it violates web security architecture.

joesteele: I don't think we've said anything about key acquisition, except where it involves sending messages to a computer.
... I'm willing to drill into the case where I can acquire a long lived key that can decrypt content keys that are in the pssh.

ddorwin: That probably should be discussed along with getting input from other people on it.
... It could open an entire category of things that are out of scope at the moment.

joesteele: I want to make a distinction between higher level keys, and I'm fine with treating it as out of scope, but don't want the spec to disallow it.

ddorwin: Fine means allow doing it in a hidden way/
... Persisting keys, whether content keys or otherwise is not allowed by the spec.
... I thought when we punted domain keys, we were putting aside use cases that required them.

joesteele: The high traffic use case for me is to improve performance by issuing a master key that is used to decrypt other keys, and speed playback.
... Case 3 lets the CDM retreive a key from a license server and use it to access other keys.

paulc: Which use cases do we want to dig into and in which order?

ddorwin: We can discuss them here, but it might make sense to solicit bugs on use case needs.

paulc: You are saying that the pssh containing a key is somewhat orthogonal to the problem.

ddorwin: Yes.

<ddorwin> Proposal:

<ddorwin> 1. File bug to remove "keys" from the Initialization Data definition.

<ddorwin> 2. File a bug to support key in the initData.

<ddorwin> 3. File a bug on "performance keys" (aka key chaining)

<ddorwin> 4. seek input on #2 and #3

<ddorwin> 5. Block #1 on #2 and #3

joesteele: Removing keys from initialization data would help.

paulc: Can we just work this in Issue 46, or do we need bug 27093 open?

<ddorwin> 6. Close issue 41 as a dup of #1 (or just re-title it and update the first).

<ddorwin> 7. Hopefully, 27093 is orthogonal and we can close it and focus on the GitHub bugs.

<paulc> ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action03]

<trackbot> Error finding 'joesteele'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

<paulc> ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action04]

<trackbot> Created ACTION-87 - Carry out steps 1 thru 6 on the proposed solution to issue-41 [on Joe Steele - due 2015-04-23].

<paulc> ACTION-87 is due in two weeks

<paulc> Editor will resolve 27093

<scribe> scribenick: jdsmith

Common license request format

<paulc> https://github.com/steelejoe/eme-generic-protocol

joesteele: We had discussion at last TPAC about this, and some general approval.
... I think if we said CDMs should support it, we could use it as a tool to work on other bugs involving opaque messaging.
... Proposal posted.
... keys for ClearKey are JSON based, so I used that.
... 1st possible issue: key system specific identifer for keys.

<paulc> https://github.com/steelejoe/eme-generic-protocol/blob/master/eme-request-asn1.txt

joesteele: options would be to explicit define the format for this, or leave it to the CDMs.
... The proposal leaves key identifer open, and provides specific suggestions for other request data.
... Response data details are also proposed on timing, and rules for use of provided keys.
... The ask: Do we think this is useful to carry forward? David said thanks, but it needs more feedback.

MarkVickers: At a high level, I think this is very, very important.
... Criticisms of the EME API have been different from other APIs. We should get rid of opaqueness wherever we can.
... We should push the DRM vendors on opaque features. Opaqueness may be needed at times, but shouldn't be used just to avoid specifying the details.
... We should push areas that are opaque to be explicitly spec'd. Don't give up at the start. It's muh harder to come back later and turn opaque features into transparent ones.

ddorwin: If we use JSON's, how do we sign them? You can sign the contents rather than the structure. it would still require some pushing to support.

markw: Think this is a good idea as well. We need at least two DRM vendors that are committed to doing it.
... More would be better.
... Should try to get feedback from them on details that could be difficult.

<paulc> markw: List the set of features the protocol needs to support

jlacivita: We integrate with all the DRM providers, and need a user context and an application specific ID.

joesteele: Specifically excluded user context. A CDM could sign it, but we don't. It could be provided at the application level.
... I agree we should push hard for this. We could, however, use type to define a fallback position that would allow opaqueness short term, and move to transparancy later.

ddorwin: I'm not sure about user context, but there could certainly be a requirement for application signature.

joesteele: If we define the delivery key identifer in a common way, we could verify that this who this was intended for.

<ddorwin> I agree with Mark. I think there are at least two categories to work on: what features should be included and the format.

<ddorwin> We’ll probably need to do some cross-referencing against the spec features. Some things that aren’t in the EME spec (at least for now), such as renewal period might be required.

ddorwin: Should work on what features should be supported and what the format is.
... We don't need to limit what's supported in the spec. For example, renewal period is not specified today.

MarkVickers: If we have this more opaque API that's blocked by some underlying IP. The API details itself should not be a problem.

markw: The way we describe features in the API could lead to very different implementations. From the outside, they look very similar, but inside, may be very different.
... Through design of this, some venders may say a standard approach is fine, and others may not.

MarkVickers: That's understandable, but not a reason not to dive in and try to make it work.
... The word is out that we are defining a common plugin free media solution, and if we work on a common CDM interface, we should get participation.

markw: Is this V1?

MarkVickers: Has to be in from the begginging or opaque solutions will be grandfathered in.

<paulc> ACTION: paulc to check on whether the proposed generic license request/response protocol is in scope of the current HTML WG charter [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action05]

<trackbot> Created ACTION-88 - Check on whether the proposed generic license request/response protocol is in scope of the current html wg charter [on Paul Cotton - due 2015-04-23].

MarkVickers: We can ship now as we work on the spec, but shouldn't consider the spec complete until this gets addressed.

rustamk: Application developers would love this.

markw: I'm not confident about saying we'll delay the spec more than its been delayed already to add this.

paulc: My assumption is that this would be added as a separate deliverable.

markw: That would make sense to me.

MarkVickers: Once we allow the API with these messages being opaque, it will be hard to cliimb out.
... People will need time to implement this, and waiting for the CDM exchange spec would be okay.

paulc: I will check whether this is in scope (in next week). Agreed?

joesteele: Fine with me. I will make a JSON version so we can look at that.

MarkVickers: We might want a face-to-face on this specific topic.

Automatically publishing to TR space.

paulc: We've already done this for HTML 5.1. It only works under process 2014.
... The tools automatically generate the status of the document. Moving EME to the new process makes sense to me.
... If we are in LC/CR (named as one state), we don't have to move forward and back to take changes.

<paulc> ACTION: paulc to do a HTML WG CfC to move EME to Process 2014 and to move it to be published automatically to TR space for each Editor's draft commit [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action06]

<trackbot> Created ACTION-89 - Do a html wg cfc to move eme to process 2014 and to move it to be published automatically to tr space for each editor's draft commit [on Paul Cotton - due 2015-04-23].

Permanent home for EME and MSE Registries

paulc: We had an issue when we published the recent heartbeat versions for MSE and EME.
... Even though these registries have "must" in them, they are informative and not normative. Informative specs aren't allowed in TR space.
... Proposal is serve these specs in non-TR space on www.w3.org.
... This is ready to execute on the next heartbeat publication.

Plan for addressing interop/segmentation bugs

<paulc> Bug 20944 - EME should do more to encourage/ensure CDM-level interop

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

<paulc> EME Formal Objection: http://dev.w3.org/html5/status/formal-objection-status.html

<paulc> ACTION: paulc to update Bug 20944 if the TF goes ahead with work on generic license request/response protocol [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action07]

<trackbot> Created ACTION-90 - Update bug 20944 if the tf goes ahead with work on generic license request/response protocol [on Paul Cotton - due 2015-04-23].

What is the definition of independent interoperable implementions for EME?

<paulc> See http://www.w3.org/2014/Process-20140801/#implementation-experience

ddorwin: We need to make a proposal on what it means to prove interoperability on these features.

<paulc> This is done by the TF deciding (with the WG) on what the CR exit criteria are.

ddorwin: I would propose we need two different browsers with two different systems that are used.
... Leaves open what we do to each to prove they are interoperable.

paulc: When we go before the director, we will be expected to have decided features at risk, and what the actual exit criteria are.
... We could raise the min bar if we want.
... And could require complete processing of some amount of human viewable content.
... Typically working groups don't worry about this until they get their bug count lower than ours.

markw: Assuming we don't have the common protocol, the best we can do is have test pages, completely common code with no switches based on the browser, and use backend servers to do key system specific things.

ddorwin: We might need the DRM providers to stand up a permanent URL to support testing.

markw: It can't be hard coded.

ddorwin: DRM companies can help once we determine what we need.

paulc: The earlier we start on this, the better. If Mark's right, that we need a interop page coded and running, it would be good to start building this soon.
... Could someone do this now?

markw: The issue is that browsers aren't ready for interoperablility testing yet. They might be soon.

paulc: Can it be done at a very basic level?

<paulc> ACTION: rustamk to ask Cable labs about their current EME testing and whether they can expose it to the TF [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action08]

<trackbot> Error finding 'rustamk'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

ddorwin: RequestKeySystemAccess would at least need to be supported, and Chrome is the only browser shipping with it now.

<paulc> ACTION: paulc (really rustamk) to ask Cable labs about their current EME testing and whether they can expose it to the TF [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action09]

<trackbot> Created ACTION-91 - (really rustamk) to ask cable labs about their current eme testing and whether they can expose it to the tf [on Paul Cotton - due 2015-04-23].

Tests - Should we use MSE rather than .src= for spec tests?

ddorwin: All deployed uses of EME use MSE, so having tests in MSE could be reasonable.
... There could be some objections to it.

MattWolenetz: If you have some src= implementations.

markw: On any implementation (EME or src=), you'd need at least two implementors.

paulc: Some groups require more, and say a great number support a specific set of features or uses.

ddorwin: My question is partly practical. Want to make sure tests we contribute are going in the right direction.

paulc: I'd be fine talking to the Director about a specific set of content we require in testing.

title: Telecon frequency & agenda

ddorwin: Let's have a wiki like the face-to-face one and use it to communicate topics to you in advance of the scheduled calls.

<paulc> ACTION: paulc to build a generic wiki agenda for future TF meetings [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action10]

<trackbot> Created ACTION-92 - Build a generic wiki agenda for future tf meetings [on Paul Cotton - due 2015-04-23].

paulc: What did you mean by frequency?

ddorwin: Perhaps we shouldn't hold the call if there's not enough of an agenda.

paulc: Holding the call regularly can help drive progress.

rrsagent: generate minutes

<paulc> Meeting adjourned at 17:00 PT

Summary of Action Items

[NEW] ACTION: ddorwin to send an update on Bug 27269 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action02]
[NEW] ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action03]
[NEW] ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action04]
[NEW] ACTION: markw to provide additional technical recommendations for persistent-release-message based on implementation experience [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action01]
[NEW] ACTION: paulc (really rustamk) to ask Cable labs about their current EME testing and whether they can expose it to the TF [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action09]
[NEW] ACTION: paulc to build a generic wiki agenda for future TF meetings [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action10]
[NEW] ACTION: paulc to check on whether the proposed generic license request/response protocol is in scope of the current HTML WG charter [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action05]
[NEW] ACTION: paulc to do a HTML WG CfC to move EME to Process 2014 and to move it to be published automatically to TR space for each Editor's draft commit [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action06]
[NEW] ACTION: paulc to update Bug 20944 if the TF goes ahead with work on generic license request/response protocol [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action07]
[NEW] ACTION: rustamk to ask Cable labs about their current EME testing and whether they can expose it to the TF [recorded in http://www.w3.org/2015/04/16-html-media-minutes.html#action08]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/04/17 00:05:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/godo/good/
FAILED: s/conencus/consensus/
FAILED: s/does not occur i the/does not occur in the/
FAILED: s/of W3C spec for/of W3C specs for/
FAILED: s/\@\@1:/cwilso:/
FAILED: s/Mixed COntent UX/Mixed Content UX/
FAILED: s/reocmmendations/recommendations/
FAILED: s/don;t/don't/
FAILED: s/concensus, if you insist upno/consensus, if you insist upon/
FAILED: s/and want a sanity/and we want a sanity/
Succeeded: s/.../paulc/
FAILED: s/assuem/assume/
FAILED: s/usuauly/usually/
FAILED: s/mentioend/mentioned/
Succeeded: s/priviledged/privileged/
Succeeded: s/ecnryption/encryption/
Succeeded: s/.. . 2nd/... 2nd/
Succeeded: s/communcation/communication/
Succeeded: s/BobLund: against it/BobLund: CablesLabs, against it/
Succeeded: s/CablesLabs/CableLabs/
Succeeded: s/Quick/QUIC/
Succeeded: s/@@@2/distinct/
Succeeded: s/for issue 45/for Bug 26332/
Succeeded: s/4. Block/5. Block/
WARNING: No scribe lines found matching ScribeNick pattern: <Daniel> ...
Found ScribeNick: ddavis
Found Scribe: Daniel
Found ScribeNick: ddavis
Found Scribe: Daniel
Found ScribeNick: jdsmith
Found ScribeNick: jdsmith
ScribeNicks: ddavis, jdsmith
Default Present: +1.215.286.aaaa, +1.425.706.aabb, kyong, paulc, +1.650.275.aacc, rsleevi
Present: Paul_Cotton Glenn_Eguchi Cory_Heslip Rustam_Khashimkhodjaev Daniel_Davis Joe_Steele Mark_Vickers Jeremy_LaCivita Sahil Mark_Watson Matthew Wolenetz David_Dorwin Chris_Wilson Jerry_Smith
Got date from IRC log name: 16 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/16-html-media-minutes.html
People with action items: ddorwin joesteele markw paulc really rustamk

[End of scribe.perl diagnostic output]