Sure, there are sensible things that could be done with this. But given the background of the people involved, the fact that this is yet another clear profit-first gathering makes me incredibly pessimistic.

This pessimism is made worse by reading the answers of the founders here in this thread: typical corporate talk. And most importantly: preventing the very real dangers involved is clearly not a main goal, but is instead brushed off with empty platitudes like "I've been a FOSS guy my entire adult life...." instead of describing or considering actual preventive measures. And even if the claim was true, the founders had a real love for the hacker spirit, there is obviously nothing stopping them from selling to the usual suspects and golden parachute out.

I was really struggling to not make this comment just another snarky, sarcastic comment, but it is exhausting. It is exhausting to see the hatred some have for people just owning their hardware. So sorry, "don't worry, we're your friends" just doesn't cut it to come at this with a positive attitude.

The benefits are few, the potential to do a lot of harm is large. And the people involved clearly have the network and connections to make this an instrument of user-hostility.

Every time you perform an attestation the public key (and certificate) is divulged which makes it a unique identifier, and one that can be traced to the point of sale - and when buying a used device, a point of resale as the new owner can be linked to the old one.

They make an effort to increase privacy by using intermediaries to convert the identifier to an ephemeral one, and use the ephemeral identifier as the attestation key.

This does not change the fact that if the party you are attesting to gets together with the intermediary they will unmask you. If they log the attestations and the EK->AIK conversions, the database can be used to unmask you in the future.

Also note that nothing can prevent you from forging attestations if you source a private-public key pair and a valid certificate, either by extracting them from a compromised device or with help from an insider at the factory. DRM systems tend to be separate from the remote attestation ones but the principles are virtually identical. Some pirate content producers do their deeds with compromised DRM private keys.

What, this part is only needed for secure boot? I'm not sec... oh. So go back to the UEFI settings, turn secure boot off, problem solved. I usually also turn off SELinux right after install.

So I'm an old greybeard who likes to have full control. Less secure. But at least I get the choice. Hopefully I continue to do so. The notion of not being able to access online banking services or other things that require account login, without running on a "fully attested" system does worry me.

* smartphone device integrity checks (SafetyNet / Play Integrity / Apple DeviceCheck)

* HDMI/HDCP

* streaming DRM (Widevine / FairPlay)

* Secure Boot (vendor-keyed deployments)

* printers w/ signed/chipped cartridges (consumables auth)

* proprietary file formats + network effects (office docs, messaging)

Attestation, the thing we're going to be spending the next forever trying to get out of phones, now in your kernel.

this basically will remove or significantly encumber user control over their system, such that any modification will make you loose your "signed" status and ... boom! goodbye accessing the internet without an id

pottering recently works for Microsoft, they want to turn linux into an appliance just like windows, no longer a general purpose os. the transition is still far from over on windows, but look at android and how the google play services dependency/choke-hold is

im sure ill get many down votes, but despite some hyperbole this is the trajectory

It sounds like you want to achieve system transparency, but I don't see any clear mention of reproducible builds or transparency logs anywhere.

I have followed systemd's efforts into Secure Boot and TPM use with great interest. It has become increasingly clear that you are heading in a very similar direction to these projects:

- Hal Finney's transparent server

- Keylime

- System Transparency

- Project Oak

- Apple Private Cloud Compute

- Moxie's Confer.to

I still remember Jason introducing me to Lennart at FOSDEM in 2020, and we had a short conversation about System Transparency.

I'd love to meet up at FOSDEM. Email me at fredrik@mullvad.net.

Edit: Here we are six years later, and I'm pretty sure we'll eventually replace a lot of things we built with things that the systemd community has now built. On a related note, I think you should consider using Sigsum as your transparency log. :)

Edit2: For anyone interested, here's a recent lightning talk I did that explains the concept that all project above are striving towards, and likely Amutable as well: https://www.youtube.com/watch?v=Lo0gxBWwwQE

I have this fond memory of that Notary in Germany who did a remote attestation of me being with him in the same room, voting on a shareholder resolution.

While I was currently traveling on the other side of the planet.

This great concept that totally will not blow up the planet has been proudly brought to you by Ze Germans.

No matter what your intentions are: It WILL be abused and it WILL blow up. Stop this and do something useful.

[While systemd had been a nightmare for years, these days its actually pretty good, especially if you disable the "oh, and it can ALSO create perfect eggs benedict and make you a virgin again while booting up the system!" part of it. So, no bad feelings here. Also, I am German. Also: Insert list of history books here.]

The website itself is rather vague in its stated goals and mechanisms.

One good news is that maybe LP will get less involved in systemd.

Probably obvious from the surnames but this is the first time I've seen a EU company pop up on Hacker News that could be mistaken for a Californian company. Nice to see that ambition.

I understand systemd is controversial, that can be debated endlessly but the executive team and engineering team look very competitive. Will be interesting to see where this goes.

I am glad to see these efforts are now under an independent firm rather than being directed by Microsoft.

What is the ownership structure like? Where/who have you received funding from, and what is the plan for ongoing monetization of your work?

Would you ever sell the company to Microsoft, Google, or Amazon?

Thanks.

https://fosdem.org/2026/schedule/speaker/lennart_poettering/

Remote attestation requires a great deal of trust, and I simply don't have it when it comes to this leadership team.

