DRM/EME in HTML5 - an American thing | Hacker News Reader

DRM/EME in HTML5 - an American thing

ameliaandersdotter.eu

51 pointsTsiolkovsky46 comments

I find it amusing that everyone is acting like there's no DRM today and this is somehow an attempt at bringing DRM to the Open Web. DRM is already a required and de facto standard for the Open Web -- it's just hiding inside of NPAPI and ActiveX. It's there and it's even worse than DRM because there are no DRM plug-ins that don't bring massive runtimes with them that are the number one cause of security problems on the Web.

(If you do not have Flash or Silverlight today, you are not going to be able to watch restricted content. Pretty much everyone has one or both installed and will happily install it if it's not already on their system.)

Killing NPAPI and ActiveX, which is how DRM integrates with browsers today, and replacing it with a much smaller and considerably safer API is progress at shrinking the proprietary surface of today's real Web.

This is two steps forward and one step back, folks. This is positive evolution.

> DRM is already a required and de facto standard for the Open Web

How is it required? Browser makers have to implement it to adhere to standards? Site makers have to use it to adhere to standards? No, nothing like that. DRM is an optional junk now. Making it a standard promotes it to mandatory status.

Also, the statement that DRM is a "standard for the open Web" is an oxymoron. It's like saying that spreading disease (not vaccines) is a standard for curing. DRM is a complete antithesis of openness.

So, to correct what you said, it should read: DRM is already a required and de facto standard for the closed Web. And those who really care about the open Web should oppose DRM everywhere. DRM should be marginalized, through plugins and 3rd party non trusted black boxes which are hard to use and which are very apparently a problem. Not integrated with comfort through EME and the like, which only masks the problem, but doesn't solve it. To give a clear analogy - hidden surveillance camera is not better because it's hidden, it's actually worse because people don't think about it. "Unobtrusive", "comfortable" and etc. DRM is not better - it's always much worse.

Decreasing the API surface is a good goal, that's a fair point. However, in practice, the API surface will remain the same: IE will not remove ActiveX, Firefox (and a few other smaller browsers) will still have NPAPI, and Chrome has PPAPI. So this allows one use case to move to a smaller API, but that's pretty much it. A large API surface for proprietary blobs will remain.

Worse, things like iOS, Windows Phone, etc. have browsers that don't run plugins at all, but Apple and Microsoft may well add EME support there, which means an increase in their API surface that reaches proprietary blobs.

I don't think the plugin APIs like NPAPI are the relevant attack surface, because in most cases, they are only accessible with explicit user permission, i.e. by installing a plugin. We should be primarily concerned with what an untrusted page can do without user action beyond visiting it. In that sense, getting rid of Flash is a big win.

Is this getting rid of Flash, though? Many sites will still use Flash, and EME will not work in all browsers, because EME DRM plugins will only ship in browsers that manage to strike deals with Netflix/Hollywood/etc. - in particular, not in open source browsers.

Flash is cross-browser and cross-OS, but I suspect CDMs won't be. Netflix apparently doesn't mind "solving" the resulting fragmentation by encrypting everything N times, but users of other sites may not be so lucky.

Flash is only cross-browser and cross-OS for {IE,Firefox,Chrome} on {Windows,MacOS}. It barely works on Linux, doesn't work at all on iOS or modern Android, and is in general a huge barrier to adoption for free software. Not to mention its rich history of security vulnerabilities. The only reason Flash hasn't been completely abandoned yet is because it's currently the only widely-supported option for DRM.

Anyone who has worked extensively with legacy software can tell you that the procedure for removing a deeply hated but heavily used piece of code is:

1. Wrap the entire mess in a giant API.

2. Reduce that giant API over time by rewriting bits of the mess in clean new code.

3. Eventually you will have a few remnants that can't be rewritten, safely contained behind a minimal API like rotten food in a garbage bag.

4. Wait until the market forces requiring (3) are obsolete, which may take years.

5. Throw away the bag.

(1) is NPAPI and ActiveX. (2) is <audio>, <video>, <canvas>. (3) is EME, the trash bag that will let us isolate DRM from the rest of the browser. Don't fight against it on the basis of hating garbage. Everyone hates garbage, it's just that we're more interested in watching House Of Cards than in throwing it out right now.

Flash at least is a known quantity — it is possible to license to port to one's own platform (assuming one can reach agreement with Adobe on licensing terms), as was done for the Nintendo Wii (the port being done by Opera Software). Will the EME plugins (and EME doesn't even have a defined API, unlike NPAPI and PPAPI — so will likely be browser-specific even when they are available) be able to be ported by third parties?

