[personal profile] mjg59
There's been a sudden wave of people concerned about the Meitu selfie app's use of unique phone IDs. Here's what we know: the app will transmit your phone's IMEI (a unique per-phone identifier that can't be altered under normal circumstances) to servers in China. It's able to obtain this value because it asks for a permission called READ_PHONE_STATE, which (if granted) means that the app can obtain various bits of information about your phone including those unique IDs and whether you're currently on a call.

Why would anybody want these IDs? The simple answer is that app authors mostly make money by selling advertising, and advertisers like to know who's seeing their advertisements. The more app views they can tie to a single individual, the more they can track that user's response to different kinds of adverts and the more targeted (and, they hope, more profitable) the advertising towards that user. Using the same ID between multiple apps makes this easier, and so using a device-level ID rather than an app-level one is preferred. The IMEI is the most stable ID on Android devices, persisting even across factory resets.

The downside of using a device-level ID is, well, whoever has that data knows a lot about what you're running. That lets them tailor adverts to your tastes, but there are certainly circumstances where that could be embarrassing or even compromising. Using the IMEI for this is even worse, since it's also used for fundamental telephony functions - for instance, when a phone is reported stolen, its IMEI is added to a blacklist and networks will refuse to allow it to join. A sufficiently malicious person could potentially report your phone stolen and get it blocked by providing your IMEI. And phone networks are obviously able to track devices using them, so someone with enough access could figure out who you are from your app usage and then track you via your IMEI. But realistically, anyone with that level of access to the phone network could just identify you via other means. There's no reason to believe that this is part of a nefarious Chinese plot.

Is there anything you can do about this? On Android 6 and later, yes. Go to settings, hit apps, hit the gear menu in the top right, choose "App permissions" and scroll down to phone. Under there you'll see all apps that have permission to obtain this information, and you can turn them off. Doing so may cause some apps to crash or otherwise misbehave, whereas newer apps may simply ask for you to grant the permission again and refuse to do so if you don't.

Meitu isn't especially rare in this respect. Over 50% of the Android apps I have handy request your IMEI, although I haven't tracked what they all do with it. It's certainly something to be concerned about, but Meitu isn't especially rare here - there are big-name apps that do exactly the same thing. There's a legitimate question over whether Android should be making it so easy for apps to obtain this level of identifying information without more explicit informed consent from the user, but until Google do anything to make it more difficult, apps will continue making use of this information. Let's turn this into a conversation about user privacy online rather than blaming one specific example.

Date: 2017-01-20 03:17 am (UTC)
From: (Anonymous)
What you are describing is known as "attribution" in the industry.

Android's permissions are annoying even to honest developers. It is a very common case that you want your app to hold back if the user is in a call or one starts. READ_PHONE_STATE is how you find out, but it gives far more information than is needed. An interesting contrast is that Android gives you all the information (calling numbers etc) while iOS only gives opaque ids.

honest developers and READ_PHONE_STATE

Date: 2017-01-22 10:06 am (UTC)
From: (Anonymous)
Often, honest developers explain the needs for the permissions.
They also publish the source code (for example on F-Droid), so that it can be more easily checked.

Yes, this is interesting that iOS users are better protected in this particular case. Maybe because they paid a premium price and they put their trust in a single vendor, whose business model is not to sell their users privacy, for now.

Lying as a solution?

Date: 2017-01-20 08:31 am (UTC)
From: (Anonymous)
What I never understood: why doesn't the OS offer (apart from "allow" or "deny") the option to "lie" to the app (perhaps, when that makes sense in a range "slight" to "outrageous", e.g. for time or location)?

The app is happy, the user is happy.

I can only guess that this is because the OS isn't the user's ally. Duh. Who'd thunk of that.

Re: Lying as a solution?

Date: 2017-01-20 01:59 pm (UTC)
From: (Anonymous)
Would you consider writing a patch to one or more of the common open ROMs to add this functionality?

I guess you could do the same thing with apps that ask for a location for advertising purposes.

Re: Lying as a solution?

Date: 2017-01-20 04:09 pm (UTC)
lxe: (Default)
From: [personal profile] lxe
There is fake location input for advertising purposes in developer mode, AFAIK (speculating; seen it a lot of times but never used it).

One solution

Date: 2017-01-23 08:53 am (UTC)
From: (Anonymous)
would be to use XPrivacy (or something similar), which can give dummy values for these calls. So the app remains working, but doesn't get the real info. One needs a rooted phone for this, however.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags