The kill switch discussion now includes the Android devices. Google in in their terms of service agreement for apps for the Android Marketplace reserves the right to remotely remove a violating application from Android devices. This recent discussion of remote kill switch first emerged in the iPhone context, and now it has moved on to Android G1 devices. It reminded me of an area of technology called Mobile Device Management, that I once had to spend some time with. If it’s indeed Device Management that is in play here, it’s kind of interesting to see it directly affecting users and developers in such overt way. Often this technology operates behind the scene, and undercover with little awareness on the user’s part.
It mostly has to do with ensuring the integrity of a mobile device and the basic idea is that this technology allows operators to provision a mobile phone with various settings so that the device is able to work in the operator’s network without bothering the user. The technology has gone through multiple iterations of standardization and the main intended beneficiaries of this technology are the mobile operators who, on this side of the pond, seem to own the devices by locking them down.
The degree or sophistication of its deployment seems to vary from operator to operator. When we call the service centers to help us with a phone problem and they seem to magically fix it a few minutes after the call, that is mobile device management in action.
The range of functionality that this technology enables is fairly wide and includes things like controlling network settings, and locking a device, which can be useful if the device is stolen with secret anti-terror information on it and is still within the reach of a network. Then there are things like locking down certain settings so that the user cannot change them inadvertently. Their justification sometimes comes from the realm of enterprise mobility, where a business with reasonably large mobile workforce would want to manage the devices that it gives out to its employees. When I come into office and connect my laptop to office network, often the first thing that happens is the launching of the virus scanner. It tries to ensure I am not the Trojan horse that wrecked the office network. Much to my irritation, the laptop then starts to crawl just when I am rushing to get online. But I have gotten used to it.
Similar ideas have existed in the mobile device management realm where the remote management server can launch tasks and applications on phones. It may include things like initiating an automatic software download, checking for unauthorized installation, mobile virus scanners, and so on. The idea is not very foreign when we start thinking of mobile phones as mobile computers. The more recent capabilities of mobile device management includes things like installing, removal, and upgrading of software. All these ideas often seems more relevant in the case of enterprises where, like in the case of their employee laptops, they might want to ensure the quality of installed software, assuming the company feels like it owns the phones and these are intended for business use. The wifi capabilities of some of the smartphones also seemed to add credibility to this line of thinking. This would require the business to deploy mobile management server and manage all their employee’s phones like their laptops. But in reality this is much more of a hassle than it is worth from the ROI perspective and seldom does the employees’ mobile network intersect with the corporate network. It is something best left to mobile operators for now. However, in some countries I believe the scenario of businesses owning and managing a mobile network is a distinct possibility.
If an anal retentive enterprise really really needed to deploy mobile device management to watch its employees they will have to do so in concert with the mobile operator and may be that is what we are seeing with Google and Apple. Only difference is it is aimed at consumers instead of enterprise users. I can safely guess T-Mobile also has lot to do with how Google approaches this option.
They also have other simpler ways of disabling apps without having to go through the operator’s mobile network, such as using sync software when it is enabled. They could also be using simpler over the air approaches than those defined by device management specifications.
Android’s security architecture says apps need to be signed, but does not have to be signed by a certificate authority. They can be self signed. May be having CA signed apps, like in the Symbian signed approach would have reduced the need for this kill switch model. But on the other side of the coin I have seen many griping about the challenges of the Symbian signed process.
In the end, I guess somebody has to strike a balance between fostering the developer community and the degree of control. I am not sure if users will be able to download and install Android apps from non Android websites and in that case how would Android treat those apps. Neither do I know how often this kill switch will be used in reality, and its mere existence may be a deterrent to violaters.