Google Android: How to kill a perfectly good platform
Sunday, November 18th, 2007
From what I can tell so far, Android seems to be a well thought out architecture that can seamlessly join lightweight application components today and scale well to better hardware in the future. Personally, I hope it will blow away J2ME (or JavaME?) including the long awaited MIDP 3.0 platform, by offering multi-process control and application interconnectivity out of the box.
At the time of writing, Google have released an SDK containing an early implementation of most API’s and have asked for feedback. We are told that any final implementations and the first actual devices are as much as a year away.
Going through the published material, it seems that not much detail is being given about the security implementation, which perhaps should scare me a little.
If you hire a room full of security experts, ask them to review your platform (much like in the early Java days) and make recommendations, they will provide you with a list of security requirements that will lock up the platform and kill off a lot of potential innovation.
As Security requirements tend to be overriding, the functionality is locked down now and only rolled back later under intense pressure (if ever?).
This post is an appeal for balance.
An open platform
What is an open platform when it is installed on a preparatory hardware device, distributed by network operators (with a financial interest in maintaining control over their customer’s behaviour) and integrated into pre-existing content controls and enterprise requirements?
Will we see open content?
I have no idea how DRM can be implemented within an open source environment, but right now most phones that I’ve encountered prevent the user from sharing content in a way they would expect to share files on their PC.
Most ‘non-smart’ phones will refuse to forward media, e.g. receive a picture and then send it to a friend’s phone via Bluetooth. Nokia phones will refuse to forward or save JAR files. Samsung phones (the worst offender I have seen) will refuse to run any Java application that has not been downloaded via OTA. As a developer I can tell you that this is a real pain.
I don’t agree with the limiting mechanisms, but many companies have made a good living supplying ring tones, wallpapers, games, etc via OTA downloads. As a developer who has made advertising content intended to be distributed for free, it breaks my heart to see my target audience of teenagers perhaps paying €3 to download a Bluetooth application they have already seen installed on a friend’s phone.
It just illustrates that the current system is so bad you can’t even give stuff away.
Will we see open APIs?
Say I want to write a client application that seeks out other phones over Bluetooth, finds a phone with a similar client, and then quietly shares content over a peer-to-peer connection. Updating content in the background throughout the day and giving it to the user upon request.
In J2ME this can’t be done, period.
Not because the hardware can’t support it, not because of a failure of the API (JSR-82 implemented this functionality quire well), but because the security people decided that it was a security threat.
That means that the users would have to approve every peer-to-peer connection (making the application pointless), or the application would have to be signed. Signed applications will only install on the phone within a specified time period (a certificate might last one year) and if the correct code signing certificate is already installed on the phone (good luck with that one). Just to make things more interesting, it’s considered a security threat to let the user install new certificates on their own devices.
Don’t you just love security consultants?
The current system seems to benefit few outside of Veresign, who have somehow managed to get their certificates installed on most devices that I’ve tested. A Veresign (or handful of other company’s) code signing certificate is a heavy upfront investment for a university/garage based project prototype (the sort that make history) and the fallback functionality of the application refusing to install is pretty ugly.
I don’t know how to best control API permissions.
Nokia (the first to implement this API on a mass market phone, the 6600), assumed that the user was too stupid to know whether to approve this functionality or not (is this a fair assumption?). Other manufactures differ slightly, but tend not to document permissions implementations which can vary between firmware versions.
Perhaps Google don’t need my advice, but as they haven’t released their Bluetooth API implementations yet I can only guess what kinds of things they are negotiating with interested parties while I write this.
More on the evil world of crippleware.
