

They compare it to proton mail and drive that are supposedly e2ee.
Only drive is. Email is not always e2ee, it uses zero-access encryption which I believe is the same exact mechanism used by this chatbot, so the comparison is quite fair tbh.
They compare it to proton mail and drive that are supposedly e2ee.
Only drive is. Email is not always e2ee, it uses zero-access encryption which I believe is the same exact mechanism used by this chatbot, so the comparison is quite fair tbh.
How would you explain it in a way that is both nontechnical, accurate and differentiates yourself from all the other companies that are not doing something even remotely similar? I am asking genuinely because from the perspective of a user that decided to trust the company, zero-access is functionally much closer to e2ee than it is to “regular services”, which is the alternative.
Scribe can be local, if that’s what you are referring to.
They also have a specific section on it at https://proton.me/support/proton-scribe-writing-assistant#local-or-server
Also emails for the most part are not e2ee, they can’t be because the other party is not using encryption. They use “zero-access” which is different. It means proton gets the email in clear text, encrypts it with your public PGP key, deletes the original, and sends it to you.
See https://proton.me/support/proton-mail-encryption-explained
The email is encrypted in transit using TLS. It is then unencrypted and re-encrypted (by us) for storage on our servers using zero-access encryption. Once zero-access encryption has been applied, no-one except you can access emails stored on our servers (including us). It is not end-to-end encrypted, however, and might be accessible to the sender’s email service.
Over the years I’ve heard many people claim that proton’s servers being in Switzerland is more secure than other EU countries
Things change. They are doing it because Switzerland is proposing legislation that would definitely make that claim untrue. Europe is no paradise, especially certain countries, but it still makes sense.
From the lumo announcement:
Lumo represents one of many investments Proton will be making before the end of the decade to ensure that Europe stays strong, independent, and technologically sovereign. Because of legal uncertainty around Swiss government proposals(new window) to introduce mass surveillance — proposals that have been outlawed in the EU — Proton is moving most of its physical infrastructure out of Switzerland. Lumo will be the first product to move.
This shift represents an investment of over €100 million into the EU proper. While we do not give up the fight for privacy in Switzerland (and will continue to fight proposals that we believe will be extremely damaging to the Swiss economy), Proton is also embracing Europe and helping to develop a sovereign EuroStack(new window) for the future of our home continent. Lumo is European, and proudly so, and here to serve everybody who cares about privacy and security worldwide.
They actually don’t explain it in the article. The author doesn’t seem to understand why there is a claim of e2e chat history, and zero-access for chats. The point of zero access is trust. You need to trust the provider to do it, because it’s not cryptographically veritable. Upstream there is no encryption, and zero-access means providing the service (usually, unencrypted), then encrypting and discarding the plaintext.
Of course the model needs to have access to the context in plaintext, exactly like proton has access to emails sent to non-PGP addresses. What they can do is encrypt the chat histories, because these don’t need active processing, and encrypt on the fly the communication between the model (which needs plaintext access) and the client. The same is what happens with scribe.
I personally can’t stand LLMs, I am waiting eagerly for this bubble to collapse, but this article is essentially a nothing burger.
If I were in the security team of that company, I would never accept ACLs on the bucket as a sufficient compensating control for this risk. Here the best most reasonable would be encryption, which would make the bucket being public relatively unimportant.
When you are collecting so sensitive data (potentially including personal data of people not using your service), you simply can’t even imagine doing that by storing the data unencrypted.
Edit: grammar
Because it’s unnecessary in almost all cases. So far there is only one community which forbids people to comment based on who they are, but otherwise the rules boil down to standard acceptable behavior according to common sense. It’s also a nuisance for users: I am quite sure nobody wants to click several times and be derailed to check rules (on mobile) for every comment they want to write in every post they see on a feed. If this would be expected as standard behavior, I would guess even less interactions will happen.
Based on the comments here and in the previous similar post I have seen, the vast, vast majority of people (presumably men) highlight how this is a problem of visibility of posts in public feeds.
It’s a tradeoff between having the community public for discoverability and accepting that many people will not check the rules and violate them, some inadvertently.
The alternative is to make the community private, and accept that women will need to discover a women-relates community by searching for “women”, which doesn’t seem incredibly unlikely.
From the sentiments I read, most people wouldn’t care at all if the community was private and wouldn’t have a desire to “invade” it. I definitely feel part of this group.
Considering that it’s in the interest of the community (apparently) to have only women, I think it’s fair to expect the (minimal) effort from future members to look for it (plus advertising it in posts etc.) on them instead of expecting the vast majority of the users (the fediverse is mostly males) to add friction and having to check the rules of every single community of every post they open (now it might be a community, more might come). Yes, community rules are important, but being realistic, if you don’t behave like an asshole you don’t need to worry about them in 99% of the times.
However, if this tradeoff is not deemed acceptable, I think there is no point complaining about people “invading” women spaces because it’s guaranteed that many people will comment without reading the rules, as I am sure the almost totality of users does all the time. Even without counting the ones who intentionally violate the rule, there is always going to be an organic amount of people who will do so inadvertently.
At this point I think the tradeoff is so clear, that discussing the topic in such a confrontational way looks more like rage-bait than anything aimed at solving the problem.
Thanks. Absolutely my experience too. The ones where you can’t edit the email I noticed often used the email as username, and probably god knows how bad is the code on the backend.
Hey, I haven’t, but to be honest, the answers I got from most companies showed me that the processes were handled by people who barely understood the legal and technical aspects around data collection (e.g., often support agents were on the other side of privacy@), which means I wouldn’t trust them with their answer anyway AND I doubt many of these companies will have effective way to even check that.
From the data being sold point of view, I think unfortunately it’s way more effective reaching out to the few big data brokers to request cancelations or pay one of the companies who offer such service…
Thanks for the kind words!
I won’t take credits for the template, I have used the one found here: https://www.datarequests.org/blog/sample-letter-gdpr-erasure-request/
Eh, the thing is I made the formal request using data deletion module, but I just assumed that’s what the support person asked the development person (“team”), assuming it was not the same person for both!
Congratulations on completing this!
I have indeed moved most accounts to individual aliases. I used to use the same username and similar emails (perhaps grouped like shops@mydomain), but I got no benefit and the username allowed unnecessary correlations.
So alias + random username and I will have much much less trouble in the future. Hopefully!
Social/Political problems need social/political solutions, not technical solutions.
When they need, they’ll learn.
100% agree. But. If you are a principal engineer claiming to have experience hardening the thing, you would expect that learning to have already happened. Also, I would be absolutely fine with “I never had a chance to dig into this specifically, I just know it at a high level” answer. Why coming up with bs?
Maybe those engineers were like that too.
I mean, we are talking about people whose whole career was around Kubernetes, so I don’t think so?
I partially agree, but not only we are looking for experts of that thing, we are also looking for security experts, and security knowledge is very much meta-knowledge. A software developer might not care at all about - say - how the CI/CD works, because all they care is that the thing builds the code. A security expert generally has a broader scope, and their job is not functional, which means their job is exactly understanding the thing to be able to model the risks around it. So they might not care of all the tools used in that CI/CD or the exact details of the steps, but they should understand the execution flow, the way third party dependencies are pulled, verified, consumed, the authorization model etc.
There is no such thing of security professional who doesn’t understand - at least from an academic point of view - the overall setup of a thing they worked with.
If I take the image attestation example I made in the post, I consider the “inner workings” to be the cryptographic details, such as ciphers and their working mechanisms, or the exact details of the way that attestation can be verified offline, or what exactly is computed and how. I am OK with someone not knowing this. But not understanding the whole flow? Well, without this what’s left? Copying the 3 lines of code that do something from the Github documentation? Any software engineer can very much do that, what is your contribution as a security specialist?
……people lie on CVs and cover letters. If your ad has buzzwords and technology X, Y, and Z
Totally agree. It is very likely, although the more people I interview, the more I think that they are not lying from their perspective. It’s that people can legitimately make a career today by stitching together stuff with scotch tape, spending years by just by doing that and effectively have little to show for those years. But from their perspective, they might be experienced in that stuff, maybe?
I wouldn’t say it’s a large expansion of skillset, meaning it’s not massive. But yes, indeed it is problematic to find people. It is because this is a vicious circle in which companies are digging their own graves by eliminating a market for those people, which in turn means that those who would want to hire some can’t find them easily, leading to outsourcing instead. Do this for 15 years across the whole industry and it stops being an option, which is pretty much where we are today. That said, training and upskilling is always a possibility for companies who invest on their own employees and are playing the long game…
Well, for the relatively small sample of Kubernetes experts I interviewed, basically any topic beyond “you use this tool” was a disaster, including Kubernetes knowledge. I am not selective, it’s not like I expect a specific skillset, but what would you think if someone with a decade of platform security doesn’t understand cryptography and supply chain, Linux permissions, Kubernetes foundational concepts, container isolation or networking? At some point the question is legitimate, what are you expert in? The answer I have been able to give myself so far is “stitching together services that do stuff” and “recommend what the documentation/standard recommends”. I consider myself satisfied to have somewhat decent knowledge in some of those areas, I am not expecting someone understanding all of that, but none of them? Maybe from someone who just joined the industry.
You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
I am saying that the competencies of people who grew up (professionally) with outsourced services are more superficial and give them way less understanding (and agency) on the systems they oversee. I make the opinionated argument that knowing which service to use in a cloud provider is not just a different skill from implementing that functionality “manually”, but is hierarchical inferior, easier to acquire and less useful in general.
A weird parallel would be someone who hikes 100% of the time with a guide who takes care of orientation, camp setting etc., and someone who goes alone. If I am simply comparing the pictures they are showing me, I might not appreciate the difference, but if you asked me who I would trust to come hiking with me, I wouldn’t have doubt, because I consider the skill “finding, choosing and listening to the guide” to be hierarchial inferior to “orient, set camp etc. by yourself”.
So it’s not just a matter of matching the skills I need, is actually a much broader argument about deskilling engineers.
Email is almost always zero-access encryption (like live chats), considering the % of proton users and the amount of emails between them (or the even smaller % of PGP users). Drive is e2ee like chat history. Basically I see email : chats = drive : history.
Anyway, I agree it could be done better, but I don’t really see the big deal. Any user unable to understand this won’t get the difference between zero-access and e2e.