51–60 of 180 posts
I am confused. I get E2EE chat with a TEE, but the TEEs I know of (admittedly not an expert) are not powerful enough to do the actual inference, at least not any useful one. The blog posts published so far just glance over that.
It seems like the H100 gpu itself has some kind of secure execution environment built in. Not sure of the details but it appears that all data going to and from the gpu will be encrypted. https://developer.nvidia.com/blog/confidential-computing-on-...
Now, of course, it is in question as to whether my little graphics card can reasonably compare to a bigger cloud thing (and for me presently a very genuine question) but that really should be the gold standard here.
Inevitably, the TEE hardware vendor must be trusted. I don't think this is a bad assumption in today's world, but this is still a fairly new domain and longer term it becomes increasingly likely TEE compromises like design flaws, microcode bugs, key compromises, etc. are discovered (if they haven't already been!) Then we'd need to consider how Confer would handle these and what sort of "break glass" protocols are in place.
This also requires a non-trivial amount of client side coordination and guards against any supply chain attacks. Setting aside the details of how this is done, even with a transparency log, the client must trust something about “who is allowed to publish acceptable releases”. If the client trusts “anything in the log,” an attacker could publish their own signed artifacts, So the client must effectively trust a specific publisher identity/key, plus the log’s append-only/auditable property to prevent silent targeted swaps.
The net result is a need to trust Confer's identity and published releases, at least in the short term as 3rd party auditors could flag any issues in reproducible builds. As I see it, the game theory would suggest Confer remains honest, Moxie's reputation plays are fairly large role in this.
Earlier quoted context omitted.
The point of E2EE is that only the people/systems that need access to the data are able to do so. If the message is encrypted on the user's device and then is only decrypted in the TEE where the data is needed in order to process the request, and only lives there ephemerally, then in what way is it not end-to-end encrypted?
Because anyone with access to the TEE also has access to the data. The owners can say they won't tamper with it, but those are promises, not guarantees.
Earlier quoted context omitted.
I agree it is more like e2teee, but I think there is really no alternative beyond TEE + anonymization. Privacy people want it locally, but it is 5 to 10 years away (or never, if the current economics works, there is no need to reverse the trend).
There's FHE, but that's probably an even more difficult technical challenge than doing everything locally
Earlier quoted context omitted.
> Looks like Confer is hosting its own inference Even so, you're still exposing your data to Confer, and so you have to trust them that they'll behave as you want. That's a security problem that Confer doesn't help with. I'm not saying Confer isn't useful, though. e2ee is very useful. But it isn't enough to make me feel comfortable.
> you're still exposing your data to Confer They use a https://en.wikipedia.org/wiki/Trusted_execution_environment and iiuc claim that your client can confirm (attest) that the code they run doesn't leak your data, see https://confer.to/blog/2026/01/private-inference/ So you should be able to run https://github.com/conferlabs/confer-image yourself and get a hash of that and then confer.to will send you that same hash…
And there's the problem.
All of that stuff is well and good, but it seems like I have to have a fair degree of knowledge and technical skill, not to mention time and effort, to confirm that everything is as they're representing. And it's time and effort I'd have to expend on an ongoing basis.
That's not an expectation I could realistically meet, so in practice, I still have to just trust them.
Earlier quoted context omitted.
No need to make up hypotheticals. The server isn't the final destination for your LLM requests. The reply needs to come back to you.
If Bob and Alice are in an E2EE chat Bob and Alice are the ends. Even if Bob asks Alice a question and she replies back to Bob, Alice is still an end. Similarly with AI. The AI is one of the ends of the conversation.
Earlier quoted context omitted.
> you're still exposing your data to Confer They use a https://en.wikipedia.org/wiki/Trusted_execution_environment and iiuc claim that your client can confirm (attest) that the code they run doesn't leak your data, see https://confer.to/blog/2026/01/private-inference/ So you should be able to run https://github.com/conferlabs/confer-image yourself and get a hash of that and then confer.to will send you that same hash…
> I feel like this needs diagrams. And there's the problem. All of that stuff is well and good, but it seems like I have to have a fair degree of knowledge and technical skill, not to mention time and effort, to confirm that everything is as they're representing. And it's time and effort I'd have to expend on an ongoing basis. That's not an expectation I could realistically meet, so in practice, I still have to just…
"trusted execution environment" != end-to-end encryption The entire point of E2EE is that both "ends" need to be fully under your control.
This is false. From Wikipedia: "End-to-end encryption (E2EE) is a method of implementing a secure communication system where only the sender and intended recipient can read the messages." Both ends do not need to be under your control for E2EE.
Earlier quoted context omitted.
If Bob and Alice are in an E2EE chat Bob and Alice are the ends. Even if Bob asks Alice a question and she replies back to Bob, Alice is still an end. Similarly with AI. The AI is one of the ends of the conversation.
So ChatGPT is end-to-end encrypted?