I mentioned it somewhere else in the thread, and btw, I'm not affiliated with the company, this is just my charitable interpretation of their intentions: this is not for requiring _every_ consumer linux device to have attestation, but for specific devices that are needed for niche purposes to have a method to use an open OS stack while being capable of attestation.
Personally for me this is interesting because there needs to be a way where a hardware token providing an identity should interact with a device and software combination which would ensure no tampering between the user who owns the identity and the end result of computing is.
A concrete example of that is electronic ballots, which is a topic I often bump heads with the rest of HN about, where a hardware identity token (an electronic ID provided by the state) can be used to participate in official ballots, while both the citizen and the state can have some assurance that there was nothing interceding between them in a malicious way.
- You're just moving your trust elsewhere, this time to a private corporation (whoever makes the CPU / TPM / other "trusted" component).
- This doesn't guarantee voter anonymity the way paper ballots do. Considering the analog hole and the complexity of computers, I can think of a billion ways a motivated and resourceful Mallory could to connect someone to their ballot.
> This doesn't guarantee voter anonymity the way paper ballots do.
You're saying that with a lot of assurance, but in my opinion that's still to be debated. We can build something that will keep at least a degree of separation between the identity that points to a specific individual and the identity that casts the ballot.
> the plan seems to be to replace package management with image based whole dist a/b swaps
The plan is probably to have that as an alternative for the niche uses where that is appropriate.
This majority of this thread seems to have slid on that slippery slope, and jumped directly to the conclusion where the attestation mechanism will be mandatory on all linux machines in the world and you won't be able to run anything without. Which even if it would be a purpose for amutable as a company, it's unfeasible to do when there's such a breadth of distributions and non corpo affiliated developers out there that would need to cooperate for that to happen.
Nobody says that you will not have alternatives. What people are saying, is that if you're using those alternatives you won't be able to watch videos online, or access your bank account.
That's so far down the slippery slope and with so many other things that need to go wrong that I'm not worried and I'm willing to be the one to get "told you so" if it happens.
It's baffling to me that anyone can imagine pipewire has been created from scratch without any lessons learned from pulseaudio and the previous issues the audio stack on linux had, and solved, over the years. Nothing is happening in a clean room bubble, every new project stands on the shoulders of giants...
If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security.
On top of that, there are tons of devices that can pass attestation that have known vulnerabilities, so the attacker could just use one of those (or extract the keys from it) if they had any reason to. But in the mobile banking threat model they don't actually need to.
It's not a matter of being hard. It's like trying to prevent theft by forcing everyone to wear a specific brand of shoes. The fact that the shoe company insists that it's useful is not evidence that it is.
It's not that you can't solve the problem, it's that you can't solve the problem using that mechanism. Attestation is useless for this.
The thing that would actually work for this is to have an open standard supported by PCs and phones to read the chip in payment/ATM cards, because then you could do "card-present" transactions remotely. You touch your card to the phone/PC and enter your PIN to authorize a new merchant. That actually solves the problem because then instead of the bank trusting every commercially available phone on the market, they only trust the specific card that they mailed to the cardholder, and you can only authorize a new merchant with physical possession of the card because it contains a private key. But that doesn't require attestation because then you don't need the keys to be in the phone since they're in the card, and it doesn't require a third party to sign anything because the bank puts the private key into the card before sending it to the cardholder without any need for Google or Apple to certify anything.
From what I can take from your reply I suspect you might not understand what attestation is for.
Yes you can use a chip that the bank trusts (that's your card), however the bank wants to trust that the hardware you use to read that chip is not compromised and does not try to do things on the behalf of the user that the user didn't authorize. A non trusted device can operate in a different way than the user demands of it, and the user might never know.
That's the use case that hardware attestation can prevent. Or so the theory says...
I think supporters of P2P as "the one true way" perhaps don't realize that federation is just as peer to peer if your user count is 1.
The fundamental distinction between a communication network that is p2p and one that is federated is the storage mechanism.
For p2p the network itself is the storage, and as a participating node you connect and retrieve what is addressed to you while the amorphous data blob that contains said messages remains to float in the network. While for a federated network, the receiving node needs to be present on the network at all times to be able to access/receive the messages addressed to itself, after which the messages are absent from the network (to some degree or another).
Personally the overhead of having the network having to bear the weight of all its nodes data is too large to make it viable.
I think empathy should be given when a nation of people have to suffer through these events multiple times a week.
Shutting down every thread about heinous acts in the name of "it's not interesting to me" is a very inhuman act in itself, and we the citizens of the rest of the world, should perhaps sit back and bear witness while the people of the US voice their disagreement in every square and on every corner while they still can.
Open-Source in its actuality is not a lot about community. It's about making sure other people have everything they need to be able to run and modify a specific piece of software. The fact that, usually communities form around this paradigm is a happy coincidence in my opinion. Additionally, another point on both you and OP are missing the point, is that the communities that are relevant to open-source are not communities of users, but communities of contributors.
And what OP is proposing is actually forced labour. Instead of people being free to work (and fork) to their heart contents, the implication exists that they're losing their time, and instead, should focus on "collaborating" with the existing community. Which frankly nobody in the history of open-source ever denied. Forks are last instance measures, where the steering of a project gets off the rails to a high enough degree to justify such a drastic measure.
... but somehow fails to qualify that distinction in its actual content. "FOSS" includes opentofu and mysql and the redis alternatives and a lot more than just social media alternatives...
When you inflame that reader with grandstanding titles like "FOSS has delusions" perhaps they could be forgiven for taking that literally when nothing else clarifies your trite generality, me thinks.