An argument such as that can quite probably be made to build a business case against EME for a lot of device manufacturers shipping embedded browsers.

In fact, this isn't killing NPAPI and replacing it with a smaller API, it's killing it and replacing it with no API at all: there is no longer a public API between the browser and the proprietary DRM blobs, and in some implementations (e.g. Microsoft's) there's no seperation between the two at all.

Not only that, but in practice HTML5 EME is designed to allow the "proprietary surface" of the web to be extended right down to the kernel and hardware itself. Take a look at the existing Chromebook implementation of HTML5 EME used by Netflix for example: it's tied to approved Chromebooks which are locked down at the hardware level to ensure no unauthorised programs are running anywhere on the machine. Enable developer mode to run your own software and the EME module disables itself. The spec even has restrictions on how videos can be embedded in webpages to support hardware-level DRM.

Now, technically EME implementations don't have to be any more restrictive than existing solutions like Flash, but since they can be companies like Netflix are going to be pressured by content providers into only supporting implementations that are "secure" and give their "high-value" content the protection it deserves. Which means hardware-level lockdowns and restrictions on video outputs (the HTML5 EME spec already has an error code for playback being blocked because the video connector doesn't support DRM).

Wow! That make us wonder how Sweden(and Germany?) are advanced and sophisticated in technological policies over the rest of us; They got people from the pirate-party elected to the congress already? look at the all the issues they are discussing, and the high-level of the discussions..

Meanwhile, our governments or are in bed with the corporations or are unprepared to deal with their lobby in a way that dont hurt people, innovation, fair competition and democracy..

She has an X ray vision to this complicated issue and make someone who understand all the danger that come from this evil game of monopoly, feel more safe to have a good and prepared parliament to defend the interests of the people the way she is doing..

I think that is an example of what our democracies need to breath a new, revigorating air, and get stronger again with the faith and trust of the people

She's a member of the European Parliament, not the Swedish. That said, as far as I know we tend to have more heterogenous members in our parliaments, here in Europe.

Meanwhile, our governments or are in bed with the corporations or are unprepared to deal with their lobby in a way that dont hurt people, innovation, fair competition and democracy..

If you think politics in Europe (at the local, national and european level) doesn't have political corruption, I've got a bridge I can sell you.

ha! ok.. That's definitely spread all over the world, unfortunately we are not free from the spooks yet.. but what i meant is that they are a step further.. and think that countries with stronger industries and big lobby groups will have a hard time to elect and create real politics that can benefit the interests of the population in the digital rights ground..

So its not that they are not suffering from the same diseases of the democracies all over the world.. its the observation that by electing this class of representatives, prepared for the XXI century and the digital age, they are more prepared against those evil and corrosive effects on governments imposed by a industry formed in the XX century and with a hard time to adapt to new times

I find the funniest part of all of this DRM browser talk is that the people most in favor of this kind of standardized DRM are pirates. It's fairly easy to see why when you look at the obvious point that any DRM running client side can be cracked. By standardizing it into the browser, you only need to crack a single thing - the browser DRM module - and then you will have free and unrestricted access to all of the DRM content with no additional work.

It's the same way PS2 piracy was so rampant. You only needed to install a simple mod chip into your PS2, and since all of the DRM relied on that, you could now run every game with no additional work. It created something of a golden age for gaming piracy and the PS2 actually remains popular today in certain regions because of it.

So standardizing DRM into the browser is a huge boon for pirates, and a problem waiting to happen for everyone else. The stupidity is sometimes mind-blowing.

The proposed standard is just an interface to be implemented by the browsers. The actual decryption happens in a non-standard, proprietary binary module.

Yes, and there will be multiple of those, not just 1. Right now, Google and Microsoft each have their own (Widevine and PlayReady, respectively).

Not sure why you think this but the people most in favor of this kind of DRM are certainly not pirates. Also, I don't understand your PS2 comparison - how exactly did the DRM on PS2 enable piracy? It was a poor implementation of DRM that was bypassed. If they had no DRM it would have been even easier.

Otherwise most of game manufacturers would try to implement a different, custom solution (as for PC games) which would need to be cracked separately for each game, instead of a one-crack-fits-all permanent solution.

