Chromecast

[reggie14]

Originally Posted by wayner

Is Cyanogenmod only useful if you have an Android phone and want to Jailbreak it and install this mod?

CyanogenMod is an alternative build of the OS, not an app that needs root. So, to install CyanogenMod you need to unlock the bootloader of your Android phone and flash it (which is sort of like restoring an image). Unlocking the bootloader is often associated with rooting/jailbreaking an Android phone, but it's not the same thing.

I should also note that while almost every Android phone is root-able (meaning you can grant apps root access), not every Android phone has an unlockable bootloader. For instance, the current version of the Samsung Galaxy S4 firmware is rootable, but you can't unlock the bootloader to install things like CyanogenMod.

The CyanogenMod Chromecast functionality might get ported to other firmwares, but even if that's done I suspect it will only get ported to developmental firmwares. That is, you'll still need a unlocked bootloader with custom firmware. More limited functionality, like this, might be widely available on any Android device.

[sic0048]

Originally Posted by reggie14

CyanogenMod is an alternative build of the OS, not an app that needs root. So, to install CyanogenMod you need to unlock the bootloader of your Android phone and flash it (which is sort of like restoring an image). Unlocking the bootloader is often associated with rooting/jailbreaking an Android phone, but it's not the same thing.

I should also note that while almost every Android phone is root-able (meaning you can grant apps root access), not every Android phone has an unlockable bootloader. For instance, the current version of the Samsung Galaxy S4 firmware is rootable, but you can't unlock the bootloader to install things like CyanogenMod.

The CyanogenMod Chromecast functionality might get ported to other firmwares, but even if that's done I suspect it will only get ported to developmental firmwares. That is, you'll still need a unlocked bootloader with custom firmware. More limited functionality, like this, might be widely available on any Android device.

While this post is actually pretty good at explaining the situation, there is one flaw that I feel needs to be clarified - you don't need an unlocked bootloader to install custom ROMs.

You can flash custom ROMs on phones that have a locked bootloader, but are rooted. Those custom ROM won't be able to change the lowest level of programming on the phone (like the kernel), but you can still get most if not all of the functionality of the custom rom even on a locked bootloader. You also cannot change the underlying Android OS version until your service provider releases it for your phone. So for example, Google recently released Android 4.3's source code, but if you have a locked bootloader, you cannot upgrade to a ROM that uses the 4.3 code until your carrier releases the OEM 4.3 version for your phone. If there have been 4.2.2 and 4.1 releases from your carrier however, you can switch between 4.2.2 and 4.1 ROMs without any problems. Again this is because with a locked bootloader you cannot change the low level programming of the phone and they have to rely on the available OS versions that your carrier has released. I'm not sure if the Chromecast functionality that is going to be built into CM will require access to the low level programming or not. At first blush, I suspect that it will not need to access this low level programming, but I'm not sure. If it does require the low level access, then this feature will not be available on CM ROMs that are built for devices with locked bootloaders.

To make flashing custom ROMs on locked phone easier, there is even a system out there called Safestrap. It is also easier to recover from a problem because the original OEM ROM is not overwritten as it was in the "early" days of locked bootloader ROMs. Instead, it turns your phone into a multi-boot system where you can choose which ROM you want to boot into - either the original OEM rom, or one of your custom ROMS (you can install up to three different custom ROMs). Of course you pick a default ROM which the phone will boot into unless you stop the process and change the boot option.

It is also important that people understand that every phone comes with a locked bootloader. The problem is that most of the phones out there actually have an encrypted bootloader which means you cannot unlock it - ever - unless you have the encryption key from the service provider (and they never release those). On the other hand, there are a few phones out there that do not come with an encrypted bootloader and therefore you can unlock the bootloader with just a couple of easy steps.

Having an unlocked bootloader is far superior to a locked bootloader. My first Android phone was a DroidX which had an encrypted bootloader. While even back then we could flash custom roms, the limitations made me realize that I wanted an unlocked phone. My current phone is a Galaxy Nexus which came with a locked bootloader but it is not encrypted and therefore can be easily unlocked. I've vowed never to buy another phone that has an encrypted bootloader. Once you have seen the light, you will never go back!

[wayner]

So this is only useful to those who have Android phones and not someone like me with an iPhone?

[reggie14]

Originally Posted by sic0048

You can flash custom ROMs on phones that have a locked bootloader. Those custom ROM won't be able to change the lowest level of programming on the phone (like the kernel or OS version), but you can still get most if not all of the functionality of the custom rom even on a locked bootloader.

Interesting! I mean, it makes sense that this would be possible (depending on the boot chain), but I didn't realize anyone was doing this. I thought the bootloader of at least some phones did signature checking on the next component before passing control to it. Do you know how that works?

Originally Posted by sic0048

Also, it is important to understand that every phone comes with a locked bootloader. The problem is that most of the phones out there actually have an encrypted bootloader which means you cannot unlock it - ever - unless you have the encryption key from the service provider (and they never release those).

