00:00:14 Last report on CR testing status: http://lists.w3.org/Archives/Public/public-html-media/2014Dec/0012.html 00:00:28 MikeSmith: Are you here? 00:00:38 where is here? 00:01:09 there's no zakim as far as I can see 00:01:23 See https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#IRC_and_Teleconference_facilities 00:01:25 how do I phone in 00:01:28 ok 00:01:51 Call +1.617.761.6200, conference 63342 ("media") 00:03:15 rustamk has joined #html-media 00:03:46 "the conference is restricted at this time" 00:03:59 scribenick: ddavis 00:04:47 maybe somebody can Skype me in 00:05:01 or better, https://appear.in/sideshowbarker 00:05:11 We are in a large room with good audio. 00:05:25 Too bad you cannot join. Maybe the call time was only to 5pm PT? 00:05:41 dunno 00:06:43 Mike, trying appear.in - can you see/hear me? 00:09:19 rrsagent, generate the minutes 00:09:19 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html paulc_ 00:09:32 scribe: Daniel 00:09:55 Topic: [MSE] Plan for getting MSE out of CR 00:10:00 CR testing status from Jan 2015: http://lists.w3.org/Archives/Public/public-html-media/2014Dec/0012.html 00:10:26 paulc_: We had a discussion at TPAC last year about MSE testing. 00:10:45 ... What happened is that Cyril took an action item on CR testing to add to the existing test suite. 00:11:02 s/godo/good/ 00:11:04 ... The above link is his report from December. Since then he hasn't been able to make further progress. 00:11:26 s/conencus/consensus/ 00:11:33 ... So we've made a small amount of progress since Halloween. 00:11:51 s/does not occur i the/does not occur in the/ 00:11:52 ... The first topic is how to break out of this conundrum. We only have two editors. 00:12:10 s/of W3C spec for/of W3C specs for/ 00:12:10 ... We have bugs to deal with, we have a dependency on streams and we also need to figure out testing for MSE. 00:12:28 ... I've been talking to the W3C team to say we don't have the resources from Members. 00:13:09 ... Do you have any thing to update? 00:13:15 MikeSmith, can you hear us? 00:13:31 i csn hear you 00:13:42 MikeSmith, we can't hear you. 00:13:51 s/\@\@1:/cwilso:/ 00:13:57 I'll reload the page. 00:14:27 Hi 00:14:32 s/Mixed COntent UX/Mixed Content UX/ 00:14:43 theapp has me muted locally 00:15:06 hoedy 00:15:30 rrsagent, draft minutes 00:15:30 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 00:15:39 MikeSmith, can't hear you again. 00:16:28 s/reocmmendations/recommendations/ 00:16:30 rrsagent, draft minutes 00:16:30 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 00:16:31 MikeSmith, shall we try Skype instead? 00:16:47 s/don;t/don't/ 00:16:49 rrsagent, draft minutes 00:16:49 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 00:17:42 paulc_: Have you had any chance to look at MSE testing? 00:18:03 MikeSmith: No, because that's a key part and requires a significant amount of time. I'm hoping I personally won't have to. 00:18:15 s/concensus, if you insist upno/consensus, if you insist upon/ 00:18:17 paulc_: I'm sceptical about whether I'll have people here to help. 00:18:18 rrsagent, draft minutes 00:18:18 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 00:18:39 MikeSmith: We need to plan for success! 00:19:04 paulc_: I'd like to find out who's interested in moving this forward. 00:19:17 MattWolenetz: I'm interested in pushing this forward. 00:19:44 paulc_: Matt is one of the new editors from Google replacing Aaron. 00:19:54 ... He's interested in helping. 00:20:01 MikeSmith, can you hear us? 00:20:18 No, but following along on IRC 00:20:34 So please just keep going fire now 00:20:36 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. 00:20:49 ... Is that something that you (Jerry) have time to work on? 00:20:57 s/and want a sanity/and we want a sanity/ 00:20:57 s/.../paulc/ 00:21:20 s/assuem/assume/ 00:21:27 Jerry: Not had the time in the past but it's a priority, although a challenge. 00:21:44 s/usuauly/usually/ 00:21:45 paulc_: Anyone else willing to help with this? 00:22:01 ... If we're going to get this done, the people in this room (or your companies) have to help. 00:22:23 joesteele: I can ask internally but I can't promise - we're going to implement a player. 00:22:24 ericde has joined #html-media 00:22:37 paulc: We can get a small team together and have an ad-hoc meeting. 00:22:47 ... I don't think it's worthwhile convening a large group. 00:22:56 s/mentioend/mentioned/ 00:23:05 rrsagent, draft minutes 00:23:05 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 00:23:06 ... Maybe Jerry, Adobe, Mike, to figure out what the next steps are 00:23:21 q+ 00:23:28 ... then go back to the Task Force to see where we can go from there. 00:23:50 MikeSmith: I want to explain the work that needs to be done. 00:23:57 paulc has joined #html-media 00:24:12 ... We have our test suite and a process for getting tests into that suite through submitting PRs. 00:24:44 MikeSmith, you've dropped out again - we can't hear you. 00:26:17 MikeSmith, can you hear us? 00:28:29 hang on 00:29:56 MikeSmith: Along with submitting PRs, we need someone to review those tests. 00:30:07 ... Those people need to be familiar enough with the spec. 00:30:39 ... For the actual writing of the tests, one possibility is to contract with an external test-writing company. 00:30:48 ... We've done that for some tests in the past. 00:31:10 ... The quality level was good, there in the test suite (for non-MSE tests). 00:31:27 ... If that's the approach we take, we have to speak to the Google people to get their feedback. 00:31:34 ... That costs money of course. 00:31:43 ... The next part is we still need someone to review. 00:32:00 ... It's possible to outsource that but I think we should have someone committed to do the review. 00:32:22 ... That's at least as much work because someone has to evaluate the tests. 00:32:42 ... I wanted to put on the table the option of paying for the remaining tests to be done. 00:32:50 ... Some have already been done - they're done. 00:33:01 ... The work that needs to be done is analysing the current coverage. 00:33:08 paulc_: Did someone do that already? 00:33:17 MattWolenetz: Cyril had already done that. 00:33:40 ... Since then, internally we've added to those tests since last summer. 00:34:20 ... The hope was that while Google was contributing those tests, we could get some help from other browser implementers. 00:34:37 MikeSmith: We know that Mozilla is trying to implement this. 00:35:02 ... 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. 00:35:22 ... Part of the reason for having these tests is so that other implementers can have tests to work against. 00:35:48 ... The purpose of the tests is not just to get through our exit criteria, they're to make sure we have interoperability. 00:36:15 ... The level of commitment we have to that is the level of commitment we have to interoperability. 00:36:24 paulc_: We don't regularly see Mozilla here at all. 00:36:35 ... To fix that, should I go to David Baron? 00:36:42 MikeSmith: Yes, or Chris Pearce. 00:36:50 ... He's busy implementing it. 00:37:14 ... He may be too busy to come back to the WG. 00:37:23 joesteele: The time difference is a problem too. 00:37:33 paulc_: We can fix that and arrange an ad-hoc meeting. 00:37:51 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? 00:37:54 ... These issues are important so if we have to adjust our meeting times then maybe that's what we need to do. 00:38:17 MikeSmith: The people who feel the most pain at the moment are Mozilla and they can help us the most right now. 00:38:31 ... I can help with reaching out to the them. 00:39:01 paulc: Do they're problems link to the need for sample files in the test suite? 00:39:09 MikeSmith: I don't know. 00:39:19 joesteele: I've heard that. 00:39:50 pangu has joined #html-media 00:40:10 MikeSmith: To answer MarkVickers, the latter - they could only get their implementation to work with Netflix and YouTube. 00:40:16 ... but this is just hearsay. 00:40:40 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. 00:40:59 MikeSmith: I want to help with the spec because I think it's important and underutilized. 00:41:08 ... I'm also being pushed to get this done. 00:41:38 ... I'd be happy to work with Matthew and we all know each other. 00:42:01 paulc: So let's get the coverage work that Cyril did, reach out to Mozilla and find out the problems they're having. 00:42:24 ... 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. 00:43:26 ... I'll talk to Matt and Jerry and we'll figure out our go-forward plan. 00:43:41 MikeSmith: Good, please keep me in the loop. 00:44:03 rustamk has joined #html-media 00:44:39 paulc: Meeting adjourned. See you tomorrow at 9am. 00:44:57 paulc: Please get here just before 9am so we can start on time. 00:45:54 rrsagent, generate the minutes 00:45:54 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html paulc 00:46:39 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 00:46:45 rrsagent, generate minutes 00:46:45 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html ddavis 01:04:31 chaals has joined #html-media 01:27:35 rustamk has joined #html-media 01:29:43 rustamk has joined #html-media 01:55:36 rustamk has joined #html-media 02:41:38 ddorwin has joined #html-media 16:13:32 RRSAgent has joined #html-media 16:13:32 logging to http://www.w3.org/2015/04/16-html-media-irc 16:16:05 ddorwin has joined #html-media 16:16:46 chaals has joined #html-media 16:17:09 jlacivita has joined #html-media 16:19:03 topic: Bug 27269 about partitioning identifiers and data by top-level *and* EME-using origin 16:19:15 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269 16:19:59 ddavis has joined #html-media 16:20:18 topic: Bug 26332 Secure origin requirement. 16:20:19 https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/edit?usp=sharing 16:20:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 16:20:40 markw: this is what the spec says today 16:20:53 ... if you are on secure origin do this -- if not -- big gap 16:21:01 cheslip has joined #html-media 16:21:31 ... proposal is cut and paste largely from the priviledged context document 16:21:51 ... if you are not on a secure origin, the media key system should reject access 16:22:12 Where did the text come from? 16:22:13 s/priviledged/privileged/ 16:22:14 Proposed text for checking secure origin is taken from https://w3c.github.io/webappsec/specs/powerfulfeatures/#new 16:22:53 Incumbent settings object: http://www.w3.org/TR/html5/webappapis.html#incumbent-settings-object 16:22:57 jeremy: yesterday we were talking about "in the future" -- what is the range CR implies? 16:23:30 paulc: this doc is in working draft stage, Last Call is next, usually feature complete by then 16:23:40 .... working groups decision on when to exit 16:23:51 ... then comes call for implementations 16:24:16 ... Last Call will probably takes 6 weeks with written comments on the spec 16:24:30 ... then go into CR (Candidate Recommendation) 16:24:49 markw: different ways to do it, but should be a small number of months to get to Last Call 16:25:04 ... once in CR we will be there until test, interoperable implementations, etc are all done 16:25:12 ... potentially quite long 16:25:22 ... this could actually be the long pole 16:25:35 ... if implementations in the field still require HTTP 16:25:47 ... this gives us a clear goal and a process for getting there 16:25:58 ... without setting a date 16:26:12 ddorwin: this makes sense, we have to have the tests before exiting CR 16:26:29 paulc: would we put an informative reference? 16:26:36 markw: there would be a normative reference 16:26:51 ddorwin: we need to fix that line, but everyone knows that 16:27:03 paulc: where is that text? 16:27:09 ddorwin: section 3.1.1 16:27:23 http://www.w3.org/TR/encrypted-media/#methods 16:27:36 rrsagent, draft minutes 16:27:36 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 16:27:42 https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/edit?usp=sharing 16:27:46 paulc: we have a proposal on the table -- any changes 16:28:17 ddorwin: this is a slightly different approach to the same thing 16:28:28 ... first two lines are unchanged and must be changed to match the other spec 16:28:55 ... this allows us to keep the final step, and then reject of secure origin is not presnt 16:29:09 ... last box is the text about well behaved implementations regardless of secure origins 16:29:18 ... copied Marks comments about CR in the 2nd box 16:29:58 ... next slide -- 3rd algorithm in the process -- DEPRECATED, indicates what is not allowed 16:30:15 markw: this is then essentially saying the same thing then? with different words? 16:30:20 ddorwin: yes 16:30:23 sahil has joined #html-media 16:30:32 paulc: this text looks more robust and is easier to modify 16:31:13 markw: if there were any other conditions to add, this could be done with David text 16:31:18 ddorwin: for better or worse 16:31:24 jdsmith has joined #html-media 16:31:36 MarkVickers has joined #html-media 16:31:37 q? 16:31:37 Zakim, who is here? 16:31:39 sorry, joesteele, I don't know what conference this is 16:31:39 On IRC I see MarkVickers, jdsmith, sahil, cheslip, ddavis, jlacivita, chaals, ddorwin, RRSAgent, Zakim, markw, MattWolenetz, joesteele, BobLund, paulc, rustamk_, MikeSmith, cwilso, 16:31:39 ... trackbot, adrianba 16:31:44 q+ 16:32:02 ack MarkV 16:32:26 MarkVickers: I think we are making a mistake here -- want to make a fundamental point 16:32:36 ... we saw a bunch of data presented yesterday 16:32:51 ... I will grant that is all true, HTTPS everywhere is coming 16:33:03 ... folks are gathering a list of where it is needed for privacy for example 16:33:24 ddorwin: these are well understood 16:33:37 MarkVickers: I don;t think this one is well understood 16:34:00 ... 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 16:34:41 ddorwin: are you saying the reasons for HTTPS are well understood? the specs that should have HTTPS are being collected 16:34:58 MarkVickers: one example is protecting the content of URLs which is visible otherwise 16:35:18 ... 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 16:35:30 ... nothing MSE does inherently makes it need HTTPS 16:35:43 ... I would argue EME also should not be on that list 16:35:52 rustamk has joined #html-media 16:35:57 ... it really adds a communcation channel down to the CDM up through user space 16:36:18 ... the information passed up can have private data that needs to be protected -- that is granted 16:36:35 ... however if we imagine that the data is not protected, ie in the clear into user space 16:36:44 ... HTTPS does not solve that problem 16:37:00 ... passing the data in the clear into user space, already cause the problem 16:37:30 ... 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 16:38:02 ... also advertising companies could setup a site with video, just to give them access to the tracking data coming through the CDM 16:38:27 ... 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 16:38:44 ... basically HTTPS does not solve this problem. It must be encrypted before it comes up. 16:38:53 chaals: Janina wants to join the A11Y meeting see http://lists.w3.org/Archives/Public/public-html-a11y/2015Apr/0042.html 16:39:04 ... there must be some secure are where that private data is, and before it comes into user space it must be encrypted already. 16:39:13 ... when that happens HTTPS is not adding anything 16:39:32 ... long list of reasons to do HTTPS which have nothing to do with this, but in this case it does not help 16:39:41 ... it is a terrible solution for this problem 16:39:52 ... other ways of solving the problem, do a blacbox test 16:40:01 .... look at the data coming back form the CDM 16:40:27 .. . 2nd could have a 3rd party that qualifies the CDMs, might be a W3C requirement even 16:40:29 Identifiers must be encrypted: https://w3c.github.io/encrypted-media/#encrypt-identifiers 16:40:37 ... 3rd you can have a contrac, this gives you a legal edge 16:40:41 rrsagent, generate the minutes 16:40:41 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html paulc 16:40:49 ... 4th you can have a bilateral arrangement for the UA to look at the code 16:40:49 q+ 16:40:55 q+ markw 16:40:57 q+ 16:41:01 ... that is the only thing you have to do 16:41:12 ack dd 16:41:27 ddorwin: the first two points argue for no security on the web platform, because an extension or virus could access the data 16:41:44 ... other comments were about contracts, registry which are outside the scope of this spec 16:41:49 rrsagent, draft minutes 16:41:49 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 16:42:02 zakim, what code is this? 16:42:02 I don't understand your question, ddavis. 16:42:16 zakim, what call is this? 16:42:16 I don't understand your question, ddavis. 16:42:35 Kyong has joined #html-media 16:42:42 ddorwin: so extensions can do anything include making their own identifiers 16:42:48 pangu has joined #html-media 16:43:23 zakim, what room is this? 16:43:23 I don't understand your question, ddavis. 16:43:27 kyong, you can dial in now 16:43:34 zakim, this is 63342 16:43:34 ok, ddavis; that matches HTML_WG(MEDIA)12:00PM 16:44:03 zakim, who is here? 16:44:03 On the phone I see +1.215.286.aaaa, +1.425.706.aabb 16:44:05 On IRC I see pangu, Kyong, rustamk, MarkVickers, jdsmith, sahil, cheslip, ddavis, jlacivita, chaals, ddorwin, RRSAgent, Zakim, markw, MattWolenetz, joesteele, BobLund, paulc, 16:44:05 ... MikeSmith, cwilso, trackbot, adrianba 16:44:30 Hi 16:44:31 zakim, aaaa is kyong 16:44:31 +kyong; got it 16:44:32 Kyong: this is Kyong Park from Comcats, Director of Security, taking care of compliance and ecnryption issues, robustness 16:44:45 s/ecnryption/encryption/ 16:44:53 rrsagent, draft minutes 16:44:53 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 16:45:11 MarkVickers: 16:46:26 Thanks to Joe and Daniel for scribing the meeting so far. 16:46:36 s/.. . 2nd/... 2nd/ 16:46:39 rrsagent, draft minutes 16:46:39 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 16:47:28 ddorwin: generally this in not intened to push the HTTPS everywhere initiative, this is just for EME 16:47:39 ... encrypted idenfitiers is required by the spec 16:47:48 ... you are not off the hook by requiring HTTPS 16:48:00 ... identifiers are one concern but not the only one 16:48:16 ... providing access to un-sandboxed CDMs (running as root) is another 16:48:37 ... don;t want to allow MiTM attacks especially with unsandboxed CMDs 16:48:59 ... if you have an extension you can write anything you want into the page, they are dangerous and come with warnings 16:49:07 ... they are outside the scope of this 16:49:38 ... doesn't make the general goodness that comes with HTTPS go away 16:49:42 ack dd 16:50:12 ack markw 16:50:17 queue+ 16:50:19 markw: I had a 3rd slide that addresses this topic 16:50:29 q? 16:50:29 ... we did not get to that 16:50:43 See https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/edit#slide=id.g76d7a3737_0_34 16:50:58 ... we discussed defense in depth yesterday 16:51:08 Correct link: https://docs.google.com/presentation/d/18uM0Cijk_MI3op8VAa6MM6LIWtQGJ5WXjTHPmqyLa5g/view#slide=id.g76d7a3737_0_51 16:51:28 ... MarkVs concern was also one of my concerns ... that HTTPS should not be considered to mitigate CDMs which are bad actors 16:51:41 ... CDMs should be safe and UAs should ensure CDMs are safe 16:52:01 q+ 16:52:14 ... because you are passing opaque data to the UA that cannot always be verified, we have some text that says it must be verified 16:52:32 ... we should remove the text that says you can mititgate thes problems with HTTPS 16:52:51 ack Ky 16:52:52 ... what we are left with as a justification is the defense in the depth argument -- not very strong but ok 16:53:10 Kyong: my issue with the solution is the implications to the problem statement 16:53:17 q+ (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 if those CDMs are not safe, however. 16:53:30 q+ 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 if those CDMs are not safe, however. 16:53:36 ... when protected identifiers are passed between the CDM and license servers, I would anticipate a stragtegy that covers the ntire problem 16:53:44 ... TLS only covers part of the problem 16:53:57 q+ 16:53:59 ... and introduces things that have nothing to do with that problem 16:54:07 ack dd 16:54:39 ddorwin: the secure origin is required as well because that forces scripts to also be from the secure origin, general protection against other origins 16:55:08 ... 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 16:55:14 zakim, who is on the phone 16:55:14 I don't understand 'who is on the phone', paulc 16:55:24 zakim, who is on the phone? 16:55:24 On the phone I see kyong, +1.425.706.aabb 16:55:28 ... reiterate that the reason is not to protect th identifiers in transit, there are other concerns 16:55:51 ... e.g. if a UA had other permissions-type protections, without TLS you could not enforce such restrictions 16:55:52 q+ 16:56:15 ack cw 16:56:15 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 16:56:19 ... if those CDMs are not safe, however. 16:56:22 no I am not. 16:56:29 joesteele: agreed 16:56:58 I can be q-, just wanted that statement made 16:57:18 (i.e. "defense in depth" is more than just a joke about me trusting no one. ;) 16:57:19 zakim, aabb is paulc 16:57:19 +paulc; got it 16:57:26 ack markV 16:58:14 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 16:58:29 ... think we are agreed on that CDMs must do the right thing 16:59:25 ... 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. 16:59:46 ... in the CDM case folks are not thinking about that, so that means it must be encrytped. It happens automatically. 17:00:12 q+ 17:00:33 ... 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. 17:01:19 EME is unique in that it relies on passing opaque blobs to an undefined (and often unsandboxed) entity. 17:01:20 ... 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. 17:01:28 rrsagent, draft minutes 17:01:28 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 17:01:30 ack Kyong 17:02:11 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. 17:02:24 ... should be the case that the solution covers the entire problem 17:02:28 Kyong, I encourage you to read https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 17:02:46 q+ 17:02:50 rrsagent, this call spans midnight 17:02:50 I'm logging. I don't understand 'this call spans midnight', paulc. Try /msg RRSAgent help 17:03:29 ... 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. 17:03:36 ack dd 17:03:36 ... this would increase costs significantly 17:04:23 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. 17:04:52 ... the fact is that they are often unsandboxed and running as root this is a concer 17:04:58 ... pasted a link above about this 17:05:14 All, thank you for the opportunity to participate. Will rejoin in an hour. Dropping for now. 17:05:19 -kyong 17:05:23 ... we do not take this lightly and discuss a lot internally. There are good security reasons for this, not just "HTTPS is better" 17:05:23 ack markw 17:06:15 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. 17:06:32 ... there is something to that and HTTPS might cover that slight difference there. 17:06:41 q+ 17:06:55 ... in order to get companies to move though, there needs to be a larger process not just the folks in this room. 17:07:03 rrsagent, this meeting spans midnight 17:07:08 ... need the browsers vendors, site operators, etc together to discuss this 17:07:19 ... we have made good progress so far 17:07:29 ack MarkV 17:07:41 MarkVickers: think there is lot of agreement here 17:07:58 ... what David said about EME being different from MSE, totally agree with 17:08:12 ... problem that we do not have an open source DRM 17:08:20 ddavis: Thanks for the rrsagent command 17:08:32 ... but HTTPS is not solving that problem (sandboxing on the client) 17:08:47 q+ 17:08:58 ... this is specifically talking about HTTPS which is just covering the communcation to the server 17:09:09 s/communcation/communication/ 17:09:26 ... the unique problem of EME with the key messages is not helped by HTTPS 17:09:51 ... agree there are other issues, but HTTPS does not address these 17:10:23 q? 17:10:34 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. 17:10:36 ddorwin: think there is misunderstanding about what HTTPS provides 17:10:50 ... it also provides authentication of the source of the request 17:11:06 ... we know that the requester is who they say they are, so MITM cannot make requests 17:11:16 ... or introduce vulns 17:11:30 ... WebGL also talks to hardware directly, but they are well-formed and sanitized 17:11:36 ... we cannot do that with EME 17:11:45 ... would like to be able to do that but not yet 17:11:46 ack dd 17:12:02 MarkVickers: I hear and understand that point 17:12:21 paulc: we have a proposal on the table, are you against that proposal MarkV? 17:13:07 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. 17:13:29 ... I will take my cue from Kyong then 17:13:55 paulc: straw poll 17:15:14 ... this will be a straw poll on Davids proposal -- slightly more robust and easier to modify 17:15:41 Proposal: https://docs.google.com/presentation/d/1V4D36-Zd1XvJMwZjepGs9lSxygy_7AwkQtSP0_ymlP4/preview 17:15:45 plh has joined #html-media 17:15:56 ... for, against, can live with 17:16:15 ... this will be David's proposal with MarkW 3rd slides added 17:16:38 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) 17:17:11 rustamk: Comcast, against this 17:17:37 ddavis: W3C, for the proposal 17:18:03 joesteele: Adobe, can live with it 17:18:13 BobLund: against it 17:18:58 s/BobLund: against it/BobLund: CablesLabs, against it/ 17:19:13 s/CablesLabs/CableLabs/ 17:19:16 MarkVickers: Comcast, we will live with it, but against 17:19:40 markw: Netflix, for 17:19:45 ddorwin: Google, for it 17:19:51 jdsmith: Microsoft, for it 17:20:46 rrsagent,draft minutes 17:20:46 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 17:20:55 paulc: don't think we have consensus yet 17:21:23 q+ Will Comcast and Cable Labs formally object to this requirement? 17:21:51 Staw poll result - For: 4; Can live with: 1; Against: 2 17:22:00 paulc: heard one new thing, that this would have other disadvantages 17:22:16 MarkVickers: yes, but Kyong would have to go over that 17:22:26 ... I agree with most of this 17:22:44 ... my only concern is that it will be made mandatory 17:23:17 ericde has joined #html-media 17:23:28 markw: that would be my question, if this was SHOULD could we agree with it 17:23:32 ... ? 17:24:05 paulc: are you proposing we take this note out and then do the straw poll again? 17:24:38 markw; think we should add a requirement that whether it will turn from SHOULD to MUST is an open issue 17:24:42 ... don't want to just remove it 17:25:24 q+ 17:25:32 ddorwin: all we are saying is that long term this will change, there is no time line 17:25:40 q+ 17:25:42 q+ 17:26:10 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 17:26:42 ... could do the straw poll wider -- might have more of a spread in the numbers 17:26:59 ... we have the smart folks in the room that should let us get to text 17:27:38 MarkVickers: I could list the things that need to change 17:27:43 ... that secnd bullet 17:28:01 ... Mark had some recommendations yesterday that should be made mandatory 17:28:05 markw: link is in the IRC 17:28:22 BobLund: David, was your note made to capture that as well? 17:28:38 ddorwin: yes, but I expect to go through a iterate more on that piece 17:28:52 paulc: should we have a coffee break and discuss offline? 17:29:24 ddorwin: we will be at CR? will they formally object? they said they will live with it 17:30:00 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 17:30:14 ... folks need to include that in their costs 17:30:36 ... but folks don't want to put a stake in the ground when they don't have the data to support those plans 17:30:45 ... we need to fit the language to the gap 17:31:08 paulc: lets look at the proposed text. 17:31:30 q+ 17:31:34 ... What if it said -- it is expected that this requirement will be evaluated at CR? 17:32:06 MarkVickers: one issue is timing related, but it is more generic where it could be something other than HTTPS that meets the same goals 17:32:49 ... 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. 17:32:51 q+ 17:33:10 BobLund: The problem is that getting a certificate for LAN devices is hard 17:33:25 ddorwin: there is another WG working on how to define this 17:33:38 ... this is why it is hard to discuss this we don't have the right words 17:34:07 ... we may not need a PKI for example, if we have something equivalent 17:34:34 BobLund: we can get certs that are not publicaly signed, but we don't want to have to train users that way 17:35:12 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. 17:35:55 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 17:36:23 paulc: lets take a 20min break and we should have Kyong again. 17:36:31 rrsagent, generate minutes 17:36:31 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 18:04:45 rsleevi has joined #html-media 18:05:08 q? 18:05:29 + +1.650.275.aacc 18:06:23 rustamk has joined #html-media 18:08:38 Chair: Paul 18:09:56 Meeting: HTML Media Task Force Teleconference 18:11:14 zakim, who is here? 18:11:14 On the phone I see paulc, rsleevi 18:11:16 On IRC I see rustamk, rsleevi, ericde, plh, pangu, Kyong, MarkVickers, ddavis, jlacivita, chaals, ddorwin, RRSAgent, Zakim, markw, joesteele, BobLund, paulc, MikeSmith, cwilso, 18:11:16 ... trackbot, adrianba 18:11:25 scribenick: ddavis 18:11:28 scribe: Daniel 18:11:45 cheslip has joined #html-media 18:12:33 Chair: Paul 18:12:35 Meeting: HTML Media Task Force Teleconference 18:12:50 rrsagent, generate minutes 18:12:50 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html ddavis 18:14:13 zakim,, who is here? 18:14:13 I don't understand your question, MarkVickers. 18:14:14 zakim, who is on the phone? 18:14:15 On the phone I see paulc, rsleevi 18:14:26 zakim, who is here? 18:14:26 On the phone I see paulc, rsleevi 18:14:28 On IRC I see cheslip, rustamk, rsleevi, ericde, plh, pangu, Kyong, MarkVickers, ddavis, jlacivita, chaals, ddorwin, RRSAgent, Zakim, markw, joesteele, BobLund, paulc, MikeSmith, 18:14:28 ... cwilso, trackbot, adrianba 18:14:42 Kyong: can you dial in? 18:15:28 ddorwin: Comcast is more concerned about @@@ than the CDM issue. 18:15:43 ... I have two proposals... 18:15:45 Kyong: are you there? 18:15:58 cheslip_ has joined #html-media 18:16:21 ... 1) Instead of expected to be mandatory will be re-evaluated. 18:16:47 ... We want to avoid readers of the spec to implement it and then have to redo it soon after. 18:17:03 ... We should be clear about what the long term plan is and that this is actually going to happen. 18:17:09 MattWolenetz has joined #html-media 18:17:14 ... I worry about delaying this and being not clear. 18:17:23 ... One concern is the timeline. 18:17:51 ... 2) The home network case, to add an issue box about how it should be enforced/how it works on internal networks. 18:18:12 ... I offered to find out what's going on and we can reference that from the issue box. 18:18:21 ... We should be clear about that and the known concerns. 18:18:45 paulc: [Typing a proposed change to ddorwin's proposal] 18:19:33 +kyong 18:19:56 paulc: Proposed change: "It is expected that the removal of this step will be evaluated during CR". 18:21:21 paulc: 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". 18:21:44 MarkVickers: We had a further discussion and summarized what are Comcast's three issues. 18:22:06 ... 1) Making our network/CDNs efficient for sending video securely, similar to Netflix's issue. 18:22:34 ... 2) With LAN devices (gateways, STBs) to be secure end points and a certificate issue. 18:23:05 ... 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. 18:23:48 ... 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. 18:24:53 ... 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. 18:25:06 ... We can work with them for a solution to privileged context in a LAN. 18:25:13 ... Are you OK with those two? 18:25:18 Kyong: Yes, I think so. 18:25:53 MarkVickers: I'd like you to address your concerns that our discussions are making things difficult. 18:26:35 Kyong: Every device that interacts with our service/content we track devices so we can understand whether a device has access to certain data. 18:27:02 ... Access anywhere is predicated on being able to authenticate and get the authenticity of a client. 18:27:25 ... We end up negotiating session keys with each client and they can be used within app layers to protect data and authenticate clients. 18:27:35 ... This is equivalent to a TLS handshake. 18:27:52 ... We share that state across enterprise across the country. 18:28:11 ... There's a protracted sequence of steps to understand where a title can be source 18:28:33 ... Because we've already negotiated the keys we're able to use algorithms to authenticate clients and protect data. 18:28:55 ... What would be counter-productive would be to introduce a TLS handshake. 18:29:11 q+ 18:29:12 ... It's redundant to what we've already defined for our security channels. 18:29:37 ... Furthermore, the measure of security from TLS is less than what we have established by our current strategy. 18:29:44 TAG Finding HTTPS: http://www.w3.org/2001/tag/doc/web-https 18:29:49 ... In other words, we're added overhead unnecessarily. 18:30:03 ... This would create additional latency while not added security. 18:30:21 ... It would mean we've lost the right to choose the security for our infrastructure. 18:30:45 MarkVickers: So right now they're not referring to HTTPS/TLS - they referring more generically to privileged contexts. 18:30:55 ... Does what you're doing qualify as privileged context? 18:31:16 ... Also are you building the security using web browser tools or just for custom clients? 18:31:27 Kyong: It's a question of whether clients have credentials. 18:31:47 Kyong: Provided the client has the credentials we can use that to create a secure channel and exchange keys. 18:32:11 ... 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. 18:32:36 ... Second, we should be able to use security frameworks that are not proprietary to Comcast. 18:33:11 markw: We have a similar setup with an alternative security protocol using JavaScript. 18:33:41 http://techblog.netflix.com/2014/10/message-security-layer-modern-take-on.html 18:33:47 ... 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. 18:34:05 ... It doesn't mean that new tech can't be used in future. 18:34:34 ... Anybody can go to the security groups to standardize their technology. Particularly for the LAN case that's what's going to be necessary. 18:34:51 ... I don't think it should be a reason to influence our approach to EME. 18:35:21 ... The security has to be implemented in the browser in order for the browser to tell the user that it's secure. 18:36:26 q+ 18:36:27 Kyong: One of the security effects is a secure channel between a CDM and exit point. 18:36:49 markw: Once you have a green padlock in the browser all other communication from that page has to be secure. 18:37:10 ... It would be nice if there were other security protocols but there's a lot of work to get that to happen. 18:37:21 ... It's not something that's excluded from future discussion. 18:37:45 q- 18:37:48 q- 18:37:53 q- 18:38:00 ack dd 18:38:05 sahil has joined #html-media 18:38:26 ddorwin: The only thing browsers know is what they can enforce which is currently TLS or privileged context (e.g. local network maybe). 18:38:49 ... If you want the green padlock, you must be on a secure page and your communications must be secure. 18:38:52 q+ 18:39:13 ... 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. 18:39:42 paulc: I believe our minutes reflect we have proposal to change the text. Is that enough of a change to get consensus? 18:39:53 paulc: Proposed change: "It is expected that the removal of this step will be evaluated during CR". 18:40:03 paulc: 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". 18:40:19 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 18:40:55 paulc: What we're saying is that the note saying this is deprecated also says "It is expected that..." (proposed change #1 above). 18:41:12 ... In particular, it's common that when we have a problem in the text we use an ISSUE box. 18:41:36 ... Around the proposed change we'd have an issue box pointing to the bug. 18:41:42 q+ 18:41:46 -q 18:41:59 ... Once that bug has been filed. 18:42:01 The privileged context language addresses my issue 18:42:05 ack MarkV 18:42:13 MarkVickers: We had three issues - the first will be solved in time. 18:42:33 ... The second issue (LAN context issue) is address by the issue box. 18:42:44 ... We could be vague on that now because we haven't seen the bug. 18:43:11 ... Kyong, do you think your third issue could be rolled in solving the privileged context for LAN issue? 18:43:21 ... Since it's about an enterprise issue. 18:43:39 ... Or do you think it's a separate issue that should have a separate bug. 18:43:48 Kyong: I don't know that it fully addresses the problem. 18:44:24 ... It seems other security measures would be permitted but that's predicated on qualifying and having a security approach that's approved. 18:44:57 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? 18:45:21 ... We can still implement that protocol on top of JavaScript but that wouldn't be enough to allow us to use EME. 18:45:30 ddorwin: Today, you're not going to get any green lock. 18:45:55 ... You're only options today are an HTTP page which doesn't change. 18:46:07 ... For the browser, any connection like this is insecure. 18:46:19 ... The importance of this is good to discuss with WebAppSec. 18:46:27 ... The browser only knows about what it does. 18:46:38 q+ 18:47:11 paulc: It seems to me that it might come down to whether Mark can get browsers to adopt his protocol or just adopt TLS. 18:47:27 ... The earlier you (Comcast) get engaged with WebAppSec the better. 18:47:34 MarkVickers: That would be addressing issue three. 18:47:44 ... Issue two isn't solved by just using TLS. 18:47:47 joesteele: and doing that would solve more than just the EME problem -- you would get the green lock for other use cases as well 18:47:53 q+ 18:48:11 paulc: Getting involved with WebAppSec is good because that's the only place to ask this kind of question. 18:48:50 ack rsl 18:48:56 rsleevi: I work with ddorwin and the Chrome team. 18:49:07 ... I'm interested in security. 18:49:14 ... I want to explain the rationale. 18:49:30 ... There's been a lot of talk about the protocol but that's not our biggest sticking point. 18:49:54 ... One aspect of intent is what does the user expect? 18:50:10 ... If they type HTTPS:// they expect to go to a secure, confidential page. 18:50:24 ... The part mixed content tries to solve is identifying the intent of the author. 18:50:48 ... If the page author says load this page over HTTP we don't know whether they intend for it to be secure or not. 18:51:00 ... Mixed content and the privileged context specs look at intent. 18:51:35 ... This is in browsers today, so e.g. Firefox will load HTTP content but say we can skip authentication, called "opportunistic encryption". 18:52:01 ... There's another protocol called Quick. 18:52:08 ... There are two parts we're concerned about. 18:52:16 s/Quick/QUIC/ 18:52:21 ... 1) When you load a page we want to make sure that's what the author intended. 18:52:45 https://www.chromium.org/quic 18:52:49 ... 2) If the user types https:// that they're given the confidentially they expect. 18:53:04 ... So with HTTP it's hard to know what the intent is. 18:53:16 ericde has joined #html-media 18:53:24 ... The scheme and the protocol are slightly @@@2 18:53:46 s/@@@2/distinct/ 18:53:51 ... If there are other protocols that offer the same confidentiality and authenticity as TLS that's a conversation for the browser vendors. 18:54:14 rsleevi: It sounds like there's some concern about how to communicate securely on a local network. 18:54:28 ... There are some solutions currently and it's an area of great focus for browsers. 18:55:03 ... Whatever device you're talking to, it's important to communicate securely on a local network, which is not inherently secure. 18:55:03 @rsleevi: can you give us some pointers to the work on secure local network communication ? 18:55:24 It's great to hear that the LAN secure endpoint issue is already an issue being worked on! 18:55:26 ... For those thinking that privileged context means TLS - that's not correct. It's supposed to be agnostic. 18:55:45 ... As long as the intent is clear, it can be done securely. 18:55:49 q? 18:56:03 paulc: That was very helpful, thank you. 18:56:10 ack Kyong 18:56:30 Kyong: It's not necessarily an issue with secure origins or that other sessions are secure. 18:56:49 ... I have no problem with maintaining security and privacy. 18:57:20 ... 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. 18:57:25 ack dd 18:57:37 ddorwin: The browsers are responsible for presenting the current state to the user. 18:57:55 ... Whatever we say in the spec, it's likely that browsers will implement this some time in the future. 18:58:08 q+ 18:58:08 ... This requirement is going to come. 18:58:10 q+ 18:58:17 ... Hopefully we can solve the internal network thing. 18:58:29 ack Kyong 18:58:34 ... Regardless of what it says in the spec it's not going to change what's going to happen in some major browsers. 18:59:09 Kyong: My understanding is out of this concern for privacy of identifiers, I don't have a problem with this. 18:59:09 -rsleevi 18:59:15 q+ 18:59:26 +rsleevi 18:59:47 ... 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. 18:59:49 ack Markv 19:00:15 MarkVickers: Out of our three issues - 1) I'm happy with the language there. 19:00:35 ... 2) Really happy hearing Ryan's information that this is already being considered an issue and being addressed. 19:01:01 ... 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. 19:01:10 ... It's a big problem that keeps coming up for us. 19:01:22 ... 3) The disagreement can be put quick succinctly. 19:01:51 ... 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. 19:02:08 ... You could build your own system into the browser. 19:02:21 ... That capability is being removed is the concern. 19:02:21 ack dd 19:02:24 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.) 19:02:45 ddorwin: The reason for the privileged context is not just to protect the identifier. 19:02:50 ... The bug goes into this. 19:03:10 ... It's about authentication and trusting from man-in-the-middle attacks. 19:03:37 MarkVickers: Kyong, I'll try to relay it to you separately. 19:03:56 paulc: It's been suggested to me to get the widest possible input on this issue, not just in this room. 19:04:20 ... So we have a change proposal. I'd like to ask the editors to put together a proposal for issue 45 and make that available widely. 19:04:36 s/for issue 45/for Bug 26332/ 19:04:37 ... Comcast need to make sure that their third issue is also included. 19:05:01 ... 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. 19:05:18 ... I don't believe we should get more consensus within the room because we still need to get wider review. 19:05:25 ... Any objections? 19:05:40 MarkVickers: Maybe we should split your proposal into two parts. 19:06:03 ... A statement like regardless if HTTPS is being used the keys should be encrypted. 19:06:14 ... and then isolate the only part that has some difference to get buy in. 19:06:46 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. 19:07:07 ddorwin: There are many changes we can make. 19:07:39 ... 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. 19:07:55 ... That note is a problem but most of my text is irrelevant without that note. 19:08:09 ... Even if we take out all the other stuff that's the message we're trying to get out. 19:08:35 jdsmith has joined #html-media 19:08:35 ... I'd like to consider that the new proposal is that we'll do this by PR. 19:08:51 ... If we leave here without a concrete plan it'll be TPAC before we solve this. 19:08:59 MarkVickers: I'm OK with that language. 19:09:08 paulc: What changes do you want to make ddorwin? 19:09:26 ddorwin: We can work on markw's proposal. 19:09:36 ... I don't want any change to your text. 19:09:55 paulc: Do I have unanimous support? 19:10:07 Yes from the participants in the room. 19:10:19 paulc: So we can resolve 26332. 19:10:37 paulc: I'll handle this by highlighting this in an email to the Task Force. 19:11:26 paulc: ddorwin, thank you to Ryan because his input was very useful. 19:11:48 -rsleevi 19:11:55 ... The subtlety that there are different requirements to satisfy the protocol is a revelation. 19:11:57 -kyong 19:12:07 rsleevi has left #html-media 19:12:12 paulc: Thank you. Lunchtime. Meeting back at 1:15pm 19:12:16 Gents, just dropped off 19:12:50 OK Kyong, we'll be back in an hour. 19:18:42 rustamk has joined #html-media 19:22:36 rustamk has joined #html-media 19:38:51 sahil has joined #html-media 19:55:21 rrsagent, make logs public 20:04:44 rustamk has joined #html-media 20:11:18 rrsagent, generate minutes 20:11:18 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html ddavis 20:12:15 MattWolenetz has joined #html-media 20:18:55 q+ 20:19:04 topic: Issue 45 20:19:06 https://github.com/w3c/encrypted-media/issues/45 20:20:44 ddorwin: Summarize issue. We are interested in solving the issue, and want to enable content. Netflix has their reasons for preferring this solution. 20:21:10 ... Issue is that access to Netflix content imposes requirements on user agents. 20:22:08 ... Current solution would fragment the web, and enable content based on whether this requirement was supported or not. 20:22:37 Rustamk: Need a secure way to know that a license has been removed from a system. 20:23:24 ...Lacking this, you run into issues determining whether a license is still valid for a system. 20:24:00 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. 20:24:34 pangu has joined #html-media 20:24:36 Rustamk: Understand that, but outside of the persistent-release-message, haven't seen a way to know that a license has been deleted. 20:24:57 ...We need a way to know that a license has been deleted from a system. 20:25:24 q+ 20:25:28 Ddorwin: Persisted licenses do that now. They persist a license on a system until you delete it. 20:25:57 Rustamk: Q: for Netflix: What's your use case for persisteed-release-message? 20:27:34 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. 20:28:48 ...using persistent-release-messages, this could be detected after the fact, and could be used to block these proxy servers. 20:29:16 q+ 20:29:17 ack joe 20:29:25 Rustank: Comcast has the same use case for stream counts and keeping track of concurrent streams. 20:29:25 ack rst 20:29:55 joesteele: Think that persistent-release-messages and persistent-licenses should work together. 20:30:16 ....release message provides an assertion from the CDM so that the license cannot be transferred to other devices. 20:30:44 ... don't think the current persistent-licenses support a secure message on license deletion. 20:31:13 ddorwin: Please everyone read the language in the spec about persisted-licenses. 20:32:18 ...concurrent stream limits are possible by other mechanisms transparent to EME. They are in the license. Release messages are also possible for persistent-licenses. 20:32:58 Please don't argue for or against something because of how long has been in the spec. 20:32:58 ... the persistent-release-message type hasn't been in the spec that long. Enum was added fairly recently. 20:33:24 ...not a preexisting feature that's had consensus support. 20:33:38 q? 20:33:46 ack rus 20:33:50 ack dd 20:34:21 rustamk: reading through editor's draft and don't see the release message for persistent-licenses. 20:35:10 ddorwin: Intent is to support release messages on persistent licenses, otherwise wouldn't be useful for use cases like content checkout. 20:35:20 https://w3c.github.io/encrypted-media/#update 20:36:48 joesteele: "If sanitized response includes a license destruction acknowledgement..." 20:37:21 ... language under "remove" describes the behavior. 20:38:25 ... step 5.2.5 defines a license release message. 20:38:28 https://w3c.github.io/encrypted-media/#remove step 5.2.5 20:39:40 q+ 20:39:53 ack markw 20:40:00 .... thought step 3 of "remove" related to persistent-release-message. 20:40:35 chaals has joined #html-media 20:40:38 markw: Can see that the messaging is pretty much the same between persistent-release-message and persistent-license. 20:40:49 q+ 20:41:06 ...difference is that persistent-release-message can work on devices that don't have a provision for persisting licenses. 20:41:11 q+ 20:41:25 ack dd 20:41:58 ddorwin: While these share the release message part, they have very different offline properties. 20:42:27 ...first of all, persistent-licenses are not supported by all clients, and there is a fallback behavior defined. 20:42:39 ...temporary is required for all and supports online playback. 20:43:06 ...persistent-licenses aren't required to access content at all, but allows offline playback as an additional experience. 20:43:56 ...persistent-license also have an explicit action to remove them from the device and create a release message. 20:44:19 ...the persistent-release-message behavior is not as explicit. 20:45:07 q+ 20:45:39 ack joe 20:45:42 ack markw 20:46:00 ...having this undefined feature in the spec isn't desirable. I think we should remove it and move on the defining alternatives. 20:46:23 markw: The feature is defined in the spec, and documents how and when release messages are sent. 20:46:42 ...I hear the concern about generating release messages for other cases (e.g. browser close). 20:47:31 ...We could describe more details about what's in the message and define behavior on how often active license information is stored. 20:47:33 q+ 20:47:48 ...That should respond to concerns about behavior on system shutdown. 20:48:04 ack dd 20:48:20 ...The feature is further along than David's concerns express, and we don't have alternatives proposed. 20:48:35 ddowin: We've not spent time defining alternatives. 20:49:05 ...The other problem is that messages may ultimately be required for more cases than the spec itself requires. 20:49:05 q+ 20:49:16 ack joe 20:49:33 ...By including the feature in the spec, we are opening ourselves up for these kind of additions. 20:50:16 joesteele: Some fragmentation across devices is to a certain extent unavoidable. I don't personally think this will happen that much. 20:50:19 Q+ 20:50:23 q+ 20:50:27 ack markw 20:51:00 ack dd 20:52:07 ddorwin: We need to avoid making problems worse, and fragementation exposure should be minimized. 20:52:17 q+ 20:52:26 ...We should take steps to ensure that access to content is possible for every device. 20:52:52 ...We should not require every device to support persistence to access content. 20:53:04 markw: It's optional, not required. 20:53:15 ddorwin: But it may be required to access Netflix. 20:53:57 q- 20:54:15 markw: Whether it's included in the spec isn't relevant to whether it's a requirement for access to our content. 20:54:48 paulc: Do you have a concrete list of things in the spec here that could be improved. 20:55:28 markw: We are working on improvements to this and could have more soon. 20:56:06 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. 20:56:30 ...It's too early to say what should or shouldn't be in the spec based on implementation experience. 20:56:57 ...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. 20:57:23 q+ 20:57:29 ddorwin: Isn't CR based on browser/UA implementation rather than website implementations? 20:58:07 paulc: We can set criteria for this to be what we want, and could require more than one implementation supports this feature. 20:58:33 ddorwin: But that is browser implementation rather than website use of the feature. 20:59:05 markw: It's true that there aren't that many certifiers here, and it shouldn't be surprising if Netflix uses a feature first. 21:00:10 ...The CR criteria says multiple browsers and DRM providers support a feature, and if they support the feature, that should support its value. 21:00:28 ddorwin: Any other supporters here for the feature? 21:00:33 ack markw 21:01:03 rustamk: I see possiblities for Comcast to use the feature, and think we have the same use case requirements. 21:01:40 ddorwin: Then how do we address the concerns about the architecture and offline access, and what happens if only some UAs support the feature. 21:02:06 MarkVickers: It appears that users would still get access, but some aspects of the service might be tied to this feature. 21:02:33 ddorwin: I believe Netflix supports this features because it allows better up-time relative to other options. 21:02:48 markw: Time is the main priority. 21:03:33 q+ 21:04:03 ack markw 21:04:08 ddorwin: There may be other solutions for insuring uptime. If license server access is dropped, perhaps playback can continue in some way. 21:04:11 ericde has joined #html-media 21:04:33 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. 21:05:08 q+ 21:05:27 ack dd 21:05:27 ...it's up to us if content is provided based on some UA feature or not. 21:06:06 MarkVickers: It might be more than performance level, but access to features like download could be tied to an optional feature. 21:06:49 paulc: MarkW: Can you take an action to provide more detail on updates for the spec here? 21:07:05 markw: Yes. 21:08:18 Action: markw to provide additional technical recommendations for persistent-release-message based on implementation experience 21:08:19 Created ACTION-85 - Provide additional technical recommendations for persistent-release-message based on implementation experience [on Mark Watson - due 2015-04-23]. 21:08:28 ACTION-85 is due in two weeks 21:08:41 ACTION-85: due in two weeks 21:08:41 Notes added to ACTION-85 Provide additional technical recommendations for persistent-release-message based on implementation experience. 21:09:17 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. 21:10:01 cheslip has joined #html-media 21:10:15 topic: Bug 27269 21:10:18 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269 21:10:37 ACTION: ddorwin to send an update on Bug 27269 21:10:38 Created ACTION-86 - Send an update on bug 27269 [on David Dorwin - due 2015-04-23]. 21:11:01 rrsagent, generate minutes 21:11:01 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html ddavis 21:11:12 topic: bug 27093 and issue 41 21:11:18 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093 21:11:32 scribenick: jdsmith 21:11:38 https://github.com/w3c/encrypted-media/issues/41 21:12:55 Bug 27093 Blocks: 20944 26838 27053 21:14:05 See three use cases in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093#c11 21:14:45 David's request to discuss use cases: https://github.com/w3c/encrypted-media/issues/41#issuecomment-93646287 21:15:08 ddorwin: Proposed we discuss the use cases today. 21:15:42 q+ to say The reason it prohibits keys is that the algorithms don't support it. That's why we should discuss use cases. 21:16:56 https://w3c.github.io/encrypted-media/#definitions Initialization Data: 21:16:57 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". 21:17:15 ...Others make sense from a security and privacy perspective, but not keys. 21:18:01 paulc: Your use cases require that keys be removed from here. 21:18:10 ...Correct? 21:18:37 joesteele: Yes, that is correct. It is the minimum change and would be good enough for me. 21:18:52 ...Given these use cases, should we describe them somehow in the spec? 21:19:13 ...I don't want to introduce use cases, but don't want the spec to preclude them. 21:19:15 ack dd 21:19:15 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. 21:19:50 q+ 21:19:53 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. 21:20:25 ...If the use case is common and we want to support it, then we should make these updates. 21:21:26 joesteele: Advocating that the CDM may be able to get the content key without sending a message to the server. 21:21:51 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. 21:21:58 ack markw 21:22:50 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. 21:23:27 ...We aren't explicit about how the keys are delivered. It's acceptable to allow differences with various key systems. 21:24:15 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. 21:24:54 ddorwin: If performance is important, then application developers will want to make sure that those benefits are available on all systems. 21:25:14 joesteele: The current spec says that a proprietary pssh is supported/allowed. 21:25:50 q+ 21:26:15 The last NOTE in http://w3c.github.io/encrypted-media/#initialization-data 21:27:29 jdsmith_ has joined #html-media 21:28:47 joesteele: spec says that initiData should not (not must not) include keys 21:29:16 ...I tried to call out where algorithms need to be changed to allow this. 21:29:42 q+ to ask How does one write an interoperable application if how the keys are obtained is key system specific? 21:29:52 markw: It seems clear to me that it's part of the spec for CDM messages to be opaque. 21:30:22 ...More complicated question is should we change our procedures to allow for this? 21:31:04 ...Possible principles: If we encounter a use case that requires slightly different message flow, then we should try to accommodate that. 21:31:34 ack markw 21:31:38 ack dd 21:31:38 ddorwin, you wanted to ask How does one write an interoperable application if how the keys are obtained is key system specific? 21:31:45 ...Or, we should only support the message flows that are defined in the spec, and modify it if necessary to support a use case. 21:32:09 q+ 21:32:28 MarkVickers_ has joined #html-media 21:32:33 q+ 21:32:34 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. 21:32:45 ddorwin: Prefer the second principle so that we explain how things would work. 21:33:41 ...If we allowed alternative key deliveries (some magic), how would the application deal with these differences? 21:33:58 joesteele: Some CDMs would send more or less key messages than others. 21:34:29 ...if you allow for applications to accept zero through N key messages, then this should just work. 21:34:47 ddorwin: Mostly concerned about the zero case and how it was created. 21:35:18 ...Without understanding this, it seems like it could affect availability of content. 21:36:32 paulc: Was a use case the zero key exchange? 21:37:09 See the use cases in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093#c11 21:38:44 jdsmith has joined #html-media 21:39:22 joesteele: Case 1: key already available locally, passed through hidden means, and usable to play other related content. 21:40:45 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. 21:41:25 ...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. 21:42:11 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. 21:42:38 ddorwin: So basically, all implementations have the same key? 21:43:19 joesteele: Yes. This works for scenarios where content over the channel should be encrypted, but having a unique key isn't important. 21:43:37 ddorwin: That doesn't sound like a common use case. 21:44:01 joesteele: Goes back to a fundamental question: Do I want every client to support this? Probably not. 21:44:30 ...We have this problem today. We'd have to send a bogus message back even though it's not necessary. 21:45:05 ...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. 21:46:10 ddorwin: You could break down case 2 to use a master key of some kind. A key in the pssh is separate. 21:46:21 ...There are other reasons to support keys in the pssh. 21:46:55 ...Then there is the key alreay exists. It seems like that is a corner case and should mess up the spec to support it. 21:47:07 ...shouldn't mess up... 21:47:30 ack joe 21:47:32 q? 21:47:37 ack markv 21:47:59 MarkVickers: There are other use cases beyond the ones Joe has defined. 21:48:37 ...There are similarities between key system access and MIME types. 21:50:05 q+ 21:51:13 ...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. 21:51:38 ddorwin: Goal of EME should be to enable content that work across browsers. 21:52:11 MarkVickers: To be clear, we want to use the model here of CENC, CDMs, etc... 21:52:44 q+ 21:53:12 ddorwin: We've discussed out of band license acquisition before and it's not supported because it violates web security architecture. 21:53:18 ack dd 21:53:21 ack joe 21:53:44 joesteele: I don't think we've said anything about key acquisition, except where it involves sending messages to a computer. 21:54:16 ...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. 21:55:06 ddorwin: That probably should be discussed along with getting input from other people on it. 21:55:30 ...It could open an entire category of things that are out of scope at the moment. 21:56:04 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. 21:56:21 ddorwin: Fine means allow doing it in a hidden way/ 21:57:23 ddorwin: Persisting keys, whether content keys or otherwise is not allowed by the spec. 21:58:30 ddorwin: I thought when we punted domain keys, we were putting aside use cases that required them. 21:59:42 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. 22:01:04 joesteele: Case 3 lets the CDM retreive a key from a license server and use it to access other keys. 22:01:13 ericde_ has joined #html-media 22:01:54 paulc: Which use cases do we want to dig into and in which order? 22:02:25 ddorwin: We can discuss them here, but it might make sense to solicit bugs on use case needs. 22:03:00 paulc: You are saying that the pssh containing a key is somewhat orthogonal to the problem. 22:03:07 ddorwin: Yes. 22:03:28 Proposal: 22:03:45 1. File bug to remove "keys" from the Initialization Data definition. 22:03:59 2. File a bug to support key in the initData. 22:04:18 3. File a bug on "performance keys" (aka key chaining) 22:04:23 4. seek input on #2 and #3 22:04:33 4. Block #1 on #2 and #3 22:04:45 joesteele: Removing keys from initialization data would help. 22:04:45 s/4. Block/5. Block/ 22:05:22 paulc: Can we just work this in Issue 46, or do we need bug 27093 open? 22:05:35 6. Close issue 41 as a dup of #1 (or just re-title it and update the first). 22:06:00 7. Hopefully, 27093 is orthogonal and we can close it and focus on the GitHub bugs. 22:10:59 ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 22:10:59 Error finding 'joesteele'. You can review and register nicknames at . 22:11:53 ACTION: joesteele to carry out steps 1 thru 6 on the proposed solution to ISSUE-41 22:11:53 Created ACTION-87 - Carry out steps 1 thru 6 on the proposed solution to issue-41 [on Joe Steele - due 2015-04-23]. 22:12:15 ACTION-87 is due in two weeks 22:12:43 Editor will resolve 27093 22:13:22 rrsagent, generate the minutes 22:13:22 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html paulc 22:40:18 rustamk has joined #html-media 22:41:05 jdsmith has joined #html-media 22:41:19 scribenick: jdsmith 22:42:47 topic: Common license request format 22:42:58 https://github.com/steelejoe/eme-generic-protocol 22:43:22 joesteele: We had discussion at last TPAC about this, and some general approval. 22:43:58 ...I think if we said CDMs should support it, we could use it as a tool to work on other bugs involving opaque messaging. 22:44:27 ...Proposal posted. 22:44:49 ...keys for ClearKey are JSON based, so I used that. 22:45:45 ...1st possible issue: key system specific identifer for keys. 22:46:07 https://github.com/steelejoe/eme-generic-protocol/blob/master/eme-request-asn1.txt 22:47:25 ...options would be to explicit define the format for this, or leave it to the CDMs. 22:47:46 q+ 22:48:16 sahil has joined #html-media 22:50:16 ...The proposal leaves key identifer open, and provides specific suggestions for other request data. 22:51:18 ...Response data details are also proposed on timing, and rules for use of provided keys. 22:52:51 ...The ask: Do we think this is useful to carry forward? David said thanks, but it needs more feedback. 22:53:33 ack markv 22:53:45 q+ 22:53:53 MarkVickers: At a high level, I think this is very, very important. 22:54:25 ...Criticisms of the EME API have been different from other APIs. We should get rid of opaqueness wherever we can. 22:55:33 q+ 22:55:51 ...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. 22:56:48 q+ 22:57:54 ack dd 22:58:00 q+ 22:58:12 ...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. 22:59:51 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. 23:00:02 ack markw 23:00:25 markw: Think this is a good idea as well. We need at least two DRM vendors that are committed to doing it. 23:00:34 ...More would be better. 23:01:18 q+ 23:01:20 ...Should try to get feedback from them on details that could be difficult. 23:02:02 markw: List the set of features the protocol needs to support 23:02:14 ack jl 23:02:41 MarkVickers has joined #html-media 23:03:21 jlacivita: We integrate with all the DRM providers, and need a user context and an application specific ID. 23:03:54 joesteele: Specifically excluded user context. A CDM could sign it, but we don't. It could be provided at the application level. 23:03:58 ack joe 23:04:35 -paulc 23:04:36 HTML_WG(MEDIA)12:00PM has ended 23:04:36 Attendees were +1.215.286.aaaa, +1.425.706.aabb, kyong, paulc, +1.650.275.aacc, rsleevi 23:04:56 joesteele: 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. 23:04:58 q+ 23:05:44 ddorwin: I'm not sure about user context, but there could certainly be a requirement for application signature. 23:06:36 rrsagent, draft minutes 23:06:36 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html joesteele 23:06:39 joesteele: If we define the delivery key identifer in a common way, we could verify that this who this was intended for. 23:06:42 Zakim, who is here? 23:06:42 apparently HTML_WG(MEDIA)12:00PM has ended, joesteele 23:06:44 On IRC I see MarkVickers, sahil, jdsmith, rustamk, cheslip, ericde, chaals, pangu, MattWolenetz, ddavis, jlacivita, ddorwin, RRSAgent, Zakim, markw, joesteele, paulc, MikeSmith, 23:06:44 ... cwilso, trackbot, adrianba 23:06:49 I agree with Mark. I think there are at least two categories to work on: what features should be included and the format. 23:06:53 q? 23:07:14 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. 23:07:21 ddorwin: Should work on what features should be supported and what the format is. 23:08:00 ack markv 23:08:01 ...We don't need to limit what's supported in the spec. For example, renewal period is not specified today. 23:08:34 q+ 23:08:58 MarkVickers: If we have this more opaque API that's blocked by some underlying IP. The API details itself should not be a problem. 23:09:30 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. 23:09:56 ...Through design of this, some venders may say a standard approach is fine, and others may not. 23:10:18 MarkVickers: That's understandable, but not a reason not to dive in and try to make it work. 23:11:19 ...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. 23:11:34 markw: Is this V1? 23:11:59 MarkVickers: Has to be in from the begginging or opaque solutions will be grandfathered in. 23:12:24 ACTION: paulc to check on whether the proposed generic license request/response protocol is in scope of the current HTML WG charter 23:12:24 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]. 23:12:28 ...We can ship now as we work on the spec, but shouldn't consider the spec complete until this gets addressed. 23:12:55 q+ 23:13:30 rustamk: Application developers would love this. 23:14:51 markw: I'm not confident about saying we'll delay the spec more than its been delayed already to add this. 23:15:07 paulc: My assumption is that this would be added as a separate deliverable. 23:15:23 markw: That would make sense to me. 23:16:03 MarkVickers: Once we allow the API with these messages being opaque, it will be hard to cliimb out. 23:16:09 q+ 23:16:24 q- 23:16:31 ack markw 23:16:50 ...People will need time to implement this, and waiting for the CDM exchange spec would be okay. 23:17:12 paulc: I will check whether this is in scope (in next week). Agreed? 23:17:35 joesteele: Fine with me. I will make a JSON version so we can look at that. 23:17:56 MarkVickers: We might want a face-to-face on this specific topic. 23:18:09 topic: Automatically publishing to TR space. 23:18:45 paulc: We've already done this for HTML 5.1. It only works under process 2014. 23:19:13 ...The tools automatically generate the status of the document. Moving EME to the new process makes sense to me. 23:19:47 ...If we are in LC/CR (named as one state), we don't have to move forward and back to take changes. 23:21:19 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 23:21:19 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]. 23:21:57 topic: Permanent home for EME and MSE Registries 23:23:30 paulc: We had an issue when we published the recent heartbeat versions for MSE and EME. 23:25:00 ...Even though these registries have "must" in them, they are informative and not normative. Informative specs aren't allowed in TR space. 23:26:11 ...Proposal is serve these specs in non-TR space on www.w3.org. 23:26:25 ...This is ready to execute on the next heartbeat publication. 23:27:08 topic: Plan for addressing interop/segmentation bugs 23:27:42 Bug 20944 - EME should do more to encourage/ensure CDM-level interop 23:27:51 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944 23:28:43 EME Formal Objection: http://dev.w3.org/html5/status/formal-objection-status.html 23:32:25 ACTION: paulc to update Bug 20944 if the TF goes ahead with work on generic license request/response protocol 23:32:25 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]. 23:33:57 topic: What is the definition of independent interoperable implementions for EME? 23:34:31 See http://www.w3.org/2014/Process-20140801/#implementation-experience 23:34:47 ddorwin: We need to make a proposal on what it means to prove interoperability on these features. 23:34:54 This is done by the TF deciding (with the WG) on what the CR exit criteria are. 23:35:12 ...I would propose we need two different browsers with two different systems that are used. 23:35:28 ...Leaves open what we do to each to prove they are interoperable. 23:36:04 paulc: When we go before the director, we will be expected to have decided features at risk, and what the actual exit criteria are. 23:36:15 ...We could raise the min bar if we want. 23:36:29 ...And could require complete processing of some amount of human viewable content. 23:36:47 ...Typically working groups don't worry about this until they get their bug count lower than ours. 23:37:34 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. 23:38:23 ddorwin: We might need the DRM providers to stand up a permanent URL to support testing. 23:38:29 markw: It can't be hard coded. 23:38:49 ddorwin: DRM companies can help once we determine what we need. 23:40:12 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. 23:44:07 paulc: Could someone do this now? 23:44:41 markw: The issue is that browsers aren't ready for interoperablility testing yet. They might be soon. 23:44:51 paulc: Can it be done at a very basic level? 23:45:17 action: rustamk to ask Cable labs about their current EME testing and whether they can expose it to the TF 23:45:17 Error finding 'rustamk'. You can review and register nicknames at . 23:45:19 ddorwin: RequestKeySystemAccess would at least need to be supported, and Chrome is the only browser shipping with it now. 23:45:51 Action: paulc (really rustamk) to ask Cable labs about their current EME testing and whether they can expose it to the TF 23:45:51 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]. 23:46:21 Topic: Tests - Should we use MSE rather than .src= for spec tests? 23:47:37 ddorwin: All deployed uses of EME use MSE, so having tests in MSE could be reasonable. 23:47:52 ...There could be some objections to it. 23:50:43 MattWolenetz: If you have some src= implementations. 23:51:09 markw: On any implementation (EME or src=), you'd need at least two implementors. 23:51:41 paulc: Some groups require more, and say a great number support a specific set of features or uses. 23:52:35 ddorwin: My question is partly practical. Want to make sure tests we contribute are going in the right direction. 23:53:01 paulc: I'd be fine talking to the Director about a specific set of content we require in testing. 23:53:43 title: Telecon frequency & agenda 23:54:17 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. 23:54:32 ACTION: paulc to build a generic wiki agenda for future TF meetings 23:54:32 Created ACTION-92 - Build a generic wiki agenda for future tf meetings [on Paul Cotton - due 2015-04-23]. 23:55:05 paulc: What did you mean by frequency? 23:55:31 ddorwin: Perhaps we shouldn't hold the call if there's not enough of an agenda. 23:55:54 paulc: Holding the call regularly can help drive progress. 23:57:34 rrsagent: generate minutes 23:57:34 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html jdsmith 23:57:41 rustamk has joined #html-media 00:04:51 Meeting adjourned at 17:00 PT 00:04:58 rrsagent, generate minutes 00:04:58 I have made the request to generate http://www.w3.org/2015/04/16-html-media-minutes.html paulc 00:07:28 ddorwin has joined #html-media 00:08:37 ddavis has joined #html-media 00:33:14 chaals has joined #html-media 00:44:14 rustamk has joined #html-media 00:51:57 rustamk has joined #html-media 03:06:42 ddorwin has joined #html-media 07:04:49 ddorwin has joined #html-media 07:08:18 rustamk has joined #html-media 07:38:37 rustamk has joined #html-media 07:58:42 rustamk has joined #html-media 08:28:59 Zakim has left #html-media 10:10:40 rustamk has joined #html-media 12:03:06 rustamk has joined #html-media 12:25:31 rustamk has joined #html-media 12:36:49 rustamk has joined #html-media 12:39:32 rustamk_ has joined #html-media 12:43:01 rustamk has joined #html-media 13:31:07 rustamk has joined #html-media 14:47:39 ddorwin has joined #html-media 16:44:36 chaals has joined #html-media