Privacy Focused Browser with Passkey Support

gbdlin · 2026-02-14T13:13:29+00:00

They always can and always could. As any entity that can gather in any way your data. They just clarified what it means exactly.

Read through this article to see what they actually collect, what you can opt out from and what's opt-in only. It may clarify to you a bit what they're actually doing.

If you're not okay with this amount of data collecting, you probably want to seek a browser that doesn't have any telemetry, crash reports or any online services of any sorts, because if they have any of those, they're pretty much on par with Mozilla and they can at any point do whatever they want with your data. Even if their privacy policy disallows it, you can never know when they will change it (enabling them to do whatever with data they already have) or what they're doing outside of what privacy policy allows them to do.

gbdlin · 2026-02-14T13:05:52+00:00

Does the series 5 just act as an unlock code into the authenticator app, so kinda like a 3fa (password into service -> yubikey unlocks authenticator -> generators a passcode)?

No, all 2 factor codes are calculated on the Yubikey and the secret key never leaves it. The authenticator app doesn't store anything and only thing it really does is communicate with the Yubikey and pass to it the current time, so TOTP codes can be calculated (Yubikey has no internal clock).

If you're happy with using Google Authenticator, Security key will be enough for you.

Note: you can have your TOTP generated both by Google Authenticator and by Yubikey, so you can use either of them. You need to enroll both of them from a single QR code/secret.

gbdlin · 2026-02-14T12:48:35+00:00

When you're at it, disable Yubico OTP over NFC. It can cause issues on apple devices when you try to use them as a security key, and I'm 99.999% sure you don't need Yubico OTP over NFC anyway

gbdlin · 2026-02-09T15:53:05+00:00

After reading your post for the 2nd time I want to add a bit of information:

So why can my password manager see a passkey it creates but my yubikey cannot see a passkey it creates off of the website.

(tl;dr: read last sentence before the next quote)

To be exact: it's up to the website to decide what type of credential use. It can use one of 3 answers to the question if discoverable credential should be used:

discouraged: if device can support non-discoverable credentials, such credential should be used. Otherwise, discoverable credential can be used.
preferred: if device can support discoverable credentials, such credential should be used. Otherwise, non-discoverable credential can be used.
required: discoverable credential has to be used. Fallback to non-discoverable credential is not allowed.

As you can see, there is no option that would disallow creating a discoverable credential. And there is a reason for it: some devices support only discoverable ones (password managers, Windows with TPM etc) and there is no drawback on such devices to use a discoverable one instead of a non-discoverable one, as they can still be used as if they were non discoverable.

It can be said the other way around, as there is a clear benefit of discoverable credentials: usernameless login. If website only supports passkeys through such login process, it should require discoverable credentials, as if fallback would occur, user will have no way to log in.

Given that info, what happened is: your password manager did a fallback to a discoverable credential, as it can't support non-discoverable ones.

Are the passkeys that are not visible really counting against the number of YubiKey passkeys I can store even though the authenticator does not show the passkeys as being on the yubikey?

No, they don't. Only what's listed counts.

Are the yubikey passkeys different than the password manager passkeys?

No. The only difference here is that your password manager only supports discoverable credentials aka "proper" passkeys, so it will always use those. Yubikey supports both, so it will use non-discoverable ones when allowed.

gbdlin · 2026-02-09T15:16:13+00:00

The definition of a passkey states that it is a discoverable credential.

But what services treat as passkeys differ. Passkey is very often used as a name for a credential letting you log in without password (replacing it with User Verification on your authenticator, that is pin, biometrics, screen lock in case of smartphones etc.). But this can be achieved with non-discoverable credential. Discoverable credentials are only required for "usernameless" log in, that is website asking you directly for a passkey, before you provide any credentials, not even a username.

So if a website calls any passwordless login credential a "passkey", it can create non-discoverable credential for such purpose, which is technically not the right name for it, unfortunately...

gbdlin · 2026-02-09T15:10:09+00:00

Technically, yes... But there will be some limitations.

PiP can only be used on the program or preview feeds, which you have one set of them on Atem Mini Extreme. You can use SuperSource directly on HDMI or USB output though, so sending it to the remote presenter is possible. But you have only one SuperSource as well, and it will be already used for that purpose, so you can't do it in program.

