More than 1k Android apps harvest data even after you deny permissions | Hacker News Reader

More than 1k Android apps harvest data even after you deny permissions

cnet.com

304 pointsspacemanspiffy140 comments

[0] from the researchers pdf:

• 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...

Ban. These. Apps. And. Devs. Permanently.

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".

Will google dare to ban alibaba?

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

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.

My mistake, I meant Alibaba's apps

Maybe someone in EU can file a class action lawsuit base on GDPR?

Per description here, it seems have enough legal, $, evident here to make a few lawyers excited?

Not really unless they are stealing PII.

IP addresses are considered PII, and IMEIs are in every way worse than IP addresses.

The router’s MAC is not PII for example. This is why I write that GDPR only applies in case they collect actual PII.

Several jurisdictions consider MAC addresses to be personal information as well.

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.

Shadowban them with bogus data to pollute their database.

I am a fan of GDPR to be honest.

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.

If the app can get around the permission system - it’s a vulnerability in Android itself that Google needs to correct.

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.

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).

> 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.

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 might be using them without being aware of but the rest can be nicely permabanned.

How would you go about reliably and efficiently determining which category each falls into?

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 you use a library that engages in criminal activity, you are legitimately a criminal as well and should be held accountable.

> 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.

Vet your dependencies. I have no mercy for people who put crap on my phone.

And that excuses them how?

Ignorantia legis non excusat

Who cares how accidental it was? If you don't vet what happens in your application and why, you have no right to put it on someone else's computer.

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.

Thought of the day, collecting certain types of information on people should require posting a bond and an annual audit and disclosure.

No bond, no audit, no disclosure -> felony.

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.

Yes. These are malware. It's disgusting.

Android and all google properties are malware, we just don't have a lot of good alternatives at the moment.

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.

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.

I absolutely agree, and in my experience your list hardly scratches the surface. And awful not in the normal way that many large companies are awful.

[edit after reading more of the PDF]:

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.

They should be lifetime banned from every Alphabet property. Others have suffered this fate for lesser offenses.

They don't have the will and the courage to ban Facebook/WhatsApp/Instagram from App Store.

Banning is just a band-aid

We need systematic solu...oh wait GDPR - just hit them with all the fines.

> 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`...

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.

Correct.

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.

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.

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.

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.

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.

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.

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.

Users will probably be annoyed if the clipboard contents seems to randomly disappear because an app got killed by the OS.

That is a solved problem on iOS. There is an API that supports third party password managers.

https://appleinsider.com/articles/18/09/18/inside-ios-12-aut...

There is also an API like this an Android, but some apps don't support filling passwords well.

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.

[0] https://www.ftc.gov/system/files/documents/public_events/141...

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.

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.

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.

If Google's part of your threat model, it's probably time to ditch the Android phone entirely. No amount of permissions is really going to matter.

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.

Google and Apple are both part of my threat model. So I use an old dumbphone. It doesn't even text.

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...

https://f-droid.org/en/packages/com.jarsilio.android.scrambl...

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.

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.

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 agree that's a simple experiment. What does it demonstrate?

You said this:

> 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.

Hopefully!—at least if this happens it's a bug.

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).

What exactly is the blame of Android? That it allows the app to read photos when user allows it to read photo files?

On iOS, you have to separately allow image access and access to location data stored as part of the image.

> 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.

> Without rooting your phone you can't even install firewalls or prevent applications from ever connecting to the outside world.

Of course you can. There are multiple apps that do this. One example: https://f-droid.org/en/packages/eu.faircode.netguard/

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

Nope. It runs solely on the device. How else would it know which app is making the network request? What are you basing your strange claims on?

> 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.

From their own FAQ:

> NetGuard will do its best, but it is limited by the fact it must use the VPN service.

FAQ: https://github.com/M66B/NetGuard/blob/master/FAQ.md

VPNService is an API (https://developer.android.com/reference/android/net/VpnServi...). Your own link points tp this documentation. It does not require sending your data to a VPN, and in this case, it obviously doesn't.

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.

> Real firewalls need root.

Real computers let you install trusted stuff that has root.

> Doesn't play well with other VPNs for this reason. Real firewalls need root.

"Real firewalls" also don't play well with other VPNs. I don't see what functionality you think you're missing here.

> 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.

Nobody's suggesting that. Just install another build (like the one I posted on F-droid) or any number of other apps that do the same thing.

> Ultimately this is functionality users should have access to by default

No OS comes with this functionality by default, only the APIs to implement it, exactly like Android.

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.

Yes Android is to blame. The entire idea behind a sandboxed mobile OS is that random developers can’t be trusted not to invade your privacy.

But honestly neither can Google, but that’s another story...

If you upload a picture to Shutterfly, that is a user specifically putting the photo in the app's sandbox. The same thing happens on every other OS.

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.

> The app has to specifically ask for location access to get the metadata.

Source? https://apple.stackexchange.com/questions/335809/can-ios-app... disagrees with your claim.

> 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

Does iOS do anything to prevent this?

Yes, iOS prevents you from directly accessing the images and apps sharing files between themselves.

Which has been one of the major reasons some people used Android - the ability to use their phone more like a computer.

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.

This particular issue should be fixed by Android Q's new "scoped storage" permission model: https://developer.android.com/preview/privacy/scoped-storage...

Looks like apps can opt out via an api call, so it's not really a security measure.

That's only for the beta build of Android Q. It won't work in the production release.

There's a paper linked from the article which contains details on the sidechannels: https://www.ftc.gov/system/files/documents/public_events/141...

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.

For this specific issue, I believe https://developer.android.com/preview/privacy/scoped-storage is the solution.

Too bad many Android developers are opposing this feature (e.g. previous discussion: https://news.ycombinator.com/item?id=19521211).

Yeah, that seems like the right answer.

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.)

Loos like that system also fixes the "steal user location data from pictures metadata" bypass: https://developer.android.com/preview/privacy/scoped-storage...

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.

It's NOT pretty absurd to use access point information to gain location knowledge. Google Street View has done so.

> 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.

https://developer.android.com/guide/topics/connectivity/blue...

Please take a step back and look at this again.

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)

Even APIs of J2ME applets and symbian s60 did not reveal hardware addresses to the program.

I felt that google was lazy and simply mapped bluez 1-to-1 to public api.

What happens when you disable GPS system-level and allowed Bluetooth? Does discovery fail?

Yes

Why shouldn't I buy Google's explanation?

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.

> Why shouldn't I buy Google's explanation?

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.

Would any/all of these methods be violations of U.S. criminal laws against unauthorized computer access?

They seem to contravene the computer owner's explicit choices about allowed access.

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.

(I am not a lawyer.)

Why do they have to wait for Android Q? Couldn't they pull the apps now?

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...

By default apps should not be able to call home, in order to save battery and data plan, ohh and also privacy.

So don't let them.

Doesn't work so well on apps that by their very nature and a variety of contrived reason have to call home.

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.

https://stackoverflow.com/questions/46341694/detect-add-phot...

> Google said it would be addressing the issues in Android Q, which is expected to release this year.

How nice that many of the phones out there will never see this vulnerability fixed.

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.

Sandboxes are never safe.

But man some of these bypasses are getting into evil genius level of shady cleverness.

Is it tho? or is the OS just too relaxed on security?

Think old Windows that people always ridicule, the publicity was rare on calling out bad practice/intentions, it has always been the fault of the OS.

We're asking the sandbox to be perfect and that'll never be a thing. It's always a race between the sandbox makers and those trying to escape it.

"Google says a fix won’t come until Android Q."

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.

Reply on news.ycombinator.com