Building Tools for Internet Shutdowns

I made Skirk and twoman to help people in Iran get online during internet shutdowns. They use different routes: Skirk carries encrypted traffic through a Google Drive mailbox; twoman uses shared hosting as a relay.

Neither can promise a connection everywhere. A service that works today can disappear tomorrow. That uncertainty shapes the whole tool, from the protocol to the error message.

Check what still works

A domain resolving doesn't mean a connection will complete. A host might serve a page but reject a long request. A cloud API might work until its quota runs out.

Before choosing a transport, check the actual path: which requests succeed, how long they take, what size they can carry, and whether replies make it back. Repeat that check under poor conditions. Testing only from a fast, unrestricted connection tells you very little about the people you're building for.

Getting connected is only the beginning

Moving a few bytes proves the transport works. A usable tool also needs installation, profile import, updates, diagnosis, and recovery.

An error like “connection failed” leaves someone guessing. “The relay answered, but the exit didn't” gives them somewhere to start. A status check should follow traffic across the whole path; a running process alone isn't enough.

Setup needs the same care. If an installer fails halfway through, say what changed and how to retry or remove it. Don't make a user piece that together from a page of logs.

Expect interrupted sessions

Phones sleep. Requests time out. Replies arrive twice or after a restart. Queues fill while the route is unavailable.

Give each session and stream an identity so an old reply can't land in a new connection. Put limits on retries and queued data. Expire abandoned work, including anything left in an intermediary's storage. Otherwise, a short outage can become a growing backlog that outlives the connection itself.

Measure useful tasks as well as throughput: how long it takes to connect, load a small page, and recover after the route drops. More parallel requests can help until they hit a quota or make every response slower.

Be precise about protection

Encryption doesn't make a user anonymous. Intermediaries can still observe metadata, and a compromised device remains a problem. Credentials, account limits, and provider access are dependencies too.

Those limits belong near the setup instructions. Logs should avoid secrets, profiles should be revocable, and diagnostic exports should make clear what they contain. People using these tools need enough information to judge whether a route fits their situation.

The repositories contain the current setup instructions and limitations. They matter more than any claim that a tool will “just work.”