Smartphone cameras have advanced so tremendously over the past few years that they have almost completely replaced point and shoot digital cameras for the most of us. Furthermore, since our smartphones are always with us, the majority of us end up taking tons of photos throughout the lifespan of our devices. But what happens to all the old photos you take? Do you store them on an external hard-drive or keep them backed up to an online cloud service like Flickr? Let us know what your favorite way of storing old photos is and why.
SwiftKey and Google Keyboard: Ever Heard of User Privacy?
A few days ago, I wrote an article here discussing some changes in Google Play Store permissions handling, and how these changes may have adverse privacy risks for users. The comments on that article indicated an overwhelming amount of concern from readers as to the permissions being used by applications, with many looking to use App Ops or XPrivacy to protect themselves.
Today, I’m going to take a slight detour and look at the permissions needed by two popular apps: Google’s first party keyboard, and SwiftKey. Both of these are keyboard applications, and both are available for download for free on the Play Store (the latter now being “freemium” with for-pay themes available).
Despite these applications having direct access to every key you press, in entering every URL you visit, text message or Email you send, and password you type, it appears few people actually consider the permissions used by their keyboard, and the implications of this.
Let’s take a look at Google’s keyboard. Take note that I had to edit up the below image, as the Play Store web interface does its best to prevent you from seeing the full list of permissions in one view, Even with a 20″ monitor in vertical orientation, it still chose to hide most of them within this scrolling view. For your viewing pleasure however, I have brought the list together into a single view.
Let’s take a look at what’s going on here. First off, Google Keyboard has access to your own contact card, and accounts on your device. This means it has the ability to know who you are, and all of the Email (and other) accounts you have available on your device. That means it’s possible for them to see what Google/Dropbox/ Twitter/Microsoft Exchange/Facebook accounts you have available on your phone. I have absolutely no idea why this is needed, nor why people are willing to give this information over.
Next up, the app can read your contacts. That’s fair enough–Google obviously want to add your contact names to the spell-checker and auto-complete databases. This makes sense, and is something justifiable for a keyboard. The ability to modify or delete the contents of USB storage is somewhat strange, but while it does allow access to all your data stored on your “SD card,” there’s unfortunately no real way to do this in any more granular way. Ideally, Google would only use the secure /data/data storage, and therefore wouldn’t need this. Alternatively, they could use ASEC containers to transparently get more storage space on your SD card, without requiring any access to your persona files on the SD card.
The ability to download files without notification is where it starts to get properly concerning – note that these permissions are tucked away at the bottom of the list, so you must scroll to reach them. Quite why a keyboard needs the ability to not just download files, but do so without telling the user, certainly is worrying. How much data does it really need to download without telling you?
The ability to run at startup is fine. That’s something you would reasonably expect from a keyboard application. On the other hand, tucked away, immediately after perhaps the most innocuous permission, is the most invasive: full Internet access.
Yes, that’s right, Google Keyboard has full and unfettered access to the Internet, as well as your keystrokes, and contacts, and SD card contents, and identity. And our permissions list immediately jumps into saying that Google Keyboard can harmlessly use your keyboard. Anyone think there’s a little bit of “hiding” the nasty permissions going on here?
The next two permissions are innocuous, and allow access to the user’s custom dictionary—again, totally expected from a keyboard application. Finally, the permission to view network connections is requested. I once again cannot offer any insight as to why there’s a need for this, other than to facilitate the other existing permissions for accessing the Internet without your knowledge.
As a keyboard, Google’s offering is ironically rather well-endowed with permissions. Indeed, at this point, I thought it would be difficult to find a keyboard with even less regard for user privacy in its selection of permissions. Unfortunately, I was wrong.
SwiftKey, which recently became a free application, is a very popular third party keyboard, often lauded for its prediction algorithm being able to predict the next word you will use. Does this come at a cost, however, in its use of permissions? Once again, I have expanded this list, which was rolled up by the Play Store web interface into a scrolling list, so you can see all of the permissions at once.
At a quick glance, SwiftKey appears to be fairly similar in its permissions selection to Google Keyboard. The addition of In-App Purchases is due to its recent re-launch as a free app (rather than a pay-upfront app), and is not of great concern to privacy.
Our first difference is that SwiftKey has access to read SMS and MMS messages. This makes sense, given SwiftKey has a feature to learn language patterns from messages. Unfortunately, given that SwiftKey is a closed source application (like Google Keyboard), it’s difficult to tell exactly what is done with this data–more open source, high quality, keyboard choices are definitely needed on the market!
Another difference is that SwiftKey claims the infamous “READ_PHONE_STATE” permission. This gives access to your IMEI, IMSI, and SIMID identifiers, as well as phone numbers, and the details of the other party in any calls (including their phone number). At this point, I can really not think of anything to add here as to why SwiftKey might need this data. Sure, all apps compatible with Android 1.5 are shown as using this permission, as there was no dedicated permission for this at that time. Android 1.5 is a relic from 2009, however, so there’s no excuse for this being present today. I can only surmise that SwiftKey, in their infinite wisdom, have decided they would like to be able to track their users, and needed to have a unique hardware identifier like the IMEI to do so. Unfortunately while Google prohibits the use of the IMEI for advertising tracking (they want their user-resettable advertising ID to be used instead), they do not have a blanket ban on the use of device identifiers in general, which can be used to track your usage between applications, and provide a persistent means of identifying you in future.
Once again, SwiftKey featured full Internet access, a permission tucked away down in the “other” section. Am I the only one somewhat concerned that SwiftKey has full access to the Internet, as well as all of the other data it’s accessing (such as SMS messages, your identity details and accounts, and IMEI)?
It’s clear from only a brief look at the permissions of two popular keyboards–one being Google’s own, and one being SwiftKey–that there are some major questions to be asked about the use of permissions in “security-sensitive” Android applications. Apple’s iOS 8 intends to introduce third party keyboards in the upcoming release, with no Internet access available for these applications by default, and an opportunity for the user to deny the keyboard access to the internet if it requests it.
On Android, stock users don’t have this option. Fortunately, if you are a rooted user running the Xposed Framework, XPrivacy does help here. I have blocked every permission from SwiftKey, with the exception of accessing my user dictionary and SD card (where it stores its data), and it operates absolutely fine. I may not get the “advantages” of an Internet-connected keyboard (why, for the love of all that is Android, does my keyboard want me to sign into G+ to get “cloud” features? It’s a keyboard!!)
It’s clear that the Play Store is certainly trying to make it difficult to see what permissions are being used by apps, and the new changes to categorised permissions pose entirely separate and significant risks, as I highlighted recently. Maybe it’s time for technically savvy users to stop and take stock of what they have installed on their phone, and what apps they are trusting with all their keystrokes. Are you happy with your keyboard accessing the Internet without your knowledge? Did you know it could do that when you installed it? Lots of questions, it’s time for users to demand answers from developers, and take control of their own privacy, as it’s clear Google and app developers are not interested in doing this.
Want something on the XDA Portal? Send us a tip!
Before the release of Android 5.0 Lollipop, the Holo Design guidelines served as the official reference for Android design, right from IceCream Sandwich to KitKat. However, updates to the guidelines were few and far between, leading to a lack of synchronization between Android design and current UI/UX trends. Google seems to have learned from their mistake the last time around, and earlier this week, a significant update was released for the Material Design guidelines, marking the second revision in less...
New Privacy concerns have emerged regarding Cyanogen’s latest announcements, primarily the inclusion of email app Boxer and that of a multitude of Microsoft apps, including Bing services, Skype, OneDrive, OneNote, Outlook, and Microsoft Office. The concerns arise when you look at both announcements together. At face value they may appear to be the beginning of Cyanogen’s plan to “take Android away from Google,” however there is certainly something more nefarious occurring. Along side the partnership with Microsoft, Cyanogen also recently announced...