What does this mean? Why would anyone want this? Can you explain this to me like I'm five years old?

[1] https://en.wikipedia.org/wiki/Confused_deputy_problem

One of the most grating pain points of the early versions of systemd was a general lack of humility, some would say rank arrogance, displayed by the project lead and his orbiters. Today systemd is in a state of "not great, not terrible" but it was (and in some circles still is) notorious for breaking peoples' linux installs, their workflows, and generally just causing a lot of headaches. The systemd project leads responded mostly with Apple-style "you're holding it wrong" sneers.

It's not immediately clear to me what exactly Amutable will be implementing, but it smells a lot like some sort of DRM, and my immediate reaction is that this is something that Big Tech wants but that users don't.

My question is this: Has Lennart's attitude changed, or can linux users expect more of the same paternalism as some new technology is pushed on us whether we like it or not?

Who is this for / what problem does it solve?

I guess security? Or maybe reproducability?

See: “it’s just an init system”where it’s now also a resolver, log system, etc.

I can buy good intentions, but this opens up too much possibility for not-so-good-intended consequences. Deliberate or emergent.

>We are building cryptographically verifiable integrity into Linux systems

I wonder what that means ? It could be a good thing, but I tend to think it could be a privacy nightmare depending on who controls the keys.

For individuals, IMO the risk mostly come from software they want to run (install script or supply chain attack). So if the end user is in control of what gets signed, I don't see much benefit. Unless you force users to use an app store...

Whatever it is, I hope it doesn't go the usual path of a minimal support, optional support and then being virtually mandatory by means of tight coupling with other subsystems.

You're free to root your phone. You're free to run whatever you want. You're just not entitled to have third parties trust that device with their systems and money. Same as you're free to decline STD testing - you just don't get to then demand unprotected sex from partners who require it.

Device attestation fails? No streaming video or audio for you (you obvious pirate!).

Device attestation fails? No online gaming for you (you obvious cheater!).

Device attestation fails? No banking for you (you obvious fraudster!).

Device attestation fails? No internet access for you (you obvious dissident!).

Sure, there are some good uses of this, and those good uses will happen, but this sort of tech will be overwhelmingly used for bad.

2. Are you looking for pilot customers?

---

Making secure boot 100 times simpler would be a deffo plus.

I wish you great success

- it looks like they want to build a ChromeOS without Google.

I can relate to people being rather hostile to the idea of boot verification, because this is a process that is really low level and also something that we as computer experts rarely interact with more deeply. The most challenging part of installing a Linux system is always installing the boot loader, potentially setting up an UEFI partition. These are things that I don't do everyday and that I don't have deep knowledge in. And if things go wrong, then it is extra hard to fix things. Secure boot makes it even harder to understand what is going on. There is a general lack of knowledge of what is happening behind the scenes and it is really hard to learn about it. I feel that the people behind this project should really keep XKCD 2501 in mind when talking to their fellow computer experts.

Why not adopt seL4 like everybody else who is not outright delusional[0][1]?

0. https://sel4.systems/Foundation/Membership/

1. https://sel4.systems/use.html

If there’s a path to profitability, great for them, and for me too; because it means it won’t be available at no charge.

A reliably attestable system has to nail the entire boot chain: BIOS/firmware, bootloader, kernel/initramfs pairs, the `init` process, and the system configuration. Flip a single bit anywhere along the process, and your equipment is now a brick.

Getting all of this right requires deep system knowledge, plus a lot of hair-pulling adjustment, assuming if you still have hair left.

I think this part of Linux has been underrated. TPM is a powerful platform that is universally available, and Linux is the perfect OS to fully utilize it. The need for trust in digital realm will only increase. Who knows, it may even integrate with cryptocurrency or even social platforms. I really wish them a good luck.

I can see like a 100 ways this can make computing worse for 99% people and like 1-2 scenarios where it might actually be useful.

Like if the politicians pushing for chat control/on device scanning of data come knocking again and actually go through (they can try infinitely) tech like this will really be "useful". Oops your device cannot produce a valid attestation, no internet for you.

"Those who give up freedom for security deserve neither."

1. How will the company make money? (You have probably been asked that a million times :).)

2. Similar to the sibling: what are the first bits that you are going to work on.

At any rate, super cool and very nice that you are based in EU/Germany/Berlin!

Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.

Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.

But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.

However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?

Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.

Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.

Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.

Why should we trust microsofties to produce something secure and non-backdoored?

And, lastly, why should Linux's security be tied to a private company? Oooh, but it's of course not about security: it's about things like DRM.

I hope Linus doesn't get blinded here: systemd managed to get PID 1 on many distros but they thankfully didn't manage, yet, to control the kernel. I hope this project ain't the final straw to finally meddle into the kernel.

Currently I'm doing:

    Proxmox / systemd-less VMs / containers

So my plan is:

    FreeBSD / bhyve hypervisor / systemd-less Linux VMs / containers

This project is an attack on general-purpose computing.

In that world, authoring technology that enables this even more is either completely mad or evil. To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom, acceptance of risk. If you build software that actively intends to take this away from me to put it into the hands of economic interests and political actors then you deserve all the hate you can get.

https://news.ycombinator.com/item?id=18321884

- Linux is better now

- Nothing bad