Mailfence (mailfence.com) has been created out of our belief that 'Internet privacy is an absolute and definitive right'. After the revelations of massive global surveillance (PRISM....etc) - we decided it was time to offer a service fully dedicated to email privacy. We double-checked each line of code, hardened our servers and worked hard to find a SSL certificate with no american company involved in the certification chain (which is not that easy to find). Withal, the only answer to absolute privacy was end-to-end encryption and we opted OpenPGP (a well known standard - that was further refined in RFC-4880) along with the support of MIME.
The goal was to implement a "TRUE" end-to-end encryption setup (where en(de)cryption occurs purely on the client-side) under an easy-to-use application environment, that is absolutely independent from any third-party (add-on, plugin...) - which by far is the biggest landmark we have set in the secure emailing industry.
Our application use public libraries (openpgp.js - fairly audited) and provides a PGP/MIME based end-to-end solution, including an integrated key-store for managing (importing, exporting, modifying, revoking/deleting...) all of the user PGP public and private keys. Moreover, mailfence gives users the ability of 'Digital Signatures' for (both generating and verifying) PGP/MIME based schemes - an another unique feature which no other service (with-in such eco-system) provides.
Therefore, mailfence is a complete email-suite which not only focuses on User privacy and anonymity - but also gives an entire set of collaborative tools (i.e. Contacts, Calendar, Documents, Groups, Polls...) - so to meet the expectations for all kind of users (personal/private, professional/enterprise).
To further align our strong belief of "Privacy is a right and not a feature" - we donate 15% of "Pro" subscription revenue to associations (Electronic Frontier Foundation and the European Digital Rights Foundation) that globally defend the rights of user privacy on every possible level. Being a small team (with limited resources) - we are cautious, reliable, stable & honest and are massively working on improving our service.
Your suggestions/recommendations are highly welcomed - which will duly help us to further enhance and shape our service under your needs.
- Mailfence Team

Mailfence is solely dedicated to "email privacy and security" and was born as a result of Snowden Revelations with a belief of "Privacy is a right, not a feature". Following are other precise distinctions.

Needless to say - mailfence holds a significant amount of "uniqueness", not only with its in-house services but from tons other main-stream solutions as well.
Moreover, as I mentioned earlier - we donate 15% of "Pro" subscription revenue to dedicated associations (Electronic Frontier Foundation and the European Digital Rights Foundation) that globally defend the rights of user privacy on every possible level - which further aligns our values and goals towards online privacy.

Superficially, I'm impressed with what I've seen so far. Few questions:

1) Does fencemail.com use any public keyrings, such as pgp.mit.edu? So that if a non-fencemail user publishes their public key somewhere, fencemail will find it?

1.1) If not, suppose I'm not a fencemail user, but I want to send a message to two fencemail users. Do they each have to add my public key to the keyring, or is it a shared public keyring so that my key only needs to be added once? I don't see a fencemail equivalent of hushtools.com, where outsiders can supply their public keys so that encryption "just works" for fencemail users who correspond with outsiders.

2) If a fencemail user downloads their mail over IMAP, is the payload PGP-encrypted? IOW, do they need to export their private key from fencemail and then import it locally?

3) Why does fencemail.com use non-free javascript? Why is it blocked by the LibreJS tool?

4) Why is First name and Last name required? Streetwise users don't give their real names, so you immediately put them in a position of making a false statement. It would be more appropriate to make these fields *optional* during registration, and changeable thereafter.

1) Does fencemail.com use any public keyrings, such as pgp.mit.edu? So that if a non-fencemail user publishes their public key somewhere, fencemail will find it?

> Yes, mailfence users can find and import other PGP public keys from public key servers (pgp.mit.edu...) via their integrated key store (into their key-ring) and can also publish their own public keys so that other users can find them as well. For more info. check out this "how-to" guide.

Quote:

Originally Posted by zimmermanfan

1.1) If not, suppose I'm not a fencemail user, but I want to send a message to two fencemail users. Do they each have to add my public key to the keyring, or is it a shared public keyring so that my key only needs to be added once? I don't see a fencemail equivalent of hushtools.com, where outsiders can supply their public keys so that encryption "just works" for fencemail users who correspond with outsiders.

