Device Fingerprinting Test Results, Concerns, and Questions

GrapheneOS

rigor-us Apps can only see the list of apps within the same profile and it's not a very stable identifier. There's a per-app-per-profile software identifier (ANDROID_ID) so identifying a specific profile doesn't require apps to do fingerprinting.

Media DRM ID is known to be flawed and that's why we're planning on gating it behind a toggle for returning a placeholder value. It hasn't been implemented yet because it won't resolve the broader issue of fingerprinting so it's not one of the highest priorities. It's going to get addressed in GrapheneOS but it isn't going to change much.

In the much longer term, support for running apps in virtual machines is planned. There will be a much more limited set of functionality available which will gradually need to be filled in and there can be far more toggles. This is the only way of hiding many things like the device model from apps by having the same virtual machine image builds across devices and supporting using a standardized screen resolution, etc. They could still do timing/performance-based fingerprinting which is also doable by websites. This can also theoretically be used for communication between apps and even web sites. The performance impact of CPU and other resource usage by an app or web site can be observed by others, so there's inherently a potential for data leaks and communication through this approach, not only fingerprinting the hardware and OS based on performance of various functionality.

GrapheneOS

We do not think fixing the Media DRM ID is realistic but rather we'll need to provide a toggle where a placeholder value such as one based on ANDROID_ID can be returned by default with a notification provided to the user informing them the app tried to access it and that they can toggle on using the actual Media DRM ID if they want to do that. Trying to fix it would likely break the functionality since it wouldn't be the expected value anymore. This feature predates the removal of access to actual hardware identifiers and they did seem to take privacy into account by making it per-app but didn't make it per-profile-per-app as required to properly support profiles. It may not provide the intended functionality with a per-profile-per-app approach.

Android trying to prevent apps identifying the device is still really in an early phase and Android removing the most obvious way of doing it (hardware identifiers) doesn't mean that it has been prevented. Not being able to access hardware identifiers like IMEI is still very useful, especially if all other identifiers beyond device model and OS can be reset or changed.

PeacefulBoar

I recently did some testing of RDM ID identifiers, using the two software mentioned at https://discuss.grapheneos.org/d/19484-unique-drm-id/7 .

The result was that for the same software Stock OS, Stock OS with factory settings restored, GrapheneOS, and GrapheneOS with factory settings restored the RDM ID was an identical value.

I don't know if there is any way to change the value of RDM ID.

I've used a near real name google account to log into sandboxed Play services, and if it sends the RDM ID to google then the google account in my other profiles is no longer anonymous. And there is no way to restore my anonymity on this device by restoring factory settings.

graphenemuffin

PeacefulBoar

Yes, exactly. @GrapheneOS how come "fixing" MediaDRM "won't change much"? This is a sure-way for ANY application to know you're the same person across profiles, whereas other types of fingerprinting aren't as alarming and certain as this.

I don't know how this isn't talked about more.

6r4f

This is concerning and very interesting. Thank you everybody for letting us know and keep us updated on any news in regards to this.

Imagine the amount of resources they invest in fingerprinting, tracking and restrictions would actually be used for the advancement of humankind...

mmobder

6r4f try Cromite that is less fingerprintable. It doesn't play videos on X, but it's OK from many perspectives

de0u

graphenemuffin How come "fixing" MediaDRM "won't change much"?

I guess it depends on what is meant by "fixing". Would a toggle return a fixed bogus value, a random value every time, a random value chosen when a user profile is created...? Should a Private Space have the same value as the parent user profile? Note that arbitrary changes to the i.d. will cause some things to stop working: for video decryption to work, the i.d. as seen by the video app must match the provisioned Widevine certificate, or else the video won't decrypt.

Aside from all of that, in order for changing the behavior of the Media DRM i.d. to "change much", one precondition would be that a lot of apps are using it. I believe I have seen complaints about one app, Snapchat, using it. Presumably Netflix and other video subscription services use it as well. Is there a list of other apps and/or web sites that are definitely using it?

