Skiff Mail (Email Provider)

Are some of the audits going to be available?

1 Like

Is this in response to my comment or for OnlyOffice?

1 Like

In regard to Skiff, I was just curious about if there was some kind of ETA on the cure53 report.

As Skiff uses its own encryption, (and weā€™re not cryptographers), weā€™re keen to know what professional cryptographers have to say about it.

1 Like

Itā€™s coming up this spring but weā€™ve done 3 additional security audits. Do you have any particular questions that we could send to Trail of Bits? You could ask the CEO on a public forum or anywhere else. Also, just wondering - I didnā€™t see public security audits for a bunch of other recommended tools. Is there any reason why it feels like we have to exceed additional criteria?

I think having criteria is great because it makes a process objective, but that has to involve sticking with it.

1 Like

I expect us to release email download in the next 2 days as well.

1 Like

Not specifically, weā€™d like to see the report in itā€™s complete state. Customarily we also link to the report in the description so that our recommendation can be validated.

It may very well be added to the criteria shortly. The reason is there are a lot of ā€œweb appsā€ which offer ā€œE2EEā€, but are designed by web developers without any background in cryptography. We donā€™t want to be adding those kinds of things to the site. If thereā€™s anything to learn from the LastPass incident itā€™s that these things need to be validated to ensure quality.

Weā€™re not singling Skiff out specifically, but it is a shift weā€™ve made across the site (you may notice that on the instant messenger section) for example. We are dubious about adding anything that doesnā€™t have a report but offers E2EE as a feature.

It does, but we also donā€™t want to be in a position where we canā€™t tighten it either without removing a heap of recommendations that we previously made. We try to make recommendations based on what we expect the tentative criteria will be.

1 Like

I donā€™t believe that this is common practice. It is totally fair to ask for something to back up our e2ee claims but simply stating to want to see the entire pentest report is a standard no one else is being held to including

  • most of the products listed on this site
  • is not industry standard
  • Protonmail has switched to releasing letters of attestation

We can argue all day about what the standard should be but again, this is not standard. These reports are typically shared under NDA for large customers to gain an understanding of a vendorā€™s security program. When auditors write these reports, they are not written for a general public audience even for a technical one.

Yes, I also have worked in appsec my entire career and have run multi million bug bounty programs, conducted internal and external technical audits, built vendor security programs, presented at reputable conferences so we also have some idea of what we are talking about as well :slight_smile: We are not some random, shady shop sprung out of the depths of the internet trying to trick users into handing over their data. We also have a fundamental belief in user privacy which is why Skiff set out building e2ee applications in the first place. We have put a lot of thought and effort into building a modern e2ee application worksuite and I highly encourage you to read our whitepaper which outlines so much.

A reasonable ask would be to open source the crypto libraries, ask questions on the core crypto components, and ask for some proof of an audit. Weā€™ve done the first. Open to questions and engaging on discussions there. And third, weā€™re working to release some joint statement with Trail of Bits on this.

Regarding the claims on the crypto libraries, a very reasonable question would have been asking for how our core crypto libraries work which could be examined and verified using a web debugger to see these libraries working. We didnā€™t invent any crypto. We use standard accepted libraries like tweetnacl and have open sourced the core abstractions built on these standardized crypto libraries to make these claims easier to verify.

Not only this but all of our advisors reputation is at stake such as the CTO of Signal if we were to be unintentionally or intentionally lying about these claims as you seem to be suggesting.

Iā€™d much rather engage on real technical discussions or reasonable asks like mail import (which we have prioritized as Andrew mentioned) or the entire checklist for mail service providers like in the original github issue (which we also accepted as reasonable and largely completed that work).

3 Likes

It does happen particularly for new products, and weā€™ve seen that with Signal audits regarding the protocol, as well as Matrix in the past. These components generally donā€™t change significantly.

Weā€™re not necessarily saying we want to see the ā€œentireā€ pentest report, just the part that relates specifically to Skiffā€™s E2EE implementation, and what the status of that was.

While Protonmail may very well have done that, they are a significantly bigger and more established company. Does Skiff have such a blog article pointing to their letter of attestation? The TrailOfBits audits donā€™t really have any online footprint that I can see besides what is claimed here and a very brief mention on Publications from Trail of Bits. It does not say whether anything was found, or anything still exists.

It still remains that Skiff is still a fairly new company that had itā€™s launch late 2021, the pivot to email was more recent as of 2022. It is newer than most other companies in the industry. Just to reiterate, weā€™re not quizzing you on these things, because weā€™re singling Skiff out, but rather we do want to tighten that category.

Iā€™ve read that whitepaper and it does make sense to me, there wasnā€™t anything out of the obvious there, however my area of expertise is not cryptography.

This would be the sort of thing weā€™d be very interested to see, because currently it feels very ā€œunofficialā€ that audits have even taken place. Normally companies are quite proud and will announce that it has taken place on their blog.

I wasnā€™t inferring that you were ā€œlyingā€ about anything specifically, just that a blog article with some official mention of the audit would be useful when claiming that one exists. it would be useful for us to link in the description. The method youā€™ve described above we have in fact in regard to some other products ā€œout thereā€.

