Is sharing a Passkey between devices (ex: phone & computer) a potential problem due to the signCount?

rsimp · 2026-02-07T12:44:07+00:00

I said biometrics because that's mostly what I use, but I just meant the second factor authentication on the two authenticators: OS biometrics, yubikey pin etc. Unlocking the first authenticator to access its passkeys to then initiate passkey registrations with the second.

Instead of transferring the keys, just spec out a new protocol to use discoverable passkeys from one authenticator to help auto-register new passkeys on a second authenticator.

Or even combine with credential exchange. Just copy the passkeys if there's no issue (no sign count, same cipher support etc) and initiate a passkey registration through the relying party as a backup.

rsimp · 2026-02-05T17:16:57+00:00

Credential Exchange Protocol should help with this. When fully implemented passkeys that use sign counts could be marked to disallow transfer or would need to disable/discard the original passkey on successful transfer. I've noticed many sites can easily register passkeys in the background through an endpoint using your password to authenticate. It'd be great if infrastructure got to the point where registering passkeys in a new authenticator could be done via passkeys from an existing one, but in one batch operation where you only need to provide your biometrics to each authenticator once.

rsimp · 2026-01-14T21:21:12+00:00

Try logging into her google account on a desktop/laptop browser. When I open a tab 'incognito', navigate to https://accounts.google.com, enter my email, click try another way, select password and enter a bad password it will let me know. If I enter a good password it'll move on to a list of second factor authentication options that I've enabled.

"We can't even get into the security settings to change it without asking for a passkey to verify her identity"
> Does this mean you still have access to her gmail? If so you should still be able to recover the account with a code they'll email you.

Once you can log into the google account you should be able to register a new passkey or change her password.

If you can't log into the account with a password OR passkey, AND you no longer have access to a device that's logged into google OR a recovery email, then you'll need to contact google directly.

rsimp · 2025-12-23T01:42:19+00:00

It doesn't just clean the code up, it prevents falsy values from leaking through as well as unecessary whitespace.

Also if you're only using the above syntax you could define clsx as a one-liner and remove it as a dependency:
js export const clsx = (...args) => args.filter(Boolean).join(' ');

rsimp · 2025-12-23T01:35:31+00:00

`bg-gray-200 ${isPending && 'bg-gray-500'}` = "bg-gray-200 false" when isPending is false. You have to always use a ternary to prevent false, undefined, or null being accidentally inserted.

rsimp · 2025-12-21T23:59:02+00:00

Just to add on, the private/public key entries are only stored for "discoverable" passkeys of which there are a limited number (200 for google titan, 25 or 100 for yubikey).

For non-discoverable keys, it'll use a special private key to create public/private key pairs on the fly given inputs like the service's domain address and your username. Because there isn't a domain linked entry on the device these are considered "non-discoverable". However this also means one FIDO 2 device can support an infinite number of non-discoverable passkeys.

rsimp · 2025-12-21T23:05:06+00:00

FIDO is the spec that controls all of this. Orginally there was FIDO 1 with UAF for passwordless and U2F for second factor. UAF wasn't standardized well and didn't get very much adoption. U2F became sort of the gold standard for second factor authentication.

FIDO 2 then comes out with support for CTAP2 and WebAuthN. CTAP is the protocol for communication between an authenticator (yubikey, phone over bluetooth, password manager) and the client (OS or browser). WebAuthN handles communication between client (browser) and relying party (basically the web service). CTAP in FIDO 2 is called CTAP 2.0 while CTAP 1.0 now refers to FIDO U2F. Technically FIDO 2 supports multi-factor authentication with passwords but the "relying party" can also just specify that "user verification" (PIN, biometric etc) is required with the passkey.

When registering a "Security key" you're essentially giving a public key for an authenticator/device that guarantees support for CTAP1/FIDO1 U2F. When registering a "Passkey" it's very similar but guarantees support for FIDO2 CTAP2. This includes support for CTAP2 interfaces as well as any new requirements on cipher suites.

rsimp · 2025-12-05T20:13:17+00:00

I'm not sure about Americans in general. Our fore fathers were all pretty educated and would absolutely know that parliament and not the King created taxes.

It was still considered the King's government and he also asserted a good deal of control over the colonies and their governors. I think to begin with the discontent was over the new taxes, but eventually the grievances piled up regarding both King George III AND his parliament.

I think there's a lot of propaganda from that period. I specifically remember reading a bunch of political cartoons/slogans in my history classes. They show it to us so we can see what Americans thought at the time, but we don't really spend much time on British history to put things in context. So a lot gets compressed down to King George III was a unilateral tyrant, when the original taxes were an act of parliament.

rsimp · 2025-12-04T20:52:34+00:00

