More Than 1,000 Android Apps Harvest Data Even After You Deny Permissions (cnet.com) 85
An anonymous reader shares a report: Permissions on Android apps are intended to be gatekeepers for how much data your device gives up. If you don't want a flashlight app to be able to read through your call logs, you should be able to deny that access. But even when you say no, many apps find a way around: Researchers discovered more than 1,000 apps that skirted restrictions, allowing them to gather precise geolocation data and phone identifiers behind your back. The discovery highlights how difficult it is to stay private online, particularly if you're attached to your phones and mobile apps. Tech companies have mountains of personal data on millions of people, including where they've been, who they're friends with and what they're interested in.
Lawmakers are attempting to reel that in with privacy regulation, and app permissions are supposed to control what data you give up. Apple and Google have released new features to improve people's privacy, but apps continue to find hidden ways to get around these protections. Researchers from the International Computer Science Institute found up to 1,325 Android apps that were gathering data from devices even after people explicitly denied them permission. Serge Egelman, director of usable security and privacy research at the ICSI, presented the study in late June at the Federal Trade Commission's PrivacyCon.
Lawmakers are attempting to reel that in with privacy regulation, and app permissions are supposed to control what data you give up. Apple and Google have released new features to improve people's privacy, but apps continue to find hidden ways to get around these protections. Researchers from the International Computer Science Institute found up to 1,325 Android apps that were gathering data from devices even after people explicitly denied them permission. Serge Egelman, director of usable security and privacy research at the ICSI, presented the study in late June at the Federal Trade Commission's PrivacyCon.
Caution: Hot Mic! (Score:1)
It's always on, and so is the camera. Well maybe not the camera. That heats up the phone a bit.
Re: (Score:2)
(Instagram, 2 minutes later)
CrazeeKoolCameras
Sponsored
Looking for an amazing camera? Crazy deals on the camera that rocked Shark Tank and is disrupting a 5 jillion dollar industry!
Re: (Score:3)
From the OP
Permissions on Android apps are intended to be gatekeepers for how much data your device gives up.
No, most permissions on Android were not written with that purpose in mind.
Re: (Score:2)
Exactly what I was going to post.
Google has a vested interest in harvesting data yet they are the creators of the dominant OS.
This is the fox counting the chickens.
When the fox counts the chickens it's too late, as that means the fox is already in the hen house.
The info harvesting holes will never be plugged.
I think my next phone will run Linux, but I expect Verizon will figure out a way to make that as painful as possible.
They have already turned up the pain on my unlocked phone I expect more as technology
Re: (Score:2)
Google has a vested interest in harvesting data yet they are the creators of the dominant OS.
Very true, but tangential to the issue at hand, which is harvesting of data by apps, not the OS. Yes, Google could stop this by tightening and enforcing privacy settings, but it doesn't appear that Google is the entity directly benefitting by apps' harvesting of data.
Re: (Score:2)
Google benefits from apps that harvest data because it's passing through their platform, meaning they can harvest it too, and because it gets these shady app developers to come to their platform in the hope of raiding a free and mostly unregulated trove of users' data
Re: (Score:2)
Lawsuit (Score:4, Interesting)
Re: (Score:3, Insightful)
You forfeit all your rights when running proprietary software. You don't control the software, the software controls you. You should know that by now.
Re: (Score:2)
Re: (Score:2)
You forfeit all your rights when running proprietary software. You don't control the software, the software controls you. You should know that by now.
The last time I checked Android is not proprietary software.
It's open source product of an advertising company which exists entirely to maximize profit by collecting your personal information while shoving advertisements in your face.
If you have the means I suggest judging software on individual merit rather than dogmatic ideology.
Re: (Score:2)
I think you're overdue for a check then. Android nowadays is as much free software as MacOS is. Oh, you'll stumble upon a random free bit here and there, but that's it.
https://source.android.com/ [android.com]
Re: (Score:2)
AOSP can't be used from pure source code only and requires additional hardware-related proprietary libraries to run, such as for hardware graphics acceleration. See the sections below for download links and Device binaries for additional resources.
My advice for you is to pick a standard and stick to it. If absolutism is your game just remember neither can Linux execute on any hardware that people actually own because the underlying hardware is harboring proprietary non-free firmware blobs and the hardware itself is undocumented and not open source.
One can't exactly load Linux on any x86 system that anyone actually owns when the processors in the storage controller are executing proprietary non-free non-open code firmware or the CPUs are executing un
Re: (Score:2)
This is only a fraction of Android, it's like if you redirected me to http://opensource.apple.com/ [apple.com] --- that does not make Finder free software. Most useful libraries in Android are _not_ in AOSP. That was already the case 5 years ago as outlined in this Ars Technica article.
Android is an OPERATING SYSTEM not a Linux distro. That Google has their own proprietary apps some people like better than what is included with AOSP or available as open source elsewhere (https://github.com/LineageOS) isn't a credible argument.
It's like saying Super Tux Kart sucks ass so Linux isn't free because I have to run a Nintendo emulator to play non-free proprietary title Mario kart.
Re: (Score:2)
How is that different from Open Source software that you didn't make yourself?
Re: (Score:2)
Is there any basis I wonder to initiate a class act lawsuit against Google and Apple for misleading customers
Google: Yes.
Apple: No.
Apple isn't responsible for defects in Android.
Re: (Score:2)
Googles reply will be that they are not responsible for bad actors that the user installs.
Re: (Score:2)
If I say I don't want an app to have access to specific aspects of my system, that should be definitive, not just loosely implemented .
It's not your system. It's Google's. They just let you use it. Read the fine print.
Absolutely untrue. See this paper [arxiv.org] for an accurate view of how Google sees the relationship between device, user and platform, with respect to security and, implicitly, ownership.
Re: (Score:2)
Re: (Score:2)
Absolutely untrue. See this paper for an accurate view of how Google sees the relationship between device, user and platform, with respect to security and, implicitly, ownership.
The paper is written by Google for Google and is full of frankly unbelievable claims:
"2.2 Android security principals "Consent is informed and meaningful"."
Reality is take it or leave it demands is coercion not consent. Where do I give consent for software to access the network? Oh right I can't. Where do I go to understand or control what an app is doing or can do with vague blanket grants of permissions? Oh right I can't. For all I know that flashlight app is recording me 24x7 and uploading it to som
Re: (Score:2)
Is there any basis I wonder to initiate a class act lawsuit against Google and Apple for misleading customers on what control (if any) they have over their devices? If I say I don't want an app to have access to specific aspects of my system, that should be definitive, not just loosely implemented .
It is definitive, except that app developers have come up with ways to gather information that Google didn't consider. You can say that Google should have considered them... but this is the nature of security, it's a constant arms race, and there will always be clever people who come up with techniques that hadn't been previously considered.
In this case, it appears that apps that have permission to access your photos are examining the EXIF information in the photos to find out where they were taken. So
Re: (Score:2)
It is definitive, except that app developers have come up with ways to gather information that Google didn't consider.
Like what?
You can say that Google should have considered them... but this is the nature of security, it's a constant arms race, and there will always be clever people who come up with techniques that hadn't been previously considered.
I suspect most people are clever enough to see why reactive security is not a winning strategy.
In this case, it appears that apps that have permission to access your photos are examining the EXIF information in the photos to find out where they were taken. So whenever you take a photo, these apps get a fix on your location.
Very seldom do people actually want to give apps access to their photos. What is actually happening is apps are DEMANDING generic access to storage. A take it or leave it demand without any possibility of user applying constraints limiting what folder(s) can be accessed or given any ability to review and authorize access requests.
Other apps that have network permission examine the IP external IP address (easy to do: just ping a remote server and see what the source IP is) and use that to geolocate you.
Geo IP is worthless you get city or part of town if lucky that's it.
What
Re: (Score:1)
Re: (Score:2)
If I say I don't want an app to have access to specific aspects of my system, that should be definitive, not just loosely implemented .
Is there any fraud here?
Re: (Score:2)
I din't know why you're including Apple here. They've been pretty up front about how they handle your data and how the permissions work. As far as I know, they haven't had a lot of troubles with this stuff when it comes to anything controlled with an explicit permission. The problems mainly stem from apps with cross platform frameworks designed to leak your data that are supposed to make app development easier for lazy or uncaring devs.
Re: (Score:2)
How is Blokada going to enforce permissions settings?
Re: (Score:2)
Android is not an ecosystem, it is a cesspool and the creator of the pond is the worst player.
Re: (Score:2)
I only hope Linux is the answer
Re: (Score:2)
Isn't Android part Linux?
Re:Time to start over (Isn't Android part Linux?) (Score:2)
>> Isn't Android part Linux?
NO!
Android is just an "app"
that runs on Linux.
... and this is a surprise? (Score:1)
Re: (Score:2)
I've had enough conversations with mobile devs to know this is the case. Devs who started in mobile app development are a completely different breed from your old grognards who wrote system software. Many of these assholes are adamant that they are entitled to their user's data because its their app and anything that happens while their code is running belongs to them. I have no idea how this mentality started.
Re: (Score:2)
Flash your phone and use FDroid (Score:4, Informative)
Although it is quite a technical hurdle to overcome the challenges presented in this article, it is not impossible.
People need to become smarter with the products and services they use. That being said, if you use a cellphone, you should know how to make that device private using open source software.
Purchase a phone that has an unlocked bootloader (highly suggest OnePlus), and then flash all of that spy/bloat ware off and use a fully open source custom ROM.
Install FDroid (The Free/Libre Open Source Software app store) and use the apps available there. If you still need access to Google Play apps that provide push notifications, checkout the microG project which can fulfil these functions for you without the bullshittery that Google comes with.
And for the love of God, stop installing closedsource malware apps on your devices unless you can quarantine them at all times using AFWall+ (rooted phone) or NetGuard (non-rooted phone).
If you do not understand how these things work, then maybe you should do some DuckDuckGo searching and figure it out because your naivety is all being exploited, or stop using smart phones.
It's called Theft (Score:2)
Burn it with fire.
Summary of the techniques (Score:5, Informative)
The techniques used to circumvent permissions seem to fall into 2 categories.
Side channels:
App 1 has permission, app 2 doesn't. There is a communication channel between app 1 and app 2 (ex: a file on the SD card). App 2 ask for data through app 1.
Exploitation of the network stack:
Using standard networking system calls, it is possible to get things like the MAC addresses, which allow for unique identification or and some level of localization.
Re: (Score:3)
Exploitation of the network stack:
Using standard networking system calls, it is possible to get things like the MAC addresses, which allow for unique identification or and some level of localization.
I think it's stronger than that. Using standard networking system calls you can send a message to a remote server, which can then discover the IP address of your device (or, more likely, the IP address of the NATing router it's talking to). If you're on Wifi, that IP address almost certainly corresponds to a fixed geographical location, which can be geolocated.
No platform ability to read details of the hardware or network stack configuration is needed. The simple ability to connect to a remote server i
Re: (Score:2)
I think it's stronger than that. Using standard networking system calls you can send a message to a remote server, which can then discover the IP address of your device (or, more likely, the IP address of the NATing router it's talking to). If you're on Wifi, that IP address almost certainly corresponds to a fixed geographical location, which can be geolocated.
No platform ability to read details of the hardware or network stack configuration is needed. The simple ability to connect to a remote server is all that is required to geolocate you. This means that any app with the network access permission implicitly has location permission.
Absolutely not. These things are nowhere close to being the same.
MAC addresses have been globally systematically mined and associated with precise locations of nearly every AP in existence actively belching beacons to determine precise location of every bloody last AP.
Obtaining precise location from public facing Internet addresses is much more difficult than getting a list of MACs for a variety of reasons. Public addresses are not exposed to the public and cannot be systematically mined in this way. The
Re: (Score:2)
You didn't read my post. I'm fully aware of the distinction between IP and MAC addresses (a couple of decades ago I wrote a TCP/IP stack from scratch for an embedded system that for various reasons couldn't use any of the available options). Public IP addresses are also trivially easy to get, and even though DHCP does result in router IPs changing a bit they're (a) remarkably persistent and (b) tend at least to be localized to a relatively small area, e.g. one DSLAM which serves a block.
Geolocation of IP
Re: (Score:2)
You didn't read my post.
I read your post.
I'm fully aware of the distinction between IP and MAC addresses
What you are aware of is irrelevant. Only what you express with actual words matters. I read no capability distinctions proffered by you. If you feel this is untrue or unfair please feel free to quote accordingly. What I did read from you seemed like a very clearly defined attempt to pull a whataboutIP when issue of MACs were brought up.
a couple of decades ago I wrote a TCP/IP stack from scratch for an embedded system that for various reasons couldn't use any of the available options
I assume you and everyone reading this knows the difference between an L2 and L3 address. My intention was not to insult anyone's intelligence.
Public IP addresses are also trivially easy to get,
Yes of c
Re: (Score:2)
Public IP addresses are also trivially easy to get,
Yes of course they are given they are public. Yet the fact remains you can't execute a systematic location data mining operating of public IPs without associating with the access points and sending data. That kind of data mining would probably land the people doing it in jail and unless the AP was open likely wouldn't be practical to implement.
That kind of data mining has been done and is being done by many companies, for both IPs and SSIDs. There are lots of high-quality geolocation services out there that will give you the location associated with any IP address. If you allow a web site to determine your location from a desktop or laptop, the location that it comes up with is based solely on such IP/physical address mapping databases, and it's amazingly accurate. For example, on your desktop or laptop, go to Google Maps and hit the little "l
Re: (Score:2)
That kind of data mining has been done and is being done by many companies, for both IPs and SSIDs. There are lots of high-quality geolocation services out there that will give you the location associated with any IP address. If you allow a web site to determine your location from a desktop or laptop, the location that it comes up with is based solely on such IP/physical address mapping databases, and it's amazingly accurate. For example, on your desktop or laptop, go to Google Maps and hit the little "location" button in the lower right corner, and Maps will show you its estimate of your location based on your IP. It's often very close.
I just tried it and coordinates displayed in the map are just over three miles away as crow flies. Do the same thing on an ancient apple iPod without a GPS or cellular radio and it shows my precise location to within 20 feet using AP MAC data.
There is no credible comparison to be had between the two.
Re: (Score:2)
Side channels:
App 1 has permission, app 2 doesn't. There is a communication channel between app 1 and app 2 (ex: a file on the SD card). App 2 ask for data through app 1.
And don't expect the side channels to go away. Because Google, the purveyor of Android, uses them itself:
- App 1 = Google Play services
- App 2 = Maps (and probably others as well).
Try this:
- In Settings -> General -> PHONE MANAGEMENT -> Apps
- Disable Google Play Services (and pretty much anything el
Re: (Score:2)
But [Maps] apparently reports your location back to Google ...
And perhaps other stuff as well. Who knows?
Re: (Score:2)
Of course it DOES work just fine (at least for the functions I've tried). But it apparently reports your location back to Google by forwarding it through Google Play services, and tries to sucker you into reenabling it if you've turned it off.
Google has become a nag factory.
Whether constant nagging from behind Google's search monopoly to switch to Chrome or constant retaliatory prompting in basic phone and messaging that would work just fine with Google play disabled if not for the never ending constant nagging that requires replacement in order to restore usability / user sanity.
Google has gone from don't be evil to waging nag wars of attrition against users.
Trickier (Score:5, Insightful)
Its a little trickier than it appears - although a lot of the problems do indeed seem to be bugs in the OS or the permissions handling. Here's just one scenario that might surprise a user when we try to make them responsible for complex permissions interactions.
Let's say that you allow the camera to use location information, which is a normal and reasonable thing to do.
Now let's say that you disallow an app to use location information, also reasonable.
Finally, let's say that you allow the app permission to access the camera, because it wants to upload a photo of something - quite a lot of apps do this, after all.
All seems reasonable to the user, and they've done the Right Thing. But now let's say that the app periodically chooses to take a photo, read the embedded coordinates, and delete the photo if it was added to your library. Now it knows where you are, even though you've done your best as an informed consumer to prevent that from happening.
Without the kind of annoying app review that Apple brings to the table, its very hard to prevent things like this - even with human review it's not easy. Getting the permission chains reasonable but still allowing people to swap in/out their own helper apps of choice (maps, keyboards, etc) makes this even harder.
Re: (Score:2)
Its a little trickier than it appears - although a lot of the problems do indeed seem to be bugs in the OS or the permissions handling. Here's just one scenario that might surprise a user when we try to make them responsible for complex permissions interactions.
Android problems are structural, very much intentional and only getting worse. Take it or leave it access demands and the continued aggregation and watering down of access rights are largely responsible. Specific example of things getting much worse: Network access is no longer even displayed as an enumerated privilege.
Let's say that you allow the camera to use location information, which is a normal and reasonable thing to do.
I have two issues with this:
First I do not believe it is reasonable and normal for camera to use location.
Second and most importantly the camera is hardware and permissions are applied to in
So Google? (Score:2)
Just use AOSP + MicroG + F-Droid (Score:2)
The only way to achieve a reasonable degree of privacy on Android is:
1. Unlock your phone bootloader.
2. Install a Google apps free AOSP ROM.
3. Install microG (an open source reimplementation of some Google services).
4. Install F-Droid and get FLOSS-only apps from there.
If in step two you install "Lineage OS for microG" distro, you already have steps 3 and 4.
Following this route is not easy, and you will miss non-free apps, but if you value privacy, it is the way to go (and not the stupid suggestion of buyin
Source Code was available to how many of these 1k? (Score:2)