• We designed a pipeline for automatically discovering vulnerabilities in the Android permissions system through
a combination of dynamic and static analysis, in effect
creating a scalable honeypot environment.
• We tested our pipeline on more than 88,000 apps and
discovered a number of vulnerabilities, which we responsibly disclosed. These apps were downloaded from the
U.S. Google Play Store and include popular apps from
all categories. We further describe the vulnerabilities in
detail, and measure the degree to which they are in active use, and thus pose a threat to users. We discovered
covert and side channels used in the wild that compromise both users’ location data and persistent identifers.
• We discovered companies getting the MAC addresses of
the connected WiFi base stations from the ARP cache.
This can be used as a surrogate for location data. We
found 5 apps exploiting this vulnerability and 5 with the
pertinent code to do so.
• We discovered Unity obtaining the device MAC address
using ioctl system calls. The MAC address can be
used to uniquely identify the device. We found 42 apps
exploiting this vulnerability and 12,408 apps with the
pertinent code to do so.
• We also discovered that third-party libraries provided
by two Chinese companies—Baidu and Salmonads—
independently make use of the SD card as a covert channel, so that when an app can read the phone’s IMEI, it
stores it for other apps that cannot. We found 159 apps
with the potential to exploit this covert channel and empirically found 13 apps doing so.
• We found one app that used picture metadata as a side
channel to access precise location information despite
not holding location permissions.
It's hypocricy if they let these malicious devs keep publishing but keep harassing non-malicious developers with things like "How dare you have a Donate button in your app".
It seems like at least some of these apps might be using these vulnerabilities without even being aware of it, as the offending code is in third party libraries. Game devs grabbing mac addresses via Unity's API, for example, may not know that that information is supposed to be restricted on Android.
> some of these apps might be using these vulnerabilities without even being aware of it, as the offending code is in third party libraries
I'll assume by vulnerabilities you meant to say exploits. Given that: True but so what. This is criminal behavior. Using criminal libraries makes you complicit and a co-conspirator.
They aren't reliably determining violations of current absurd rules and people's apps get hit all the time for no good reason, so basically they could just continue doing what they've done so far.
If these apps get banned because they use poor dependencies, maybe better dependencies will become popular, and developers will also have a reason to be more aware of what code they are using.
Sure. And if an app intentionally exploits that vulnerability to bypass the permission system, its developer should no longer be able to publish in the Play Store.
To be fair, denying application knowledge of _device own_ MAC address is beyond absurd. If Google really wants that, they should buy their own MAC block, and regularly rotate the addresses within it when network is off.
A lot of Android own APIs (such as Wi-Fi P2P and Bluetooth) are built on implicit assumption, that application developer knows MAC address of device it is running on. Instead of fixing those APIs, Google now requires everyone using them to request Precise Location permission from user _and_ enable a Location Toggle in device settings. This is pure harassment.
An app developer being able to uniquely identify a device across applications has been considered a privacy violation for well over a decade. Even Microsoft in the Windows CE days made it hard for an app to uniquely identify a device.
The idea itself isn't bad, but Google's implementation of it is terrible. Good actors are forced to show security prompts, that literally scream "this application is malware!!". Bad actors enjoy ability to share MAC/IMEI/whatever with each other and skip whole "prompt for irrelevant permission" nonsense. They don't even particularly care about reading hardware addresses — why bother, when you can embed something like fingerprint.js and automatically identify every single device in existence!
If Google does not improve their P2P networking APIs, everyone may end up eventually integrating some Chinese spyware library, because it is the only approach that does not suck (and there is apparently no penalty for doing so).
Usually apps that exploit flaws in Android are even labeled malicious and actively removed from all devices, this might be even better than just perma-banning the developers.
> If the app can get around the permission system - it’s a vulnerability in Android
That's the same argument as saying that if someone can use a baseball bat to smash in the window to my car, it's a vulnerability in the auto manufacturers glass manufacturing and should be their fault and not that of the car thief. It's an absurd and ridiculously nonsensical argument in defense of criminals.
There's also the concept of white, grey and black hats. Just because someone finds a vulnerability doesn't make it okay to abuse it. The right thing to do is to disclose it, and businesses like Google do benefit from incentivizing it.
Alibaba does no effort to conceal that they target ads by IMEI.
Browse Alibaba app*, search something. Do factory reset, make new account, and the first thing you will see after logging in with new acc will be your products from your last search.
Moreover, Alibaba's app will refuse to work if you block IMEI retrieval, or if they detect some kind of spoofing
edit, made it clear that it is the app, not website that links you by imei to your previous accs and history
You know, maybe they should. Same for LinkedIn (assuming they're still doing dirty tricks). Maybe it's time for major app devs that exploit security holes in released applications to get the ban hammer, and show smaller devs it won't be acceptable and have less excuse if/when it happens to them.
How does that work? None of the methods described in this paper seem like they'd work with _websites_. They all seem to rely on permissions only available to native apps.
Belated edit: Anything that does something that you don't want, while pretending to be something that you do want, is malware. Especially if it goes out of the way to do that, evading limits, and hides what it's doing.
Even Unity? Their CEO says half of all games are built on that. I imagine users would riot if most games were to simply disappear tomorrow.
Or more likely, since it’s Android, the first thing everybody would do is switch to the App store that has all the software they want, even though they know it’s bad.
Yes, even Unity. Unity goes out of its way to get information that it does not have permission to acquire or transmit. It looks like knowledge of this is limited to a few developers who are "in the know" and I would not be surprised if Unity has given that info out to large licensees who have mentioned a need to uniquely identify players without permission.
There's something a lot of people don't know about Unity the company - they are awful. Difficult to work with, constant rumors about managerial scapegoating, questionable sales tactics.. the recent news about the allegations against the CEO didn't surprise me in the slightest.
I don't work with them closely, but I work with them closely enough that I've recommended that my employer cease all interaction with them, including further license purchases. That's how bad the taste in my mouth is after I deal with them interactively in any capacity.
The entire Android ecosystem is about abuse. Banning these apps won't help. Google legitimized surveillance capitalism that is the worst that could have happened.
The picture metadata exploit is interesting. It would be trivial to guess the user's home and work location given enough photos with EXIF data (locations and timestamps).
I'm curious how this works on iOS. Granting complete access to "Photos" always seemed overly broad. It should be possible to limit an app to only save images, and/or limit accessing images to photos from the last 3 days etc, or only the images the app has created.
Allowing an app to grab literally years of time and location information (via photo EXIF data) just to do something as simple as saving a filtered picture or opening a screenshot seems bad.
But as someone who loves metadata, I'd can't see myself disabling it altogether. Does anyone know how this works today on iOS? Can an app wholesale upload thousands of pics (or just the metadata) in the background without the user knowing?
> It should be possible to limit an app to only save images, and/or limit accessing images to photos from the last 3 days etc, or only the images the app has created.
It is, but currently this is something that apps need to use the API for rather than it being something that users can restrict.
On iOS, photo write and read access are granted separately, so you can allow an app to only save photos.
Apps can also import photos without any permissions at all by invoking the system photo picker (where the user manually has to pick the photos one by one).
Is it the case that when the app uses the system photo picker, that the app is only ever presented with the photos the user selects? In other words, the app doesn't have direct read access to the main photo library.
This is true on both android and iOS, but on android the 'system' photo picker is an intent which fires up the gallery/google photos and typically has a pretty bad user experience, so not many app developers use it.
> We also discovered that third-party libraries provided by two Chinese companies—Baidu and Salmonads— independently make use of the SD card as a covert channel, so that when an app can read the phone’s IMEI, it stores it for other apps that cannot.
From the paper, it looks like it stores those in `/sdcard/.googlex9/.xamdecoq0962` and `/sdcard/backups/.SystemConfig/.cuid2`. I wonder what would happen if I simlinked those files to `/dev/null`...
Wow. I'll use this paper as a good reason to encourage usage of a firewall (afwall or netguard) for my non nerdy friends. It can stop a lot of this nonsense being reported back, but sadly not all.
I'm thinking there's probably a reporting vector in how an app might use the download manager to leak data.
By what set of mechanisms is it possible for the app to access data that you've denied the app access to? It seems the flaw is in Android allowing this to happen.
The example given (app accessing photo with embedded gps coords) seems very specific and doesn't deal with the general notion of data harvesting.
And wrt mac address lookups - for this reason it's not possible to list the available wifi access points on android without requiring the location permission. It's pretty absurd that "list the access points that I have recently received wifi beacons for" is equal to "locate where I am on earth", but that's the world we live in now.
Whether it's just location data or a larger set of data is unclear from the article.
> The 1,325 apps that violated permissions on Android used workarounds hidden in its code that would take personal data from sources like Wi-Fi connections and metadata stored in photos.
> Researchers found that Shutterfly, a photo-editing app, had been gathering GPS coordinates from photos and sending that data to its own servers, even when users declined to give the app permission to access location data.
> Some apps were relying on other apps that were granted permission to look at personal data, piggybacking off their access to gather phone identifiers like your IMEI number. These apps would read through unprotected files on a device's SD card and harvest data they didn't have permission to access. So if you let other apps access personal data, and they stored it in a folder on the SD card, these spying apps would be able to take that information.
So basically, they can't read your location, but they can read other things that contain your (previous) location and other information about you.
Edit: The article links to the original research[0], which seems to describe/link to different methods that the apps use. I haven't had time to read it yet, but it seems interesting.
> Researchers found that Shutterfly, a photo-editing app, had been gathering GPS coordinates from photos and sending that data to its own servers, even when users declined to give the app permission to access location data.
One of the first things I disable when I have a new phone is geolocation being added to photos. I just don't want my location randomly being shared from an image without my consent. If I wanted you to know where I took the picture, I would tell you.
> If I wanted you to know where I took the picture, I would tell you.
That's really missing the major use case, though, isn't it? I like having it enabled so my phone will tell me where I took the picture, because there's little chance I'll be able to a year later.
It'd be nice if the "access photos" API on the device would have a separate permission for EXIF data. Without it, the app would receive only the image itself, not the attached metadata - kinda like how Facebook strips off any EXIF data when you publish a photo there.
This is actually the change coming to Android Q - OS will strip out location data from photos when apps access them. EXIF will require extra permissions.
That's awesome. I have EXIF-stripping apps which I use to remove location data before uploading them in other apps, but for all I know the EXIF-stripping apps are harvesting the location data themselves...
That still leaves google collecting your location info from the EXIF data just as I assume facebook collects your as it is stripped out. Google doesn't need to know the exact date, time, and location every photo I take was taken either.
google should be part of everyone's threat model, but while we're forced to live with google and forced to hand over some data, it's best to limit what we send them voluntarily whenever we have any option.
I think that's what Google Photos do when you share (at least by link). Would be nice if photos accessed on Android had their location stripped, if the app doesn't have location access.
It should be disabled by default, data that doesn't exist is data that can't stolen. Most people are also surprised that an image contains GPS co-ordinates and do not consider that something as simple as sharing a photo on the internet is giving away there home address.
> So basically, they can't read your location, but they can read other things that contain your (previous) location
Yes, and I think we could make a good case that the Android platform did a poor job of clarifying this to the user. I would guess that the typical android user thinks "location permission" means location data of any type as generated by any subsystem on the device.
To whom would a reasonable user assign responsibility for this protection failure -- app developers or the Android platform?
I mean, as much as I'd like to give Android crud here, I think this is incredibly unethical developer behavior, and it's kind of incredible to see we still have so many people in the industry who think scraping location data out of people's stored photos for advertising data is okay. It's well outside the realm of something I'd think someone would even try to do, especially from a pretty legitimate company like Shutterfly.
> I mean, as much as I'd like to give Android crud here, I think this is incredibly unethical developer behavior ….
Right, but "our system will protect you from ethical developers!" isn't much of a security model, so I think there's still plenty of blame for Android here.
What exactly is the blame of Android? That it allows the app to read photos when user allows it to read photo files?
Because this criminal behaviour is also present in Linux, Windows and macOS.
Or the fact that an app can write a file to disk? And then another app can open the file? Also criminal behaviour present in other operating systems. Some users might even call it a feature and do the unthinkable - share files between applications! Horrible!
Seriously, you're blaming the OS because it allows you to run useful software on it, just like a desktop computer. If you want a jailed down device, it's fine: buy Apple. But that doesn't mean every pocket computer needs to be a crippled device.
> Seriously, you're blaming the OS because it allows you to run useful software on it, just like a desktop computer.
Unlike a desktop computer Android prevents you from taking steps to protect yourself. Without rooting your phone you can't even install firewalls or prevent applications from ever connecting to the outside world. Google designed their OS to collect and leak your data. It's why their permissions system (even when working as designed) is garbage. Google doesn't want you to have the ability to protect yourself. It assumes responsibility and lets you (sometimes) disable some permissions from some apps (but not others) at their discretion. No one does that on my desktop computers. Most people's phones are filled with apps they don't want but aren't even allowed to uninstall.
It looks like netguard is a VPN service, not a true firewall. A firewall on my desktop doesn't require me to route all my traffic through a VPN. Netguard also injects ads in your traffic (or at least did) https://imgur.com/a/2YG7Q
Netguard is open source (with a license not supported on iOS: https://github.com/M66B/NetGuard), so there is no reason to use a build that shows ads. Alternatively, as I said earlier, there are multiple firewall apps you could use that don't require root.
The weird thing is that you went out of your way to research to find a misleading quote when the page itself points out why the quote is misleading and that the app is open source (negating your ads claim earlier).
It has to route traffic through a local VPN to drop the traffic. Doesn't play well with other VPNs for this reason. Real firewalls need root. The VPN trick is a hack to get around that while still providing some of that functionality. Yes, you could edit the source code and compile it yourself every time it updates to remove the ads, but I think that's a little much to expect.
Ultimately this is functionality users should have access to by default without needing to resort to hacks and ad-filled workarounds.
Android: without rooting your phone, I keep writing this on HN :) it is called "NoRoot Firewall". Free app, it creates a VPN within your phone and asks you for every ip:port to allow/block and one can also use rules such as Block 111.111.., port: 123. Worth checking out. I have e.g. a chess app, I keep it block all IPs/Ports. I never have to worry for tracking, spying, ads, etc.
I would not consider my iPhone to be a crippled device.
Just because these issues exist on a traditional computing device, does not mean we should continue that trend when a new type of platform exists (mobile).
Plus, many of us likely have much more personal data on our phones that we ever had on our computers, especially location data for where you are all the time.
This is absolutely a failure of the OS, but if you choose to accept that fine. But the issue is for those that are not in the tech community and don't realize there data is being mined when they specially chose the option to deny it.
I expect my devices to uphold the security model they advertise.
My desktop OS (macOS, for what it matters) doesn't ask me to approve permissions for apps, so I assume that anything I install has whatever privileges I have (or root privileges, given the broken must-install-as-root behaviour of many of them).
On the other hand, for example, Firefox asks my permission before allowing sites to use the microphone or camera, and I expect it to enforce that. If sites can get access to my microphone or camera without my giving them permission, then Firefox has failed, even if those sites have got that access through unexpected means.
I agree it's very hard to have a secure but useable general-purpose system—but pretending that you're offering such a system while not actually having the appropriate mechanisms to enforce it is, arguably, an even worse solution than offering an utterly locked-down system.
Just as an added point for my claim that this position is not hypocritical, I consider https://news.ycombinator.com/item?id=20387298 to be a flaw in the macOS security model, for which the OS deserves blame, and not just an instance of poor app design (although it is clearly that).
Here's a simple experiment. On a Linux box, open your GUI text editor. Try to open /var/log/syslog. You will see "Permission denied". That's because only apps with root can access /var/*.
> I assume that anything I install has whatever privileges I have (or root privileges, given the broken must-install-as-root behaviour of many of them).
My point is that Linux apps don't have general root rights. Even though you must install them as root. That is, unless you start them as root. So an app can't just decide to access and change some other app's settings.
> My point is that Linux apps don't have general root rights. Even though you must install them as root. That is, unless you start them as root.
I'm running macOS, so this isn't directly relevant; I don't know much about Linux apps, but macOS ones often do some skulduggery—for example, Dropbox uses its root installation privileges to make some very hard-to-eradicate startup items (https://applehelpwriter.com/2016/08/29/discovering-how-dropb...). Nonetheless, you are right that I was confusing "installed as root" with "has root privileges".
> So an app can't just decide to access and change some other app's settings.
Not with iOS. There is a separate media library API that’s separate from the file access API. You can give an app permission to access your media library without giving it access to the location metadata. The app has to specifically ask for location access to get the metadata.
> You can give an app permission to access your media library without giving it access to the location metadata. The app has to specifically ask for location access to get the metadata
I believe this used to be true, but it's not anymore. I just tested it and even without location permissions, the location EXIF is included
No, iOS prevents the application from directly accessing files without the user’s permission. The user can choose to allow access granularly to a file via the file picker within the app.
There are also separate permissions to allow apps to read and write from the media library.
Example: if you have an SD card installed, one advertising SDK creates a file on it. When the SDK is running in an app with appropriate permissions, it writes the IMEI and advertising ID to that file. When it's running in an app without appropriate permissions, it retrieves the IMEI and advertising ID from that file.
Lots of interesting tricks. The one that surprises me the most is Unity using ioctl tricks to harvest the device's MAC address.
Scoped storage does not prevent applications from sharing PII with each other. There are already advertising networks, using BroadcastReceivers and ContentProviders to share analytics data — it is simple and does not require individual apps to have external storage access.
However, I think you still have to hold developers responsible for clever tricks that violate the intent of the Android permissions system. There are always going to be loopholes. (This likewise means that there has to be room for developers to make honest mistakes.)
Android does not ask for permission to read certain things like the clipboard. So an app can intercept anything added to the clipboard such as passwords copied in by password managers.
Wow. The password manager I've been using for the past few years has dedicated buttons/gestures for copying the password to the clipboard (like many others, I'd assumed.)
I feel like the expectations in this case are clear: a copied password should only accessible when the user "pastes" it. (The app even clears the clipboard after a certain amount of time, making it seem like the only weak point in the system is the paste functionality.)
To find out that this is not the case is pretty mind blowing. Does anybody know of any good reasons why the clipboard shouldn't be secure?
> Does anybody know of any good reasons why the clipboard shouldn't be secure?
Seems like a UI issue to me. Right now apps themselves invoke the paste command (e.g. they can put a "paste" button in their UI). If you remove clipboard access from programs, the UI would have to be presented by the OS.
Requiring paste to be initiated by the OS may work alright for text boxes (but you'd now have to sandbox all the text boxes to avoid the app simulating taps), but it wouldn't work for say, pasting images.
Another option is to add a dialog box every time asking the user "did you REALLY want to paste?", but that will quickly get annoying.
I can imagine something along the lines of checking whether user interaction was the root cause of getting access to the clipboard as a middle ground... e.g. on web, popup blockers work this way. If a user interacts with a button, and that javascript series of functions opens a popup, it is allowed. If a non user interaction function in javascript, say a running ad, tries to open a popup, it is blocked. Could try the same approach, where only if the user initiated the current running series of functions, would it be allowed to access the clipboard. Or even ask for elevated user interaction functions, so that security teams would have an explicit list of elevated functions that are allowed to access sensitive data, allowing for easier manual checks. Anything else would have the annoying confirmation.
If you use Lineage OS (or its predecessor, CyanogenMod, both of which are Android forks) you are, ostensibly, given the ability to permit or deny access to read from and/or write to the clipboard via the included permissions manager, Privacy Guard.
As far as I'm aware iOS doesn't require permission for clipboard access either. Up until Q a background service on Android could constantly monitor the clipboard however.
Not knowing the underlying architecture, but would it be hard to give each app its own virtual clipboard that only the UI has access to (paste)? And does IOS already account for this? Daily it seems as though I'm reconsidering Lineage. While I like the flexibility of Android I feel as though there are still too many obtuse protections missing.
Why not require both clipboard source and target applications to be running at the same time (i.e. clipboard acts as a channel, not a buffer)? This is implemented in GNOME native apps.
> The update will address the issue by hiding location information in photos from apps and requiring any apps that access Wi-Fi to also have permission for location data, according to Google.
The great minds at Google have done it again!!
This craziness (Bluetooth requires location) was the reason I never bought a smartwatch. I guess now I should stop using internet too.
According to Google Bluetooth requires location, because it van be used to find your location. So there is some reasoning behind this decisions, although I wwould be mutch happier with something like: Location (Bluetooth), location (GPS), location (WiFi)
>A location permission is required because Bluetooth scans can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities.
What is the cause and what is the effect here? Is Google's solution making it better or worse from a practical privacy point of view?
(Also, don't buy Google's explanation that this is just to inform users of potential misuse - they actually log your location and even wait for a GPS lock when you pair a new device)
If an app that uses bluetooth can get my location via beacons or etc., then bluetooth should be wrapped in location privileges. An app that I do not want having my location should not be allowed to use bluetooth, and I have to accept that any app that does use bluetooth could get my location.
While it does mean that apps that use bluetooth now have a slightly easier way of getting location (i.e., via phone GPS, not just bluetooth), we shouldn't obfuscate that bluetooth is another way to get that information. In the end, you are trusting the app developer with the privilege of knowing your location. If you don't trust them with that, then they can't be allowed to use bluetooth, full stop.
Because Google is notorious for coming up with bogus explanations whenever they get caught red-handed. Every month there is a bunch of news articles, where high-ranked Google employee claims to spy on everyone to "protect people from electric pigs", "lower the danger of Confucian Jihad", "enrich e-mail UX with hefty data-harvesting" or something along those lines.
> If an app that uses bluetooth can get my location via beacons or etc., then bluetooth should be wrapped in location privileges.
There is no reason why apps have to be able to "get location from beacons" in order to connect with another phone over Bluetooth. Same for P2P Wi-Fi API — pairing with another device already requires exchanging tokens via graphical dialog with explicit user approval on both devices. Removing ability to read scan results from API would be enough to fix the underlying data leak. Once two devices are paired, they should be able to exchange data without need for any permissions or user actions.
Instead Google forces users to keep Location enabled long after initial connection is made. Even if there is no underlying bad intention, they should be ashamed of forcing such garbage UX upon people.
> and requiring any apps that access Wi-Fi to also have permission for location data, according to Google.
Doesn't this just force everyone who uses an app with their wireless connection to give that app access their location data too? That seems like forcing users to leak more of their data rather than protecting it.
Now instead of some apps that I've denied location access getting it anyway by trickery, I now have to allow all apps to record my location data or else they can't access the internet at all!
The fun doesn't stop at your phone, you're usually leaking location data to third party passive scanners too just by turning on bluetooth. It will broadcast a mac address that is usually poorly and/or infrequently randomized, if it's randomized at all. Some phones will somewhat mitigate this, but random bluetooth devices rarely will.
Ramble is a simple bluetooth scanner app on android, check how often your friends and coworkers mac addresses are updating.
> Egelman said the researchers notified Google about these issues last September, as well as the FTC. Google said it would be addressing the issues in Android Q, which is expected to release this year.
A whole year to get a solution out?! Google is clearly demonstrating where it stands when it concerns privacy.
With the usual low penetration of the latest release of Android, this will probably be “solved” for the majority of the devices in four years from now. Sigh!
Edit: Why not crack down on apps through updates to the Play Store policies and rules? Apple seems to use that tactic sometimes.
> Edit: Why not crack down on apps through updates to the Play Store policies and rules? Apple seems to use that tactic sometimes.
Google has been doing that a lot lately and has created the appropriate amount of heavy complaining from the side of developers. Still, auditing source code for every one of those things is pretty much impossible - even iOS apps use a lot of such tricks to fingerprint users and Apple has a hard time keeping on top as well.
I think this behavior is covered by existing criminal law. If not, the law needs to be updated.
Replace “phone“ with “web server”, and you will find legal precedents showing that much of the behavior is criminal.
In particular, it is clearly not legal to walk the file system tree to obtain access to private data you were explicitly denied access to, and then directly profit from the data you illegally harvested.
Failing to strip exif location data, even though gps access was denied? That’s a gray area, at worst.
They can pull the apps, but Android Q will add several additional security features - e.g. scoped storage (no more SD card access without user consent), EXIF location stripping (accessing EXIF from photos will require additional permissions) and plugging of several possible fingerprinting sidechannels.
This really feels like a cat and mouse game, with Google not actually trying to solve the issue. The proposed additional security "features" will give a false sense of security.
Any way for 2 apps to communicate together will be exploited for the same purpose in the future. Google would have to fix the issue in a more fundamental level, which requires better understanding of users habits and wishes in term of privacy.
But obviously, privacy-oriented users are the worst users for an ad network machine...
The Android platform and Play Store place too much trust in the integrity of app developers who are forced to occupy an intentionally low-profitability app ecosystem. Google will never expend the effort to filter out all of the malware. It's too expensive. Google is too inefficient and the dev teams are too loosely managed.
There certainly is a way to make it so an app can ‘add photos only’ on iOS. I have only seen it used a handful of time and some apps like Facebook Messenger where I’ve somehow got that permission setting set in the past actually ignore it and demand full access despite just trying to save a photo.
Phones and web browsers are not secure, not even a little tiny bit.
It is problematic that it is nearly impossible to go unidentified and untracked, constantly. IoT makes this so much worse because now nearly everything around you is constantly harvesting data, I am somewhat personally embarrassed about how little attention I have paid.
Meanwhile Android Q is going to gut a number of power user features, like any ability to wardrive or create a decent signal strength map of your home or workplace.
• We designed a pipeline for automatically discovering vulnerabilities in the Android permissions system through a combination of dynamic and static analysis, in effect creating a scalable honeypot environment.
• We tested our pipeline on more than 88,000 apps and discovered a number of vulnerabilities, which we responsibly disclosed. These apps were downloaded from the U.S. Google Play Store and include popular apps from all categories. We further describe the vulnerabilities in detail, and measure the degree to which they are in active use, and thus pose a threat to users. We discovered covert and side channels used in the wild that compromise both users’ location data and persistent identifers.
• We discovered companies getting the MAC addresses of the connected WiFi base stations from the ARP cache. This can be used as a surrogate for location data. We found 5 apps exploiting this vulnerability and 5 with the pertinent code to do so.
• We discovered Unity obtaining the device MAC address using ioctl system calls. The MAC address can be used to uniquely identify the device. We found 42 apps exploiting this vulnerability and 12,408 apps with the pertinent code to do so.
• We also discovered that third-party libraries provided by two Chinese companies—Baidu and Salmonads— independently make use of the SD card as a covert channel, so that when an app can read the phone’s IMEI, it stores it for other apps that cannot. We found 159 apps with the potential to exploit this covert channel and empirically found 13 apps doing so.
• We found one app that used picture metadata as a side channel to access precise location information despite not holding location permissions.
[0] https://www.ftc.gov/system/files/documents/public_events/141...