Hi, so I’m doing a bit of a review on this now.
More clarification on E2EE to users
I think many users are going to simply think “Encrypted” means that it is “E2EE” when it’s not. Most users are going to be emailing non-skiff users. I think Proton Mail for example makes this really obvious: How to check encryption status using lock icons | Proton. That article is linked from the compose window.
I also did not see an option there to send a Temporary Inbox, style message to non-Skiff users. Notably this is something that Proton Mail, Tutanota and Mailbox have.
This gives the ability for external users to reply E2EE in their web browser. While not ideal it’s better than nothing.
I realize email encryption is hard and really the only standard is PGP. I know you’re really not going to want to hear that seeing as you wrote Skiff - Private, encrypted, secure email - 10 GB free but it is an unfortunate truth that PGP will probably never entirely die until something replaces it, that can be federated across email providers.
What Skiff is right now, is certainly not going to replace it. It also won’t be the The Signal Protocol either, as this requires key exchange which isn’t possible on an asynchronous communication protocol like SMTP. There has been an attempt (and you might remember criptext, which hasn’t seen any activity in ages). Signal Messenger isn’t going to replace email, as there is still a workflow for “letter” style immutable responses as opposed to transient back-forward conversation.
There are also efforts to modernize PGP such as RFC 9580 - OpenPGP. In that article I would have personally used a better source than a sensationalist wired.co.uk article claiming that PGP is dead, (I would have used https://efail.de). There are a few loud voices that want to make that claim, but until another RFC with benefits over the current one is created, that’s unlikely to happen.
Efail was a “blip” in 2018, now that vulnerable clients are fixed, and developers are using gpgme instead of directly invoking gpg and trying to parse HTML emails, the issue really isn’t quite as dire to even bother mentioning. Modern versions of Thunderbird, don’t even use GnuPG anymore (where that proof of concept originally was discovered), instead they use OpenPGP.js.
Also forward secrecy may not be as important as you think: Op-ed: Why I’m not giving up on PGP - Ars Technica explains that quite well. Additional efforts such as using a security key can provide extra security against key theft. You can’t have your Skiff keys stolen because Skiff doesn’t give you access to them, so that is one way to solve that problem.
Even established providers like Tutanota have only come as close as providing a “Temporary inbox” where users put a message in a JavaScript implementation on the provider’s website, which I might add does introduce other security issues such as does it have the same guarantees as a client side implementation from a third party. This is important regarding the introduction of a backdoor or interception order (perhaps an NSL, remember Edward Snowden and LavaBit) for particular users. We may see something based on MLS but until then I think PGP is here to stay.
Marketing
I see many articles like this one Skiff - Private, encrypted, secure email - 10 GB free which focus heavily on E2EE in a very general sense. The article leaves out that emails that are sent to non-skiff users are not E2EE. It feels like a point you’re striving to not highlight. This is the sort of thing we see networks like Telegram do a lot, leaving users to genuinely think that all their messages are E2EE, when they aren’t.
There does seem to be a fair bit of “marketing fluff”, on the blog as opposed “real content”. This kind of thing happened during the early days of CTemplar. I would like to see improved quality there, such as articles about real issues, (Proton has a section for this) and changes in the Skiff product. I would also suggest having more screenshots when providing guides of how to do particular things in Skiff. These are useful when third parties want to support users of your product.
With the above article it mentions “In this guide”, but it’s not really a guide, it’s a basic explainer on transport encryption vs end-to-end encryption.
One section there stuck out to me “The importance of end-to-end email encryption” talks about compliance in the business sector. An important part of Compliance and governance - besides sounding important is that your manager can actually audit what email you’ve been sending from the company domain which is why things like Google Vault exists. I would tone down the “this is good for business”, marketing because the reality is when you are a business, you have a right to know what your employees are doing with the company domain.
There is more to providing service to businesses than simply giving them bigger data caps or allowing more seats. Even Proton Mail is not perfect in this regard, and with their resources and time it’s taken a long time to get anywhere close. In Skiff’s defense, all privacy providers, that is ones which use E2EE in as many places as possible, are going to have to solve a lot of very difficult problems, and engineer a lot of custom solutions to meet existing business workflows. I haven’t seen a single one with commercial features like email routing, groups and distribution lists, shared calendars, shared inboxes, custom DKIM keys, and other functionality.
Please avoid outrageous claims like:
one of the most progressive providers in the data security industry
This simply is not true, while Skiff may be a good product some day, competitors do still lead in many areas, and that is to be expected as they’ve had longer for their products to mature. I think in general “honest marketing” goes a long way. An example of that would be what IVPN does (they’re a VPN provider), but they’re quite happy to tell you about the limitations of their product and what it should be used for. (As an example).
This might also explain why I see Skiff users constantly spruiking the product on Reddit. I had wondered about that.
Community
I noticed was that they only have a Discord community, which in general isn’t very privacy friendly. I would have like to have seen a Matrix community. Skiff could then make sure at least their data is stored on a server they own, (for example like Mozilla.org have an EMS instance). I’d actually like to see a Mastodon account too for announcements, as it is nice to have less commercial and invasive alternatives to Twitter.
Honestly I don’t think anyone uses LinkedIn these days. It does feel like “old school marketing firm” made those decisions.
The email interface, is very basic, for example I noticed you cannot have nested folders unlike Proton Mail. Tutanota doesn’t support this either. I’d probably have a toolbar in the composition window though for users who don’t know they can use markdown.
I also noticed there’s no way to see email headers, which makes it impossible to really dissect an email to see if it’s not a phishing email. Gmail etc lets you see DMARC status and all headers. Both Tutanota and Protonmail, as well as all the other providers we list on the website have this.
Import
I noticed the import features in Skiff, support importing via EML, MBox, Outlook or an IMAP server. This has always been a struggle point for privacy providers, notably Tutanota is only thinking about that now after having an issue in their tracker for a very long time Email import · Issue #630 · tutao/tutanota · GitHub.
Meanwhile Proton Mail Easy Switch only came about rather recently. Before that users had the pleasure of dealing with the Import/Export and it’s unreliability.
Things should improve with Proton Mail, with the new v3 bridge, that has a completely re-implemented APIs, and IMAP implementation, and avoiding issues like Our ProtonMail Adventure - A Five Act Drama.
Curious to know why there’s $10 credit from coming from Outlook, but not gmail or uploading email from another provider.
Export
There also seems to be no export feature, as this post also notes:
https://www.fastcompany.com/90764245/id-love-to-dump-gmail-for-this-slick-private-email-but-theres-a-catch
I do see features like “Connect a wallet to send and receive email from your Web3 identity” this I don’t consider an important feature. When you are missing key features like export I don’t know why Skiff is wasting time on this.
I’m now thinking of adding export as a requirement to the PG criteria. This is the first time we’ve come across a provider without that feature. Data liberty is as important and we don’t believe user data should ever be held hostage.
I also notice that article mentions:
But even if Skiff adds more of these features, it still has one inherent challenge: It’s a new, unproven service backed by venture capital. While Gmail isn’t going anywhere, I can’t confidently say the same about Skiff.
The concern there is, if the VC decides to not give it more funds and the product isn’t in as good health as it should be, viability may be an issue long term. Without an export feature that would make me very uncomfortable.
Filters
No add email filtering rules, ie a label or a folder. All mail must be manually organized/moved/labeled.
Pricing
Email doesn’t take up a lot of space, and most users won’t need 100GB of storage. The pricing of Proton Mail and Tutanota is quite different to Skiff’s pricing on the entry level accounts.
Calendar
So the calendar is simple with a nice design. It does appear that there are some fairly important features missing though - such as the ability to share calendars.
It would also be nice to be able to import calendars from a URL, rather than just an ICS file. Common usecase for this would be subscribing to public holidays etc.
I noticed that it said during the import that “Repeated events are not yet supported”, I would consider this a crucial missing feature.
Drive/Pages
This certainly seems to be the strong point. If we do go forward with listing Skiff, we’ll be mentioning this is the main reason you’d want to use Skiff. This would be one of the stronger features of the product. One of the weak points of things like Proton Drive is there isn’t really any way to author documents in your web browser, let alone collaborate with other users.
Privacy Policy
All information processed by us may be transferred, processed, and stored anywhere in the world, including, but not limited to, the United States or other countries, which may have data protection laws that are different from the laws where you live. We endeavor to safeguard your information consistent with the requirements of applicable laws.
Doesn’t seem to be anything about GDPR there. Typically these days even for non EU providers they will address that.
I did notice this piece which was a bit ambiguous:
De-identified and Aggregated Information. We may use information about you to create de-identified and/or aggregated information. We may use such aggregate or de-identified information for any purpose, and such information is not subject to the limitations set forth in this Policy.
Sometimes de-identified information is able to be reversed. I don’t particularly like to see open ended clauses in a privacy policy.
Skiff Acceptable Use Policy
I did notice in there:
- scrapes content hosted on our Site or through the Services without prior Skiff’s prior written authorization;
This would imply one isn’t allowed to write a scraper to export their email.
Other questions:
As Skiff is using its own implementation to achieve E2EE within the service, is there a cryptographic audit for this? I see mention here Skiff - Private, encrypted, secure email - 10 GB free
We have been committed to open source software since the very beginning of Skiff. We strongly believe that privacy cannot be just a promise; software must be available for anyone to independently audit and validate.
Realistically though this isn’t just “going to happen” because the product is open source. Is there funding available for a paid audit that encompasses the implementation, and network?
After having a look at the repo, particularly Commits · skiff-org/skiff-apps · GitHub it appears no development takes place in public, so this might as well be a public FTP. Also you should look at using .gitignore and not upload metadata like .DS_Store files. The issue with that is, it provides a lack of transparency around new features and potential regressions, essentially someone has to sit down and figure out what the codebase does, how it fits together etc.
The above statement really does feel like you’re hoping an audit will fall in your lap somehow.