I personally like a lot the gazillion bangs also available, the personal up/downranking/blocking of websites and their quick answer is often fairly good (I mostly use it for documentation lookup). The lenses are definitely the best feature though, especially coupled with bangs. I converted even my wife who really loves it.

If you use GnuPG or one of the GUI implementations it does.

No, because it’s the server that terminates the TLS connection, not the recipient’s client. TLS is purely a security control to protect the transport between you and the server you are talking to. It doesn’t have anything to do with e2ee. It’s still important, of course, but not for e2ee.

You do realize e2ee merely means that two users share public keys when they communicate in order to decrypt the messages they receive, right?

And how does TLS between you and your mail server help with this? Does it give you any guarantee that the public key was not tampered when it reached your server? Or instead you use the fingerprint, generally transmitted through another medium to verify that?

Nothing to stop you from hosting your own on an encrypted drive.

An encrypted drive is useful only when the server is off against physical attacks. While the server is powered on (which is when it gets breached - not considering physical attacks) the data is still in clear.

EteSync does E2E already

And…it requires a specialized client anyway. In fact, they built a DAV bridge (https://github.com/etesync/etesync-dav). Now tell me, if you use this on -say- your phone, can you use other DAV tools without using such bridge? No, because it does something very similar to what Proton does. If proton bridge will get calendar/contacts functionality too (if, because I have no idea how popular of a FR it is), you are in the exact same situation.

It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.

I feel like I covered this point? They make the client tool you are using, there is 0 need for them to steal your password to decrypt your key. Of course you are trusting them, you are seeing your unencrypted email in their webpage, where they can run arbitrary code. They do have their clients opensourced, but this doesn’t mean much. You are always exposed to a supply-chain risk for your client software.

Most users aren’t sending emails from their Proton to other Proton users either.

So…? The point is, if they do, encryption happen without them having to do anything, hence transparently. That was the point of my argument: my mom can make a proton account and send me an email and benefit from PGP without even knowing what PGP is.

Furthermore, the users that want encryption seek it out.

And that’s the whole point of the conversation: these users are techies and a super tiny minority. This way, they made a product that allow mainstream users to have encryption.

Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source.

And this control is worth zilch if they get compromised. This is a control against a MiTM who intercepts your download, it’s not a control if “the maker of Thunderbird” decides to screw you over in the same way that Proton would do by serving malicious JS code. If the threat actor you are considering is a malicious software supplier, you have exactly the same issue. There can be pressures from government agencies, the vendor might decide to go bananas or might get compromised.

However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic.

Yes, this is true and it’s the real only difference. I consider it a corner case and something that only affects the time needed to compromise your emails, not the feasibility, but it’s true. I am counting on the other hand on a company who has business interests in not letting that happen and a security team to support that work.

A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.

Maybe…? If government actors are in your threat model, you shouldn’t use email in the first place. Metadata are unencrypted and cannot be encrypted, and there are better tools. That said, government agencies have the resources to target the supply chain for individuals and simply “encourage” software distributors to distribute patched versions of the software. This is also a much better strategy because it’s likely they can just get access to the whole endpoint and maintain easy persistence (while with JS you are in the browser sandbox and potentially system sandbox), potentially allowing to compromise even other tools (say, Signal). So yeah, the likelihood might be higher with JS-based software, but the impact is smaller. Everyone has their own risk appetite and can decide what they are comfortable with, but again, if you are considering the NSA (or equivalent) as your adversaries, don’t use emails.

You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?

Yes.

First, explain what you mean by a fat client? GnuPG is not a fat client.

In computer networking, a rich client (also called heavy, fat or thick client) is a computer (a “client” in client–server network architecture) that typically provides rich functionality independent of the central server.

What I mean is this: a client that implements quite some functionality besides what the server would require to work. In this case, the client handles key management, encryption, decryption, signature verification etc. all functionalities that the server doesn’t even know they exist. This is normal, because the encryption is done on top of regular email protocols, so they require a lot of logic in the client side.

Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone.

For sure it’s different, I didn’t say it’s the same thing. I am saying that you can migrate away easily if your needs change and you’d rather have interoperability.

DAV is as secure as the server you run it on and the certificate you use for transport.

Exactly. Which is why in the very comment you quoted I said:

There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared.

Are you trusting your Nextcloud instance (yours of hosted by someone else) not getting pwned/the server being seized/accessed physically/etc. more than you trust Proton not to get pwnd? Then *Dav tools might be for you.

Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused?

Because most people don’t care about those particular things. Almost all the world uses completely proprietary tools (Gmail) that also violate your privacy.

Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.

It’s not unnecessary, it’s the result of a technical choice. A winning technical choice actually. PGP has a negligible user-base, while Proton has already 100 million accounts. I would be surprised if there were 10 million people actually using PGP. They sacrificed the flexibility and composability of tools (which results almost always in complexity) and made an opinionated solution that works well enough for the mainstream population, who has no interest in picking their tools and simply expects a Gmail-like experience.

And if you really have stringent requirements, they anyway provided the bridge, so that you can have that flexibility if it’s really important for you.

IMAPS & PGP/GPG, CalDav & CardDav

• IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
• PGP/GPG is what they use. They just made a tool that is opinionated and just works, rather than one which is more flexible but also more complex. Good choice? Bad choice? It’s a choice.
• *DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility). Proton decided that they want to implement e2ee calendar, and they decided to roll their own thing. It’s up to everyone to decide whether e2ee is a more important feature than interoperability with other tools. I don’t care about interoperability, for example, and I’d take e2ee over that.

