[Mailfence]

Originally Posted by zimmermanfan

Based on what you said, the correct answer is "No", mailfence ("MF") will not find it. The user must find it, and add it manually.

As I said, "mailfence users can find and import other PGP public keys from public key servers via their integrated key store". Now you seem to ask, will they be able to use it directly- and that's where the answer is 'No', they'll have to import them first (and verify it) before moving any further.

Originally Posted by zimmermanfan

This may be good for security, but makes mailfence less usable for novices.

That's what we are trying to do: raising the bar of ease-of-use until that thin line of security (which is our utmost priority) - so to make mailfence a platform for both technical and non-technical users, without compromising the security over convenience.

Originally Posted by zimmermanfan

Suppose a MF user emails someone for the first time. If the key is not on their keyring, why not check pgp.mit.edu automatically, and offer to import the key on the condition that the user verifies the fingerprint?

We are currently thinking likewise, and I'm glad that you've also suggested a somewhat similar approach. Though, being a small team (with limited resources) - we are currently focusing on other priority issues, and will consider this one soon.

Originally Posted by zimmermanfan

It's unclear how separate public keyrings protects your users. When a MF user composes an outbound message, what's to stop MF from substituting a different public key? Even if the user has their own public keyring, the webtool won't necessarily use it.

The question is about (absolute) "control" of privacy and a dedicated key-store (having private and public keyrings) exactly provides that. Then the notion goes towards security, where that absolute control comes into play and allow users to make the right decisions (avoiding the use of wrong public keys by proper fingerprint verification...etc). We don't adhere to the false concept of "Security through obfuscation" where most of the other solutions does all the user's key management - leaving them with no room to control their keypairs (which indeed are super private to user's).
Furthermore, this also enable our users to enjoy full PGP interoperability in a restrictionless manner, use multiple key-pairs, use no third-party plugin/add-on, perform critical operations (generation of revocation certificate, modifying passphrase/expiration date,...), etc...
We are currently enhancing our "How To" guide and Blog - to also educate users with best-practices in simple and intuitive ways.

Originally Posted by zimmermanfan

Quote: Originally Posted by Mailfence
> The JavaScript we use is very complex and compressed. LibreJS simply translates 'it's complex' by 'it's suspect' which we find unrealistic. Its analysis is too simple to handle most modern JavaScript frameworks. FYI: we are planning to release the code of our front-end in a later phase which will further clarify this and other code-level concerns.

Bug report filed: https://savannah.gnu.org/bugs/?48266

Thank you for your efforts, and we'll look forward for their response.

Originally Posted by zimmermanfan

Mailfence requires an e-mail address for registration. This is flawed for several reasons.
....
It's essential that disclosing a password recovery e-mail address be optional (or non-existent). Since this is a mandate, I'm out. I will not be registering on mailfence or advocating it to others until this is fixed.

While agreeing to some of your points and not with others - we duly respect the user right of online anonymity and freedom of association on the whole (and have planned multiple measures to take in this regard as well). However, under the related technical boundaries, this may or may not include the condition of an alternate email address.

Thank you for your detailed feedback - and will remain at your disposal.