Are some of the audits going to be available?
Is this in response to my comment or for OnlyOffice?
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.
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.
I expect us to release email download in the next 2 days as well.
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.
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 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).
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.
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
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
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!
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.