277 points by zdw 2 days ago | 233 comments on HN
| Moderate positive
Contested
Editorial · v3.7· 2026-02-28 11:59:57 0
Summary Digital Privacy & Data Protection Advocates
Tim Cappalli advocates against using passkeys with PRF extensions to encrypt user data, warning that the practice creates a 'blast radius' where users unknowingly risk permanent loss of encrypted backups, photos, and documents. The content champions user privacy rights, informed consent, and data protection while calling for concrete industry safeguards including warnings, documentation, and transparency measures.
If the user deletes passwords they're shown the same exact message. The only saving grace for passwords is that you can remember them, but are you also suggesting to not use generated passwords?
This is why I haven't started using passkeys. Managing them is looks complicated and I don't understand the ramifcations of what I'm doing.
Also a style nit, it's OK to use "he" or "she" pronouns in a contrived narrative. The "they/their" usage really detracted from the clarity of the example.
Nothing in this post is specific to passkeys; it reads like advice to not encrypt data. There’s no way to prevent some users from losing their encryption key anyway. Whatever warnings you include, even when software doesn't connect to the internet and just encrypts local files, someone will write to support that they forgot their password and ask you to "reset" it.
This give much more conscious control to the user knowing that they are explicitly encrypting which file with which passkey. Additionally, you can just download the page and serve it via localhost so that you always have control of the relying party for your passkey.
How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.
Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.
Passkeys have way too many footguns for me. If I use my phone to sign in I'm going to accidentally create a passkey there on iOS embedded webview. When I use Google Chrome, the website won't give me any information for me to find where I stored the passkey. Was it in iOS keyring? Chrome? My Bitwarden? If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.
I'm sure it's of use to many people but it's been no end of pain for me and it has really signaled to me what it's like to grow into an old man unable to use computers when I was once a young man who would find this easy.
Mom can't figure out what they are or how to use them. They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck (yeah yeah multiple devices and paths to auth and backup codes, none of that matters). It's one further step down the attested hardware software and eyeballs path. Passwords forever, shortcomings be damned.
Probably everything else is debatable, I do agree with one thing though, the cat is indeed out of the bag. It would have been probably a really good use case if the scope was limited to only hardware based security keys for enterprise users only.
Rolling it out for OS platforms, software based authenticators just muddies the water. You cannot even provide any guarantees around it being phishing resistant anymore.
It is conundrum that passkeys were designed to help the majority as they are frictionless (like passwordmanagers etc) but fail in reality.
Even those that have 2 devices they don't have them all the time.
Another overlooked issue is that some banks etc don't allow for 2 devices as login or 2FA. Even if it allowed one needs to keep the spare device always updated. Either Govt needs to build a common API that one can use directly through google pay or apple pay - so that only one app is needed to be kept up to date.
to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them - but at least then if I lose the phone - and I show my ID they should allow me to setup my new phone. But that is also not possible. (I am discounting the awful AI bans)
Passkeys to me come across as a part solution to a valid problem. Education is part of the solution. Treating the user as too dumb to understand why they need strong passwords or passkeys is important.
I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
I use passkeys from keepasxc because the native workflow for passkeys is opaque and easy to misunderstand what you are actually doing. And it's predicated on having an account with big us tech companies.
> "Even if there were explanatory text, Erika, like most users, doesn’t typically read through every dialog box, and they certainly can’t be expected to remember this technical detail a year from now."
Passkeys are a step in the right direction, ironically for the exact reason the author advises caution. We've been telling people to "store your backup key somewhere safe" for the best part of a decade now, and your average Erika hasn't got on well with that at all. Locking themselves out and losing data left, right and centre.
If you've worked at any kind of scale you'll know well that a certain percentage of users will lose their data with E2EE, full stop. It's just different from everything else they've ever used. These are the same people who'd be lost without the "forgot password" link, and there's no shame in that. That's just the reality of it. And passkeys can help people like this to not lose their keys.
If the product is truly E2EE, the best options right now are the passkey implementations baked into Chrome or Apple. Windows, as ever, needs a bit of work, but the password managers seem to be picking up the slack well enough. We also need to educate people that with true E2EE there is no "forgot password" email. Passkeys and the tooling around them still have a ways to go, but we're getting there.
The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.
Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.
The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.
What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
This story of a user deleting their passkey doesn't seem plausible to me. They don't remember why they have a specific passkey for a messaging app? Surely recognizing the app that stores so many memories is enough not to delete the passkey. And why are they "cleaning up" their passkeys in the first place? Yes I put "cleaning up" in quotes, this metaphor, suggesting that a long list of unused passkeys is dirty in some way is inappropriate.
If an app has a billion users, how many do you expect will delete their passkey for no reason? Is this more important then end-to-end encryption for everyone?
If deleting one's passkey for no reason was a thing, I'd expect a real story about a real user, rather then a made-up scenario.
The essay has a condescending attitude towards the normie computer user who can't possibly be expected to know, but it's precisely the normie computer user who would never get the stupid idea of "cleaning up" their passkeys in the first place -- that's something only a nerd with a neurotic attitude to their computer would do.
Somewhat related, i recently ran into the issue, after i created an account on Confer.to [1] on my Desktop, i couldn't login on my iPad / iOS with Proton Pass and/or Bitwarden.
The error message was: "Error: "Authenticator did not return a PRF result — this passkey probably isn’t PRF-capable."
So i now have an account, but can only use it on my Desktop.
(can't change to a password login either, it's Passkeys only...)
[1] end-to-end encrypted AI, developed by Moxie Marlinspike, the founder of Signal: https://confer.to/
I think the distinction is that a passkey is meant to be used for authentication (logging in), and is usually not the only way you can authenticate. If you delete your password, passkey, or 2FA method, you can still go through a "forgot password" flow.
Encryption is different. If you encrypt data with a generated password and then delete it, you're toast, and passkeys are no different. I think the author is arguing that users may not even realize that the passkey itself is needed to decrypt, possibly because they're so associated with login.
I don't think I would have even realized why I felt tension reading if you hadn't mentioned this. They/their wasn't confusing at all but, giving the hypothetical user a name was the weird part. I realize now I was expecting some other user to enter the scenario the whole time. Alice and Bob style. When I got to the end, I felt like I missed something. If there's just one, "the user"/"they"/"their" is fine.
Embedded webviews are the stupidest thing ever. Yesterday I got halfway through a checkout process, had to go back to another app to check something, and then the webview simply disappeared so I didn't bother finishing the checkout. This was on Android
Usually I open it in Chrome but for some reason I didn't realize it was a webview this time
> As of October 2025, passkey login has been fully rolled out and is now required for members with Health Savings Accounts (HSAs) and Reimbursement Accounts (RAs) who use the HealthEquity Mobile app and web experience.
The FAQ is a little misleading by saying WHEN your account has a passkey this and that, but reality is that after October they made them completely mandatory, no bypass, no exceptions. 100% coverage.
Oh, and by the way, passkeys have been broken on PC/Linux when using Firefox for months:
> There Was A Problem: We encountered an error contacting the login service. Please try again in a few minutes.
Neat. You have to use Chrome or Edge.... For months, after making it mandatory...
I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.
I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.
That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.
Generated passwords can be useful, but they come with challenges like management and security. It's better to adopt approaches like password managers or biometrics to enhance usability while maintaining security.
>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck
This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.
And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.
It's more likely for them to accidentally be deleted (or otherwise lost access): in my experience approximately zero users actually understand where their passkeys are stored, and they can be all over the place: the number one question I get is 'why can't I log in?' because they've accepted a passkey setup dialog on one machine without really reading it and now can't log in on another. Sometimes it's on the same machine but in different contexts. No passkeys should be considered something that the average user is going to reliably hold onto (in large part because the industry has been so keen to foist them on users but not very keen at all to educate them on how they work. This also makes them a lot less useful from a security point of view because it means you can't get rid of the recovery process, which tends to be the weaker link).
Passkeys on iOS and macOS actually work quite well in that regard. They get stored in your provider of choice across the web, web views, apps etc., at least in my experience.
Mine is Bitwarden, and that's available on pretty much all platforms, natively where available (except on macOS currently), as a browser extension otherwise.
For the rare instance in which I need to authenticate using a passkey on a computer where I'm not logged into Bitwarden, there's the cross-device CaBLE flow where I can scan a QR code with my phone and use Bitwarden to authenticate. This works across OSes and browsers.
the problem so far is UI and incompatibility across devices, OSes etc.
I am a big fan of Passkeys and the idea of using PRF for E2E encryption, but I wouldn't implement that as now, there is almost zero control over where those passkeys are, how I can recover them, how I manage them. Whenever I have to switch computer (mandatory policy at work), or phone (mandatory obsolence) or if I want to work across OSes (Mac for work, Windows for fun), everything falls apart, incomprehensible interfaces, inexistent transparency and control. And I'm a pro user that has actually studied how the standard works.
I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.
You're thinking about hardware authenticators, not Passkeys. Passkeys are definitionally synchronized and backed up in the cloud (otherwise you just have a sparkling WebAuthN authenticator).
Proprietary clouds and sync backends create their own set of problems, but they do solve the availability issue of always having to register at least two different security keys with each service.
> to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them
That's exactly what you can do today!
> I show my ID they should allow me to setup my new phone.
You have to show them your phone number, which for better or worse is our age's "showing ID", but then you can indeed get back in.
I think the idea behind PRF was something like "use this as one of several keys", never as "use this the only key". I don't think this was explicitly called out in the specs, though.
> this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion
That sounds like a reasonable idea, but still doesn't help with the case of a completely deleted/destroyed authenticator, e.g. a lost Apple/Google account or Yubikey.
The only viable solution to me for mass adoption is restricting (by recommendation, since there's no way to programmatically enforce it) PRF to scenarios where it's only one out of several ways to get access back. Some password managers do this, e.g. they encrypt their master secret under a PRF-derived key, but this is not the only way/place to get to the master secret, and they also encourage printed key backups etc.
I consider myself pretty sophisticated with passkeys (I wrote a toy implementation of WebAuthN once to understand them better), and yet I still get tripped up by this sometimes: Not via intentional deletion, but accidental overwriting.
As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.
Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.
Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.
This is usually due to relying party and possibly password manager bugs, but it does happen.
> I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
Both iOS and Android sync passkeys to their respective cloud accounts by default. (Of course, losing access to that account, sharing one across family members and causing confusion etc. are still concerns.)
The real problem is lock-in, as this effectively often prevents entire families from switching from iOS to Android or vice versa. I'd encourage anyone managing their family's tech setup to pick a platform-agnostic passkey implementation such as 1Password or Bitwarden for that reason.
Core advocacy. Content defends right to private data (encrypted messages, photos, documents) and warns against design practices that put privacy at risk. Advocates that users should understand and consent to how their private data is protected.
FW Ratio: 60%
Observable Facts
Article identifies multiple categories of private data at risk: 'encrypting message backups (including images and videos), end-to-end encryption, encrypting documents and other files'.
Author emphasizes that privacy protection has been 'coupled' to a credential without user awareness: 'There is nothing in the UI that emphasizes that these backups are now tightly coupled to their passkey.'
Explicit call to industry: 'please stop promoting and using passkeys to encrypt user data.'
Inferences
The article treats privacy protection and user consent as inseparable rights—users have a right to private data AND a right to understand how it is protected.
The focus on the 'coupling' problem frames the issue as one of arbitrary or hidden interference with privacy, directly implicating Article 12.
Strong advocacy against arbitrary interference with privacy. Core argument: users suffer arbitrary loss of access to private data ('interference') because the coupling between credential and encryption is not transparent to them. Advocates for warnings and disclosure to prevent this arbitrary harm.
FW Ratio: 60%
Observable Facts
Author states: 'When you overload a credential used for authentication by also using it for encryption, the "blast radius" for losing that credential becomes immeasurably larger.'
Key observation about user experience: user deletes passkey thinking it only affects authentication, unaware it will destroy encrypted backups—this is arbitrary interference from user's perspective.
Author proposes remedy: 'please prioritize adding warnings for users when they delete a passkey with PRF'—treating warnings as right to information about interference.
Inferences
The article defines 'arbitrary interference' not as hostile action but as silent, undisclosed coupling of uses—users cannot consent to or anticipate the interference.
The proposed solutions (warnings, documentation, disclosure) frame privacy protection as requiring transparency about technical architecture, not just data protection.
Content invokes human dignity as foundational value. Frames data loss (encrypted personal memories) as violation of dignity and user agency. Emphasizes that users deserve to understand implications of their choices.
FW Ratio: 60%
Observable Facts
Author describes encrypted data as 'most sacred data' and invokes photos of deceased relatives as example of irreplaceable personal content.
Article emphasizes that users cannot be expected to understand technical coupling between authentication and encryption, violating informed consent.
Author frames the issue as a matter of user understanding and agency: 'We cannot, and should not, expect users to know this.'
Inferences
The framing treats data protection and informed consent as aspects of human dignity, aligning with UDHR's foundational commitment to human dignity.
The emphasis on user agency and understanding suggests a rights-based approach to technology design.
Strong exercise and advocacy of freedom of opinion. Author freely expresses concern about industry practice and calls for change. Opinion clearly labeled, concerns substantiated with technical reasoning and user scenarios.
FW Ratio: 60%
Observable Facts
Blog explicitly presents content as opinion/editorial: 'Random Thoughts' category, clearly authored by identified individual.
Author expresses opinion freely: 'I am deeply concerned about users losing their most sacred data.'
No apparent platform suppression or gatekeeping; blog is open to public read.
Inferences
The platform and authorship model enable free expression without interference, supporting Article 19 rights.
The willingness to publish criticism of industry practice (major tech companies Apple, Google, Bitwarden mentioned) demonstrates actual freedom of expression in practice.
Content advocates for data security as a fundamental aspect of personal security. 'Blast radius' framing emphasizes how credential loss cascades into security compromise of user's most sensitive data.
FW Ratio: 50%
Observable Facts
Author explicitly uses term 'blast radius' to describe the scope of harm when a single credential is lost, equating it to security compromise.
Inferences
The 'blast radius' framing treats data security as inseparable from personal security, suggesting that unauthorized data loss represents a security violation.
Content advocates for users' property rights in personal data. Encrypted documents, photos, and digital assets are user property that can be arbitrarily lost. Advocates for design practices that protect users' ability to retain and access their property.
FW Ratio: 67%
Observable Facts
Article lists 'encrypting documents and other files' and personal photos as data at risk—all constitute user property.
Erika scenario illustrates loss of property: 'Goodbye, memories' (loss of personal photo property).
Inferences
The advocacy treats encrypted backups and personal files as property that users have right to retain and access, with protection against arbitrary loss.
Content advocates that all users deserve equal protection and understanding regarding their data. Framing assumes equal dignity of all users (Erika example) and their equal right to protect personal assets.
FW Ratio: 50%
Observable Facts
Article uses 'Erika' as representative user example, illustrating harm affecting all users equally regardless of technical knowledge.
Inferences
The choice of a common-name, relatable user scenario asserts universal vulnerability to this harm, implying equal human dignity deserves equal protection.
Content advocates for protection of users' participation in cultural/personal digital life. Personal photos, messages, documents are expressions of cultural and personal identity. Data loss means loss of ability to participate in and preserve personal cultural archive.
FW Ratio: 50%
Observable Facts
Article emphasizes photos and personal digital content as precious cultural/personal assets: 'photos of loved ones who are no longer here,' messages, documents, crypto wallets.
Inferences
The framing treats personal digital data as cultural/personal expression deserving protection equivalent to Article 27 protections.
Indirectly advocates for user participation in standards/industry governance. Calls on identity industry to change course, implies users should have voice in how their data is protected through standards and platform governance.
FW Ratio: 50%
Observable Facts
Author's asks are directed at governance bodies: 'To the wider identity industry,' 'To credential managers,' 'To sites and services'—treating these as entities that should respond to user rights concerns.
Inferences
The framing implies that users have right to participate in (or at least have influence over) decisions about data protection standards and practices.
Tangentially addresses right to adequate standard of living by advocating for digital security/data access as part of adequate modern life. Loss of encrypted data/backups harms user's ability to maintain digital life adequately.
FW Ratio: 50%
Observable Facts
Article frames encrypted backups as necessary for adequate digital life: backups support access to essential communications, photos, financial data.
Inferences
The advocacy implicitly treats digital security and data access as part of adequate living standard in contemporary society.
Tangential reference to family/home via 'photos of loved ones who are no longer here' as example of irreplaceable family data. Advocates protecting family memories and personal/family privacy.
FW Ratio: 50%
Observable Facts
Author invokes family data as highest priority: 'They don't want to lose their messages and photos, especially those of loved ones who are no longer here.'
Inferences
The framing treats family photos and memories as sacred family/personal assets deserving protection equivalent to Article 16 protections.
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 11:31:12 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.