Technical Architecture Group F2F Meeting

Discussion of note-keeping etiquette/format. Should we use MD in etherpad?

Agenda: https://www.w3.org/wiki/TAG/Planning/2014-07-F2F#Proposed_Topics

DA: At some point we will need to post this to W3C space, and we will want to format it.

YK: Markdown seems fine. It should be easy to convert Markdown to HTML to move to W3C space.

Agenda Planning

DD: CSS archeology could be a working session. What if we dived into the APIs in one of the afternoons?

DA: we have most of the afternoons open. Can slot that in for tomorrow.

DA: Extensible web doc catchup. How are we doing 1 year later? Brian Kardell will be here Tues afternoon.

DA: developer event tomrrow evening.

DA: copyright discussion...this afternoon

SK: should be before EME discussion

DA: would like to slot in darobin's discussion of the future of the web Tues morning because we're going to be joined by PLH to discuss URLs; he's currently at IETF.

DA: we've got robin available to talk about modularization of HTML5

YK: TC39 has an objection to massive modularization because there's nobody who can see the whole once you do that. It might be useful to do snapshots.

TBL: specs should be machine readable!

YK: e.g., classes and modules being added to ES without some sort of integration.

DA: another topic, reviewing the reviews we're doing. Perhaps this morning from 11 to 12.

DD: defining REST...somethign we've argued about.

TBL: AWWW talks quite a lot about REST. Defined by Roy Fielding, but we have spent a lot time talking about it.

DA: it's more along the lines of critiqing OMA's style guide, not defining it.

YK: http://jsonapi.org/ <= I've been working on this for some time. REST is *hard*.

YK: "If you've ever argued with your team about the way your JSON responses should be formatted, JSON API is your anti-bikeshedding weapon."

DA: <background>

DA: Mark's view is that the W3C should have a strict view of what REST is.

YK: I work on something that tries to define these sorts of things. It's *REALLY COMPLICATED*.

TBL: one of the Mark's would say, if you're chaging something you would read, you should use PUT.

YK: we don't know of any APIs that meet the platonic ideal of a REST API.

TBL: no...

YK: lots of people don't understand the data/metadata split

TBL: HTTP is very clear about this. There's one set of headers that are data and one that are metadata.

YK: lots of people bikeshedding this who are BAD at it.

TBL: are these people bikeshedding this because...?

YK: 2 types: fumbling vs. deep knowledge. The deep knowledge blows right past implementers.

TBL: but is there damage being caused?

YK: not really. Doesn't wind up mattering. Many PUTs don't include all of the required fields and we get along anyway.

DA: back to the question asked, in AWWW Volume 1, REST isn't even mentioned; it gets a mention in the references.

DA: if someone were looking to understand what we define REST as, we don't have that

TBL: we should be talking about good web architecture, not REST

YK: if people want a definition of REST, we're the wrong body.

AR: are we going to do this or not?

YK: even Roy isn't calling it REST any more.

AR: so what are we going to do?

DA: not a lot of appetite to do anything.

SK: how do we make this thing auto-scroll?

DA: lets not make a decision about this right now.

DA: other items...Promises guide

DD: do we want to publish it?

DA: why don't you walk us through it and then we can take a resolution.

DA: this morning.

DA: service worker extension spec patterns.

AR: was meant to have a blog post on this, but it's not done yet.

DA: so Wed then?

PL: gemoetry spec item...guests?

DD: sorry, no.

PL: some of them are in AU

DA: discussion over dinner about TAG organization/management?

AR: can we dicuss how to more efficiently deliver cat gifs through the internet?

DA: cf: https://pornel.net/efficient-gifs

DA: no, if it was good enough for grandpa...

SK: we should talk about Web Animations

DA: when should we discuss? How about this afternoon? We can bump to Wed if we don't get to it.

Promises Guide

TOPIC: https://github.com/w3ctag/promises-guide

DD: a TOC could help; I've incorporated all the feedback I've recieved to date.

DD: e.g., lead with advice. I've added a section on async algorightms. Turns out that web specs tend to have implied knowledge about how async things are supposed to work. I'e taken a shot at writing it down.

DD: the main point is that you need to say "these steps are asynchronous". Steps after that can be observed before the async ones; threading implications.

DD: theres a related concept of queuing tasks. You say "I queue a task" in spec language and there are situations which are subtle. You might, e.g., do a structured clone which could call a getter which thunks back into user code.

