A years-old privacy flaw will finally be coming to an end on Android. It’s an issue you’ve probably never heard of, but one that you should absolutely be concerned about. Currently, apps on Android can gain full access to the network activity on your device – even without asking for any sensitive permissions. These apps can’t detect the content of your network calls, but they can sniff any outgoing or incoming connection via TCP/UDP to determine if you are connecting to a certain server. For instance, an app can detect when another app on your device connects to a financial institution’s server. Don’t believe me? Just download one of the many netstat apps on the Play Store and see for yourself.
I had no idea this was an issue at all. Good to see it fixed, and since it’ll probably be part of a monthly security update, it’ll propagate to most Android devices.
So I guess this probably won’t get back ported to Oreo?
WorknMan,
Haha, I’m still on lollipop and not receiving updates. At least it’ll be fixed on new phones.I’m not as bothered by this as not being able to limit app access to my contacts and other personal information, which is very invasive; I shouldn’t have to give that out just to run an app. As indicated in a recent article, app developers have a financial incentive to collect more than the app needs to function so that they can turn around and sell it
When apps are adamant that they want access to something you don’t want to give in order to run, why can’t you give them ‘fake’ permission?
Like access to a fake contact list, fake sms access, etc?
For some things, this might make sense, but the only sensible approach to generalize it for pretty much all of the standard Android permissions where it does make sense is to just show empty data sets for them (empty calendar and contacts list, total silence on the mic, black image on the camera, etc).
For a small handful of things, it’s more an issue of the permissions being too coarse. For example, getting a unique ID for the handset, which is a not all that uncommon case for some games, is lumped in with permissions to make phone calls, because you have to access the SIM card to do it, even though it doesn’t touch the cell radio itself.
For some things though, it gets into really problematic situations and potentially even really shaky legal territory. Spoofing location data for example is a serious cheating issue for a number of games, and allows for trivial fabrication of really basic alibi
I think every permission given to the app should have 2 states: allow and fake. Fake should return randomized data (such as randomized photo from predefined set with added noise, fake filesystem contents, offline mode, etc.), so application should have completely no control of these features and it should never be able to detect the permission level which has been set by the user.
Except that some permissions really are needed for applications to work, and randomizing things is not easy (it will drain your battery faster).
That said, complete randomization is trivial for exactly two things, namely:
* Microphone: You can literally just return a very long pre-generated loop of white noise with a very low amplitude (to simulate ambient background noise) and it should be essentially indistinguishable from the real thing.
* Camera: Seriously, don’t mess around with random stuff, just return a black image. It’s indistinguishable from the user having physically covered the camera.
For certain things, there’s a sane option that doesn’t involve ‘random’ data. In particular, you can just return empty data sets for the calendar, SMS, and contacts (the app wouldn’t be able to realistically distinguish between them really being empty, or the permission being blocked).
In theory, storage access could be handled similarly to the calendar and contacts, except that that would break almost every app that actually uses it. Proper virtualization of storage would be a better approach (that is, each app gets its own directory, and can’t access things outside that), but that would need to be optional, as some other apps would be unusable with virtualized storage.
Sensor data is harder, as there are constraints on what constitutes ‘sane’ sensor data. Of what my Nexus 6P has:
* The audimeter is trivial, as it’s just reading data from the mic, and would be handled by that.
* The photometer is pretty easy too, just keep it around a roughly 100 Lux plus or minus about 20.
* The barometer is also pretty trivial, just keep it around standard atmospheric pressure, with very slow random drift by no more than 5%.
* Battery level should just be reported, period. There’s no reason any application that wants info on battery charge shouldn’t be able to get it, especially considering that it can’t be used to ID the device or user in any sane way.
* Battery temperature is tricky, as it has to wander in correlation with system load, so the call to check battery temperature could get very computationally expensive if implemented such that it really is random (though again it’s not something that can really be used for collecting personal data).
* Mobile and WiFi signal strength get a bit tricky too, as they have to make at least some sense, though I can’t give a good answer as to what does make sense.
* The accelerometer has to have one direction roughly equal to positive or negative 1G plus a little b it to account for the device weight, and the others have to shift in very small amounts very quickly. Additionally though, the basic values have to be reasonable, no sane app is going to believe the phone is intermittently going through acceleration greater than a few G in every direction, so pretty significant constraints have to be imposed, and you have to correlate all three axes.
* The magnetometer is tricky too, as most phones reliably return noticeably skewed results while charging, and anything that can get a compass reading through any other means can easily check the magnetometer against that.
* The gyroscope is reasonably easy most of the time. If your holding the device ‘still’, it will still report changes pseudo-random rotational acceleration of up to approximately plus or minus 0.1 radians per second.
The thing that makes those complicated though is that there are a lot of derived values. My Nexus 6P shows derived virtual sensors reporting gravitational force (derived directly from the accelerometer), device orientation (called ‘rotational vector’ in the API, derived from the accelerometer (to figure out which way is down) and probably also the gyroscope), and a fake proximity sensor based on the light sensor. A lot of phones provide other complex derived values (a compass for example, derived from the magnetometer, or an impact sensor derived from the accelerometer and gyroscope). All of these have to make sense relative to the real sensors.
And, beyond all of that, location data is still an issue. You can’t realistically return random location data, it’s just too trivial to detect that it’s random, and too hard to simulate realistic behavior, not to mention that it would still allow for cheating in AR games that use location data. Thankfully though, this is one that’s make or break for apps that legitimately need it (that is, if it’s off, they don’t work, period), and I’ve never seen anything request it that doesn’t handle it being denied gracefully (because a lot of people do deny it).
ahferroin7,
There’s no reason to go overboard with the quality of “fake” data. The ability to create convincingly real input through fake means seems like a very broad cat and mouse game, but why does that even have to be a goal? It shouldn’t be necessary just to add missing privacy controls to android.
The root of the issue is that the user has no way to deny apps access because android was designed around the (rather bad) assumption that the user approves all data access once a user agrees to install an application. Since android has not given users a way to block access at run time, android applications haven’t needed to handle permission denied exceptions. Unhanded exceptions will cause crashes, which is bad. If the goal is merely to respect the user’s request not to share data and to not crash apps, then supplying trivial fake blank data seems like a valid approach.
You do realize that current versions of Android use a deny by default and prompt on first use model? Newly installed apps on Android 6.0 and newer have no permissions by default, and you have to explicitly grant each one the app tries to use, either through the settings app, or via prompts that ask you if you want to allow or deny the access, so yes, apps should be handling denied permissions gracefully (and they should have already), it’s just that some permissions really are needed for some apps, and others were just designed by people who shouldn’t be writing software. The only apps that can get around this at all are the ones that come preloaded on the phone, as they will usually have permissions pre-set so that they just work. Yes, you can’t easily deny something at runtime after you’ve allowed it, but it’s trivial to just go into the permissions settings to remove the access.
The issue isn’t that Android has no privacy settings (that’s what app permissions are), it’s that there’s no way to easily handle poorly written apps that think they need something that they really don’t. Faking data is a reasonable way to handle that, but just trivially faking it without making it convincing will lead to apps that refuse to run because you aren’t sharing your data with them (because they know you’re faking it).
As far as actually faking data, it really isn’t hard to fake much of it convincingly. The only really difficult ones are location data (and apps that use that either actually require it to function, or use it to enhance services but don’t depend on it, so there’s not really any point to faking it), phone access (which is really baseband processor access, and needs to be properly de-aggregated, I don’t mind sharing my handset ID or even phone number, but I damn well don’t want anything but me able to place calls), and storage (which can’t really be faked without doing some form of filesystem virtualization).
ahferroin7,
IMHO I don’t think stock android should really attempt to generate convincing fake data. The goal of convincing fake data fundamentally creates a cat and mouse game where generation techniques and detection techniques are fighting one another. A lot of developer time as well as CPU cycles will be wasted on both sides. Detection becomes more difficult over time, making it less reliable. Eventually you’d end up with false positives/negatives where software is telling you that your real data isn’t real enough to pass even though it’s not fake.
Maybe there could be a third party solution for fake data generation, but it doesn’t seem to me like it belongs in stock android. Android should have hooks for other data providers though, which could have other innovative uses.
Edited 2018-05-08 13:18 UTC
Unfortunately, it’s ‘Allow’, ‘Deny once’, and ‘Deny always’. I’d actually argue that it should have options for always allow or always deny, as well as one-shots, but that’s me.
[q]IMHO I don’t think stock android should really attempt to generate convincing fake data. The goal of convincing fake data fundamentally creates a cat and mouse scenario where generation techniques and detection techniques are fighting one another. As it becomes more difficult, you’d end up with false positives/negatives where software is telling you that your real data doesn’t appear to be real enough though it’s not fake.[\q]
That’s why it’s so hard for the location data and storage data though. It’s trivial in comparison to feed good fake data to stuff listening on the mic or watching the cameras, so IMO there’s not any reason to not do that. Similarly, it’s pretty trivial to just show an empty calendar or contacts list, and while those are unlikely, they are valid states that real people do have, so any app that uses those has to accept them.
ahferroin7,
Just for the sake of argument…
Error #87: Contacts list does not contain any contacts. Please make sure your phone’s contacts are not blocked before continuing.
The simple answer here is the same thing deniable encryption does.
Allow the users to populate a decoy with whatever they want and, suddenly, the false positive rate of any fake-detection code is too high to be viable.
ssokolow,
Sure, but at that point why not just implement it as a multi-user feature and call it a day? There are plenty of reasons to have more than one contact list, more than one calendar, etc. If you have a way to hide/reveal lists to specific apps, then wouldn’t that be sufficient?
There would be nothing “fake” about such a list with respect to android. It would be a “real” list as far as android & apps are concerned, which just happens to contain fake data.
When you start to think about the workflows, your suggestion quickly becomes a case of “easier said than done” if you want it to be something that average user can use.
Xprivacy does this if you really want it. For example when you run Facebook Messenger it can be fed faked values like XX for country code, PRIVATE for wifi ssid, etc. Very hack’ish though but it works great.
No apps check for faked values though so it isn’t really a problem that randomizing is hard. I feed fake values to lots of apps with no problems (Xposed + XprivacyLua). You can generate a new random value a boot or at every request.
Nothing checks now. If this were to become a core part of Android though, it’s very likely that quite a few less honest apps would adapt to try and circumvent it by refusing to run if they think the data is fake.
jmogannz,
Blocking apps from accessing data is a perfectly reasonable and logical thing for users to do. However the reason you can’t is because there’s a conflict of interest arising from the needs of google and users diverging when it comes to our data.
With hacked versions of android you can do this, and at one point several years ago google engineers unofficially released a version of android that did it too, but google didn’t want users to be able to turn off or “fake” the data because google use the same APIs themselves. For better or worse, google doesn’t let users have better privacy controls because it hurts google’s interests.