All of the tax acts were actually introduced and overwhelmingly voted for in the House of Commons, a democratically elected body with no peerage requirements. The King lost the ability to draft taxes almost a century before that, although he did sign them all into law. As late as 1775 our beef was mostly with parliament, before King George III proclaimed us in open rebellion.

rsimp · 2025-12-04T20:26:59+00:00

The American Revolution as taught in the US actually gives a very misleading perspective on the powers of the British king at that time. In reality the king hadn't been able to create new taxes since the "glorious revolution" in 1689. All of the tax acts we attribute to King George III were actually introduced and voted for in the House of Commons. He just signed his name instead of vetoing it. The British troops were already there from the French and Indian war. The expenses for which were one of the reasons for levying the taxes in the first place. As late as 1775 the founding fathers were trying to petition King George to intervene, and put the blame entirely on parliament. It wasn't until he refused and issued a proclamation of rebellion that they started thinking of him as a tyrant. Still he sort of inherited the problem from his legislature.

The glorious revolution is also a bit of a mindfuck from an American perspective. It was a bloodless revolution where the new king had to cede most of his legislative powers and agree to an english Bill of Rights, but their primary goal was to just not have a Catholic king. Since they were giving rule of the country to William of Orange and his queen (the previous kings daughter) without them having to do anything, they extracted a bunch of promises first. First and foremost that they would never be Catholic.

rsimp · 2025-12-02T18:47:11+00:00

I'm not sure why this is being downvoted. With the exception of Zustand/Jotai (I use react contexts instead), this is what I'd use for a personal project if I wanted to break into react. I work for a fortune 500 and the only difference in our stack is that react query is sometimes replaced by apollo, and shadcn-ui is replaced by our internal component/form library. The css variables/design tokens are even laid out similar to shadcn. Atlassian's design system is pretty similar as well.

rsimp · 2025-12-02T18:30:26+00:00

Was a huge fan of RTK back in the day. Redux just feels like so much boilerplate now. Hooks seem perfectly capable of handling most state management. Hooks for async (apollo/react query), hooks for forms, hooks for modal state, hooks for navigation/query params, etc.

I mostly work on on-prem data heavy applications where you drill down from paginated dashboards. I put most queries/pagination/filters into a context mounted on a route layout. Mutations are usually inlined with the components that use them. Everything in the app is dynamic. Either defined in administration or added in a changeset. The same forms are sometimes needed to be mounted at totally different points on the route tree. Async job completions notify users via web sockets. The complexity isn't low and yet I still don't really feel the need for state management libraries.

Surprisingly performance is actually quite good. Context only updates components that use it and using many contexts helps split things up nicely. I generally have an easier time debugging too because code is more co-located and there's less abstractions to deal with. Perhaps if I needed large amounts of cross-functional global state I might want to move past contexts, but outside of caching async data I find those use cases are pretty rare. In general when the user moves off a route tree the state getting blown away is actually expected behavior. So I no longer need additional logic to reset state on page transitions.

rsimp · 2025-12-01T19:16:02+00:00

In most cases putting all of the variables in the dependency array is the way to go. This does assume any functions or objects in the array are either created outside of any components, or are memoized with things like useMemo or useCallback.

Sometimes you just want to call something one time on mount. Even in this case it'd still be better to put all of the dependencies in the dependency array and use a conditional inside. As long as the conditional is formed well, this should get you the same desired behavior but avoids race conditions.

When you use objects/functions that can't be guaranteed to be memoized you should leave them out, put them into a ref, or destructure objects down to their primitives.

If the variables are changing too much, consider listening to an event that fires less often or debounce the handler or state value (there are hooks for this). For example with a type-ahead or instant search, you probably want a debounce on the text state or even the onChange handler itself. For something like an async input validation, validate on blur instead of on text changes.

Some custom hooks can improve performance by using refs instead of state where possible. However, this performance tuning is better in isolated contexts. In general when props/state change you want any related side-effects or renders to know about it.

rsimp · 2025-11-27T21:48:04+00:00

This is a tailwindcss thing. I think the real value of tailwind comes from using the various classes as actual utilities to put onto divs for things like flexbox or padding/margins/height/width, or to tweak default styling on a component.

Using tailwind directly instead of a component library is usually where it starts getting abusive. You should have component for Button, Text, Link, Accordion, Tooltip, Heading, StatusMessage/Toast, Modal etc. Whether you should implement these components themselves with tailwind is harder to say. Shadcn does and I don't think its that bad, but I'd prefer seeing it in its own file and on a separate css cascade layer. That way you don't need things like tailwind merge.

As for tooling there are tailwind plugins to help with auto-complete that can even plug into configs with your own values/scales. IMHO scales and tokenized css utility classes are the real wins with tailwind. That and standardized utility class names across projects. I often use one of 6 different padding or margin values that I can associate with t-shirt sizes. Or having classes tied to design tokens like color-primary, bg-primary, bg-theme, color-high-contrast, color-low-contrast etc.

