44 ms·

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 happe

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.

sschueller 7y ago
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.
- drampelt 7y ago
  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.
  - windexh8er 7y ago
    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.
- doc_gunthrop 7y ago
  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.
- deleted 7y ago
  [deleted]
- imtyler 7y ago
  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?
  - kalleboo 7y ago
    > 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.
    - etherealG 7y ago
      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.
- anticensor 7y ago
  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.
  - djakjxnanjak 7y ago
    Users will probably be annoyed if the clipboard contents seems to randomly disappear because an app got killed by the OS.
- scarface74 7y ago
  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-autofill-gives-password-manager-apps-on-your-iphone-a-big-boost https://appleinsider.com/articles/18/09/18/inside-ios-12-aut...
  - pitaj 7y ago
    There is also an API like this an Android, but some apps don't support filling passwords well.
wartijn_ 7y ago
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/1415032/privacycon2019_serge_egelman.pdf https://www.ftc.gov/system/files/documents/public_events/141...
- giancarlostoro 7y ago
  > 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.
  - ceejayoz 7y ago
    > 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.
BryantD 7y ago
There's a paper linked from the article which contains details on the sidechannels: https://www.ftc.gov/system/files/documents/public_events/1415032/privacycon2019_serge_egelman.pdf 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.
- deleted 7y ago
  [deleted]
- yegle 7y ago
  For this specific issue, I believe https://developer.android.com/preview/privacy/scoped-storage 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 https://news.ycombinator.com/item?id=19521211).
  - BryantD 7y ago
    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.)
  - Ajedi32 7y ago
    Loos like that system also fixes the "steal user location data from pictures metadata" bypass: https://developer.android.com/preview/privacy/scoped-storage#photos-location-info https://developer.android.com/preview/privacy/scoped-storage...
  - altfredd 7y ago
    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.
doomjunky 7y ago
It's NOT pretty absurd to use access point information to gain location knowledge. Google Street View has done so.

sschueller 7y ago

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.

drampelt 7y ago
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.
- windexh8er 7y ago
  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.
doc_gunthrop 7y ago
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.
deleted 7y ago
[deleted]
imtyler 7y ago
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?
- kalleboo 7y ago
  > 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.
  - etherealG 7y ago
    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.
anticensor 7y ago
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.
- djakjxnanjak 7y ago
  Users will probably be annoyed if the clipboard contents seems to randomly disappear because an app got killed by the OS.
scarface74 7y ago
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-autofill-gives-password-manager-apps-on-your-iphone-a-big-boost https://appleinsider.com/articles/18/09/18/inside-ios-12-aut...
- pitaj 7y ago
  There is also an API like this an Android, but some apps don't support filling passwords well.

wartijn_ 7y ago

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/1415032/privacycon2019_serge_egelman.pdf https://www.ftc.gov/system/files/documents/public_events/141...

giancarlostoro 7y ago
> 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.
- ceejayoz 7y ago
  > 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.

BryantD 7y ago

There's a paper linked from the article which contains details on the sidechannels: https://www.ftc.gov/system/files/documents/public_events/1415032/privacycon2019_serge_egelman.pdf 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.

deleted 7y ago
[deleted]
yegle 7y ago
For this specific issue, I believe https://developer.android.com/preview/privacy/scoped-storage 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 https://news.ycombinator.com/item?id=19521211).
- BryantD 7y ago
  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.)
- Ajedi32 7y ago
  Loos like that system also fixes the "steal user location data from pictures metadata" bypass: https://developer.android.com/preview/privacy/scoped-storage#photos-location-info https://developer.android.com/preview/privacy/scoped-storage...
- altfredd 7y ago
  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.

doomjunky 7y ago

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