Implement TEE-Based Confidential Computing for Lumo Inference
Feature Request: Implement TEE-Based Confidential Computing for Lumo Inference
Summary
Lumo's current security model does not protect user prompts during inference — the window when plaintext is most exposed and most exploitable. This is not a theoretical concern; it is a documented architectural gap with a proven, production-ready solution that a direct competitor is already shipping.
The Problem
Lumo's security model blog post dismisses inference-time privacy by framing the only alternative as homomorphic encryption (HE), correctly noting it is impractically slow. However, this framing is a false dichotomy.
As Proton's own documentation acknowledges:
"prompts are asymmetrically encrypted so only the Lumo GPU servers are able to decrypt them"
This means:
Proton-controlled GPU servers decrypt and process user prompts in plaintext
During this window, the data is accessible to anyone with server access — including Proton staff, infrastructure providers, or authorities serving a lawful order
The privacy guarantee during inference is based entirely on policy and trust, not cryptographic enforcement
This is the same "we promise not to look" model that has repeatedly failed users across the tech industry when legal pressure is applied.
The Solution: Trusted Execution Environments (TEEs)
Confer — built by Moxie Marlinspike (creator of Signal) — has demonstrated that TEE-based confidential computing for LLM inference is practical and production-ready today, without the performance penalties of homomorphic encryption.
Confer's approach, documented publicly at https://confer.to/blog/2026/01/private-inference/:
Confidential VMs: Inference runs inside a hardware-enforced enclave using AMD SEV-SNP or Intel TDX. The host OS, data center operator, and even Confer's own developers cannot access the TEE's memory or execution state.
Noise Pipes: User prompts are encrypted end-to-end from the client device directly into the TEE. Plaintext never exists outside the enclave.
Remote Attestation: Users can cryptographically verify that the correct, unmodified code is running inside the enclave — making it independently auditable, not just trust-based.
This runs at normal inference speeds with no meaningful latency penalty — directly contradicting the implication in Lumo's security model post that practical inference-time privacy is not achievable.
Why This Matters
Lumo's current model is vulnerable in scenarios Proton cannot control:
A government serves a lawful intercept order during an active inference session
A data centre provider (even in Europe) is compelled to provide access to running server memory
An insider threat at Proton with GPU server access
A future change in Swiss or EU law expanding surveillance obligations
GDPR jurisdiction and no-logs policies do not protect against real-time access to plaintext during inference. Only hardware-enforced isolation does.
Requested Changes
Migrate Lumo inference to run inside Confidential VMs (AMD SEV-SNP / Intel TDX) so that the host and operator never have access to plaintext prompts or responses.
Implement remote attestation so users and independent auditors can verify cryptographically what code is running on Lumo's servers — consistent with Proton's open-source transparency commitments.
Update the security model documentation to accurately reflect the current limitations during inference, rather than implying the problem is unsolvable.
Prior Art & References
Confer private inference blog post: https://confer.to/blog/2026/01/private-inference/
AMD SEV-SNP confidential computing: https://www.amd.com/en/developer/sev.html
Intel TDX: https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html
Proton Lumo security model (current): https://proton.me/blog/lumo-security-model
Notes
This is not a criticism of Lumo's encryption at rest or no-logs policy, both of which are meaningful. This is specifically about the inference-time gap, which is the highest-risk window and the one most likely to be exploited by legal compulsion. Proton has the engineering capability and the stated mission to close this gap. Confer has shown it is technically achievable. The question is whether it is a priority.
Details added here:
X
shared this idea
-
X
commented
### Additional Context: This Is Not an Isolated Issue — It's a Pattern (2/2)
#### 4. Lumo — The Pattern Repeats
Proton's own security model documentation states:
> *"prompts are asymmetrically encrypted so only the Lumo GPU servers are able to decrypt them"*
This is the same structure as above: technically accurate in the narrowest sense while omitting that Proton-controlled servers decrypt and process prompts in plaintext during inference — with no hardware-enforced isolation preventing Proton staff, infrastructure providers, or authorities with a lawful order from accessing that data.
The security model post dismisses inference-time privacy by citing homomorphic encryption as impractically slow — without mentioning TEEs, which Confer (confer.to) has already deployed in production using AMD SEV-SNP and Intel TDX at normal inference speeds. This omission in a technical security document is not accidental. Full GitHub issue with technical detail: [link]
---
#### 5. Anticipated Counterarguments — Addressed
**"Proton complies with the law. That's transparent."**
No one disputes legal compliance is required. The argument is about what happens before a legal order arrives. A lock that opens with a master key is still a lock — but marketing it as a vault that "cannot be opened" is a different claim. There is no law requiring a company to *retain* decryptable data. There is only law requiring them to produce data they *have*. Signal complies with legal orders by having nothing to produce. That is also legal compliance — just honest architecture. Compliance with law and protection of user data are not mutually exclusive. They become mutually exclusive only when you build a system that retains data that can be handed over, then market it as if you hadn't.**"Signal also complies with legal orders."**
Yes. When governments demand Signal hand over user data, Signal complies with the law by telling them it has nothing. The legal obligation is identical. The outcome for users is entirely different. The point of privacy by design is not to resist law — it is to make the data unavailable so compliance is harmless.**"TEEs would compromise performance / are too complex."**
Confer has demonstrated this is false in production, at commercial scale, today. The performance argument was credible before January 2026. It is not credible now.**"No system is 100% secure."**
The request is not for perfection. It is for the gap between Lumo's marketing and Lumo's architecture to be closed — either by implementing TEEs or by correcting the marketing to accurately describe what is and is not protected. Either is acceptable. Neither has happened.---
#### The Core Issue
What Proton is building is a lock that works under normal conditions and fails under adversarial ones — which is precisely the condition a lock needs to withstand. A privacy tool that protects you from ad-tech but not from a government order protects you from the threat you were never worried about.
The point of privacy technology is not to make surveillance slightly more inconvenient. It is to make it structurally impossible. Signal understood this. Mullvad understood this. Confer was built on this exact principle. The technology to apply it to AI inference exists and is shipping today.
At 100 million users and €100M+ in infrastructure, the gap between Proton's marketing and its architecture is no longer a startup's growing pains. It is a choice. The people who pay the price are not those who read the privacy policy footnotes — they are the journalists, activists, and legal professionals who trusted the headline.
---
**References:**
- Sam Bent, "The Proton Problem": https://www.sambent.com/proton-helped-the-fbi-unmask-a-protester-then-said-they-didnt/
- Sam Bent, "Proton Meet Isn't What They Told You": https://www.sambent.com/proton-meet-isnt-what-they-told-you/
- Privacy Guides — Proton misleading marketing thread: https://discuss.privacyguides.net/t/how-should-we-handle-protons-misleading-marketing/
- Confer private inference blog: https://confer.to/blog/2026/01/private-inference/
- Proton VPN kill switch Reddit confirmation: https://www.reddit.com/r/ProtonVPN/comments/1iu2a2i/protonvpn_leaks_my_ip_when_switching_vpn_networks/ -
X
commented
### Additional Context: This Is Not an Isolated Issue — It's a Pattern (1/2)
The inference-time gap in Lumo is not an isolated technical oversight. It is the latest instance of a documented, repeating pattern at Proton: marketing that implies stronger privacy guarantees than the architecture actually delivers, discovered after users have already trusted the product with sensitive data.
---
#### 1. The Kill Switch (Proton VPN / macOS)
Proton's VPN kill switch marketing states it protects your IP address during server switches. Proton's own support team has confirmed in writing on Reddit that **"Kill Switch on Mac will not prevent your device from connecting to the internet during manual disconnection events."** This is not a footnote — it is the primary scenario users enable the kill switch for.
Mullvad VPN solves this on the same operating system by writing directly to macOS's PF firewall with atomic transactions, rather than relying on Apple's VPN framework. The technical solution exists. Proton has not shipped it. Meanwhile, the marketing page continues to describe the kill switch without qualifying that it does not work on macOS during the exact scenarios users depend on it for.
Privacy Guides has an open thread titled "How should we handle Proton's misleading marketing?" specifically on this issue: https://discuss.privacyguides.net/t/how-should-we-handle-protons-misleading-marketing/
---
#### 2. Proton Meet and the CLOUD Act Infrastructure
Proton launched Proton Meet explicitly citing the US CLOUD Act as the reason to switch from Zoom and Google Meet. Their website states: *"All of our API and database servers are in our European data centers, outside of US jurisdiction and subjugation to US laws such as the CLOUD Act."*
Security researcher Sam Bent performed a network capture of live Proton Meet calls and found active connections to Oracle Corporation (Phoenix, AZ) and Amazon EC2 (us-west-2, Oregon). The reason: Proton Meet is built on **LiveKit Cloud**, a California corporation explicitly subject to the CLOUD Act, with sub-processors including DigitalOcean (US), Google (US), Oracle (US), Cockroach Labs (US), and Datadog (US) — zero non-US companies in the infrastructure chain.
LiveKit's own Data Processing Addendum states: *"Observability Data, telemetry, and related logs are stored and processed in the United States regardless of the selected Pinned Region."*
Proton built Proton Meet to escape the CLOUD Act, on CLOUD Act infrastructure, and did not disclose LiveKit as a sub-processor in their Meet privacy policy.
Full analysis: https://www.sambent.com/proton-meet-isnt-what-they-told-you/---
#### 3. Proton Mail — "Zero Access" With an Asterisk
Proton Mail's marketing heavily implies Proton cannot read your emails. Their own privacy policy states:
> *"unencrypted messages sent from external providers to your Account... are scanned for spam and viruses... Such inbound messages are scanned for spam in memory"*
Emails arrive in plaintext, are scanned in memory on Proton's servers, and then encrypted. The "zero access" claim applies only to data **at rest**, not to the moment of ingest. This distinction is buried in the privacy policy and absent from the marketing.
Sam Bent's full analysis: https://www.sambent.com/proton-helped-the-fbi-unmask-a-protester-then-said-they-didnt/
*(Continued in Part 2)*