Most active commenters
  • tadfisher(4)

←back to thread

We should have the ability to run any code we want on hardware we own

(hugotunius.se)
2071 points K0nserv | 16 comments | 31 Aug 25 21:46 UTC | HN request time: 1.728s | source | bottom
Show context
zmmmmm ◴[01 Sep 25 02:51 UTC] 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 ◴[01 Sep 25 03:50 UTC] 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 ◴[01 Sep 25 06:19 UTC] 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 #
1. kleiba ◴[01 Sep 25 07:00 UTC] No.45090207[source]▶
For someone who hasn't spent any time thinking about that matter, could you please elaborate your point?
replies(2): >>45090297 #>>45090312 #
2. progval ◴[01 Sep 25 07:16 UTC] No.45090297[source]▶
"Passkeys are incompatible with open-source software" https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
replies(1): >>45090365 #
3. dingaling ◴[01 Sep 25 07:19 UTC] No.45090312[source]▶
Imagine using ssh-keygen, but it locks the private key in a vendor-managed secure enclave. You can't copy it, export it, rename it or do anything wth it.
replies(1): >>45090507 #
4. fragmede ◴[01 Sep 25 07:30 UTC] No.45090365[source]▶
Then how come KeePassXC has them?
replies(1): >>45090480 #
5. indigo945 ◴[01 Sep 25 07:45 UTC] No.45090480{3}[source]▶
The linked blog post explains it. The spec can be implemented by open source software, but the upcoming (or now current?) update to the spec enables attestation, that is, it allows the auth provider to cryptographically verify which implementation the client is using. Under this scheme, auth providers can simply choose to no longer support open source implementations like KeePassXC, and since the spec authors have already claimed that KeePassXC is "non-compliant" because it doesn't ask for a PIN on every auth request, it seems likely that that would happen.
replies(2): >>45090540 #>>45090669 #
6. tadfisher ◴[01 Sep 25 07:50 UTC] No.45090507[source]▶
I don't just imagine it, I do it, by using gpg-agent as my ssh-agent and using the private key generated by a Yubikey. Another way is to use tpm2-tools so only your laptop running your own signed boot chain can use the key. It is desirable to lock private key material in a physical thing that is hard to steal.

You can choose not to do this, and that's fine. Hardware attestation is dead because Apple refuses to implement it, so no one can force you to.

replies(1): >>45092306 #
7. fragmede ◴[01 Sep 25 07:55 UTC] No.45090540{4}[source]▶
Yes but it seems like KeyPassXC could just ask for PIN on every auth request to satisfy that requirement, without having to close their source.
replies(1): >>45090756 #
8. tadfisher ◴[01 Sep 25 08:16 UTC] No.45090669{4}[source]▶
Attestation is dead outside of corporate environments. Apple will not implement it except through MDM.
replies(2): >>45090738 #>>45091137 #
9. freedomben ◴[01 Sep 25 08:29 UTC] No.45090738{5}[source]▶
Isn't PAT apple implementing attestation for everyone?
10. reddalo ◴[01 Sep 25 08:33 UTC] No.45090756{5}[source]▶
What if I don't want KeyPassXC to ask me for a PIN every time? I can modify its source code and nobody can stop me.
replies(1): >>45091712 #
11. GoblinSlayer ◴[01 Sep 25 09:43 UTC] No.45091137{5}[source]▶
Apple will implement it.
replies(1): >>45095690 #
12. pbhjpbhj ◴[01 Sep 25 11:12 UTC] No.45091712{6}[source]▶
Then your version of KeyPass will not be signed and won't pass TPM checks and so the banking app will refuse to run unless you open the signed version?
replies(1): >>45096544 #
13. oigursh ◴[01 Sep 25 12:45 UTC] No.45092306{3}[source]▶
Can you explain your motivation around gpg-agent and yubikey little more, please? So the private key can't be copied elsewhere?
replies(1): >>45095502 #
14. tadfisher ◴[01 Sep 25 18:51 UTC] No.45095502{4}[source]▶
Yes, that's the motivation.

These days I would explore the TPM option, but I'm worried that has less legal teeth than a physical key if I'm in a law enforcement situation.

There's also practicality; I really, really don't want to tell my boss that TSA or whoever had access to the company git repositories and databases for X minutes or hours, and that's sidestepped by checking a bag with the Yubikey (wastes their time) or mailing it to the destination (needs a warrant).

15. tadfisher ◴[01 Sep 25 19:15 UTC] No.45095690{6}[source]▶
Source? That is surprising news.
16. yencabulator ◴[01 Sep 25 20:57 UTC] No.45096544{7}[source]▶
Which leads us back full circle to "Passkeys are incompatible with open-source software" from https://news.ycombinator.com/item?id=45090297