DD: have had it reviewed by Boris Zabarsky and I'm happy that got resolved.

DD: I said previously that there are 2 primary use-cases: "one and done" operations and "one time events"; loaded indicators, e.g.

DD: More generally, we're starting to see Promises being used in state transitions. We wante to give images a loaded promise; as we might do for other DOM thing. But Images are reloadable. If you re-assign .src on an image, the .loaded property will vend a different promise. Turns out this is pretty common on the web platform. We're suggesting people use a property and not a getter method.

AR: are you going to push for common naming of `.loaded`?

DD: left it implicit. I had an example of `.finished` in Web Animations.

YK: maybe we should have an interface for this?

DD: interesting.

YK: then you can write duck-typed code against this.

DD: will file an issue on that.

AR: should we try to get that into DOM?

DD: Jake Archibald wanted to get this into everythign, which seems great. So yes.

AR: we should probably then go find all the APIs that we need to revise to get them to adopt this everywhere.

DA: yes, we should make that hit list, but after we review the doc.

DD: in terms of open issues, we have some shorthand phrases that should be in Web IDL instead of prose. I think that normative stuff should be in IDL not text.

AR: disagree.

DD: I made a change to WebIDL and it was accepted.

DD: we're giving guidance that's pretty normative.

AR: use of arrow functions? Should we avoid that?

DD: they're in FF!

YK: it's a popular feature.

YK: when do you think we should target new features in docs like this?

AR: dunno. A year?

YK: what about classes? they are much clearer.

AR: yep.

DA: can we add a note?

DD: would prefer to push people into the future.

DD: I use `let` and `...` a few times. But can de-ES6-ify this.

DD: if we move this to HTML, could have a toggle to support both.

DD: filed.

AR: is the Realms note important?

DD: yes. BZ made a strong argument for this.

AR: are you discussing the queuing order about inter-window Promise resolution?

YK: trying to make that deterministic seems insane.

AR: there's no adoption-style API.

DD: but what's the scheduling across windows?

DD: there's a related issue: we don't have an idea of microtasks in ES and Allen WB is loathe to add them to ES.

YK: we need this in DOM, but we shouldn't specify this in TC39. ES will have a platform hook and we need DOM to clearly outline what the hook will be.

DD: Hixie was working on this. I can provide some spec text for this.

ACTION: Domenic to work with Hixie to get the appropriate hooks into HTML to specify that promises use microtasks.

YK: I'd like for us to have `setImmediate`, `setTimeout`, etc. and I'd like to be able to shim in at all times. Some of these things don't allow them to be interleaved. There are some strict orderings in the microtask queue. It's very difficult to shim in at an appropriate point across browsers. We are underspecified about where you might be able to shim in.

YK: currently, we only have "we observed this works this way in this browser". We should work to specify this.

YK: everyone who builds a Promise library hits this. RSVP has "ASAP" and it's much bigger than it should be.

DD: Promises are perhaps that point in time in some browser.

DD: This might be a TC39 thing, but TC39 is a very long way from defining the microtask queue.

YK: you want to define all the deterministic ordering points and you want to let people hook at all those point.

YK: you might like to be notified when you "pop the stack". E.g. Angular's Zones. E.g. a way to know when you're about to return to userland code.

RESOLUTION: Pending Domenic's one action (de-ES6-ifying) we should "publish" this document as a "last call" TAG finding.

DA: we don't usually get a lot of substantive feedback, but it'd be great to have this done but leave the feedback channel open.

DD: It is very important to me that there not be any outdated content in W3C space.

ACTION: Yves to help Domenic set things up so promises guide commits flow through automatically to W3C

DA: plan of action: put in W3C space; do a blog post; send to mailing lists. Which mailing lists?

public-script-coord, www-tag, es-discuss, whatwg, (tag-announce!?!)

<TAG-ANNOUNCE!?!?>

DA: anyone we should reach out to?

DD: seems that Web Animations is pre-emptively looking at our review feedback and incorporating changes!

SK: Definitely. New revision contains 4 changes, all seem to be drawn from Review

AR: early and often.

DD: hit-list for state-transition promises. HTML has a lot. Links, styles, videos, images, audio, ...

DD: CSS font-loading already has this, but we if define an interface we'd want them to use or or at least reference this guide.

YK: if we had an interface, might be cool to have a JS library that does it.

