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 "with attestation". I don't like this trend and I don't think I'll be using such products
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).
FHE is impossible. You cannot expect to compete on 100x more cost for the same service you provide (and there is no design for accelerated hardware (Tensor Core) on FHE).
if (big if) you trust the execution environment, which is apparently auditable, and if (big if) you trust the TEE merkle hash used to sign the response is computer based on the TEE as claimed (and not a malicious actor spoofing a TEE that lives within an evil environment) and also if you trust the inference engine (vllm / sglanf, what have you) then I guess you can be confident the system is private.
Lots of ifs there, though. I do trust Moxie in terms of execution though. Doesn’t seem like the type of person to take half measures.
Agree. Products and services in the privacy space have a tendency to be incredibly misleading in their phrasing, framing, and overall marketing as to the nature of their assertions that sound pretty much like: "we totally can never ever see your messages, completely and utterly impossible". Proton is particularly bad for this, it's rather unfortunate to see this from "Moxie" as well.
It's like, come on you know exactly what you're doing, it's unambiguous how people will interpret this, so just stop it. Cue everyone arguing over the minutiae while hardly anyone points out how troubling it is that these people/entities have no concerns with being so misleading/dishonest...
Sure, for e.g. E2E email, the expectation is that all the computation occurs on the client, and the server is a dumb store of opaque encrypted stuff.
In a traditional E2E chat app, on the other hand, you've still got a backend service acting as a dumb pipe, that shouldn't have the keys to decrypt traffic flowing through it; but you've also got multiple clients — not just your own that share your keybag, but the clients of other users you're communicating with. "E2E" in the context of a chat app, means "messages are encrypted within your client; messages can then only be decrypted within the destination client(s) [i.e. the client(s) of the user(s) in the message thread with you.]"
"E2E AI chat" would be E2E chat, with an LLM. The LLM is the other user in the chat thread with you; and this other user has its own distinct set of devices that it must interact through (because those devices are within the security boundary of its inference infrastructure.) So messages must decrypt on the LLM's side for it to read and reply to, just as they must decrypt on another human user's side for them to read and reply to. The LLM isn't the backend here; the chat servers acting as a "pipe" are the backend, while the LLM is on the same level of the network diagram as the user is.
Let's consider the trivial version of an "E2E AI chat" design, where you physically control and possess the inference infrastructure. The LLM infra is e.g. your home workstation with some beefy GPUs in it. In this version, you can just run Signal on the same workstation, and connect it to the locally-running inference model as an MCP server. Then all your other devices gain the ability to "E2E AI chat" with the agent that resides in your workstation.
The design question, being addressed by Moxie here, is what happens in the non-trivial case, when you aren't in physical possession of any inference infrastructure.
Which is obviously the applicable case to solve for most people, 100% of the time, since most people don't own and won't ever own fancy GPU workstations.
But, perhaps more interesting for us tech-heads that do consider buying such hardware, and would like to solve problems by designing architectures that make use of it... the same design question still pertains, at least somewhat, even when you do "own" the infra; just as long as you aren't in 100% continuous physical possession of it.
You would still want attestation (and whatever else is required here) even for an agent installed on your home workstation, so long as you're planning to ever communicate with it through your little chat gateway when you're not at home. (Which, I mean... why else would you bother with setting up an "E2E AI chat" in the first place, if not to be able to do that?)
Consider: your local flavor of state spooks could wait for you to leave your house; slip in and install a rootkit that directly reads from the inference backend's memory; and then disappear into the night before you get home. And, no matter how highly you presume your abilities to detect that your home has been intruded into / your computer has been modified / etc once you have physical access to those things again... you'd still want to be able to detect a compromise of your machine even before you get home, so that you'll know to avoid speaking to your agent (and thereby the nearby wiretap van) until then.
Just like your mobile device is one end of the end-to-end encryption, the TEE is the other end. If properly implemented, the TEE would measure all software and ensure that there are no side channels that the sensitive data could be read from.
When the server is the final recipient of a message sent over TLS, then yes, that is end-to-end encryption (for instance if a load balancer is not decrypting traffic in the middle). If the message's final recipient is a third party, then you are correct, an additional layer of encryption would be necessary. The TEE is the execution environment that needs access to the decrypted data to process the AI operations, therefore it is one end of the end-to-end encryption.
E2EE is usually applied in contexts where the message's final recipient is NOT the server on the other end of a TLS connection, so yes, this scenario is a stretch. The point is that in the context of an AI chat app, you have to decide on the boundary that you draw around the server components that are processing the request and necessarily need access to decrypted data, and call that one "end" of the connection.
No, because there is a web server that exposes an API that accepts a plaintext prompt and returns plaintext responses (even if this API is exposed via TLS). Since this web server is not the same server as the backend systems that are processing the prompt, it is a middle entity, rather than an end in the system.
The difference here is that the web server receiving a request for Confer receives an encrypted blob that only gets decrypted when running in memory in the TEE where the data will be used, which IS an end in the system.
See my other comment, but the answer here is resoundingly "No". For the communication to be end-to-end encrypted the payload needs to be encrypted through all steps of the delivery process until it reached the final entity it is meant for. Infrastructure like cloudflare generally is configured to be able to read the full contents of the web request (TLS interception or Load balancing) and therefore the message lives for a time unencrypted in the memory of a system that is not the intended recipient.
What he did with messaging... So he will centralize all of it with known broken SGX metadata protections, weak supply chain integrity, and a mandate everyone supply their phone numbers and agree to Apple or Google terms of service to use it?
It seems like Signal may be another example of "read-only" open source, where there is no expectation anyone will actually try to _use_ the source code. Instead, there is an expectation that everyone will use binaries distributed by a third party and allow remote code installation and RCE of software on their computers _at the third party's discretion_. In other words, all users will cede control to a third party
NB. This comment is not referring to the "Signal protocol". It pertains to _control_ over the software that implements it
The issue being there's not really a credible better option. Matrix is the next best, because they do avoid the tie-in to phone numbers and such, but their cryptographic design is not so great (or rather, makes more tradeoffs for usability and decentralisation), and it's a lot buggier and harder to use.
Full time matrix user and all my family and businesses use Matrix too. It works just fine, and with self hosting, I control the metadata on the servers I host for my orgs.
It actually is the least bad option available, and decentralization is always worth it even if development is slower and more complex as a consequence.
Do you know a better alternative that I can get my elderly parents and non-technical friends to use?
I haven’t come across one and from my amateur POV it seems much better than WhatsApp or Telegram.
XMPP, as Matrix is pretty much centralized, unless you're fortunate enough to register outside of matrix.org. Both xmpp.org and jabber.org is no longer open for registration.
Not sure why you're gettimg downvoted. This is exactly what he did to instant messaging; extremely damaging to everyone and without solid arguments for such design.
Or, he took a barely niché messaging app plugin (OTR), improved it to provide forward secrecy for non-round trips, and deployed the current state-of-the art end-to-end encryption to over 3,000,000,000 users, as Signal isn't the only tool to use double-ratchet E2EE.
>broken SGX metadata protections
Citation needed. Also, SGX is just there to try to verify what the server is doing, including that the server isn't collecting metadata. The real talking is done by the responses to warrants https://signal.org/bigbrother/ where they've been able to hand over only two timestamps of when the user created their account and when they were last seen. If that's not good enough for you, you're better off using Tor-p2p messengers that don't have servers collecting your metadata at all, such as Cwtch or Quiet.
>weak supply chain integrity
You can download the app as an .apk from their website if you don't trust Google Play Store.
>a mandate everyone supply their phone numbers
That's how you combat spam. It sucks but there are very few options outside the corner of Zooko's triangle that has your username look like "4sci35xrhp2d45gbm3qpta7ogfedonuw2mucmc36jxemucd7fmgzj3ad".
>and agree to Apple or Google terms of service to use it?
Yeah that's what happens when you create a phone app for the masses.
Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
He IS a hacker from the 90s. It’s an assumed name. Plenty of hackers from the 90s have pseudonyms.
> so-called creator of some encryption protocol
All evidence points to him being one of the protocol’s designers, along with Trevor Perrin.
I’ve met both of them. The first time I met Moxie and talked about axolotl (as it was called back then) was in 2014. Moxie and Trevor strike me as having more integrity and conviction than most. There is no doubt in my mind that they are real and genuine.
Interestingly enough, some of the work Trevor did related to Signal’s cryptography was later used by Jason Donenfeld in the design of WireGuard.
> It screams honeypot like nothing else.
As you can see there is plenty of evidence suggesting otherwise.
>Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
This criticism has absolutely zero substance and honestly just reads like paranoid rambling. The Signal protocol has been independently formally analyzed [1] and has no known security issues.
The example you linked is about push notifications in general, nothing specific to the Signal app. If the concern is that your OS is compromised or spying on you, that's not something E2E encryption can protect against, whether it's Signal or any other app.
So the argument against Signal is now "the creator's nickname sounds odd"? I mean, OK? Keep using WhatsApp, Telegram or Instagram if you think those are more private than Signal.
It's just people having zero product sense, or an idea of what it means to target more than 0.01% of the market. The last comment said that Signal's problem is that it's mobile-first, which, how does someone even think that a messaging app should be anything other than mobile-first?
> You can download the app as an .apk from their website if you don't trust Google Play Store.
I wish apple & google provided a way to verify that an app was actually compiled from some specific git SHA. Right now applications can claim they're opensource, and claim that you can read the source code yourself. But there's no way to check that the authors haven't added any extra nasties into the code before building and submitting the APK / ios application bundle.
It would be pretty easy to do. Just have a build process at apple / google which you can point to a git repo, and let them build the application. Or - even easier - just have a way to see the application's signature in the app store. Then opensource app developers could compile their APK / ios app using github actions. And 3rd parties could check the SHA matches the app binaries in the store.
This is what F-droid does (well, I suspect most apps don't have reproducable builds that would allow 3rd-party verification), but Signal does not want 3rd-party builds of their client anyhow.
>> and agree to Apple or Google terms of service to use it?
> Yeah that's what happens when you create a phone app for the masses.
No, that's what happens when you actively forbid alternative clients and servers, prevent (secure) alternative methods of delivery for your app and force people to rely on the American megacorps known for helping governmental spying on users, https://news.ycombinator.com/item?id=38555810
It’s exciting to hear that Moxie and colleagues are working on something like this. They definitely have the skills to pull it off.
Few in this world have done as much for privacy as the people who built Signal. Yes, it’s not perfect, but building security systems with good UX is hard. There are all sorts of tradeoffs and sacrifices one needs to make.
For those interested in the underlying technology, they’re basically combining reproducible builds, remote attestation, and transparency logs. They’re doing the same thing that Apple Private Cloud Compute is doing, and a few others. I call it system transparency, or runtime transparency. Here’s a lighting talk I did last year: https://youtu.be/Lo0gxBWwwQE
I don't know, I'd say Signal is perfect, as it maximizes "privacy times spread". A solution that's more private wouldn't be as widespread, and thus wouldn't benefit as many people.
Signal's achievement is that it's very private while being extremely usable (it just works). Under that lens, I don't think it could be improved much.
>Signal's achievement is that it's very private while being extremely usable (it just works).
Exactly. Plus it basically pioneered the multi-device E2EE. E.g., Telegram claimed defaulting to E2EE would kill multi-client support:
"Unlike WhatsApp, we can allow our users to access their Telegram message history from several devices at once thanks to our built-in instant cloud sync"
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.)."
Unless I misunderstand, this doesn't seem to address what I consider to be the largest privacy risk: the information you're providing to the LLM itself. Is there even a solution to that problem?
I mean, e2ee is great and welcome, of course. That's a wonderful thing. But I need more.
> 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.
I don’t know what model they’re using, but it looks like everything should be staying on their servers, not going back to, eg, OpenAI or Anthropic.
That is a highly misleading statement: the GPU runs with real weights and real unencrypted user plaintext, since it has to multiply matrices of plain text, which is passed on to the supposedly "secure VM" (protected by Intel/Nvidia promises) and encrypted there. In no way is it e2e, unless you count the GPU as the "end".
It is true that nVidia GPU-CC TEE is not secure against decapsulation attacks, but there is a lot of effort to minimize the attack surface. This recent paper gives a pretty good overview of the security architecture: https://arxiv.org/pdf/2507.02770
So what you are saying is that all the TEE and remote attestation and everything might work for CPU based workflows but they just don't work with GPU effectively being unencrpyted and anyone can read it from there?
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.
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.
As I read it, the attestation is simply that the server is running a particular kernel and application in the Secure Enclave using the hardware’s certification. That does not attest that there is no sidechannel. If exfiltration from the TEE is achieved, the attestation will not change.
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.
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.
In most of modern life we trust to experts to some degree. I couldn't off the top of my head explain DH key exchange, I don't know if I'll ever understand elliptic curves, but I see that most of the cryptographic community understands them as good methods for many problems and if lots of experts who otherwise argue about anything will agree "what yes, of course DH is good for key exchange but that's beside the point and djb is still wrong about florbnitz keys" then it's likely DH is indeed good for key exchange.
If everyone had to understand every detail to trust in tech we would not have nuclear plants or coast around on huge flammable piles of charged lithium
In theory, you trust the "crowd" (rather than the hosting entity) because if they don't do what they said, the "crowd" should make a noise about it and you would know.
That’s true, but it’s still a distinct threat model from “we use the API of a company run by one of the least trustworthy humans on the planet.” We can talk through side channel attacks and whatnot, but we’re discussing issues with Confer’s implementation, not trusting a different third party.
As someone who has spent a good time of time working on trusted compute (in the crypto domain) I'll say this is generally pretty well thought out, doesn't get us to an entirely 0-trust e2e solution, but is still very good.
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.
An interesting take on the AI model. I'm not sure what their business model is like, as collecting training data is the one thing that free AI users "pay" in return for services, but at least this chat model seems honest.
Using remote attestation in the browser to attest the server rather than the client is refreshing.
Using passkeys to encrypt data does limit browser/hardware combinations, though. My Firefox+Bitwarden setup doesn't work with this, unfortunately. Firefox on Android also seems to be broken, but Chrome on Android works well at least.
Collecting the email doesn't inspire much confidence. An account-number model like Mullvad's would seem preferable, or you could go all-in on syncable passkeys as the only user identifier.
The web app itself feels poorly made—almost vibe-coded in places: nonsensical gradients, UI elements rendering in flashes of white, and subtly off margins and padding.
The model itself is unknown, but speaks with the cadence reminiscent of GPT-4o.
I'm no expert, but calling this "end-to-end encrypted" is only accurate if one end is your client and the other is a very much interposable GPU (assuming vendor’s TEE actually works—something that, in light of tee.fail, feels rather optimistic).
> An account-number model like Mullvad's would seem preferable
Thank you! :)
> .. assuming vendor’s TEE actually works
For sure TEEs have a rich history of vulnerabilities and nuanced limitations in their threat models. As a concept however, it is really powerful, and implementers will likely get things more and more right.
As for GPUs, some of Nvidia’s hardware does support remote attestation.
I’m missing something, won’t the input to the llm necessarily be plaintext? And the output too? Then, as long as the llm has logs, the real input by users will be available somewhere in their servers
>Data and conversations originating from users and the resulting responses from the LLMs are encrypted in a trusted execution environment (TEE) that prevents even server administrators from peeking at or tampering with them.
I think what they meant to say is that data is decrypted only in a trusted execution environment, and otherwise is stored/transmitted in an encrypted format.
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.
That is where the attestation comes in to show that the environment is only running cryptographically verified versions of open source software that does not have the mechanisms to allow tampering.
The point of measured environments like the TEE is that you are able to make guarantees about all the software that is running in the environment (verified with the attestation). "If the software can modify data legitimately, it can be tampered with." - the software that makes up the SBOM for these environments do not expose administrator functions to access the decrypted data.
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.
Interestingly the confer image on GitHub doesn’t seem to include in the attestation the model weights (they seem loaded from a mounted ext4 disk without dm-verity). Probably this doesn’t compromise the privacy of the communication (as long as the model format is not containing any executable part) but it exposes users to a “model swapping” attack, where the confer operator makes a user talk to an “evil” model without they can notice it. Such evil model may be fine tuned to provide some specifically crafted output to the user. Authenticating the model seems important, maybe it is done at another level of the stack?
I see references to vLLM in the GitHub but not which actual model (Llama, Mistral, etc.) or if they have a custom fine tune, or you give your own huggingface link?
> 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 webcams, or am I missing something?
I am super curious about this. I wonder baseline it needs to meet to pull me away from using ChatGPT or Claude.
My usage of it would be quite different than ChatGPT. I’d be much freer in what I ask it.
I think there’s a real opportunity for something like this. I would have thought Apple would have created it but they just announced they’ll use Gemini.
Again with the confidential VM and remote attestation crypto theater? Moxie has a good track record in general, and yet he seems to have a huge blindspot in trusting Intel broken "trusted VM" computing for some inexplicable reason. He designed the user backups of Signal messages to server with similar crypto secure "enclave" snake-oil.
AFAIK the signal backups use symmetric encryption with user generated and controlled keys and anonymous credentials (https://signal.org/blog/introducing-secure-backups/). Do you have a link about the usage of sgx there?
Also fwiw I think tees and remote attestation are a pretty pragmatic solution here that meaningfully improves on the current state of the art for llm inference and I'm happy to see it.
Aha. This, ideally, is a job for local only. Ollama et al.
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.
I have a hybrid model here. For many many tasks a local 12b or similar works totally fine. For the rest I use cloud, those things tend to be less privacy sensitive anyway.
Like when someone sends me a message, I made something that categorises it for urgency. If I'd use cloud it means they get a copy of all those messages. But locally there's no issue and complexity wise it's pretty low for an LLM.
Things like research jobs I do do in cloud, but they don't really contain any personal content, they just research using sources they already have access to anyway. Same with programming, there's nothing really sensitive in there.
Nice. You're exactly nailing what I'm working towards already. I'm programming with gemini for now and have no problem there, but the home use case I found for local Ollama was "taking a billion old bookmarks and tagging them." Am looking forward to pointing ollama at more personal stuff.
Yeah I have two servers now. One with a big AMD for decent LLM performance. And one for a smaller Nvidia that runs mostly Whisper and some small models for side tasks.
At least Cocoon and similar services relying on TEE don't call this end-to-end encryption. Hardware DRM is not E2EE, it's security by obscurity. Not to say it doesn't work, but it doesn't provide mathematically strong guarantees either.
My issue is it claims to be end-to-end encrypted, which is really weird. Sure, TLS between you and your bank's server is end-to-end encrypted. But that puts your trust on the service provider.
Usually in a context where a cypherpunk deploys E2EE it means only the intended parties have access to plaintexts. And when it's you having chat with a server it's like cloud backups, the data must be encrypted by the time it leaves your device, and decrypted only once it has reached your device again. For remote computing, that would require LLM handles ciphertexts only, basically, fully homomorphic encryption (FHE). If it's that, then sure, shut up and take my money, but AFAIK the science of FHE isn't nearly there yet.
So the only alternative I can see here is SGX where client verifies what the server is doing with the data. That probably works against surveillance capitalism, hostile takeover etc., but it is also US NOBUS backdoor. Intel is a PRISM partner after all, and who knows if national security requests allow compelling SGX keys. USG did go after Lavabit RSA keys after all.
So I'd really want to see this either explained, or conveyed in the product's threat model documentation, and see that threat model offered on the front page of the project. Security is about knowing the limits of the privacy design so that the user can make an informed decision.
You don’t have to use Google login though?
People building solutions like this that aim for broad adoption have to make certain compromises and this seems OK to me (just talking about offering a social login option, haven’t checked the whole project in detail)
Most people don't care about Google knowing whether they're using a particular app. If they do, they have the option not to use it. The main concern is that the chats themselves are E2E encrypted, which we have every reason to believe.
This is a perfect example of purism vs. pragmatism. Moxie is a pragmatist who builds things that the average person can actually use. If it means that millions of people who would otherwise have used ChatGPT will migrate because of the reduced friction and get better privacy as a result, that's a win even if at the margin they're still leaking one insignificant piece of metadata to Google.
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.
MM is basically up-selling his _Signal_ trust score. Granted, Signal/RedPhone predecessor upped the game but calling this E2E encrypted AI chat is a bit of a stretch..
Interesting! I wonder a) how much of an issue this addresses, ie how much are people worried about privacy when they use other LLMs? and b) how much of a disadvantage it is for Confer not to be able to read/ train in user data.
I am shocked at how quickly everyone is trying to forget that TEE.fail happened, and so now this technology doesn't prove anything. I mean, it isn't useless, but DNS/TLS and physical security/trust become load bearing, to the point where the claims made by these services are nonsensical/dishonest.
it fails with "touch your security key", hell who is this for? Epstein? I don't touch anything, especially not "security keys" (whatever tf that means)
If this is how little you think of an app with ~50 million monthly active users, I take it making apps with a billion MAU is something you routinely do during your toilet breaks, or...?
what did he do for messaging? Signal is hardly more private than goddamn Whatsapp. in fact, given that Whatsapp had not been heavily shilled as the "totally private messenger for journalists and whistleblowers :^)" by the establishment media, I distrust it less.
edit @ -4 points: please go ahead and explain why does Signal need your phone number and reject third party clients.
Yeah, it seems kind of funny how Signal is marketed as a somewhat paranoid solution, but most people run it on an iPhone out of the app store with no way to verify the source. All it takes is one villain to infiltrate one of a few offices and Signal falls apart.
Same goes for Whatsapp, but the marketing is different there.
Ok so which iPhone app can be verified from source?
Or is your problem that your peer might run the app on an insecure device? How would you exclude decade old Android devices with unpatched holes? I don't want to argue nirvana fallacy here but what is the solution you'd like to propose?
I don't think there is a solution -- Signal advertises itself as having a sort of security that isn't really possible with any commercially available device. You have to trust more people then just the person you're communicating with; if that's unacceptable then you need to give up a bunch of convenience and find another method of communicating.
Fortunately, the parties that you have to trust when you use signal haven't been malicious in any way, but that doesn't mean that they can't.
Also while we would expect heavy promotion for a trapped app from some agency it's also a very reasonable situation for a protocol/app that actually was secure.
You can of course never be sure but the fact that it's heavily promoted/used by people on both the whistleblowers, large corporations and multiple different National Officials at the same time is probably the best trustworthyness signal we can ever get for something like this.
(if all of these can trust it somewhaat it has to be a ridiculously deep conspiracy to not have leaked at least to some national security agency and forbidden to use(
> Signal is hardly more private than goddamn Whatsapp.
To be fair, that is largely because WhatsApp partnered with Open Whisper to bring the Signal protocol into Whatsapp. So effectively, you're saying "Signal-the-app is hardly more private than another app that shares Signal-the-protocol".
In practical terms, the only way for Signal to be significantly more private than WhatsApp is if WhatsApp were deliberately breaking privacy through some alternative channel (e.g. exfiltrating messages through a separate connection to Meta).
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 "with attestation". I don't like this trend and I don't think I'll be using such products
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
FHE is impossible. You cannot expect to compete on 100x more cost for the same service you provide (and there is no design for accelerated hardware (Tensor Core) on FHE).
Only 100x the cost? Really? Can you cite a reference how you get it that cheap?
FHE would be ideal. Relevant conversation from 6 months ago:
https://news.ycombinator.com/item?id=44601023
> ... 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.
ISTM that most people would rather give away their privacy than pay even a single cent for most things.
if (big if) you trust the execution environment, which is apparently auditable, and if (big if) you trust the TEE merkle hash used to sign the response is computer based on the TEE as claimed (and not a malicious actor spoofing a TEE that lives within an evil environment) and also if you trust the inference engine (vllm / sglanf, what have you) then I guess you can be confident the system is private.
Lots of ifs there, though. I do trust Moxie in terms of execution though. Doesn’t seem like the type of person to take half measures.
> if (big if) you trust the execution environment, which is apparently auditable
This is the key question.
What makes it so strange is such an execution environment would have clear applications outside of AI usage.
Agree. Products and services in the privacy space have a tendency to be incredibly misleading in their phrasing, framing, and overall marketing as to the nature of their assertions that sound pretty much like: "we totally can never ever see your messages, completely and utterly impossible". Proton is particularly bad for this, it's rather unfortunate to see this from "Moxie" as well.
It's like, come on you know exactly what you're doing, it's unambiguous how people will interpret this, so just stop it. Cue everyone arguing over the minutiae while hardly anyone points out how troubling it is that these people/entities have no concerns with being so misleading/dishonest...
"Server-side" is a bit of a misnomer here.
Sure, for e.g. E2E email, the expectation is that all the computation occurs on the client, and the server is a dumb store of opaque encrypted stuff.
In a traditional E2E chat app, on the other hand, you've still got a backend service acting as a dumb pipe, that shouldn't have the keys to decrypt traffic flowing through it; but you've also got multiple clients — not just your own that share your keybag, but the clients of other users you're communicating with. "E2E" in the context of a chat app, means "messages are encrypted within your client; messages can then only be decrypted within the destination client(s) [i.e. the client(s) of the user(s) in the message thread with you.]"
"E2E AI chat" would be E2E chat, with an LLM. The LLM is the other user in the chat thread with you; and this other user has its own distinct set of devices that it must interact through (because those devices are within the security boundary of its inference infrastructure.) So messages must decrypt on the LLM's side for it to read and reply to, just as they must decrypt on another human user's side for them to read and reply to. The LLM isn't the backend here; the chat servers acting as a "pipe" are the backend, while the LLM is on the same level of the network diagram as the user is.
Let's consider the trivial version of an "E2E AI chat" design, where you physically control and possess the inference infrastructure. The LLM infra is e.g. your home workstation with some beefy GPUs in it. In this version, you can just run Signal on the same workstation, and connect it to the locally-running inference model as an MCP server. Then all your other devices gain the ability to "E2E AI chat" with the agent that resides in your workstation.
The design question, being addressed by Moxie here, is what happens in the non-trivial case, when you aren't in physical possession of any inference infrastructure.
Which is obviously the applicable case to solve for most people, 100% of the time, since most people don't own and won't ever own fancy GPU workstations.
But, perhaps more interesting for us tech-heads that do consider buying such hardware, and would like to solve problems by designing architectures that make use of it... the same design question still pertains, at least somewhat, even when you do "own" the infra; just as long as you aren't in 100% continuous physical possession of it.
You would still want attestation (and whatever else is required here) even for an agent installed on your home workstation, so long as you're planning to ever communicate with it through your little chat gateway when you're not at home. (Which, I mean... why else would you bother with setting up an "E2E AI chat" in the first place, if not to be able to do that?)
Consider: your local flavor of state spooks could wait for you to leave your house; slip in and install a rootkit that directly reads from the inference backend's memory; and then disappear into the night before you get home. And, no matter how highly you presume your abilities to detect that your home has been intruded into / your computer has been modified / etc once you have physical access to those things again... you'd still want to be able to detect a compromise of your machine even before you get home, so that you'll know to avoid speaking to your agent (and thereby the nearby wiretap van) until then.
Just like your mobile device is one end of the end-to-end encryption, the TEE is the other end. If properly implemented, the TEE would measure all software and ensure that there are no side channels that the sensitive data could be read from.
By that logic SSL/TLS is also end-to-end encryption, except it isn't
When the server is the final recipient of a message sent over TLS, then yes, that is end-to-end encryption (for instance if a load balancer is not decrypting traffic in the middle). If the message's final recipient is a third party, then you are correct, an additional layer of encryption would be necessary. The TEE is the execution environment that needs access to the decrypted data to process the AI operations, therefore it is one end of the end-to-end encryption.
This interpretation basically waters down the meaning of end-to-end encryption to the point of uselessness. You may as well just say "encryption".
E2EE is usually applied in contexts where the message's final recipient is NOT the server on the other end of a TLS connection, so yes, this scenario is a stretch. The point is that in the context of an AI chat app, you have to decide on the boundary that you draw around the server components that are processing the request and necessarily need access to decrypted data, and call that one "end" of the connection.
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.
So ChatGPT is end-to-end encrypted?
No, because there is a web server that exposes an API that accepts a plaintext prompt and returns plaintext responses (even if this API is exposed via TLS). Since this web server is not the same server as the backend systems that are processing the prompt, it is a middle entity, rather than an end in the system.
The difference here is that the web server receiving a request for Confer receives an encrypted blob that only gets decrypted when running in memory in the TEE where the data will be used, which IS an end in the system.
Is your point that TLS is typically decrypted by a web server rather than directly by the app the web server forwards traffic to?
Yes. I include Cloudflare as part of the infrastructure of the ChatGPT service.
See my other comment, but the answer here is resoundingly "No". For the communication to be end-to-end encrypted the payload needs to be encrypted through all steps of the delivery process until it reached the final entity it is meant for. Infrastructure like cloudflare generally is configured to be able to read the full contents of the web request (TLS interception or Load balancing) and therefore the message lives for a time unencrypted in the memory of a system that is not the intended recipient.
Go read a book on basic cryptography. Please.
I have read through Handbook of Applied Cryptography.
What he did with messaging... So he will centralize all of it with known broken SGX metadata protections, weak supply chain integrity, and a mandate everyone supply their phone numbers and agree to Apple or Google terms of service to use it?
By default, the mobile app continually tries to connect to "updates2.signal.org"
Perhaps manual, user-controlled updates is not part of the design
If the source code is available^1 then surely someone has modified it to remove the phone number requirement, not to mention other improvements
1. https://github.com/signalapp/Signal-Server
It seems like Signal may be another example of "read-only" open source, where there is no expectation anyone will actually try to _use_ the source code. Instead, there is an expectation that everyone will use binaries distributed by a third party and allow remote code installation and RCE of software on their computers _at the third party's discretion_. In other words, all users will cede control to a third party
NB. This comment is not referring to the "Signal protocol". It pertains to _control_ over the software that implements it
The issue being there's not really a credible better option. Matrix is the next best, because they do avoid the tie-in to phone numbers and such, but their cryptographic design is not so great (or rather, makes more tradeoffs for usability and decentralisation), and it's a lot buggier and harder to use.
Full time matrix user and all my family and businesses use Matrix too. It works just fine, and with self hosting, I control the metadata on the servers I host for my orgs.
It actually is the least bad option available, and decentralization is always worth it even if development is slower and more complex as a consequence.
Do you know a better alternative that I can get my elderly parents and non-technical friends to use? I haven’t come across one and from my amateur POV it seems much better than WhatsApp or Telegram.
XMPP, as Matrix is pretty much centralized, unless you're fortunate enough to register outside of matrix.org. Both xmpp.org and jabber.org is no longer open for registration.
Matrix.
Not sure why you're gettimg downvoted. This is exactly what he did to instant messaging; extremely damaging to everyone and without solid arguments for such design.
Or, he took a barely niché messaging app plugin (OTR), improved it to provide forward secrecy for non-round trips, and deployed the current state-of-the art end-to-end encryption to over 3,000,000,000 users, as Signal isn't the only tool to use double-ratchet E2EE.
>broken SGX metadata protections
Citation needed. Also, SGX is just there to try to verify what the server is doing, including that the server isn't collecting metadata. The real talking is done by the responses to warrants https://signal.org/bigbrother/ where they've been able to hand over only two timestamps of when the user created their account and when they were last seen. If that's not good enough for you, you're better off using Tor-p2p messengers that don't have servers collecting your metadata at all, such as Cwtch or Quiet.
>weak supply chain integrity
You can download the app as an .apk from their website if you don't trust Google Play Store.
>a mandate everyone supply their phone numbers
That's how you combat spam. It sucks but there are very few options outside the corner of Zooko's triangle that has your username look like "4sci35xrhp2d45gbm3qpta7ogfedonuw2mucmc36jxemucd7fmgzj3ad".
>and agree to Apple or Google terms of service to use it?
Yeah that's what happens when you create a phone app for the masses.
Exactly. These arguments are so weak that they read more like a smear campaign than an actual technical discussion.
"You have to agree to Apple's terms to use it"? What's Signal meant to do, jailbreak your phone before installing itself on it?
Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
He IS a hacker from the 90s. It’s an assumed name. Plenty of hackers from the 90s have pseudonyms.
> so-called creator of some encryption protocol
All evidence points to him being one of the protocol’s designers, along with Trevor Perrin.
I’ve met both of them. The first time I met Moxie and talked about axolotl (as it was called back then) was in 2014. Moxie and Trevor strike me as having more integrity and conviction than most. There is no doubt in my mind that they are real and genuine.
Interestingly enough, some of the work Trevor did related to Signal’s cryptography was later used by Jason Donenfeld in the design of WireGuard.
> It screams honeypot like nothing else.
As you can see there is plenty of evidence suggesting otherwise.
>Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
This criticism has absolutely zero substance and honestly just reads like paranoid rambling. The Signal protocol has been independently formally analyzed [1] and has no known security issues.
[1] https://eprint.iacr.org/2016/1013
It's not about the protocol but other sides of the design. Example: https://news.ycombinator.com/item?id=38555810
The example you linked is about push notifications in general, nothing specific to the Signal app. If the concern is that your OS is compromised or spying on you, that's not something E2E encryption can protect against, whether it's Signal or any other app.
> nothing specific to the Signal app
The specific part is that Signal forces Google and Apple on its users, and forces the specific kind of push notifications, too.
So the argument against Signal is now "the creator's nickname sounds odd"? I mean, OK? Keep using WhatsApp, Telegram or Instagram if you think those are more private than Signal.
It's totally comments of people using Telegram.
It's just people having zero product sense, or an idea of what it means to target more than 0.01% of the market. The last comment said that Signal's problem is that it's mobile-first, which, how does someone even think that a messaging app should be anything other than mobile-first?
Having Google and Apple apps is fine. Having that be the only option, and the recommended option for high risk use cases is unforgivable.
Those aren't the only two options. You can buy a non-Google Android phone and install the APK on it.
How do I run Signal on my Librem 5?
You write an OS/2 emulator for it and use the OS/2 version of Signal, of course. How else?
Does anyone actually think that’s his real name?
I'm sure some people who don't realise it's a pseudonym do? Sounds like you're one of them.
Lol, why are you so mad? My while point is that he doesn’t reveal his actual name.
Oh man, I didn't think I'll actually see a reply with "u mad bro?" on this site. Anyway, good luck with your endeavors.
> You can download the app as an .apk from their website if you don't trust Google Play Store.
I wish apple & google provided a way to verify that an app was actually compiled from some specific git SHA. Right now applications can claim they're opensource, and claim that you can read the source code yourself. But there's no way to check that the authors haven't added any extra nasties into the code before building and submitting the APK / ios application bundle.
It would be pretty easy to do. Just have a build process at apple / google which you can point to a git repo, and let them build the application. Or - even easier - just have a way to see the application's signature in the app store. Then opensource app developers could compile their APK / ios app using github actions. And 3rd parties could check the SHA matches the app binaries in the store.
This is what F-droid does (well, I suspect most apps don't have reproducable builds that would allow 3rd-party verification), but Signal does not want 3rd-party builds of their client anyhow.
They could still figure out a way to attest their builds against source.
This is much harder when Signal actively goes against that.
>over 3,000,000,000 users
Is that a typo or are you really implying half the human population use Signal?
Edit: I misread, you are counting almost every messaging app user.
Just WhatsApp. Moxie's ideas are used in plenty of other messengers. The context was "what Moxie did for the field of instant messaging".
Yeah, whatsapp uses the same protocol.
>>broken SGX metadata protections
>Citation needed.
https://sgx.fail
https://en.wikipedia.org/wiki/Software_Guard_Extensions#List...
>> and agree to Apple or Google terms of service to use it?
> Yeah that's what happens when you create a phone app for the masses.
No, that's what happens when you actively forbid alternative clients and servers, prevent (secure) alternative methods of delivery for your app and force people to rely on the American megacorps known for helping governmental spying on users, https://news.ycombinator.com/item?id=38555810
It’s exciting to hear that Moxie and colleagues are working on something like this. They definitely have the skills to pull it off.
Few in this world have done as much for privacy as the people who built Signal. Yes, it’s not perfect, but building security systems with good UX is hard. There are all sorts of tradeoffs and sacrifices one needs to make.
For those interested in the underlying technology, they’re basically combining reproducible builds, remote attestation, and transparency logs. They’re doing the same thing that Apple Private Cloud Compute is doing, and a few others. I call it system transparency, or runtime transparency. Here’s a lighting talk I did last year: https://youtu.be/Lo0gxBWwwQE
I don't know, I'd say Signal is perfect, as it maximizes "privacy times spread". A solution that's more private wouldn't be as widespread, and thus wouldn't benefit as many people.
Signal's achievement is that it's very private while being extremely usable (it just works). Under that lens, I don't think it could be improved much.
>Signal's achievement is that it's very private while being extremely usable (it just works).
Exactly. Plus it basically pioneered the multi-device E2EE. E.g., Telegram claimed defaulting to E2EE would kill multi-client support:
"Unlike WhatsApp, we can allow our users to access their Telegram message history from several devices at once thanks to our built-in instant cloud sync"
https://web.archive.org/web/20200226124508/https://tgraph.io...
Signal just did it, and in a fantastic way given that there's no cross device key verification hassle or anything. And Telegram never caught up.
It's not perfect simply because it's a mobile-first app. That's Signal's main problem.
Yeah, most people don't even have a phone, let alone use it as their main method of communication...
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.)."
That is funny it won't even show us the homepage.
We are allowed into the blog though! https://confer.to/blog/
In KeePassXC:
> Your authenticator doesn't support encryption keys. Please try again using 1Password — some password managers like Bitwarden don't work yet.
Great new way to lock out potential new users. I bet large part of users interested in privacy are using Linux and some fork of Firefox.
I'm getting that that on macOS with Firefox 139+, for whatever reason...
I was also getting this, but works today.
Unless I misunderstand, this doesn't seem to address what I consider to be the largest privacy risk: the information you're providing to the LLM itself. Is there even a solution to that problem?
I mean, e2ee is great and welcome, of course. That's a wonderful thing. But I need more.
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.
I don’t know what model they’re using, but it looks like everything should be staying on their servers, not going back to, eg, OpenAI or Anthropic.
That is a highly misleading statement: the GPU runs with real weights and real unencrypted user plaintext, since it has to multiply matrices of plain text, which is passed on to the supposedly "secure VM" (protected by Intel/Nvidia promises) and encrypted there. In no way is it e2e, unless you count the GPU as the "end".
It is true that nVidia GPU-CC TEE is not secure against decapsulation attacks, but there is a lot of effort to minimize the attack surface. This recent paper gives a pretty good overview of the security architecture: https://arxiv.org/pdf/2507.02770
So what you are saying is that all the TEE and remote attestation and everything might work for CPU based workflows but they just don't work with GPU effectively being unencrpyted and anyone can read it from there?
Edit: https://news.ycombinator.com/item?id=46600839 this comment says that the gpu have such capabilities as well, So I am interested what you were mentioning in the first place?
> 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, 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.
As I read it, the attestation is simply that the server is running a particular kernel and application in the Secure Enclave using the hardware’s certification. That does not attest that there is no sidechannel. If exfiltration from the TEE is achieved, the attestation will not change.
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.
That's the main selling point of TEE though, isn't it? That what your hypothetical team could do, can't be done?
I don’t believe for a minute that it can’t be done even with physical access. Perhaps it’s more difficult.
> 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 trust them.
In most of modern life we trust to experts to some degree. I couldn't off the top of my head explain DH key exchange, I don't know if I'll ever understand elliptic curves, but I see that most of the cryptographic community understands them as good methods for many problems and if lots of experts who otherwise argue about anything will agree "what yes, of course DH is good for key exchange but that's beside the point and djb is still wrong about florbnitz keys" then it's likely DH is indeed good for key exchange.
If everyone had to understand every detail to trust in tech we would not have nuclear plants or coast around on huge flammable piles of charged lithium
In theory, you trust the "crowd" (rather than the hosting entity) because if they don't do what they said, the "crowd" should make a noise about it and you would know.
That’s true, but it’s still a distinct threat model from “we use the API of a company run by one of the least trustworthy humans on the planet.” We can talk through side channel attacks and whatnot, but we’re discussing issues with Confer’s implementation, not trusting a different third party.
We'll add that link to the toptext as well. Thanks!
(It got submitted a few times but did not get any comments - might as well consolidate these threads)
I do wonder what models it uses under the hood.
ChatGPT already knows more about me than Google did before LLMs, but would I switch to inferior models to preserve privacy? Hard tradeoff.
As someone who has spent a good time of time working on trusted compute (in the crypto domain) I'll say this is generally pretty well thought out, doesn't get us to an entirely 0-trust e2e solution, but is still very good.
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.
An interesting take on the AI model. I'm not sure what their business model is like, as collecting training data is the one thing that free AI users "pay" in return for services, but at least this chat model seems honest.
Using remote attestation in the browser to attest the server rather than the client is refreshing.
Using passkeys to encrypt data does limit browser/hardware combinations, though. My Firefox+Bitwarden setup doesn't work with this, unfortunately. Firefox on Android also seems to be broken, but Chrome on Android works well at least.
Collecting the email doesn't inspire much confidence. An account-number model like Mullvad's would seem preferable, or you could go all-in on syncable passkeys as the only user identifier.
The web app itself feels poorly made—almost vibe-coded in places: nonsensical gradients, UI elements rendering in flashes of white, and subtly off margins and padding.
The model itself is unknown, but speaks with the cadence reminiscent of GPT-4o.
I'm no expert, but calling this "end-to-end encrypted" is only accurate if one end is your client and the other is a very much interposable GPU (assuming vendor’s TEE actually works—something that, in light of tee.fail, feels rather optimistic).
> An account-number model like Mullvad's would seem preferable
Thank you! :)
> .. assuming vendor’s TEE actually works
For sure TEEs have a rich history of vulnerabilities and nuanced limitations in their threat models. As a concept however, it is really powerful, and implementers will likely get things more and more right.
As for GPUs, some of Nvidia’s hardware does support remote attestation.
https://docs.nvidia.com/attestation/index.html
I really really want this, however keypass doesn't work with bitwarden and no, I'm not moving to 1Password.
I’m missing something, won’t the input to the llm necessarily be plaintext? And the output too? Then, as long as the llm has logs, the real input by users will be available somewhere in their servers
According to the article:
>Data and conversations originating from users and the resulting responses from the LLMs are encrypted in a trusted execution environment (TEE) that prevents even server administrators from peeking at or tampering with them.
I think what they meant to say is that data is decrypted only in a trusted execution environment, and otherwise is stored/transmitted in an encrypted format.
Well, if anyone could do it properly, Moxie certainly has the track record.
https://news.ycombinator.com/item?id=46619643
"trusted execution environment" != end-to-end encryption
The entire point of E2EE is that both "ends" need to be fully under your control.
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.
That is where the attestation comes in to show that the environment is only running cryptographically verified versions of open source software that does not have the mechanisms to allow tampering.
That's insufficient. Code signing doesn't do anything against theft or malfeasance by internal actors. Or external ones, I suppose.
If the software can modify data legitimately, it can be tampered with.
The point of measured environments like the TEE is that you are able to make guarantees about all the software that is running in the environment (verified with the attestation). "If the software can modify data legitimately, it can be tampered with." - the software that makes up the SBOM for these environments do not expose administrator functions to access the decrypted data.
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.
They do if you're both the sender and intended recipient
because ... ?
The best private LLM is the one you host yourself.
Interestingly the confer image on GitHub doesn’t seem to include in the attestation the model weights (they seem loaded from a mounted ext4 disk without dm-verity). Probably this doesn’t compromise the privacy of the communication (as long as the model format is not containing any executable part) but it exposes users to a “model swapping” attack, where the confer operator makes a user talk to an “evil” model without they can notice it. Such evil model may be fine tuned to provide some specifically crafted output to the user. Authenticating the model seems important, maybe it is done at another level of the stack?
Does it say anywhere which model it’s using?
I see references to vLLM in the GitHub but not which actual model (Llama, Mistral, etc.) or if they have a custom fine tune, or you give your own huggingface link?
> 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 webcams, or am I missing something?
Windows Hello should work fine just by PIN, it's the platform authentication part that's important, not the way you unlock it
I am super curious about this. I wonder baseline it needs to meet to pull me away from using ChatGPT or Claude.
My usage of it would be quite different than ChatGPT. I’d be much freer in what I ask it.
I think there’s a real opportunity for something like this. I would have thought Apple would have created it but they just announced they’ll use Gemini.
Awesome launch Moxie!
Again with the confidential VM and remote attestation crypto theater? Moxie has a good track record in general, and yet he seems to have a huge blindspot in trusting Intel broken "trusted VM" computing for some inexplicable reason. He designed the user backups of Signal messages to server with similar crypto secure "enclave" snake-oil.
AFAIK the signal backups use symmetric encryption with user generated and controlled keys and anonymous credentials (https://signal.org/blog/introducing-secure-backups/). Do you have a link about the usage of sgx there?
Also fwiw I think tees and remote attestation are a pretty pragmatic solution here that meaningfully improves on the current state of the art for llm inference and I'm happy to see it.
I think there is only so much you can do practically. Without a secure "enclave", there isn't really much you can do. What's your alternative?
Aha. This, ideally, is a job for local only. Ollama et al.
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.
I have a hybrid model here. For many many tasks a local 12b or similar works totally fine. For the rest I use cloud, those things tend to be less privacy sensitive anyway.
Like when someone sends me a message, I made something that categorises it for urgency. If I'd use cloud it means they get a copy of all those messages. But locally there's no issue and complexity wise it's pretty low for an LLM.
Things like research jobs I do do in cloud, but they don't really contain any personal content, they just research using sources they already have access to anyway. Same with programming, there's nothing really sensitive in there.
Nice. You're exactly nailing what I'm working towards already. I'm programming with gemini for now and have no problem there, but the home use case I found for local Ollama was "taking a billion old bookmarks and tagging them." Am looking forward to pointing ollama at more personal stuff.
Yeah I have two servers now. One with a big AMD for decent LLM performance. And one for a smaller Nvidia that runs mostly Whisper and some small models for side tasks.
At least Cocoon and similar services relying on TEE don't call this end-to-end encryption. Hardware DRM is not E2EE, it's security by obscurity. Not to say it doesn't work, but it doesn't provide mathematically strong guarantees either.
The website is: https://confer.to/
"Confer - Truly private AI. Your space to think."
"Your Data Remains Yours, Never trained on. Never sold. Never shared. Nobody can access it but you."
"Continue With Google"
Make of that what you will.
My issue is it claims to be end-to-end encrypted, which is really weird. Sure, TLS between you and your bank's server is end-to-end encrypted. But that puts your trust on the service provider.
Usually in a context where a cypherpunk deploys E2EE it means only the intended parties have access to plaintexts. And when it's you having chat with a server it's like cloud backups, the data must be encrypted by the time it leaves your device, and decrypted only once it has reached your device again. For remote computing, that would require LLM handles ciphertexts only, basically, fully homomorphic encryption (FHE). If it's that, then sure, shut up and take my money, but AFAIK the science of FHE isn't nearly there yet.
So the only alternative I can see here is SGX where client verifies what the server is doing with the data. That probably works against surveillance capitalism, hostile takeover etc., but it is also US NOBUS backdoor. Intel is a PRISM partner after all, and who knows if national security requests allow compelling SGX keys. USG did go after Lavabit RSA keys after all.
So I'd really want to see this either explained, or conveyed in the product's threat model documentation, and see that threat model offered on the front page of the project. Security is about knowing the limits of the privacy design so that the user can make an informed decision.
Looks like using Google for login. You can also "Continue with Email." Logging in with Google is pretty standard.
It is not privacy oriented if you are sharing login, profile information with Google and Confer.
It wouldn't be long until Google and Gemini can read this information and Google knows you are using Confer.
Wouldn't trust it regardless if Email is available.
The fact that confer allows Google login shows that Confer doesn't care about users privacy.
You don’t have to use Google login though? People building solutions like this that aim for broad adoption have to make certain compromises and this seems OK to me (just talking about offering a social login option, haven’t checked the whole project in detail)
Most people don't care about Google knowing whether they're using a particular app. If they do, they have the option not to use it. The main concern is that the chats themselves are E2E encrypted, which we have every reason to believe.
This is a perfect example of purism vs. pragmatism. Moxie is a pragmatist who builds things that the average person can actually use. If it means that millions of people who would otherwise have used ChatGPT will migrate because of the reduced friction and get better privacy as a result, that's a win even if at the margin they're still leaking one insignificant piece of metadata to Google.
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-...
Yes, the TEE is CPU + H100 GPU.
Huh, thanks!
MM is basically up-selling his _Signal_ trust score. Granted, Signal/RedPhone predecessor upped the game but calling this E2E encrypted AI chat is a bit of a stretch..
Interesting! I wonder a) how much of an issue this addresses, ie how much are people worried about privacy when they use other LLMs? and b) how much of a disadvantage it is for Confer not to be able to read/ train in user data.
I am shocked at how quickly everyone is trying to forget that TEE.fail happened, and so now this technology doesn't prove anything. I mean, it isn't useless, but DNS/TLS and physical security/trust become load bearing, to the point where the claims made by these services are nonsensical/dishonest.
Exactly. That's why we're building an offline device for portable AI. Check it out at https://atomcomputers.org
How does inference work with a TEE, isn’t performance a lot more restricted?
Has anyone gotten access yet?
it fails with "touch your security key", hell who is this for? Epstein? I don't touch anything, especially not "security keys" (whatever tf that means)
Backdoor it?
Add a defunct cryptotoken?
Hey, Telegram had one. He had to get to feature parity.
Do what he did for messaging? Make a thing almost nobody uses?
3 billion WhatsApp users use protocol built on his labor, every day.
If this is how little you think of an app with ~50 million monthly active users, I take it making apps with a billion MAU is something you routinely do during your toilet breaks, or...?
what did he do for messaging? Signal is hardly more private than goddamn Whatsapp. in fact, given that Whatsapp had not been heavily shilled as the "totally private messenger for journalists and whistleblowers :^)" by the establishment media, I distrust it less.
edit @ -4 points: please go ahead and explain why does Signal need your phone number and reject third party clients.
Yeah, it seems kind of funny how Signal is marketed as a somewhat paranoid solution, but most people run it on an iPhone out of the app store with no way to verify the source. All it takes is one villain to infiltrate one of a few offices and Signal falls apart.
Same goes for Whatsapp, but the marketing is different there.
Ok so which iPhone app can be verified from source?
Or is your problem that your peer might run the app on an insecure device? How would you exclude decade old Android devices with unpatched holes? I don't want to argue nirvana fallacy here but what is the solution you'd like to propose?
I don't think there is a solution -- Signal advertises itself as having a sort of security that isn't really possible with any commercially available device. You have to trust more people then just the person you're communicating with; if that's unacceptable then you need to give up a bunch of convenience and find another method of communicating.
Fortunately, the parties that you have to trust when you use signal haven't been malicious in any way, but that doesn't mean that they can't.
He implemented E2EE in Whatsapp as well.
> Signal is hardly more private than goddamn Whatsapp
Kind of because Whatsapp adopted Signal's E2EE... And not even that long ago!
If by "not even that long ago" you mean "a few months short of a decade ago", sure.
Even if you discount Signal he did more or less design the protocol that WhatsApp is using https://techcrunch.com/2014/11/18/end-to-end-for-everyone/
Also while we would expect heavy promotion for a trapped app from some agency it's also a very reasonable situation for a protocol/app that actually was secure.
You can of course never be sure but the fact that it's heavily promoted/used by people on both the whistleblowers, large corporations and multiple different National Officials at the same time is probably the best trustworthyness signal we can ever get for something like this.
(if all of these can trust it somewhaat it has to be a ridiculously deep conspiracy to not have leaked at least to some national security agency and forbidden to use(
> Signal is hardly more private than goddamn Whatsapp.
To be fair, that is largely because WhatsApp partnered with Open Whisper to bring the Signal protocol into Whatsapp. So effectively, you're saying "Signal-the-app is hardly more private than another app that shares Signal-the-protocol".
In practical terms, the only way for Signal to be significantly more private than WhatsApp is if WhatsApp were deliberately breaking privacy through some alternative channel (e.g. exfiltrating messages through a separate connection to Meta).