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