W3C home > Mailing lists > Public > public-html-media@w3.org > August 2014

RE: {minutes} HTML WG media telecon 2014-08-26 - EME status and bug discussion

From: Adrian Bateman <adrianba@microsoft.com>
Date: Tue, 26 Aug 2014 16:11:24 +0000
To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <b22bbfdbff4944bcbe3411c8e50e9e99@BL2PR03MB604.namprd03.prod.outlook.com>
Minutes -> http://www.w3.org/2014/08/26-html-media-minutes.html

                               - DRAFT -

                  HTML Media Task Force Teleconference

26 Aug 2014


      [2] http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/08/26-html-media-irc


          Paul Cotton

          Adrian Bateman


     * [4]Topics
         1. [5]TAG EME draft
         2. [6]Bugs
         3. [7]Bug 26575 - Separate creation of the
            MediaKeySession from "message" event generation
         4. [8]Bug 26372 - Revisit the need for EME-specific
            DOMException names and the "error" attribute and event
         5. [9]Bug 26600 - Text is confused between persistent
            session vs persistent licenses
         6. [10]Bug 26401 - Key message destinationURL usage is
            not reflected in examples
         7. [11]Bug 25923 - isTypeSupported should be asynchronous
         8. [12]Do we need LoadSession?
     * [13]Summary of Action Items

   <trackbot> Date: 26 August 2014

   <paulc> Agenda:

     [14] 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:

     [15] http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html

TAG EME draft


     [16] https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md

   paulc: wanted to bring this to your attention

   <paulc> See

     [17] 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:

     [18] http://lists.w3.org/Archives/Public/www-tag/2014Aug/0055.html


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

   <paulc> Proposal:

     [19] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10

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

   <ddorwin> see changes at

     [20] 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


     [21] 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


     [22] 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
   ... 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

   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

   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


     [23] 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> See also

     [24] http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0026.html

   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

   paulc: people wanted time to look at this


     [25] 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

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

     [26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920

   ddorwin: i'm against exposing security issues when it is not
   ... 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
   ... and it is the responsibility of the CDM to do what it can
   to protect this
   ... could require considering this in the security
   ... 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
   ... 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

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


     [27] 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 --

     [28] http://www.w3.org/WAI/PF/HTML/wiki/Media_Multiple_Text_Tracks_API

   ddorwin: isTypeSupported isn't necessarily a permissionable
   ... 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

   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


     [29] 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:

     [30] 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

   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


     [31] 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

   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

Summary of Action Items

   [End of minutes]

From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
Sent: Monday, August 25, 2014 2:38 PM
To: public-html-media@w3.org
Subject: {agenda} HTML WG media telecon 2014-08-26 - EME status and bug discussion

The HTML WG media teleconference meeting will occur on 2014-08-26 for up to 60 minutes from 15:00Z to 16:00Z.
Tokyo midnight, Amsterdam/Oslo 17:00, London/Dublin 16:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00.
Chair of the meeting: Paul Cotton
Scribe: TBD
(See the end of this email for dial-in and IRC info.)
== Agenda ==
1. Roll call, introductions and selection of scribe
2. Previous meeting minutes
Aug 19:
Aug 12:

3. EME status and bugs
a) Encrypted Media Extensions editor's draft
Last updated on Aug 25.

b) Candidate heartbeat WD
Status: Pending publication.

c) Encrypted Media Extensions bugs: 
Status as of Aug 25: 18 bugs
Status as of Aug 18: 18 bugs
Status as of Aug 11: 21 bugs
Status as of Jul 27: 21 bugs

d) TAG EME draft
See discussion starting with Mark's reply at:
and David's contribution:

4.  New EME bugs since the last meeting

5. EME bugs with proposal

a) Bug 26575 - Separate creation of the MediaKeySession from "message" event generation
Status: At the Aug 19 meeting we agreed to discuss this bug's proposal at the Aug 26 meeting.

b) Bug 26372 - Revisit the need for EME-specific DOMException names and the "error" attribute and event
Status: At the Aug 19 meeting Jerry offered to take up this bug.  See Joe's suggestion in:

6. EME bugs awaiting input from Task Force or actions

a) Bug 26600 - Text is confused between persistent session vs persistent licenses
Status: At the Aug 19 meeting we agreed to discuss this bug at the Aug 26 meeting.

b) [Bug 26401] Key message destinationURL usage is not reflected in examples
Status: At the Aug 19 we agreed to let the TF discuss this bug.

c) Bug 25923 - isTypeSupported should be asynchronous
Status: At the Aug 19 meeting Jerry offered to look at this bug.  See Jerry's reply:
7.  Do we need LoadSession?
Status:  At the Aug 19 meeting Joe offered to review David's reply in:

8. EME Use cases Wiki
Status: At the Aug 19 meeting we agreed that TF members needed to review Joe's changes.

9. Bugs under active discussion

a) [Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)
Status: Lots of discussion since the Aug 19 meeting.

10. Other EME bugs

11. Any other business
12. Chair and Scribe for next meeting

13. Adjournment
== Dial-in and IRC Details ==
Zakim teleconference bridge:
   +1.617.761.6200, conference 63342 ("media")
Supplementary IRC chat (logged):
   #html-media on irc.w3.org port 6665 or port 80 Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329
Received on Tuesday, 26 August 2014 16:12:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:53 UTC