As a total outsider to this discussion, both (a) asking for claimed open-source development to be open-source and (b) asking for audits to be published seem totally fair to me.
It depends on the scope of the audit commissioned, this is what weâre curious about. The more things it covers, the more expensive it will be.
I think youâre misinterpreting what I mean by âdeveloped in the openâ, what weâre talking about is an open workflow where issues (bugs) are raised, which in turn progress relate to pull requests. We see this with major vendors like Redhat, Mozilla, even Google for example. This enables external contributors to, âget up to speedâ, or even know what youâre working on.
That is very much the direction we want to have, once there are products in that category, likewise if it were a requirement we need to also be able to point to such an audit in some way. If there are no audited products we canât have that hard requirement. As an interim, we use a ranking system to put the products which have audits higher on the page.
That is optional. Google uses an OAuth API which is quite clearly documented. The only thing Google really knows is that someone might have a Cryptee account if they choose to use that feature. In any case I donât think these comparisons to Cryptee are helpful, and it feels a bit like a straw man.
2 Likes
The product is open-source, but we do not open-source in development features. We publish on major releases, which is consistent with products like Signal (recommended).
Did you realize that Tuta and Proton do not publish audits? They have published some attestations, but Trail of Bits (our auditor) does not write attestations. Other products weâve mentioned (Cryptee) do not even have audits.
It takes 5 seconds to verify that Trail of Bits did complete 2 audits of Skiff that were each 4-6 person weeks, which covers everything in our product, codebase, SDLC, infra, etc.
If you read the thread in detail, youâll see what I am pointing out as the core issue: Constantly changing requirements and comparisons.
1 Like
Itâs strange to have such common practices treated with such skepticism. Given the CTO of Signal is an advisor of ourâs, and the CEO of Trail of Bits is as well, of course we would rely on the best practices set by those organizations, which are the top in their respective domains.
@dngray if it is an issue that you do not have enough products on the collaboration products, notes, or calendar pages, why not add Skiff Pages/Drive/Calendar?
Okay, so thatâs going to become a regular thing now?
I did say that would be sufficient, as it would have information about what was undertaken, and give us something precise to link to.
Theyâre also not claiming to have an audit either.
Thatâs the first time youâve mentioned the scope of the audit.
I donât doubt the quality of their audit, I just wanted to have some more information about it, and something we can link to if we do mention it. Weâre not a fan of making a claim on the site we cannot back up with a citation.
The audit would indicate where on that page it resides. That is the point Iâm trying to make. Ideally I would like to put it above Cryptee because it has an audit.
1 Like
Meant to post from my public acct:
What do you mean claiming? You can see it publicly on the Trail of Bits website, multiple times. Dan also tweeted about us here - https://twitter.com/dguido/status/1498403981978124299. Weâre working on more but TOB does not do attestations.
Why not link to the TOB site demonstrating that they did an audit?
Here is a quote Dan sent me that heâs shared with some of our advisors before:
In Skiffâs case, our last project was 6 person-weeks of effort and reviewed all available source-code for the project. This let them achieve a substantial depth of coverage, given the large amount of time, the expert qualified staff from Trail of Bits, and the open availability of the source code and interactions with their engineering team. In my opinion, the latest Skiff audit represents a substantially larger investment than what other privacy projects typically make (e.g., they are typically from a low-quality firm, have a small level of effort, and a limited scope).
I understand how important this information is and am glad itâs getting covered. A lot of the frustration is that many years of work goes into preparing for even submitting to PrivacyGuides, which I would regard as having some of the highest criteria in this space.
Not anything bad.
They did, and I donât deny that, its just that besides them doing one, nothing else is really known publicly.
People will wonder about context.
It does sound promising, but I canât really link to a forum post in the description.
Precisely, too few things are audited.
The reason we do that, is because we want to cut through the noise and be able to clearly define best options in the market. At the same time our reputation is also important, so for us to endorse a product, we truly have to believe in it/be able to justify enough to use it ourselves, (if that makes sense).
I donât doubt that Skiff related system of products will be good. As far a source/repositories go weâd like to see something more like this which will in turn lead to more of this and that (if you get my meaning).
1 Like
I totally understand - this is a great example of a direction we should be going in. FYI, Skiff is much younger (Proton will turn 10 this year, and Skiff 3). We only started the discussion when we were confident that our products stand the test of the criteria and guide.
1 Like
I think w/ our latest criteria changes, Iâd be fine with adding Skiff Mail once Amazon SES is no longer in use, which is something thatâs planned anyways to my understanding?
Going to mark this thread as âwaitingâ (for that change) and see if the rest of the team has any other input?
That makes sense. We have definitely been planning on removing it. Iâm assuming you still donât like the SES as an âextremeâ backup if Skiff mailservers go down? As an engineer I always like having more backups, so it would be helpful to know.
Yes, basically.
We added a criteria (within the last few weeks) specifying that mail infrastructure has to be on servers you own/operate instead of outsourced. There were a few reasons for this, having a setup like yours might enable downgrade attacks if inbound-smtp.skiff.com was blocked on a network for example. Ultimately we feel itâs conceivable that backup MX servers might be used in situations other than actual outages of the primary servers, and itâs easier to just avoid that situation altogether.
Since mail senders are required by spec to retry delivery if the receiving server is offline for at least a good while, Iâm not really concerned about outages personally given that they donât last 1+ day or anything⌠Of course if you had a mail server on separate infrastructure with a lower priority for backups that you still manage yourself that would be fine. (It could simply queue incoming mail for delivery once the primary servers come back online, so it would potentially be less complex and less prone to outages than your primary servers.)
Even ignoring that, not being able to configure the security defaults of Amazon SES would disqualify you anyways once the changes at Minimum TLS requirements (for Email Providers) are made, which sounds like will be happening soon based on our talks with other providers so far. (Your main mail servers already meet our future criteria in that thread).
Shouldnât this be the biggest blocker? It would seem that being hosted in the US is a severe disadvantage for Skiff as opposed to Proton Mail (Hosted in Switzerland).
I fail to see how the ECPA will affect it though, as it only affects emails stored for 180 days, which will obviously not affect Skiff seeing as they are stored E2EE.
When it comes to incoming messages, itâs a lot unclearer. Lavabit was forced by a federal judge to fork over the encryption keys. What exactly is stopping the same from happening for Skiff?
Also, bare in mind that the number 1 flaw of any email service is that they rarely use E2EE with one another, only with one self. Hence most incoming emails will never use E2EE, so it would seem that Skiff could be affected in the same way Lavabit were.
Any plans of hosting the data for European users in Europe? : Skiff (reddit.com)
According to skiff, American privacy laws are goodâŚ
I think we will likely remove this requirement for this reason if/when we add Skiff Mail, as all of the providers we recommend will use E2EE storage (hopefully anyways⌠Startmail kind of doesnât, but weâre discussing that in another thread and may just end up removing them).
They didnât exactly win me over when I read that. I also fail to see why they would delete the thread unless Iâm missing something.
The thing that worries me the most with Skiff is that when it comes to messages sent E2EE, their choice to host it in the US doesnât matter. When it comes to messages that arenât E2EE on the other hand, which is inevitably going to be most of them, the lack of E2EE is definitely a problem. The situation with Lavabit shows that.
Being in the US would also give the NSA and similar organisations an advantage. Switzerland is hardly perfect, but I fail to see how the Lavabit situation would ever happen over there. Proton Mail has been around for ten years now and the worst thing that has happened to them is that they were forced to log an IP of a terrorist.
In short, I fail to see how they can consider the US to be a better choice than Switzerland.
Hi all,
Skiffâs director of security chiming in here again.
Thereâs a lot in these previous comments about US jurisdiction and Iâm not a lawyer so canât provide legal analysis or recommendations. However, I want to clarify a few things that could help to provide a more constructive conversation.
-
US companies that handed over data to the NSA often did so under a secret court order because these service providers saved the underlying data in a way that they had perpetual access to this data. Iâm not here to argue the moral or ethical implications of this. Just trying to establish a common baseline of facts. (Yes, some companies may have more willingly handed over this data than others.)
-
Skiff does not have access to any emails once they are encrypted in our inbound processing pipeline. Skiff performs actions such as spam detection and virus scanning that are legitimately in the userâs interests and ensure viability of the Skiff email product. However once Skiff goes to store this information, we encrypt this data with the userâs public keys and never retain any copy of the underlying email. At best if Skiff is asked to hand over existing data under some secret court order, we would only have access to the underlying ciphertext. (This is all outlined publicly in our whitepaper that I recommend reading at skiff.com/whitepaper)
You can argue that this is insufficient still but I want to lay out the basic facts so that we can have an informed, productive conversation rooted in technical facts that moves beyond âUSA badâ
Thanks!
2 Likes
After they are encrypted the emails cannot be accessed by you. No one is disputing this. My worries lie in that you can be forced to save (non-E2EE) incoming messages before they are encrypted just like Tutanota were in the past. I have yet to see this happen for a Swiss company, and it seems to have happened in the past for at least one US email host. That being Lavabit.
I think the concern being brought up here is not regarding keys related to storage, but rather keys related to transport encryption. In the Lavabit case brought up earlier, the US government requested their TLS keys to intercept future traffic, not keys to access existing mailboxes. I donât see how Skiff Mail could work around this?
That being said, I donât think this issue is a blocker for adding Skiff Mail in the first place. This is kind of outside the threat model of most people.
2 Likes