How is that different from accidentally deleting your keepass database? Or forgetting your password? I think it’d be easier for me to forget than find myself trying to flush all my hw tokens…
Same way. A majority generally have a old phone that was already signed in to google. Or if they remember only Apple ID and password (one very difficult password) + sms. They can login on to a new phone.
Everything is SYNCED immediately.
What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.
I can get another hw key (if one of mine breaks, which I, surprisingly enough, have not yet managed to achieve)
And since I have at least two at all times, the possibility of one of them breaking changes… not much really.
Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…
There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.
I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.
> Also... Is flushing your whole keys down the toilet a problem you run into often?
It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.
House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.
Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.
TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.
Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.
I think it depends on the context? It's in an ID card's design goals to be provably valid, so it's pointless to not publish its public keys, but something like SSH pubkeys, uhh, should I really be so eager to just publicly dump all of mine…?
The only downside I see with publishing ssh public keys is:
- If you install such keys to a host, and an attacker (with access to said host) has catalogued your ssh keys, they can see that you have access to said host (if they can correlate your method of publishing the keys to your identity)
On the other hand, if you go to the other extreme (?), you can have a different public ssh key per host. This way the server owner/attacker is not able to correlate that ssh key with other keys to recover your identity. (You need to take care that ssh won't offer too many public keys in that case.) Example case of a service that might get offered many ssh keys: github.
Personally I don't bother. But I wouldn't be too bothered about just putting my public keys to some "secret" URL in the internet either, so I can easily enable myself ssh access to a host with a single curl.. Maybe I should indeed do that.
The choice to have different keys everywhere is key to how the dumbest Security Keys work and thus ensures that two parties who trust "you" don't have (from this at least) a way to correlate your identity.
A single Security Key can authenticate to Facebook as WeedLover420 and then be used to sign into the Google account of the Secretary of the US Marijuana Task Force and even if both Facebook and Google were co-operating in the work there's no way to connect these authentications. Obviously WeedLover420 is more likely to get caught because they used the same IP address to do both things and they stink of weed and they look stoned all the time, but none of those are because of the Security Key, that was locked down good.
Switching from Android style Linux HAL to FreeDesktop style Linux HAL… I honestly think we need more Linux HAL options than just those two, when one is threatening to self-destruct and the other is arguably the single worst interface design ever conceived, by all measurements.
Can you expand on this? I did follow the “Moblin/Maemo/MeeGo” forks back in the day and it struck me as odd Android pulled off the HAL layer but “Linux” was unable to.
Every [Linux based] OS usually needs some sort of HAL to wrap [ioctl] driver calls into APIs that can be consumed by more than one process at a time. Nokia/Moblin/Sailfish use Freedesktop style HALs, i.e. stuff like Wayland, Pipewire, anything accessible over DBus (which also implies extremely slow IPC by any standards; mach ipc on apple's darwins is probably faster [sobs]).
Basically I'm suggesting that we might need a whole new OS on top of the Linux kernel.
Nah, DBus itself is plain bad interface design. Perhaps they could just piggyback off Binder if DBus itself weren't beyond saving. Also, despite a common sentiment online, it's not at all a complex process to implement a Binder userspace (given you have a sensible IDL in the first place, that is…)
Wrt/ torvie's narcissistic snarks linked above, the most important task for a kernel is still to facilitate fast IPC. The only viable forms of IPC in Linux are UDS and Binder. The former is slow and clunky. The latter is not a valid choice for DBus. So DBus devs have to manage slow, clunky, ill-suited legacy IPC. When a kernel can't be bothered to accommodate one of the most important operating systems built upon it, that seems really bad.
Nvidia GPUs refuse to accelerate 3D w/o an output connected; if I had a Radeon, I wouldn't need the plug, it's just an Nvidia thing I believe.
Afaict, Moonshine relies on a separate graphical session running on your monitor and that's how it gets around that limitation of Nvidia GPUs. If I had a monitor plugged in to my box, Sunshine would work just as well.
It’s possible to make a fake display to avoid that; both Linux and Windows have this ability. No dummy plug is required (though it is simpler than software solutions).
I don't use the dummy plug for display, it's only that consumer nvidia gpus won't have working 3D acceleration if there is nothing physically connected to the card. My dummy plug doesn't support the resolutions I run games at anyway.
EDIT: Ok, correction, I bothered to go unplug the dummy plug and it still works. So I was wrong, Sunshine does not need a dummy plug at all, not even on Nvidia. Now it remains a mystery why I have one in the first place if it's useless after all…
Sunshine was significantly easier for me to get working using a dummy plug. I'm currently exploring other options but that's definitely the happy path.
Now you try working with a fake in your head's place! :þ
But yeah, real head (a monitor; doesn't have to be on) also works just as well, and even no head at all works, just won't accelerate 3D. Arbitrary resolutions also work.
My only complaint with sunshine is that the webui authentication is really broken. Fortunately I don't need to go there much.
Wow, Firefox never fully loads the page, while WebKit fails to load it altogether, instead it displays "Operation was cancelled" in system font after a short freeze. I didn't manage to see the images change in any way as the post would suggest though, which left me confused.
I thought I'm the hardest to impress gremlin out there, but despite what the comments here look like, this is the best looking and practical MD3 CSS I've seen to the time. Not fond of promoting ethanol consumption though.
reply