Proton stores your keys

Proton stores an encrypted blob.

All they need now is your decryption password & they can read your messages

“All they need now is your private key”. It’s literally a secret, they use bcrypt and then encrypt it. Also, “they” are not generally in the threat model. “They” can serve you JS that simply exfiltrates your email, because the emails are displayed in their web-app, they have no need to steal your password to decrypt your key and read your email…

It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes.

Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.

Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server.

Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.

How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side?

I mean, their clients are open-source and have also been audited?

If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging?

I don’t know. But here we are talking about a different risk: someone compromising Proton, getting your encrypted private key, and starting bruteforcing bcrypt-hashed-and-salted passwords. I find that risk acceptable.

This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.

See other post.

If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client.

Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?

There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.

Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.

There are certain things that are known facts, there is no need to prove them every time.

The simple fact that:

• There is not a standard tool that is common
• The amount of people who use PGP is ridiculously low, including within tech circles. Just to make one example, even a famous cryptographer such as Filippo Sottile mentions to receive maybe a couple of PGP encrypted emails a year. I work in security and I have never received one, nobody among my colleagues has a public key to use, and I have never seen anybody who was not a tech professional use PGP.

You can also see:

• https://www.latacora.com/blog/2019/07/16/the-pgp-problem/:

We can’t say this any better than Ted Unangst: “There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again.” If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast. Now try doing that with PGP.

• https://fosdem.org/2024/schedule/event/fosdem-2024-3297-sequoia-pgp-rethinking-openpgp-tooling/

A recent talk, I will quote the preamble:

Although OpenPGP is widely considered hard to use, overcomplicated, and the stuff of nerds, our prior experience working on another OpenPGP implementation suggested that the OpenPGP standard is actually pretty good, but the tooling needs improvement.

