archive etherpad notes
New page
This is an archive of the Mozilla [[Summit2013]] session [https://etherpad.mozilla.org/drmwtf DRM WTF Etherpad]
----
Welcome to the Mozilla Summit Santa Clara
DRM WTF session Etherpad!
Session hashtag: #drmwtf
== URLs ==
URLs:
* https://etherpad.mozilla.org/drmwtf
* https://wiki.mozilla.org/Summit2013/Sessions/Sunday#DRM_WTF
* W3C Encrypted Media Extensions (EME) Draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
* EFF's Formal Objection to the HTML WG charter: https://www.eff.org/pages/drm/w3c-formal-objection-html-wg
== Contribution License ==
By contributing to this Etherpad, you agree to place your contributions in the public domain according to CC0: http://creativecommons.org/publicdomain/zero/1.0/
== Attendees Notetakers ==
Attendees / Notetakers:
* Tantek Çelik - http://tantek.com/ - @t - co-facilitator
* Johnny Stenback - @jstenback - co-facilitator
* Timothy B. Terriberry - @derf - Media Engineer
* Bill Walker, Apps and Marketplace
* James Bennett - @ubernostrum - MDN
* Owen
* Greg Maxwell - @gmaxwell
* Rob Helmer - @roberthelmer - web engineering
* Hsiao-Ting Yu "小B (Xiao-B)" - @littlebtc - Web developer
* Rui You - @Med0paW - Software Engineer
* ... add yourself
* ...
== Notes ==
=== Other vendors DRM ===
Other vendors' DRM solutions:
* Google has widevine (http://www.widevine.com/)
* Microsoft has playready - http://www.microsoft.com/playready/
* Apple has fairplay?
* Amazon streaming also uses Silverlight.
* Hulu uses Flash Player Access.
Netflix usecase:
Works today in Firefox using Silverlight plugin
everywhere but Linux. but works with WINE on Linux?
Google's widevine works in ChromeOS and Android.
Widevine - there is a plugin for Macs, and it works on Android as well.
If you enable Chrome developer mode, suddenly the DRM scheme doesn't work right now.
EME spec doesn't actually specify the DRM mechanism, so what does that mean for a site to support DRM across all those different platforms (OS, Browser) does the site have to support each of them.
The EME spec defines an interface between Javascript and some kind of content-restriction mechanism underneath. It's a message passing mechanism. You have one file (media file), there are a bunch of keys. The message exchange tells the CDM underneath how to unlock one of them.
In order to support each of these systems, you'll need to have one of the keys specified for that system. It does not require reencoding the file for each system.
You can serve up JS that figures out what you have and picks the right one.
So you'll end up seeing content providers not bothering with reencoding. Or not - all they have to do is put a key at the front of the file and run a server that speaks this messaging file. It's not "I have to reencode my entire media file".
This calls into question the W3C's motivations. Reminds me of when WHATWG was formed. The EFF had a great article - does this open the door to start requesting whatever feature they want, and as long as they can pay off the W3C for it...
DRM is going to happen whether it is in W3C, or IETF, or elsewhere.
Also worried about uses other than video.
Is this something we actually need?
We can try to nudge Hollywood into other directions, but they have billions of dollars to throw at people to do what they want.
Do we nudge so hard that we make ourselves irrelevant?
How many people watch Netflix on their browser? (several hands go up)
Is FirefoxOS going to ship on TVs?
Is there any alternative without completely destroying the business models?
If there is a good alternative for the Hollywood companies / copyright holders, where those companies can still make money, then there is a good way out of this.
If you had this magic alternative, how would you convince the other browser vendors? Would depend on how the alternative works.
One problem is, this is how they do it now, Access / Silverlight - DRM through NPAPI.
If we say, you cannot do it the way you do it now with the open web, then we have to tell them what they do instead.
The technical beauty here is that we standardize the way to do DRM, having a nice, small API. Bad thing is that the generality makes it reusable all sorts of places. Next thing the eBooks people will want to DRM this and DRM that. They won't have to make a big investment to figure out Silverlight etc. The UX won't suck as much as it does now (installing plugins, having no OS-standard widgets in Flash, etc.). We'll end up spreading DRM.
The actual content decryption modules, what will they be tied to? Everyone in the market besides IE are open source browser engines. Will there be a certification process? Browser executable with this hash? How does that effect someone who wants to hack their local copy of Firefox or Chromium?
If you give the content providers an inch, then they'll take a mile. If you give them EME, then they'll ask for more. Aren't they already asking for a mile? So we need to take a hardline and tell them no.
Right now the EME draft does not have a security provision. There is no guarantee that the keys are not accessible to the end user.
Is that like DVD? Where there's no guarantee that the keys are not available to the end user? Pretty much. [quote from EME draft]
We can't predict the future, but we can look at what Chromium does today. The actual widevine CDM is not in Chromium, but the interface is. The spec requires a simple AES128 decryption service just to be compliant. But there's not certification of the actual Chrome binary. If you modified your binary, they wouldn't know the difference. The CDM is sandboxed, Chrome doesn't have access to it.
What's stopping someone from writing an addon for Firefox that proves the whole spec insecure? Nothing.
I worry that we are trying to make a DRM system that makes sense and that's not possible with an open source system.
The minute we implement the API, there'll be a StackOverflow question about here's the line of code to change and recompile your Firefox.
Marginalization?
If this gets proposed and it fails, then will they go to Congress? They go to Congress all the time, they know this is not foolproof. They're going to ask for different things.
If we prevent that slippery slope by taking a hardline, no DRM.
There's an opportunity here in Mozilla's discussion about DRM to point out where that hardline really is.
Content providers seem to have a greater voice in Congress than the other side.
Are we even doing a hardline today? We're not. That's what the NPAPI plugins are. How is this (EME) different than that?
Our general purpose plugin API is worse. But we can say it's not our fault.
If we stop and we say we're going to do no DRM at all, then what incentive does Hollywood have in their interaction with other browser vendors to not strive for the most evil thing they can?
However if we say we'll implement this narrow API and put you in a sandbox, and make sure you can't verify our binary, nor spy on our users, but we'll give you this API you asked for.
If they're happy with an executable in a sandbox, why wouldn't they be happy compiling to asm.js? The problem is the CDM is doing the video decoding too.
It's doing the decoding inside the sandbox, and you're not doing that in JS in HD on a mobile device. Maybe 10 years from now. But not today.
What is Chrome's and Microsoft's financial incentive? You sell licenses for the CDM servers. They have other financial incentives as well. Not just arm-twisting. Content providers are conservative.
Going back to plugins. People can just install a binary outside their browser too. The answer you would use this infrastructure over a plugin, and a plugin over a binary. It's a more uniform target. A lot of people are saying "this is great I can lock up my ebooks and javascript games".
There's an opportunity here to set better limitations on how the EME stuff works, to preserve more user freedom.
The really important part is to prevent the disease from spreading.
Audio is fairly *not* DRM'd today. Largest vendors give away audio files with watermarks. We don't want a regression.
There's already some indication that the ebook industry is willing to move away from DRM.
DRM-free music came up because big labels were afraid of Apple and wanted to use Amazon too.
Now the book publishers are afraid of Amazon, and they may go DRM-free as well to be able to go outside of Amazon.
Historically, regardless of what ideological decision we make, the market forces may cause DRM-free anyway.
What's interesting about EME, is that it doesn't make DRM less of a pain in the ass. There's still a different CDM per browser. Still painful to do this serverside to make this work. EME doesn't make it easier. It gives us some control over the sandbox.
It feels like this is like there are some really good aspects, even though the reasons they're doing it does not align at all with the way we do things.
There is an improvement in usability, but it's still not very usable. You're still not dealing with shifting plugin API interfaces. It's important to be mindful of what we're enabling.
Do we have any leverage to demand that the DRM allows offline use or allows users to get their content free after a few years? No. EME does not define a rights model. Other systems have a complicated rights models. EME is explicitly saying we are not covering any of that. No rights model built into EME. It's not suitable for offline file DRM. It can be used for Netflix streaming case, but you'd have to extend it all kinds of ways to make it work for the offline use-case.
This is an opportunity for us, because we have some leverage, but not total leverage because we cannot say no.
Maybe rental DRM kind of makes sense. Just purchased DRM use is bad. Any offline DRM is user hostile and we don't want to go there.
In the Netflix case, the audio is not encrypted. Hollywood does not demand them to do that. Audio is a different rights holders model.
Kind of ok with DRM for audio streaming but you can buy something for a $1 without DRM.
Is this something we can wait a year or two? Are third parties using this? Chromecast.
When Netflix stop supporting Silverlight, we're going to be compelled to act. What's the time pressure?
Even if we talk about Silverlight going away, there are performance issues that are going to be bigger over time. If you look at Silverlight in Safari vs. Firefox on MacOSX there's a problem. That can only get worse. With the competition moving to EME, they're getting better performance.
If we can manage to kill-off NPAPI plugins at the same time, people might not be that mad.
We can still fight the power and do something (e.g. PIPA/SOPA). We have a unique position when we go to DC.
We can make it opt-in.
With FirefoxOS and needing this, I don't know if some of these cellular networks are setup for streaming video content. People use FaceTime over 3G networks - that's two way video streaming.
Are getting pressure to put this in FirefoxOS as well? Desktop is ceding to mobile...
What would be the next fight? Are there ways of pre-empting?
The content producers are the ones making these demands? What about India? They're very aggressive in India too. Very protective of their rights.
The most powerful content providers are in the US. Those that make the most pressure for schemes etc. Content out of the US, especially video content, is worldwide. That content makes most of the money. Where most of the money is, is most of the power.
On the mobile side, whether or not the networks support it doesn't matter because you can always get the bandwidth over wifi.
Netflix can provide their own app on iPhone or Android. But that's the problem for FirefoxOS - how do we compete there? Also problem with native apps by other content providers too - video that's not available on Netflix.
Would you rather have someone run a native app or a web app?
Media team is concerned too, considering just allowing certain codecs for privileged apps. Could do the same for EME, make it privileged, and make it *only* for devices, and it doesn't get out to the desktop.
Do market forces give us any kind of safety valve?
Can we do something to help those market forces? E.g. give an option for DRM, but encourage non-DRM.
Can we encourage richer experiences e.g. popcorn.js when running without DRM? Not sure if this is a good idea or not. Are we penalizing the right people? The idea of taking it out on the users is abhorrent. Can we create a market force that affects smaller players?
Barrier to entry problem. Bigger guys start doing "website plays best on (something that's not us)" which makes our users have to choose to use us (Firefox) or not.
Is it feasible that a company like Netflix could say only available on Chrome?
Here's a really crazy idea - the one thing we could bring to bear is lots of users and lots of computing power. What if we made it possible for Firefox users to contribute their compute/storage power to allow content creators to distribute/transcode for free if they agree to our terms. User choice. Open media. Open codecs. Our users could contribute the pieces they have - CPU power, disk space. Not sure how this would manifest itself or provide enough incentive. It could be something we could offer. Make it a call to action, opt-in. Then approach content creators, and say, this is what we can offer you, and we're hoping that you will join us. Maybe we can get independent film houses approaching us. Gets thrown into the Mozilla cloud. And then it gets hosted in the DRM-free solution. Not mutually exclusive.
The problem is how people make money. It's much easier to buy DRM free music than buy and rip a CD.
Why don't we push back and say, watermark?
It's a solution for audio at rest, but not streaming audio.
Watermarking has a place in this environment but don't see that happening in the next small number of years. Probably need some sort of cloud solution.
The point about being so much easier to buy the track than to rip it - something we can offer - the thing that pushed that is Apple built the iTunes store. Amazon built their store. They made it stupid easy to find what you want and buy it.
Right now movies are still in the fragmented, Apple / Amazon / Netflix has their own things. If you want to talk about making it easy so people buy things rather than pirate them, you have talk about ease of access.
The industry has seen how successful Apple is and they now fear that. The industry is terrified of letting iTunes sell it (video).
The video guys have been watching the RIAA go sue everyone, and instead of that approach, they spread their catalog around.
Piracy rates are way higher for video too.
Or make DRM hard, or make it easier to make to distribute without DRM. That's got some legs. But it's long term not short term.
Something evil is probably going to happen. We want to make it the least evil we can and still be relevant. There's some cool ideas here and we should try to put some energy around them.
We know that there are things that are cooking. Watermarking is somewhere down the road.
== Questions ==
Q: How should Mozilla position itself on the general question of DRM, and specifically the Encrypted Media Extensions?
EME single attack surface, sandbox. One good aspect of this is that this is pain in the butt for everybody. And it especially hurts the little guys. Costs them more serverside to implement DRM than they're going to make selling their content.
Alternatives: building tools to distribute content, indie film makers that want to get their content out. That's exciting.
We could release a WebRTC-based reference streaming implementation. LouisCK might use it and make money, and then the bigger players would pay attention.
We also have a marketplace that sells apps. Shall we do that with DRM-free video too? With marketplace we are also saying we are not *the* marketplace, you can do it yourself too. It's almost similar to identity. We didn't want to become a centralized identity provider. We want to encourage federated identity. Connect people that want to buy and sell. Federated commmerce.
Q: If we want to support Firefox via partnership can we support that on every platform?
It's up to the CDM. And there is none for Linux. Does Chrome for Linux have support? Only ChromeOS.
Q: Who will wontfix https://bugzilla.mozilla.org/show_bug.cgi?id=923590
We should mark this bug a duplicate with implement EME.
Context for the bug: someone or random person filed a bug, that said Moz should commit to never implement DRM. Got pick up on BoingBoing. Lots of comments on the bug.
We could ignore it. Or OTOH it has some visibility, and maybe it merits an official response. E.g. other browsers have implemented it, maybe we need to respond.
It merits a response but bugzilla is not for that.
It's very difficult when you have a bug when you're trying to have a conversation between engineers reviewing patches and people fill a bug with random comments.
We already committed to implementing unencrypted DRM lite?