I've never completely understood the terms "locked" and "encrypted" bootloaders. When people say "encrypted," do they always mean encrypted, or do they sometimes mean signed?

There are certainly some phones that don't have encrypted bootloaders that are not (easily) unlockable. It seems like most Android phones have locked bootloaders that may or may not be unlockable. Take the S4, for example. The bootloader is locked. You can unlock easily on T-mobile and Sprint, I believe, but not on AT&T and Verizon. I don't think the bootloader is encrypted on those, it's just that the firmware blocks you from unlocking it. But, you may be able to bypass those protections if you can find a vulnerability in the bootloader.

Originally Posted by sic0048

Having an unlocked bootloader is far superior to a locked bootloader.

From a flexibility point of view, sure. From a security point of view, absolutely not. Having an unlocked bootloader really gives anyone with physical access to your phone complete control over it.

I haven't tried it yet, but it looks like more recent versions of TWRP let you turn on device encryption. That would give you some protection, although it really depends on your password at that point.

Like you, I now try to get phones with unlockable bootloaders so I can install ROMs. But, somewhat ironically, I spend a lot of time at work talking about the security horrors of mobile devices with unsecured boot chains. I unlock and root my phone for two big reasons: 1) I want to run relatively new versions of Android, and Verizon rarely updates phones, and 2) backing up and restoring application data is a pain without root.

I do some other stuff with root too, but I wouldn't really miss anything except for those two things.

[sic0048]

Originally Posted by reggie14

I've never completely understood the terms "locked" and "encrypted" bootloaders. When people say "encrypted," do they always mean encrypted, or do they sometimes mean signed?

Actually "signed" might be the term they use - I'm writing this off the top of my head. But even then, it basically is a type of encryption that will only open itself to "signed" updates (which means it includes the encryption key). Those "signed" updates are only released by the carriers. [strike]I am not aware of any developer that has been successful in breaking this encryption system.[/strike] EDIT - I guess developers are having success getting around some of the signed bootloaders now.

[reggie14]

Originally Posted by wayner

So this is only useful to those who have Android phones and not someone like me with an iPhone?

Yes. I don't know if its possible for someone to create something similar for jailbroken iPhones. I suspect it's theoretically possible, but infeasible in practice. The Cyanogenmod folks can see the code they're mucking with.

Apple already has AirPlay in their ecosystem, and it's decently supported by their apps.

[sic0048]

Originally Posted by wayner

So this is only useful to those who have Android phones and not someone like me with an iPhone?

At this time, the CM type changes (which are built into the system at the OS level vs an app) will only be available to Android. It's another clear example of why the open source Android OS is far superior to the Apple iOS IMHO. The Apple OS is too locked down to allow for these types of core OS changes.

Of course there may eventually be an app developed that would allow you to stream local content from an Apple device to a Chromecast, but that is technically different than having that ability built into the OS. It would be like having a Airplay app instead of having Airplay built into the core OS. An app might give the same end result, but it won't be anywhere near as convenient to use.

[reggie14]

Originally Posted by sic0048

Actually "signed" might be the term they use - I'm writing this off the top of my head. But even then, it basically is a type of encryption that will only open itself to "signed" updates (which means it includes the encryption key). Those "signed" updates are only released by the carriers. I am not aware of any developer that has been successful in breaking this encryption system.

I'm not sure if this falls under what you're talking about, but here's an excellent blog post describing how someone managed to unlock the bootloader in some Motorola phones.

It's interesting that Motorola went to the effort to use ARM TrustZone to protect the bootloader, but then didn't bother to blow a particular fuse that would would have rendered the device permanently locked. I wonder if an engineer at Motorola intentionally didn't blow that fuse.

[sic0048]

Originally Posted by reggie14

There are certainly some phones that don't have encrypted bootloaders that are not (easily) unlockable. It seems like most Android phones have locked bootloaders that may or may not be unlockable. Take the S4, for example. The bootloader is locked. You can unlock easily on T-mobile and Sprint, I believe, but not on AT&T and Verizon. I don't think the bootloader is encrypted on those, it's just that the firmware blocks you from unlocking it. But, you may be able to bypass those protections if you can find a vulnerability in the bootloader.

The decision to sign/encrypt a bootloader is made by the carriers. Of course they work with the manufactures to make it happen, but ultimately it is AT&T and Verizon that have decided to make unlocking the bootloader of the S4 hard. They do it to "protect their proprietary programming" that they put on the phone. In other words, they don't want you removing all the carrier alterations and "features" that they have added and they don't want people/companies copying that code either.

[Fuzzy]

Originally Posted by sic0048

The decision to sign/encrypt a bootloader is made by the carriers. Of course they work with the manufactures to make it happen, but ultimately it is AT&T and Verizon that have decided to make unlocking the bootloader of the S4 hard. They do it to "protect their proprietary programming" that they put on the phone. In other words, they don't want you removing all the carrier alterations and "features" that they have added and they don't want people/companies copying that code either.

