Does Skiff optionally support CardDAV and/or CalDAV? Or otherwise offer a way to sync contacts with a phone and share calendars with others?
We do not yet support CardDAV or CalDAV, but we hope to in the future. They have been requested frequently.
CardDav and CalDav protocols do not support end-to-end encryption AFAIK
Correct, but a contacts service isn’t useful to most people if it has no way to sync with devices, like on your phone.
This can either be via (optional) non-encrypted sync like with CardDAV, or with a workaround like EteSync uses.
I noticed that, and am having a look at it now.
@nishil I see that you still have some outdated ciphers accepted, this is likely a misconfiguration. Nothing too big but maybe good to look into:
Also please consider to add a security.txt see https://securitytxt.org/ so that people can actually find where to report vulnerabilities.
As for email:
DNSSEC is not correctly configured, therefore you do not meet the requirements of PG.
Also TLS for email allows 1.0 this version should not be accepted. I wonder generally why inbound-smtp.us-west-2.amazonaws.com is used. This seems to have a weak configuration also DANE is missing.
Hi, so I’m doing a bit of a review on this now.
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: https://proton.me/support/encryption-lock-meaning. 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 https://skiff.org/blog/pgp-dead-what-next 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 https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/. 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: https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ 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.
I see many articles like this one https://skiff.org/blog/end-to-end-encryption-email 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.
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.
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 https://github.com/tutao/tutanota/issues/630.
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 https://blog.sigma-star.at/post/2022/07/protonmail-adventure/.
Curious to know why there’s $10 credit from coming from Outlook, but not gmail or uploading email from another provider.
There also seems to be no export feature, as this post also notes:
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.
No add email filtering rules, ie a label or a folder. All mail must be manually organized/moved/labeled.
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.
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.
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.
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.
As Skiff is using its own implementation to achieve E2EE within the service, is there a cryptographic audit for this? I see mention here https://skiff.org/blog/open-source
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 https://github.com/skiff-org/skiff-mail/commits/main 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.
Posting a few initial responses with more to come. This is super comprehensive feedback, and we appreciate the feature requests and constructive criticism.
External mail sent and received to non-Skiff providers is still stored encrypted with user public keys, so it is not accessible by Skiff. It is quite hard to capture these nuances in tooltips, but the point is that even external mail is safe, and it is never unencrypted. I completely disagree that it is misleading.
I think PGP is quite out of scope for the criteria here. Given the articles you linked to, if only 30,000 external users use it, it’s basically unused by the Proton user base, and Tuta does not support it. Both Skiff and Tuta also encrypt email subjects, which I think is an enormous privacy benefit.
Sending encrypted content to other users is possible. You can use a Skiff document on view/edit mode, which is end-to-end encrypted with a link URL and also offers password protection (additional encryption) and watermarking. Proton, Tuta, and all other providers do not offer functionality like this, but I actually think it’s better because it offers real-time collaboration, commenting, and more.
I think discussing our community channels is a bit out of scope. We had a Matrix community, but it was bombarded with drugs and crypto spam that made it completely unusable and safe for users. We do have a Mastodon at ioc.exchange. I honestly think this is quite of scope, particularly given many recommended services on PrivacyGuides (Proton, Tuta, Brave, etc.) use many of the same social channels (Twitter).
Import from other providers is coming. MBOX and EML should also give you the same credit. We have Gmail import ready to launch as well.
The funding discussion is a bit one-sided. Venture capital is simply capital, and all companies require it to survive. Brave, DuckDuckGo, Proton, and many other recommended companies have taken venture funding - including Brave + DuckDuckGo in the last year! Skiff has many years of capital and paying customers to keep our services running.
Export is coming. We’re prioritizing everything we can, and we’re just building import options. There are super comprehensive export options on Pages/Drive - export to MD, DOCX, PDF, and ZIP for entire folders, or even exporting entire teams - so we have no bias against it.
The blog is being reorganized, but a lot of it is written for content marketing and SEO. If you dig into the Proton/Brave sites, you’ll see similar content, just not as publicly visible. For example, see Learn | Brave with “the best private browser.” These types of lines are typical to SEO optimized blog posts.
I agree on the pricing comment, but the plans are optimized for using Skiff as a suite, where 100 GB is actually quite helpful for Drive/Pages storage. Also, the free plans are much more generous, and the paid plans more expensive.
Repeating events are coming to Calendar soon.
We have undergone 3+ audits, all from Trail of Bits. GitHub - trailofbits/publications: Publications from Trail of Bits. If you’d like more info, Dan Guido (TOB’s CEO) has Tweeted about us a bunch. The audits cover all Skiff products, security model, and infrastructure.
The issue is that isn’t really E2EE. As soon as an email leaves Skiff’s system it no longer has E2EE. It is only E2EE while Skiff has it. Generally when people think of E2EE email they expect it to be E2EE on both ends, the recipient and the sender’s end point.
- I’m not a Proton Mail customer, but I can send an E2EE email to one of their users.
- I’m not a customer of Tutanota, but if one emails me with an encrypted email and provides the temporary password - say over the phone, I can make sure that email is E2EE when it leaves my browser.
Perhaps not with the same assurance as PGP, (for example Tutanota could in theory disable E2EE for a particular user), ie by changing the server side code so when a particular user sends me a temporary inbox link, there is no encryption.
If I am a Thunderbird user, Mozilla cannot be compelled in any way to target a specific user. PGP without forward secrecy still can provide the highest level of assurance because implementations don’t necessarily come from the provider. Key theft is basically impossible with a Yubikey.
For commercial providers even Proton wants to keep an encrypted copy of the private key, this is because of support requests they do not want to deal with. I accept responsibility that loss of my keys will mean a loss of my email.
The point I’m trying to make is that it is not accurate by any means to say “PGP is dead” or that it is “broken”, there are certainly improvements that could be made.
You really can’t know how many PGP users there are. It’s a decentralized protocol without reporting functionality. There are many implementations and many providers. I have run into Proton Mail (and occasionally Tutanota) users (outside of the privacy communities), but I’ve never run into a user of smaller privacy providers.
While this is important, it may not be as important as making sure the email body is encrypted on both the recipient’s server and your own. Email subjects can contain sensitive information and while there is Protected Headers for Cryptographic E-mail it’s unfortunately not widespread. Proton Mail for example doesn’t support it.
Email metadata is a lost cause, you’ll never be able to encrypt To, From, and that’s some of the most private data out there.
I would agree that is one of Skiff’s benefits, which I did mention above. For a small team that mostly keeps things internal that would be the strongest customer base, unfortunately by itself, it’s quite niche.
This doesn’t really help with incoming email from various sources or if you have to share something sensitive with an external user.
For user support I actually think a forum-styled system is better because bar of entry is low, and content can stay up there long term, and it certainly helps with SEO. Common go-to services for this are https://www.useresponse.com and https://uservoice.com.
They do, it was just something that I noticed. Might be worth adding that to the bottom of your page footer. This had no bearing on listing, but I thought it was worth mentioning anyway.
Okay, that wasn’t really obvious to me.
Just to clarify, I was not saying that VC funding is bad, or anything like that, only that it is cruicial to viability of a company to continue, especially during the early days. VCs do without a doubt want to see a ROI.
Yes I noticed that, and I figured as much. I do get that creating an email provider from scratch is hard because you basically have to provide what users of other services already have. Your competition is well resourced, Google, Proton etc.
Yes, I’m well aware they do that.
Are any of them public? I would be curious to take a look.
They’re not in a publishable format today, but we are undergoing one with Cure53 (https://cure53.de) next that we plan to publish.
Also, to clarify the E2EE doc case, I agree the UX is worse but you could create a Skiff document, create an editable link, add a password, and send it out to get the same benefit as a password-protected email. We hope to add that feature soon.
I’m really glad to hear that .
You’d still have to send out the link, which would be difficult.
Couldn’t you just make a doc, make a public link, and send that via email? Doc stays E2EE (you can add password).
I agree this is more complex than an email password button, but we had originally made this use case with Pages (our first products) so you could share E2EE data externally.
I’m not sure why that site is replying with those results. If you look at hardenize.com, you can see it is a clean report.
I also reran the test on internet.nl and it shows the correct results when I ran it. I’m unsure why when you ran it, it didn’t show a lot of those protocols showing up.
The github issue mentioned that it was acceptable to have SES as long as there is a plan to deprecate and this is also reflected in the listing criteria.
However, I personally believe this is minimal risk as our servers with TLS 1.2 and ciphersuites are prioritized over SES. The SES server should only be used if our primary server is down as mentioned in the comment. This is also mitigated that email clients (sending servers in this case) will negotiate the highest possible TLS and cipher available to it and the server (Skiff’s mailserver in this case).
I believe that this poses a minimal risk to users but acknowledge that downgrade attacks can happen. For this reason, we have a plan over the next 3-6 months to deprecate SES as a backup solution.
I agree on the ciphersuite ordering issue and security.txt. I’ll get the security.txt in this week but hopefully sometime tomorrow along with the ciphersuite changes. Appreciate the help here!
Isn’t sending a link via signal or some other E2EE messaging platform more secure than a link sent over email? I would certainly think so. A user isn’t prohibited from sending over email and we can do some UX to make it more integrated for sure, but the ability at the end of the day is there along with using a more secure transmission mechanism like Signal. I would argue that is stronger.
This is a terrible user experience that in practice users will never do. Nowhere on the site instructs them to do this to circumvent limitations in the product. One of the main points of email is that it is an immutable copy, like a letter in the mail. It cannot be changed or revised after being sent.
The criteria on the site is very much an entry level bar (must pass to even consider discussion), it isn’t however exhaustive. Some things are more important than others.
Unlike other websites we do thoroughly test the products before adding them. It has to pass the “would I recommend this to my client test” as well. I work in an area, where I provide consulting services. It is often my job to find a solution to recommend to my clients that can solve their particular use case.
Not so sound paranoid, but I wouldn’t be at all surprised if there wasn’t a PRISM ingestion point on the SES network. Without E2EE to external users there will be a high chance that email won’t be so private.
I do see three major issues preventing Skiff Mail from being added at this time:
- Not E2EE as soon as it leaves Skiff network, not warning to users about this, essentially leading users to believe everything is E2EE. The blog article on E2EE is a good explanation of what E2EE is, however the product does not reflect this description in practice unless, you’re a Skiff user sending to other Skiff users.
- No ability for users to leave Skiff, if they decide it doesn’t work for them, there are going to be users who decide they need nested folders and filters to sort email.
- No ability to get email header information, this is important for forensics or determining whether email received is phishing.
It however may be more appropriate to recommend this product on our The Best Private and Secure Cloud Storage Providers - Privacy Guides page or Notebooks - Privacy Guides section. Of course, I would really like to see that Cure53 report first.
I’m also keen to hear back from @amilich in regard to the other issues mentioned in my previous posts. I’m also curious to know where the “30,000 external users” data comes from, because I’ve noticed you say this a few times here, and on Reddit. I don’t believe that is true at all.
I do obviously understand that will take time to reply.
It is very worrying that you do not have an answer to why this occurred as it comes from your own DNS configuration. If it doesn’t show now it means that you have changed the config. I am happy if it is solved, but does that ensure it won’t happen again. Did someone test in production?
If TLS is set to preferring a certain version it is prone to downgrade attacks. Many evil governments make use of this to extract user meta data therefore it is better to enforce it. Nobody realistically relies on TLS 1.2
Also yet again it shows the issues mentioned above today: Email test: skiff.com
It’s quite demoralizing and frustrating from the corporate experience to be put in this position (I’m Skiff’s CEO). I see the greatest success for Privacy Guides to work with companies to make more privacy-respecting, secure services. We’ve done exactly that in good faith - respecting your criteria and allocating engineers on our team to get us to the point of recommendation. This costs an enormous amount for a product to implement.
We’ve now spent months implementing all of the best practices, both because we want Skiff to be as secure and private as possible, and because we want to be recommended on your guide. We’re becoming quite popular (almost half a million users in the last year) and would love to share and help grow your community while ensuring that products are held to high standards. Moving the bar constantly is extremely frustrating and demoralizing to our team. Transparently, it’s hard for us to even believe that the criteria are created in good faith.
Our solution for external sharing was not intended for email. It is much more powerful to share E2EE real-time collaborative docs/files with subpages, embedded E2EE files, and so much more. It’s both confusing and frustrating to require that we implement a less powerful, worse experience that was never part of the original spec.
Email headers is a reasonable feature to look for, but password protected emails and feature requests (like nested folders) are completely out of place.
The features discussed will help your users in the immediately as they are industry RFCs that many email providers (including non-privacy ones implement).
If we did add Skiff Mail, it would be one of the weakest recommendations when compared to the others listed. That would not be fair to the others already listed.
That may be the case, however this evaluation was for listing in the email section.
There are certain expectations for email, these are that not collaborated on (unless you have shared inbox functionality). Once an email is sent it is not expected to change. This is vastly different from a collaboration office suite use case. They are complimentary tools to each other and they have their different roles.
What you’ve suggested, (paraphrasing), “just send a link to an encrypted document”, would be like me having explain to a lawyer that he “doesn’t want email” and he should just talk in a “online office suite”. They would not be happy with that solution.
The issue still remains that people will use your service and be under the illusion that emails that sent to remote providers are E2EE. That is a big problem and one you still need to address.
Even if you do not have a technical solution to that problem, you need to be honest about it to your customers. Accepting limitations of a product and informing users about that is something we hold in high regard. After all their safety should be first priority.
The popularity of your product is not something we evaluate, and it doesn’t concern us in our evaluation.
Our priority is to evaluate products and inform our readers about that product and what our experience consisted of. It is one of the reasons we do not accept money from any of the products listed, unlike some other websites.
Our site has always been community focused, factual, in evaluations.
The things I mentioned in my review weren’t necessarily blockers to being added. They were observations I made and I wanted share with the community.
The criteria is very much a minimum bar used to filter out products which are not “up there with the others”.
We are evaluating you on is the lack of export functionality.
This is important that customers and their data are not locked up in a service that they cannot move away from should they want to, or need to. I acknowledge that you say this feature is coming.
The other things I mentioned (filters, nested folders etc) are observations I made while testing the product. These things are common enough and its important users know what they are getting into before they use your product, as they may rely on these things for their workflow.
Password protected emails are important. A common usecase has been to share a “password” during a phone call or an in-person meeting. Then the sender will supply the document required to their customer or contact.
The extra functionality such as collaboration is not always needed when sending a sensitive document. In my consulting, my clients regularly want to send privileged legal documents or medical reports.