Skiff Mail (Email Provider)

Site Development Tool Suggestions
10

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.

I’ve seen that on Telegram and Discord as well. The main concern is that Discord encourages users to hand out their phone number, and provides no E2EE on messages. While it could be argued there nothing is really private there, inevitably you’re probably going to field support requests from that source. Discord’s privacy policy is a bit opaque when it comes to collecting data for advertising, where it ends up, etc.

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.

:+1:

Are any of them public? I would be curious to take a look.

3 Likes
11

They’re not in a publishable format today, but we are undergoing one with Cure53 (https://cure53.de) next that we plan to publish.

12

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.

13

I’m really glad to hear that :+1: .

You’d still have to send out the link, which would be difficult.

14

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.

15

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.

Screen Shot 2023-01-08 at 9.48.05 PM
Screen Shot 2023-01-08 at 9.48.05 PM818×842 17.9 KB

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!

2 Likes
16

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.

1 Like
17

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.

3 Likes
18

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?

19

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

20

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.

4 Likes
21

The features discussed will help your users in the immediately as they are industry RFCs that many email providers (including non-privacy ones implement).

On the current criteria we do have core requirements, that being E2EE and do evaluate other such things such as marketing used surrounding a product.

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.

5 Likes
22

Export/headers/password protection are all great features to have.

I still completely disagree with Skiff Mail being the “weakest” recommendation. Nested folders were not supported on Tuta until a month ago, and Skiff Mail has numerous other helpful features that are either paid or non existent on Proton/Tuta (schedule send, auto reply, default signature removal on the free tier, both folders and labels, separate Calendar application, native macOS app, etc.).

1 Like
23

It is because all the others provide some way to send an E2EE email. The issue with Skiff is that it is difficult to make that initial share without using some other product first.

Sharing a document on a collaboration suite, isn’t the same as an immutable copy with a date on it at a particular point in time.

The email header functionality is crucial for determining whether someone is the target of spearfishing. Some scammers will go to some effort to find out a lot about a victim, their org and then try to pretend to be someone within that org. All our current recommendations allow for this.

That was not part of the evaluation, but something I noticed along the way. It was worth mentioning because it is a feature that users may have had with other providers that they will lose when importing their mail into Skiff.

The last client I migrated had over a thousand directories. They had been using email for 20 years and had about 40k emails. They did not want to lose that structure, and it was necessary that the product I selected for them supported that feature.

The first tier of paid usage on Skiff is quite a bit more than it’s competitors. Sure, you do get more storage, but quite often a user won’t have 100GB of email or files to store. This impacts your product, because it means that a lot of people will stay on the free tier, which doesn’t make you any money. Money is needed for viability, and its important that the company remains healthy.

3 Likes
24

I am going to vote AGAINST listening Skiff.
I have made a test account and for this account I have set a recovery email. After doing this I started receiving unsolicited spam from Skiff on this email address. I have never signed up to the newsletter and this email alias was created today specifically for the recovery.

For this newsletter the email alias is shared with Sendinblue to send out the newsletter. I have never given any consent for this. Unacceptable. Generally sending out marketing emails.

Besides my sincere doubt about the security settings and the professionalism of the team on this, this is an absolute no go. I am leaving this discussion feeling betrayed by Skiff, this is a false privacy promise.

1 Like
25

You received a product update with no tracking that can be opted out of. However, these emails should also go to your Skiff Mail address, not your external one.

I apologize for this - it is likely a bug from when we went from emails as logins (before Skiff Mail) to usernames as logins (everyone gets a Skiff Mail address). There are no trackers in the emails and you can unsubscribe to this and all future mail.

We don’t use Sendinblue.

I apologize that you feel disappointed, but I’d suggest looking at the responses above in good faith and realizing that we spent months on the recommended criteria - not even the minimum criteria.

3 Likes
26

To even explain more, many Skiff users only use Pages/Drive. Until May 2022, no Skiff user had a Skiff email address. So, all of those users received a Privacy Digest update containing product launches.

Here is a public link with a year of such updates:

https://app.skiff.com/docs/5a69bd5c-30bd-4e3f-bc32-411732454892#iZIdgMgnTY2Wkra%2FtDQl1%2BE%2FpfP5dK5%2BU8KyuLUBDks%3D

1 Like
27

I will correct it was indeed Sendgrid, not Sendinblue, doesn’t change the argument.

Skiff send a marketing email, regardless of whether this is a product email it is SPAM. I do not want to unsubscribe, I never signed up for this.

Good bye

1 Like
28

It’s not spam. It’s a critical product update with a major new feature offering. How would you suggest we notify our users that they can now privately purchase domains for even more private email? Or, that Skiff Mail even exists?

Sendgrid is used to manage unsubscribes in the email. As a note, other services you recommend use similar products. For example, Bitwarden users Hubspot to manage their product updates and newsletter - Hubspot is much worse for privacy than Sendgrid, which is a transactional mailing services.

Honestly, it’s so frustrating to see us held to arbitrary standards not enforced to the other products on the site. It breaks my heart to see our team respect your criteria and process and feel like they’ve been slapped in the face after months of work.

4 Likes
29

Also, I’d love to get Skiff Drive and Pages considered as well. I believe they are quite compelling feature wise compared to Cryptee/ProtonDrive/NextCloud. Should we open a separate ticket?

1 Like