And you can find as many opinion pieces as you want, by just searching (for example: https://nullprogram.com/blog/2017/03/12/).

However, if you really believe I am wrong, and you disagree that PGP tooling is widely considered bad, complex and almost a meme in the security community, you are welcome to show where I am wrong. Show me a simple PGP setup that non-technical people use.

P.s.

I also found https://arxiv.org/pdf/1510.08555.pdf, an interesting paper which is a followup of another paper 10 years older about usability of PGP tools.

They generally require to have data visible on the server and/or handle independently encryption/decryption with related tools and key management (including key discovery).

For some, it might be worth, for 99% of the population who wouldn’t be able to do this but also doesn’t want their content availablento the provider, it’s not.

GPG is a huge pain in the ass to manage. Everyone knows this, because it’s the case. The web of trust also doesn’t scale and has many problems, handling key securely is hard, making GPG work on all devices is something which is completely impossible for people without solid technical skills.

If you think otherwise, you are just in a bubble.

It’s actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.

They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it’s extremely inaccessible for the general population.

This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.

Companies have to comply with law enforcement. If anything, the little amount of data they were able to give after being forced is a good proof of their overall claim. If there is someone to blame here are courts using antiterrorism laws to catch environmental activists.

I guess Poland? I know from my colleagues that internet infrastructure jumped from old slow stuff to fiber there and it’s fairly cheap.

Super cool project, thanks for sharing! I think I will try to integrate it with my static sites.

Ottenere il dominio dimostrando la proprietà del marchio non è molto complesso, suppongo non sarà difficile. A meno che non hanno il marchio registrato…

I am curious about the details of that conversation, because I remember reading Dev’s comments in some post on Lemmy where they mentioned this option.

One thing I have never understood and keep repeating in this context: Beehaw has >7k$ balance. If they really have a few issues that would solve 90% of the problems, why not putting a 500/1000/2000$ bounty of that feature.

Your just focusing on strict technical definitions and completely ignoring the context of things. I described before how TLS is useful in the context of some SMTP e2e encrypted solution.

Yes, mentioning things that have not to do with e2ee. Anything that is encrypted with TLS is not e2ee in the context of emails. You talked about metadata, but the server has access to those because it terminates the connection, therefore, they are not e2ee. It’s a protection against leakage between you and the server (and between server and other server, and between server and the destination of your email), not between you and the destination, hence, irrelevant in the context of e2ee. Metadata such as destination can obviously never be e2ee, otherwise the server wouldn’t know where to send the email, and since it needs access to it, it’s not e2ee, whether you use TLS or not. TLS in this context doesn’t contribute at all to end to end encryption. Your definition is wrong, e2ee is a technical definition, is not an abstract thing: e2ee means that only the two ends of a conversation have access to the data encrypted. TLS is by definition between you and your mail server, hence it doesn’t provide any benefit in the context of e2ee. It is useful, but for other reasons that have nothing to do with e2ee.

never questioned that. With SMTP you can do true e2ee using PGP and friends

Exactly, and this is what Proton does. You simply don’t accept that Proton decided to write another client that is tightly coupled with their mail service, which is absolutely nothing malicious or vendor-locky, compared to using an already made client. Proton is simply PGP + SMTP.

with CalDAV/WebDAV you’ll need to have some kind of middle man doing the encryption and decryption - it’s a fair trade off for a specific problem.

Yes, and this middle-man is proton client, which sits on the client’s side. I am glad you understood how the only way to have e2ee with *DAV automatically technically impedes you to use “whatever server”. If anybody else but the client does the encryption/decryption, you lost the end-to-end part. I am not saying e2ee in this context is absolutely necessary, you might not care and value more the possibility to plug other *DAV servers, good. Proton is not for you in that case.

but about SMTP where you can have true e2ee

Yes, you can using a PGP client, like OpenPGP of Proton webmail, or Proton bridge. You need stuff on top of SMTP.

Your previous comment of “SMTP requires server to access the data” is simply wrong.

Nope, you are simply misinterpreting it. In SMTP the server requires access to the data because it’s the one delivering it. PGP is built so that the data it’s a ciphertext and not plaintext, so that the server can’t see the actual content of the mail, but it needs to have the data and ship it, in contrast for example to a p2p protocol. PGP is however on top of SMTP and requires a client doing it for you. OpenPGP or Proton do exactly this. There is no way to support SMTP “natively” and offer e2ee. You would like Proton not to do e2ee and leave the responsibility of the client to do the PGP part, with the freedom of picking whatever client you want? Well, that’s exactly the opposite of their business model, since what they aimed is to make PGP de-facto transparent to the users so that it’s available even to people who are not advanced users.

Do you have any proof that they use CalDAV/CardDAV?

https://github.com/search?q=org%3AProtonMail+CalDAV&type=code you can dig yourself into the code if you are curious to understand.

In the same way they don’t do IMAP/SMTP.

I sent you already a GIthub search of their clients for SMTP, look for yourself in the code. Do you think that makes any sense at all for them to reinvent the wheel and come up with ad-hoc protocols when all they need is a client? You can also have a look at the job offers they post: https://boards.eu.greenhouse.io/proton/jobs/4294852101 You can see SMTP mentioned and experience with Postfix in production. It’s very likely that they are running that in the background.

Get over yourself and your purist approaches, when a company provides a service that is standardized in a specific set of protocols and they decide to go ahead and implement their own stuff it is, at least, a subtle, form of vendor lock-in. End of story.

No it’s not. Vendor lock means:

In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products, unable to use another vendor without substantial switching costs.

Proton uses open standards, and just builds clients that wrap them. This means, emails are in a format that can easily be imported elsewhere, same for Calendar and Contacts. You are now watering down the definition of vendor lock to try to make your claim less wrong, but it is wrong. I repeat, and you are welcome to prove me wrong:

• There is no substantial cost in any form to migrate from Proton to an equivalent service elsewhere:
  • You can migrate email simply, by changing domain DNS records and exporting/importing the data.
  • You can export your Calendar in a standard format
  • You can export your Contacts in a standard format

This means that I can change vendor easily without significant cost, hence I am not locked-in.

What you actually mean is that while using Proton you can’t interoperate easily with other tools, and this is a by-design compromise to have e2ee done in the way they wanted to make it, which is available to mainstream population. You disagree with their approach? Absolutely legitimate, you prefer to use OpenPGP, handle keys and everything yourself? Then for sure, Proton is not worth for you as you can choose the tools you want if that’s important for you. But there is no vendor-lock, they simply bundled together the email client with the PGP client, so that you don’t have the full flexibility of separating the two.

You disagree with this definition of vendor lock? Awesome, give me your definition and link some source that use that definition. Because if you keep moving the goalpost and redefine what vendor lock means, there is no point to discuss.

So tell me, why is it that Proton simply didn’t go for OpenPGP + SMTP + IMAP and simply build a nice web / desktop client for it and kept it compatible with all the other generic solutions out there? What’s the point?

How is this relevant? I don’t know and I don’t care why they picked this technical solution.

It isn’t and I hope I’m never proven right about Proton for your own sake.

It is, and you have been proven wrong. Either that, or you completely misuse or worse misunderstand what vendor lock is.

Yes you move if you can.

It’s not if. You can.

It has all to do with vendor lock-in and it is already explained.

Yes, you explained interoperability that has nothing to do with vendor lock. They are two. different. things.

If a company uses shady stuff that restricts interoperability by definition it is a form of vendor lock-in as you won’t be able to move to another provider as quickly and fast as you might with others.

False. Again. Interoperability it’s a property that has to do with using the application. Interoperable applications potentially can totally vendor lock. Lemmy interoperates with Mastodon, but vendor locks you because you can not export everything and port all your content away. You definition is wrong. Just admit you misused the term and move on, there is no need to double down.

And it is, because there’s specific metadata that might get leaked on email headers if not minimized by other techniques that will get protected with TLS between servers.

They use TLS. TLS is useful for transport security. Proton uses TLS. TLS doesn’t have anything to do with e2ee in the context of emails because TLS is always terminated by the server. Therefore it is by definition not an e2ee protocol in this context. It is in the context of web, because there the two “ends” are your browser and the web server. It’s not in the context of messaging where the other “end” is another client.

It isn’t perfect

This has nothing to do with perfection, you are simply misunderstanding fundamentally what e2ee is in this context.

it’s better than having email servers delivering PGP mail over plain text connections

And in fact Proton doesn’t do that.

You should be ashamed of yourself for even suggesting that there’s no usefulness whatsoever for this use case.

I am not ashamed because I understand TLS, and I understand that it’s useless in the context of email e2ee. You simply don’t understand the topic but feel brave enough to evangelize on the internet about something you don’t fully understand.

here’s how decent companies deal with that: they encrypt the data in transit (using TLS) and when stored on their servers by using key store and that is itself encrypted with your login password / hash / derivation or some similar technique.

JFC. Proton uses TLS for transit connections. E2EE means that the server does not have access to the data. If the server has the key, in whatever form, and can perform a decryption, it’s not e2ee. The only way to have e2ee for these protocols is that the client(s) and only the clients do the encryption/decryption operations. This is exactly what Proton clients do. They use DAV protocols but they extend them with implementing encryption on the client side. Therefore, naturally, by design, they are not compatible with servers which -instead- expect data unencrypted to serve it, unencrypted (only via TLS, which again, it’s a transport protocol, has nothing to do with application data) to other clients.

Ironically, when saying what “decent companies” do, you have described what Proton does: they use your client key to encrypt data on client side. Then they transfer this data via a secure channel (TLS). The server has no keys and sees only encrypted data, and serves such data to other clients (Proton web, android etc.) that do the decryption/encryption operation back. Underlying it’s still CalDAV/WebDAV.

You clearly have bought into their propaganda but oh well think whatever you want, you’re the one using the service and it’s your data that will be hostage after all.

I don’t need to buy propaganda, I am a security professional and do this stuff for a living. I also understand what vendor lock is because all the companies I ever worked with had forms of vendor lock, and I am aware of Proton features instead.

Maybe you should really stop, reflect and evaluate if you really have the competence to make certain claims on the internet. I understand nobody is there keeping score and there are no consequences, but you are honestly embarassing yourself and spreading false information due to the clear lack of understanding about concepts such as e2ee, transport security, vendor locking, etc.

There are lots of ways to do e2e encryption on e-mail over SMTP (OpenPGP, S/MIME etc.)

Yes, and that requires using a client. The JS code of the webclient and the bridge are clients for PGP.

SMTP itself also supports TLS for secure server-to-server communications (or server-to-client in submission contexts) as well as header minimization options to prevent metadata leakage.

TLS is completely pointless in this conversation. TLS is a point-to-point protocol and it’s not e2e where the definition of the “ends” are message recipient and sender (i.e., their client applications), it only protects the transport from your client to the server, then the server terminates the connection and has access to the plaintext data. Proton also uses TLS, but again, it has no use whatsoever for e2ee.

And Proton decided NOT to use any of those proven solutions and go for some obscure propriety thing instead because it fits their business better and makes development faster.

They didn’t do anything obscure, they have opensource clients that do PGP encryption similar to how your web client would do. Doing encryption on the client is the only way to ensure the server can’t have access to the content of the emails. It just happens that the client is called “proton bridge” or “proton web” instead of OpenPGP.

only exists until they allow it to exist.

It’s their official product, and anyway it’s not a blocker for anything. They stop giving you the bridge? You move in less than 1h to another provider.

You don’t know if there are rate limits on the bridge usage and other small details that may restrict your ability to move large amounts of email around.

Do you know that there are, or are we arguing on hypotheticals?

Decent providers will give you an export option that will export all your e-mail using industry standard formats such as mbox and maildir.

True. You can still get the data out, whether they don’t do in a “best practice” way or not. It’s not vendor lock.

Proton mail is so closed that you can’t even sync your Proton mail contacts / calendars with iOS or Android - you can only use their closed source mail client to access that data or the webui.

https://github.com/ProtonMail. All the mail clients are opensource.

Also, WebDAV, CardDAV, CalDAV do not support e2ee. You need once again a client that extends it, which is what Proton also does!

So the question is very simple: do you prefer e2ee or you prefer native plain caldav/webdav/carddav? If the answer for you is the latter, Proton is simply a product that is not for you. If you prefer the former, then Proton does it. Either way, this is not again vendor-lock. They allow you to export contacts and calendar in a standard format, and you can move to a new provider.

Proton doesn’t respect the open internet by not basing their services on those protocols and then they feed miss-information (like the thing about e2e encryption being impossible on SMTP) and by using it you’re just contributing to a less open Internet.

SMTP does not allow e2ee by definition. I am not sure whether you don’t understand SMTP or how e2ee works, but SMTP is a protocol based on the server having access to the content. The only way you can do e2ee is using a client that encyrpts the content, like PGP (which is what Proton uses), before sending it to the server. This is exactly what happens with Proton, the webclients use SMTP to talk to proton server but before that they do client-side encryption (using PGP), exactly like you would do with any other client (see https://github.com/search?q=repo%3AProtonMail%2FWebClients smtp&type=code).

Now, you made a claim, which is that Proton vendor locks you:

• Mail can be moved easily. Change DNS record (or set forwarding) and export previous email.
• Calendar can be moved easily, export ics -> import in new calendar
• Contacts can be moved easily, export vcf -> import in new contact

So your claim that you are vendor locked it’s simply false, deal with it.

You made some additional claims about Proton not using plain standard protocols. That’s true. None of those protocols support e2ee, so they wrote clients that extend those protocols. All clients are opensourced, including the bridge. This has anyway nothing to do with being vendor locked, which in fact you completely did not explain. You talked about interoperability at most, which is not related to vendor lock.

You also made additional uniformed or false claims:

• TLS being helpful for e2ee. Is not in the context of email.
• You failed to understand why using native Cal/Web/CardDAV is incompatible with e2ee.
• You called “closed source mail client”, when all the email clients are opensource.

FYI, that was one of the things I disliked the most about Proton (email client slow). They released the newly rewritten app few weeks ago finally, and it’s working great.

What vendor lock-in are you talking about?

I can take my domain, customize DNS records and in a couple of minutes I am using a new provider. They also allow to export email content, which means I obviously don’t lose anything.

With a free email account, you are anyway locked-in as with every provider, because you are using their domain. You can set automatic forwarding in that case.

Vendor lock exists when you invest substantial amount of work to build tools around a specific platform (say, AWS), or where you have no way to easily take the data from one platform out and use something else to do the same thing (say, Meta).

The fact that you can’t use SMTP, which is a protocol that requires data on the server is not a vendor lock-in in any sense of the word. It’s a decision that depends on having that content e2e encrypted, because the two things are simy incompatible.

Also the code for all Proton clients and the bridge is open source, and the bridge is essentially a client that emulates being a server so that you can use your preferred tools to access the emails. Even in this scenario, there is no vendor lock and all it takes is changing the configuration of your tool from the local bridge address to whatever SMTP server you want to use elsewhere.

Can you please describe in which way you are actually locked-in, to show that you have a clue about what the word means?