[HN Gopher] Confer - End to end encrypted AI chat
___________________________________________________________________
Confer - End to end encrypted AI chat
_Signal creator Moxie Marlinspike wants to do for AI what he did
for messaging_ - https://arstechnica.com/security/2026/01/signal-
creator-moxi... _Private Inference_ :
https://confer.to/blog/2026/01/private-inference/
Author : vednig
Score : 64 points
Date : 2026-01-13 13:45 UTC (9 hours ago)
(HTM) web link (confer.to)
(TXT) w3m dump (confer.to)
| AdmiralAsshat wrote:
| Well, if anyone could do it properly, Moxie certainly has the
| track record.
| f_allwein wrote:
| 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.
| JohnFen wrote:
| 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.
| roughly wrote:
| 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.
| dang wrote:
| 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)
| jeroadhd wrote:
| 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".
| Imustaskforhelp wrote:
| 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?
| AlanYx wrote:
| 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
| JohnFen wrote:
| > 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.
| internet_points wrote:
| > 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.
| binary132 wrote:
| 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.
| JohnFen wrote:
| > 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.
| jeroenhd wrote:
| 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.
| datadrivenangel wrote:
| 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.)."
| crtasm wrote:
| That is funny it won't even show us the homepage.
|
| We are allowed into the blog though! https://confer.to/blog/
| Marsymars wrote:
| I'm getting that that on macOS with Firefox 139+, for whatever
| reason...
| butz wrote:
| 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.
| hiimkeks wrote:
| 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.
| dfajgljsldkjag wrote:
| 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-...
| donaldihunter wrote:
| Yes, the TEE is CPU + H100 GPU.
| hiimkeks wrote:
| Huh, thanks!
| shawnz wrote:
| 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
| Stefan-H wrote:
| 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.
| paxys wrote:
| By that logic SSL/TLS is also end-to-end encryption, except
| it isn't
| Stefan-H wrote:
| 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.
| paxys wrote:
| 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.
| charcircuit wrote:
| 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.
| shawnz wrote:
| This interpretation basically waters down the meaning of
| end-to-end encryption to the point of uselessness. You
| may as well just say "encryption".
| Stefan-H wrote:
| 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.
| liuliu wrote:
| 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).
| shawnz wrote:
| There's FHE, but that's probably an even more difficult
| technical challenge than doing everything locally
| gardnr wrote:
| FHE would be ideal. Relevant conversation from 6 months
| ago:
|
| https://news.ycombinator.com/item?id=44601023
| liuliu wrote:
| 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).
| ignoramous wrote:
| > _... 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.
| binary132 wrote:
| ISTM that most people would rather give away their privacy
| than pay even a single cent for most things.
| 2bitencryption wrote:
| 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.
| derefr wrote:
| "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.
| jeroadhd wrote:
| 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.
| liuliu wrote:
| 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?
| tkz1312 wrote:
| 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.
| paxys wrote:
| "trusted execution environment" != end-to-end encryption
|
| The entire point of E2EE is that both "ends" need to be fully
| under your control.
| Stefan-H wrote:
| 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?
| paxys wrote:
| 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.
| Stefan-H wrote:
| 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.
| optymizer wrote:
| 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.
| letmetweakit wrote:
| How does inference work with a TEE, isn't performance a lot more
| restricted?
| LordDragonfang wrote:
| > 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?
| literalAardvark wrote:
| Windows Hello should work fine just by PIN, it's the platform
| authentication part that's important, not the way you unlock it
| slipheen wrote:
| 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?
| jdthedisciple wrote:
| The best private LLM is the one you host yourself.
| orbital-decay wrote:
| 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.
| throwaway35636 wrote:
| 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?
| jrm4 wrote:
| 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.
| azmenak wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-13 23:02 UTC)