Is an Initially Restrictive API really a Bad Idea?
July 31, 2010 2 Comments
Security is a funny thing. Anything man-made can be man-broken and only naïvety is hard-headed enough to fail in accepting that fact. That’s not an invitation for developers to skip on implementing security as it’s all about increasing barriers for would-be hackers to try and tear down. However, no matter how many layers of security developers implement in their software, the strength and integrity of the security system is only as strong as its weakest link – usually the user. From lack of anti-virus or firewall protection to being victims of social engineering, users are often the cause of their own downfall in regards to security. Now, this post isn’t a lecture on security, but it’s something I think is relevant in light of the Android ‘openness’ available to developers against the more restrictive nature of the Windows Phone 7 platform.
There has been some disappointment within the developer community when it comes to accessing aspects of the phone. Due to the architecture of the phone, third party applications run in sandbox. That is, they are essentially isolated from the rest of the phone, including other third party apps. The API provides Launchers and Choosers to allow third party apps to have certain access to information on the user’s phone, but even doing this relinquishes control from the app to the underlying OS (whilst the app gets tombstoned). The question is, is this really a bad thing?
This post was inspired after I came across this CNET article explaining how around 20% of the 48,000 apps in the Android marketplace have access to private or sensitive information on the user’s phone. Now, Android as an OS isn’t to blame for most of the malware allowed to run. The apps still come with a manifest file and still require users to ‘okay’ the application accessing certain aspects of the phone such as the GPS, accelerometer, phone log etc… Yet, most users either don’t know what some of the permission requests mean, or they simply don’t care and ‘okay’ it as if it’s some sort of EULA😉. What this resulted in, according to the article, are applications that were able to make phone calls to premium lines and send an unlimited number of text messages at premium rates – all without the user knowing. To be fair to Google, a Google spokesman stated
“ [The Android Market Thread Report] falsely suggests that Android users don’t have control over which apps access their data”. “Not only must each Android app get users’ permission to access sensitive information, but developers must also go through billing background checks to confirm their real identities, and we will disable any apps that are found to be malicious.”
They do the best they can in order to prevent malicious software from getting through, but this approach may not be the best for the users. Should it really be a reactive approach rather than a proactive one that MS has taken? Of course, there’s no right or wrong answers, only points for and against.
Microsoft have taken the proactive approach in that developers require similar manifest files as seen in Android development. Users also need to allow permission to applications in order for them to access parts of the phone, but that’s really where the similarities end. The sandboxing nature of the WP7 platform means that even if the user allows permission, third party applications only have certain access to the phone. As mentioned earlier, even if the app wants to simply access the contacts list, it loses control and the OS takes over. This means that the application cannot interact in any way, shape or form to the contacts list until the user decides on their action, at which point the application can only retrieve certain information based on the user’s selection. This restrictiveness may initially hinder certain great app ideas from being developed, but it further ensures the security and privacy of the phone and, more importantly, the user. Another addition is the fact that there is no side-loading allowed on non-developer devices. Therefore, all applications must go through the Marketplace which means that MS can immediately pull the switch on an app should be it be found acting illegally. Google say that they too block malicious apps, but Android allows for side-loading. This results in many, potentially malicious, applications to be transferred via forums and websites not affiliated with Google in any way. Convenient? Highly. Dangerous? Yup. Unless you’re a power user or, at least familiar with technologies and common scamming techniques, there’s a high chance a great looking, fully functional application could be hiding a more sinister app that is secretly stealing data. Even if the app is found out, without a kill-switch, more people could have the same app running, unaware of its actions. Technically, the user did give permission to the applications so it’s not Android’s fault, is it ;)?
The post is getting quite long, so I’ll stop around here. It’s an interesting balance here between restricting developers and, in turn, creativity and allowing developers so much freedom that they can do whatever they like knowing that some users don’t understand what they’re giving permission to. As a hobbyist, I like hacking around with Android’s openness and being able to create pretty much anything. Commercially, as an independent developer, I like WP7’s approach of starting off restrictive and slowly opening up different avenues. Downside, of course, is that some app ideas will have to be placed on the back burner pending further SDK updates, but there are plenty of doable applications to wile away the time till the next update. As long as MS don’t remain fully locked down, I believe the path they’ve chosen of ‘tight security initially, then slowly opened up’ is the best approach in ensuring users remain as secure as possible. When things go wrong, users don’t usually blame themselves, but the app for stealing data and the platform for allowing the app to steal data. Last thing MS need entering this already difficult market is to show a lapse in security on the platform.