Another precondition for removing/faking/randomizing the Media DRM i.d. to "change much" would be that a fair number of apps that can currently fingerprint users would lose the ability to do so. Is there reason to believe that "fixing" the Media DRM i.d. would significantly impede specific apps and/or web sites fingerprinting users?

If it is clear that "fixing" the Media DRM i.d. would "change much", presumably it is easy to provide specific examples...

Meanwhile, the GrapheneOS team recently added code to alert users when Play Integrity is invoked. If a member of the community submitted similar code to alert users when the Media DRM i.d. is read, I suspect that would be reviewed.

DeletedUser495

graphenemuffin you can query if an app uses MediaDRM classes in Scanner section of App Manager (app I frequently recommend) before you first run it to be sure if they are present.

graphenemuffin

de0u I believe I have seen complaints about one app, Snapchat, using it. Presumably Netflix and other video subscription services use it as well. Is there a list of other apps and/or web sites that are definitely using it?

Well, isn't this a symptom of this problem? We don't know what could be using it; anybody could be using it. As a GrapheneOS users, given we respect our privacy & security more than most, I think it is fair to say we shouldn't be just hoping they don't use MediaDRM to track us? Especially given the API to access this identifier, AFAIK, doesn't depend on any special permissions?

I honestly think it's a strange position to just hope they don't query for this identifier and call it a day.

graphenemuffin

de0u

Don't be needlessly naive; it's clear that that was inferred from your comments, specifically

de0u Aside from all of that, in order for changing the behavior of the Media DRM i.d. to "change much", one precondition would be that a lot of apps are using it.

I just want to be clear I am not making any demands to anyone. I already know GrapheneOS have stated they're working on this (though the last update I had seen was from 2023). I just think people should be more aware of this particular identifier; I mean, it's not even documented here https://grapheneos.org/faq#non-hardware-identifiers but ANDROID_ID is.

We already have seen @PeacefulBoar get caught unwary by this, in this thread, for example.

de0u

graphenemuffin It's clear that that was inferred from your comments, specifically

de0u Aside from all of that, in order for changing the behavior of the Media DRM i.d. to "change much", one precondition would be that a lot of apps are using it.

I'm afraid that's just set theory. If, hypothetically speaking, only one app is using the Media DRM i.d. for fingerprinting purposes, then changing the handling would reduce the fingerprinting of just one app. If, hypothetically speaking, 10,000 apps are using it that way, then changing the handling might make a substantial difference.

I don't see how that straightforward implication results in a further implication that anybody is "just [hoping] they don't query for this identifier and [calling] it a day". Mitigations other than hope are possible.

Meanwhile, if many non-media apps are querying for the Media DRM i.d., adding a list of them to the open issue might be productive.

de0u

graphenemuffin I honestly think it's a strange position to just hope they don't query for this identifier and call it a day.

I'm not sure who has stated that position. Is it possible to provide a source?

de0u

graphenemuffin Don't be needlessly naive [...]

It seems as if this forum presented you with an opportunity to avoid needlessly being rude, which unfortunately was not achieved. Hopefully going forward if similar opportunities present themselves the results will be better.

Nobody

DeletedUser495 you can query if an app uses MediaDRM classes in Scanner section of App Manager (app I frequently recommend) before you first run it to be sure if they are present

Is that "MuntashirAkon" app manager on github?

indigomadelin

DeletedUser495 Where is the Scanner located? I can't find the button in App Manager. I installed https://github.com/fingerprintjs/fingerprintjs-android (for test because it definitely uses DRM ID), but I don't see any references to Media DRM ID in Activities, Receivers, Providers, (User) Permissions

DeletedUser495

Nobody yes

DeletedUser495

indigomadelin if you tap on an app, there is a panel in the middle Launch - Uninstall - View in Settings - Manifest - Scanner - F-Droid - Store, just scroll through it.

But I have gone through a few apps that are known for DRM collection and answer is not that simple. Look at apps Manifest file, you can also extract apk and go through it (view it as ZIP) but there is no guarantee you will find if an app uses DRM Apis, since it is cooked straight into Android framework. So can't help there.

« Previous Page