HTML Media Task Force Teleconference -- 26 Aug 2014

<trackbot> Date: 26 August 2014

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html

<markw> Xakim, MarkW is me

<paulc> We are going to need a scribe since Joe does not appear to be here.

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html

TAG EME draft

<paulc> https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md

paulc: wanted to bring this to your attention

<paulc> See http://lists.w3.org/Archives/Public/www-tag/2014Aug/0052.html

paulc: david and mark have been commenting on this

markw: think we're waiting for TAG to revise document

<paulc> Also: http://lists.w3.org/Archives/Public/www-tag/2014Aug/0055.html

Bugs

Bug 26575 - Separate creation of the MediaKeySession from "message" event generation

<paulc> Proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10

paulc: at the last meeting, agreed to deal with the proposal in comment1
... david, you added that yesterday and you have made some changes
... next item is to get feedback?

<ddorwin> see changes at https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#extensions

ddorwin: yes, comment 10 describes what i did, proposal in comment 1
... one more thing to do is to make createSession synchronous

<ddorwin> https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-createsession

ddorwin: algorithms doesn't do anything interesting except make an object
... want to check if anyone has reasons not to
... seems fine to be synchronous
... equivalent to new MediaKeys

paulc: anyone have questions?

jdsmith: it makes complete sense

paulc: should we go ahead and if people have subsequent feedback they can reopen and comment

markw: my only comment is whether we should change the name to be related to initialize
... this would suggest you shouldn't call it twice

<markw> Should generateKeyMessage be init ?

ddorwin: init is kind of ambiguous - generateRequest is more general than original generateKeyRequest
... did include rules about not allowing to be called again

paulc: think you should add this to the list to be fixed

ddorwin: will do today

Bug 26372 - Revisit the need for EME-specific DOMException names and the "error" attribute and event

paulc: jerry was going to look at this
... joe put in a proposal

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

jdsmith: i think the comments are mostly older
... oh, it was on 8/25 - probably the only viable path is to have an event with code
... joe thinks it might be worth pursueing
... i looked at this but i haven't made progress really

markw: why is it necessary to have informational event instead of error code on an object

ddorwin: basically most errors are returned in rejected promises
... only a few use cases for asynchronous error
... and some aren't errors - could be status
... output protection, key expired, etc.
... joe summarises ones that need to be addressed
... might not solve with generic error, could be specific events

markw: it's not our experience that there are only few errors

ddorwin: rejected promise contains DOMException
... defined in ES6/DOM4

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

ddorwin: do you mean debug sitting in front of a computer or in logs

markw: both but mostly looking at things in the field

ddorwin: logs was jerry's point too but on the PC itself you can see debug messages

jdsmith: we're convinced that you need systemCodes of some kind to deliver consumer quality experiences

paulc: just need someone to make a proposal, perhaps which object to have the systemCode returned
... leave with the editors
... now have bugs that we don't have proposals for

Bug 26600 - Text is confused between persistent session vs persistent licenses

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

paulc: some more discussion on the list
... can we make any progress today?

paulc: last week we looked at david's recent proposal and people said they need time to look at it
... can someone volunteer to take a look at this and decide if they are okay?

markw: i will follow-up

joesteele: think this is going to be impacted by another bug
... 26575

paulc: already discussed that one
... on david's resolution list for today

joesteele: okay

Bug 26401 - Key message destinationURL usage is not reflected in examples

paulc: people wanted time to look at this

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

<paulc> Need feedback.

joesteele: in the last meeting, there was clear support for URL in the PSSH but not david

ddorwin: think this is a dup of 25920
... i don't think that we can provide URLs from random media sources to the application
... don't think that is responsible
... unclear that some of the use cases where there is URL are interoperable

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920 for the item that David thinks 26401 is a duplicate of

ddorwin: i'm against exposing security issues when it is not interoperable
... don't deny there are URLs in PSSH but that doesn't mean EME apps need them

joesteele: this isn't random data, it is media data explicitly loaded by the app
... (might be related to loading over SSL)
... player definitely knows what it is loading
... but i don't think there is a security argument here
... then the question becomes is there an interop problem here
... i think there may be but one we can't avoid if we want to support existing DRMs
... critical to some DRMs out there

ddorwin: don't think it is critical
... why does the URL have to be in initdata rather than known in the app

joesteele: may be created on the fly and based on something by the DRM
... for example if they don't own the DRM

ddorwin: but why embed in the media file

joesteele: might not be in the file, might be alongside

ddorwin: if it is coming down next to it then you can do it a different way
... concern is when data coming from needkey
... (may be other issues with needkey based on SSL thread)
... media data could be compromised outside of the application

joesteele: i feel like that is a separate issue
... media data could be compromised to introduce malware which could be mitigated in lots of different ways but we're not normatively requiring that
... 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
... we're saying one of the specs we're supporting is Common Encryption DASH and the URL is allowed by that spec
... we joined this group with the understanding that we would support that spec in EME
... my point is that the app can't always know the URL coming out of the PSSH

