41–50 of 180 posts
"trusted execution environment" != end-to-end encryption The entire point of E2EE is that both "ends" need to be fully under your control.
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.
Get a fun error message on debian 13 with firefox v140: "This application requires passkey with PRF extension support for secure encryption key storage. Your browser or device doesn't support these advanced features.Please use Chrome 116+, Firefox 139+, or Edge 141+ on a device with platform authentication (Face ID, Touch ID, Windows Hello, etc.)."
> Advanced Passkey Features Required > This application requires passkey with PRF extension support for secure encryption key storage. Your browser or device doesn't support these advanced features. > Please use Chrome 116+, Firefox 139+, or Edge 141+ on a device with platform authentication (Face ID, Touch ID, Windows Hello, etc.). (Running Chrome 143) So... does this just not support desktops without overpriced web…
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).
> ... 5 to 10 years away (or never, if the current economics works... Think PCs in 5y to 10y that can run SoTA multi-modal LLMs (cf Mac Pro) will cost as much as cars do, and I reckon folks will buy it.
Earlier quoted context omitted.
Looks like Confer is hosting its own inference: https://confer.to/blog/2026/01/private-inference/ > LLMs are fundamentally stateless—input in, output out—which makes them ideal for this environment. For Confer, we run inference inside a confidential VM. Your prompts are encrypted from your device directly into the TEE using Noise Pipes, processed there, and responses are encrypted back. The host never sees plaintext.…
> 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.
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, but now it's been signed by Intel I guess? to tell you that yes not only did confer.to send you that hash, but that hash is indeed a hash of what's running inside the Trusted Execution Environment.
I feel like this needs diagrams.
I don't agree that this is end to end encrypted. For example, a compromise of the TEE would mean your data is exposed. In a truly end to end encrypted system, I wouldn't expect a server side compromise to be able to expose my data. This is similar to the weasely language Google is now using with the Magic Cue feature ever since Android 16 QPR 1. When it launched, it was local only -- now it's local and in the cloud "…
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…
To put it another way, I am quite sure that a sufficiently skilled (or privileged: how do you know the manufacturer is not keeping copies of these hardware keys?) team could sit down with one of these enclave modules and figure out how to get the memory image (or whatever) out without altering the attested signature.