Exactly. That's why I'll never use passkeys: they're just another way to force us into a commercial walled garden.

Passwords with 2FA are simply better and more freedom friendly.

I store my passkeys in KeePassXC and I have absolutely no feeling of being walled into any garden, personally.

but what do passkeys offer in terms of security, when stored in password managers, compared to having a (password manager) generated password and a totp?

I believe that by allowing password managers to store passkeys, the whole purpose of "device based security" got lost..

They are 100% immune to credentials phishing. You literally cannot authenticate to an impersonator site based on cryptographic guarantees.

And yes, I know the happy path of password managers uses host-based autofill which does add some friction to phishing attempts, but given the prevalence of unexpected but legitimate urls with weird alternate subdomains/SSO/redirects in modern login flows, you have to manually autofill/add an exception often enough that it's possible to let your guard down once at the wrong time.

Yes. I use hardware based passkeys and absolutely love them. I think it was a giant mistake having them 'software' based. It some ways it kind of defeats the entire purpose...

Wait until websites start demanding device-bound/attested passkeys. Big tech just needs to get enough adoption to make this change.

Nobody is going to do this because Apple’s devices don’t support this for the Passwords app out of the box, by design.

As much as I hate to admit it (because I love passkeys UX), but I do think that device-bound/attested passkeys are going to happen in the future :(

UPD: oh, heck, attested passkeys are actually already in the protocol. Why can't we just have nice things?

I just bought a passkey... It's a USB device, completely separate from any big conglomerates.

But then you need to phisically carry it along with you everywhere you go, if you want to log into a service :/

Yes, it’s like a key. :)

Though realistically I use a passkey for services I care about and a password manager for the rest.

Keys can be copied very easily. It’s one of their primary features. Can you easily copy your USB key?

Physical keys can easily be copied, and physical locks can easily be picked. That might be fine for your house or storage unit, but for your bank account or your car (newer cars no longer have simple physical keys/locks), we've moved beyond that tech.

That any and all physical security measures can be defeated is a feature, not a bug. Almost no human beings actually need that level of security, and the tradeoffs are absolutely not worth it for those of us without Mossad as a threat.

How often do people lock themselves out of their own house? Don't you know anyone with ADHD? Imagine any time that happens it is mathematically verifiably permanent as a fact of reality itself. It doesn't matter that the state still views you as the legal owner, you are never allowed in ever again.

No web service is like that. They all offer recovery options. We aren't talking about Bitcoin here.

The trend of companies becoming easier to contact and customer service becoming better is well-documented.

Tell that to the people who have lost access to their Google account.

Now we aren't talking about a security problem, we're talking about who really owns what. Google can lock you out of your account no matter what kind of authentication they use for that account

It's a lot easier to be locked out with a passkey than without one.

No it's not. Google flips a bit in their database and no matter what kind of authentication you set up with them, you get denied

This does not reflect my own lived experience.

But if true, that means that Google can choose to not provide you a recovery service, which is functionally the same as them not having it.

I'm not even sure what your point is anymore. If Google decides they don't want you to log in anymore, you can't log in anymore. It doesn't matter if you try to log in with a passkey, a password, your fingerprint, or sending a secret code in with carrier pidgeon. This has nothing to do with passkeys vs passwords vs anything else.

If Google does want you to be able to log in then they will work with you to make that happen, whether you forgot your password, lost your passkey, or your carrier pidgeon died.

Passkeys are not special in this regard at all. What does make them special is that nobody can use a phishing attack to steal your passkey and log in to your account. Nobody can guess your passkey and log into your account. Nobody can intercept your passkey in flight and log in as you. That's the important distinction.

Yubikeys are Secure Enclaves designed to not be copyable

Right. That's the flaw I was pointing out.

You can 'copy' it by registering a new one to the service.

That's not the problem for me - I carry a bunch of tokens with me anyway (all my banking stuff is on hardware tokens, for example). My problem is more: My browsers run in containers or VMs, intentionally without hardware access. Getting passkeys to work there would be quite a bit of effort.

And hope you don't lose it, or leave it in a pocket when you do the laundry, or plug it into a faulty USB port that zaps it, etc.

My yubikeys have survived dips in the ocean, spilled beers, run over by cars, dropped in pans of used motor oil, left out in thunderstorms, and multiple trips through the washer and dryer. They're still fine even after a decade.

Nothing survives the xkcd 538 wrench attack.

How do you see passkeys as a walled garden but not 2FA? You presumably store your 2FA seed in a password manager.

I can write my own authenticator implementation in a few hours by hand, maybe 5 minutes vibe coded. https://www.rfc-editor.org/info/rfc6238/

Even if you throw your phone into a volcano and buy a new one, you can still receive SMS verification.

KeePassXC supports passkeys

Passwords can move between walled gardens generally very easily (export) or manually in all cases (enter by hand).

Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.

It's not iCloud Photos, in my case it's Google Photos. But I keep a copy of all my photos in a self-hosted instance of Immich [1], which I then back up to a Hetzner Storage Box using Backrest [2].

So I end up with 3 copies of all my photos, on 3 different providers (I mean... 2 different providers plus my homelab disk).