DD: but sometimes the names are different. `ready` vs. `loaded`. Sometimes they actually differ.

YK: maybe `loaded` is the wrong term then?

DD: we should talk about this.

Specificaiton Reviews

SK: 19 open issues. 3 urgent reviews.

DA: This is wiki where I'm hoping we can capture reviews, status, etc... https://www.w3.org/wiki/TAG/Reviews (not in detail, just high level status)

DD: some thing we have spent time on but have not captured: font loading and crypto. AR has spent time on Push. SK and I have spent time on Web Animations; not on their list but changes a-flying. Web Audio is going well.

AR: we spent time on WebRTC last year.

DD: ORTC confusion.

YK: I looked into this a lot, and sort of think the ORTC folks are correct. Feels like SQLite vs IndexedDB. Does rely on opaque details of underlying stuff. ORTC standardizes more of the lower stuff.

DD: I know a bit about this from our TalkBox folks...they're pretty positive about ORTC.

DD: finding a WebRTC person who understand ORTC beyond slognaeering would be useful.

YK: in the way that standardizing SQLite seemed good but might not have been, this seems similar; an enumeration of reliable pain points.

DD: we should probably get both groups in the room.

YK: the WebRTC perspective is likely that you have to deal with this stuff anyway, just wrap.

YK: they do different things. ORTC is a heavier lift in that it doesn't just reference an IETF spec.

DD: related to hangouts interop between FF and Chrome?

YK: difference in goals. Web developers vs. people who are already experts in the area.

YK: I feel like the ORTC doc we discussed previously is somethign we should revisit.

DA: we should reach out.

[discussion about that]

YK: there's a difference between saying "we need both" vs. the ORTC heavy-lift.

DA: we should update this page: https://www.w3.org/wiki/TAG/Reviews

DA: what else?

AR/YK: we should work on bolstering the origin model. It is not as bad as people say.

AR: there is consensus that the origin model is broken on the basis of it being broken by the <script> element (and <img>s with regard to tracking).

YK: basically anything that can trigger a network request

AR: we finally have a way to lock that down with CSP. That gives us a way for the origin model to be a pretty tight ship.

YK: you want a "safe for single-origin mode", right?

AR: you can use `default self`

YK: There isn't very good guidance on what you need to do to get a "good security model"

DA: how can we boil this down? "Same origin isn't broken; here are the problems people have with it now; here's how you can fix them now that we have CSP"

YK: we don't need OCAP.

TBL: You like the same origin model?

YK/AR: Yes. It's fantastic.

TBL: so you're not worried about a lack of finer granularity?

YK: people have learned how to use subdomains and paths. Subdomains and paths can both be used easily on the server side.

TBL: it messes up other things. You might have made choices about what you put in a URI, but the party that's responsible has to be put up-front in the domain name....which is OK.

YK: Human beings are good at coarse-grained security. They are bad at fine-grained security.

DD: SSL makes things a bit more complicated; wildcard certificates are more expensive.

YK: why are certs so expensive?

DA: difficulty of TLS is a real issue. Generally as we add new features that demand it.

DA: when I went and talked to the Guardian tech staff about pervasive monitoring, etc. I suggested SSL/HTTPS...and there are all kinds of reasons. 3rd-party content. 3rd-party ad networks. Their business is at risk. Big hassle.

DA: that pain is something we need to listen to in the web community. Even big companies have trouble.

YK: I continue to belive that if we can't bring down the cost, we should allow self-signed certs. They are better than naked HTTP.

AR: proposal with Dan Kaminsky and CSP folks (Mike West, etc.) for "same protocol", e.g. forcing "//" vs. "http://" or "https://"

YK: there's an issue with people who don't serve the same content over TLS vs. HTTP.

DD: some issues with Akami. Bank partnered with them and they didn't want to stream video.

DA: it was intresting to hear that Google wasn't willing to move ads to HTTPS.

AR: <notes https://support.google.com/adsense/answer/10528?hl=en>

DA: Started a document on github https://github.com/w3ctag/secure-the-web/blob/master/origin.md where we could capture some these ideas on origin specifically...

TBL: why can't browsers just make paths security boundaries? Lots of difficulty to disentangle `/people/*` vs `*.origin.com`

TBL: my Google calendar has a problem like this. If I add scripts, they'd all have to move to `timbl.googlecalendar.com`. If I delegate control over that calendar, even though it's about me but owned by someone else, then you need to move things again.