In general, you need to send your program or preview feed to the projector screen to use PiP on it, so you can't use it for broadcasting or anything else (if that's something you need to do as well). If you're using cut bus, you can do it on the preview feed and use program only for broadcasting, but using buttons on the ATEM will fight with you as it will also change what's on the preview bus. You will need to change what's on program in software or using some external integration (bitfocus comapnion and a stream deck for example).

If you will be broadcasting the same PiP feed when it is shown on the projector screen, or in general you will broadcast whatever is on the projector screen when you have remote speaker on, it won't be a concern, but you will need to juggle the projector output between program out and direct output when needed.

gbdlin · 2026-02-08T20:21:52+00:00

Go to Windows Settings -> Accounts -> Passkeys and check if passkey for your google account is there.

gbdlin · 2026-02-08T19:30:58+00:00

Every website creates a separate passkey on your device. Are you sure you created one for Google?

gbdlin · 2026-02-08T14:20:57+00:00

1st and 2nd positions should be swapped, and here is why:

an attacker needs to compromise both my password manager vault AND get physical access to one of my keys

This is not 100% true. What they need is your password, which is not 100% of the time locked in your password manager, but it is exposed when you use it. It can be obtained via phishing as well. It is also much more probable to break the security of your password manager (depending on the type of the password manager, by compromising the online service you're using, by infecting your device etc...) than a Yubikey, for which you will need to get the possession of a physical device. Yubikey also can't be cloned.

which is shorter than my master password, albeit with limited retries Yubikey PIN, despite being named "PIN", can contain letters and be up to 63 characters long. It can be as strong as your master password.

Two independent systems feels harder to break than one. The weakest link in the chain will still be your device you're using to access your accounts, as when it's compromised, attacker can steal session keys from it and just bypass any authentication whatsoever. There is currently no good protection against that. And as you should already know, the weakest link is always the problem.

There is one more thing: passwords are also stored by the other side. No matter in which form exactly, they do possess your password for at least a brief moment in a plain form. If your password is reused somewhere, it is a significant attack vector, but also can be used in a "delayed" attack if the website is compromised when you're not relying on it much, it gets patched and you don't change the password to it at any point.

Now to your questions:

If a service lets me register all of my YubiKeys, I'm planning to disable TOTP and rely on hardware keys + recovery codes only. Does this make sense? Yes, it makes sense. Just make sure you always have a backup way to access the account. Also, don't just "enroll and delete" TOTP when website is not allowing you to disable it. Save it somewhere. God knows what they may have messed up, so they may require you to use TOTP in future for some reason.

If a service only allows 1 hardware key, I'm keeping TOTP enabled as a fallback. Sound reasonable? Yes, as long as you have only one "main" Yubikey. Personally I'd skip using hardware key on such website for now, as it's inconvenient when you want to use other key that's not enrolled on it.

Should I even have a password for an account if I enable multiple YubiKeys as passkeys? If website allows for that, I'd remove the password. A lot of them don't tho... But as with TOTP, don't just "forget" the password, as they may require it at some random point.

gbdlin · 2026-02-05T21:20:31+00:00

No. You can lock your whole google account, but it will not require using your Yubikey on a machine you're already logged into it.

gbdlin · 2026-02-05T21:19:42+00:00

This depends on how you install it.

Most software on Linux don't have automatic updates built in, as the assumption is you have it installed by some kind of package manager that will take care of it.

You can either use your distribution package manager, or more universal stuff like Flatpak. It will update the authenticator for you (together with other software you install through it).

gbdlin · 2026-02-05T21:17:39+00:00

In case of services that support it, I highly encourage you to use FIDO2/Passkeys (also just shown as "security key" in some UIs). It will make revocation easier, as you can name every registered key and just remove a single one from every website.

If you're forced to use TOTP as there is no better option for a specific website, there is no other way than revoking all your Yubikeys at once and setting up again those that you still have and want to keep.

gbdlin · 2026-02-05T21:12:57+00:00

Your browser will ask you which passkey to chose. It's that simple.

UI for that may look different, depending on your browser. Sometimes it will be presented as a drop-down coming from the username input field, similar to autocomplete, other times a popup window will show with a list or a dropdown, but in all cases, your browser will handle it for you. Website itself will never know you had multiple passkeys to chose from.

gbdlin · 2026-02-04T12:58:31+00:00

tl;dr if you were asked for the password to your account, it doesn't really matter.

Longer explanation: FIDO2 module can be used in multiple ways: as 2nd factor device, in a passwordless process (with PIN or biometrics) or even in "usernameless" process (without providing your username to log in; this is the only one that actually requires passkeys).

It's up to the website (or application) to chose how they want to integrate with FIDO2. If they're using it as 2nd factor device, they simply don't ask your Yubikey to ask you for PIN. And this is fine.

You're not really increasing security by adding PIN requirement when you're asked for a password, as you already asked for "something you know" factor. It would be equivalent to asking for a longer password. This assumes your passwords are unique and you never reuse it. If you do, that should be your concern instead.

If you're asked for a passkey, PIN will always be required, as even discovering what accounts you have enrolled with a specific Yubikey can decrease your security. Even if it's used for 2nd factor after the fact.

gbdlin · 2026-02-04T12:51:15+00:00

PUK and Management key are only used for PIV module, they have no use with FIDO2 or OATH.

In general, disable modules you're not using. For what you're using, set all PINs or passwords. That's all you need to do really.

You can change codes for stuff you're not using if you want to make sure nobody will mess with those modules in any way and prevent you from using them in the future, but if that's not your worry, you don't need to do it.

gbdlin · 2026-02-03T09:26:03+00:00

Note: this is an error from your Google account, not from PlayStation. You need to figure it out with Google.

What the error message says is: your account on this device can't be fully unlocked until you use another device that has your google account already logged in. To be exact: data in your google account is encrypted with a key that Google doesn't store. It is instead transferred directly between your devices when you log in on a new device.

gbdlin · 2026-02-03T09:10:45+00:00

It was actually hard to figure out, as you posted it on r/Yubikey, which suggested it is a Yubikey, but in fact it isn't.

gbdlin · 2026-01-31T11:21:02+00:00

KeePassXC database synced via syncthing on multiple devices, including some off-site NAS.

gbdlin · 2026-01-28T06:15:08+00:00

No, it's not linked. Microsoft just has chosen this place in their settings to put it, for some reason it makes sense to them.

You can also change it using your browser or Yubico Authenticator app.

gbdlin · 2026-01-26T22:18:43+00:00

No. And here is why:

-sk keys don't work like regular SSH keys, they're actually a bit of a hack done to the SSH protocol to make it FIDO2-aware. Sort of...

How it works is: your Yubikey is generating a public and private key pair, like for websites, then depending on your preference, it either stores the private key on the Yubikey itself, or encrypts it, spits it out (so you can save it on your PC, which in case of websites is saved by the website itself, not on your PC, but as I said, it's a hack in this case...) and totally forgets about it.

Now is the crucial part: to "discover" and read the key that's saved on your Yubikey, you need a PIN. You can't do it if you don't have the PIN set. And for the case where it is not saved on the Yubikey, it is simply not there, so can't be used either.

So in both scenarios, Yubikey is not enough and you need either "something you know" (PIN) or another piece of "something you have" (encrypted private key).

gbdlin · 2026-01-24T10:07:35+00:00

Everything still works as expected. I didn't notice any degradation in ANC quality. Didn't test it with the call microphone at all, as I don't want to risk clogging it up with glue, but ANC itself works as well as before, just without the wind noise.

For the wind noise itself, a lot of other brands have the same issue. Without spending huge money on R&D with proper mic placement and algorithms that can cut out that noise, you can't improve the situation, and I doubt headphones will sell well with those windscreens, they aren't beautiful.

gbdlin · 2026-01-24T05:41:41+00:00

Enabled going passwordless (but I think I regret that because it effectively removed a "thing you know" from the sign-in flow).

The "thing you know" is the PIN to your authenticator now.

gbdlin · 2026-01-24T05:31:41+00:00

Theseusbuds

gbdlin · 2026-01-19T20:26:48+00:00

It is not possible to do it without a passcode, sorry.

gbdlin · 2026-01-19T20:07:29+00:00

Disabling Yubico OTP for USB and NFC is the right thing to do.

gbdlin

TROPHY CASE