The hardware and the OS will hold the DRM, as far as I understand. That means that if say pirates break the DRM on Windows, Microsoft can patch it by next Tuesday.

That being said DRM by default in browsers (through EME) is probably the end of the "open web" - or at the very least the end of a "clean open web", meaning that everything will need to be hacked and cracked to make it work. Want to copy text or an image from a website? You'll have to find the crack for that website. Not to mention that doing that will be soon declared illegal (if it's not already from the moment DRM is applied to something).

This. I don't get why so many comments gloss over the fact that this isn't just about Netflix types of content, but something as simple as "view source" becomes banned outright. Its a step above when sites restrict right clicks because damn that image/whatever is off the hizzy and needs "protection"

Minification and obfuscation have often been enough so far but the slope we're sliding down is pretty steep and if TBL wants us at the bottom a lot of people are just going to follow suit. As someone who's finally embracing that development is increasingly being pushed to the web over native devices, I'm likely to be looking for yet another career shift (first from IT to software dev) before its all said and done. I do not look forward to debugging DRM when I already loathe minified JavaScript. Tooling is already abysmally slow in spite of Chrome's excellent dev tools (unmatched by any other browser or plugin IMO).

While I do understand the concept of protecting IP, this measure is inherently flawed right out of the gate. I'd honestly rather keep archaic Flash and not-so-archaic Silverlight around because at least their tooling is decent. I can't wait another 10+ years for this to catch up because everyone is foolishly starting from 0, not building on their successes (however much or little you define).

Comments 'gloss over it' because that's not what this fight is about. EME does not allow disabling 'view source' (unless I've completely misunderstood it). It's a step down the DRM road, but assuming that taking one step that way means we'll inevitably go the rest of the way seems hyperbolic.

https://www.eff.org/deeplinks/2013/10/lowering-your-standard... is where I got the 'view source' line. If its hyperbolic, the EFF does a very good job of pushing it.

I thought another article pointed blocking the command out in the spec but I could be totally wrong there. Even so, nothing is stopping anyone from building a dumb front end and placing the entirety of the logic in the DRM container. Netflix isn't an argument in countries where it doesn't apply, like much of the world. View source and the actual openness of the web would be that argument, however. If its a concoction made up by what the EFF believes this fight would go versus an actual result of the fight as it stands, then I sadly fell for it pretty hard. Its not a difficult leap to make but I'm definitely more interested in facts over opinion based on someone's failing attempt at predicting the future.

I think the EFF is engaging in some FUD themselves on this. There's some other project exploring ways to protect source code of web applications, and the EFF suggests that, now that the W3C has touched some form of DRM, that will be able to push a way for sites to disable 'view source'. I don't think that's realistic - minification and copyright work well enough to protect JS code already. I'm disappointed that the EFF is resorting to scare tactics like this rather than debating the actual issue at hand.

There is no standard W3C DRM. The W3C EME spec that uproar is about is only a plug-in interface for launching arbitrary binary vendor-specific blobs (just like the <object> element, except as a JS API on <video>).

A browser that is 100% compliant with all W3C specs (and nothing non-standard) will not be able to play a single Netflix video, because that requires (deliberately non-standardized) Netflix DRM Extension (CDM) to be licensed and baked into the browser.

I don't understand why they are pushing drm when they could implement a webbytecode (ie. the v8 ast as a loadable blob) and just do the drm on their own dime.

Because running it this way, Google, Microsoft and Apple can't exclude browser competition. With EME they can.

AFAIK, Apple is not participating in EME - has that changed?

Apple is, and has been participating in EME. Apple employees are active on the W3C EME-WG ML and they are regularly scheduled to attendance of Telephoneconferences by Microsoft, to which they appear and comment.

Microsoft has become the main lobbying party in pushing EME forward, with google mostly taking a passive role. There is no standard that W3C or WhatWG develop that was pursued as aggressively by Microsoft as EME.

The last time similar levels of "standards activism" by Microsoft are documented is when they corrupted an international standardization process to push the Open XML document standard trough.

I would be very worried if the EFF, Cory Doctorow, RMS, FSF, CCC, defective by design, WhatWG and a long list of other organizations agree against a standard, but Microsoft, Apple, Google and Netflix are closely cooperating to make it happen.

The (eventual) AC vote on progression is a simple majority vote — where there is one vote per AC representative (and one AC rep per Member). (The vote technically only happens if an appeal is launched with 5% of the AC in support, which requires one or more Formal Objections — but will almost certainly happen in this case.)

