3 ms·

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 a

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.

shmerl 13y ago
> 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.
azakai 13y ago
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.
- takluyver 13y ago
  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.
  - azakai 13y ago
    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.
wmf 13y ago
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.
- jmillikin 13y ago
  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.
  - gsnedders 13y ago
    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.
makomk 13y ago
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).

shmerl 13y ago

> 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.

azakai 13y ago

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.

takluyver 13y ago
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.
- azakai 13y ago
  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.

wmf 13y ago

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.

jmillikin 13y ago
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.
- gsnedders 13y ago
  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.

makomk 13y ago

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).