Building a Better Dead Man's Switch
Building a distributed Dead Man's Switch on Oasis

Table of Contents

What is a Dead Man's Switch?

A Dead Man’s Switch is a tool for releasing sensitive information. The tool allows you to upload sensitive media—documents, videos, photos—that you’d like to be made public at some time in the future, or only to certain organizations. For example, you could pick a release date that makes the information public:

  • Once you leave a certain country (e.g., if you fear retribution from a government)
  • When you die (e.g., a last will and testament).

Example use cases

Insurance Policy for Physical Safety – A front line user can post some information that becomes public (for example) the following week. Week after week, the user can press a proverbial button to delay the release of the information. If that user is apprehended or detained, the information would become public. The switch effectively acts as an insurance policy on the user’s safety.

Human Rights Trust – Videos and photos of atrocities are submitted to a repository but not released publicly until the uploader chooses to make them public, or is detained. This could be useful for human rights organizations and teams working on the front line.

Whistleblowing – You can post sensitive documents you’d like to be made public while keeping them encrypted, without having to trust a platform such as WikiLeaks to configure its technical systems correctly.

Last Will & Testament – Use our tool if you are in a jurisdiction with poor rule of law and wish to release some information upon your death.

Motivating a distributed Dead Man's Switch

If you’re a looking for a Dead Man's Switch, your options today aren’t amazing.

  • You can reveal the fact that you have secrets without revealing the secrets themselves, but that could get you arrested before you can release anything.
  • You can trust one or a few people, but you then have to trust them with multiple copies of the data, and trust them to coordinate with one another (and with you).
  • You can use a centralized software solution, but such a service can be pretty easily taken down by someone with political or legal means. If your adversary has some technical chops, the documents on that service could also be tampered with — -you might be able to prove the tampering occurred with a hash, but good luck recovering the data.

Your options today are:

SecureDrop – You can send sensitive information to journalists, but must trust the journalists to have configured SecureDrop correctly. You also need to trust the journalists to release your information publicly in a timely manner, and without editing the information. Our tool does not place any setup onus on newsrooms or other trusted providers; it runs on a decentralized1, peer-to-peer system. – This tool is closed-source and thus has no particular security guarantees. It is also centralized, meaning that, like SecureDrop, you must trust the system’s operators entirely with your security.

Self-encryption of documents – If you're technically minded, you can encrypt the data yourself. But, if only you have the decryption key and you are apprehended, the documents cannot become public. In our system, your decryption key is decentralized, allowing information to become public even if you’re apprehended.

Something like IPFS would help us post files in a tamper-proof, uncensorable way using content addressing. But if you want to encrypt the data, how do you manage the release of the encryption key?

Our system

This is where Oasis, a smart contract platform that supports confidential state, comes in. In our system:

  • Neither the documents, nor the fact that they’ve been posted, can be censored or taken down.
  • The on-chain contract manages the coordination among trusted parties required for the key release.
  • When the documents are released, you can definitively prove that the now-public document is the same as the once-secret one.

From this technical vision, I undertook an iterative cycle of design and development, described below.

User studies

My development process was iterative, designing a smart contract on Oasis while simultaneously performing user studies with help from Rachael Cornejo. In this section, I'll describe our user tests, and explain how they motivated specifications for the Dead Man's Switch.


We talked to eight potential stakeholders in human rights and whistleblowing groups. We recruited participants through social networks, beginning with the Berkeley Human Rights Center and performing snowball sampling until we hit a saturation point (i.e., when people began referring us to people to whom we had already spoken). We recruited participants who helped equip human rights defenders with digital tools. Our eight participants spanned every continent except Antarctica, including sensitive regions such as the Middle East and Subsaharan Africa. Although we cannot be sure, we have a reasonable degree of confidence that our participants represents almost all "brokers" of technical tools for whistleblowers in the English-speaking world.

