Comment by JonoW | Hacker News Reader

Comment by JonoW | Hacker News Reader

Parent Full thread

I hear lots of objection to DRM in HTML but no alternatives. If EME is rejected and not added to the HTML spec, lets consider some alternatives:

1. Leave things as they are, so Flash and Silverlight limp along to serve DRMed content, and native apps are required to watch on devices which don't support plugins. Verdict: Not great, but hey it's how it is now.

2. Lobby the media owners to drop DRM. Verdict: Highly improbable

3. Lobby the media distributers (Netflix etc) to boycott media owners who won't drop DRM. Verdict: Highly improbable

4. Ask end-users to boycott purchase of un-DRMed content (and no pirate it, as they will only encourage the media owners to use more DRM). Verdict: Highly improbable. Us nerds may do it, but regular folk don't really care about DRM.

5. EME is implemented as a convention, but not in the official spec. Verdict: Possible, I think EME will be implemented in IE and Chrome with or without it being in the spec. Mozilla wouldn't I presume.

Can anyone think of any others?

We leave things as they are. If content distributors refuse to play without DRM, let them stick to inconvenient existing plugins. The DRM-insisting gatekeepers will ultimately need the web more than the web needs them, so they'll have to concede eventually, even if it takes a good while before it happens.

Why do they need the web? If the only way to watch Game of Thrones is to install a standalone application then people will simply install the standalone application.

I think this is the crux of the issue - should the web be a general purpose platform? Or do we draw a line somewhere and say some tasks, like watching protected video isn't something it should be doing. Personally I think all video consumption is a good fit for the web, it's seem awkward to split protected and unprotected video.

Ask browser vendors to include an authorization dialog before installing a CDM which describes what the CDM can do so that they can make an informed choice.

"The site xxx.com wants to install a module on your computer, this module has been signed by acme inc. Installing this module may be a requirement for consuming protected media from xxx.com.

In order to prevent you from circumventing policy; this module needs to make modifications to your computer as detailed in the license agreement (read here). These modifications will allow acme inc to read files on your computer, disable parts of your computer's functionality as specified by policy Z and may send personal information gathered to Acme Inc or selected partners

Allow?

Ok/Cancel

"

I think that option #5 is ideal. I don't believe that DRM belongs in the HTML spec. I see the spec as more of a toolkit to support whatever it is you need done (video/audio APIs, canvas, etc). DRM features should exist at the user level, preferably in the browser (as you have pointed out) or as it currently stands in an external plugin.

> I hear lots of objection to DRM in HTML but no alternatives.

To quote Thomas Sowell:

"No matter how disastrously some policy has turned out, anyone who criticizes it can expect to hear: “But what would you replace it with?” When you put out a fire, what do you replace it with?"

Reply on news.ycombinator.com