markw_: i think we should generalise this
... the CDM is able to provide information to help route the message to the right place
... could be a destination URI so it might not always be a URL
... we do have use cases where we need data from CDM to help route message
... then a question is can you rely on initdata to help with this routing
... and i don't think you can eliminate this
... CDM might not know the actual URL but it might indicate routing information
... specific problem seems to be about exposing raw URLs
... but if we allow the first two parts then we can't exclude this
... and it is the responsibility of the CDM to do what it can to protect this
... could require considering this in the security considerations
... don't think we can exclude something in initdata determining what to do with message

<Zakim> ddorwin, you wanted to say the application can also parse the PSSH - it doesn't need the UA to do it.

ddorwin: application can also parse PSSH so it doesn't necessarily need the UA to do it
... also i would like to see us address these use cases without allowing script injection from other origins
... which is what we are doing by allowing cross-origin urls to be exposed

joesteele: app can't necessarily parse PSSH because data might be encrypted by CDM
... and exposing key would break robustness rules for DRM
... would you feel more comfortable if the URL that came back was somehow format constrained?

ddorwin: no, i don't think so because all someone has to do is replace adobe URL with evil.com URL

joesteele: what is the outcome of replacing it?

ddorwin: you could then provide back a license that is used to attack or could be a proxy and track what is happening
... some more issues were discussed in the other bug
... have to think about this going through TAG or Director review
... allowing URL from untrusted data will be a red flag

joesteele: how is this different from URL in track?

ddorwin: not sure, can you provide a pointer

paulc: joe, are you tracking the TAG conversation?

joesteele: aware but not tracking

paulc: david indirectly mentioned that

ddorwin: one issue is a general problem mentioned by Henri - more concerns about needkey (now encrypted) and data from initdata

paulc: you want to do research on...?

ddorwin: extracting initdata from media data
... we're arguing whether this is a security concern, perhaps we need security experts

paulc: mark mentioned maybe signing the URL?

joesteele: who would be validating this?

markw: i think i was saying the initdata could be validated in some way
... joe, you said your data is encrypted so that already makes it more difficult
... initdata could be integrity protected
... could be public/private key signed
... for this if we're showing an example we should show something secure
... 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

joesteele: i did say our initdata is encrypted and it is also signed
... our CDM follows most of these cryptographic best practices
... i hate to see us restrict things generically because somebody could be a bad actor then everyone has to do something
... would prefer UA enforces than this is in the spec

Bug 25923 - isTypeSupported should be asynchronous

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

paulc: jerry said he would take a look and he added a question, which anne has answered
... what is the next step?

jdsmith: i think from the general utility of isTypeSupported then synchronous is the most useful
... there is the idea that some kind of permission UI would be shown against isTypeSupported
... and so you make this async to let this UI be shown
... this isn't our idea for when you would show this UI

ddorwin: there is a larger issue of how apps should expect the permissions UI to occur
... and that might be a larger discussion
... you could imagine isTypeSupported saying maybe and the permission being on use

<joesteele> 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

ddorwin: isTypeSupported isn't necessarily a permissionable thing
... it's is for detection not necessarily actually using
... also, for Mozilla not just permission but possibly also download too

paulc: do we have a specific bug for this?

ddorwin: no, might be worth discussing

jdsmith: i think that is the essence of this isTypeSupported request

paulc: why don't you add that as a comment

jdsmith: i will but we might want to transition this to a bug about permissions
... i'd prefer isTypeSupported to run and get responses without extra overhead

paulc: you could open a bug and make isTypeSupported dependent on the permissions one

jdsmith: ok

Do we need LoadSession?

paulc: believe from the last meeting, asked people to take a look at david's response

http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0016.html

paulc: joe replied
... and mark and joe discussed
... where do we stand?
... should i assume we need to let the discussion continue?

joesteele: haven't seen additional discussion - i think the current model is not great
... but don't think i'm getting support for my proposal
... have not seen folks who are actually using this saying they would use it
... we would probably not use this model

<ddorwin> Mark's message: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0026.html

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
... i think there are others that had similar comments to joe
... i prefer we had a common model so these use cases handled the same way by different DRMs
... on the other hand i do see the value of arguments David has put forward so application can better track what is happening
... think we need to invest more in a middle ground
... would like to get to a common approach but maybe that isn't possible

joesteele: i think the last proposal from david separating mediakeysession is a good step along the way
... where this is just for routing messages to the CDM
... and persistence is handled separately
... i think if we do 26575 then we won't need persistent sessions any more

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

paulc: david is going to implement this one

markw_: i don't think 26575 is equivalent to you not needing persistent sessions
... you need to be able to recreate an old session with the same ID as before

joesteele: in our case i don't think you can an old session, some of the artifacts are the same

markw_: i think that is the same thing as persisting a session

joesteele: that implies i know which things you care about and that isn't defined

<paulc> ok

[...] discussion about which parts of session need to be restored

paulc: going to leave the discussion there - out of time
... meet again next Tuesday morning

ddorwin: only be available for part
... probably first and last not middle

paulc: shall we go 2 weeks to the next meeting?
... okay, next meeting in two weeks
... on sep 9

- DRAFT -

HTML Media Task Force Teleconference

26 Aug 2014

Attendees

Contents