DA: <scribe forgot>

DD: I think AR was saying that we need agreement that origin-based security works as a baseline for arguments.

YK: Coarse grained security is easier to reason about than security that you can only understand by reading server config.

YK: people argue that the existance of arbitrary script loading breaks it entirely.

DD: there's a paper on this that was referenced by something AR sent me, but the model it presents is the idea that there's a "secure browser" that people use for some things but not others (e.g., banking). The punchline is that CSP could be that thing.

[Noah has joined]

AR: <expalins the storage partition concept>

YK: I see that this can be small, but until we tell people what to do, we aren't going to change minds. I've been on teams where CORS and CSP are mysterious and complicated, even though in reality they might not be.

AR: are you arguing that we need to produce a guide?

YK: we need a "better website" mode or a guide that outlines what to do.

DA: with existing tech?

YK: there are things you can do with existing tech that might make the world safe.

DA: Alex, should you start on this?

AR: yes. Something I should do. Apologies for derailing.

YK: CORS is painful because of intranets. E.g. `go/seekrit`

RESOLUTION: We will start working on a document "Same Origin Not Considered Harmful" - Alex to take lead: https://github.com/w3ctag/secure-the-web/blob/master/origin.md

YK: `Access-Control-Allow-Origin: *` should be sufficient for most people and most people should put it in their sites.

TBL: even for stuff that need auth?

YK: yeah, it's orthoginal to authentication.

TBL: so even w3.org should do this globally for auth'd stuff?

YK: Yeah. There was a fear that behind-the-firewall sites might be gamed (e.g. phishing). Not a consideration for most public websites.

DD: we should get this into HTML5Boilerplate.

YK: good point.

YK: maybe the answer is for us to write all of this down? Was trying to get Rails to do this, but the core team though this was dangerous. But intranets aren't the common case.

TBL: imagine apache asks you if it's intranet or not...

TBL: you could imagine a server even inspecting it's environment and doing the Right Thing as a result.

YK/DD: hobbles lots of things.

YK: it "feels dangerous" even when it's not.

DD: here's all the specs: http://www.w3.org/TR/tr-technology-review

DD: I'm going to start filing issues on the TAG repo.

Copyright

SK: I have prepared a short presentation on copyright.

https://yadi.sk/i/aMdynBM6X495q (Copied to W3C space: Copyright.pdf)

Noah Mendelsohn here...mostly just listening and learning...arrived late morning

TBL: Maybe there should be a "legal" section in every W3C spec

http://en.wikipedia.org/wiki/Happy_Birthday_to_You#Copyright_status

YK: sigh

DA: How are regional rights related to this?

PL: In Canada, you pay a tax for purchasing blank media, and it gives you the (untransferrable) right to copy

SK: This law is designed to compensate authors for personal usage.

YK: In Canada, once you pay for a blank CD, you have purchased the right to copy onto that CD for personal use, and it cannot be
transferred away via a EULA or other contract.

TBL: What would you replace copyright with?

AR: The moral principle of proportionality is violated by the existing copyright laws. A rewrite of the Bern convention would
have international maximum penalties, which would be relatively low.

EME

AR: background: https://docs.google.com/document/d/1-v5s570vnBYUYaUdguiPG1ePyrr4Ra8LC-IHThpZGrM/edit

DDorwin: Seems DRM isn't going away. It's sort of coming back in music with music streaming services. There is also a new push around 4K.

DDorwin: what we've looked at is: how can we enable this content on the web as safely and reasonably as possible, assuming we won't be able to stream it in the clear. 3 years ago, and still today, are vertical stacks from player, to server, etc. Content providers that want to publish to that platform need to have the whole stack. Content is then limited to client platforms that have support for that stack.

DDorwin: that's not necessary to protect the content. Browsers were getting media engines. Proprietary formats, etc, didn't seem necessary. Hence common encryption. That's where EME comes from; trying to minimize the scope of DRM and, to some extent, contain it. Plugins run unsandboxed generally, as is their app stack, and the goal was to minimize the potential for risk. EME enables better sandboxing.

