In the thread, both founders make false claims about their service, routinely misrepresent the level of privacy attained, and show lack of understanding of their own cryptography.
In particular, you will see in multiple comments left by the founders:
Multiple claims implying Skiff is fully end-to-end encrypted, even with emails sent and received outside of Skiff, which is simply false (and unlike other encrypted email providers is not even possible due to lack of interoperability)
Conflating encryption at rest and end-to-end encryption multiple times, and simply dismissing the difference at every chance
Claiming compromised clients are a solved problem somehow due to the low-level crypto primitives library used
Using language such as “Skiff can’t access” to sweep the lack of E2EE under the rug, which would be very confusing and simply misleading to a non-technical user reading it
Even on their official website, Skiff – Transparency - Read more, they claim emails are end-to-end encrypted, completely omitting the cruicial fact that this is only for emails between skiff users (and without forward secrecy, making it worse than even Whatsapp), clearly exploiting “end to end encryption” as a marketing term
There is a repeating pattern of overrepresenting the level of privacy attained and being very fuzzy in their communication and marketing about this issue. Irresponsible claims like this are very dangerous. Besides betraying users who may rely on these claims for their own safety, it also undermines the legitimacy of the privacy ecosystem as a whole.
To recommend Skiff, their marketing should be clear about what is and isn’t E2EE (which is only intra-Skiff communication) in non-technical language as a bare minimum. Claims made on social media should be accurate and free from undecided language. Trusting the people behind privacy services is paramount to their function, and Skiff has shown time and again that growth is more important to them than being truthful (even in other areas - for example continuing to falsely advertise “Open Source” many weeks after being made aware).
I’m sorry, but this is nonsensical. Skiff has made either as or stronger security decisions as every other secure mail provider listed. The only change we should move towards is greater interoperability, which we are. Skiff Pages already offers this.
Compromised clients is not part of the threat model of using any of the listed email services.
Skiff cannot access your emails. Other providers choose the term “zero-knowledge” encryption which is even more misleading and made-up. “Skiff cannot access your emails” is a far more honest term than “stored with zero-knowledge encryption,” which is not a cryptographic term.
Anyway, this post seems to be venting generally about a specific issue that unfortunately seems to need better terms and education about the “encrypted email” or “end-to-end encrypted email” product category.
We absolutely never conflate E2EE and encryption at rest. When we say "Skiff cannot store your emails, we do not mean encryption at rest. We mean, as we stated in that thread, in our security model, and in every other public comment, that this means public-key cryptography - keeping your data private to you.
BTW - it seems like you joined this forum to post about this specific grievance. I’d advise reading Skiff Mail (Email Provider) - #173 by amilich - the most viewed and most commented thread on the forum - where we walked through hundreds of comments, discussed many of these definitions, and made changes to our product over a year to support this community.
Just took a glance through a few other providers;; check out Security at Tuta as an example.
Tutanota encrypts all data by default: Email, calendars, contacts. The end-to-end encryption provided by Tutanota ensures that your data is secure and private, even if it falls into the wrong hands.
etc.
What part of Skiff – Security Whitepaper - Read more do you think is unclear? I am happy to make a change if anything is misrepresented. But, I do not see anything that is untrue in the slightest.
Finally, we in no way “prioritize growth.” We’ve made security-first decisions up and down our product line and company, from undergoing the most rigorous slate of audits (Skiff – Transparency - Read more) from before our product even launched, to end-to-end encrypting more data than many of our competitors across all 4 of our products. We’ve also been extremely engaged with the PG community, our Twitter community, our Discord community, our subreddit, our Canny feature request board, and other platforms to constantly improve our product suite based on user feedback.
Nothing in my original post has been a personal opinion or “venting”. I am only stating plain and simple facts anyone can verify for themselves.
Here is an academic definition of end to end encryption: encryption between two parties such that no others (including the server) may access their communications. When an email is sent to Skiff from any non-Skiff server (e.g. Gmail), the email is unencrypted, therefore the Skiff server has access to the email and likewise when an email is sent outside of Skiff. The guarantee provided here is a promise from Skiff that servers “won’t look at or log” the email before using public key cryptography to store it for the user (you seem to think public key crypto is equivalent to E2EE when it is not). This is not a cryptographic guarantee (and one that can be legally subverted), it is only as strong as a VPN provider advertising a no-log policy.
In plain and simple terms, this is encryption at rest, as the data is only encrypted after being seen by the Skiff server, and it is concerning that you seem to think otherwise of your own product and continue to use the same language in your response. This topic has been discussed multiple times over in the HN thread as well.
Your entire response seems to be calling my grievance “nonsensical”, then referring to how other providers may or may not be using inaccurate language (thus making it okay for you somehow as well?), and how your excellent community engagement is somehow relevant to any of this.
I’m not going to be engaging in a back and forth here. I have nothing to gain out of Skiff’s removal, but at the very least this issue should gain visibility.
Andrew, as pointed out by others in both the HN thread and here, Skiff isn’t e2ee except when both users are using Skiff (and hopefully, this is what was audited by Cure53 and Trail). If Proton and Tutanota are engaging in misleading marketing, then that’s a separate matter altogether.
No e2ee across providers isn’t as bad as it sounds since that limitation is inherent in current email protocols (this is also one reason federated e2ee protocols like Matrix exist). OTOH, if email users relied on PGP for e2ee, then things take a dramatic turn as there’s a lot to lose with PGP (as opposed to say Signal; and hence folks in precarious position might prefer to use Signal over Skiff / PGP instead).