[Minutes] HTML Media Extensions WG meeting, Thu Apr 20

Meeting: HTML Media Extensions WG meeting, Thu Apr 20

Minutes are recorded at http://www.w3.org/2017/04/20-html-media-minutes.html
and below.

/paulc



[W3C]<http://www.w3.org/>

- DRAFT -
HTML Media Task Force Teleconference
20 Apr 2017

See also: IRC log<http://www.w3.org/2017/04/20-html-media-irc>

Attendees
Present
jdsmith, dsinger, dob, johnsim, markw, paulc, jeff, wseltzer, plh, timbl, amy, BobLund, hsivonen, Gerry, Smith, Danny, O'Brien, Netflix, Mike, Champion, ddorwin, pal, Guest49, jernoble
Regrets
Chair
paulc
Scribe
amy
Contents

  *   Topics<http://www.w3.org/2017/04/20-html-media-minutes.html#agenda>
     *   HME WG member discussion with W3C Director on EME Proposed Recommendation<http://www.w3.org/2017/04/20-html-media-minutes.html#item01>
  *   Summary of Action Items<http://www.w3.org/2017/04/20-html-media-minutes.html#ActionSummary>
  *   Summary of Resolutions<http://www.w3.org/2017/04/20-html-media-minutes.html#ResolutionSummary>

________________________________