> If you're not a mailfence user - and sending an encrypted email to multiple recipients that uses mailfence. You will need their PGP public keys (via public key server - if they have published it there, or by any other out-of-band means) in order to encrypt your email for them. As recipients (mailfence users), they will need their private key to decrypt an email which you've sent to them - and does not require your public key for that purpose.
Now both of the recipients will have to add your public key in their integrated key stores (individually) to securely reply back to you - this will allow them to verify your public key in a much richer way (matching fingerprint....etc) instead of relying onto a centralized local key-server which not only is insecure but also contradicts with the concept of PGP on philosophical grounds (No centralization/or centralized authority).
Moreover, a fully featured integrated key store also enable our users to perform all the crypto-keys related operations (import/export/modify/revoke/delete...) by themselves and thus transfer the full control of their privacy into their own hands - and that is what our belief duly relies upon.

Quote:

Originally Posted by zimmermanfan

2) If a fencemail user downloads their mail over IMAP, is the payload PGP-encrypted? IOW, do they need to export their private key from fencemail and then import it locally?

> Mailfence is a 'pure' end-to-end encrypted solution (en(de)cryption occurs on the client-side) - therefore all the encrypted content remains encrypted at all times.
When you import encrypted emails via IMAP - you will receive them in as-is manner and will have to export your private key (in your local machine/or any other device) to decrypt them.

Quote:

Originally Posted by zimmermanfan

3) Why does fencemail.com use non-free javascript? Why is it blocked by the LibreJS tool?

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

Quote:

Originally Posted by zimmermanfan

4) Why is First name and Last name required? Streetwise users don't give their real names, so you immediately put them in a position of making a false statement. It would be more appropriate to make these fields *optional* during registration, and changeable thereafter.

> Those fields allow us to suggest you an email address and provide you a login name. You can always change them once you create your account (in your 'personal data').
Moreover, as per our privacy policy - we never share any sort of data with any third-party, and comply by the Belgian law.

1) Does mailfence.com use any public keyrings, such as pgp.mit.edu? So that if a non-mailfence user publishes their public key somewhere, mailfence will find it?

> Yes, mailfence users can find and import other PGP public keys from public key servers (pgp.mit.edu...) via their integrated key store (into their key-ring) and can also publish their own public keys so that other users can find them as well. For more info. check out this "how-to" guide.

I asked "if a non-mailfence user publishes their public key somewhere, mailfence will find it?" 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.

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

With hushmail, an expert non-hushmail user can tell a total novice to get a hushmail account, and the expert user can do all the key management on their end so that it /just works/ for the novice.

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?

Quote:

Originally Posted by Mailfence

Now both of the recipients will have to add your public key in their integrated key stores (individually) to securely reply back to you - this will allow them to verify your public key in a much richer way (matching fingerprint....etc) instead of relying onto a centralized local key-server which not only is insecure but also contradicts with the concept of PGP on philosophical grounds (No centralization/or centralized authority).
Moreover, a fully featured integrated key store also enable our users to perform all the crypto-keys related operations (import/export/modify/revoke/delete...) by themselves and thus transfer the full control of their privacy into their own hands - and that is what our belief duly relies upon.

I screwed up the phrasing of my question, but you answered it well.

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.

Quote:

Originally Posted by Mailfence

When you import encrypted emails via IMAP - you will receive them in as-is manner and will have to export your private key (in your local machine/or any other device) to decrypt them.

Good answer.. that's what I would expect.

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.

Mailfence requires an e-mail address for registration. This is flawed for several reasons.

* Creates chicken-egg problem. It's wrong to presume the user has e-mail service already. If the user does not already have an e-mail account, Mailfence blocks them from creating one. If they had one already, they might not need a Maifence account in the first place.

* If the user already has an e-mail account, then linking the two accounts defeats the purpose of having two accounts. It's bad identity management. Either way it's broken.

* I'll be the judge of whether I need a password recovery mechanism. It's less secure to supply an e-mail address for password recovery because if the other e-mail account is compromised, the adversary can attack the mailfence account by simply requesting a password reset.

* Even if an adversary has not compromised the password recovery account, sending tokens in the clear via e-mail is also prone to attack.

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.

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.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.

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

Quote:

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.

I have to admit to be a rookie when it comes to encryption and terminology such as in the posts above.

Does the need for a decryption key mean that if a MailFence user emails someone using for example Hotmail/Yahoo/Gmail or vice versa, the email would be not received or not readable?

I also have some questions that to me are quite important when choosing a new mail host:
- do you keep a log of previous sign-in dates and locations?
- what is the inactivity/expiry limit of a MailFence account? I mean, this doesn't necessarily have to be the same as for a Mail.be or ContactOffice.com account even when they are run by the same parent company.

I won't ask for how long the service has been around and whether it'll survive the forseeable future despite the competition from the big players out there. Mail.be/ContactOffice/MailFence have been around quite a while, I know as I am Belgian myself