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