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?

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).

Just want to point out, that apparently WordPress.org is not owned by the foundation but rather Matt himself, which many people are confused about. It should probably not be used as a stand-in way to refer to the foundation.

https://www.pluginvulnerabilities.com/2024/09/30/who-owns-the-wordpress-website-and-wordpress-org/

Matt Mullenweg Apparently Personally Owns the Website

The author of the post quoted in the previous section seems to treat it as a given the Matt Mullenweg owns the WordPress website. The closest we have found to confirmation of that is screenshots apparently from a WordPress Slack were he apparently wrote this:

W.org belongs to me, it’s not part of the foundation or any trust, I run it in an open way that allows lots of folks to participate but they don’t own it.

And this:

I have direct and root access to the account (and everything on w.org) because I started it.

It’s an improvement over the current systems. Incremental improvements to the state of things can be a good thing too.

Isn’t the main problem that most people don’t use the E2E encrypted chat feature on Telegram, so most of what’s going on is not actually private and Telegram does have the ability to moderate but refuses to (and also refuses to cooperate)?

Something like Signal gets around this by not having the technical ability to moderate (or any substantial data to hand over).