MOTODEV Blog

[#1]

We know there has been continued interest in the topic of bootloaders on Motorola's Android devices as well as how we make use of the eFuse technology on DROID X and other handsets.  We've recently released a company statement with additional information which you can find below.

Regards,

Lori

----------------------

Motorola's primary focus is the security of our end users and protection of their data, while also meeting carrier, partner and legal requirements. The DROID X and a majority of Android consumer devices on the market today have a secured bootloader.  

In reference specifically to eFuse, the technology is not loaded with the purpose of preventing a consumer device from functioning, but rather ensuring for the user that the device only  runs on updated and tested versions of software.   If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed. Checking for a valid software configuration is a common practice within the industry to protect the user against potential malicious software threats.  

Motorola has been a long time advocate of open platforms and provides a number of resources to developers to foster the ecosystem including tools and access to devices for developers via MOTODEV at http://developer.motorola.com.

[#2]

These phones are Motorola's devices to sell and market in whatever manner they choose too. This I understand and it is how it should be. I have been very happy with my original Droid phone and I have enjoyed tinkering with it. As my first smart phone it is has come across as an amazing piece of technology for me. I've met others for whom this is far from their first smart phone and it also has been just as rewarding for them to use this device. Well done Motorola and thanks for a great device.

I can buy a computer from a variety of companies. I can then totally wipe that original software off of there, and install another OS. I do not want a windows computer to "protect" me from installing a newer version of windows, or even from installing a different OS such as Linux, which comes in many different flavors. Maybe even a more efficient version than what I first had. I may even overclock the unit.

I'd rather have that control via an app that registers my wishes and thus lets the hardware maker know I've opted out of coverage for a variety of items, such as toasted circuits if that is their concern, but perhaps not for items such as keys falling off the keyboard.

I'd like to mention that it appears the press out there indicates a more widespread community of "rooters" than what was perhaps first thought existed. This community has promoted the Droid, and helped with its sales. Good chance the reason for some of the press out there is due to that same community. You have to take the good press with the bad I guess.

Being happy with the moto-droid I've recommended it to many. In the future I will follow your advice and purchase a device such as the Nexus One that lets me use my device how I want to use it, as I should be able to, as long as I'm not violating any laws. Motorola has stated the original Droid was created with an open bootloader for business reasons. I'm curious what those were. I'm also curious how this hurt Motorola or end users and brought about a change in policy.

[#3]

Hello Lori,

First of all I want to make my compliments to communicate seriously with your customers by responding in this forum.

I believe that the success of Android for a huge part is realized due the open concept of Android.  In my point of view is securing handsets to prevent custom ROMs a method that is not in line with this concept. For that reason I’m really interested in the “specific business reasons” to secure handsets.

In a other post, you make clear that Motorola will not disclose the "specific business reasons" behind securing handsets, so I don't ask for that. But the eFuse technology is probably a solution to give users and developers more possibilities to customize their phones, without damaging the business reasons of Motorola. I say probably, because I don’t know the business reasons.

My idea is the following concept. As soon a non-original (non-signed) firmware is uploaded to the phone, the eFuse will “blown”. This blown eFuse will not have any impact to the phones functionality. It’s only a label for Motorola to detect that the phone has (now or in the past) not original firmware loaded. As soon as the eFuse is blown, Motorola does not have any product responsibility anymore.

I believe that the possibility to load customized ROMs will increase Motorola’s market share. Not only developers, but also early adaptors likes to play around with custom ROM’s. This early adaptors are mostly people who gives advice to regular users about the good and bad products.  I believe that it’s very important to get these early adaptors at Motorola’s side.

Of course, buying a HTC (and probably Samsung, Sony Ericsson or other product) is an option. But I like the excellent hardware quality of the Motorola products.

[#4]

This post is unresponsive to the question:

"Why use the Milestone/Droid X security model rather than the Droid security model?"

The additional security in the Milestone and Droid X do little to nothing in the way of giving end users additional security yet it makes it much more difficult to put custom firmware on the phone. The responses from Motorola have continually ignored this distinction. Should we give up on getting and answer and just jump to conclusions such as "VZW made you do it." etc?

In fact, you could have an unlockable boot loader like the Nexus One that ensures the product has a voided warranty and still allows users to do whatever they want with the phone they bought.

[#5]

Although eFuse hit the headlines, it's not the main issue. People are justifiable concerned that they will either be excluded from future Android updates or have to wait ages for them.

As someone who is happily running Android 2.1 on a G1 I won't buy a phone if I have to rely on my carrier for updates.

The other issue is bloatware and unwanted customizations. This plagues the PC market as well as the phone market - the difference being that it's easier to remove junk from a new PC.

As Android improves with every release I don't want to be trapped in a 24 month contract with a phone where I'm forbidden from installing the software I would to use.

[#6]

"We understand there is a community of developers interested in going beyond Android application development and experimenting with Android system development and re-flashing phones.  For these developers, we highly recommend obtaining either a Google ADP1 developer phone or a Nexus One, both of which are intended for these purposes."

Google just discontinued the Nexus One and shows no signs of making another dev phone. What now?

[#7]

What is to gain from this? It's just as easy to take someones phone, and steal important info by "sliding you finger", and being open to that persons sensitive information. The majority of people who get the Droid/X aren't going to go into those settings and take the time to find it. Sure people will do that, but I doubt the majority will. I'm only 16 and every Tom, Joe, and Sally, at my school has 0% protection for their device. If you honestly think that because someone is unable to access the recovery partition, and find their way into the locked phone, is going to stop them, is simply not true. Not yes, it is a “back up,” protection method, but how many people are savvy enough to pull that off? And how often is someone going to go through that trouble. It's not like the DROID X has a SIM card, and whoever takes it can pop another one in a call it theirs. I bought the DROID X, but I took my time debating weather I'd be happy with a device as locked down as it is. You made the right choice with the Droid 1, and if you don't think that helped you sell the phone, then read the thousands of blog posts, and forum threads, filled with people explaining why they are happy they were able to have a custom ROM, or install applications that require root access. The DROID X is a truely phenomenal phone, but if the next Droid “whatever,” has this severe amount of protection, I don't know if I'll be able to stay a customer.

I see no harm done to your business because you're choice with the original Droid. I'm sure the Motorola software engineers, have several items at home that they have tinkered with, and pushed beyond the recommended limits. Programmers do that, they tinker, they use their knowledge to make things the way they deem fit. We bought the phone, we've been loyal to the DROID brand, and we want to be able to manipulate OUR devices, the way we want to. Locking the bootloader is a pointless waste of time on your parts. They only reason I can see for this is because a few tech savvy idiots, want to go taking peoples phones. I have never heard a case where someone was unable to get a phone back because some got into the recovery partition. If I'm wrong with anything I have said, then please correct me. I wish to know why continue to hamper our efforts. We are hobbyist/programmers, we love Motorola, and the devices they manufacture, but the continuation of locking down you phones, is tarnishing of an amazing brand.

[#8]

I believe there are a lot of developers like me who would love to experiment with the excellent hardware that Motorola make and go byond the boundaries of Android app development. This will also help Motorola as they can buy out innovations by these developers which already optimized for their products.  Infact a separate open developer Droid X can be released with a little higher price than normal.

[#9]

There is no reason for the eFuse, is a useless reflection of  the crappy closed platform model and I think you will be surprised to learn that you are missing out on a large number of sales due to it.

I feel bad for the poor end users who get the Droid X and find out that Motorola stops producing OS updates for it and are stuck on ancient OS versions.

A perfect example is the ADP1 in which you speak, the last official OS update for ADP1 is 1.6.  Luckily as 3rd party developers have supported it I am currently running 2.2 on my ADP1 without any problems.

You don't have to support the 3rd party operating systems, you do have to support the blown eFuses you will be seeing on devices that should otherwise work.

eFuse == DRM  , users won't stand for it.

I can say I have lost all interest in ever purchasing another Motorola phone after this.  I will also be not recommending Motorola phones to all who ask about Android devices.

[#10]

I think Motorola management needs to understand the philosophy behing the GNU license. The basic idea is that GNU licensed software comes with a promise that the user will not be locked in when using the software, and in return you get to use the software for free. Access to the source is a means for doing this, not a goal in itself. The basic goal of GNU is not really universal acess to the software, although nice, but that the end user can fix bugs. And the license is written to try to uphold this intension. However, when GPL v2 was written, loopholes, such as signed bootloaders have popped up.

And this is the culprint. Motorola is (among a lot of other companies, btw) using a loophole in the license, and thus not fully providing the intended benefits of the GNU license. This is taking away users freedom, and this is bad bad karma, and will hurt Motorola in the medium to long term. (Apart from the obvious drawback of having just a few inhouse developers that can fix bugs instead of the whole user comunity, which means always being at a disadvantage when new features get released.)

The real point here is although att allows tivovization (locked bootloader), it was never the intention of GPL v2. It is pretty clear if you read the backround texts on GPL, and one of the major reasons why v3 was created, because it takes away the freedom to fix it yourself, a stated goal of GPL. This is very obviously a loophole. Although it's legal to be rude, its not a good thing. And I have the feeling that Motorola management isn't fully aware of how bad this is and looks, and the fact that other's do it as well is beside the point.

Thinkig that Motorola development team can keep up with all devolopments in the Android world, and fix everything themselves, is actually a sign of corporate hubris. The reference to business logic seems to imply that nobody noticed that open source have changed the rules of the game, all users are now part of the development team (although in a very varying degrees).

And this results in our old HTC Magics runs without the very disturbing bugs our Milestone have. Because of this, no matter how much I like the Milestone, to be honest to my friends I have to tell them that buying a phone with the equvalent of a hood that can't be opened for 3:rd party service is a rotten idea.

[#11]

motorola really really needs to come out with a custom rom friendly handset to address the customer segment who would like to customize their handsets beyond the 'cut-and-dried' android. or at least there'd need to be an 'official' way that a customer/developer could create a custom rom and install it. i'm skipping milestone (which i think is a good device) partly because of implied limitations (or am i incorrect?) that the milestone cannot be customized beyond a basic android 'skin' technologies like dalvik bytecode apps, android gui framework, NDK are all cool however as it is known (at least for now) that using Native apps could bring about significant performance improvements by simply coding in C, C++ http://code.google.com/p/android-benchmarks/ ideally one of the end game is perhaps to achieve a C or C++ accessible API platform such as those of LIMO http://www.limofoundation.org/ or the more lofty OMA http://www.openmobilealliance.org/default.aspx in the same spirit as linux 'distributions' and the emulating success of linux, a mobile device has limited hardware resources ram / rom , cpu speed and the need to run on low power to improve battery life between re-charges allowing custom rom would enable the developer to target a particular spin / of such an api framework using a C, C++, objective C based approach thereby providing apps which potentially run at native speeds on the mobile device