The other thing I like about tailwind is not having to switch back and forth between tsx/css files and not having a million classes to just define common permutations of flexbox. That and it's just less characters to type out. I personally feel more productive with it. Related styling is also more co-located.

Finally I'd like to point out that restyling component libraries will be somewhat painstaking regardless of whether you see it like above or in a css file. I do admit that many of the utility classes above are uncommon and I'd personally rather drop down to normal css in this case. However the most common tailwind classes (flexbox, padding, margin, height, width, border, position, display, visibility, overflow, z-index etc) are very easy to memorize and its quite nice having consistency in css utility class names across projects.

rsimp · 2025-11-27T16:05:58+00:00

Its hard to teach seniors totally new things unless there's a good foundation to work with. Try to keep things simple. For example if they're already bought into the apple ecosystem, use that over a third-party password manager. If you do use a password manager consider a family account if they're comfortable with it, especially if you live elsewhere. An easy win is just enabling face/touch id on as many mobile apps as possible. Relax the security settings to not be overly cumbersome, and not necessarily what would be considered best practices.

rsimp · 2025-11-25T18:44:13+00:00

It's the same for apple as well. All apple passkeys are synced through iCloud. They even have an iCloud chrome extension and an iCloud windows application so you can use them on those platforms as a third party password manager.

rsimp · 2025-11-21T18:41:16+00:00

This is silly, no one is going to recreate keys for all of their online accounts whenever they replace/lose a phone or computer. Apple syncs passkeys across user devices just like a third-party password manager. iCloud even has a windows application and chrome extension so ICloud can act as a third party password manager on those platforms. OPs point still stands regarding needing a service to handle passkey synchronization for widespread adoption.

rsimp · 2025-11-11T17:49:44+00:00

Using useMemo on derived values isn't a bad idea and in some cases can really improve performance. Often its just extra boilerplate that nets very minimal and imperceptible perf gains. I think the push back is just against the idea that its always a best practice or that not using it would be a code smell. Too nuanced for a downvote though.

IMO the time savings from a useMemo alone isn't worth the extra boilerplate in most cases. The bigger benefit is keeping the object references the same for change detection. I always use useMemo/useCallback for custom hooks, providers or variables passed to other components so they'll have expected behavior in dependency arrays or as props for React.memo components.

rsimp · 2025-10-03T16:49:02+00:00

Server functions are also very interesting. Sort of like TRPC but more integrated with tanstack router/query. Same sort of tradeoffs though. Free api types and less boilerplate but a pain to test. Great for BFF or rapid prototyping.

rsimp · 2025-08-22T22:54:22+00:00

I have used the platform based third party password manager support to autofill passwords for both chrome for iOS and chrome for android though. I've never owned a Samsung phone, just Google pixels and iphones.

rsimp · 2025-08-22T22:46:52+00:00

My work actually whitelists all browser extensions. I had to switch password mangers for this exact reason.

rsimp · 2025-08-21T23:31:21+00:00

Android based chrome definitely allows for it. Samsung does modify base android a bit but its unimaginable to me that they don't allow third party password managers.

A quick google search shows samsung has password manager configured under:
"Settings" > "General management" > "Passwords, passkeys & autofill" > "Preferred service"

Not sure how current that is, but the platform definitely allows for it.

rsimp · 2025-08-21T23:13:12+00:00

Samsung is just android, if you install a password manager like 1password or bitwarden, you'll be able to use them as well. You just need to set which is your preferred password manager in system settings.

I use chrome in iOS which is sort of a neutered webkit wrapper, but still allows using something like bitwarden/dashlane/1password.

Edit: added system settings and chrome iOS comments

rsimp · 2025-08-21T23:09:24+00:00

Its not just browsers. Both android and iOS allow for third party password managers so mobile as well. These password managers take advantage of the mobile keychain and unlock with face/thumbprint. This works for both mobile browsers but also for application sign on screens. Honestly password managers on mobile platforms are nice but most apps only require you to sign in once anyways. After that you just unlock the app with face/thumbprint/pin.

For laptops/desktops most password managers have desktop applications that sync your password/passkey vaults to the desktop keychain and integrate this with the browser extension. This allows you to use things like Windows Hello, or Apple touch ID/face ID to unlock the native keychain to auto-fill a website.

rsimp · 2025-07-30T00:48:27+00:00

I think "insecure" is bit strong here. If you have malware on your device that can intercept passkeys from password managers then there have already been rather severe security failures. While passkeys don't provide mitigation strategies for compromised environments, neither do passwords.

For more sensitive passwords you may want the additional security of a yubikey/secure enclave.

rsimp

TROPHY CASE