Skip to content

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

Technology
86 44 1
  • 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?

  • 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.

    They support IMAP. Which means, IMAP client can read your mails from the server.

    Proton mail does not support IMAP. Because your emails are encrypted on the server.

    Again, unless you add a layer of encryption (assuming the recipient understands it, too), it's plaintext. On the servers.

    Protonmail doesn’t claim that non-protonmail email is end to end encrypted. Any emails sent to a regular email without third party encryption will be plain text through the SMTP server, but they don’t store it. So in this case they are still not storing your emails in plaintext. Your recipient will, but that’s out of Protonmail’s control.

    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.

    You’ve not established that at all. Protonmail stores that message with client side encryption and they have no access to it. Nothing you’ve brought up here suggests that anything is stored in plaintext on Protonmail servers.

  • I literally said exactly what you're explaining. I'm not sure what you're trying to accomplish here....

    What they're saying is that you said that the bubble has kinda already popped because (insert description of the middle of the dot com bubble here when smaller companies began to join in). Based on that, the bubble hasn't popped at all, small companies are just able to buy in as well before the collapse hits.

  • 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.

    Protonmail does not support IMAP, what they have is a program called Proton Bridge that locally decrypts you email then you can set it up so that your IMAP client then reads from Proton Bridge, giving you a seamless experience with one email client having access to all your email accounts.

  • 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.

    +1, it appears they didn't check the support page:

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

    If bitnet or some other technical innovation pans out? Straight to ASICs, yeah.

    Future smartphone will probably be pretty good at running them.

  • 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?

    Why does an email service need a chatbot, even for business?

    they are not only an email service, for quite some time now

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

    sure, with a thousand or two dollars worth of equipment and then computer knowledge. Anyone could do it really. but even if not, why don't they just rawdog deepseek? I don't get it either

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

    that's right. you can upload files though, or select some from your proton drive, and can do web search.

  • Why does an email service need a chatbot, even for business?

    they are not only an email service, for quite some time now

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

    sure, with a thousand or two dollars worth of equipment and then computer knowledge. Anyone could do it really. but even if not, why don't they just rawdog deepseek? I don't get it either

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

    that's right. you can upload files though, or select some from your proton drive, and can do web search.

    sure, with a thousand or two dollars worth of equipment and then computer knowledge. Anyone could do it really. but even if not, why don’t they just rawdog deepseek? I don’t get it either

    What I mean is there are about 1000 different places to get 32B class models via Open Web UI with privacy guarantees.

    With mail, vpn, (and some of their other services?) they have a great software stack and cross integration to differentiate them, but this is literally a carbon copy of any Open Web UI service… There is nothing different other than the color scheme and system prompt.

    I’m not trying to sound condescending, but it really feels like a cloned “me too,” with the only value being the Proton brand and customer trust.

  • Why does an email service need a chatbot, even for business?

    they are not only an email service, for quite some time now

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

    sure, with a thousand or two dollars worth of equipment and then computer knowledge. Anyone could do it really. but even if not, why don't they just rawdog deepseek? I don't get it either

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

    that's right. you can upload files though, or select some from your proton drive, and can do web search.

    I guess the sell is easy access to Proton Drive for RAG here?

  • 33 Stimmen
    8 Beiträge
    44 Aufrufe
    A
    they don't just whimsically decide on a daily basis whether or not to comply with court orders. something changed legally that caused them to take action.
  • It's rude to show AI output to people

    Technology technology
    53
    1
    454 Stimmen
    53 Beiträge
    668 Aufrufe
    F
    I gave advice, advice rarely follows what you've experienced or people wouldn't feel the need to give it.
  • 4 Stimmen
    1 Beiträge
    17 Aufrufe
    Niemand hat geantwortet
  • 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.
  • Programming languages

    Technology technology
    1
    1
    0 Stimmen
    1 Beiträge
    15 Aufrufe
    Niemand hat geantwortet
  • 7 Stimmen
    9 Beiträge
    90 Aufrufe
    V
    Ah yeah, that doesn't look like my cup of tea.
  • 360 Stimmen
    24 Beiträge
    210 Aufrufe
    F
    If only they didn’t fake it to get their desired result, then maybe it could have been useful. I agree that LiDAR and other technologies should be used in conjunction with regular cameras. I don’t know why anyone would be against that unless they have vested interests. For various reasons though I understand that it isn’t always possible - price being a big one.
  • No Frills PCB Brings USB-C Power To The Breadboard

    Technology technology
    3
    1
    0 Stimmen
    3 Beiträge
    45 Aufrufe
    coelacanthus@lemmy.kde.socialC
    and even without it, you'll get 150mA @ 5V by default out of the USB 3 host upstream and up to 900mA with some pretty basic USB negotiation in a protocol that dates from USB 1.0 That's wrong. With USB Type-C, you can get the power up to 3A @ 5V with just two 5.1kΩ resistor on CC pins.