[HN Gopher] How Android developers access installed apps on user...
___________________________________________________________________
How Android developers access installed apps on user's device [pdf]
Author : Fragoel2
Score : 55 points
Date : 2020-03-24 20:11 UTC (2 hours ago)
(HTM) web link (www.ivanomalavolta.com)
(TXT) w3m dump (www.ivanomalavolta.com)
| yellow_lead wrote:
| If I wanted to do similar research to this, can anyone share a
| good method for obtaining a large corpus of apps like these
| researchers presumably did?
|
| EDIT: Should've read the paper first, looks like they used this
| https://androzoo.uni.lu/
| dserodio wrote:
| I'd love to read a condensed version
| jascii wrote:
| Installed apps list is available through IAMS API, Devs use
| this to profile users.
| kyleee wrote:
| Interesting, what are the legit (if any) reasons this info is
| exposed via that API/endpoint?
| zentiggr wrote:
| I'm happy with granting usage access to a launcher app,
| that can construct a 'recently used' app page.
|
| The apps that tend to stay at the bottom of that launcher
| page are the ones I'd like to most consider removing.
| anonymousab wrote:
| Anti-malware/adware applications could use it to check for
| known bad applications.
| seemack wrote:
| One legit purpose would be to provide better UX in the
| source app. It could display text to explain the situation
| to the user in the case that they don't have the required
| ap. This would be a more seamless experience than a screen
| that has to account for both possibilities.
| jascii wrote:
| That is a good question, and thanks for asking it with a
| lot less toxic sarcasm then I would have.
| folli wrote:
| One legitimate use case is perhaps that in the olden days
| before in-app purchases, you could install an empty paid
| app that would than act as a token that would enable some
| functionality in another app. The second app would need
| some way of checking the presence of the first app.
| mercora wrote:
| you could achieve the same without in-app purchases or
| this API if you are in control of both apps. You could
| for example sign the app with the same key and gain
| privileges by that over your other apps if i recall
| correctly and if its still true.
| phh wrote:
| For this API precisely, I have to admit I have a pretty
| hard time to tell.
|
| However, there are other APIs that leak the list of
| installed applications that have pretty legitimate usages.
|
| For instance the intent resolving API:
|
| - This can be used for an app to know which applications
| the user can share messages to. I believe that nowadays
| developers are supposed to use a generic API for that, that
| don't expose the list of applications to the user, but
| that's a pretty new API.
|
| - This can be used by application Launchers, or apps that
| provide shortcuts or automated launch of other apps
| veeti wrote:
| There are plenty of legitimate use cases listed under
| section 4.5.
|
| I'm sure there is some scumbag adtech SDK out there
| profiling people based on their installed apps, but I think
| that most uses of these API's would turn out to be
| innocuous on a closer look.
|
| For instance, I've worked on apps that check if another app
| from the same company is installed, so that they can
| integrate together. Think Facebook and Messenger: two
| separate apps.
|
| It seems that this sort of innocent check would turn out in
| this study as a "call accessing package names". Sounds
| ominous at first, but I'm just asking for one package X,
| not scraping all your installed apps to sell you something.
|
| Anyway, this is all being locked down in Android 11 [1].
| Many of these use cases are being addressed with a more
| secure API, but I hope there are no apps left behind.
|
| [1] https://developer.android.com/preview/privacy/package-
| visibi...
| TeMPOraL wrote:
| I'm guessing for replacement launchers and apps that launch
| other apps?
| bentcorner wrote:
| Condensed:
|
| https://developer.android.com/reference/android/content/pm/P...
| and
| https://developer.android.com/reference/android/content/pm/P...
| provide a list of installed applications on the phone. These
| APIs are silent to the user.
|
| The study analyzed apps available on the Google Play Store, and
| compared two lists of apps: Open-source apps (via
| https://androidtimemachine.github.io/), and non-open-source
| free apps (the top 500 free apps for each category in the play
| store). The non-open-source apps were the most common users of
| these APIs. Additionally, most of the time the callers of these
| APIs in non-open-source apps are advertising related libraries.
| richardwhiuk wrote:
| Previously in Android app development, the application sandbox
| has been sufficiently leaky that if a user has another app
| installed, it can cause problems for the app being developed.
|
| It's useful to be able to warn users that they've got an app
| installed that will conflict in this way, and suggest an
| upgrade/uninstall/warn them of poor behaviour.
| scarface74 wrote:
| iOS had a similar leak that was exploited by apps like Twitter.
|
| https://www.techspot.com/news/58991-twitter-track-list-apps-...
|
| It used the "canOprnUrl" method if I recall correctly.
|
| Apple locked this down less than a year later in iOS 10 where an
| app has to explicitly list which urls can be tested this way and
| there is a hard limit. Of course this goes through app review.
___________________________________________________________________
(page generated 2020-03-24 23:00 UTC)