Slashdot Mirror
Netflix Wants To Go HTML5, But Not Without DRM
FuzzNugget writes "In a recent blog post, Netflix details their plans to transition from Silverlight to HTML5, but with one caveat: HTML5 needs to include a built-in DRM scheme. With the W3C's proposed Encrypted Media Extensions, this may come to fruition. But what would we sacrificing in openness and the web as we know it? How will developers of open source browsers like Firefox respond to this?"
Netflix probably wants DRM too, FWIW. Remember their model is based upon people getting unlimited access to their library but paying by the month. If it were easy for their customers to simply download and save all the movies they're interested in over the space of a month, and then unsubscribe for a few months until the next time they see movies they're interested in, then the entire model would break down - less revenues received, and more money spent on bandwidth per month.
I'm wondering, actually, if the long term solution is in things like Cinavia, which, in theory, implements enough of the "checking the license in hardware" that the system (or one evolved from it) could conceivably be built into PCs and tablets without preventing the transportation and decoding part of the process being open source.
Of course, that wouldn't work today, it'd require the majority of monitors and tablets support the system to the point people find it difficult to get a device that doesn't have this built in, so it's not really going to work for Netflix today.
You are not alone. This is not normal. None of this is normal.
The only way DRM can work if if you make the decrypted video uncaptureable. So on any system where the root user can read the frame buffer there is no point. HTML5 DRM will only work on systems that have DRM build in to the OS, which is pretty much the same systems that have silverlight.
The only way i can see it ever getting to linux is if the encrypted stream can be passed to rights managed hardware on a GPU. but then if i have a GPU that can effectively play the encrypted stream, why would i ever worry about decrypting it in the first place, i could dump the network stream to disk, and play back through GPU whenever I wanted.
This means Silverlight will dynamically adjust the video and audio bitrate so that even users on less-than-fast lines can stream Silverlight video content.
I doubt that Silverlight is anything special in that regard. I would be stunned to learn that it used anything other than a standard codec like vc1 and just switches between a couple of different bit-rate streams that were pre-encoded.
This being said, the DRM probably isn't as needed by the Netflix itself but the content providers.
Nope. Netflix lurves DRM. They will force it on viewers even when the producer does not want it. Hell, they won't even let the producer put up a message at the start of the movie to tell viewers they can get a DRM-free copy.
When information is power, privacy is freedom.
If it were easy for their customers to simply download and save all the movies they're interested in over the space of a month, and then unsubscribe for a few months until the next time they see movies they're interested in, then the entire model would break down - less revenues received, and more money spent on bandwidth per month.
That theory is already debunked. If it were true, Netflix and all the other streaming services would have already failed. Since it is tremendously simple to just hop on over to TPB and grab whatever you want in whatever quality you want it in. People want to pay a reasonable price to have this stuff available legally.
Netflix probably wants DRM too, FWIW. Remember their model is based upon people getting unlimited access to their library but paying by the month. If it were easy for their customers to simply download and save all the movies they're interested in over the space of a month, and then unsubscribe for a few months until the next time they see movies they're interested in, then the entire model would break down - less revenues received, and more money spent on bandwidth per month.
The problem with that argument is that it's bullshit. If you look at the most popular lists on services like Netflix, they're full of new releases. I don't subscribe to a rental service just because they have a big catalogue, I subscribe to them because they have a big and growing catalogue. At any given time, my DVD rental list has a number of unreleased things, which are added to the main list as they are released. If I had infinite local storage and bandwidth, I could download everything that they had that I might want to watch today, and their service next month would still be valuable to me next month. On the other hand, the fact that I can't download 20 hours of their content today and watch it on a transatlantic flight or a long train journey means that it is less valuable than a DRM-free service would be.
I am TheRaven on Soylent News
Netflix also has a great UI, especially for TV episodes. It's a lot easier to deal with than trying to piecemeal together a bunch of pirated stuff. Well worth the $8 a month.
The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
Just a side note: to use current Netflix on Linux, guys uses wine + firefox + moonlight. And it works pretty fine. See more here, a working ppa with all the solution working: http://ubuntuforums.org/showthread.php?t=2084592 This is a good point about current Linux distros status: if you don't want port your application, no problem, we can simulate your environment. Ok, not FOSS solution, but at least works.
"But what would we sacrificing in openness and the web as we know it?"
Let's recap. The proposal for opened and standardized DRM method in HTML is just a bunch of callback and methods so a media content can say it has a protection and then the web browser can look up in its plugin repository if a DRM plugin can decrypt the content. The HTML part is 100% open and standardized. The actual DRM encryption and keys are not. Which is the point of any DRM scheme.
So adding DRM support into HTML, as media play/pause/method already did, won't make the Web more closed or more proprietary. The opposite is true.
Currently, media owner that choose to use protection for their content must rely on proprietary technologies. With a standard DRM framework (ie for distributing and handling protected content, not the part of decrypting it), at least, we could have much more openness on this kind of content.
Now, adding DRM to HTML does NOT change the web. Should an actor decide to use those DRMs features, you are totally free to NOT use their services. But the thing for sure is that we will have much more actors ready to use standard and open functionality to distribute their content in a protected way.
Sig (appended to the end of comments you post, 120 chars)
it takes seconds to turn it on and find something to watch
Sounds awesome! It takes me years to find something to watch. Mostly because everything sucks.
HTML is a markup language that attempts to be cross platform and presentation agnostic, whereas DRM is all about controlling the user experience.
1) DRM is not an actual type of media content, it's just a way of regulating access in time and space: It's like the bad old days when HTML designers were forcing us to browse their websites EXACTLY in 800x600 on a particular browser. Here you're supposed to have EXACTLY the right credentials from EXACTLY the right secure enviromnent. This is just as stupid. Today most people browse the web from a phone where even desktop style drop down menus from 5 years ago are a pain.
2) DRM in HTML kills web pages: Documents and web pages are timeless. Any web page that exists today, if it is archived, can be displayed 10 years from now. But in 10 years, the DRM content will be impossible to read because either the authentication servers are gone, or your credentials no longer work, or the product has been discontinued, etc. Either way, a web page becomes corrupted for reading. Documents are archivable. Digital rights are not.
3) DRM makes the Internet brittle: If you have DRM on lots of web pages, when it goes stale it's going to be like 404's without Google's page cache. Is that the web we want?
4) DRM support has no business being part of HTML: The HTML standard is already a very complex language. Anyone who wants to implement a web browser or HTML parser has to support a lot of things. There's no reason why DRM should be supported as well, just to have a standards compliant HTML parsing system.
5) The end result of 4) is that programmers and companies who must support HTML documents, as it gets more complex, won't implement the full standard, just the tiny bits they actually need. Then we'll be back in the 90s with incompatible browsers and parsers everywhere.
6) DRM breaks transparency. For example, think about what it takes to implement a spam filter that parses HTML pages as in 4). With DRM content locking away parts of an HTML document, this breaks the security model. A random spam filter is obviously not going to have account access to view/scan whatever the content is, so either it lets it through (hello spammers/phishers) or it blocks it without trying (hello user complaints).
7) If companies like Netflix want DRM, they should put it where it already belongs, at the server in the authentication part of the HTTP protocol. HTML is a document format for content, digital rights aren't content.
8) Alternatively, Netflix can build a DRM plugin and require its users to use it. Oh but wait, with all the different browsers we're now using, that would be painful to support everywhere, right? Much better to ask the WHOLE WORLD to support DRM and keep it up to date, so that Netflix doesn't need to do anything! Wrong. DRM is sufficiently niche that those companies that want to use it should implement it themselves, and support it themselves. It's common sense.
9) DRM is a business model, not a content markup. And as business models go, it's quite expensive to implement, since a single breach in the chain invalidates it and we all know that some hackers crack those chains just for fun. So it's natural that Netflix doesn't want to pay for it, and prefers to externalise the cost to the Internet at large. We shouldn't let it.
10) I'm starting to repeat myself, so I'll stop now. Just say no to DRM in HTML.