"protected content distributors are not, in general, switching to unprotected media. Instead, they're switching away from the Web entirely."
Good. This is what we want. This is what victory looks like. They are perfectly entitled to homebrew whatever weird little network they want, which is about as likely to compete with the web as Blockbuster's braindead internet video rental system was.
Eventually they'll decide they're tired of not making money and come around. Until then, they'll continue to get robbed by the professional pirate crew at YouTube, etc. Not my problem.
The only way the open Web can lose now is if it makes the deal with the snakeoil
DRM devil, which works¹ just well enough to be dangerous but excludes large swaths of users, opens up gaping security holes in everything and generally makes everyone's life difficult.
¹ works=plays, not that the content protection stuff works.
As far as I'm concerned It's a good thing that there are too many DRM'd technologies.
They are all stamping on each other, engaging in corporate infighting, patenting the underlying DRM technology and so on. Apple want their walled garden, Google their one and nothing from one store plays on another's device. And content providers keep demanding all their resellers implement the stuff dispite anyone being able to grab anything off the PirateBay.
As a result the clear path is to avoid DRM and go with formats that play anywhere. Or people will just pirate everything.
Having one DRM standard that does play everywhere could provide a kind of unity amongst DRM. This is dangerous, we don't want that crap getting stronger. It could lead to a point where consumers are fine with DRM and are not pissed of because they can't play their iPod music on their new Android phone. People becoming accepting of DRM doesn't seem like a good outcome at all.
Fortunately that isn't what we are likely to get. The standard doesn't specify any actual DRM mechanism so they will keep having their walled gardens and competing technology, they will just be able to put them in a HTML5 UI instead. So in the end adding this to HTML5 seems to be totally pointless. Vendors could already implement their own extensions to HTML5 this is nothing more than a 'put drm here' hint. It's unlikely that vendors would implement anything that would allow competitors content to plan on their platform.
Unfortunately, it doesn't look like it will actually avoid any of the proprietary mess. The encryption/decryption framework is still based on proprietary blobs that will have to be distributed. And they can be distributed with prejudice.
That is, just because you're on a browser that supports this exchange standard doesn't mean that you'll have access to the blob that actually does the decrypting. The major distributors will just continue their current strategy of platform/device lock-in.
I had gone into this thinking it would be a cool way to easily allow protected/authenticated cross-platform playback. But it does nothing of the sort. Content providers will still discriminate, and we'll be powerless to stop them. This just provides a common API for their discrimination. So... I guess that's something?
It's not only on their own platforms. Every time someone downloads a movie from iTunes and has it not work because, surprise, you can't do HDCP over VGA to your projector, is a success.
> But the claim is disingenuous when used as an argument against DRM. Deprived of the ability to use browser plugins, protected content distributors are not, in general, switching to unprotected media. Instead, they're switching away from the Web entirely. Want to send DRM-protected video to an iPhone? "There's an app for that." Native applications on iOS, Android, Windows Phone, and Windows 8, can all implement DRM, with some platforms, such as Android and Windows 8, even offering various APIs and features to assist this.
> In other words, the alternative to using DRM in browser plugins on the Web is not "abandoning DRM;" it's "abandoning the Web."
This shows a lack of understanding of what makes the web great. There's really no difference between a native app and a EME backed DRM layer. The web isn't about the browser window that it resides it; it's about content rendering the same on every platform. A page using EME is not going to render the same on every platform.
This is the status quo, with development costs being shifted from media companies (who no longer have to write separate apps for every platform they care about) to the platform owners who have to implement an approved DRM scheme or get their own scheme approved.
This is pure bullshit. EME doesn't change how something is rendered, only whether certain content can be delivered at all. And we already have existing standards-backed cases where different platforms get different content (or no content at all). Coincidentally, it affects the exact same thing EME does: media rendering. I can deliver an H.264 video and be standards-compliant, yet rendering differently in Safari vs Chrome (because Chrome refuses to support H.264).
Sadly, it appears impossible to reduce it, because the companies involved cannot come to a solution that works for everybody. So the two choices are 1) allow for this in the standard, or 2) throw your hands up in the air and not standardize it at all.
We've already tried the "not standardize" route. It didn't work out very well.
> Rather, it defines a set of APIs that allow JavaScript and HTML to interact with decryption/protection modules.
Which are non-portable, and only work on particular devices.
Which is:
* the opposite of open.
* a return to "you'll need browser X on OS Y to use this website"
Early versions of iOS and Android were hampered by non-open web until those technologies faded away.
Our next OSs - Tizen, Firefox, Valve box, Ubuntu if they ever get their shit together, whatever other unknown unknowns - won't be able to access any of this content.
I sit right beside a W3C member all day who assures me this is 100% the case (and will at some point blog about exactly this).
Whenever you do anything on the web your browser is talking to a whole stack of machine specific stuff, graphics drivers etc. The browser is just an abstraction layer on top of this.
I don't see how this would necessarily be worse than the current status quo. Big content providers who demand DRM are just using things like Silverlight instead which don't provide any official support for any of those OSes so they can't access that content anyway (without some wine hacks).
At least this way it is possible to produce a Linux variant that does support these things without having to ask MS for a silverlight port.
These abstraction layers solve problems. Propietary DRM binary blobs try to solve a problem that is impossible to solve: how do you show content to someone and simultaneously hide it?
So the only way out is to make it inconceivably expensive for an attacker, which leads the way to obfuscation, and eventually, as we have seen, invasive technology like kernel modules and other nonsense. They keep on adding abstraction layers, but the other way around: going ever deeper.
I personally see no value in providing an API to someone trying to solve the halting problem. Especially not if the next step is having them pressure us into installing their distributed halting problem solver.
Well I agree that it largely seems like a waste of time, but I don't get how it necessarily makes anything worse.
If you don't want the kernel modules etc you can still use an OS that doesn't package them or allows disabling them. You will still be in the position you are now.
I know the prevailing attitude here is anti-DRM at all costs, but I think this argument hits some incredibly good points. Basically there are only a few options for delivering available to companies like Netflix:
1. Write native apps
2. Use HTML with a plug-in
3. Integrate DRM into HTML
4. Don't use DRM at all
I don't think that option 4 is realistic in the near term, as much as we'd like. Maybe one day we can get there like with music. I do think that TV and Movies are a much different market, where rental is more attractive than purchase, so it might not be totally viable.
That leaves native apps, plugins, and DRM support in HTML. Can anyone who thinks the web model is the best way to deliver content and apps reasonably argue that DRM in HTML _isn't_ the best of those?
For more fringe platforms, a standard like EME is the only hope for support from mainstream contest providers. Without something like EME you're at the mercy of the providers cost / benefit analysis: are there enough paying users on your platform to justify the costs of supporting it. With EME you're at the mercy of the platforms cost / benefit analysis: are there enough users of all the content providers to justify supporting EME. That is more likely to be true.
Yes, there are problems with supporting fully open systems, but those were there anyway, without EME. If you choose to only run OSS without hardware DRM you might have trouble watching Netflix. My guess is that that's ok with you on principle.
So you don't use any of Netflix, HBO Go, Amazon streaming, iTunes movies and TV, Google Play, Hulu, etc.? (I suppose you also don't use DVDs, BluRay, PS3 or XBox?)
That's fine, but you can't expect all consumers to be the same. Most want access to the content more than they want, or even care about, DRM-free access.
It's a power struggle. Does it really make sense to change the web for the convenience of money-making companies ? DRM hasn't taken over the web yet because it's not convenient. What will happen when it becomes commonly available ? Will Firefox be able to survive ? I think it's worth having these conversations instead of just going ahead to please Netflix, Microsoft and Google.
Can someone please explain to me what netflix's DRM actually entails? I mean if something appears on my screen, it can be captured and there's pretty much no way for netflix to stop it from being recorded?
Can I get something clarified here, because I'm a bit confused about one aspect of this.
So these DRM extensions are platform-specific binary globs that will be simple to talk to via JS. The idea being that you write an HTML5 page that has a <video> tag in it, which takes content from a URI, passes it to this binary blog, which then returns you something to render. (basically, don't worry if I got the API wrong).
These binary extensions: who writes them? Is there going to be a generic "Windows" DRM binary blog that gets called if you're on Windows for YouTube, Netflix, HBO, etc? That's written by (e.g) Microsoft? Or are you going to have to install DRM binaries from each website, like drivers, into your system?
If it's the latter, how the BALLS^ does anyone expect that to work on linux, or more importantly (in terms of tasty tasty money) iOS? Do they actually expect it to work on iOS, or will they just deliver content through apps? If it's apps, what problem is this solution solving exactly? Is it just a way of getting rid of the downsides of flash? Because in terms of cross platform compatibility it's obviously creating its own issues.
^I wouldn't usually talk like this on HN, but I think it's warranted here
The DRM plugin (called a CDM) would probably be provided by the OS. So iOS & OS X would have Fairplay, Windows would have WMDRM, Chrome OS has Widevine, Android would be a mess, and Linux would have nothing.
The problem it solves is the following: Netflix needs DRM to get content deals, Microsoft wants to get rid of Silverlight which Netflix currently depends on, Google wants to be able to play Netflix on their Chromebook. All would much prefer if DRM was painted in the positive lights of HTML5.
Silverlight and Flash are reproducing the browser's HTML5 video functionalities of decoding and displaying videos. EMEs are the minimum necessary to add DRM to this existing setup.
They don't care about iOS or Linux, they're just pushing forward their aligned interests.
> Mozilla, in particular, is fighting this very outcome. The underlying justification for its development of the Firefox OS smartphone platform is that it wants to ensure that the Web itself is the application platform, and that software and services aren't locked away in a series of proprietary, platform-specific apps. And yet, it is precisely this outcome that opposition to EME will produce.
It's not in Mozilla's interest to support EME because they won't be available for their platform. They're essentially plugins with a narrower API and I don't see how it would make sense to have them if you have access to the source code and the decryption key.
If EME gets ratified as a standard, the w3c has effectively declared itself corrupt to the point of no longer being useful and no longer relevant to the future of the web.
W3c approving this is w3c approving its own resignation as a standard organization. I'd rather not see that happen.
How is shrinking the surface of the required proprietary, platform-specific binary blob from "the full application stack of Flash or Siverlight" to "just the DRM bits of Flash or Silverlight" not a step forward?
I should have said Flash is available for IE, Chrome, Firefox, Opera, and Safari for Windows, Mac, and Linux. Considering that some of those browsers have a "no new plugins" policy, it seems likely that they will not allow any third-party CDMs. Thus it's hard to imagine that any single CDM will reach a 95% desktop install base.
Ah, I think I get it. You're saying we should keep content locked up in Flash indefinitely because you don't believe that a better solution can get the penetration of Flash? Is that right?
I think content providers (and users) would gladly retire Flash if they could "lock up" their content in EME instead.
The CDM API should make porting to multiple platforms easier because the browser implements all the non-DRM infrastructure like networking and playback. That said, I don't really expect Linux to suddenly be a top priority for Netflix or Amazon. On the other hand, a CDM is bright red bullseye for crackers. :)
I also see them as equal, but I'd say I'd prefer the one that implies no official endorsement of a closed system by an open standards committee. That Flash also happens to be the one with more adoption is a bonus point.
"Even if W3C decided to drop EME, there are enough important
companies working on the spec—including Netflix, Google, and
Microsoft—that a common platform will be built. The only
difference is whether it happens under the W3C umbrella, or
merely as a de facto standard assembled by all the interested
parties."
Someone tell this author that when you see a horrific 10 car pileup, you're not supposed to say: "Well at least it happened on OUR land".
they're unlikely to even notice if one or two videos (for
example, one of the Netflix-produced broadcasts like House
of Cards or the forthcoming Arrested Development episodes)
are unprotected. It wouldn't make a difference to them.
I'd notice. The only reason I'm considering getting Netflix is to watch Arrested Developent. However, I basically only have Linux machines and so I won't be able to.
1. "Even if W3C decided to drop EME, there are enough important companies working on the spec--including Netflix, Google, and Microsoft--that a common platform will be built. The only difference is whether it happens under the W3C umbrella..."
This is probably true, but that doesn't make EME a good thing. Okay, so some powerful media companies are colluding to develop a shitty content delivery platform. How does that at all entail the idea that HTML should throw support behind it? Just because it's going to happen doesn't mean you have to officially endorse it.
2. "Deprived of the ability to use browser plugins, protected content distributors are not, in general, switching to unprotected media. Instead, they're switching away from the Web entirely."
I really don't see this as a problem. The web simply doesn't need these DRM-enamored content distributors. It will do fine without them. In fact, if the web loses them, the web wins.
3. "Opposition to EME will produce" a situation where software and services are "locked away in a series of proprietary, platform-specific apps".
This is just a stupid thing to say. DRM requires a series of proprietary, platform-specific apps, regardless of how they're implemented. The proposed CDMs (content decryption modules) that EME requires are also proprietary and platform-specific. They are quite simply no better than traditional HTML plug-ins like Flash or newer delivery platforms like native mobile apps. "A rose by any other name". Except that DRM doesn't smell sweet at all.
4. "A case could be made that EME will make it easier for content distributors to experiment with--and perhaps eventually switch to--DRM-free distribution."
While it's technically true that EME might make it slightly easier for such experimentation, that's really besides the point. Ease of implementation is absolutely not what's stopping these content distributors from such experiments. Business politics is what's stopping them. If a business decides that it wants to try a DRM-free model, it will try it. The implementation details hardly affect the decision.
The main argument here seems to be having a "testing ground for unprotected content".
We have had a testing ground for "unprotected content" for several thousands of years, from stone tablets right up until the CD. I would say it works pretty well.
Judging by their actions, it appears that their goal is to merely make their product harder to consume. It's self sabotage / destructive behavior, but they appear to ignore any appeal to reason.
It's a crappy solution, but if they want to cripple their service I don't see it costs me anything. Heck, it may even work out better in the long run - the less trade you do with someone the less intelligence you have on their activities, and people have something relatively simple to get into the habit and skillset of disobeying authority on.
It's always going to be necessary to have people with the skills to circumvent authority. In the absence of external selection pressures keeping society honest mutation and internal interest groups ensure that you'll diverge from an acceptable standard of living.
This doesn't seem like a bad thing for my interests. It may be a bad thing for the interests of those who just want everyone to be able to go to any webpage, click a button and go, I suppose.
I think there are many great comments already on the w3 site regarding EME, but it seems the main and strongest arguments are still:
1. Why should the w3 bend, kertow, or even care about the content business model and profitability?
2. Why should the w3 with a supposed focus on openness even consider adding in something like EME?
3. Who are these mystery users, apart from the content barons, who are apparently in full agreement that we really do need Digital Restrictions Management in the browser?
Providers refuse to provide DRM-free video now because they know that as long as nobody takes the plunge into DRM-free, they can wring marginally more money out of every customer with DRM. But once one company takes the plunge into DRM-free, this model is over. Customers will demand it of the other companies, and the ones who want to stay in business will have little choice but to abandon DRM and the unethical-yet-slightly-more-profitable models that depend on it.
This worked for music. All signs indicate that it's working for books, though that is still in progress. It will work for video, too, if we let it. All that's required is a few more years' worth of patience. Unfortunately, the W3C doesn't seem to get that.
I'd be curious what the effect of DRM on movies is to the bottom line for holywood.
I mean what the DRM software does is make it harder for me to save a copy of a netflix stream to my harddrive to watch later after my netflix subscription has expired.
But it doesn't make it any harder for me to hit up the pirate bay and download the exact same content minus the DRM.
Hollywood has a serious piracy problem with all their content distribution channels. The entire industry is dependent on a network of third party distributors (theaters, DVD duplicators and retailers, hotel PPV, cable channels) that would much rather profit off films without paying for them. Hollywood spends tons of money and effort enforcing these deals, plugging leaks, and putting down the criminal syndicates acting as middlemen in the pro piracy world.
The possibility that Internet video distribution will open up new and interesting ways for their distributors to rip them off keeps Hollywood execs up awake at night.
Until very recently (or possibly, the near future) it hasn't been possible to do large-scale, for-pay video distribution on the Internet without doing a bunch of intrusive tooling on the client side to make the streaming work right anyway. They might as well demand that Netflix, etc. build in DRM while they're at it. I would also be really surprised if Netflix's DRM systems weren't tightly integrated with the accounting and auditing systems that measure what Netflix owes the film distributors.
Basically, you're not the target of the DRM systems, and "Content Protection" is a perfectly reasonable thing that's effective enough everywhere but the last-hop retail streaming to users. There, it's just an afterthought and a habit, not something that actually helps the bottom line.
DRM is about protecting future revenue streams, not current ones. Once you've bought a movie on iTunes you're locked into using it the way that the media company and Apple have agreed upon. You cannot watch it on your Xbox or vice versa. You cannot transfer it to more than 5 devices. You cannot come up with a creative new way to play the content. Rather, any innovation has to be first approved, allowing the possibility for you to be charged for it again.
So really it isn't anything to do with stopping piracy (since the pirates can just pirate anyway) but to try and make non-pirates possibly pay multiple times for the same content?
Why would you even want to save a Netflix stream? You can generally find pretty good blue-ray rips of whatever Netflix has which would be higher quality since they don't have to be low-bitrate enough for streaming. Not that I'm saying Netflix itself is pointless, just that archiving things from Netflix streams is pointless.
And I see that not saving downloaded data to be wasteful. If I download it, I should be able to play and replay it without further data transmission. And being able to 'download vid, watch later' would be nice with a netflix model.
I can understand not caring about junk like cat videos: they are watch once, delete. Streaming makes sense.
Aside that, the pirates fit my wants better than the ones that want my money. I'll spend my money on other things.
Good. This is what we want. This is what victory looks like. They are perfectly entitled to homebrew whatever weird little network they want, which is about as likely to compete with the web as Blockbuster's braindead internet video rental system was.
Eventually they'll decide they're tired of not making money and come around. Until then, they'll continue to get robbed by the professional pirate crew at YouTube, etc. Not my problem.
The only way the open Web can lose now is if it makes the deal with the snakeoil DRM devil, which works¹ just well enough to be dangerous but excludes large swaths of users, opens up gaping security holes in everything and generally makes everyone's life difficult.
¹ works=plays, not that the content protection stuff works.