[tombert]

I don't know the right solution to the HTML5 DRM thing. I hate DRM, I don't really support its use, but I also use Linux full-time.

Without the HTML5 DRM, I don't think I'd be able to watch Netflix on my laptop, without some Wine wrapper, and really, is that much better? I don't see the studios signing off on Netflix without the use of DRM, and since Silverlight doesn't work on Linux, I selfishly don't have a problem with HTML5 DRM...most of the time.

That said, ethical-me totes does have a problem with DRM being part of the otherwise-open web. Relying on stuff that I can can't break sort of makes my inner-Stallman sad.

[Daiz]

>I don't know the right solution to the HTML5 DRM thing.

Easy. If they want content protection, they should build it in JavaScript. Doesn't threaten the entire existence of the Open Web, any sufficiently decent scheme will prevent casual copying (dedicated pirates will always find a way, if nothing else then via screen capture), and it's actually cross-platform (unlike EME, where "cross-platform" is entirely up to the creators of the black box DRM plugins, so if Netflix et al wanted to say "sod off, we're not making our DRM plugin available on Linux" then you'd be totally out of luck).

Sadly, of course this isn't actually enough for the people demanding heavy DRM, since it's not just about "protecting the content" but about controlling the whole platform, which is what really makes EME such an existential threat for the entire Open Web. That's why I can't approve of it, and why you shouldn't either.

But content protection through JavaScript? Totally fair game, I say. Assuming that it's for a catalog rental model like what Netflix offers, anyway. Content protection has no place in any individual (media) products you buy, those should be DRM-free - otherwise you're not really buying them, just renting them for an undefined period.

(On a final note, I also practice what I preach here - I work for a comic publisher and am in charge of most things digital distribution, including the content protection scheme for our catalog rental subscription service. It's developed in JS and I'll do my utmost best to ensure we never ever touch EME in any way. Should be more cost effective for us that way anyway!)

[DaveMebs]

But if the DRM solution is implemented through JS code in the browser, it is trivial to pirate. I know DRM is always broken, etc., but at the same time it is hard to take an argument at face value that discounts the security differences between these approaches.

JS is trivial for anyone moderately skilled to crack - you're sending content in the clear from the browser through the stack.

DRM solutions enabled by EME can be much more robust and difficult to crack.

Similar to other commentators, I struggle with the issue, but just saying "put it in JS" is not a very compelling argument. The current EME approach of a publically defined API that any DRM solution can plug into feels like a pretty reasonable compromise here.

[Daiz]

>it is trivial to pirate.

As long as it isn't trivial for the casual user, I wouldn't call it much of an issue. As I said, dedicated pirates will find a way regardless, even if comes down to screen capturing. That's how people are pirating Netflix content at the moment. Of course, this does lead to some level of quality loss, since you're doing a lossy re-encode of a lossy source.

On that note, if we consider "wannabe pirates must re-encode the video to share it around" as a decent video content protection goal, then you can definitely do that with HTML5 video and some JS without resorting to any kind of EME trickery.

Anyway, at the end of the day, it is definitely true that JS content protection schemes will be inherently weaker compared to black box DRM plugin solutions enabled by EME. But why on Earth should we compromise the very nature of Open Web to enable this rather than make Big Media compromise on their platform control addiction to have their content on the Open Web? And if they're unwilling to do that, then well, they can stick to their Flash and Silverlight all they want in my opinion. EME doesn't make any promises about cross-platform compatibility anyway, so better stick with the two devils we know than switch to a system comprised of several unknown demons.

[dasil003]

JS DRM is not DRM, full stop. The entire point is the black box. Without that you are always one greasemonkey script away from having a full-stream ripper for the casual user.

Yes, there is always the analog loophole, so ultimately all DRM is a best effort, but any JS implementation is at best 1% of current DRM implementations, it is no better than clear key encryption regardless of what obfuscation you put around it.

I really don't understand the point of the hand-wringing over EME. Before EME the only option for DRM was full-blown plugins, EME is much better for the open web than the dictatorship of Flash or Silverlight. As far as I can tell, technical activists are hoping to somehow put pressure on big content by refusing EME, but having spent the last 8 years building a streaming company, I can tell the EFF and everyone else that their advocacy has exactly zero weight with any content rightsholders. Big content will never capitulate to the abstract desires of the free software crowd because they hold the nuts. You either play ball with their demands or you don't get the content. Yes piracy will never go away, but it's illegal, so they will just continue playing whackamole for anything that approaches a good UX and pushing their DRM agenda on the rest of the industry.

Opposing EME is just a pointless skirmish over an implementation detail which overall is a huge net win for open web standards. Being absolutist about it just means everyone is going to have some shitty plugin, and they will have some shitty plugin because people want the studio content.

And as stupid and pointless as DRM is in the grand scheme of things, there is no principle I can think of that forbid people from building it. The Right Thing™ is that studios should be free to build DRM, and people should be free to hack it, there shouldn't be legal protections on either side. But for the free software community to refuse to make any integration points with DRM is just cutting off ones nose to spite ones face.

[tajen]

Why doesn't Netflix/all film directors distribute slightly different versions of their movies to every single viewer? Half a second here, a whiter scene there, it takes only 32 boolean situations to uniquely identify 2bn views, and they culd chase the viewer in court. Or do they do that already?

[Daiz]

That'd require a lot more extra processing power than you might think, as video encoding is very demanding processing-wise. Say you have a 1h30min long movie. Without anything like this, you only need to encode that 1h30min once[1], after which you can serve the same encode to all your customers, whether there's hundreds, thousands or millions of them. But if you encoded even just say, 5 seconds of unique footage per customer, it takes only about 1080 customers to double your video encoding time for just this title.

There are also other issues with this, like how resilient the scheme would be. If your watermarking relies on things that the user would hardly spot when watching, then it's very likely that re-encoding the video would simply get rid of the watermarks, since quality video compression is generally based on the idea of throwing away as much information that the user wouldn't notice while keeping as much important bits as you can. At the same time, if you make the watermarking easy enough to spot while looking carefully, then you could just have two people compare their watermarks and consciously mess them up.

That being said, various kinds of watermarking technologies do exist, but unless they're dynamically added to the content on playback they should all very much have the same kind of scaling issues as far as video encoding is concerned.

[1] Once in all the varying quality and compatibility levels you offer, anyway.

[dasil003]

Well actually with modern segmented streaming (HLS or DASH), you only need 2 encodes to get 2^n (for video of n segments) unique streams. The trick is you generate the manifest per user, and they each get a unique permutation.

I actually spoke to a vendor in the last month that claims to have actually deployed this and actually prosecuted pirates. Obviously this is a sales engineer pitching a product, so take it with a grain of salt, but I have no reason to believe the technology is not reasonably robust and scalable.

[ant6n]

So then we need captures from, say, 16 users and some software to scramble all of them together.

[BHSPitMonkey]

If implemented in the player, no re-encoding would be necessary. Naturally this wouldn't help if a pirate grabs the data before it reaches the player.

[anamexis]

All they would need to do is diff it against someone else's copy, flip a couple "bits" and incriminate some random person.

[chris_wot]

Or randomly flips bits anywhere and call it corruption.

[ywecur]

This is an extremely good solution IMO.

[tombert]

I'll admit that I know almost nothing about the ways DRM works, but my gut tells me that JS would be too slow to implement anything too robust. If DRM is anything like crypto, wouldn't it require something relatively CPU-heavy?

That said, I didn't know the cross-platform thing was optional, and I agree that when I buy something, it should be DRM free. If it has to phone-home, then I don't own it, and things like Darkspore prove it can be stolen from me be the company.

[Daiz]

DRM isn't really comparable to traditional crypto in the sense that crypto is intended to protect your secrets from anyone who doesn't have the key, while DRM is about preventing someone with the key from copying the unprotected content (since the content needs to be decrypted for consumption). As such, CPU-heaviness should not exactly be a requirement, as the cryptographic strength of the protection itself isn't necessarily the most important thing.

[brianpgordon]

You can hardly call anything beyond JavaScript "heavy DRM." Something written in pure JavaScript running along the rest of the page's scripts could hardly be called DRM at all. It would be completely trivial to break.

I'm actually OK with the current HTML5 DRM scheme. Sure some binary blob runs and you don't know what's going on inside, but Firefox runs it in a sandbox so it can't do anything bad. Seems fine to me.

[guyzero]

If the decryption keys were exposed in JS you'd only be a few debugger operations away from defeating any DRM system.

[zerocrates]

I have a hard time getting too worked up over EME. Netflix's content providers want DRM (as probably does Netflix itself, for its self-productions), and the EME-based stuff seems to be a clear win vs. Flash or Silverlight. The alternatives are clinging longer to Flash and friends or pushing things yet further out into apps where services are free to have whatever DRM they want.

Sure, you could instead hope for a world where the the studios don't want or mandate DRM, but that's pretty pie-in-the-sky thinking, especially for a cheap subscription service like Netflix.

[wallacoloo]

> Sure, you could instead hope for a world where the the studios don't want or mandate DRM, but that's pretty pie-in-the-sky thinking, especially for a cheap subscription service like Netflix.

Whether the studios want or even mandate DRM is irrelevant. DRM is fundamentally not securable (in the sense that it will always be breakable).

Bits are (nearly) free. When I buy digital goods, I'm not paying for the goods. I'm paying for the service and ultimately just voting with my money ("make more films and services like this, please", so to speak).

Illegal film services offer me superb service. I can download whole seasons of shows in whichever quality I want in the click of a button. I get archivability - I don't have to worry about the media ever becoming unavailable due to licensing, censorship, the publisher going out of business, etc. And I get desktop integration; I can hit the super key, type 'Sherlock' and hit enter, and an episode starts playing immediately. Netflix requires that I open a new browser (Google Chrome b/c Firefox on Linux doesn't work), type a URL, authenticate, and then proceed with the above steps, all on the assumption that they even have what I'm looking for (new shows don't get added very quickly) and that I have a solid internet connection. After that, the video has to buffer and I can't seek randomly.

