X
My feedback
125 results found
-
335 votesX
supported this idea
·
-
343 votesX
supported this idea
·
-
374 votesX
supported this idea
·
-
347 votesX
supported this idea
·
-
1 voteX
shared this idea
·
An error occurred while saving the comment An error occurred while saving the comment 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)*
### 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/