[1] https://immich.app/ [2] https://github.com/garethgeorge/backrest

I can't understand how such a huge company can have such a lousy UX.

Peak Tech Salesforce was 2010 +/- 2 years - i.e. after Visualforce and before Aura era. It used to be a developer oriented platform and it became shiny/flashy garbage eventually. But all these shiny things allowed them to get a large market cap with very brilliant sales people, it's hard to deny.

VF and Aura overlapped. Aura was just a bad start and janky. We sometimes just did React instead, for a while.

LWC is worlds better. And the local tooling with the cli and VSCode extensions is miles better than the old Eclipse/Sublime FMT days.

Aura existed simply because Salesforce thought to be smarter than open source, well. Can't deny it though: Salesforce engineers were great on the backend, but frontend dev has never been their thing. Back then there was Angular 1 which was miles ahead. React was released shortly after Aura itself, so to say. LWC is what Aura shall have been 10+ years ago. And that ties back to what OP wrote: awful UX extremely slow bloated with JS.

Now, don't talk me about VSCode Extensions. This is the perfect example of an awful dev experience. apex-jorje-lsp.jar with a JVM to parse Apex taking GB of memories, extensions taking dozens of seconds to load (when they load) ... In fact, the only decent LSP is aer, a simple decently working Go binary rather than the monster Salesforce shipped. The one good tooling Salesforce built in the last 15 years is, to some extent, the SF CLI - which came after the `force` CLI from the same guys who built `aer`, anyway. And nowadays, people can use that with their preferred editor from Zed to Vim with shortcuts from built upon the SF CLI.

So no, Salesforce didn't do great with tooling, they just did the bare minimum waiting on the (small) community to give them the right ideas.

Angular and React didn’t solve the same requirements, they were just somewhat workable stand-ins while Aura was jank.

And the tooling is heavy, but I’ll repeat, it’s all miles better than it was back then.

We traded janky and sparse for a full suite of pretty great tooling that can be a resource hog.

Remembering the relative simplicity of the old stuff as “better” overall is just rose-tinted glasses.

aura was open source for a long time. https://github.com/forcedotcom/aura

That's not what I meant. Salesforce had a choice to use (and support) battle tested frameworks, and decided instead to build their own one.

To be fair, they came in with some requirements that I don't think anyone else had at the time, and even today aren't in any mainstream ones afaik.

I think the biggest difference was around providing security and stability barriers between front-end components on the same page, with the intent of allowing you to compose a page that contains your own components and those of other third party applications you've installed with guarantees about how they can (and can't) interact. Not sure they couldn't have tacked that onto another framework, but it comes with enough trade-offs and compromises that I'm not sure anyone else would have wanted to upstream it, so they would have been forking something anyway.

Aura wasn't much fun to work with, was never really feature complete, and not advocating for it... but it actually kind of made sense if you thought about front end with the context of how salesforce did security and multitenancy in mind.

I think around 2012 there was not a lot of options for an enterprise rally around. Aura was designed and built in the same timeframe as react/angular/ember/etc iirc.

Is like Microsoft Windows in that way?

Yes, maybe you're right. Windows used to be good in the 9x era. Then it all went downhill.

>Google is doing everything possible to juice their revenue right now, in ways they've never seen before

My experience confirms this: many years ago I had a website banned from serving Google Ads. They said my pages didn't have enough content.

Then a competitor started showing ads on the exact same type of pages where I had previously been able to serve them. So I tried getting my website approved again and -- surprise -- now I can serve ads again.

Yeah they accept websites without content nowadays, which I think should be the case either way.

What is not okay is them pushing a huge amount of ads into website, constantly asking you to enable auto-ads and vignette ads and what-not.

I am having this issue getting approved, and Google denies me every time. I last tried back in August.

I think it's a very sad state of affairs, but I find even myself trusting the Facebook page more than the actual website for many places, since you can see the latest updates on Facebook (and how recent they are), while the website could be completely outdated with no way to tell it.

I think bigger apps are also slowing down updates to prevent vandalism from appearing to a wide number of users.

The main problem with Google Ads is that Google tries to squeeze money out of you in all possible ways.

I think the only sane way tu run a Google Ads campaign is to:

- only enable Google Search ads (i.e. disable all third-party publishers -- this may be a bit extreme but it's good if you're advertisting a niche product that people are actually searching for)

- only use "exact match" keywords ("broad match" is so broad that Google will show your ads in completely unrelevant SERPs)

- disable AI Max

- disable all automations

- reject any of their "optimization" tips

- set a max CPC even if they say it's bad for you

In other words, reject everything they suggest you to do. Maybe I'm wrong, or maybe this only works for my use case, but that's how I've been using Google Ads succesfully without wasting money.

> only enable Google Search ads

Except then they just don't run your ads unless you're willing to pay silly amounts like $3 per click for bot traffic.

Also: run experiments to find an "optimal" budget with the right size for your target audience. If you, e.g., set a too restrictive geographic rule, but also set a budget higher than what they manage to burn showing your ads at the area you defined, they will override the rules you set up to guarantee 100% of your money will be burnt.

I used to follow him, but then I've read some controversial news about him...

In case people don't know the Google Graveyard: https://killedbygoogle.com/