For journalists: how to receive anonymous tips without leaving a server trail

If you're a reporter, you've probably had a moment where someone reached out who clearly should not have been using the channel they were using. A government employee on their work email. A corporate insider on Slack. A whistleblower on Twitter DMs. They were trying to do the right thing — they just didn't have a sensible option, so they used the channel that was open.

This post is about giving them a sensible option, and what to think about when you set one up.

The threat model, plainly

For a source-to-journalist tip, the source generally needs to fear:

1. Server records linking them to you. Email servers, message archives, DM histories — all of these create a permanent record that "this person contacted that journalist." That record is subject to subpoena, employer discovery, and breach.
2. Identity exposure through the channel itself. If reaching you requires a phone number, a verified account, or anything tied to their real identity, the act of contact is identifying.
3. Persistence on either device. Even if the channel is private, messages sitting on the source's phone or your laptop can be subpoenaed, seized, or stolen.
4. Metadata even without content. "Source X talked to Journalist Y on date Z for N minutes" is itself often the dangerous information, even if no one knows what was said.
5. The source's own machine. You can't help them with this, but it's worth being aware: a managed work laptop with monitoring software will leak everything regardless of which app they use.

A reasonable tip line should minimize at least the first four. Most don't.

What common channels actually leak

Work email

Disastrous. The source's employer can read their outgoing email. Your news organization's email provider has it. Both records sit indefinitely. This happens constantly, and it's why DOJ leak investigations so often start with email subpoenas.

Personal email

Better but still bad. The provider has the message. The journalist's organization usually has it. The source's email account is identity-linked. Use of work-vs-personal email is also itself a signal.

Twitter / X DMs

Server-stored, not E2E encrypted. The platform can read everything. Account-linked. Twitter's data has been requested by US and foreign governments before, sometimes successfully.

LinkedIn messages

Same as Twitter, except corporate-identity-linked, which is even worse for sources reaching out about their own employer.

Signal

Genuinely good — but requires the source to download Signal, register a phone number, and add you to contacts. The phone-number step is the friction killer. A government employee using their personal phone to install Signal and message a reporter is creating a record on their phone bill that an investigation can find.

SecureDrop

The gold standard for actual whistleblower work. Tor-based, no metadata, no account. The catch: it requires the source to install Tor Browser and follow careful operational steps. Most casual tipsters won't do that. SecureDrop is the right tool for serious, prepared sources, not for someone who has 30 seconds at lunch to reach out.

Briar, Session, etc.

Various decentralized options. All require app installation, which means the source has the same identifiable "I downloaded a privacy app on my phone today" record.

The gap: low-friction, no-account, ephemeral

What's missing in most newsroom tip-line setups is a channel that:

• Requires zero installation by the source
• Requires zero account creation by the source
• Leaves no server record on either side
• Works in 30 seconds from a browser tab

This is the gap browser-based, peer-to-peer tools fill. A reporter publishes a link. The source opens it. Both browsers connect directly. They talk. Both close the tab. Nothing remains on a server, because there isn't one.

Btwinus is one such tool. It's not a replacement for SecureDrop for serious whistleblower documents — but it's a much better first-contact channel than email or DMs, and it requires nothing of the source besides clicking a link. (Here's the technical breakdown of how it works without an account or a server.)

A practical setup for reporters

Step 1: Have a real first-contact channel

Publish a way to reach you that doesn't compromise sources at the moment of first contact. A Btwinus-style ephemeral link is good for this. Signal is also fine for sources who already use it. Listing both, and explaining briefly what each is for, lets the source pick.

Step 2: Use first contact to triage, not to handle the whole tip

The first conversation is for figuring out what's happening, what the source's situation is, and where to take it from there. It's not where you receive the actual documents. Once you've established that the tip is real and the source needs to send sensitive material, you upgrade to SecureDrop, in-person dead drops, or another higher-assurance channel.

Step 3: Don't ask for identifying information you don't need

The source's name is rarely the most important thing in the first contact. What they know matters more. Hold off on identity questions until they're necessary, and never push.

Step 4: Be clear about what each channel actually protects

If you use Btwinus for first contact, tell the source what it does and doesn't do. It hides the conversation from any server. It does not hide the fact that they opened a webpage from someone monitoring their machine, their network, or their browser history. They should know that.

Step 5: Train your colleagues

The weakest link in most newsrooms isn't the tip-line technology. It's the editor who replies "send me what you've got" via the same email the source nervously used to reach out, defeating the purpose entirely. Whoever handles tips needs to know how to respond without escalating the source's exposure.

What Btwinus is good at, in this context

For a journalist's tip line, the relevant Btwinus properties are:

• Source needs no account, no app. They click a link and they're talking to you. The friction is lower than email.
• Conversation never touches a server. Subpoenaing Btwinus would yield nothing, because nothing is stored.
• Two-channel model adds an extra lock. The link can be shared publicly (it's encrypted); the passphrase travels separately. If a source's network is monitored and they only see the link, they still can't be tied to the content of the conversation.
• The chat ends when either tab closes. No history on either side after disconnect. Source doesn't have to remember to delete anything.

What Btwinus isn't good at, in this context

• Not async. Source and journalist must both be at the chat at the same time. For long tips this requires scheduling.
• Limited file transfer. Small payloads work; multi-gigabyte document drops do not. Use SecureDrop or in-person handoff for those.
• Doesn't protect against compromised endpoints. If the source's laptop is monitored, no chat tool helps.

The practical recommendation

Add an "Anonymous tip" link on your bio page. Have it open a Btwinus session (or generate a fresh link periodically). Pair it with a Signal username for sources who prefer that. Mention SecureDrop separately for serious whistleblowers. The result is a tiered system where the right tool is available for the right level of risk, and no source has to default to corporate email because they couldn't find a better option.

The goal isn't perfect security — it's much better than the default, with no friction. Most tip lines fail not because they're insecure, but because no one uses them. A browser link nobody has to install fixes the second problem without sacrificing the first.