- 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>
Minutes -> http://www.w3.org/2014/08/26-html-media-minutes.html
- DRAFT -
HTML Media Task Force Teleconference
26 Aug 2014
[2]Agenda
[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
Attendees
Present
Regrets
Chair
Paul Cotton
Scribe
Adrian Bateman
Contents
* [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/2014A
ug/0028.html
[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/2014A
ug/0028.html
[15] http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0028.html
TAG EME draft
<paulc>
[16]https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
[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.ht
ml
[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.ht
ml
[18] 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:
[19]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10
[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
comment1
... david, you added that yesterday and you have made some
changes
... next item is to get feedback?
<ddorwin> see changes at
[20]https://dvcs.w3.org/hg/html-media/raw-file/default/encrypte
d-media/encrypted-media.html#extensions
[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
<ddorwin>
[21]https://dvcs.w3.org/hg/html-media/raw-file/default/encrypte
d-media/encrypted-media.html#dom-createsession
[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
<paulc>
[22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c8
[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
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>
[23]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600
[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/2014A
ug/0026.html
[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
examples
paulc: people wanted time to look at this
<paulc>
[25]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26401
[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
interoperable
<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
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>
[27]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c10
[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_Trac
ks_API
[28] 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
[29]http://lists.w3.org/Archives/Public/public-html-media/2014A
ug/0016.html
[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/2014A
ug/0026.html
[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
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>
[31]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10
[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
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
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.
http://timeanddate.com/s/2qnz
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:
http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0018.html
Aug 12:
http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0009.html
3. EME status and bugs
a) Encrypted Media Extensions editor's draft
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Last updated on Aug 25.
b) Candidate heartbeat WD
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media-wd.html
Status: Pending publication.
c) Encrypted Media Extensions bugs:
http://tinyurl.com/7tfambo
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
https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
See discussion starting with Mark's reply at:
http://lists.w3.org/Archives/Public/www-tag/2014Aug/0052.html
and David's contribution:
http://lists.w3.org/Archives/Public/www-tag/2014Aug/0055.html
4. New EME bugs since the last meeting
None.
5. EME bugs with proposal
a) Bug 26575 - Separate creation of the MediaKeySession from "message" event generation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575#c10
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372
Status: At the Aug 19 meeting Jerry offered to take up this bug. See Joe's suggestion in:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c8
6. EME bugs awaiting input from Task Force or actions
a) Bug 26600 - Text is confused between persistent session vs persistent licenses
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26401
Status: At the Aug 19 we agreed to let the TF discuss this bug.
c) Bug 25923 - isTypeSupported should be asynchronous
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923
Status: At the Aug 19 meeting Jerry offered to look at this bug. See Jerry's reply:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c10
7. Do we need LoadSession?
http://lists.w3.org/Archives/Public/public-html-media/2014Jul/0018.html
Status: At the Aug 19 meeting Joe offered to review David's reply in:
http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0016.html
8. EME Use cases Wiki
https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases
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)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
Status: Lots of discussion since the Aug 19 meeting.
10. Other EME bugs
http://tinyurl.com/7tfambo
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")
https://www.w3.org/Guide/1998/08/teleconference-calendar#s_5366
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