Pulser_G2 · Jun 12, 2014 at 07:00 am

SwiftKey and Google Keyboard: Ever Heard of User Privacy?

unnamedA 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.

Google Keyboard

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.

Google Keyboard Permissions

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

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.

SwiftKey Permissions

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)?

Conclusion

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!
TAGS:

Pulser_G2

Pulser_G2 is an editor on XDA-Developers, the largest community for Android users. Developer Admin at xda-developers, interested in everything in mobile and security. A developer and engineer, who would re-write everything in C or Assembler if the time was there. View Pulser_G2's posts and articles here.
Mario Tomás Serrafero · Mar 30, 2015 at 11:00 pm · no comments

Would the LG G4 Fare Well With The Snapdragon 808?

The LG G4 has a lot to prove, given that last year’s LG G3 was among the best smartphones of 2014. The Global Mobile Awards given out during the time of MWC 2015 named it the Smartphone of The Year (SOTY?) alongside the iPhone 6, and at the time of its release it packed the very best in Android specifications, from the powerful Snapdragon 801 to the class-leading 1440p display. The camera, battery life and feature set were also deemed...

XDA NEWS
GermainZ · Mar 30, 2015 at 02:41 pm · 3 comments

DexPatcher: Patch Android APKs Using Java

You've probably seen or installed modified applications, be it a patched dialer for your resolution or a custom WhatsApp version with added features. How do developers do that, though? A lot of the time, the applications' source code isn't even available, so how does it all work? We'll see that first, then take a look at a new tool that aims to make the process much easier, and finally compare it to the popular Xposed framework to see how they...

XDA NEWS
Emil Kako · Mar 30, 2015 at 01:53 pm · 2 comments

Is Cloud Storage Ready to Replace External Storage?

With more and more OEMs ditching SD cards on their flagships, cloud storage is becoming even more important in the mobile world. Services like Dropbox and Google Drive have already become widely adopted by the majority of smartphone users, but is cloud storage ready to replace external storage? Let us know your thoughts below.

DISCUSS
Share This