Thanks for sharing! PGP support has been a huge request and enables end-to-end encryption automatically between large email providers for one of the first times we know of.
It's enough of other companies making money on our data. That's why I started Skiff (end-to-end encrypted email/docs/drive/calendar)! It's harder to build products E2EE but you get long-term trust from users.
Few notes
- iOS issue stems from a recent upgrade from an iframe to a webview. It's fixed on all mobile apps and versions.
- All DMARC-failing mail does go to spam.
- Caching images on receipt was examined but deemed impractical. It balloons email size from generally 50-150 KB to possibly multiple MB. Even for a personal mailbox, this could lead to 100s of GB being stored. Some version of this could be done on device or in the browser and temporarily stored. I actually think iOS either does this or will do this in the future.
Skiff encrypts all received emails with user public keys immediately on receipt. This is quite clear in our security model page and whitepaper. Skiff does not have access to any user emails, including external received ones.
Unfortunately this does not matter, since the trust model is same as it would not be encrypted at all. We still need to trust the third party.
Somehow the infrastructure should be transparent so that outsider can verify indeed at any time, that you don't collect logs from that traffic, or have no other means to inspect traffic if you want to.
There are currently no other means than just to use E2E encryption.
There is also another almost there, but that would mean that you should open-source your whole infrastructure, and use reproducible builds. Somehow there should be way to get access for outsiders, that you indeed use your infrastructure as you describe in your source code. But this is very complicated and also changeable at any time, unlike E2EE.
We use an open-source mailserver (Haraka), but security audits are the most trustworthy way to do this. We've had 4: skiff.com/transparency. Audits cover infrastructure.
> There is no foolproof way to load any remote content without possibly exposing email open information.
Also, this is false. You could download all remote content at time of delivery. That way it would be impossible for a sender to differentiate between an email simply being delivered and one being read.
Even more worrying, I just went into the settings and toggled on "Block remote content" and then sent my self another test through https://www.emailprivacytester.com, and it still triggered a remote content load when I viewed the email.
It's saying that the images were blocked, but that didn't stop them being fetched. Entirely defeating the point of the setting.
My point was that defaults matter, and your default is not privacy preserving. Yet you claim to be a "privacy first" service. There are many email clients which do not download remote content by default. I would argue that they preserve privacy better than Skiff does.
Yes - privacy focused mail providers offer this as an option but do not enable it by default. Mainstream mail providers do not even have it as an option.
Are you joking? I've never even come across an email client or provider that doesn't have options to toggle loading remote images. What mainstream mail providers don't have this option?
The only difference between your option and other providers are:
1. Yours doesn't even work. It still loads the remote images. It just doesn't display them
2. Yours has the wrong default.
Your "block remote content" option is even worse than just forcibly loading remote images and not even having the option in the first place, because it tricks the user into thinking that it will preserve privacy, like it does for other providers, but it does not preserve privacy in your case as it still loads the images.
No, I'm not joking. We do have this option, and it's consistent with the defaults across private mail providers. Still waiting for your list of the ones that don't load images by default.
It does not load the images. That's just patently false disinfo.
> No, I'm not joking. We do have this option, and it's consistent with the defaults across private mail providers. Still waiting for your list of the ones that don't load images by default.
If you read back, you'll see I wrote email clients and providers. But I'll note that you have not provided a list of clients or providers with privacy defaults that are worse than yours.
> It does not load the images. That's just patently false disinfo.
It absolutely does. You have no idea how your own product works. I literally showed you a tool where you (or anyone else) can verify this yourself in a few minutes: https://www.emailprivacytester.com - By the way, I am the author of this tool, and your email product is the least privacy preserving email product on the market right now.
I'll be blogging this up unless it's acknowledged and fixed.
I assume that once you've fixed the bug you'll be contacting all of your users to let them know that they've been exposed to this privacy flaw. At least the ones that may have disabled remote content at some point.
I just tested Tutanota and it does not have the same bug that skiff has. I think you must be having trouble understanding what the bug is. In skiff, even if you choose to not load remote images, when you view an email that has remote images, although it doesn't show the images, it does fetch them. I look at my web server logs, and I can see it happen. Emailprivacytester.com also shows it happen. I have tested this several times now.
I do not know what your difficulty is. Perhaps you should pass this on to somebody more technical than yourself at your organisation who can actually understand and diagnose the problem.
> by default, does not load external content from other servers (pictures and videos in emails). The user can choose to have external content shown with a single click or tap, if they trust the sender.
So there you go. An email company that does not load images by default. Whereas the default setting for Skiff is to load images automatically. So in this respect, Tutanota puts "privacy first" and Skiff doesn't.
You haven't published the reports, scope, and full findings. We don't even know what Trail was testing. I don't think the security audit stuff matters at all, and Trail is a fine firm, but you can't use the mere existence of a pentest project this way.
Any security engineer would have a heart attack if any employee, friend, or colleague said "security audit stuff [doesn't] matter." I wouldn't use software that doesn't undergo security audits.
I am a security engineer. You can go reach out to whoever managed your assessment at Trail and ask them about me by name if you like. What you're saying doesn't make sense. Maybe you could make it make sense! But you'd need to start by disclosing what the actual project scopes for each of these projects was.
It is misleading to tell about audits in this context.
Your transparency statement clearly says that Security audits. This is different than privacy audits. You cannot audit privacy, since you can intentionally change the functionality of your software right after the audit.
For the same reason, you cannot share open-source version of your software and say that it respects privacy. That can be only said if you use reproducible builds, and for client software only.
Both security audits and sharing your software as open, is about security, not the privacy. Open-source software and security audits help to reduce unintentional issues. And in this context it means a lot.
Actually, that's completely false. Security audits are a standard, reputable process for software. Trail of Bits is probably the best (or one of very few top) firms in this category. Check out: https://github.com/trailofbits
Is Trail of Bits doing random checks on your running infrastucture to verify that you are not changing your software against your users?
No. That is not what security audits are. Security audits ensure that software does safely what you, as service orderer claim, in a single moment. Usually including checklist.
But they cannot guarantee that you don’t change software between audits.
That is why E2EE exists as then it does not matter and we don’t need to trust.
Open-source, security audited client for E2EE communication with reproducible builds is the magical, correct combination to ensure both security and privacy.
What exactly got tested in each of these assessments, and what conclusions did those assessments draw? I asked this upthread and I'm asking here again, because "we've had 4 audits" doesn't mean anything without that detail.
Again, only between users with skiff emails, which is a negligible portion of all emails. This needs to be made clear as it is very misleading to the average user who probably thinks all emails are end to end encrypted.
No: Skiff does not have access to a single email stored on our platform, including ones received externally. All are public-key encrypted, including subjects and content.
This is encryption at rest, with the user holding the keys, and not end to end to end encryption, since the server recieves emails coming outaide of akiff in unencrypted form to begin with.
As a simple demonstration, even if client side code is perfectly secure, an adversary with server control can simply log all emails passing through the server and instantly have access to all new user emails that way. This means users have to trust the server, contradicting any notion of E2EE.
