August 14, 2014
On status reports, transparency and overall safety
While running a company from the U.S. has its benefits, when the goal is to provide improvements on privacy, the “where” matters almost as much as the “how”.
One of the things we have been debating internally for some time is the implementation of a warrant canary. After much anticipation, the day is finally here!
What’s a canary?
When it comes to privacy, trust is a complex value to earn. We’ve been asked a lot of questions lately such as, “How can we know you haven’t inserted a backdoor and are now legally restricted as to what you can say?”.
If your conspiracy theories go far enough, then the answer to the above question is you can’t.
But, we are a widely distributed team, holding us all under some (possibly questionable) law is going to be hard, and the goal of what we are doing here is exactly that: making sure access to your data is as complicated as possible. It’s never going to be impossible though.
So a warrant canary is one more obstacle somebody or some entity with enough power would have to circumvent, and it works just like Homer Simpson’s Everything’s OK Alarm.
The canary will be around as long as everything is going smoothly, otherwise it’s not going to be updated in the expected timeframe.
More details please?
The canary itself can take many forms, the one we’ve chosen is a specific plain text signed with multiple GPG keys.
The GPG keys belong to different SpiderOakers which we’ve selected based on geolocation. So besides doing all the legal (or illegal) things an adversary would need to do to get a backdoor somewhere in SpiderOak, they’ll also need to compel 3 people around the globe to sign a message at a specific moment in time.
How often will the OK alarm beep?
The timeframe between canaries varies depending on the aspects considered. We initially thought once a month was a reasonable timeframe, but then discussing it a bit longer and the reasons behind what other people have done, we realized it was too short.
The EFF has compiled a really helpful FAQ on this subject, and in there they raise an interesting point: even though you might want to publish a canary often, if you do get something like a NSL, you’ll have to go to court or do other legal stuff to find out more about it. If it turns out it’s just a bogus claim or something you can fight against, that’s great! But it might take a few months for you to find that out, and in the meantime you killed the canary.
In cases such as SpiderOak, killing a canary can quite possibly mean killing the business, so we switched to publishing the canary every 6 months. This means the first canary will be signed between August 10 and August 15, 2014. The next one will be signed between February 10 and February 15, 2015.
It indeed sounds like a lot of time, but it’s the best compromise we’ve found.
What if one of the people in the signing group goes rogue?
The canary signing group of people is bigger than 3, so if somebody is unavailable for any reason he or she can be replaced by a backup.
If somebody in the group goes rogue, or simply leaves SpiderOak, a canary-like message will be published, signed by the trusted parties explaining who is no longer in the group and who’s replacing that person.
Where will we find this canary thing?
It’ll be in the form of a blog post, with the same Category as this one: Status Reports. So people subscribed to the blog can be notified immediately of the canary update. And it will also be available through the following static URL:
Which will be what’s linked from SpiderOak’s homepage.
How do I verify that the canary is correct?
The way you can verify this:
- First, create 4 files: one with the canary text (canary.txt), and one for each signature (sig1.asc, sig2.asc and sig3.asc).
- Download gpg
- Run the following commands:
gpg --verify sig1.asc canary.txt gpg --verify sig2.asc canary.txt gpg --verify sig3.asc canary.txt
They should all output a message containing “Good signature from <person from canary group here>“.
The keys on the default canary group are:
Key ID: 0x1712D3E36F2F0403 Primary key fingerprint: 0DAB 1518 36A3 CBBA 0362 FC17 1712 D3E3 6F2F 0403 Key ID: 0xE435F15CA6B145F8 Primary key fingerprint: B411 3438 B56B D51C D208 E17E E435 F15C A6B1 45F8 Key ID: 0x132B9F2251131E5C Primary key fingerprint: DC1E FB15 4444 E4B5 2726 8430 132B 9F22 5113 1E5C
I understand it’s not the easiest thing to do, but it’s something you can do twice a year if you choose.
Nothing is set in stone though, if we find an easier alternative to check while maintaining the same degree of security, we’ll migrate to that method.
Any change on how the canary works will be posted and signed in the same way as the regular canary.