To begin with I think weā€™re looking at adding this to the productivity tools section and the calendar contact sections.

Just in regard to @ph00lt0ā€™s concerns about GDPR, it does seem that youā€™re still sending marketing emails to userā€™s recovery addresses. I think these emails should be directed to their @skiff.com address as a recovery address may not be very private.

The general standard isnā€™t to send marketing emails to recovery addresses and in fact Iā€™ve never seen a product do that.

I agree with this and weā€™re working with Trail of Bits to get a public blog post or attestation out. I hope that happens soon. I think we donā€™t take issue at all with some criteria related to audits, just that weā€™ve done everything by the book and want to be an incredibly strong recommendation.

We launched EML export yesterday (I worked on this personally!), which should resolve some other concerns above.

3 Likes

It would be great to be on the Productivity/Calendar sections. As a note, I donā€™t see anything about CryptPad being independently audited, let alone requiring that the audit be reviewed or have a public attestation.

Iā€™ve tested it just then, works quite well, which also means headers can now be accessed :+1:

It would seem that each email has to be individually exported, this limitation would be something we have to mention in the description as we have with another email provider, as it makes it still quite impracticable to export a users entire mailbox.

I did notice a bug when I sent a plaintext email to my Skiff address.

I replied to it with my Skiff address and the plain text part on the reply didnā€™t have any line breaks, where there should have been. The HTML portion was also on one line, but thatā€™s okay as the <br> and <p> tags were intact.

Itā€™s not, but we would like to mention that Skiff is in the description (and cite that), as a result it would also get a higher ranking on the page, until which point we have enough options, to tighten the criteria, keeping the best.

I completely understand, I think we just would like to know what we are missing to be on Productivity/Calendar today and on Mail.

I replied above, (edited my reply and addressed the EML export thing).

I didnā€™t expect you to reply so quickly :slight_smile:

I would be curious to know whether this EML export feature could at least be expanded to at least allow folder/label export.

I am definitely open to that, we will work on export features but it takes time. I personally implemented the EML export and also redid our Pages/Drive export to do Markdown export for files, folders, and ZIPs as default.

So, I think itā€™s a great feature for us to implement, but is that what is missing to be recommended as an email provider?

Not sure what you mean by description on the page - am I missing a section on productivity tools?

I tested that just then and it works particularly well. It includes all sub pages which is wonderful. Very nice to see LaTeX support there too. I could certainly see this being used by students in compsci for collaboration.

Iā€™m talking about on the email, description, like we do for Tutanota, we mention that you can only export a folder of emails at a time. In this case we would have to mention that you can only export individual emails.

This is typically where we mention any attestation reports, or audits, or anything of that nature. We do sometimes mention limitations there as well.

Depending overall on how the product stacks up against competitors, we adjust its placement on the page.

Just a further detail on that. I noticed with the address that I have no recovery email set, the marketing emails are correctly placed in the skiff.com inbox. I think this should be the default. Not sure if you have an internal bug about that.

It is definitely a bug. What should happen is that users who signed up before Skiff Mail should receive it at an external email, and Skiff Mail users should not. But sometimes the earlier users then later signed up for Skiff Mail. There are a lot of nuances like this, but it categorically does not conflict in any way with GDPR; these emails are also likely transactional as they are to users who have signed up and are receiving information on how to set up new features. For example, Gmail import, remote content blocking, etc. They also all have unsubscribe links.

That doesnā€™t happen to be the case. I signed up after Skiff Mail, gave it a recovery address, and the emails are being sent to the recovery address and the skiff.com address. This account was opened on the 10th January 2023 so thatā€™s certainly after Skiff Mail launched.

Users in this case may very well want to see these emails, but not on their recovery inbox.

Any updates on the thread regarding adding Pages/Drive/Calendar and Mail?

Does Skiff Drive support backward secrecy?

Suppose someone, say X, has access to a shared folder. X decided to store the encryption key of the root shared folder.

In the future, if X gains access to the encrypted metadata and content of new subfolders & files under the original shared folder, can they decrypt the content even after the password has changed?

My preliminary examination of ProtonDriveā€™s architecture suggests they have a similar issue, although I havenā€™t confirmed this yet. According to the whitepaper, Skiff seems to have similar architecture, but I decided to ask here.

Unfortunately, I couldnā€™t find a whitepaper on Cryptee. But, if I have to guess, most drive products might have a similar issue due to the complexity of solving this issue.

PS: I am an early adopter of Skill mail and pages and am excited about its future. Best of luck to you and the team!

1 Like

Itā€™s not entirely fair to evaluate Skiff against newly proposed standards, as there are already established services that donā€™t meet these criteria.

If PrivacyGuide wants to introduce blocking standards for new services, it should be clear and upfront about it. This would involve adding prominent warnings about the existing services and specifying all the criteria they donā€™t meet.
Also, simply stating that Skiff meets a certain criteria doesnā€™t necessarily address the lack of warning for legacy listings.

3 Likes