Could you create a separate account for the tablet without that credit card? Just curious.

What do you use instead? My main reason for using Amazon is the shipping which no one else can come close to

Same or next day shipping on most things I order is wild, when something goes beyond a 2-3 days on Amazon it even feels odd

And the “do you actually need the item/s that fast” isn’t the response I am looking for

Silicon Valley has no concept of consent and boundaries. If computing was a night club, "Silicon Valley" is the guy who goes up to every woman saying "Want to dance? [Yes or Maybe Later]?"

As someone with elderly parents, the Googles and the Microsofts of the world really don't seem to give a shit about the elderly anymore, if they ever did. Random UI updates and workflow changes with no announcements, thinking they're "intuitive."

One of these days the product managers who push these things thinking "oh, it's easy, you just . . ." are either going to be explaining it to confused Mom or Dad, or they're going to be elderly and irritated themselves. Until then I hope they stub their toe or step on random Legos regularly.

It should be but haven’t checked her apple vault. I checked Google password manager and her windows password manager and there nothing in either. She might have used her phone and it’s in her iOS vault which I’ll check next. But this is what makes this entire passkey thing a mess. She’s 75, she didn’t do this on purpose and the ecosystem is just a mess

The same way you share them now: sharing the account name and password and doing whatever you currently do to deal with any 2FA they occasionally toss in.

If they also allow passkeys as an alternative form of login that doesn't need 2FA you can use those to make the account sharing more secure.

When setting up sharing with someone first change the password to something else, and then share the account name and password. After they log in the can add a passkey to the account on their device or devices.

Then you can change the password back to your real password. When they want to use the account they login with their passkey.

If the service doesn't accept login passkeys but does allows passkeys for 2FA, you have to use real password sharing, but at least they can have a passkey for 2FA which may be easier than how you know handle 2FA.

How do people handle 2FA with account sharing? If the site uses TOTP you can give them the QR code that you received back when you made the account (you do save a screenshot of such QR codes for backup, right?).

But how do you handle SMS 2FA, which seems to be far more commonly offered than TOTP?

For email 2FA I suppose you could set up a filter on your incoming mail that forwards any incoming code emails to the people you shared with, and hope that the time limit on the code is long enough for this to work.

In general you shouldn’t - Netflix[0] really should get proper invite-based family sharing, and Spotify’s subscriber agreement has a section that defines Premium as a “Single-user Paid Subscription” and thus can’t be used by multiple people, legally (and you might be at risk of getting banned if they detect it)

However, passkeys can and are available to be shared via password managers. They’re not locked to the secure chip on the device where they live usually. iOS’ Passwords app has a share button and 1Password lets you share passkey-containing items.

In fact, the QR code login feature makes it even easier to do a one-time sign in to your account for a friend, if you don’t want them to be able to login to your account indefinitely.

0: Netflix doesn’t support passkeys because their main audience is people signing in via smart TVs and whatnot, which largely don’t support CTAP or Webauthn in general)

The website should display a qr code you can scan with your phone that allows you to then login, unfortunately a lot of sites don't implement this, and some don't implement backup codes. This isn't the fault of passkeys per se, but of poor implementations.

Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.

My suggestion would be to not do that. But keep a password and an offline TOTP app if you must. It’s still an option.

While we're at it, the insanity of those "recovery questions", made even worse when many companies demand the same ones.

The problem with hardware tokens is that they 1) Only store a limited number of logins, 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss

This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).

The problem isn't the cost of replacing it, the problem is - how do you log in when all your passkey-bearing devices just got flushed down the toilet?

Enrolling two devices stored in different locations for every sign up is extremely annoying.

I suspect that most people that ostensibly do this actually only enroll one for non-critical accounts and then depend on some fallback mechanism.

What services implement it like this? Don't services usually implement passkeys as a more secure alternative to a password, but password login is still available?

Some sites allow passkeys as an option for MFA, so that could be an issue if the passkey is your only MFA option and MFA is required. But I imagine email would pretty much always be a fallback.

> Isn't there a workflow where you scan a QR code to confirm the pass key on your phone?

For people in this position, if they had their phone, they probably wouldn't be logging in on a computer anyway.

This is what I use to log into our remote desktop software at work. The passkey is on my phone and I scan a QR code presented by the remote desktop software (in this case it's the Windows App on my macbook and Microsoft Authenticator on my android).

There is. Doesn't work on every browser but it's really nice and I use it routinely.

Many people are moving to only a single portable device that’s easily lost, broken, or stolen, without any understanding of backups or fallbacks for their accounts.

And many are moving to virtual wallets like Cashapp rather than banks with a physical presence where you can take out money without a phone.

It’s a bad situation.

If the user just has a username/password fallback and that's it, then yes, but the aim of passkeys is that won't be the norm, rather users will only have passkeys and the fallback would be to, e.g: magic link email log in where the phishing attack is still broken. I've seen some sites explicitly disallow plain username/password login after you enable passkeys for this reason (you can still put them in, but then it just does a magic link flow afterwards as a second factor).

The pitch is that passwords will supposedly be phased out entirely as an option.

Loads of hosting sites do this, username.domain.tld is the most common one.

Your last sentence got me good, as I'm a developer who copy-pastes passwords into websites (from a 12? year old KeePass database, for whatever that's worth).

I've tried using the Firefox integration in the past - more than once - and I don't know... it had so many warts that I got fed up with it and turned it off. And now I have 1Password (from work) also doing its best to feed me credentials all the time. So trying the KeePass integration again is going to have them both drawing suggestion dropdowns all the time..

But ok, I'll give it another honest shot. Because of your comment.

There are too many websites where this is broken for me (even with Firefox's built-in password fill) to go as far as to never copy-paste passwords. If web devs actually implemented it consistently, I might be that draconian about it, but asking them to do that when we already have the '200 MB of JS is needed to view this page' problem, I have my doubts we're going to see this problem going away any time soon.

It should be a big red flag for sure, but the reality is most users aren't going to understand that. They got told to use a password manager by someone or find it convenient, but they don't understand the security flow enough to catch that it's a potential attack, or how to resolve it safely.

Historically I've seen lots of sites do a subdomain shuffle for login pages every now and then which routinely breaks domain matching, introducing false positives that users have to deal with, making them numb to the threat too. Passkeys baking in the domain check with no workaround means that sites can't do that, which is a benefit.

You don't. The browser handles the passkey matching to the domain which is obviously a better place to do it. There could obviously still be bugs as with all things, but it's much more intentionally integrated into the flow which makes it much harder to bypass.

The users are the ones manually copy/pasting the password. There's no way the password manager could prevent this short of disallowing copying/viewing passwords.

The password integration breaks because it's trying to detect password fields rather and failing because of weird HTML/JS code.

The passkey integration goes the other way, which is much more reliable.

> Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?

Gell-Mann amnesia effect

https://en.wikipedia.org/wiki/Michael_Crichton#%22Gell-Mann_...

Peace of mind is a luxury good

I’m a big dummy who commented before reading the article, this is actually called out there

> The last option is to use “Hybrid Transport”, where you scan a QR code and connect via Bluetooth simultaneously to the computer. Whilst this option is secure and works in theory, reality is plagued with edge-cases where connections fail or Bluetooth is straight-up unsupported.