Honeycomb adds a framework to support DRM plugins. Android 3.1 adds an actual implementation of a DRM plugin called Widevine (acquired by Google in Dec. 2010). Android 3.1 also supports HDCP. The DRM plugin is technically not built into Android; it's a modular add-on. The interface to the DRM plugins is part of Android.
In order for DRM and HDCP to actually work the DRM system has to validate that the system can be trusted. (That's all that DRM does.) If the system is rooted, apparently the DRM system can not validly claim that the system can be trusted.
Google's YouTube Movie Rental service that's part of the Android Market on Android 3.1 apparently relies on the DRM system to validate that the system can be trusted. (This condition may have been part of the deal to get the movie studios to allow their content to be distributed and rented through the Android Market.) If the DRM framework reports that the system can not be trusted because the system has been rooted then the jig's up -- no movies.
Bottom line: you can't have a movie rental service that requires that the system be trustworthy and a possibly untrustworthy system that would result from the system being rooted. You can have one or the other -- not both.
What I'd like to understand is how pluggable these DRM plugins are. For most things on Android you can just replace the default thingy with your own (dialer, home screen are prominent examples).
How long until someone comes up with a custom DRM plugin that returns true for all validation requests?
You properly have to replace the entire component - eg you have to decrypt the movie (easy enough since the master key was leaked some time ago), talk to the hardware, etc.
The most interesting thing here, to me, is not that this happened — with the MPAA as it is — but this is the first time we've really seen something like this.
For example, the MPAA does not require Apple to block movie purchases or playback on jailbroken iPhones or Apple TVs. Maybe that something overlooked in the Apple contacts that they've gotten a chance to correct in their deals with Google?
There is probably a huge amount of truth to this. Apple puts enough effort into stopping jail breaking that they can easily claim their movie blocking is done through those efforts.
I would suggest that the lack of a Netflix app on WebOS would corroborate this. You only have to enter a short key combination to unlock the phone (put it into dev mode).
Yes the MPAA doesn't distribute the licenses, but no that doesn't mean they have nothing to do with it.
They influence under what conditions content can be played on a device. Consider the case of CableCARD, where a device manufacturer has to have their hardware and OS certified before they will be allowed to make a device and distribute drivers for it.
A consortium of cable providers enforces that requirement, but ultimately, content producers are the ones demanding these restrictions (like the various copy restriction flags).
This is completely unsurprising. The licensing agreements with the studios mandate these kinds of measures. If Google didn't do it, they wouldn't be able to play the game.
Or is there a crypto chain of trust in android devices, analagous to the "trusted computing" on the PC platform?
There is. Everything on an Android device, including stuff in the OS image, is signed. I would assume that the movie player would converse with the movie service and it would easily be determined that the player is not running on a system image provided by a trusted signer.
Subverting it would, I assume, require cracking the signing algorithm.
There are probably much easier ways; extracting keys from a local device (but this may only be a break of a single device, not a class break of all devices, hopefully), or exploiting bugs in any of the trusted binaries to load other code.
The trusted/measured boot process on PCs (which is not actually used by anything widely deployed, as of 2011) is similar, but I think the Android device will have an easier time.
The likes of HTC and Motorola are already shipping Android devices with signed bootloaders. It is increasingly likely that with tablet content deals for movies and tv shows in the works that there will be more use of signed bootloaders in combination with Android 3.1+ DRM frameworks.
The openness of Android, the OS, has nothing to do with it.
Google Movies service is just another application running on Android.
If you had "Dsl Movies" application for Android (or iOS or Windows) you would have a right to protect your service from people trying to watch the movies for free or extract them from your service and post them on the internet.
Why do you think that Google has no such right to protect their movie service?
As to general snarkiness about openness of Android: please come back when you can download source code to iOS or WP7 or BlackBerry, compile it and then install on your device.
As to general snarkiness about openness of Android: please come back when you can download source code to iOS or WP7 or BlackBerry, compile it and then install on your device.
While I agree the snarkiness doesn't help his point and in fact has no bearing on the argument at all, to say Google is OK to not release the source for their self-proclaimed, open system because other vendors have not released the source for their self-proclaimed, extremely closed systems is ludicrous.
I think his point is that Google has released their source. As he pointed out, Google Movies is an application and it doesn't have to be open-source just because the Android OS is open-source. It's a completely independent piece of code.
Anyway, this is much ado about nothing since I'm sure there will be a patched version out almost immediately.
Actually, the GPL and LGPL portions of Honeycomb have been in the repositories for a while. What most people are clamoring for, is actually the portions that aren't GPL/LGPL.
There are several ways to build vanilla Android just fine. The only Google App on my phone is Market. How are people so incredibly uninformed about Android still?
AllenKids either hasn't used an Android phone in the past 18 months or is getting his information for really poor/biased/uninformed sources.
Manually managing app/tasks in Android is a recipe for really poor performance and battery life. Anything after Eclair will handle app killing very appropriately. I've only had one app that needed killing and even then, I haven't had to kill it recently at all with CM7 running the show.
DRM and a truly open platform cannot co-exist. It is impossible. When you control a point in the stack, you control everything below it. A good example of this is VMware.
My comment was a bit snarky, the but the point remains. I can't get my hands on the latest sources so I can add a fix to prevent applications from detecting rooted devices (a cat and mouse game for sure, but beside the point). My money would also be on Google shitting a very large brick and trying to find a subtile way to prevent my patch from working.
But drm is not similar to a password the client doesn't know. In drm the client has to know the password, it's the user that's being kept in the dark. If you have total access (source) to the drm system you can always modify it to report that the system is secure.
Ha that is really going to help reduce piracy. Sorry you can't see our movies (even if you are willing to pay for them) because you might share them with your friends.
On the other hand, if you get them for free of some torrent or from rapidshare (and finding the links are much, much easier than rooting your phone) there are no such restrictions and the studio doesn't make a dime.
I wonder if they can keep this up? If they can successfully keep those devices blocked, there are other services that could be built on top of such technology, even if it's just Google throwing manpower and dollars at the problem to keep those cracking the system busy.
Correct me if I'm wrong, but won't this hurt Google's business rather than protect it? With no legitimate means of buying/renting movies on their Android devices people will likely resort to piracy.
For the users, it is either this or no movie player for them. No movie player means a big product disadvantage compared to competitors, which is very bad for Google as a company.
> I'd rather have no movies and no music than to have our technology become increasingly hobbled by the entertainment industry.
Unfortunately, whilst you're not alone in your sentiment, the majority of users to whom Android devices are sold don't care either way, and those are the same users that make Google the most money.
Not sure if that's the case. The company makes the most money from online ads, so is it better to foster long-term technology growth or to convince more people to use Android?
> Not sure if that's the case. The company makes the most money from online ads, so is it better to foster long-term technology growth or to convince more people to use Android?
Getting more Android devices into the hands of users now is important to Google: it increases developer appeal (growing the platform), which draws even more users (increasing advertising revenue). Having competitive, consumer-orientated features like this—that stack up against Apple (and Amazon)—are far more important to these goals than things like whether a device is rootable, themeable and/or side-loadable.
Consumers will become very discouraged quickly when they try to add a skin, or theme, or any customization, and all of a sudden certain applications will no longer work.
I feel this is akin to having a Windows PC that would disable Netflix streaming if you wanted to dual-boot your PC.
Android devices are the current generation of the previous Windows-era ecosystem. A bunch of clone hardware running slightly tweaked OEM versions of an OS.
The biggest difference, which consumers will really start to have issues with, is tying a software OS update to a hardware revision (If Dell prevented you from upgrading a Windows 98 machine to a Windows 2000 machine, not because of hardware limitations, but simply to generate more device sales).
> I feel this is akin to having a Windows PC that would disable Netflix streaming if you wanted to dual-boot your PC.
It's more akin to having a Windows PC that would disable Windows Media DRM files if you had unsigned drivers loaded into the kernel. Which it does. This isn't without precedent, by any means.
I don't see "our technology" becoming "increasingly hobbled" just because there's one Android app out there that doesn't want to cooperate with a rooted phone. If anything this is positive since it probably acknowledges that anyone with a rooted phone is going to be able to capture the contents of the movie in an unencrypted format.
ok, navigating a little on the linked page it seems it's option "some gMovie i've never heard about"
Quote some 2 clicks away from the linked "article":
Q: Where is my Videos app?
A: At this time, the Videos application is only available to Verizon Motorola Xoom users.[...]
Honeycomb adds a framework to support DRM plugins. Android 3.1 adds an actual implementation of a DRM plugin called Widevine (acquired by Google in Dec. 2010). Android 3.1 also supports HDCP. The DRM plugin is technically not built into Android; it's a modular add-on. The interface to the DRM plugins is part of Android.
In order for DRM and HDCP to actually work the DRM system has to validate that the system can be trusted. (That's all that DRM does.) If the system is rooted, apparently the DRM system can not validly claim that the system can be trusted.
Google's YouTube Movie Rental service that's part of the Android Market on Android 3.1 apparently relies on the DRM system to validate that the system can be trusted. (This condition may have been part of the deal to get the movie studios to allow their content to be distributed and rented through the Android Market.) If the DRM framework reports that the system can not be trusted because the system has been rooted then the jig's up -- no movies.
Bottom line: you can't have a movie rental service that requires that the system be trustworthy and a possibly untrustworthy system that would result from the system being rooted. You can have one or the other -- not both.