Sandboxes are never safe.
But man some of these bypasses are getting into evil genius level of shady cleverness.
More than 1k Android apps harvest data even after you deny permissions
51–60 of 146 posts
Re: More than 1k Android apps harvest data even after you deny permissions
#52Earlier quoted context omitted.
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…
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
Re: More than 1k Android apps harvest data even after you deny permissions
#53Earlier quoted context omitted.
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.
Re: More than 1k Android apps harvest data even after you deny permissions
#54Earlier quoted context omitted.
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.
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.
Re: More than 1k Android apps harvest data even after you deny permissions
#55By 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 and…
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.
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...
Re: More than 1k Android apps harvest data even after you deny permissions
#56Earlier quoted context omitted.
> 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 yo…
> 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 its…
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.
Re: More than 1k Android apps harvest data even after you deny permissions
#57Earlier quoted context omitted.
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'…
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)
What happens when you disable GPS system-level and allowed Bluetooth? Does discovery fail?
Re: More than 1k Android apps harvest data even after you deny permissions
#58Earlier quoted context omitted.
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.
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.
Re: More than 1k Android apps harvest data even after you deny permissions
#59Earlier quoted context omitted.
> 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…
> 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.
Re: More than 1k Android apps harvest data even after you deny permissions
#60Earlier quoted context omitted.
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 locati…
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.