silversurfer

Level 56
Verified
Trusted
Content Creator
Malware Hunter
A research paper published this week has analyzed the current usage of a lesser-known feature of the Android operating system that could be a danger to user privacy.

The study found that many of today's top Android apps make use of IAMs (Installed Application Methods), a set of Android OS API calls that allow app developers to get a list of other applications installed on the device.

Google initially created these API calls[1, 2] to allow developers to detect app incompatibilities or fine-tune interactions with other apps. However, the study published this week suggests that IAMs are also being used to track and fingerprint users, posing a palpable privacy risk.

The danger to user privacy comes from the fact that an advertiser could infer interests and personal traits (gender, spoken languages, religious beliefs, age groups) by analyzing a user's list of installed applications.

In addition, there is also the issue that users can't protect themselves against IAM-based fingerprinting. This is because IAM calls are "silent methods," meaning that an app does not need to ask the user for permission before it executes.

Furthermore, many IAM calls are also executed without the app developer's knowledge. If an app supports an analytics package or an advertising library, researchers found that many of these ran silent IAM API calls without the app developer being aware this was happening.
More details about this research are available in a research paper titled "Leave my Apps Alone! A Study on how Android Developers Access Installed Apps on User's Device," set to be presented this fall at the MOBILESoft 2020 conference in Seoul, South Korea.
 

security123

Level 6
Also from the GrapheneOS dev:
Stop falling for charlatans claiming to have "discovered" that the OS works this way when it's the basic design. That's especially true if they don't even understand that simply removing APIs for listing other apps won't stop apps from being able to discover which other apps are installed in the profile. People without a basic understanding of the application model are not in a position to write papers or news articles about these things.
If you want profiles to have better usability and flexibility, please contribute to making them better. See Access to list of apps · Issue #149 · GrapheneOS/os_issue_tracker for why there cannot simply be a security feature disallowing listing other apps, as it fundamentally couldn't work. See add support for scoped apps only able to see or interact with system components, not other third party apps (i.e. essentially what profiles already do, but scoped to 1 app) · Issue #156 · GrapheneOS/os_issue_tracker for a feature that's actually possible, but it overlaps heavily with profiles and isn't necessarily desirable.
This is not the first thread on this topic here but it is the final one. Posts are now moderated and future posts on this topic or others that have already been covered here simply won't be approved or given a response. There is no need to have a bunch of threads retreading the same things over and over again. If you want to have a conversation about things with other people, use the IRC / Matrix channel, but the expectation of doing research before either asking questions or making claims still applies there.
There are 2 kinds of profiles: user profiles and work profiles. Profiles provide a lot of useful functionality that's not currently exposed to end users. A lot of work is needed to expose more of the supported functionality and make profiles more flexible and usable.
User profiles are a great fit for isolated workspaces with distinct encryption keys. Work is needed to make them more usable and seamless as isolated workspaces rather than only for multiple users of the devices.
The work profile feature is a nice demonstration of a seamless approach, but it's designed for remote device management of a single work profile per user profile. It's not meant to be used as a way to locally manage an isolated workspace tied to the user profile. Requiring a device administrator app is undesirable and the feature only supports a single work profile per user profile.
User profiles are a much better starting point for fully isolated workspaces since it's not tied to device management and they're cleanly split from each other. It's easier to build from this than work profiles.
Source: https://www.reddit.com/r/GrapheneOS/comments/fpc2av