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".
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.
Ignorantia legis non excusat
No bond, no audit, no disclosure -> felony.
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.
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).
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.
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
Banning will hinder them, but it is just case by case band-aid solution.
Risk of huge fine that can put you out of business seems more logical.
Per description here, it seems have enough legal, $, evident here to make a few lawyers excited?
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.
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.
We need systematic solu...oh wait GDPR - just hit them with all the fines.
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 is, but currently this is something that apps need to use the API for rather than it being something that users can restrict.
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).
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.
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`...
I'm thinking there's probably a reporting vector in how an app might use the download manager to leak data.
• 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...