Passkeys have gained significant traction as a phishing-resistant alternative to traditional passwords. Unlike passwords, which can be stolen via fake websites (phishing), passkeys are cryptographically bound to specific domains; a browser will not offer a passkey for `example.com` if the user is on `examp1e.com`. However, some critics argue that this shift toward passkeys introduces a new risk: the loss of ultimate user agency over their own hardware and software choices.
This image illustrates the general concept of passkeys as a modern security standard discussed in the opening paragraph.
A central point of contention involves "attestation," a feature in the WebAuthn protocol that allows a website to request cryptographic proof of the authenticator being used. Critics suggest that by turning up the requirement for attestation, services could eventually restrict logins to only those using approved operating systems or unmodified firmware, effectively locking out users who prefer privacy-focused distributions like LineageOS. Proponents of passkeys counter that most consumer passkeys—those synced across iCloud Keychain, Google Password Manager, or 1Password—do not provide an attestation statement at all. They argue that while a site *can* ask for it, doing so would instantly lock out the vast majority of existing users, making such a move commercially impractical for most websites.
The technical definition of what attestation actually reveals remains a significant nuance in the debate. While some claim it provides no information about the OS or extensions, others point out that certain devices may leak state information during the process. For example, some Android implementations might reveal whether a device has passed verified boot checks, potentially allowing a service to detect if a phone is running a custom ROM. Furthermore, even though many current providers do not require attestation, the existence of the mechanism creates a theoretical path toward more restrictive authentication environments where hardware and software 'trust' are strictly enforced by the service provider rather than the user.