The open-source boundary matters. Proton publishes the Lumo web client in its WebClients monorepo and released the iOS and Android app code with Lumo 1.1. Treat that as client transparency plus open-source model selection, not as a public server or inference stack.
Use Proton Lumo when you want cloud AI inside the Proton ecosystem, encrypted chat history, no account requirement for guest use, and European jurisdiction. Do not use it for threat models that require cryptographic confidentiality during inference. For that, use Confer for attested TEE inference or Ensu for local inference.
Sources: Proton’s launch post, Lumo security model, Lumo privacy support, Lumo 1.1 open-source mobile note, and Proton Lumo.
]]>The trust model is end-to-TEE, not classic end-to-end encryption. The operator is designed not to see prompts by default, but the trust boundary moves to TEE hardware, remote attestation, reproducible builds, and the transparency log. TEE side channels remain a risk class to evaluate separately.
The current primary docs do not publish a formal third-party security audit. Confer’s attestation and reproducible-build path is continuous verifiability, not the same thing as an audit. The current docs also do not claim anonymous paid signup or anonymous payment, so treat the paid tier as identifying until Confer documents otherwise.
Use Confer when the prompts themselves are sensitive and you still need cloud inference. Use Ensu when local-only inference is a better fit, and use Proton Lumo when Proton ecosystem integration matters more than inference-time confidentiality.
Sources: About Confer, Private inference, passkey encryption, and ConferLabs on GitHub.
]]>