If purchasing rights to this media involves supporting such an anti-user system, I simply won't purchase the media. It's a shame for the artists - I wish it were different - but in the meanwhile I will support the arts by dumping the money I would have spent on Netflix, Google Play, etc into more usable and pro-consumer/pro-artist systems like Bandcamp and Patreon.

[Matt3o12_]

Why do companies still want DRM. I can understand that they wanted it when it was new but DRM has been proven to be worthless in terms of adding copyright protection and be a pain in the ass for the end use (I can't watch Netflix on my PC because the VGA adapter does not supper DMR). It is only a matter of hours before a cracked movie lands on torrent sites. So what is the purpose of DRM?

[zerocrates]

It seems that the intent is just to raise enough of a barrier to prevent casual copying: so, make it so there's not some 1-click program you can install that can dump all of House of Cards to your desktop.

Of course, this doesn't do anything about torrenting which can accomplish just that. I don't know if they're attempting to target people who are scared or morally opposed to torrenting, but would copy off a subscription service?

[shmerl]

DRM has nothing to do with preventing copying. I'm surprized some still assume that's the reason it's used.

[Matt3o12_]

What is it used for then?

[shmerl]

Various crooked reasons. Some common ones include:

1. Covering incompetence. Poor sales of bad product are blamed on pirates, and those who were responsible can say "but we don't sit idle, we put another DRM in place".

2. Control over the market (standards poisoning, excluding competition, lock-in and etc.). That's what mobile carriers did to prevent people from switching to competitors.

3. Satisfying their hunger for power and ability to tell others what to do or not to do. DRM allows creating new "laws" without any democratic process. As soon as something has DRM attached to it, they can forbid what they don't like using DMCA-1201.

And so on and so forth. Those who use DRM know perfectly well that not only it can't reduce lost sales, it only increases them. So they use it for very different (and crooked) reasons, unless they are simply completely clueless.

[muddi900]

People used to say about PC games, but the Denuvo encryption is unbreakable right now. The hackers and the studios are not on equal footing anymore.

This will happen to web DRM as well.

[gergles]

EME is just Flash 2.0, only it's even worse, as it relies on architecture specific binary blobs being sent to your browser and running in the (privileged) context of your graphics card driver. At least in Flash, the Flash VM could theoretically have provided some degree of sandboxing.