They also want to slow the advancement of OS features, so that the easiest way you can get the new shiny features, is on the new shiny phones.

[wayner]

Originally Posted by reggie14

Yes. I don't know if its possible for someone to create something similar for jailbroken iPhones. I suspect it's theoretically possible, but infeasible in practice. The Cyanogenmod folks can see the code they're mucking with.

Apple already has AirPlay in their ecosystem, and it's decently supported by their apps.

I have a corporate supplied iPhone (just switched from BB) so Jailbreaking is not in the cards, at least not unless I get my own phone.

[reggie14]

Originally Posted by sic0048

The decision to sign/encrypt a bootloader is made by the carriers. Of course they work with the manufactures to make it happen, but ultimately it is AT&T and Verizon that have decided to make unlocking the bootloader of the S4 hard. They do it to "protect their proprietary programming" that they put on the phone. In other words, they don't want you removing all the carrier alterations and "features" that they have added and they don't want people/companies copying that code either.

I'm sure there are business reasons at play too, but I'm a bit less cynical about the motivation for locking bootloaders. Right or wrong, there are different expectations on the carriers regarding mobile phones than there are on regular ISPs and laptops/desktops. There are reasonably good support and security reasons to lock bootloaders. If you hose up your laptop it's not Comcast's problem, but if you hose up your phone it is Verizon's. And, unlocking the bootloader gives you access to muck with the baseband radio firmware, which some carriers are understandably nervous about. I've heard incredible stats from carriers on the percentage of service requests on phones caused by rooting/unlocking. I'm more than a little skeptical that they're accurate, although I'm fairly confident the people saying them believe them to be accurate.

Wearing my personal hat, I like the flexibility unlocked bootloaders give me, although I wish there were more protections in place (both for the user and the network operator). Wearing my work hat I'm inclined to say lock it down and come up with better ways to solve some of the problems that lead people to unlock (e.g., more timely updates, better backup/restore capabilities).

Unlockable phones that start off locked is an OK compromise, although even then I really think you need a way for the phone to report whether its locked or not (preferably without looking at the phone). I wouldn't want to let my employees do BYOD with unlocked devices.

[panteragstk]

Originally Posted by reggie14

While it sounds interesting, I'm not sure how useful it will be. What apps does it work with? I mean, it's not "everything." I doubt it will work with Netflix/Hulu/HBO Go and other streaming apps with protected content.

From the demo it seems that anything that can play video will be able to be sent to chromecast. HBO go and hulu and many others are going to have official support soon anyway. Plex as well.

[Fuzzy]

Originally Posted by panteragstk

From the demo it seems that anything that can play video will be able to be sent to chromecast. HBO go and hulu and many others are going to have official support soon anyway. Plex as well.

The idea is it's anything that uses the core playback API's. Not sure if Hulu/Netflix et al do so. Basically, this replaces the 'rendering' part of the API with a stream to chomecast - I'm guessing.

[panteragstk]

Originally Posted by Fuzzy

The idea is it's anything that uses the core playback API's. Not sure if Hulu/Netflix et al do so. Basically, this replaces the 'rendering' part of the API with a stream to chomecast - I'm guessing.

It seems that's the way he did it. The preview app isn't all that great. The videos have to already be on your phone or in dropbox or drive.

The demo shown was that you could start playing anything that used the android player and it would stream to chromecast. I'm pretty interested in how plex implements this. I was really hoping you could just play a video in the default player and then pause and choose to stream to chromecast. That would make phoenix remote able to stream anything to chromecast. That would be very nice.

[reggie14]

Originally Posted by panteragstk

From the demo it seems that anything that can play video will be able to be sent to chromecast. HBO go and hulu and many others are going to have official support soon anyway. Plex as well.

It works with any app that uses the built-in Android media player. I'm not sure what that includes.

[panteragstk]

Originally Posted by reggie14

It works with any app that uses the built-in Android media player. I'm not sure what that includes.

As of now the AirCast demo app doesn't even do that much. Once the functionality is built in we'll see how it works. I have to think that quite a few of the app devs for the more popular video/streaming apps will build this functionality into their apps negating the need for the "workaround". Time will tell.

[reggie14]

Originally Posted by panteragstk

As of now the AirCast demo app doesn't even do that much. Once the functionality is built in we'll see how it works. I have to think that quite a few of the app devs for the more popular video/streaming apps will build this functionality into their apps negating the need for the "workaround". Time will tell.

I'm inclined to agree. The "big" streaming services (Netflix, Hulu, HBO, etc.) will either built it into their products or find a way to block it.

I guess there's a relatively big tail of apps that include a little bit of streaming. Those folks likely don't bother with DRM, and probably are much less likely update their apps specifically to support Chromecast. I don't care about those much.

[valnar]

http://www.muktware.com/5857/google-...-local-content

[PiX64]

Originally Posted by valnar

http://www.muktware.com/5857/google-...-local-content

that right there makes me unhappy.