For each stakeholder, we provided a "one pager" describing our tool and its use cases. We told stakeholders that this project would be free and open-source. We very quickly divided our stakeholders into two groups: users and brokers. Users would be direct users of the Dead Man's Switch (i.e., releasing content). Brokers are those who come into contact with potential whistleblowers, and direct them to specific technical tools such as ours.

We also quickly learned that talking to end-users would be near impossible for a few reasons. First, very few people need to use a Dead Man's Switch, and those who do need to use one typically only need to do so once in their lives. Further, those who have used a Dead Man's Switch in the past would be very hesitant to talk to us, and brokers understandably did not want to reveal their identities or any information that could lead to discovery of their identities.

As such, we settled on recruiting brokers exclusively. Our goal was to establish user needs through these brokers. In doing so, we discussed our tool with brokers, answered their questions, and learned what tools they currently use to allow for whistleblowing, including current pain-points. We would then use these results to inform the design specifications for our own tool.


Along with the tools we already knew about, we learned about two more tools from our participants:

  • Orbot - Orbot enables use of Tor on Android. It is very frequently recommended by brokers, as many whistleblowers use Android phones and live in jurisdictions in which Internet use is heavily monitored and/or censored.
  • Sipderoak Semaphor - Sempahor is a group messaging and filesharing platform that uses a mixture of end-to-end encryption and "private blockchain technology." The system is open source, but has not been audited as far as I can tell. It is unclear to me what role blockchain plays in the service, and how its functionality is different from Signal. The service is paid, and the free model has a 2GB size limit per file.

We learned a great deal from these sessions—much more than can fit into this brief report. However, three main painpoints around existing solutions emerged during our analysis.

  1. Tools break in low-bandwidth environments. Many whistleblowers are in jurisdictions with unreliable Internet access. Transferring large files, especially over Tor, very frequently breaks existing tools.
  2. Having downloaded apps can be dangerous. Almost everyone to whom we spoke mentioned that having an app (e.g., Signal) can raise suspicion if a person is searched or apprehended. One issue with Signal in particular is that deleting the app also deletes prior messages, which can neither be backed up nor recovered. Whistleblowers should either not need to download an app, or should be able to delete a downloaded app at any time.
  3. Brokers do not want to maintain hosted solutions. SecureDrop requires news or advocacy organizations to maintain software themselves, provide documentation, and keep those systems up-to-date. While the brokers with whom we spoke are highly technically knowledgeable, they do not have time and do not want to be responsible for updating a hosted software, or for staying up-to-date with new vulnerabilities.

We used these painpoints, along with more targeted feedback, to inform the design of our smart contract, which we describe in the next section.

Our smart contract: nikkileaks

Our smart contract is available on GitHub under an Apache 2.0 license.

I developed this smart contract iteratively throughout the project, allowing specifications to emerge from our user studies, and checking these specifications against the Oasis technical team (particularly Nick Hynes).

