Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Netflix Using HTML5 Video For ARM Chromebook

Unknown Lamer posted about a year and a half ago | from the shiny-new-antifeatures dept.

DRM 232

sfcrazy writes "Netflix is using HTML5 video streaming instead of using Microsoft's Silverlight on Chromebooks (which now supports DRM for HTML5). Recently Google enabled the much controversial DRM support for HTML5 in Chrome OS to bring services like Netflix to Chromebooks using HTML5." Still no word on general support for GNU/Linux, but x86 or ARM, what's the difference? (If you're ok with DRM at least.)

cancel ×

232 comments

Sorry! There are no comments related to the filter you selected.

if you're ok with DRM (2)

Anonymous Coward | about a year and a half ago | (#43143695)

No, im not. But thanks for asking.

and if you're not (3, Insightful)

tepples (727027) | about a year and a half ago | (#43144129)

If you're not OK with DRM, then you're not OK with motion pictures published by Columbia, Disney, Fox, Paramount, Universal, or Warner.

Re:and if you're not (5, Funny)

cheater512 (783349) | about a year and a half ago | (#43144273)

What do you mean? Their products are easily accessible DRM free.

Jeez with the number of times The Pirate Bay and the rest of them get mentioned on Slashdot I'm surprised more people don't know about torrents. :P

Risk of being sued for copyright infringement (1)

tepples (727027) | about a year and a half ago | (#43144291)

Their products are easily accessible DRM free.

Not without running the risk of being sued for copyright infringement. Even in countries where downloading is not prohibited, torrent users upload as they download, or they get very little download speed from public trackers and kicked off private trackers.

Re:Risk of being sued for copyright infringement (2)

fredprado (2569351) | about a year and a half ago | (#43144533)

The chances of it happening are considerably lower than the chances of you dying in a car accident. Still many people keep driving cars...

Re:Risk of being sued for copyright infringement (2, Funny)

node 3 (115640) | about a year and a half ago | (#43144921)

Yeah, they keep driving them, but they wouldn't download a car.

Re:Risk of being sued for copyright infringement (2, Insightful)

fredprado (2569351) | about a year and a half ago | (#43145245)

Yet!

Re:and if you're not (0)

Anonymous Coward | about a year and a half ago | (#43144977)

Not all of us are willing to run roughshod over the property rights of others just because we have a craving to be entertained. You know... delayed gratification, adulthood, all that good stuff. Maybe you'll find out about it some day.

Sonny Bono (5, Insightful)

tepples (727027) | about a year and a half ago | (#43145443)

You know... delayed gratification

Except the U.S. Congress keeps extending this delay. It's already well over a decade past the human life expectancy.

Re:Sonny Bono (1)

Anonymous Coward | about a year and a half ago | (#43145699)

The current lenght is 120 years after creation or 95% after . And we know the only reason it's not 130 is because nobody has lobbied for that yet.

Re:and if you're not (0)

Anonymous Coward | about a year and a half ago | (#43145597)

(Shrug) I'm under no moral obligation to respect property "rights" you invented.

Re:and if you're not (1)

exomondo (1725132) | about a year and a half ago | (#43144553)

The movies themselves are fine, it's the DRM i don't like.

Re:and if you're not (2)

hairyfeet (841228) | about a year and a half ago | (#43145351)

That's not gonna be the problem, the problem is FOSS and DRM are completely opposed to one another (which RMS made quite clear that was his intent) so that Google will end up having to lock down the OS to keep the DRM from being trivially cracked. After all if you have the source there is no reason why you couldn't compile a kernel that say put video and audio out into a file, so unless they have hardware DRM built into the unit I predict Google WILL lock it down.

I have a feeling Google already knew this day was coming which is why GPL V3 has been verbotten, if there was GPL V3 there wouldn't be the "TiVoization" trick that allows you to lock down the software with code signing thus making the source worthless.But we all should have known this day was coming, the masses want big studio content, music, movies, games, and that means DRM. Since Google has been using FOSS as their base and they are trying to sell to the masses this day had to come, it was either that or tell the masses no big content which would be the kiss of death for ChromeOS.

Re:if you're ok with DRM (4, Insightful)

Zibodiz (2160038) | about a year and a half ago | (#43144881)

If you're not okay with DRM, then you probably don't care about Netflix, as it's entirely based on the concept of you not owning any of the content they provide to you. So what does it matter? DRM isn't cool, but Netflix is a creature that lives entirely inside the DRM-isphere, so if you want Netflix, you're gonna get DRM. Just be happy when it shows up in Linux, regardless of rights management.

It's quite simple (-1)

Anonymous Coward | about a year and a half ago | (#43143717)

It's quite simple. The difference is that a Chromebook has hardware support for DRM. Your generic Loonix "boxes" doesn't.

Re:It's quite simple (2)

jedidiah (1196) | about a year and a half ago | (#43144047)

> It's quite simple. The difference is that a Chromebook has hardware support for DRM. Your generic Loonix "boxes" doesn't.

That's moronic. Most of the supported devices on the planet don't have any "special hardware support" and are quite capable of running Linux as well as whatever other operating systems have a supported Netflix client.

HTML5 with DRM, or Silverlight... (1)

Phoenix Rising (28955) | about a year and a half ago | (#43143719)

Decisions, decisions...

Not that either are ideal, but considering that Silverlight (or Netflix) can't manage to sync my audio and video on my current netbook, I'd be willing to switch to improve my Netflix stream.

Re:HTML5 with DRM, or Silverlight... (1, Insightful)

pipatron (966506) | about a year and a half ago | (#43143921)

How about [x] None of the above, and keep downloading movies until they start using a closed, non-intrusive system?

Re:HTML5 with DRM, or Silverlight... (0)

Anonymous Coward | about a year and a half ago | (#43145287)

If you really meant "none of the above", you'd stop downloading movies. Just because you don't agree with DRM doesn't give you the right to violate copyright.

Movie studios have a right to distribute their product in whatever stupid manner they want. You have a right to call them stupid, tell the rest of the world they are stupid, and not buy their product. You don't have the right to break the law because you think they're stupid.

Re:HTML5 with DRM, or Silverlight... (0)

Anonymous Coward | about a year and a half ago | (#43145485)

Who says he needs a right to do it? Who says he needs to follow that law?

How's it work on Android? (3, Informative)

PCM2 (4486) | about a year and a half ago | (#43143721)

Eh? Netflix seems to work just fine on my Android tablets, and I'm pretty sure it's not using Silverlight there. Probably doesn't use it on the various Smart TVs and Blu-Ray players that support it, either. Is this just a case of Google deciding to enable something that other people were using already? Or do these other platforms use Moonlight or something?

Re:How's it work on Android? (-1, Redundant)

Desler (1608317) | about a year and a half ago | (#43143737)

Hardware DRM is how it works.

Re:How's it work on Android? (1)

Anonymous Coward | about a year and a half ago | (#43143835)

Or more like they use their own propietary app for that instead of using the browser.

Re:How's it work on Android? (0, Redundant)

Desler (1608317) | about a year and a half ago | (#43143845)

Nope, it's due to hardware-level support of DRM. They even said so when they first started releasing it for select devices.

Re:How's it work on Android? (3, Insightful)

jedidiah (1196) | about a year and a half ago | (#43144083)

You keep on repeating that but it still doesn't make any more sense no matter how much you repeat it.

Your typical PC or Mac doesn't require such things. Why should an OS running another form factor?

An appliance being a pretty locked down and highly controlled environment actually needs LESS "extra special hardware DRM support" than a PC.

Re:How's it work on Android? (1)

exomondo (1725132) | about a year and a half ago | (#43144643)

Your typical PC or Mac doesn't require such things.

Because they implement the DRM in software.

Re:How's it work on Android? (0)

Anonymous Coward | about a year and a half ago | (#43145583)

That's what they said, but that isn't what was so. The Netflix app as it was originally released was only on one device, but the .apk would run on almost any Android device, including the original Nook Color running CyanogenMod. There was no specific hardware DRM needed.

Re:How's it work on Android? (4, Informative)

dreamchaser (49529) | about a year and a half ago | (#43143841)

No it's not. Netflix will run on any Android device running 2.2 and higher, regardless of support on said devices for hardware DRM. They do it in software within the Netflix app.

Re:How's it work on Android? (1, Redundant)

Desler (1608317) | about a year and a half ago | (#43143869)

Yes it is. They even said so when they first started rolling it out.

Although we don’t have a common platform security mechanism and DRM, we are able to work with individual handset manufacturers to add content protection to their devices. Unfortunately, this is a much slower approach and leads to a fragmented experience on Android, in which some handsets will have access to Netflix and others won’t.

It's also why consoles and set top boxes have it.

Re:How's it work on Android? (1)

mcl630 (1839996) | about a year and a half ago | (#43144009)

That was true when Netflix for Android first came out, but isn't any longer. As dreamchaser said, nowadays it will run on any Android 2.2 or higher device.

Re:How's it work on Android? (2)

dreamchaser (49529) | about a year and a half ago | (#43144619)

That changed with the 1.4 version of the Netflix client for Android. I think it was 1.4 at least, but as I said it will now run on any Android device running 2.2 or later, regardless of any hardware support. You're quoting a quite outdated blog post.

Re:How's it work on Android? (3, Informative)

MrEricSir (398214) | about a year and a half ago | (#43143771)

Moonlight can't be used for Netflix, which is why Linux users have to resort to crazy hacks like this [omgubuntu.co.uk] to get their Netflix fix.

I'd also point out that the iPad has had an official Netflix app for some time, and I highly doubt that involves running Silverlight either.

Re:How's it work on Android? (0)

Desler (1608317) | about a year and a half ago | (#43143785)

Yes, that's because mobile devices and set tops, and consoles support DRM at the hardware level. So there is no need for the software DRM of Silverlight.

Re:How's it work on Android? (1)

Aranykai (1053846) | about a year and a half ago | (#43144085)

Crazy hacks? Its just firefox and wine. Geez, you add one repo and install a package and it just works 99% of the time.

What more could you want?

Re:How's it work on Android? (2)

MrEricSir (398214) | about a year and a half ago | (#43144313)

Just because it's nicely packaged and easy to use doesn't mean it's not a crazy hack. I don't mean to knock it by calling it that, on the contrary -- what's more awesome than a crazy hack?!

Re:How's it work on Android? (1)

gnapster (1401889) | about a year and a half ago | (#43144889)

Two crazy hacks?

Re:How's it work on Android? (1)

kriston (7886) | about a year and a half ago | (#43144899)

At these prices and levels of effort, why not just get a Chromebook, anyway?

Re:How's it work on Android? (1)

gnapster (1401889) | about a year and a half ago | (#43144951)

This guy had one answer: "when I travel I take only my Linux laptop [slashdot.org] ." If I'm already taking a laptop to do things that a chromebook can't do, why should I have to take a chromebook, as well?

For myself, I've got a Windows partition for things like this. But I can definitely see the chromebook advantage.

Re:How's it work on Android? (1)

hawguy (1600213) | about a year and a half ago | (#43144315)

Crazy hacks? Its just firefox and wine. Geez, you add one repo and install a package and it just works 99% of the time.

What more could you want?

How about something that works 100% of the time and without having to give an unknown repository the ability to install binaries on my system?

Re:How's it work on Android? (2)

DragonWriter (970822) | about a year and a half ago | (#43143879)

Eh? Netflix seems to work just fine on my Android tablets, and I'm pretty sure it's not using Silverlight there. Probably doesn't use it on the various Smart TVs and Blu-Ray players that support it, either.

On all of those, its by way of a proprietary app that handles the DRM for the streaming video.

Is this just a case of Google deciding to enable something that other people were using already?

Its a case of--as TFA states--Google providing in Chrome a mechanism for supporting DRM along with HTML5 streaming video in the browser.

Re:How's it work on Android? (0)

Anonymous Coward | about a year and a half ago | (#43144267)

Apps are custom software you have to install on your device, so they could be using anything they want.

ms peoplenon Netflix board (0)

Anonymous Coward | about a year and a half ago | (#43143727)

Differece is the presence of microsoft execs on the Netflix board. The lack of Netflix streaming (such as it is) seems to discourage many the potential linux switcher.

Re:ms peoplenon Netflix board (2)

Desler (1608317) | about a year and a half ago | (#43143753)

Riiiiiiight. So then why would Microsoft have allowed Netflix on Android and iOS if that were the case? Those two are crushing it in the mobile space. What a dumb conspiracy. The issue is with the DRM, not with some stupid "M$" conspiracy.

Re:ms peoplenon Netflix board (2)

jedidiah (1196) | about a year and a half ago | (#43144137)

Microsoft wasn't in control. They were just leading Netflix down the garden path. That created a legacy support issue for desktops. This never happened with tablets because by that time everyone realized what a dud Silverlight was. Plus, Jobs didn't put up with that sort of thing in his little walled garden.

Apple became successful enough to undermine Microsoft's influence. (Adobe's too)

Re:ms peoplenon Netflix board (1)

symbolset (646467) | about a year and a half ago | (#43144279)

Today the top three technology companies by market capitalization don't use Windows at all. It was a big /. story when Apple passed Microsoft. And Google. But IBM? Just another day in the technology mines.

Re:ms peoplenon Netflix board (1)

AvitarX (172628) | about a year and a half ago | (#43144185)

Because netflix can't credibly ignore a market crushing ms, but can do so ignoring a market that may grow, but hasn't.

Re:ms peoplenon Netflix board (1)

lister king of smeg (2481612) | about a year and a half ago | (#43144349)

Because they can't out vote the rest of the netflix board that don't have windows phones but do have iphones and androids.

Re:ms peoplenon Netflix board (1)

mspohr (589790) | about a year and a half ago | (#43144427)

I couldn't get Silverlight to install on my Mac OSX.
Netflix told me to call Microsoft.
Microsoft was clueless about OSX but still wanted $99 for the service call.
My solution was to cancel Netflix.

Re:ms peoplenon Netflix board (1)

RawsonDR (1029682) | about a year and a half ago | (#43144807)

Netflix told me to call Microsoft. Microsoft was clueless about OSX but still wanted $99 for the service call. My solution was to cancel Netflix.

You should carefully document the steps reproducing your solution and sell this for $49 to frustrated Netflix users. It even pays for itself over time.

Re:ms peoplenon Netflix board (1)

CrankyFool (680025) | about a year and a half ago | (#43145173)

I'm sorry, can you name one Microsoft executive on the Netflix board? Because I looked at http://ir.netflix.com/management.cfm#3562 [netflix.com] and couldn't find any.

Don't say "no" ; say "yes, but..." (2, Interesting)

Sloppy (14984) | about a year and a half ago | (#43143777)

I'm totally ok with DRM, provided that it's very clear how to implement it, and I don't need to sign any contracts or otherwise agree to keep any trade secrets. Just write up the RFC, send it to IETF, and we'll all get to work on our your-DRM-compatible players. Everybody wins.

Re:Don't say "no" ; say "yes, but..." (4, Insightful)

fyngyrz (762201) | about a year and a half ago | (#43143859)

Yes. Everybody wins. Except consumers, who can't record it, can't excerpt it for fair use, can't back it up, can't move it to a later media format, and so will lose their investment eventually either because the media is obsolete or because the media the content is provided on has gone bad.

So, yeah, absolutely, everybody wins.

Not.

Re:Don't say "no" ; say "yes, but..." (1)

Ryanrule (1657199) | about a year and a half ago | (#43143911)

Subscription based content access. You are paying for a service.

Re:Don't say "no" ; say "yes, but..." (1)

Anonymous Coward | about a year and a half ago | (#43144089)

Entry into the markplace is entry into the culture. Nobody should get gag-order rights over that.

A limited copyright to enable captialism, sure. Keyword is limited. It has to be balanced by public rights to do things with their share of the experience. The public, without which the content is valueless. They are partners in making it valuable, and must get balanced rights to that.

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43144991)

Wow, I've read some insane justifications for shitty pirate behavior over the years, but you, sir, have just taken the cake.

Re:Don't say "no" ; say "yes, but..." (1)

Man On Pink Corner (1089867) | about a year and a half ago | (#43145615)

What he just stated is the entire moral basis for copyright law.

Copyright law was never supposed to govern end use. That's something some people who were powerful but not very smart made up very recently.

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43143977)

I win every month with Netflix. I get tons of access to great content for 7 bucks. Thats half the cost of a new dvd you can keep. I dont own the content im streaming, im just watching it for the time being. What do you understand about rent or stream? What makes you think you have the right to record stuff you dont own? You dont own the content. Get it?

Re:Don't say "no" ; say "yes, but..." (1)

Microlith (54737) | about a year and a half ago | (#43144043)

What makes you think you have the right to record stuff you dont own? You dont own the content. Get it?

My god, it'd kill the industry if people could record things! Just like the VCR did back in the early 80s, like Jack Valenti predicted it would!

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43144573)

You're comparing apples to oranges. Here are (some) of the reasons why VCR recording is no where similar to modern day DRM copying.

  1. Almost exclusively used for TV shows at a time when episodes weren't available for resale, only catchable by rerun. Sure, every now and then a movie would come along, but it was rarely a blockbluster and aired on such a delay, movie sales could hardly be seen as being impacted by pirates.
  2. Not something that could be abused on a wide-scale (i.e. internet vs sneakernet)
  3. Had a cost, albeit minimal, in the form of blank tapes.

It's essentially the law of assholes. Sure, people being able to record things won't kill the industry, but if everyone started recording things and stopped paying, the industry would collapse.

DRM (1)

fyngyrz (762201) | about a year and a half ago | (#43144443)

What don't YOU understand about the privilege of copyright being extended for a limited time? What don't YOU understand about the fact that without this...

"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;"

...there would be no protection for these works at all? What don't YOU understand about the fact that by taking those inventions away from the public other than for one glimpse, the intent of the entire system is being suborned?

By moving your expectations to rental, they've created an imaginary divide, as if these inventions were somehow immune from the obligation to the public they were produced under the aegis of. They're not.

If the public cannot obtain the full benefit of the work, then the obligation to the public has been sundered and the author(s) should be taken to task for it. We have every reason to expect that a purchase results in ownership, and that ownership carries the ability to protect that property and use it as we see fit, as long as we don't interfere with those rights during the protected period. From this comes the right to copy for our own use; to back up; to create mixes of titles in the order that pleases us; to review and study the content; to excerpt sections for fair use in conveying to others our opinions and interpretations of the work itself.

DRM advocates have almost completely snowed the American public (and likely, others) in taking from them the very benefits the constitution intended to secure for them WRT artistic productions. That you have been taken in by this does not surprise me. What concerns me isn't your individual error, but the broad negative effects this will have on our society. It is insidious in the short term and invidious in the long.

Re:DRM (1)

devent (1627873) | about a year and a half ago | (#43144969)

So true. If anything copyright terms should have been shorter and shorter because of progress in technology decrease the time to market and decreases the time to realize a profit for the author.

50 years ego you needed a longer copyright term for the author to realize a profit from his or her work, because you didn't had DVDs and the Internet. Today it's all digital and the publishing business have very sophisticated technology to bring the work to the market.

But because of Disney and Hollywood I predict that the public domain will be eliminated, by ever increasing copyright terms to protect Mickey Mouse. If it's not already eliminated by DRM and DRM protective laws. The craziness of DVD regions alone is the master example of how far Hollywood will go to rape the public interests.

Any politician that works for the public should press for shorter copyright terms and any politician that works for the public should press for the abolishment of DRM. Because the damage to the public clearly outweighs the benefits of a few. I would go so far as to lose any copyright protection by using any form of DRM.

Re:Don't say "no" ; say "yes, but..." (1)

Isaac Remuant (1891806) | about a year and a half ago | (#43145503)

What makes you think you have the right to record stuff you dont own? You dont own the content. Get it?

What makes you think companies have the right to have a say of what I do with my hardware at home?

So recording a TV show on VCR was piracy too?

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43145659)

What makes you think companies have the right to have a say of what I do with my hardware at home?

You don't have to accept their terms if you don't want to, just don't do business with them if you're opposed to their conditions.

Re:Don't say "no" ; say "yes, but..." (4, Insightful)

jedidiah (1196) | about a year and a half ago | (#43144165)

I can live with DRM for a rental service. I am more interested in features, performance, and usability. There are other reasons I would complain about Netflix before getting into the DRM.

Purchases on the other hand are an entirely different kettle of fish.

Re:Don't say "no" ; say "yes, but..." (1)

devent (1627873) | about a year and a half ago | (#43144895)

Don't you get it? You will not "own" anything.
Even if you pay the full price, you still not "own" anything. You will "own" a license that can be terminated for whatever reason and will severe limit your rights. Format shifting? Backup-copy? First-sale rights? It's already not possible.
With a DVD or VHS you had at least your video as long as you can read the media. With the new digital media it will be remote deleted for whatever reason.

Re: Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43144445)

I don't need nor want to own other people's work, I want to own and control MY work, so I understand them protecting theirs.

It's just like a museum, you pay to see some art pieces, than you leave with memories.

All new songs or movies suck anyway.

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43145121)

Until they can encrypt the light waves coming out of the screen, and sound waves coming out of the speakers, then I won't be prevented from duplicating the content. In fact, they'll have to encrypt my own memories to keep me from "copying" a movie / music / etc.

For all the dystopian horrors DRM is the root of, at least we get cybernitc implants, eh?

Re:Don't say "no" ; say "yes, but..." (1)

Microlith (54737) | about a year and a half ago | (#43143861)

I'm totally ok with DRM, provided that it's very clear how to implement it

Which it won't be, because DRM that is clear about how it is implemented is quickly broken.

I don't need to sign any contracts or otherwise agree to keep any trade secrets.

You'll not only be required to sign an NDA, but also to license the patents.

Just write up the RFC, send it to IETF, and we'll all get to work on our your-DRM-compatible players

If only it were that simple. Then the DRM would be broken outright and we could stop making up this bullshit.

Everybody wins.

No, with DRM no one wins.

Re:Don't say "no" ; say "yes, but..." (0)

Anonymous Coward | about a year and a half ago | (#43144923)

In this case - movie rentals - it's fine.

Re:Don't say "no" ; say "yes, but..." (1)

hawguy (1600213) | about a year and a half ago | (#43143941)

I'm totally ok with DRM, provided that it's very clear how to implement it, and I don't need to sign any contracts or otherwise agree to keep any trade secrets. Just write up the RFC, send it to IETF, and we'll all get to work on our your-DRM-compatible players. Everybody wins.

I can't tell if you're trolling or serious, but how could you have a documented, published DRM standard that actually works? Anyone could use the standard to write a "player" that does nothing more than record the stream.

You may argue that DRM doesn't work at all, but the fact that there's no native Netflix player on Linux (yet) seems to indicate otherwise.

Kerckhoffs's principle (1)

tepples (727027) | about a year and a half ago | (#43144311)

how could you have a documented, published DRM standard that actually works? Anyone could use the standard to write a "player" that does nothing more than record the stream.

Following Kerckhoffs's principle [wikipedia.org] , the algorithm is published but the required cryptographic keys are secret.

Re:Kerckhoffs's principle (1)

hawguy (1600213) | about a year and a half ago | (#43144425)

how could you have a documented, published DRM standard that actually works? Anyone could use the standard to write a "player" that does nothing more than record the stream.

Following Kerckhoffs's principle [wikipedia.org] , the algorithm is published but the required cryptographic keys are secret.

How would you do that when the content has to be decrypted on the client, so the client has to have the keys at some point. Even if the content holder encrypted all content with a unique key with each stream, preventing you from replaying the stream on other players, the client has to be able to decrypt it in order to play it. So the client can either save the keys along with the encrypted content, or can decypt the content and save off an unencrypted copy.

Re:Kerckhoffs's principle (1)

ssam (2723487) | about a year and a half ago | (#43144441)

but where does the decryption key live? The play needs to know it to play the file. If you put the key in the hardware, and pass the encrypted stream to the hardware, then you have just moved the DRM to somewhere else. Thats like saying its an open DRM protocol because it works over open TCP.

Re:Kerckhoffs's principle (1)

exomondo (1725132) | about a year and a half ago | (#43144983)

Following Kerckhoffs's principle [wikipedia.org] , the algorithm is published but the required cryptographic keys are secret.

How would doing that prevent the creation of a "player" that does nothing more than record the stream [slashdot.org] ?

Key revocation (1)

tepples (727027) | about a year and a half ago | (#43145127)

Distribution of player keys would depend on posting a bond that a developer won't make such a player. Misused keys would be revoked and unable to view streams.

Re:Key revocation (1)

exomondo (1725132) | about a year and a half ago | (#43145223)

Distribution of player keys would depend on posting a bond that a developer won't make such a player. Misused keys would be revoked and unable to view streams.

Then you've missed a fundamental element of the discussion thread [slashdot.org] . And in any case how much would this bond be and when would it be returned?

Re:Don't say "no" ; say "yes, but..." (1)

wierd_w (1375923) | about a year and a half ago | (#43145299)

Require a unique decode key, a session ID, and a valid user identity in their database, with unique on the fly encoding?

Eg, in order to use the service, the device must be provisioned with a unique player key, (either has one already, or one is generated and provided to the player when the netflix app is installed and kept in a local keystore) and is encoded with the "secret" key that is generated for each user identity (subscriber) and is kept in the netflix server farm.

Multiple private keys, multiple public keys, but a single standard implementation.

This is the sort of thing TPM modules were intended for, and devices outfitted with one would get a boost to the crypto functions involved.

The idea is that even if you know your own key by disassembling the device, you can't easily deduce the session key, nor the secret user identity secret key. This means that grabbing the raw stream without also simulating the netflix app straight up would be essentially proftless, because there isn't enough information to break standard industry encryption methods.

If the netflix service requires the player to identify its version and it is a cryptographically signed executable, then the service can refuse to issue a session key to the "player". If hackers successfully implement a pirate player, then it will always report the "discovered" vulnerable player version, and Netflix can simply force an app update, and it stops working after they blacklist that player.

(This is basically what deCSS does; it uses a "discovered" key found in a poorly written software DVD player. Because CSS is a very juvenile encrypt method, meant for offline transport, once its broken, it stays broken. Not so with this system.)

Essentially, we have a datastream being sent to the player, that has the following keys involved:

Per User entity key (secret, on netflix server.Unique to user.)
Per session private key (generated once per session using random number generator and the player unique key. Kept cached on netflix server and purged after disconnection. May be appended to netflix server session logfile for "litigation" purposes.)
Per session public key (generated once per session using the private key, and sent to the player. May also be logged by netflix session logfile.)
Player unique key. Hardware player key if in a TPM, software encoded unique player key on devices without a TPM.
Player runtime software digital signature, done with secret RSA key and a public key.

So, to GET a useful stream from a netflix server (with a pirate "player"), you would need:

1) the whitepaper on the encoding. (Check. Public doc.)
2) the player unique ID. (Check, its local, and theoretically obtainable.)
3) session unique ID (not so easily obtained if encrypted when dispatched, and if session rules require reprovisioning of keys on failure, with fresh random keys. Doubly so if not stored in clear form in memory.)
4) Netflix public RSA key (to get and decode the session key)
5) a whitelisted player image digital signature (easily defeated by netflix with a forced update. Easily detected if the image files downloaded by app stores are bearing unique signatures, since any two sessions with an identical player image signature would red flag. Each image is provisioned with a unique public key, then signed with the secret private key before being delivered. Means .apk files couldn't be replicated on devices, as the player would be invalidated quickly! Broken player is easily fixed by uninstalling then reinstalling the app with an actual approved appstore download. This means that in order to successfully spoof a player, it cannot be mass shared, or must be derived in some fashion from a unique player download. This makes it a royal PITA to keep it up, especially if Netflix uses a "routine update" timetable. (Say, once every month.)

This means that for each and every pirate player installation, you would be required to:

Brutally dig out the unique player ID, and derive the signature of the player image as well as the unique image public key, successfully fake out the netflix server's provisioning challenge, successfully capture and decode the session key, answer any random mid-stream challenges the server might throw at it, successfully.

Automated tools to do this could be greatly complicated by inconsistent file offsets inside the player image file for the player unique and player runtime keys, in combination with per download uniqueness.

The whole idea here is to heavily capitalize on the fact that this is innately an online provisioning system, and that players must be in active contact with a provisioning server to receive a stream. (Unlike a DVD or Bluray disc, where no such assumption can be made.) This is what makes all the unique key use possible. It also enables the stream server to issue random key related challenges, and disconnect and blacklist a player entity mid session.

The idea is not to completely prevent unauthorized player use, but to seriously curtail that use by making it such a serious PITA that only the most dedicated pirate sharers would be willing to put up with the hassle, and allowing the provider an easy means of flagging excessive stream users who's service useage does not correspond to a normal user's interest profile. (Eg, stream selection appears random, or favors only new releases, with no repeat plays, and where heavy streaming happens such that it is unrealistic to expect even a family to be watching at that level of use. In such cases, a triggered mandatory client update based on stream use to freshen the client's validity could be performed. A valid and normal user would just update their device, and keep rolling. The pirate has to rebuild his kit setup with a new and fresh image download to resume. This forces pirates into normal stream use patterns to avoid the problem, while also having to jump through a lot of hoops, which greatly reduces the value of the streaming service being abused by said pirate.)

If you throw in some digital watermarking on the video feed data itself that can survive a re-encode run, (perhaps in the audio too?) Then finding a pirate copy of a stream on the internet would directly identify the pirate, (the stream is alread being uniquely cryptographically processed. Poking a few bits in the stream itself prior to crypto is icing on the cake.) And the appropriate teams of attack trained lawyers could be notified. Good luck explaining how your unique keys got "hijacked", since there is 1:1 parity between your unique keys and your user account. (This is not an IP address type subpoena. This is a "we have a unique crypto fingerprint pointing at your user account, which was found in the uploaded video file, and we have your real name, address, and credit card information on file. In order for this file to exist on the internet, ONLY you could have created it." Very different beasties.)

While computationally heavy, it is theoretically possible on modern multicore processors.

DRM doesn't have to be "perfect", it just has to be "good enough to thwart passive offenders", and "be able to uniquely identify consumate offenders for prosecution."

Both of those are easily obtainable goals, even with publicly documented and registered methodologies.

DRM (-1)

Anonymous Coward | about a year and a half ago | (#43143855)

Fuck drm. Only faggots and squat pissers like the POS michael bloomberg would like that shit.

No thanks (1)

Hatta (162192) | about a year and a half ago | (#43143889)

I'd actually love to give Netflix my money, but DRM is a deal breaker. I can get better service with torrents and rss, so I do. I'd pay for that too, if it were licensed. But not a penny for DRM.

Re:No thanks (1)

Anonymous Coward | about a year and a half ago | (#43144097)

Netflix is a subscription-based service provider which streams content to you. In this scenario, to what end does DRM inhibit your experience or tread on your right as a consumer? I am legitimately curious, because while I am very anti-DRM in most scenarios, I fail to see the issue with a DRM-lock on content designed and intended to only be streamed.

Re:No thanks (1)

hawguy (1600213) | about a year and a half ago | (#43144555)

Netflix is a subscription-based service provider which streams content to you. In this scenario, to what end does DRM inhibit your experience or tread on your right as a consumer? I am legitimately curious, because while I am very anti-DRM in most scenarios, I fail to see the issue with a DRM-lock on content designed and intended to only be streamed.

I can tell you how Netflix's DRM inhibits my experience as a consumer - when I travel I take only my Linux laptop, thus have no way to watch Netflix videos (well, unless I'm willing to use a Wine based hack). It's not a platform limitation since Netflix runs well on Linux based devices.

Though it's not really the DRM that bothers me, I'd be just as happy if they had a Linux player.

Well, there is one other limitation that bothers me as a consumer - it's when Netflix takes down content from their streaming service. I've been mid way through a movie, paused it for a few days and then gone back to look for it and find that it's no longer available for streaming. It'd be nice if I could download the movie and keep it available until I'm done with it. It's stuff like that that makes torrents much more attractive - better selection and once you download the movie, it's yours forever.

What's Chromebook's user-agent string? (1)

myNameIsNotImportant (592769) | about a year and a half ago | (#43143933)

So, what's chromebook's user-agent string, so i can finally watch netflix w/o installing silverlight?

Re:What's Chromebook's user-agent string? (3, Informative)

pavon (30274) | about a year and a half ago | (#43144033)

That won't be enough. You will also need a browser that allows DRM for HTML5 (Chrome 26 beta is the only one so far), and the specific DRM plugin used by Netflix compiled for an x86 system, which hasn't been made available.

Is this EME or NaCl? (1)

kervin (64171) | about a year and a half ago | (#43144027)

The article ( and Slashdot ) somehow links the Netflix app to Encrypted Media Extensions but I don't see where this is confirmed.

It is also likely that Netflix used Native Client [liliputing.com] . NaCl [wikipedia.org] may also explain why it's only available for certain platforms.

EME (4, Informative)

pavon (30274) | about a year and a half ago | (#43144075)

Netflix did use NaCl on the Intel Chromebooks, but are now using HTML5/EME on the ARM chromebooks. Here is the official Chrome Google+ feed [google.com] announcement.

No worries, it will get broken. (1)

Anonymous Coward | about a year and a half ago | (#43144191)

It will get broken open, just like any stupid DRM schemes.
And it will take W3C a trillion years to fix it, as per usual.
This is just to make the media companies happy.

Just be happy knowing that you will be smart enough to know how to get around it eventually.
We won't be getting away from DRM any time soon, and you cannot change the will of others.
Tell others about things like Vodo and Kickstarter, that is the best you can do, realistically.
The media industry will remain mostly closed for decades to come. And they will be caught cold in an alleyway before they allow it to become more open.
We have a long battle ahead of us if we wish for an open media industry where we can pay and decide what lives and aren't decided upon by stupid and HUGELY estimated viewing figure groups.

Chrome sync is dangerous. (3, Interesting)

140Mandak262Jamuna (970587) | about a year and a half ago | (#43144507)

I bought a chromebook a week back and was all gung-ho about it. [slashdot.org] So much so that some AC called me shill.

Yesterday I was showing to my friend and logged into my gmail account in Chrome running in his windows box. Impressed him with my two factor authentication, text message to my phone and all that. But made the mistake of clicking yes to "synch" when prompted by chrome.

It brought all my bookmarks on to his machine!. So I deleted them in his machine, then they were also gone from my account in my Chromebook. Not only that all HIS bookmarks were on my machine. I deleted them. Then I found all my saved web passwords were on his machine! This screw up after bragging about two factor authentication. He uninstalled Chrome and reinstalled to get rid of all remnants of anything. I lost my bookmarks. Apparently this is a common problem with Chrome and google synch and it has been widely reported and complained about. Still the dialog asking for synch did not give any warning that my passwords and bookmarks and auto-completes are being downloaded into a new machine. I am very disappointed by Chrome and google.

Luckily he is a friend, and I never store any serious passwords in my gmail account. So no serious harm done. Now where is that AC who called me a shill?

Re:Chrome sync is dangerous. (1)

kriston (7886) | about a year and a half ago | (#43144915)

Am I incorrect in assuming that the local copy of your synchronized data is encrypted on a Chromebook?

Re:Chrome sync is dangerous. (1)

140Mandak262Jamuna (970587) | about a year and a half ago | (#43145067)

What I understand is, the data in chromebook is encrypted using gmail password. When I synched it with chrome running in a windows box, Chrome decrypts it using gmail password from the cloud, and then encrypts it using the windows login. Because I logged in to gmail using a chrome instance launched by my friend, now friend's machine got a copy of my passwords readable by him.

Re:Chrome sync is dangerous. (2)

guspasho (941623) | about a year and a half ago | (#43145241)

I had this problem with iCloud and importing bookmarks from Safari on my Mac to Safari on my iPhone. I tried clearing them off of one, and bam, gone on both, irretrievably so. So annoying. Anyone know what the proper procedure for this is supposed to be? I'm very suspicious of trying to use iCloud now.

Re:Chrome sync is dangerous. (5, Funny)

Tubal-Cain (1289912) | about a year and a half ago | (#43145379)

It brought all my bookmarks on to his machine!. So I deleted them in his machine, then they were also gone from my account in my Chromebook. Not only that all HIS bookmarks were on my machine. I deleted them. Then I found all my saved web passwords were on his machine! This screw up after bragging about two factor authentication.

You didn't disable Sync on his machine before deleting?

Re:Chrome sync is dangerous. (1)

Irick (1842362) | about a year and a half ago | (#43145413)

This is why you should use a separate pass phrase to encrypt synced data.

Yay (1)

DougDot (966387) | about a year and a half ago | (#43144711)

It works at least as well any of the flash sites, like Amazon.com, on my Samsung Chromebook.

Not on the x86 Acer C7 Chromebook (1)

kriston (7886) | about a year and a half ago | (#43144883)

Wow, that is nice. On my x86 Acer C7 Chromebook, which was using Silverlight just last week, is stellar using HTML5. I was wondering why the video looks and "feels" different.

thumbs up (1)

alai582 (2858851) | about a year and a half ago | (#43144935)

this is good for people with outdated pcs or macs

Wait a second... (1)

fieldstone (985598) | about a year and a half ago | (#43145167)

Doesn't this mean that getting Netflix to work on Linux might be as simple as spoofing the user agent from a Chromebook? Especially if you were using Chrome, Netflix probably wouldn't detect that you're not actually using a Chromebook. Has anyone tried this?

Re:Wait a second... (0)

Anonymous Coward | about a year and a half ago | (#43145303)

Doesn't this mean that getting Netflix to work on Linux might be as simple as spoofing the user agent from a Chromebook? Especially if you were using Chrome, Netflix probably wouldn't detect that you're not actually using a Chromebook. Has anyone tried this?

Nope. They are using a plugin to support this: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Good (1)

vga_init (589198) | about a year and a half ago | (#43145357)

Not all DRM is evil. It really depends on who is applying it, when, where, and how. DRM is an ugly name for a set of technologies that have their uses; if I agree to let Netflix stream a movie to me and understand that my computer is going to encrypt and handle it in such a way that I won't be able to save or download the movie, that's OK with me; I'm still the one in control. That doesn't mean proprietary video streaming will always be crammed down my throat.

Using DRM in this way is a great boon for open technology. In this case it's helping HTML5 video to stand on its own and be established as a universal standard. When the standard become more popular, it becomes easier to utilize it for our own libertarian purposes. This will get people off of and away from disgusting things like Flash and Silverlight. It's a win win situation.

shunky (-1)

Anonymous Coward | about a year and a half ago | (#43145429)

It is very useful.
http://www.cnstonecrusher.com
http://www.cnimpactcrusher.com
http://www.Vibrating-screen.cn
http://www.stoneproductionline.com
http://www.hydraulicconecrusher.net

I am okay with some DRM (0)

Anonymous Coward | about a year and a half ago | (#43145563)

Netflix style DRM is acceptable. Content providers should be able to protect themselves (even if it is generally a useless endavor)

DRM ala the new simcity is pretty unacceptable. It's one thing to keep an ongoing service going, it's different to make a local application unusable.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>