The EFF is the only person/org in that list of people who are Members. The rest — effectively — have no say. The Director practically cannot go against the majority of the AC (as they can just amend the Process to remove the Director's veto). You'll need to convince a lot more Members to vote against it. I see no evidence of MS having done anything underhand here — this is simply a case of a lot (quite possibly a majority) of Members wanting something a lot of people disagree with.

Thanks for the info! Are there any public links I could read more about this on? (specifically Apple's involvement and commitment)

1. The only way to have even somewhat secure Digital Restrictions Management is to have some proprietary binary on the local machine which can authenticate itself to the display device. This requires a level of access permission which you do not want to provide to the web in general.

2. If the DRM blob were delivered via the web, then it would be trivially easy to connect through a proxy that delivered its own ineffective DRM blob. Content companies would not accept this solution.

3. The goal of EME is not to increase the number of people who can access restricted content, it's to provide a replacement for the rapidly collapsing Flash Player pseudo-standard. The various content companies require their distributors to use something at least as good as Flash, but YouTube et al know that Flash probably won't exist in a few years, so the race is on to see which replacement will dominate the market.

---

The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. This position, in my opinion, is fantastically optimistic.

If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback.

How will the open Web advance if EME is added to the standard? Using HTML with DRM modules in a "standard" way doesn't make the Web any more open, than when that DRM is outside outside the browser altogether. I.e. while content companies are crazy bent on DRM, let them use their custom applications all they want. What's the problem with that? In time they might gain sanity and drop this useless junk. But their mind sickness is not a reason to pollute the standard with it as well.

HTML+DRM is closer to an open web than a locally installed proprietary application + DRM.

Those who are interested in open Web aren't going to use any DRM, and they could just avoid those external applications. Now they have to worry about disabling EME in the browser, and if that's even possible, since it's a "standard". I clearly see EME to be a setback to the open Web. If content companies aren't interested in open Web, let them stay outside it, until they reconsider.

> HTML+DRM is closer to an open web than a locally installed proprietary application + DRM.

HTML+DRM is closer to a fully locked-down proprietary-only DRM -web than a 3rd-party locally installed proprietary application + DRM.

> HTML+DRM is closer to an open web than a locally installed proprietary application + DRM.

No, HTML+DRM still requires, in addition to the EME API implementation, the actual DRM module. The DRM module will be a locally installed proprietary application - not something standardized, not open, not cross-platform not cross-browser.

There are currently 2 such DRM modules, one by Microsoft for IE and one by Google for Chrome. They are proprietary binary blobs, non-standard except for the small external API interface to EME, and are the result of private collaboration with content creation companies.

> The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video.

No, that's not the expectation of EME opponents. EME opponents understand that companies will continue to use restricted access, as they always have, but want them to do it off-spec and on their own dime.

> If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback.

That would be far less of a setback for the open web than the current state, which bakes the notion of restricted access into the open standards.

"off-spec and on their own dime" could also be written "for only the top 2-3 most popular operating systems". If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine, then that's a significant reason for users to buy the completely proprietary systems.

  > That would be far less of a setback for the open web
  > than the current state, which bakes the notion of
  > restricted access into the open standards.

If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized.

> If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine

The status quo is that Linux users are already locked out of Netflix.

The only reason that Cyanogenmod users aren't is because they can run the standard Android apk, which, incidentally, is a separate proprietary blob that Netflix had to write and produce on their own dime.

I'd rather vendors be forced to ship proprietary binaries that they have to produce themselves than for them to offload the work onto open-source browsers (or, worse, be able to pressure open-source browsers to cripple their own functionality in order to preserve DRM).

> If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized.

If widespread restrictions are going to exist, it's better for them to be less convenient for everyone involved (both consumers and distributors), not more.

Actually, the status quo is that Linux users are more locked out of Netflix with HTML5 EME than they are with the existing solutions. Silverlight is a small enough plugin that people have figured out how to run it under Linux using Wine, likewise with the Android .apk and CyanogenMod; but I don't think anyone's even managed to get the EME-based Netflix for Chromebooks to run with developer mode enabled let alone on different hardware, and IE11's EME implementation requires the whole of IE11.

And if the standard is implemented, there's no reason to believe the media companies will implement Content Decryption Modules for Ubuntu, FirefoxOS, etc, so what exactly would we gain?

> If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized.

Those widespread restrictions imply that only proprietary browsers and operating systems can use EME.

However "standardizing" the interface gives those proprietary companies the opportunity to claim that their solution is "standards compliant", while in reality the standard is a farce and their solutions are nothing of the kind.

First thing, Chrome is a proprietary browser platform. Only Chromium should be in the last sentence. I believe Chrome already ships with EME; I am not sure if that includes Google's DRM plugin for it as well, but if not then that is soon to come as well. Chrome already ships with various other proprietary code (Flash, SwiftShader, a PDF reader, etc.) so this would not be a new thing.

Google and Microsoft have been developing proprietary DRM plugins, with Netflix and Hollywood, for their browsers. EME is just a generic API to those plugins. So your comparison of what will happen with vs. without EME appears flawed: in both cases, only proprietary browsers that include DRM plugins, which are the result of private collaboration with Netflix and Hollywood, will be able to access content. And yes, that would leave out open source browsers like Firefox and Chromium - with or without EME.

I also disagree with the premise underlying

> The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. This position, in my opinion, is fantastically optimistic.

I agree to the conclusion - that it is highly optimistic to see Hollywood quickly move to unrestricted video. But you are assuming there is no other option. There are in fact several:

1. Watermarking as an alternative to DRM, that achieves similar results.

2. Non-proprietary DRM solutions, either standardized (which EME does nothing for, intentionally) or done in web content (HTML5). Those would not be as secure as proprietary binary blobs (what EME assumes), but could still prevent 99% of casual piracy - and professional piracy isn't stopped even by the blobs.

3. Eventual movement to unrestricted video, perhaps after a period of using 1 and/or 2. We saw this in music, it took a while, but sanity prevailed.

  > First thing, Chrome is a proprietary browser platform.
  > Only Chromium should be in the last sentence. I believe
  > Chrome already ships with EME; I am not sure if that
  > includes Google's DRM plugin for it as well, but if not
  > then that is soon to come as well. Chrome already ships
  > with various other proprietary code (Flash, SwiftShader,
  > a PDF reader, etc.) so this would not be a new thing.

I want to distinguish between a browser platform, where the browser is considered an integral part of the underlying OS, and standalone web browsers. Chrome and Firefox are regular applications, they do not (yet?) feature the deep OS integration that would be necessary to implement functional digital restrictions.

Google's DRM plugin is currently available for both Firefox and Chrome through the standard Netscape plugin API, but is not bundled with either browser.

  > in both cases, only proprietary browsers that include
  > DRM plugins, which are the result of private
  > collaboration with Netflix and Hollywood, will be able
  > to access content. And yes, that would leave out open
  > source browsers like Firefox and Chromium - with or
  > without EME.

If I'm reading the EME spec correctly, then EME plugins can be installable by the end user in the same way that Netscape plugins are today. Assuming the browser chooses to implement the plugin system, both Firefox and Chromium ought to be able to use DRM plugins from the system.

  > 2. Non-proprietary DRM solutions, either standardized
  > (which EME does nothing for, intentionally) or done in
  > web content (HTML5). Those would not be as secure as
  > proprietary binary blobs (what EME assumes), but could
  > still prevent 99% of casual piracy - and professional
  > piracy isn't stopped even by the blobs.

Any non-proprietary DRM solution would not be able to stop even casual piracy. The casual pirate will search for [download netflix movie], click the first link, install a browser extension, and get a one-step piracy button right in their browser.

That's what content companies are terrified of, and any DRM system that can't stop this sort of pirate will not be accepted.

  > 3. Eventual movement to unrestricted video, perhaps
  > after a period of using 1 and/or 2. We saw this in
  > music, it took a while, but sanity prevailed.

We have not seen a victory for free formats in music. The majority of music online is still distributed wrapped in layers of digital restrictions (e.g. Pandora, Spotify) or in patent-encumbered formats (e.g. iTunes, Google Play, Amazon).

> If I'm reading the EME spec correctly, then EME plugins can be installable by the end user in the same way that Netscape plugins are today.

They can be, but neither the browser vendors nor the content providers have to allow them to be, and the EME spec doesn't standardise any equivalent of NPAPI that standardises the interface between them and the browser. Browser vendors can (and it appears will in some cases, e.g. Internet Explorer) only support EME modules supplied by them and compiled into the browser binary; this is anticipated by the spec.

She makes a good point. Netflix doesn't work at all in Australia. This is very much an American thing.

Reply on news.ycombinator.com