The problem with biometrics is, when you somehow loose your exclusive access to it, you can't change them.
This is especially a problem in jurisdictions, where you can't be forced to tell a password, but where your fingers and face are fair game.
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
Be respectful: Treat fellow community members with respect and courtesy.
Quality over quantity: Share informative and thought-provoking content.
No spam or self-promotion: Avoid excessive self-promotion or spamming.
No NSFW adult content
Follow general lemmy guidelines.
The problem with biometrics is, when you somehow loose your exclusive access to it, you can't change them.
This is especially a problem in jurisdictions, where you can't be forced to tell a password, but where your fingers and face are fair game.
Fingerprint sensors have been an interesting hurdle for Linux distros. Not one I necessarily would have anticipated either. The biggest question seems to come down to their security as well, given that there have been exposed flaws in the design of biometric hardware that tries to generalize its compatibility.
Microsoft has defined SDCP as a strong standard for TPM/Windows, but there isn't an equivalent for Linux. Match on chip sensors have made things a bit easier, but there isn't a standard way to communicate the validated authentication to the OS, usually relying on TLS.
it's always amazed me that fingerprint sensors aren't all match on chip, for the longest time I assumed that the fingerprint reader held a key for unlocking the device that is only returned with the correct fingerprint. How else do you implement them securely?
It is. It's just... how do you know you're actually talking to the fingerprint sensor and not a fake one that's been plugged in?
Think of it like a locked mailbox: the fingerprint sensor might securely match the fingerprint and only unlock if it's correct—but if anyone can swap out the mailbox with their own lookalike, and the OS just blindly accepts the "unlocked" signal, the whole security model breaks. Without an attestation mechanism (like SDCP on Windows or secure enclave-backed verification), the OS can't prove it's getting input from trusted hardware. Match-on-chip helps, but it's not enough unless the result is cryptographically signed by the sensor and validated by the OS through a trusted, authenticated channel.
That's the gap in Linux: there's no widely adopted standard for verifying that trust path end-to-end.
This only really works for people who have hardware whose fingerprint readers are supported by upstream fprintd; would be interesting if they (or another distro; haven't seen anybody implement this yet) add a "just works" option for installing and setting up e.g. libfprint-tod-vfs0090
or python-validity
(which I use on two of my machines actually), similar to how some distros (Mint included I believe, but haven't dealt with it in a while) give you an option for installing Nvidia proprietary drivers (or just make it work out of the box).
However these drivers are extremely sketch at times so... I guess there's some good out of it not being preconfigured for people (because you have to look into it yourself and realize just how terrifying they are, both security and stability wise, python-validity
especially)...
(though now I'm on NixOS where I have it pretty much "just work" through not that much effort, at least not as much as on Arch, and definitely not as much as on Mint which was painful because PPA fuckery)
ah, there is it. My reader isn't supported by fprintd so I guess I wouldn't benefit from this change. I'm glad I saw this before I decided to give mint another go
don't worry though, it's meh-ish on all distros, and nobody automatically sets it up for you (as easy as I made it out to be on NixOS, it's not, and it was only "easy" because I'd already dealt with the driver before... in fact I had to carry over my old systemd suspend/hibernate restart script for it because it doesn't really cooperate with waking up from sleep)...
...unless your reader just isn't supported at all, in which case yeah nope