←back to thread

2071 points K0nserv | 1 comments | | HN request time: 0s | source
Show context
zmmmmm ◴[] No.45088995[source]
> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware

It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your own operating system because it's not in Netflix's financial interest for you to do so. Or your banks, or your government. They all benefit from you not having control, so you can't.

This is why it's so important to defend the real principles here not just the technical artefacts of them. Netflix shouldn't be able to insist on a particular type of DRM for me to receive their service. Governments shouldn't be able to prevent me from end to end encrypting things. I should be able to opt into all this if I want more security, but it can't be mandatory. However all of these things are not technical, they are principles and rights that we have to argue for.

replies(38): >>45089166 #>>45089202 #>>45089284 #>>45089333 #>>45089427 #>>45089429 #>>45089435 #>>45089489 #>>45089510 #>>45089540 #>>45089671 #>>45089713 #>>45089774 #>>45089807 #>>45089822 #>>45089863 #>>45089898 #>>45089923 #>>45089969 #>>45090089 #>>45090324 #>>45090433 #>>45090512 #>>45090536 #>>45090578 #>>45090671 #>>45090714 #>>45090902 #>>45090919 #>>45091186 #>>45091432 #>>45091515 #>>45091629 #>>45091710 #>>45092238 #>>45092325 #>>45092412 #>>45092773 #
JeremyNT ◴[] No.45089284[source]
This is the crux of the matter.

Maybe conceptually you will be able to run some kind of open operating system with your own code, but it will be unable to access software or services provided by corporate or governmental entities.

This has been obvious for some time, and as soon as passkeys started popping up the endgame became clear.

Pleading to the government definitely can't save us now though, because they want the control just as much as the corporations do.

replies(5): >>45089321 #>>45089323 #>>45089975 #>>45090561 #>>45090592 #
reddalo ◴[] No.45089975[source]
> as soon as passkeys started popping up the endgame became clear

That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does.

They're just a lock-in mechanism.

replies(3): >>45090207 #>>45090270 #>>45090402 #
lucideer ◴[] No.45090270[source]
"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything.

Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys".

Two things have changed with the rebrand:

1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually.

2. A lot of large companies have set themselves up as providers of FIDO2 resident keys without export or migration mechanisms. This is the vendor lock-in part (no export feature), but it's not a feature of the underlying tech itself.

Fwiw FIDO are actively working on some standard for exporting/importing keys so that's something.

If you want to use passkeys without lockin, just use Bitwarden or KeepPassXC - they all have full support. Or you can also store a limited number of passkeys on your FIDO2-compatible hardware key like Yubikey or the open-source Nitrokeys.

replies(3): >>45090466 #>>45090951 #>>45091194 #
breakingcups ◴[] No.45090466[source]
Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407
replies(3): >>45090617 #>>45090649 #>>45090815 #
1. lucideer ◴[] No.45090815[source]
FIDO can't force any app developers to do anything but fwiw I think "pressuring" people to encrypt secrets at rest rather than storing them in plaintext is ok.

---

There's levels to appropriate paranoia around these things of course. SSH private keys are stored in plaintext for millions of engineers around the world - sometimes probably even passed around through unsecured emails or whatnot I would guess. They're still largely more secure than user:pass on aggregate, despite that rather major peril.

So ultimately, plaintext creds are not necessarily catastrophic. But still - imo - something worth concerted effort to dissuade at least at early stages of standards' implementation.

---

Edit: also, looks like the outcome of that thread was ultimately that KeepassXC have opted to implement the spec as per[0]. Good outcome to a good request.

[0] https://github.com/keepassxreboot/keepassxc/issues/11363