Librem 5 app-based device fingerprinting

Anyone knows anything about how much persistent data Librem 5 leaks? Android for instance has various IDs, model names et cetera, so it’s really simple for an application to assign a unique fingerprint to use later and maintain a user profile even if said app is completely uninstalled and re-installed later.

So how is it with Librem 5? Is it possible to write a fingerprinting app that does the same? Is it possible to avoid fingerprinting entirely?

1 Like

Some background: Snitching on Phones That Snitch On You – Purism

Without knowing specifically what “the same” refers to, I would say “probably.”

I would say there are too many potential pitfalls in the world of device fingerprinting to answer that question in the affirmative… but it certainly doesn’t hurt to try.

1 Like

It has been speculated that taking measures to avoid fingerprinting might make fingerprinting easier.

2 Likes

I think if I was knowingly going to run an app on my Librem 5 that was going to try to fingerprint me and send the data home to the creator of the app, I would recompile the app without that feature first before launching it. That way, then, the app does not fingerprint me.

4 Likes

This is the correct answer. The idea here is to use Free Software (and Open Source software to a certain degree as well), where the fingerprinting is obvious and visible to all, and removable.

And we would have a quick enough fork that would become the new main project that people want to use, unless it’s something like Signal where the service is locked to a single provider, there we have less freedom…

1 Like

My friend and I who have Librem 5’s use XMPP with OMEMO encryption, which as I understand it takes the Signal encryption code and uses it to encrypt messages outside of the Signal app. Seems better. [Edit: It also probably will start working with Chatty natively on Crimson if they fixed the bugs affecting Byzantium, but I haven’t checked the state of Crimson on L5 for a while.]

So, I think that even in the case of Signal, the concept still applies to some degree. It is probably the time to stop using the original servers and application until or unless they make an effort to provide a seamless Librem 5 experience that does not depend on tethering to some non-Librem-5 device that they think I’m supposed to have.

1 Like

Yeah, the OMEMO encryption is based on the double-ratchet encryption algorithm used by Signal. People often confused the two because both are often referred to as “Signal Protocol”, though one is encryption and one is a communication protocol.

For example, some people thought it would be easy for WhatsApp to connect to Signal because WhatsApp has started using the “Signal Protocol” some years ago – but that was referring to the encryption…

FYI: I’m using Mobian (Trixie, so future Debian 13) on my L5 now, and Chatty’s OMEMO is still… not so good. I use Dino instead.

Well I’ve installed the purple-lurch package to provide omemo, I can’t remember if there’s a better or purism-made package for supporting omemo with libpurple apps.

Right, therein lies the issue… haha

1 Like

Fingerprinting can be done on the server side too though.

(At a minimum, some bits can be derived from your IP address. So you would want to use a VPN.)

And if the app is a web browser, it may be less practical to recompile without fingerprinting or to avoid using the app completely.

Sometimes, yes. In a world where many people don’t care, saying that you care is actually adding to the fingerprint.

For example, anyone using a Librem 5 that identifies itself as a Librem 5 is automatically adding a whole lot of detail to the fingerprint.

Make it illegal without informed consent? :slight_smile:

This may not be exactly in line with what you are asking but it was pointed out the other day that any photo taken on the Librem 5 automatically tags the photo as having been taken on a Librem 5. So straight off, if you are going to leak any photos then you need to strip metadata before leaking the photo.

2 Likes

So no conclusive answer yet… I was thinking about whether there’s a list of IDs that can potentially be harvested by a user-installable application. I understand the ideas behind server-based fingerprinting and leaking IP addresses et cetera, but my question only concerns offline fingerprinting (imagine a scenario where that fingerprint ID never even gets transferred to a remote server).

So,

  1. Install a fingerprinting app, get a fingerprint ID, uninstall the app, reboot the phone, install the app again, get a fingerprint ID.
  2. Install a fingerprinting app, get an ID, reset the device, install the app again, get an ID again.

Second, any meaningful sandboxing already in the OS or is any app allowed to run wild and free and has full access to all the features that a user it’s running under has?

1 Like

PureOS has AppArmor, although I am not sure if it is configured for any applications on ARM64.

2 Likes

No but we can start one here:

  • IMEI, IMSI, ICCID + IP addresses associated with this card
  • WiFi MAC address, Bluetooth MAC address + IP addresses associated with this card
  • serial number(s)? (potentially lots of different hardware e.g. device, CPU, RAM, M.2 cards or e.g. some USB devices)
  • UUIDs associated with disk devices and/or file systems

That is a list of possibilities. That is looking only at potential direct identifiers, rather than looking at more subtle and indirect fingerprinting.

Don’t forget also that if you run untrusted blackbox code and it has persistent storage then it is free simply to generate a (random) UUID and treat that as your fingerprint - without having to access any of the above potential identifiers.

4 Likes

Wow, that’s a handful of freely available IDs.
I understand the point about UUID, my question was more about that fingerprint persisting after a complete application uninstall and reinstall. For example, on Android by default all service files created by an application get deleted if an application itself is uninstalled. Not sure what happens on PureOS and specifically on Librem5. Perhaps it follows the standard Linux model and that means there will be a lot of leftover files kept?

1 Like

It depends on whether you use apt remove or apt purge - but I wouldn’t know which of those the GUI uses. (apt purge gets rid of config etc. files - so there shouldn’t be anything left over.)

They may or may not be freely available. However if you run untrusted code then you certainly take the risk. Note that many of the hardware-related IDs will not change - if you reinstall an individual app or even if you reinstall the whole system.

Fun question: Because of the way the Librem 5 gets installed initially, does everyone end up with the same file system UUIDs? Or do the UUIDs get regenerated on first boot? If the former then in some respects it can’t be used for fingerprinting. On the other hand, having the same UUID isn’t ideal.

Anyone who owns two Librem 5 phones running the same software version able to answer that?

1 Like

I’m not familiar with Linux package management, does apt purge really clean every file created by an application? Suppose my application did a touch /etc/whatever - how would apt know it was created by a certain application? I presume it might have some metadata stored somewhere so it would know, but still… And then that metadata could in theory also be changed by an application.

Regarding the UUIDs, can’t Purism answer the question themselves? They surely know the ins and outs.

1 Like

I think you are right - an intentionally malicious application could likely create a file that survives apt purge - the behaviour that I described would only apply to a well-behaved application.

If you need something more robust than that then there are a range of container technologies that you can use under Linux that might better confine the malicious application and genuinely prevent any file from surviving complete removal of the application. (In other words, the system may still not know every file created by the malicious application but the malicious application will only be able to write into certain dedicated directories, which directories can then be completely wiped out when the application is completely removed.)

I understand that that was just an example but that command will fail (permission denied). If a malicious application is going to leave a permanent fingerprint, it would most likely have to do so somewhere hiding in the user’s home directory. (This is mostly what the malicious application would want anyway i.e. to fingerprint individual users in a multi-user system.)

1 Like