So when I read Android 16 (API 36) changes, I stumbled upon this interesting finding
Android 16 (API level 36) includes the following security changes.
MediaStore version lockdown
For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques.
This got me thinking, what are other ways app can fingerprint users on Android?
If the profiles are not running at the same time there is -
The following can also be used If profiles are running at the same time. Remember owner profile is always running -
Both fingerprintjs and TrustDevice offer open source libraries to app developers which can be easily included in their app to allow them to fingerprint the device their app is running on.
kDI Device Info system permission | F-Droid - Free and Open Source Android App Repository can let you see a lot of the stuff available to apps without any permissions granted
Thanks for this, I was actually looking for an app to see my device fingerprint.
That’s a lot, I didn’t know about the storage, is it at least rounded ? Time screen is also quite sensitive.
I am also wondering about IPC communications. I know GrapheneOS always repeats that Android apps are sand-boxed, but when I install Messenger or Threads it will automatically recognise that I also have an Instagram account.
The android sandbox protects apps from other hostile apps. If facebook/meta owns all the apps in question (which they do), they’re freely allowed to communicate with each other.
Does iOS have similar issues?
There are fingerprintable APIs on iOS too, but Apple started restricting using them recently as part of the reason API.
Some APIs that your app uses to deliver its core functionality — in code you write or included in a third-party SDK — have the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting. Regardless of whether a user gives your app permission to track, fingerprinting is not allowed. Describe the reasons your app or third-party SDK on iOS, iPadOS, tvOS, visionOS, or watchOS uses these APIs, and check that your app or third-party SDK only uses the APIs for the expected reasons.
It includes APIs for accessing file timestamps, system boot time, available disk space, list of active keyboards, and user defaults.
It was not enforced from day one though, so not sure if they enforce it now.
How is that checked ? AFAIK even “Sandboxed” Google Play Services works by communicating with all other apps, so it doesn’t seem only apps from the same company can communicate with each other.
Right. That’s because most of the non-Google apps want to communicate with Play Services through IPC. Android is designed in such a way that both apps have to consent to communicate. You can read more about this by googling Intents and Binders.
Apple's Required Reason API: Aftermath after one year in practice - Appicaptor Blog
Apple designed the “Required Reason” API to enhance user privacy and trust. It helps ensure that app developers clearly communicate the reasons for requesting access to personal data or certain device capabilities.
The guideline is now active for almost a year, and we’ve observed that this approach seems to generally work. But in practice, we observe some developers sneaking around these restrictions without Apple acknowledging this fact.
Seems like it’s partially successful, but with loopholes. I guess that even for a company with the level of control of their OSes like Apple, apps still have too much invasive access to the OS to effectively limit their access to unique data.