<plh> sorry, phone issues on our side :(

<plh> trackbot, start telcon

Paul: I think we have everyone here
... some people are on IRC who are not on the call. They may have bots
... Is there anyone who wants to register attendance on the phone to correct

? Noble+

<plh> Jer Noble

agenda
HME WG member discussion with W3C Director on EME Proposed Recommendation

<Dsinger_> Jer Noble

Paul: I've convened this is at Director's request
... I'd like to turn this over to Tim.
... given that this was requested by the director, I will reserve the right to give the floor to the director at any point

Tim: we may have more than one discussion. So we don't' have to make sure we finish all the things which have come up
... the background I think we're all aware of - things are very contentious. issues around DRM. there are hugely varying different opinions about how the world should work. goes way outside they ways typically W3C has done except a couple of cases
... for this call I want to focus on technical bits, for example the TAG. the model we had on the white board was the EME system connecting the browser to connect to DRM system.
... the way we'd done that was a sandbox. so the role of EME in that way, was to protect the user from the DRM blob
... there lots of reasons people don't like DRM. two are that it's a security risk (sony rootkit fame) and 2. privacy.
... that it could leak info on almost anything. seems to me the reason to have DRM naked on your machine
... one reason was that the browser was a user agent and protects the users while allowing user to interact and have a life and buy and sell things and watch movies
... My concern is that the diagram should be modified to have the sandbox in there as a red line. there was pushback from the group saying the sandbox isn't typical

<dob> q

Tim: in the TAG we talked about the sandbox in chrome and Firefox and i got the impression the sandbox was typical
... i'd like to get a sense form the group of sandboxing. maybe we're missing trick and maybe the spec should be modified to protect users privacy and integrity of the user computer to the extent they can be

Paul: I have people ready to respond.

Mark Watson: I think as the person who commented on this when the TAG gave their opinion. I'm not saying a sandbox is not necsseary or typical. just that the people who can say are browser implementors

scribe: they can include in architecture. in other places, not so given. w/ Microsoft the DRM is part of the system. so it's not different than the MS code
... unless they have reasons to do then it's up to them. the final point is that the specs should make clear the browser should protect the user. there are parts of the spec that do this but if unclear we should change. browser are supposed to protect

Tim: excellent. i felt the text didn't give this, maybe I should re-read this. i had understood didn't insist but that would be good

Danny O'Brien: One of the issues is that there's always interaction w/ DRM - technical and legal. Marks discussion of perimeter in CDM is based around who has incentive to protect

scribe: if you're trusting MS to run browser you're trusting them to run DRM. the trouble w/ the legal situation is that understanding what's in CDM are different. one of the ways we work in looking at sandbox is trying to break them
... don't know if you saw @ but someone broke not just the sandbox but the virtual machine

Tim: that was dramatic

Danny: we know part of the maintenance is the external overview. the challenge here, we can discuss, CDM. if you're talking about security you can't talk about legal risks. criminal procession.
... For the rootkit case we had to advise people and we coudnt' say they would not be legally challenged

Tim: that point has been made before and will be made again. it's important. we have the best practices. we hope the positive way, to reduce risks. the question i'm putting before you is requiring in EME spec is protecting privacy
... not wandring through files. it's reasonable to sandbox files don't trust. it's reasonable to be an org to
... try to protect trust. there are models. one is code which can be trusted. but also mark pointed out, these are different cases
... not about testing, nevermind testing is the case. let's say what the case should be.
... shouldn't we say info should not be exfiltrated by outside

Paul: want to make sure you're aware we spend 10s if not 100s of hours on identification of a user. the WG spent a huge amount of time on this for security and privacy
... quesiton is there enough there or not

Henri: earlier it mentioned the sandbox. Firefox on desktop there's a downloadable CDM. on android we have an implementation we use platform of widevine. it comes to user on phone
... we don't get to sandbox it. with ARM TrustZone there are two kernels on the hyperviser. one is lInux. another kernel boots in trust zone. the DRM runs on trust zone, on the other kernel on top of a hyper visor
... could make distinction hypervisor is not part of the CDM but all three, CDM, hyper viser and kernel are all mystery code
... in the trust zone model the user, the sandbox can't ? the CDM

Tim: it's good to get different architectures enmerated

ddorwin: similar for chrome. As far as I'm aware, those are the only two implementations that use sandboxing.
... industry trend is platform CDM

John Simmons: first point to make is the one David echoed. trend is for CDM is in the platform + the hardware. brings up issue of when sandbox takes place

scribe: design principles on windows is let the OS apply security to the objects it controls
... question is how to sandbox them. also why you sandbox them. you sandbox software which is untrusted

<ddorwin> s/Dana?/ddorwin/

scribe: there's lots of software not a CDM. reasons given for why CDMs are considered inherently untrustworthy. can be downloaded from malicious site. 3rd party. that's true about a lot of software
... are you suggesting just sandboxing just CDM or all 3rd party

Tim: not just because just a good thing to do. priority is to protect the users
... throughout history the browser has protected the user. eg: JavaScript can't access files
... that's a model in which the user is protected form all kinds of things. you don't get a codec rummaging around user files. location sending back credit card details.
... we haven't had examples of browsers doing this so we haven't had to write it down. but because those things have an unwritten rule a codec does what it does. it would be appealing and an outcry if it did.
... recent class action w/ a company w/ using data when supposed to be a speaker. the reason EME has to be strong about this is w/ players, to a certain extent, w/ DRM blobs
... while platforms might have great integrity, there might be native apps which
... sit there and abuse users. it's out there that it's fine for a native app to read user's calendar. there is a history of abuse of user privacy by native apps so I think people see this as if you download DRM it's a bit like that
... otherwise you might trust it. it may need specifying. does the group feel there would never be a breach of 3rd party data like Adobe

John Simmons: the section 10.2 in the spec where it says what the user agent must to to get key system info to integrate security w/ this

<plh> https://www.w3.org/TR/encrypted-media/#cdm-security

scribe: must support user agent and user agent must ensure it must be updated
... I don't know of a single CDM that does not meet that

<Zakim> Dsinger_, you wanted to ask why all drms are necessarily a risk.

David Singer: 2 things. in some what has been said that all CDMs are foreign or untrusted. we dont' want to write assumptions like that into

scribe: specs. I don't see any reason it's less trustworthy than other code we've made

Tim; that point has been made

David Singer: if the user installs w/ browser, should be treated w/ caution. that's true

scribe: but if it's complex and thus vulnerable. we've had to sandbox codecs
... we don't now support downloadable codecs. we nee to focus on where is untrustworthy. the user is exercising caution but not about cDM itself

Danny O'Brien: there's another aspect. DRM systems including CDM are designed to prevent the user from doing something. to lock out a capability. looking at memory etc. which means it's a place where user

scribe: choices can be overridden. the untrustworthiness is by enabling an environment
... where user can be kept out where normally not have capability to trump what user is doing

Mark: obviously there are historical reasons for distrust. one thing we wanted to do w/ EME is carefully constraing CDM. can strengthen around privacy. we intended to preclude things mentioned - looking at calendar or looking on machine. any browser was compliant would be sure the CDM would not
... but if the CDM is the browser platform but how to remain EME compliant? browser needs certainty that use of a platform CDM won't make them non-compliant to the specification
... but we have a requirement that the sanitize data sent to the. CDM implementor needs to describe what this sanitization should consist of, to apply rules to the data being supplied to the CDM.

<dob> (This is a side-comment, and don't want to interrupt the stream, but note that there are already some uses of DRM/CDM that aren't just about playing protected content. So, for instance, including obligatory advertisements or warnings in the stream. Am I right in thinking that would be a potential use of the CDM?)

Henri: part of the source of the distrust if you're not allowed to look. in the case of Gecko? web kit the code is open
... in the case of Edge, it's not open but the majority of code is not obfuscated. in CDM it's obfuscated
... it's reasonable for users to be more suspicious of code not allowed to look. if not open source it's not resistant to

<dob> agree with hsivonen: code/hardware for CDM's has to be designed to resist external examination

Henri: debugging or inspection of the object code. from browser vendor the CDM comes from 3rd party, the browser vendor can not fix the code. because fewer people are not allowed to look may have effect, good to have some defense step from sandbox
... from privacy perspective if the CDM does not deliberately look in hard drive and CDM buffer overflow not being abused,
... still issue of DRM design protocol being able to track users. that's where the language about distinctive identifiers comes in. depends on design of CDM and sandbox.
... maybe a policy thing to be discussed vs. enforced through code

John: I wanted to give a different perceptive to danny about CDM as untrustworhty

<markw> @dob: CDM's do not get to interfere with the operation of the video element in terms of pause, seek etc. so it's hard to see how they could impose obligatory advertisements. Conceivably, CDMs that perform decoding as well as decryption could modify the decoded stream, for example to superimpose things. None of the existing CDMs have this capability and in the case of platform CDMs they perform decrypt but not decode.

John: when user uses CDM it's a choice. they're doing something that the user has requested. for that reason, I want to echo what Henri said, there's a catalogue of things which can happen. evne if
... not intentionally doing it can be exploited through buffer overflow or how protocol
... can be fingerprinted. valid concerns to be raised. but they change the fact that you have a CDM that's a platform not a browser.
... like chromium, it's a shim to do RPC to CDM in platform. sandboxing in browser I don't believe provides protection as CDM is out of control of browser

Tim; to summarize. different architectures of how things are put together. if EME was to guarantee that conformant implementations repsected privacy and security they

scribe: would have to do this in different ways. it seems the difference, if we make a world where it's provided these guarantees are given, it's a better world than one where there are native apps w/ no expectation of privacy
... where people need to download a new app for a movie. so privacy and security issues are worse. we should do everything we can so users feel justifiably secure that when using EME they're being protected - even w/ different architectures working different ways

Paul: thats why the security section says the principles of what's to be achieved. the WG are aware of different architectures, want to describe principles by

<dob> @johnsim, sorry, I may have been imprecise here. It's the job of the CDM is to enforce technically the removal of certain capabilities that usually lie with the user. You don't usually use the user's own platform to do that, so it means that the CDM itself has to take on certain capabilities that make it a high-risk piece, because it has the potential of preventing the user's veto in other areas.

Paul: this. the question is whether there's enough of this in the spec. beyond saying "you
... must sandbox. that's a solution not a principle

Tim: if you aggregate all of those, you can interpret them in this case, we need to demonstrate the browser is protecting user as much as can. i'm happy to hear the spirit on this call is that this absolutely what the intent of spec as.
... maybe there need to be more "musts" for security etc. for plugged in code

Paul: I need to watch the clock.

PLH: John mentioned it 's a user choice to view a video w/ CDM. I'd like to question that
... it's not a requirement. its a should. TAG wants this change to "must"
... w/out this , there's no way for user to know if it just a video. recently chrome removed ability to disable CDM. seems we're moving away from user consent vs. not

David Dorwin: what PLH referred to is the ability to remove in Chrome plug ins. now a gap, there's a feature to disable CDMs or EME. it wasn't a conscious decision

scribe: to say there's a sandbox it's not a magic bullet. there is no single definition of sandboxing - there are different levels. many suggestions but not verifiable. "must get agreement" but no way to check.
... besides browsers there are other implementations. that's not something they'll get for free if they take Chromium or WebKit

<Zakim> dsinger, you wanted to talk about privacy and security

David, would you want to type your question?

<dsinger> I wanted to say that the requirement that code that sits between the user and the network respect the user's privacy and security is not specific to DRMs, or the browser

<dsinger> If that is what we want to say at the W3C, we need to say it at a higher level and in a more general way

Paul: the queue is empty. we have 5 mins

Mark: briefly, to PLH's point about consent prompts. we'd love to arrive at point where using DRM has no more risk than non DRM. not a case for prompt. by ? it's a situation where it's valued. incentive to improve security
... I've argued for keeping that as a part of spec. if the prompt is not necessary it's not necessary.

tim; you may not prompt when on a trusted platform. but may prompt if on external application

Paul: that sounds like a should to me

Tim: this call is about making sure that the fact that somebody using EME gets the same security and privacy guarantees as when using EME when just using
... a browser. like when David says we should for other things like CSS. but for DRM it may need to be more specfic. if we want to roll out and get respect in community, we must give guarantees that DRM in general does not

Jer Noble: WebKit's perspective on sandboxing. ? vulnerability from an overrun similar to a malicious CDM.

scribe: ensuring has no access. w/ malicious cDM would have no more vulnerability than something else. we sandbox away from things. if we require by sandboxing we'd likely meet it for
... figuring in vulnerabilities

Henri: echo David's point about being centered on browsers. if you use Chrome OS then you see a content prompt
... but what Mark said there's no incentive for prompts. for Smart TV. the vendor has
... no incentive for prompt as much as Chrome OS. not so much emphasis for user privacy in all cases

Paul: we're at the top of the hour. this request came from Director. Tim did this meet your goal? any questions

Tim; as we're out of time, maybe we'll get back to you. maybe i've got to pour over spec to see if there's a way to make a guarantee strongly and clearly. maybe it's made strongly in the fine print

scribe: thank you all for your time. really appreciate it

Paul: thanks to group, made call w/ only 48 hours. Director and staff traveling so it's valuable that WG showed agility to meet w/ you.

Summary of Action Items
Summary of Resolutions
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.152 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2017/04/20 16:03:00 $
________________________________


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329