Skip to content

Proton’s Lumo AI chatbot: not end-to-end encrypted, not open source

Technology
81 41 1
  • Proton has my vote for fastest company ever to completely enshittify.

    Does it even count as enshittifying if they were born that way?

  • Well, I'm keeping mine. I'm actually very happy with it. This article is full slop, with loads of disinformation, and an evident lack of research. It looks like it was made with some Ai bullshit and the writer didn't even check what that thing vomited.

    It was Snowball! He wrote the article! Must have been!

  • Any business putting "privacy first" thing that works only on their server, and requires full access to plaintext data to operate, should be seen as lying.

    I've been annoyed by proton for a long while; they do (did?) provide a seemingly adequate service, but claims like "your mails are safe" when they obviously had to have them in plaintext on their server, even if only for compatibility with current standards, kept me away from them.

    they obviously had to have them in plaintext on their server, even if only for compatibility with current standards

    I don’t think that’s obvious at all. On the contrary, that’s a pretty bold claim to make, do you have any evidence that they’re doing this?

  • Proton has my vote for fastest company ever to completely enshittify.

    How have they enshittified? I haven’t noticed anything about their service get worse since they started.

  • they obviously had to have them in plaintext on their server, even if only for compatibility with current standards

    I don’t think that’s obvious at all. On the contrary, that’s a pretty bold claim to make, do you have any evidence that they’re doing this?

    Incoming Emails that aren't from proton, or PGP encrypted (which are like 99% of emails), arrives at Proton Servers via TLS which they decrypt and then have the full plaintext. This is not some conspiracy, this is just how email works.

    Now, Proton and various other "encrypted email" services then take that plaintext and encypt it with your public key, then store the ciphertext on their servers, and then they're supposed to discard the plaintext, so that in case of a future court order, they wouldn't have the plaintext anymore.

    But you can't be certain if they are lying, since they do necessarily have to have access to the plaintext for email to function. So "we can't read your emails" comes with a huge asterisk, it onlu applies to those sent between Proton accounts or other PGP encrypted emails, your average bank statement and tax forms are all accessible by Proton (you're only relying on their promise to not read it).

  • Incoming Emails that aren't from proton, or PGP encrypted (which are like 99% of emails), arrives at Proton Servers via TLS which they decrypt and then have the full plaintext. This is not some conspiracy, this is just how email works.

    Now, Proton and various other "encrypted email" services then take that plaintext and encypt it with your public key, then store the ciphertext on their servers, and then they're supposed to discard the plaintext, so that in case of a future court order, they wouldn't have the plaintext anymore.

    But you can't be certain if they are lying, since they do necessarily have to have access to the plaintext for email to function. So "we can't read your emails" comes with a huge asterisk, it onlu applies to those sent between Proton accounts or other PGP encrypted emails, your average bank statement and tax forms are all accessible by Proton (you're only relying on their promise to not read it).

    Ok yeah thats a far cry from Proton actually “Having your unencrypted emails on their servers” as if they’re not encrypted at rest.

    There’s the standard layer of trust you need to have in a third party when you’re not self hosting. Proton has proven so far that they do in fact encrypt your emails and haven’t given any up to authorities when ordered to so I’m not sure where the issue is. I thought they were caught not encrypting them or something.

  • Regarding the fact that proton stops hosting in Switzerland :
    I thought it was because of new laws in Switzerland and that they hzf not much of a choice ?

    The law isn't a law yet, its a just a proposal. Proton is still in Switzerland, but they said they're gonna move if the surveillance law actually becomes law.

  • It's probably different. The crypto bubble couldn't actually do much in the field of useful things.

    Now, I'm saying that with a HUGE grain of salt, but there are decent application with LLM (let's not call that AI). Unfortunately, these usages are not really in the sight of any business putting tons of money into their "AI" offers.

    I kinda hope we'll get better LLM hardware to operate privately, using ethically sourced models, because some stuff is really neat. But that's not the push they're going for for now. Fortunately, we can already sort of do that, although the source of many publicly available models is currently… not that great.

    There's absolutely a push for specialized hardware, look up that company called Groq !

  • Is it like crypto where cpus were good and then gpus and then FPGAs then ASICs? Or is this different?

    I think it's different. The fundamental operation of all these models is multiplying big matrices of numbers together. GPUs are already optimised for this. Crypto was trying to make the algorithm fit the GPU rather than it being a natural fit.

    With FPGAs you take a 10x loss in clock speed but can have precisely the algorithm you want. ASICs then give you the clock speed back.

    GPUs are already ASICS that implement the ideal operation for ML/AI, so FPGAs would be a backwards step.

  • It was Snowball! He wrote the article! Must have been!

    Link Preview Image

  • There's absolutely a push for specialized hardware, look up that company called Groq !

    Yes, but at this point most specialized hardware only really work for inference. Most players are training on NVIDIA GPUs, with the primary exception of Google who has their own TPUs, but even these have limitations compared to GPUs (certain kinds of memory accesses are intractably slow, making them unable to work well for methods like instant NGP).

    GPUs are already quite good, especially with things like tensor cores.

  • It's probably different. The crypto bubble couldn't actually do much in the field of useful things.

    Now, I'm saying that with a HUGE grain of salt, but there are decent application with LLM (let's not call that AI). Unfortunately, these usages are not really in the sight of any business putting tons of money into their "AI" offers.

    I kinda hope we'll get better LLM hardware to operate privately, using ethically sourced models, because some stuff is really neat. But that's not the push they're going for for now. Fortunately, we can already sort of do that, although the source of many publicly available models is currently… not that great.

    LLMs are absolutely amazing for a lot of things. I use it at work all the time to check code blocks or remembering syntax. It is NOT and should NOT be your main source of general information and we collectively have to realise how problematic and energy consuming they are.

  • This post did not contain any content.

    First of all...

    Why does an email service need a chatbot, even for business? Is it an enhanced search over your emails or something? Like, what does it do that any old chatbot wouldn't?

    EDIT: Apparently nothing. It's just a generic Open Web UI frontend with Proton branding, a no-logs (but not E2E) promise, and kinda old 12B-32B class models, possibly finetuned on Proton documentation (or maybe just a branded system prompt). But they don't use any kind of RAG as far as I can tell.

    There are about a bajillion of these, and one could host the same thing inside docker in like 10 minutes.

    ...On the other hand, it has no access to email I think?

  • This post did not contain any content.

    OK, so I just checked the page:

    Looks like a generic Open Web UI instance, much like Qwen's: https://openwebui.com/

    Based on this support page, they are using open models and possibly finetuning them:

    The models we’re using currently are Nemo, OpenHands 32B, OLMO 2 32B, and Mistral Small 3

    But this information is hard to find, and they aren't particularly smart models, even for 32B-class ones.

    Still... the author is incorrect, they specify how long requests are kept:

    When you chat with Lumo, your questions are sent to our servers using TLS encryption. After Lumo processes your query and generates a response, the data is erased. The only record of the conversation is on your device if you’re using a Free or Plus plan. If you’re using Lumo as a Guest, your conversation is erased at the end of each session. Our no-logs policy ensures wekeep no logs of what you ask, or what Lumo replies. Your chats can’t be seen, shared, or used to profile you.

    But it also mentions that, as is a necessity now, they are decrypted on the GPU servers for processing. Theoretically they could hack the input/output layers and the tokenizer into a pseudo E2E encryption scheme, but I haven't heard of anyone doing this yet... And it would probably be incompatible with their serving framework (likely vllm) without some crack CUDA and Rust engineers (as you'd need to scramble the text and tokenize/detokenize it uniquely for scrambled LLM outer layers for each request).

    They are right about one thing: Proton all but advertise Luma as E2E when that is a lie. Per its usual protocol, Open Web UI will send the chat history for that particular chat to the server for each requests, where it is decoded and tokenized. If the GPU server were to be hacked, it could absolutely be logged and intercepted.

  • It is e2ee

    It is not. Not in any meaningful way.

    When you email someone outside Proton servers, doesn't the same thing happen anyway?

    Yes it does.

    But the LLM is on Proton servers, so what's the actual vulnerability?

    Again, the issue is not the technology. The issue is deceptive marketing. Why doesn't their site clearly say what you say? Why use confusing technical terms most people won't understand and compare it to drive that is fully e2ee?

    Because this is highly nuanced technical hair splitting, which is not typically a good way to sell things.

    Look, we need to agree to disagree here, because you are not changing your mind, but I don't see anything compelling here that's introduced a sliver of doubt for me. If anything, forcing me to look into it in detail makes me feel more OK with using it.

    Whatever. Have a nice day.

  • If an AI can work on encrypted data, it's not encrypted.

    SMH

    No one is saying it's encrypted when processed, because that's not a thing that exists.

  • they obviously had to have them in plaintext on their server, even if only for compatibility with current standards

    I don’t think that’s obvious at all. On the contrary, that’s a pretty bold claim to make, do you have any evidence that they’re doing this?

    Yes. They support IMAP. Which means, IMAP client can read your mails from the server. IMAP protocol does not support encryption, so any mail that does not add another layer of encryption (like GPG with encryption) implies that your mail is available in plaintext through IMAP, and as such, on the server.

    If that's not enough, when you send a mail to a third party that just use plain, old regular mail, it is sent from their (proton's) SMTP server, in plaintext. Again, unless you add a layer of encryption (assuming the recipient understands it, too), it's plaintext. On the servers.

    Receiving is the same; if someone sends a mail to your proton address, is shows up in full plaintext on their SMTP server. Whatever they do after that (and we've established it's not client-controlled encryption), they have access to it.

    In the case of GPG with encryption (not only for signature), then the message is encrypted everywhere (assuming your "sent" folder is configured properly). But that requires both you and the other party to support that, which have nothing to do with proton; you could as well do that over gmail.

    So, no, not a bold claim. The very basic of how emails standards works requires it.

    Now, I'm not saying that Proton have nefarious plans or anything. It is very possible that they act in good faith when they say they "don't snoop", and maybe they even have some proper monitoring so that admin have a somewhat hard time to check in the data without leaving a trace, but it's 100% in clear up there as long as you're not adding your own layer of encryption on top of it, and as such, you, as the user, have to be aware of that. It might be fully encrypted at rest to prevent a third party from fetching a drive and getting data, logs might be excessively scrubbed to remove all trace of from/to addresses (something very common in logs, for maintenance purpose), they might have built-in encryption in their own clients that implement gpg or anything between their users, and they might even do it properly with full client-side controlled keypairs, but the mail content? Have to be available, or the service could not operate.

  • Incoming Emails that aren't from proton, or PGP encrypted (which are like 99% of emails), arrives at Proton Servers via TLS which they decrypt and then have the full plaintext. This is not some conspiracy, this is just how email works.

    Now, Proton and various other "encrypted email" services then take that plaintext and encypt it with your public key, then store the ciphertext on their servers, and then they're supposed to discard the plaintext, so that in case of a future court order, they wouldn't have the plaintext anymore.

    But you can't be certain if they are lying, since they do necessarily have to have access to the plaintext for email to function. So "we can't read your emails" comes with a huge asterisk, it onlu applies to those sent between Proton accounts or other PGP encrypted emails, your average bank statement and tax forms are all accessible by Proton (you're only relying on their promise to not read it).

    Now, Proton and various other “encrypted email” services then take that plaintext and encypt it with your public key, then store the ciphertext on their servers, and then they’re supposed to discard the plaintext, so that in case of a future court order, they wouldn’t have the plaintext anymore.

    You would not be able to retrieve your mails using IMAP from a regular mail client if they were doing that. You can even retrieve them from Gmail, which is unlikely to support any kind of "bring your own private key to decrypt mails from IMAP".

  • Ok yeah thats a far cry from Proton actually “Having your unencrypted emails on their servers” as if they’re not encrypted at rest.

    There’s the standard layer of trust you need to have in a third party when you’re not self hosting. Proton has proven so far that they do in fact encrypt your emails and haven’t given any up to authorities when ordered to so I’m not sure where the issue is. I thought they were caught not encrypting them or something.

    Ok yeah thats a far cry from Proton actually “Having your unencrypted emails on their servers” as if they’re not encrypted at rest.

    See my other reply. There is no way to retrieve your mail using IMAP on a regular client if they're encrypted on the server. And Gmail can retrieve your mails from proton using IMAP. It's even in their own (proton's) documentation.

  • Ok yeah thats a far cry from Proton actually “Having your unencrypted emails on their servers” as if they’re not encrypted at rest.

    See my other reply. There is no way to retrieve your mail using IMAP on a regular client if they're encrypted on the server. And Gmail can retrieve your mails from proton using IMAP. It's even in their own (proton's) documentation.

    There is no way to retrieve your mail using IMAP on a regular client if they're encrypted on the server.

    That is probably why you can’t retrieve your emails using IMAP from a regular client.

    And Gmail can retrieve your mails from proton using IMAP. It's even in their own (proton's) documentation.

    I don’t think it can. Where in the documentation did you find that?

  • 47 Stimmen
    1 Beiträge
    19 Aufrufe
    Niemand hat geantwortet
  • Password manager by Amazon

    Technology technology
    150
    2
    534 Stimmen
    150 Beiträge
    2k Aufrufe
    cralex@lemmy.zipC
    My handwriting comes with free encryption at rest. Even I might not be able to read it.
  • What are the most in-demand Tech Skills? (besides AI)

    Technology technology
    5
    10 Stimmen
    5 Beiträge
    61 Aufrufe
    jordanlund@lemmy.worldJ
    AI is devaluing other skills. I got an email today, from my own company, telling me I wouldn't have to renew my professional certification for 2 years if I passed an unrelated test on AI. The "test" was 10 questions. Glad to know my professional certification is equivalent to a 10 question pop quiz on AI.
  • Dubai to debut restaurant operated by an AI chef

    Technology technology
    6
    26 Stimmen
    6 Beiträge
    56 Aufrufe
    G
    Huh, looks like my days of having absolutely zero interest in going to Dubai are coming to a middle
  • Apple appeals EU's €500M fine over App Store payment restraints

    Technology technology
    3
    1
    21 Stimmen
    3 Beiträge
    42 Aufrufe
    zak@lemmy.worldZ
    It's likely their priority is continuing to collect all the fees they can for as long as they can rather than the fine itself.
  • Oracle, OpenAI Expand Stargate Deal for More US Data Centers

    Technology technology
    4
    18 Stimmen
    4 Beiträge
    53 Aufrufe
    M
    Is the 30B calculated before or after Oracle arbitrarily increases their pricing for no reason?
  • 71 Stimmen
    12 Beiträge
    110 Aufrufe
    C
    Because that worked so well for South Korea
  • 1 Stimmen
    2 Beiträge
    27 Aufrufe
    A
    If you're a developer, a startup founder, or part of a small team, you've poured countless hours into building your web application. You've perfected the UI, optimized the database, and shipped features your users love. But in the rush to build and deploy, a critical question often gets deferred: is your application secure? For many, the answer is a nervous "I hope so." The reality is that without a proper defense, your application is exposed to a barrage of automated attacks hitting the web every second. Threats like SQL Injection, Cross-Site Scripting (XSS), and Remote Code Execution are not just reserved for large enterprises; they are constant dangers for any application with a public IP address. The Security Barrier: When Cost and Complexity Get in the Way The standard recommendation is to place a Web Application Firewall (WAF) in front of your application. A WAF acts as a protective shield, inspecting incoming traffic and filtering out malicious requests before they can do any damage. It’s a foundational piece of modern web security. So, why doesn't everyone have one? Historically, robust WAFs have been complex and expensive. They required significant budgets, specialized knowledge to configure, and ongoing maintenance, putting them out of reach for students, solo developers, non-profits, and early-stage startups. This has created a dangerous security divide, leaving the most innovative and resource-constrained projects the most vulnerable. But that is changing. Democratizing Security: The Power of a Community WAF Security should be a right, not a privilege. Recognizing this, the landscape is shifting towards more accessible, community-driven tools. The goal is to provide powerful, enterprise-grade protection to everyone, for free. This is the principle behind the HaltDos Community WAF. It's a no-cost, perpetually free Web Application Firewall designed specifically for the community that has been underserved for too long. It’s not a stripped-down trial version; it’s a powerful security tool designed to give you immediate and effective protection against the OWASP Top 10 and other critical web threats. What Can You Actually Do with It? With a community WAF, you can deploy a security layer in minutes that: Blocks Malicious Payloads: Get instant, out-of-the-box protection against common attack patterns like SQLi, XSS, RCE, and more. Stops Bad Bots: Prevent malicious bots from scraping your content, attempting credential stuffing, or spamming your forms. Gives You Visibility: A real-time dashboard shows you exactly who is trying to attack your application and what methods they are using, providing invaluable security intelligence. Allows Customization: You can add your own custom security rules to tailor the protection specifically to your application's logic and technology stack. The best part? It can be deployed virtually anywhere—on-premises, in a private cloud, or with any major cloud provider like AWS, Azure, or Google Cloud. Get Started in Minutes You don't need to be a security guru to use it. The setup is straightforward, and the value is immediate. Protecting the project, you've worked so hard on is no longer a question of budget. Download: Get the free Community WAF from the HaltDos site. Deploy: Follow the simple instructions to set it up with your web server (it’s compatible with Nginx, Apache, and others). Secure: Watch the dashboard as it begins to inspect your traffic and block threats in real-time. Security is a journey, but it must start somewhere. For developers, startups, and anyone running a web application on a tight budget, a community WAF is the perfect first step. It's powerful, it's easy, and it's completely free.