You mean like https://acceptableads.com/ which is only supported so far by Adblock Plus (and its parent company)?

The problem is until there is some kind of penalty for being too annoying or too resource consuming, it will always be a race to the bottom with more, worse ads. As people add ad blockers to their browsers, the user pool that isn’t running them begins to dry up and more ads are needed to keep the same revenue. This results in even more people blocking them.

Two of the things I had hope for on the privacy side was Mozilla’s Privacy-Preserving Attribution for ad attribution and Google’s Privacy Sandbox collection of features for targeting like the Topics API. Both would have been better for privacy than the current system of granular, individual user tracking across sites.

If those two get wide enough adoption, regulation could be put in place to limit the old methods as there would be a better replacement available without killing the whole current ad supported economy of most sites. I get that strictly speaking from a privacy perspective ‘more anonymous/private tracking’ < ‘no tracking’ but I really don’t want perfect to be the enemy of better.

While the defaults are typically to use what the browser or OS has for storage and sync of the passkeys, you can use other things.

Like KeePassXC:

https://keepassxc.org/blog/2024-03-10-2.7.7-released/

As for attestation to how the key is stored securely (like in a hardware key), Apple’s implementation doesn’t support it for iCloud ones, so any site that tries to require it wouldn’t work for millions of people. That pretty much kills it except for managed environments (such as when a company provides a hardware key and wants to make sure that’s the only thing that’s used).

Yes, Vivaldi does: https://vivaldi.com/features/ad-blocker/

I think you mean that passkeys potentially skip the something you know. The something you have is the private key for the passkey (however it’s stored, in hardware or in software, etc). Unlocking access to that private key is done on the local device such as through a PIN/password or biometrics and gives you the second factor of something you know or something you are. If you have your password manager vault set to automatically unlock on your device for example, then that skips the something you know part.

Which is really stupid of them but technically within spec currently.

Your vault is encrypted on your device before it’s sent to Bitwarden’s servers, so even they don’t have access to your passwords and passkeys.

More info on how it is encrypted is here:

https://bitwarden.com/help/what-encryption-is-used/

Pretty much every password manager works like this. Having access to your data would be a liability for them.

Does it work like that? Everything I see says they’re tied to that device.

It depends on what kind you want to use. If you want the most security, you can store them on something like a Yubikey, with it only being on that device and not exportable. If you get a new device, you’ll need to add that new device to your accounts. For less security but more convenience, you can have them stored in a password manager that can be synced to some service (self-hosted or in the cloud) or has a database file that can be copied.

Fair, I guess I’ve never lost a password because it’s just a text string in my PW manager, not some auth process that can fail if things don’t work just right.

That’s fair. It can be a bit of a mess with different browser, OS, and password manager support and their interactions but it has continued to get better as there is more adoption and development.

Isn’t the sync for keepass-compatible apps just syncing a normal file?

If it makes you feel better, most PINs on modern devices are hardware backed in some way (TPM, secure enclave, etc) and do things like rate limiting. They’ll lock out using a PIN if it’s entered incorrectly too many times.

Typically in most situations where a PIN is used on a modern device, it is not just the number you enter but some kind of hardware backing that is limited to the local device and also does things like rate limiting attempts.

you can’t just share passkey between your devices like you can with a password

You would just sign into your password manager or browser on both devices and have access to them?

Additionally, whatever app or service you’re storing them in can provide sharing features, like how Apple allows you to share them with groups or via AirDrop.

there’s very little to no documentation about what you do if you lose access to the passkeys too.

If you lose your password, there are recovery options available on almost all accounts. Nothing about passkeys means the normal account recovery processes no longer apply.

So one password to access them all basically?

That’s essentially how all password managers work currently though?

When most sites refer to passkeys, they’re typically talking about the software-backed kind that are stored in password managers or browsers. There are still device-bound passkeys though. Also since they’re just FIDO/WebAuthn credentials under the hood, you can still use hardware-backed systems to store them if you really want.

While you’re right that device bound and non-exportable would be best from a security standpoint, there needs to be sufficient adoption of the tech by sites for it to be usable at all and sufficient adoption requires users to have options that have less friction/cost associated with them, like browser and password-manager based ones.

Looking at it through the lens of replacing passwords instead of building the absolutely highest-security system helps explain why they’re not limited to device-bound anymore.

What separate auth operation is needed besides authenticating with the local device to unlock a passkey?

More usable for the average user and more supported by actual sites and services, so yes.

The passkey stored locally in some kind of hardware backed store on your device or in your password manager is the first factor: something you have.

The PIN/password or fingerprint/face to unlock the device and access the stored passkey is the second factor: something you know or something you are, respectively.

Two factors gets you to 2FA.

And the fewer times that people are entering their password or email/SMS-based 2FA codes because they’re using passkeys, the less of an opportunity there is to be phished, even if the older authentication methods are still usable on the account.

You do realize that your biometric authentication techniques don’t actually send your biometrics (e.g. fingerprint/face) to the website you’re using and that you are actually just registering your device and storing a private key? Your biometrics are used to authenticate with your local device and unlock a locally-stored private key.

That private key is essentially what passkeys are doing, storing a private key either in a password manager or locally on device backed by some security hardware (e.g. TPM, secure enclave, hardware-backed keystore).

Sadly I’ve run into the same type of problem with a newer TLD as well. My solution was to get a domain in the older TLD space (e.g. .com, .net, .org). I doubt this will be the last site you run into that doesn’t support a newer TLD and the low likelihood that you’re going to be able to convince someone to fix the issue at every one of those outdated sites means that you’ll eventually need a backup domain for something.

I feel like it’s less a conspiracy and more that some people will accept nothing less than no ads or tracking whatsoever, even if it makes no economic sense with regards to how sites support themselves.