14:54:36 RRSAgent has joined #html-media 14:54:36 logging to http://www.w3.org/2014/08/26-html-media-irc 14:54:38 RRSAgent, make logs public 14:54:38 Zakim has joined #html-media 14:54:40 Zakim, this will be 63342 14:54:40 ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 6 minutes 14:54:41 Meeting: HTML Media Task Force Teleconference 14:54:41 Date: 26 August 2014 14:55:06 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html 14:55:53 HTML_WG()11:00AM has now started 14:56:00 +[Microsoft] 14:56:08 zakim, [Microsoft] is paulc 14:56:08 +paulc; got it 14:57:52 markw has joined #html-media 14:58:08 glenn has joined #html-media 14:59:55 jamil has joined #html-media 15:00:52 +glenn 15:01:08 ddorwin has joined #html-media 15:01:30 +ddorwin 15:01:34 -ddorwin 15:01:43 davide has joined #html-media 15:02:10 +ddorwin 15:02:28 +davide 15:02:34 adrianba has joined #html-media 15:02:58 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html 15:03:03 +MarkW 15:03:13 Xakim, MarkW is me 15:03:14 zakim, who is here? 15:03:14 On the phone I see paulc, glenn, ddorwin, davide, MarkW 15:03:16 On IRC I see adrianba, davide, ddorwin, jamil, glenn, markw, Zakim, RRSAgent, paulc, trackbot 15:03:20 Zakim, MarkW is me 15:03:20 +markw; got it 15:04:22 +jdsmith 15:04:40 jdsmith has joined #html-media 15:04:53 zakim, who is here? 15:04:53 On the phone I see paulc, glenn, ddorwin, davide, markw, jdsmith 15:04:55 On IRC I see jdsmith, adrianba, davide, ddorwin, jamil, glenn, markw, Zakim, RRSAgent, paulc, trackbot 15:05:02 -ddorwin 15:06:09 +[Microsoft] 15:06:15 zakim, [Microsoft] is me 15:06:15 +adrianba; got it 15:06:20 ddorwin has joined #html-media 15:06:58 We are going to need a scribe since Joe does not appear to be here. 15:07:32 +ddorwin 15:07:34 zakim, who is here? 15:07:34 On the phone I see paulc, glenn, davide, markw, jdsmith, adrianba, ddorwin 15:07:36 On IRC I see ddorwin, jdsmith, adrianba, davide, jamil, glenn, markw, Zakim, RRSAgent, paulc, trackbot 15:08:26 ScribeNick: adrianba 15:08:31 Scribe: Adrian Bateman 15:08:35 Chair: Paul Cotton 15:08:46 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html 15:09:15 TOPIC: TAG EME draft 15:09:17 https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md 15:09:21 paulc: wanted to bring this to your attention 15:09:30 See http://lists.w3.org/Archives/Public/www-tag/2014Aug/0052.html 15:09:31 ... david and mark have been commenting on this 15:09:57 markw: think we're waiting for TAG to revise document 15:10:08 Also: http://lists.w3.org/Archives/Public/www-tag/2014Aug/0055.html 15:10:24 TOPIC: Bugs 15:10:28 TOPIC: Bug 26575 - Separate creation of the MediaKeySession from "message" event generation 15:10:36 Proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10 15:10:45 paulc: at the last meeting, agreed to deal with the proposal in comment 10 15:10:55 ... david, you added that yesterday and you have made some changes 15:10:58 s/comment 10/comment1/ 15:11:03 ... next item is to get feedback? 15:11:22 see changes at https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#extensions 15:11:24 ddorwin: yes, comment 10 describes what i did, proposal in comment 1 15:11:40 ... one more thing to do is to make createSession synchronous 15:11:44 https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-createsession 15:11:52 ... algorithms doesn't do anything interesting except make an object 15:12:00 ... want to check if anyone has reasons not to 15:12:15 ... seems fine to be synchronous 15:12:24 ... equivalent to new MediaKeys 15:12:33 paulc: anyone have questions? 15:12:40 jdsmith: it makes complete sense 15:12:52 q+ 15:12:56 paulc: should we go ahead and if people have subsequent feedback they can reopen and comment 15:12:59 ack markw 15:13:23 markw: my only comment is whether we should change the name to be related to initialize 15:13:32 ... this would suggest you shouldn't call it twice 15:13:58 Should generateKeyMessage be init ? 15:14:16 ddorwin: init is kind of ambiguous - generateRequest is more general than original generateKeyRequest 15:14:23 ... did include rules about not allowing to be called again 15:14:49 paulc: think you should add this to the list to be fixed 15:14:53 ddorwin: will do today 15:15:31 TOPIC: Bug 26372 - Revisit the need for EME-specific DOMException names and the "error" attribute and event 15:15:42 paulc: jerry was going to look at this 15:15:46 ... joe put in a proposal 15:15:55 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c8 15:15:59 jdsmith: i think the comments are mostly older 15:16:27 jdsmith: oh, it was on 8/25 - probably the only viable path is to have an event with code 15:16:40 ... joe thinks it might be worth pursueing 15:16:46 q+ 15:16:51 ... i looked at this but i haven't made progress really 15:17:09 ack mark 15:17:18 +ReimundoGarcia 15:17:23 markw: why is it necessary to have informational event instead of error code on an object 15:17:39 ddorwin: basically most errors are returned in rejected promises 15:17:47 ... only a few use cases for asynchronous error 15:17:54 ... and some aren't errors - could be status 15:18:03 ... output protection, key expired, etc. 15:18:10 ... joe summarises ones that need to be addressed 15:18:21 ... might not solve with generic error, could be specific events 15:18:40 markw: it's not our experience that there are only few errors 15:19:00 ddorwin: rejected promise contains DOMException 15:19:11 ... defined in ES6/DOM4 15:19:48 markw: reiterate it is impossible to debug without system codes - won't define in the standard all the possible errors that can be so different from one system to another 15:20:02 ddorwin: do you mean debug sitting in front of a computer or in logs 15:20:25 markw: both but mostly looking at things in the field 15:20:46 ddorwin: logs was jerry's point to but on the PC itself you can see debug messages 15:21:00 s/point to/point too/ 15:21:34 jdsmith: we're convinced that you need systemCodes of some kind to deliver consumer quality experiences 15:21:53 paulc: just need someone to make a proposal, perhaps which object to have the systemCode returned 15:21:57 ... leave with the editors 15:22:00 joesteele has joined #html-media 15:22:20 paulc: now have bugs that we don't have proposals for 15:22:24 TOPIC: Bug 26600 - Text is confused between persistent session vs persistent licenses 15:22:30 +joesteele 15:22:30 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600 15:22:47 paulc: some more discussion on the list 15:23:18 ... can we make any progress today? 15:23:30 See also http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0026.html 15:23:46 markw_ has joined #html-media 15:24:02 ... last week we looked at david's recent proposal and people said they need time to look at it 15:24:13 ... can someone volunteer to take a look at this and decide if they are okay? 15:24:22 q+ 15:24:24 markw: i will follow-up 15:24:50 joesteele: think this is going to be impacted by another bug 15:25:10 ... 26575 15:25:18 paulc: already discussed that one 15:25:25 ... on david's resolution list for today 15:25:28 joesteele: okay 15:25:45 TOPIC: Bug 26401 - Key message destinationURL usage is not reflected in examples 15:25:53 paulc: people wanted time to look at this 15:26:00 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26401 15:26:04 Need feedback. 15:26:38 joesteele: in the last meeting, there was clear support for URL in the PSSH but not david 15:27:09 ddorwin: think this is a dup of 25920 15:27:23 ... i don't think that we can provide URLs from random media sources to the application 15:27:27 ... don't think that is responsible 15:27:41 ... unclear that some of the use cases where there is URL are interoperable 15:27:43 See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920 for the item that David thinks 26401 is a duplicate of 15:27:52 ... i'm against exposing security issues when it is not interoperable 15:28:06 ... don't deny there are URLs in PSSH but that doesn't mean EME apps need them 15:28:22 joesteele: this isn't random data, it is media data explicitly loaded by the app 15:28:35 ... (might be related to loading over SSL) 15:28:44 ... player definitely knows what it is loading 15:28:52 ... but i don't think there is a security argument here 15:29:05 ... then the question becomes is there an interop problem here 15:29:20 ... i think there may be but one we can't avoid if we want to support existing DRMs 15:29:31 ... critical to some DRMs out there 15:29:51 ddorwin: don't think it is critical 15:30:11 ... why does the URL have to be in initdata rather than known in the app 15:30:28 joesteele: may be created on the fly and based on something by the DRM 15:30:36 ... for example if they don't own the DRM 15:30:46 ddorwin: but why embed in the media file 15:30:56 joesteele: might not be in the file, might be alongside 15:31:13 ddorwin: if it is coming down next to it then you can do it a different way 15:31:33 ... concern is when data coming from needkey 15:31:48 ... (may be other issues with needkey based on SSL thread) 15:32:06 ddorwin: media data could be compromised outside of the application 15:32:20 joesteele: i feel like that is a separate issue 15:32:36 q+ 15:32:42 ack joe 15:32:51 ... media data could be compromised to introduce malware which could be mitigated in lots of different ways but we're not normatively requiring that 15:33:25 ... if we are going to support the DASH common encryption spec, and that was one of the supported standards coming into the group, then it's a problem if we change that now 15:34:14 joesteele: we're saying one of the specs we're supporting is Common Encryption DASH and the URL is in that spec 15:34:35 ... we joined this group with the understanding that we would support that spec in EME 15:35:39 ack markw 15:35:41 joesteele: my point is that the app can't always know the URL coming out of the PSSH 15:35:49 q+ to say the application can also parse the PSSH - it doesn't need the UA to do it. 15:35:51 markw_: i think we should generalise this 15:36:05 ... the CDM is able to provide information to help route the message to the right place 15:36:17 ... could be a destination URI so it might not always be a URL 15:36:31 ... we do have use cases where we need data from CDM to help route message 15:36:42 ... then a question is can you rely on initdata to help with this routing 15:36:49 ... and i don't think you can eliminate this 15:37:08 ... CDM might not know the actual URL but it might indicate routing information 15:37:20 ... specific problem seems to be about exposing raw URLs 15:37:33 ... but if we allow the first two parts then we can't exclude this 15:37:49 ... and it is the responsibility of the CDM to do what it can to protect this 15:37:59 ... could require considering this in the security considerations 15:38:10 ... don't think we can exclude something in initdata determining what to do with message 15:38:10 s/the URL is in that spec/the URL is allowed by that spec/ 15:38:19 ack dd 15:38:19 ddorwin, you wanted to say the application can also parse the PSSH - it doesn't need the UA to do it. 15:38:32 q+ 15:38:39 ddorwin: application can also parse PSSH so it doesn't necessarily need the UA to do it 15:38:56 ... also i would like to see us address these use cases without allowing script injection from other origins 15:39:13 ... which is what we are doing by allowing cross-origin urls to be exposed 15:39:18 ack joe 15:39:36 joesteele: app can't necessarily parse PSSH because data might be encrypted by CDM 15:39:46 ... and exposing key would break robustness rules for DRM 15:40:25 joesteele: would you feel more comfortable if the URL that came back was somehow format constrained? 15:40:50 ddorwin: no, i don't think so because all someone has to do is replace adobe URL with evil.com URL 15:40:58 joesteele: what is the outcome of replacing it? 15:41:17 ddorwin: you could then provide back a license that is used to attack or could be a proxy and track what is happening 15:41:26 ... some more issues were discussed in the other bug 15:41:36 ... have to think about this going through TAG or Director review 15:41:52 ... allowing URL from untrusted data will be a red flag 15:42:03 joesteele: how is this different from URL in track? 15:42:09 ddorwin: not sure, can you provide a pointer 15:42:24 paulc: joe, are you tracking the TAG conversation? 15:42:29 joesteele: aware but not tracking 15:42:39 paulc: david indirectly mentioned that 15:43:24 ddorwin: one issue is a general problem mentioned by Henri - more concerns about needkey (now encrypted) and data from initdata 15:43:57 paulc: you want to do research on...? 15:44:02 ddorwin: extracting initdata from media data 15:44:42 ddorwin: we're arguing whether this is a security concern, perhaps we need security experts 15:44:49 q+ 15:44:53 paulc: mark mentioned maybe signing the URL? 15:44:55 ack markw 15:44:59 joesteele: who would be validating this? 15:45:11 markw: i think i was saying the initdata could be validated in some way 15:45:13 q+ 15:45:25 ... joe, you said your data is encrypted so that already makes it more difficult 15:45:32 ... initdata could be integrity protected 15:45:42 ... could be public/private key signed 15:45:57 ... for this if we're showing an example we should show something secure 15:46:13 ack joe 15:46:18 ... don't see how you can prevent in our spec something that is bad from initdata unless you don't give it initdata at all 15:46:39 joesteele: i did say our initdata is encrypted and it is also signed 15:47:07 ... our CDM follows most of these cryptographic best practices 15:47:31 ... i hate to see us restrict things generically because somebody could be a bad actor then everyone has to do something 15:47:39 ... would prefer UA enforces than this is in the spec 15:48:05 TOPIC: Bug 25923 - isTypeSupported should be asynchronous 15:48:26 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c10 15:48:31 paulc: jerry said he would take a look and he added a question, which anne has answered 15:48:36 ... what is the next step? 15:49:06 jdsmith: i think from the general utility of isTypeSupported then synchronous is the most useful 15:49:23 ... there is the idea that some kind of permission UI would be shown against isTypeSupported 15:49:41 ... and so you make this async to let this UI be shown 15:49:42 q+ 15:49:47 ack dd 15:49:53 ... this isn't our idea for when you would show this UI 15:50:08 ddorwin: there is a larger issue of how apps should expect the permissions UI to occur 15:50:14 ... and that might be a larger discussion 15:50:34 ... you could imagine isTypeSupported saying maybe and the permission being on use 15:50:37 re: 26401 and David's earlier question -- this is the track reference I was talking about - the TextTrack API -- http://www.w3.org/WAI/PF/HTML/wiki/Media_Multiple_Text_Tracks_API 15:50:46 ... isTypeSupported isn't necessarily a permissionable thing 15:50:55 ... it's is for detection not necessarily actually using 15:51:14 ... also, for Mozilla not just permission but possibly also download too 15:51:19 paulc: do we have a specific bug for this? 15:51:28 ddorwin: no, might be worth discussing 15:51:40 jdsmith: i think that is the essence of this isTypeSupported request 15:51:49 paulc: why don't you add that as a comment 15:52:02 jdsmith: i will but we might want to transition this to a bug about permissions 15:52:16 ... i'd prefer isTypeSupported to run and get responses without extra overhead 15:52:35 paulc: you could open a bug and make isTypeSupported dependent on the permissions one 15:52:37 jdsmith: ok 15:52:53 TOPIC: Do we need LoadSession? 15:53:10 paulc: believe from the last meeting, asked people to take a look at david's response 15:53:17 http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0016.html 15:53:26 paulc: joe replied 15:53:37 ... and mark and joe discussed 15:53:40 ... where do we stand? 15:53:58 ... should i assume we need to let the discussion continue? 15:54:03 q+ 15:54:23 joesteele: haven't seen additional discussion - i think the current model is not great 15:54:33 ... but don't think i'm getting support for my proposal 15:54:47 ... have not seen folks who are actually using this saying they would use it 15:54:57 ... we would probably not use this model 15:55:11 ack markw_ 15:55:22 Mark's message: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0026.html 15:55:47 markw_: i think mine was the last message and i was trying to work through the implication that mediakeysession only scopes within the browsing session 15:55:56 ... i think there are others that had similar comments to joe 15:56:09 ... i prefer we had a common model so these use cases handled the same way by different DRMs 15:56:32 ... on the other hand i do see the value of arguments David has put forward so application can better track what is happening 15:56:33 q+ 15:56:40 ... think we need to invest more in a middle ground 15:56:55 ... would like to get to a common approach but maybe that isn't possible 15:56:56 ack joe 15:57:16 joesteele: i think the last proposal from david separating mediakeysession is a good step along the way 15:57:25 ... where this is just for routing messages to the CDM 15:57:37 ... and persistence is handled separately 15:57:51 ... i think if we do 26575 then we won't need persistent sessions any more 15:57:58 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10 15:57:59 q+ 15:58:04 paulc: david is going to implement this one 15:58:08 ack markw 15:58:15 rrsagent, generate minutes 15:58:15 I have made the request to generate http://www.w3.org/2014/08/26-html-media-minutes.html paulc 15:58:22 markw_: i don't think 26575 is equivalent to you not needing persistent sessions 15:58:39 ... you need to be able to recreate an old session with the same ID as before 15:59:02 joesteele: in our case i don't think you can an old session, some of the artifacts are the same 15:59:13 markw_: i think that is the same thing as persisting a session 15:59:26 joesteele: that implies i know which things you care about and that isn't defined 16:00:19 ok 16:00:33 [...] discussion about which parts of session need to be restored 16:00:50 paulc: going to leave the discussion there - out of time 16:00:56 ... meet again next Tuesday morning 16:01:02 rrsagent, generate minutes 16:01:02 I have made the request to generate http://www.w3.org/2014/08/26-html-media-minutes.html paulc 16:01:04 ddorwin: only be available for part 16:01:11 ... probably first and last not middle 16:01:28 paulc: shall we go 2 weeks to the next meeting? 16:01:45 -ReimundoGarcia 16:01:59 ... okay, next meeting in two weeks 16:02:05 ... on sep 9 16:02:09 rrsagent, make minutes 16:02:09 I have made the request to generate http://www.w3.org/2014/08/26-html-media-minutes.html adrianba 16:02:14 rrsagent, generate minutes 16:02:14 I have made the request to generate http://www.w3.org/2014/08/26-html-media-minutes.html paulc 16:02:15 rrsagent, make logs public 16:02:20 -adrianba 16:02:23 -markw 16:02:24 -joesteele 16:02:24 -davide 16:02:25 -glenn 16:02:26 -jdsmith 16:02:28 -ddorwin 16:03:02 -paulc 16:03:04 HTML_WG()11:00AM has ended 16:03:04 Attendees were paulc, glenn, ddorwin, davide, markw, jdsmith, adrianba, ReimundoGarcia, joesteele 16:03:46 rrsagent, make minutes 16:03:46 I have made the request to generate http://www.w3.org/2014/08/26-html-media-minutes.html adrianba 16:07:53 davide has left #html-media 17:13:02 jamil has joined #html-media 18:26:03 Zakim has left #html-media