Chris DiBona wrote a Google Plus post explaining how many industry vendors are touting Open Source to be inherently insecure and in turn this is exactly what makes Android devices insecure. DiBona steps up and says this is all hogwash in this post.
Follow up comments to his posting have excellent and worthy points who bring ideas and honest considerations to the table. Here are some of them if you are at all interested in educated discussions on the matter. (This is a good follow up to Molly Wood’s rant about Android from earlier in the year…)
In response to Chris DiBona’s recent posting about Android Malware infection rates being overly hyped and working mostly on ignorant fears, Charles Vaz writes a follow up comment:
Charles Vaz – Totally agree – Microsoft Windows is the only OS that people are forced to pay for from Windows 95 to Windows 98 to Windows XP to Windows Me to Windows Vista and all of these mainstream consumer OSes came without Virus protection and Consumers were still forced to buy these OS and install McAfee/Symantec/Norton Anti-Virus because of Microsoft Office being a good quality professional document creation system.
When Linux gets from LibreOffice or OpenOffice to Pro Level – then there would be a definite shift, consumers are already tired of paying double for MS Products on every OS release.
In the mobile arena – this is the primary reason apart from buggy Microsoft products – that consumers have moved away from Windows CE or Windows Mobile or Windows Phone since document viewing is great on open source or Apple IOS or Google Android products.
Why Android lost to Apple IOS was because of:
1. Initial versions of Android were buggy.
2. Android didn’t have well defined policies to security-validate and quality check Apps being uploaded into Android Market. Granted social policy would govern usage and download and rating of an App – but spurious Apps need only 1 chance tobe installed on a naive customer mobile device – and that causes more cost.
3. Android products are confusing – some only support Android version 2.1, some 2.3, some 2.7, some version 3 and many Android phones have custom non-modifiable-unless-rooted layer which makes it hard for customers to make an easy choice.
4. Older Android phones were made from cheaper hardware which turned away customers – that’s changing now.
5. Android mobile device cameras are typically worse than iPhone cameras for the same price points
Peter Sitterly – I think many of the warnings by these “virus” protection companies convince the unsuspecting public that all malware are viruses, which just isn’t true.
Furthermore, any malware which might exist for Android give notice up front about what this malware wants access to.
That aside, I do feel there is a tendency to suggest that everything is peachy and that if anything bad happens, it’s the fault of a dumb user who didn’t read the disclaimers. However, consider this… if I install a Tetris game and see that it wants access to my SMS messages, it’s simple enough for the alarm bells to go off and I simply don’t follow through with the install. However, imagine I install an application like JuiceDefender. By its very nature, since it tweaks various settings based on various criteria to maximize the battery potential, it does not surprise me that the application expects to: …receive and process SMS messages. (Malicious applications may monitor your messages or delete them without showing them to you)… view configuration of the local Bluetooth device, and to make and accept connections with paired devices… read from the system’s various log files. (This allows it to discover general information about what you are doing with the device, potentially including personal or private information)… access the phone features of the device. (An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like)… write to the USB storage… write to the SD card… modify the system’s secure settings data. (Not for use by normal applications.)
However, although I trust JuiceDefender now… what happens if one of the developers (or the developer?) goes rogue and on one of the updates decides to do a bunch of malicious stuff with this. On the next update, it won’t need any additional permissions (it already has all of the permissions it needs) and it could delete all of my SMS messages or nuke contents from my SD card or send a text message to everyone in my contacts list.
I think it’s these types of concerns that lead most people to believe that they can’t fully trust their own judgement when installing apps, no matter how careful they think they’re being. So, as a result, these anti-“virus” companies take advantage of this fear and talk about malware and viruses. I think that people envision a bunch of nefarious developers writing perfectly legitimate and useful applications, then pulling a trick on everyone and activating the hidden functionality in the app or updating it with something nefarious.
Years of history of the Internet, however, have shown that this is rarely the case. If an application is useful and installed by many, the publisher will usually find a way to profit from it and will want to protect his investment and will make sure intentionally bad behavior never finds its way into the application. So, most malware truly will be similar to a Tetris game that says it needs access to your SMS messages.
Nov 21, 2011
Andrey Yamshchikov – I’m surprised that no one’s explicitly mentioned how flawed Android’s security framework is. Am I the only one who thinks so? Let me elaborate.
While permissions are definitely a step in the right direction, they are currently not granular enough and the end user doesn’t have the amount of control s/he should. Specifically, I believe that as an OWNER (as in I paid for it and it belongs to me) the person should have the right to enjoy a completely unrestricted access to the system. But, currently, the only way to obtain this is to root the phone… at this point the idea of a developer-driven, open-source platform (and I won’t even mention “Java-based,” don’t get me started on the Dalvik VM) begins to deteriorate.
Why is there no support for the user to be able to grant the app some permissions and not others? Every app has a set of features and some features revolve around a particular permission(s) but that doesn’t mean the app should be an all-or-nothing kind of deal… Take an SMS app as an example. Does it ABSOLUTELY need access to my contacts? No. At its core, all it needs to function properly is two parameters: target phone number and the text message I wish to send. Is it NICE to have access to the contacts in order to improve usability? Yes. But why the hell can’t I specify what I want it to look at and where I don’t want it snooping at all? My personal favorite is “Network communication,” described as “full Internet access.” Really? I mean REALLY!? Just like that? How about as the OWNER of the phone, I’d like to have the ability to explicitly specify a list of URLs an app can connect to? How about I’d like to have a firewall on my device without rooting my phone? How’s that for a giant middle finger from Google?
Should I start talking about preloaded apps? You know, the ones I can’t even opt-out of (I won’t even mention about opting-in)? Nah, I think we all get that one…
Anyway, I think I’ve made my point. You can’t rely on developers or blame the end-users for any malware that might plague the market until there’s a robust security API which allows an extremely fine-tuned level of access for Android-enabled devices.
Nov 22, 2011
response to Andrey, from Peter Sitterly
+Andrey Yamshchikov I think it boils down to balance. That would be a nightmare for developers. You’d have to code for every possible scenario in which the user has disallowed access to certain things but not others. And, at the end of the day, maybe 1% of the users would actually take the time to tweak these granular controls. The majority of the people just want to install an app and use it, not have to run down a list of 20 checkboxes and then try to figure out if the app sucks because of one of the checkboxes you unchecked, or if the app just sucks.
It would also mean there could be thousands of different possible user experiences for a given app. Imagine the need for a granular review system. Imagine if your comment only applied to how unfriendly an app is when you disable X, Y, and Z. If you don’t specify your settings in the review, the app will sound broken to others reading your review, not realizing it’s only broken when you disable X, Y, and Z. In theory, the concept is sound. In actual practice, it will hardly make a noticeable dent in the ecosystem as a whole and will introduce more problems than it solves.
Nov 22, 2011 (edited)