Given an Oasis gateway gw:

 const service = await Release.deploy(gw, {
    description: 'My big secret',
    message: 'I love kimchi',
    messageReleaseTime: BigInt(moment().add(2, 'minutes').unix()),

This message will remain confidential (i.e., no one can access it) for the next two minutes. After two minutes, it will become public. The description will always be public.

Once you have your service, you can call:

service.message() - This will retrieve your message. If the message has not yet been released, the promise will reject and give you an error message. (This is true even if you wrote the message; see Possible Extensions, below).

service.changeReleaseTime({newTime: unixTime}) - This will change the release time of your message. Typically, you will probably be calling this to extend the release time of your message (i.e., making it release later than it would otherwise. However, you can also change the release date to be sooner. You can even set the release date to be in the past, effectively making the message public. Note, however, that you cannot change the release time of an already-released message. (See FAQ).

Differences from the initial design

This design is somewhat different from the design I proposed initially. In the initial specs, the contract would have exposed the following methods:

  • post(message, trusted_voters, required_votes)
  • release(messageId)
  • read(messageId) -> message

post would have allowed the user to post a message, which would be kept as confidential state until enough trusted_voters (represented by a list of addresses) called release() on that message. When the number of votes was greater than required_votes, the message would have become public.

That design focused on delegation. In our user studies, our brokers repeatedly told us that delegation is difficult for whistleblowers in practice. Getting connected to trusted parties to whom delegation could occur was risky in and of itself. On top of this risk, communicating to delegates that time is right to release information produced practical challenges. Further, the act of delegation itself put those delegated at risk.

After we established that it was possible to get a trusted time from the chain, we scrapped this design. However, the question of how delegation plays into the Dead Man's Switch core functionality is still very much an open one; see Possible Extensions in the GitHub README.

The FAQ also mentions an additional specification that arose during user testing. In the current version of the contract, you cannot alter the release time of an already-released message. This is for caller's own safety. Allowing the caller to update the release time of an already-released message to be in the future may give the caller a false sense of security. Once a message has been released, we assume it is no longer confidential.

Future work

While our smart contract delivers the functionality promised, our work opened up avenues for potential future development and research.

Producing a managed workflow

Currently, the Dead Man's Switch does "one thing well:" it posts information (e.g., a symmetric encryption key), and keeps it secret until some later date. While I initially set out to produce a "managed workflow" that encrypted files, uploaded them to IPFS and posted the material to the Oasis chain, I quickly realized that upstream dependencies rendered the development of this workflow premature.

Before we know what kind of managed workflow will work, we will need to establish boundaries on bandwidth use with file uploading, and on real-life interaction with the chain via particular platforms (Android, etc). As such, I need to wait until a deployed Oasis chain with our contract exists. Then, we can perform manual tests in different jurisdictions (see below) and determine what this managed workflow will look like.

Meeting specifications in realistic contexts

On that note, future work should test bandwidth requirements in a variety of real-life contexts, e.g., in low-connectivity environments in Subsaharan Africa, or in censorship-heavy environments in the Middle East. By testing this contract on a deployed Oasis chain with realistic file-sizes, I can get a better idea for the actual constraints facing our app's usability.

Similarly, when a deployed Oasis chain in available, future work should look to application deployment options. According to our user testing, a webpage with no downloaded apps would be ideal. In practice, browser plugins or even downloadable apps may be required. In any case, the interface should provide specific instructions on how to delete those apps (or clear one's browsing history), and on how to recover data if an app is deleted (i.e., writing down wallet secret keys).

Finally, our app will require more user testing, both with brokers and with members of the general population. Ideally, these users would be drawn from countries where whistleblowing is highly likely to occur. This will assure that the results of our user studies are applicable.

Building a better secure drop

One issue that surfaced in our user studies, somewhat related to the Dead Man's Switch though substantively different in its user base, is that an alternative to SecureDrop is badly needed. SecureDrop is a tool for newsrooms to communicate securely with sources sharing delicate information. It is different from the Dead Man's Switch in that information becomes immediately available to only one party (the news website).

In its current form, SecureDrop is very difficult to set up. Only sophisticated newsrooms have the expertise, and can dedicate the time, to deploy it properly. Even then, it's unclear that any given SecureDrop deployment is well-maintained, kept up to date, etc. A future project should use Oasis to replicate SecureDrop's functionality. Doing so would remove the onus from newsrooms to maintain software themselves, allowing more newsrooms to assure reliable, confidential communications with sources.


Our tool will be successful when the brokers in our sample will recommend this Dead Man's Switch to potential users. This user study and smart contract establishes the technical feasibility of this concept, and its need among human rights defenders. Future work could make this system the go-to solution for whistleblowing worldwide.



A decentralized system is one that does not rely on any one, centralized provider to provide services. The service is instead distributed over peers, who provide services. Together, the network uses cryptography to assure that peers act honestly. In comparison to a centralized system (e.g., SecureDrop or, you must trust them to configure their systems correctly or else your info will be compromised. Decentralized systems are trustless - they do not require you to trust any one provider.

Date: 2020-08-03 Mon 00:00


Created: 2020-08-03 Mon 23:25