![\"](\"https:\/\/wapreview.com\/images\/certError.png\" "\\"")
Mobile application signing is something that I’ve never heard a user or developer ask for or say anything good about and yet we are stuck with it. Worse yet, I see a disturbing trend where mobile network providers and phone manufacturers are requiring applications to be signed in order to even make an http connection. Which is a crying shame as most apps outside of the those for sale on the carrier portal are unsigned. Consumers are finding that using unsigned software on many of the newest handsets subjects them to a barrage of annoying and repetitive prompts<\/a> to allow the app to connect to the network – if the application even works at all<\/a>.<\/p>\nAt least my phones still let me grant http connection permission to unsigned applications. Until recently almost all phones let the user chose “always allow” for network connections on an application by application basis. But the latest devices from ATT\/Cingular and T-mobile (USA) have taken even this option away. The support forums of Opera Mini<\/a>, Google Maps<\/a> and Gmail<\/a> are rife with users complaining of the applications either not working at all or constantly and repetitively prompting for permission to access the network.<\/p>\n At his Forum Nokia Blog, Nokia Java ME champion, Hartti Suomela has a series of posts describing how carriers are restricting the APIs that unsigned applications, which run in the “Un-trusted 3rd Party Domain”, are allowed to use. The latest Cingular phones prompt the user to grant permission every single time an unsigned app like Opera Mini, Gmail or Google Maps accesses the network. Unsigned apps on Cingular<\/a> are totally prohibited from accessing the user’s phone book, calendar or location, making bluetooth connections or sending and receiving SMS or MMS messages. T-Mobile USA goes even further totally blocking unsigned apps from any network access<\/a> at all which is why Google will tell you that Gmail and Google Maps are not supported on T-Mobile.<\/p>\n To me this is completely wrong. As a user I’m typically paying my carrier a minimum of $600 a year for a voice plan plus an unlimited data plan. Sure the handset price is subsidized, but the user is paying that subsidy back over the life of the contract. As the customer and owner of the hardware and of my personal data, I should be the sole arbiter of what the applications I install on my phone should be allowed to do. To be sure, I’d like the phone to warn me when an app is unsigned or is about to do something potentially dangerous to my pocketbook or privacy, but having been warned it should be my call as to whether to allow the access. I should also be able to give permission to “always allow” on an app by app basis if I want to. That’s how security is handled on PCs and the Web. Microsoft and my ISP don’t dictate that applications have to be signed to access the network, bluetooth or a GPS unit. If they were to try they’d lose a lot of customers to unrestricted OSs or ISPs.<\/p>\n Signing is supposed to help protect the user from “rogue” software like viruses. Some mobile carriers also claim that signing is needed to prevent users from installing malicious or poorly written software that could disrupt or even bring down their networks. There may be a kernel of truth in this for native apps (Symbian viruses do exist) but it’s pure fear mongering for the sake of economic gain in the case of Java apps. There are no Java ME viruses and I haven’t heard of a single documented case of a Java application harming a network.<\/p>\n While signing seems like a good idea in principle, in practice it’s a huge headache for mobile developers and consumers. There’s a good explanation of how signing works and why it’s so costly and time consuming for developers on Mihai Preda’s blog.<\/a> In summary, signing a single application with one certificate costs hundreds of dollars per year. There’s no one certificate that works on all phones and carriers. To get the certificate required for some phones the app must also be certified on each handset model at additional couple of hundred dollars per phone model.<\/p>\n Needless to say, free software, even from major vendors like Opera and Google, is almost never signed. Carriers even lock down APIs so that they require a certificate in the “carrier domain” which of course is only available from the carrier. This is commonly done for APIs controlling features like location and uploading pictures – areas where the carrier sees a revenue opportunity for themselves. These carrier domain certificates are usually only available to the carrier’s on deck content provider partners.<\/p>\n The worst thing about this whole signing mess is that it is holding back progress and innovation in the mobile data space. Remember the original Palm Pilot? A simple organizer that quickly became a full-fledged computing platform and must-have device. Palm’s initial success was largely due to the thousands of applications that were created almost immediately by independent and amateur developers. The rapid proliferation of software was possible because of the openness and low barriers to entry of the platform. With signing the carriers are locking out the most innovative and nimble group of developers – the small shops and individuals. It’s sad but not unexpected to see the carriers doing this for the short term economic gains of having a monopoly on the sale of things like a GPS driven turn by turn directions application.<\/p>\n What can a user do if they want a phone that lets them, not their carrier control what applications can do? Surprisingly little. Buying unlocked and unbranded phones helps somewhat. But thanks to Sun and its Java Community Process (JCP), even expensive unbranded phones often have their Java APIs restricted by heavy-handed signing requirements. This PDF document<\/a> describes the JCP’s recommended security policy with regard to application signing which Java ME licensees are expected to follow, unsigned applications are in the “Third Party Protection Domain” and access to messaging and user data (phonebook and calendar) is “Oneshot” only, aka prompt every time – probably not what the user trying to copy his contacts would choose.<\/p>\n Another option if you’re willing to invalidate your phone’s warranty is hacking your phone. You can defeat the signing requirements on many Motorola GSM feature phones with Motorola Midlet Manager<\/a> which was recently featured in PC Magazine<\/a>, no less.<\/p>\n Long term the best bet for users wanting freedom from unneeded security limitations may be phones running a truly open version of Linux. The first of these, the GreenPhone<\/a> is shipping and the release of the FIC OpenMoko<\/a> (more here<\/a>) is supposed to be imminent. Both the GreenPhone and OpenMoko are really aimed at developers, not end users – initially the only installable software for them will be what you write yourself. But these phones buyers will be open source developers who will be writing and porting all sorts of software for them. I’m hoping that in a year or two we will see open Linux phones on the consumer market with a rich library of free, unencumbered software. With Sun open sourcing Java ME<\/a>, developers will be free to create a JVM with no signing restrictions to complement the open OS. I could see Linux and open source Java combined with cheap generic hardware from upstart manufacturers really shaking up status quo where the carriers control the mobile computing environment – great for users but also for innovation and ultimately for the mobile industry.<\/p>\n","protected":false},"excerpt":{"rendered":" I’m sick and tired of network operators and handset manufacturers blocking applications from access to certain phone features in the name of “security”. This may not be an issue for the majority of mobile users who never install programs on their phones. But for someone like me interested in pushing the limits of what can be done with these little computers the limitations are very frustrating. I install every native and Java application I find just to see what it … Continue reading