twleo

I don't need another desktop app...

The only thing I miss is the official API for the scheduled sending feature.

That's the only thing I would open the webpage app to do.

https://github.com/epitron/mitm-adblock

or

https://github.com/barre/privaxy

Looks good. I hate how IOS does, especially with certificate pinning, so I cannot use my ad-block http mitmproxy to block ads in Apps.

EDIT: thanks for people clarifying that pinning is done by Apps and not by IOS.

Open source does not magically make your software more secure. Community needs to audit the code if they are going to use it instead of trusting blindly.

That's why we should isolate Chromium from Google. Chromium should be lead by third-party like W3C.

Hard Pass for closed-source browser.

Me too. The only con is that Monaco does not have bold variants.

Fortunately, someone has created them!

https://github.com/vjpr/monaco-bold

Code should be self-documented. And editor should have a good mechanism to help you understand the source code. Emacs does better in this angle than Vim by far. You can find the documentation for every variable (describe-variable) and functions (describe-function) easily and jump to their source codes.

mu4e: [0]

Because I live in Emacs!

[0] https://www.djcbsoftware.nl/code/mu/mu4e.html

That is one of my questions too.

Use a low entropy things (I guess user's password would be not larger than 20 characters nowadays even using password managers) to encrypt a high entropy strings (PGP key).

Looks pretty weird to me.

Hmm. I rely mores on server-side filter rules because I don't use native Mail client.

Even if all the decryption resides in the app/web browser side, they can just silently change the code and inject some scripts to hijack the encryption routine.

Although they are open-source and can be scrutinized by anybody, it does not means that's what is run on the server side.

(Just say they have the capability; no accusation)

So at the end of the day, the question is whether you trust Proton or not. Encryption might not help in that case.

For other functionality, I will say nothing because it takes time to implement features and Proton is not as big as Google.

But for PGP? You should treat it seriously, considering your target customers.

It hurts the trust mostly.

If they cannot handle basic things like PGP correctly, how should I trust other part of their software. Especially they are a "Privacy-first" company.

"Privacy" becomes a marketing term nowadays.

iCloud filter rules is so weak...

There is also a 2-year old issues: https://github.com/ProtonMail/proton-bridge/issues/180

Proton makes it hard for open-source software developer to send patches and they don't care.

https://git-send-email.io/#step-2

Some quote from it.

Be advised that Protonmail is generally known to be a pretty bad email host. They will munge up your outgoing emails and your patches may fail to apply when received by the other end. Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.

Glad that I jumped out the ship only after one week so I can get full refund lol

Until Intel let me use ECC RAM on Consumer-grade CPU, I will use AMD without second thought.

Proton should be responsible no matter it uses the third-party open-source/propriety components or not.

If they decide to use third party libraries, that's their responsibility to review those libraries and include them to their code base.

Not "it's not my fault; it's others fault"

Bridge is open source, and as a result relies upon open-source components

I don't get it. Bridge is open source does not imply it should relies upon open-source components.

Addressing this issue at the source requires replacing the core IMAP library.

Why building an IMAP library from scratch instead of fixing/forking go-imap? Even a temporary fix to go-imap when you are developing gluon? Another repetitive work which does not guarantee the mentioned issues will be resolved completely.

Free-tier ProtonMail does not have the privilege to use this buggy bridge.

FastMail takes on PGP is very reasonable.

https://fastmail.blog/advanced/why-we-dont-offer-pgp/

I don't believe the encryption/key management from a company.

I uses FastMail after I discover this serious issue about Proton. I would say it work flawlessly and their web mail client is super fast; even faster than Gmail.

Besides, FastMail exists before Gmail and the people in FastMail are active standard protocol developers like IMAP and recently JMAP (a modern mail protocol will replace SMTP/IMAP, FastMail as a reference implementation), which is good because at least I know they understand the protocol and implement it by themselves.

I will agree with you if the bridge in a open source project backed by communities.

However, bridge is a paid feature used to attract more users.

Also, I don't understand your point about e2ee.

Bridge to proton server is also e2ee.

The mail interface is just a implementation of e2ee in browser, isn't it?

How is it a click bait? Don't forget bridge is a paid feature of Protonmail.