Hacker News Reader

Comment by account-5 | Hacker News Reader

At face value this seems reasonable, but (and this might just be me) because its being pushed by Google I have to ask myself: what's in it for Google, and what am I missing?

Manifest 3 for example breaks adblockers for the sake of 'security', and adverts are Google's business. Passkeys are pushed for security as well (and do have benefits) but for the average person locks you into a eco-system; another business model plus for Google.

So with that in mind, how does this benefit Google at the expense of the user? Making the permissions less explicit, or less separate from the content of a site might be a net benefit to Google... I don't know.

I might also be reading way too much into motivations, and/or paranoid.

View on HN

It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that. Google probably has data showing a large number of users have disabled such permissions globally, with no easy path to trick them into opting back in. That would be the cynical view!

edit: also one can never be too paranoid around Google.

> It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that.

I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.

> I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.

This does not appear to be the case, at least on iOS Safari. I went to Google Maps, gave it permission, then went to Google Search and searched for “delivery near me.” It again asked me for permission.

I imagine browsers have special logic for misbehaving major websites baked in all over the place.

Passkey lock in appears to be a temporary issue. One of the WWDC announcements was that the FIDO alliance worked out a way to securely port passkeys between platforms. I expect Google to adopt import and export before year end.

I believe the issue Google is attempting to solve is frustration when a single web page spams multiple permissions requests. (Location, camera, microphone, advertiser tracking, notifications, privacy policy agreements, terms of service, etc…). The benefit to Google is better fingerprinting when a single sheet allows all at once.

Edit: perhaps they will sneak in a Google automatic login as a permission to smooth user interactions.

It's not temporary. The whole point of attestation in the passkey spec is to make lock-in permanent.

Could you explain more? For Apple, the web page I found seems to be an enterprise thing:

https://support.apple.com/guide/deployment/passkey-attestati...

That's the "cover story" use case. The real use case is so that passkeys created on Apple devices can only ever move to other Apple devices, and ditto for on Microsoft or Google devices, and the real point of attestation is so that they can force you to use theirs by cryptographically ensuring that you're not using open-source ones like KeePassXC.

But the whole point of this new standard is to allow passkeys to be portable:

https://arstechnica.com/security/2025/06/apple-previews-new-...

If that ends up letting attested passkeys be exported outside of the Microsoft/Apple/Google oligopoly, I'll eat my hat.

Who uses attested passkeys? (Serious question.)

As an example, see this issue opened against keepassxc saying that if they continue allowing plaintext passkey export, they're at risk of being blocked once attestation is standardized:

https://github.com/keepassxreboot/keepassxc/issues/10407

The goal here isn't maximizing user choice, it's to enforce minimum agreeable standards by the major vendors. It's up to you whether your personal needs wholly align with what they want to mandate, forever.

Yeah, I’m okay with that. It’s also true that not just anyone can become a domain registry either, but we still have choices.

It’s less convenient, but you can always create a new passkey manually for an account.

Passkeys require a password manager, so at most, this locks you into a password manager - choose carefully!

But it’s not that locked in. You can generate new passkeys for a different password manager, so migration is more of an annoyance, if you do it gradually. Having more than one password manager for a while isn’t so bad.

> Passkeys require a password manager

No, they do not. For the vast majority they will simply require using the two major closed OSes which desire to lock the user in. Importantly the OS layer is where they will first encounter keypass, and so that is where the vast majority of keypass will happen, which is as gp said, the lock in factor.

Advanced users such as that that browse this site, will make use a password manager. Due to the extra effort involved, such users are a minority.

iOS and Chrome (often on Android, but not necessarily) have built-in password managers. I use both! I believe Windows has one, too.

It's true that a lot of people who don't really think about which password manager they should use will end up using one of those by default. (Much like happens with web browsers.)

Getting the masses to use password managers regularly will greatly improve security. It would be better if more people made a deliberate choice, though.

If you already had a password manager, of what good is the passkey?

One improvement is that they use public key cryptography, so they will never show up on Have I Been Pwned due to poor website security.

But yeah, if you use a password manager you’re probably doing better than most people.

If they wanted to improve things, they could include a small little xml link in their password change and registration pages that tells my password manager what passwords are allowed so it could auto-generate them rather than me trying to find out that they disallow anything longer than 32 characters, or that the ampersand isn't permitted. (Or, like years ago, when I discovered that Adobe didn't disallow long passwords they just truncated them to 64 characters internally and wouldn't accept the longer one after.)

Passkeys solve all that by hiding key generation entirely from users. But it requires a password manager and good backups.

Hiding things from me is never going to be a good thing. Hiding things from most people will never be a good thing.

Now that the FIDO alliance transfer protocol has been hashed out, Passkey transfer has been announced to be coming in iOS/macOS 26, I assume it's also coming to the other password managers

Reply on news.ycombinator.com