TBL: question: people seem to have skipped over the idea that there are 3 or 4 proprietary stacks and if you want to publish, you have to be using or playing with one of those stacks. That doesn't enable an open market. The fact that people have to go through big vendors to get things done annoys. What about, e.g., a small band that "makes it" and then has to get in bed with one of the big companies. People feel that the record companies' role is to have and exert control over the DRM stacks. Can we build DRM stacks that are open to the extent that anyone can publish on it?

DDorwin: yes. (Note: Music seems to only be DRM'd for streaming.)

TBL: what about watermarking?

DDorwin: like the copyright issues discussed earlier, any issues with the industry structure are not caused by DRM. DRM isn't really related to this.

TBL: what if I want to be an independent producer? How do I protect things?

AR: put another way, who do I need to talk to?

YK: also, problem on the receiving end, new browser entrants.

TBL: key distribution, secrecy, etc.

DDorwin: big difference between keys in secure elements vs. a PGP key.

DD: different points. Different security models.

TBL: want to pay AR to watch his film. I'm happy to encrypt it. That's great in this scenario, why do have to talk to Google or Apple or Netflix?

DD: are you happy with device limitations?

TBL: in this scenario, yes, but lets focus on this for the moment.

YK: I personally feel that the new browser entrants issue is a huge problem.

DDorwin: it's not just giving out a key, it's enforcing how the key is used too. That's what makes it difficult.

TBL: I'm not getting the key, in this scenario, my TV is.

DDorwin: The server needs to trust that client, and it needs to make sure there's a secret that hasn't been messed with. That's where interop often falls down. I explored how we might make it possible for a server to send a key to some arbitrary client.

TBL: the key can be public

PL: well, now you'd have to encrypt per-device.

DDorwin: there has to be a secret. You have to prove that the device hasn't been tampered with. How do I know that the private key is valid? This is the root of the trust relationship. A client with a validated key needs to be trusted by a specific server.

DDorwin: someone was responsible for putting the key there and the server knows if/how trusted the client is.

TBL: imagine a TV manufacturer published a list of valid keys.

DDorwin: you can imagine Widevine published a list and PlayReady validated it...

TBL: or a Sony TV publishes a list of TVs keys.

DDorwin: DRM vendors get approval from Hollywood and then they get whitelisted by the publishers. E.g., a TV has Widevine, PlayReady, etc. And the publishers trust that implementation.

TBL: can't that whole trust relationship be public? Why can't it?

DDorwin: the way the minimal system work, with Netflix as an example, they have encrypted media and multiple servers (one for Widevine, PlayReady, etc.) They get a request which they use to look up a key they get from a central authentication system, and then they use the server to encrypt the key and send it back. They have agreements with the DRM providers which provide servers which can encrypt the content key and send it back.

DDorwin: in a simplistic case, the client is asked to do a license request. It signs something, sends that to the server, and the server verifies it, and then gives that info to Netflix which says "yes, I can talk to a 2014 Sony TV", e.g.

DD: what needs to be in place to allow an indie producer to be their distribution of their movies? E.g., be their own Netflix?

DDorwin: the secrets are in the clients. There are business agreements in the background.

YK: new browser entrant question (again). I care a lot about this. A new browser has to go through a large bizdev process to be competitive.

PL: EME is a helpful solution here.

TBL: isn't that what EME is meant to be?

DDorwin: back to the example of Netflix/license-server...in general, today, a publisher has to go talk to each of the companies. It's, in theory, possible that a Widevine server could be publicly available and it could verify a device.

PL: the question is: how does an independent publisher encrypt their content?

DDorwin: you generate a random key, as per usual.

TBL: you encrypt all the streams and formats with the same key.

PL: How is the key to decrypt getting to the end user?

TBL: at the moment, you talk to the Widevine server (e.g.) and get a key

PL: don't you have to talk to each vendor to do this?

DDorwin: you need to get the clients to agree with the server.

TBL: the server has to be up and running and participating in real time

(hard to minute)

PL: how do we get around the business difficulties there?

DDorwin: you'd have to to talk to the Widevine business people to get one of these servers.

DDorwin: Widevine is still ramping up support for EME. The goal is that information should be available online. They have released an Open Source packaging tool.

DDorwin: you could continue to explore a public server option.

YK: but doesn't a publisher have to negotiate a contract with all browsers?

DDorwin: we'll, again, come back to that.

TBL: you could design it such that the publisher's server could itself verify things. The protocol would need to be open.

YK: you could imagine that Google could open WV up.

YK: I don't believe that these are orthogonal issues.

DDorwin: Worst case is a very unique client identifier that gets transmitted. Now you have the problem of this identifier which anyone, in theory, could ask for. A permanent hardware persistent identifier is scary.

TBL: but that wouldn't be just anybody...

DDorwin: that depends on the implementation. What's to keep an ad network from doing this?

TBL: We can define this!

DDorwin: there's nothing normative about the UI in the spec.

TBL: question isnt' about EME spec specifically. About overall arch.

DDorwin: the ID problem and lack of forced encryption of it is a big issue. As part of introducing this to Chrome, we protect the ID in transit from the CDM to the license server.

TBL: but ads vs Netflix...

DDorwin: Netflix can see it, but ad networks can't. We put the encryption in to mitigate the privacy issues. The group could explore prompting or secure origins to restrict who can identify a client.

TBL: e.g., vimeo...I expect to know who I am. I have no problem with them knowing what device I'm using.

DDorwin: we have to ensure that that relationship is real and acceptable to the user.

TBL: when we're talking about watching a movie, not displaying icons, I expect that.

DDorwin: Having a license server anyone could download is theoretically possible. I can only speak for Widevine. The other server vendors are often making money from selling their servers. Widevine doesn't Widevine doesn't charge for the server, but a publisher would need to probably buy a license from these other vendors too.

DA: some of these other servers talk to other specific devices in the world.

DDorwin: yeah, having many servers is a problem for content providers. Some TVs do have multiple implementations. Android phones might only have Widevine built in, but iPads won't. Desktop browsers are a bit different. For TVs and other devices, this stuff is often baked in at manufacturing time.

DA: many devices have verified boot, e.g., chromebooks.

DDorwin: ChromeOS takes a different tack. Sony TVs, e.g., probably aren't going to change quickly. It seems easier for a content provider to run many servers than for there to be many DRMs on a single device or for there to be one DRM standard.

YK: I'd like to see Google license the bits that browsers need to new entrants. Would also like to see Google open up the publishing side so that it can become a defacto standard. That seems promising.

SK: is it part of Chromium or Chrome?

DDorwin: Chrome.

SK: what do other Chromium projects have to do?

DDorwin: they have to talk to Widevine. There's also licensing for H.264, e.g.

YK: Right, not trivial.

DDorwin: clients are generally free in order to encourage adoption.

YK: maybe it's obvious that it's easy to get already...

DDorwin: there has to be some sort of legal agreement and that's a problem.

YK: Google has a history of blanket agreements. E.g., Open Handset Alliance. It might be interesting if it were more obvious that you are trying to build an open ecosystem.

DDorwin: In some cases there are technical issues, e.g. for unsupported platforms in general.

YK: e.g., for a mantainer of a Chromium.

SK: Yandex mantains a Chromium. It's hard for plugin matainance.

PL: devil's advocate. Lets say YK makes Browser X and it's successful. Wouldn't it be in Google's best interest to exclude Widevine from them?

DDorwin: you can imagine a lot of scenarios where you can avoid that.

YK: e.g., engineering resources.

DDorwin: the problem is secrets. FreeBSD port would still need to be supported by the binary provider. DRM provider has to create/distribute binaries.

YK: seems plausible.

http://torgo.com/h264-meme.png

SK: <example>

TBL: why does the device need to trust the server?

(identifier)

SK: what if the cert is self-signed? Then you could imagine the user permitting it.

DDorwin: a cert you'd buy would need to be attested to. The Cert needs to say "I'm this software blob/device and I protect software keys and content in these specific ways". You can't just buy a cert and volunteer that "I do those things".

YK: can you imagine slots where this stuff fits in

DDorwin: you have to attest to the overall system. E.g., a TV design.

TBL: where, in a new browser, do you imagine plugging in a DRM blob?

YK: you imagine giving Widevine source and then they plug it in.

DDorwin: devices and browsers are different at some level. You can imagine something other than vertical companies doing the whole thing. Imagine auditors or independent attestation authorities that do the attestation.

YK: from a browser perspective, it's a more constrained problem.

AR: aren't most devices going to be more like browsers SRTL?

DDorwin: On a TV, DRM is often part of the platform. On the desktop generally, you need a blob of DRM. If you wanted to make a new browser on a TV, you'd use the platform DRM.

DDorwin: distribution rights and licenses are an issue. If DRM clients were based on more open auditing, with an entity responsible for vetting with an open repository of trusted devices, you could get rid of the proprietary server side if you have open protocols. It'd require industry agreement.

TBL: does it require a single person to do that? Any number of groups might make whitelists of devices. Governments, NGOs, etc. might be able to.

DDorwin: right, but content providers are likely to trust a few.

TBL: Netflix might have a full department to do it but an indie producer might just take a list off of github.

DDorwin: once there's a break in that chain, the content is in the clear.

TBL: right, but an indie producer might not worry as much. They won't be distributing multi-billion dollar 4k 3D stuff...yet.

TBL: I'm arguing for the little guy

AR: the current system is binary. No little-guys.

DA: another issue: CDM privacy discussion. Also logistical issue for this PM.

DA: SK raised a privacy issue. Can you summarize?

SK: there are several objections...first about the security, the license request contains something which is unknown to the user agent...

AR: but the impls that are any good are sandboxed

SK: but there could still be leaked information

DDorwin: there are growing non-normative sections in the EME spec about privacy and security considerations to help implementers decide to improve the quality of their implementations. The spec doesn't current say "MUST", and maybe that's the right thing to do, but the UA has a lot of responsibility when integrating a CDM to know what they're doing. In Chrome, we sandbox. But if you just slap a browser onto a random DRM API, you're asking for trouble.

DA: what about the sandboxing...SK you were highlighting risks to extracting information from the UA, e.g. location, which might have privacy implications. Or you can imagine that information being used in authorization decision making in ways that are bad for consumers. Does the sandboxing mitigate that?

DDorwin: in Chrome, yes. A bigger concern is devices. On Android, DRM is part of the platform. We IPC out and call it like a native app would. We know there's an identifier and we prompt the user about that. Platform DRMs have more issues. Even if it's not using GPS, it's a larger non-sandboxed surface area.

DDorwin: it's important that the implementation know what the CDM is doing.

DA: devices are top-of-mind. Primary use has moved to mobile devices.

DDorwin: devices have platform and hardware-based DRM and that can't be sandboxed. We have no guarantee from any protocol about what it's doing. So we have to rely on a relationship with a DRM provider to understand what's going on there. Android actually has an API that lets you plug in DRM from any vendor. So a hardware manufacturer can ship FooDRM. The Android API [MediaDRM] is DRM-agnostic. A browser that just exposes what's there creates a risk.

DDorwin: there are other risks. E.g., PlayReady is exposed on Windows, but browsers may not really understand it. UAs have a big responsibility to vet and understand what they're exposing.

SK: the EME spec doesn't have any mention of sandboxing. Would prefer it. Other implementers might do other things that aren't as good. Would like to have a concrete list of what data might be passed through the UA. Don't like the idea that DRM can do whatever it wants.

DDorwin: how would you spec that? There's no UA algorithmic steps.

SK: you could use WebCrypto and system key storage.

AR: so decryption happens in the UA exclusively?

SK: UA must display some dialog when a request for a license is being requested.

DDorwin: generally proprietary. It's an avenue to explore for a better solution.

TBL: is it a security or business issue?

DDorwin: it's a challenge. Signing some data. Attestation has to be in the platform. UA can't prove things about the platform if you're relying on platform capabilities.

AR: it's about layering. <explains>

SK: you can do lots of things there. Hardware ID, etc.

DDorwin: on devices, it generally includes hardware ID.

SK: if a master key is leaked then everyone can get at it.

DDorwin: Widevine put in a mitigation with crypto for identifiers. One of the normative things you can do for the spec is to prompt the user when accessing that identifier. There are 2 things: first, it doesn't make sense for a website to be able to silently access these APIs. Beyond that, DRM can be part of the system and who knows what it's doing. I don't know how you'd solve that in a platform-based scenario.

DA: there's a question about universal enforcement of rules which were written without universal enforcement in mind.

DA: want to bring things back to the EME spec and tweaks that we can make that make the proposition better.

DDorwin: there will be pushback. Many existing impls want to do what they are already doing. You can say "no, you can't use region restrictions", but I'm not sure you'll change implementations.

DDorwin: be aware that users aren't DRM system's customers and they compete on features. That's their history.

Technical Architecture Group F2F Meeting

21 Jul 2014

Attendees

Contents

Agenda Planning

Promises Guide

Specificaiton Reviews

Copyright

EME

Sumamry of Actions