Pavelsky Durovsky didn't think this through? And so didn't you.

[Operative-001]

Wondering if it's tied to ignorance or malice the fact that 'security' boils down to TPM protection and even amateur people can, with some reasearch, figure out how to spoof TPM while tapping into the data and keys to decrypt user's content, but perhaps this was just a tech excercise and he never thought that this was going to be used, i.e. just a flex not really a product?

Let's say, I'm not someone that wants people's data. I'm someone that has money to invest and would like to buy the hardware to run this and provide a service to the community,
where is the benchmark of how much i'm expected to earn? No information. Minimum purchase is what, a 12'000$ graphics card, and there is 0 information on the benchmark of expected returns.

On the other hand, do you know who doesn't need to expect returns? Governments that can anonymously tap into the network, spoof the TPM module and tap into the information you're submitting believing it's actually encrypted.

It took me and my friend to figure out, on launch day, that this network is exploitable and exactly how about 2.5 hours in total. This project pops up into my mind sometime so I just come back to see if there is development and I wanted to leave this note for anyone that has the same recurring thought about this project and needs some closure: This project was never meant to be useful / working, it was simply a tech flex from a billionaire without any real use case because the fundamentals it's created on are just stupid. the belief that there is a way to ensure hardware is not tempered with without monitoring it 24/7 physically is just absurd, if you're using this network, assume that your information is not private. Research the fundamentals this project is based on and you'll see very fast that, for one reason or another, like cheating, spoofing in this domain has been done in the past and there are malicious actors that can and will exploit it for data in a way or another,
peace.

Pavelsky Durovsky, if you need people around you that are willing to tell you that some ideas are stupid, my hourly consultation rate is 1000$/h

[Operative-001]

This was a good idea, badly executed. You could have just as well made a non profit, rented datacenters and allowed people to purchase graphics cards using TON that staff in the nonprofit would source themselves directly from the supplier NVIDIA and set them up, automatically showing profits and using the nonprofit to allow the 'decentralized' network by creating terms of services which allowed users to 'lend' you the graphics cards, in multiple datacenters in multiple regions.

Could have charged a fee from the first payout for the setup, to keep it net 0.
Show the profits for each card on the website and the cost next to it.

Would have been too much work or you don't have the right people to advise you on these choices?

I think this product has a great market fit if done right. No one with half a braincell will trust remotely 'verified' TPM's.

There is still time to do things right, my next post will be on how to break TPM verification, with code and schematics so that we even the field between government threat actors and normal threat actors.

[slnelor]

Hello, what is your research based on?

[Operative-001]

Hello, what is your research based on?

By “research,” I mean a mix of prior public work on trusted hardware limitations, known real-world examples of hardware spoofing / attestation bypass concepts, and my own reasoning about the threat model this project depends on.

My point is not that TPM magically makes everything insecure by default, but that remote trust assumptions around hardware are much weaker than many people present them to be, especially when physical control of the machine belongs to the operator.

So my criticism is based on:

the general history of hardware/attestation bypasses and spoofing attempts,
the gap between “remote verification” and actual physical trust,
and the fact that the project seems to give users stronger privacy assurances than the underlying model can realistically guarantee.

I’m happy to be corrected on specifics if the team can explain what exact mechanism prevents a malicious operator with full machine control from extracting value from the workload or undermining the trust model.

Cocoon’s security appears to depend on Intel TDX, RA-TLS attestation, approved image measurements, and GPU confidential-computing checks. That is stronger than “just TPM,” but it still rests on a remote-attestation trust model.

Nonetheless, my personal view is that no remotely enforced security model should be treated as absolute. Remote attestation can raise the cost of tampering, but it does not replace physical control or continuous physical oversight.

For that reason, I do not think remotely verified compliance should be blindly trusted for highly sensitive workloads or valuable data. At best, it can reduce risk within a specific threat model; it cannot eliminate it.

Please also review the recent https://TEE.fail research. It is a good example of why remote attestation should be treated as a conditional security mechanism, not an absolute guarantee.

My point is not that every TEE-based system is instantly broken, but that this entire class of “remotely verified” security depends on assumptions that become fragile under pressure from highly motivated, well-funded, and technically capable adversaries, including governments. When those assumptions fail, the trust model can collapse very quickly.