Welcome to the Invisible.im project website

A: Anonymous communications between journalists and sources have become extremely difficult. Armed with nothing more than a polite request on the correct letterhead, law enforcement bodies (and indeed other government bodies) are legally entitled to obtain metadata records from ISPs, telcos and online service providers.

In the case of government leaks, the Australian Federal Police is routinely called in to investigate.

Some say the use of encryption technologies to protect the content of communications between journalist and sources is a solution to this problem. It's not.

As demonstrated several times over, the content of communications barely matters when determining the identity of a leaker. Simply proving that a communication occurred between a source and a journalist prior to the publication of a story/package is often enough to see the source identified, fired or arrested. In some countries the identification of a journalist's source can even result in their torture and murder.

In other words, the general context of the communication can almost always be inferred from the "metadata", which is information about a communication, not the content of the communication.

For example, a source communicates by phone with a journalist, then sends them an encrypted mail. Two days later the journalist publishes leaked documents the source had access to. It's game over for the source, despite the use of solid encryption.

The threat of exposure in the age of readily accessible metadata is undoubtedly having an impact on the willingness of sources to engage with the media. Given the media's important role in any functioning democracy, this desperately needs to be addressed.

Tools like SecureDrop and StrongBox are an excellent first step. But they are complex and require secure supporting infrastructure. It might help a large publication, but what about independent media and journalists? Will freelance journalists set up solutions like those? How can a source be sure that something sent in via SecureDrop will go to the right journalist, or just the journalist they want to see it?

What's needed is something far simpler. An instant message and file transfer client that leaves as small a metadata trail as possible. That's what Invisible.im is.

A: The Tor project has launched an instant messenger project that uses the anonymity network to make instant messenger chats a lot safer. It's an excellent start, but doesn't solve the key problem we're setting out to solve -- incriminating metadata trails.

It's also worth noting that invisible isn't trying to be all things to all people - rather than needing a plausible federation model for internet scale deployment, the fairly niche usecase of invisible means we can ship a prototype early, and worry about scaling as it becomes an issue (Which realistically will not become problematic as quickly).

The Tor IM bundle will still rely on third-party messaging servers to relay messages. This means there will be a record of conversations having occurred on a third-party server. While it would theoretically be possible to use this technology to establish a secure and anonymous session, but both parties to any chat using this tech would have to be using ephemeral identities to stay completely safe. We don't think that's practical, so we've taken a different approach.

Under the Tor project's model:

• Every user will still need a registered IM account with an IM provider like AOL, Yahoo, MSN, GChat, Jabber etc.
• User activity (metadata) still logged by IM service operators.
• Intelligence agencies can use an IM username as a selector, not justan IP address.
• If a user is tied to their IM pseudonym there's still a metadata trail a mile long.

TorChat is another solution. It's an open source package that enables relatively private conversations between two parties. It leaves behind no metadata. Early versions were written in Python, but TorChat2 is written in Pascal.

i2pMessenger is similar to TorChat but uses the i2p anonymisation network instead of Tor. Invisible.im will seek to enable conversations over i2p as well, but it's pretty far down on the list of immediate priorities.

Onionshare was written by Micah Lee, a tech staffer for Glenn Greenwald's media startup The Intercept. A simple file transfer package, it allows a user to share files anonymously through an ephemeral Tor hidden service. Invisible.im will support anonymous file transfers and we've even swapped a few emails with Micah, who might be interested in helping out with this part of it.

A: Instead of re-inventing the wheel, it was decided early on to glue various bits of existing IM software together. There are many, many open source XMPP clients and servers available to choose from today, why not use them?

The secret sauce in Invisible.im is actually pretty simple.

With traditional, existing IM services, users install an XMPP client and connect to an XMPP server run by someone else. They log in with a username and password and away they go.

But because we're using Tor, we can do things a bit differently. Once a user registers a Tor hidden service, we can think of their system as being routable on a real world, static address. If your routing address is static, it can be used as an identifier.

So, if you have a static routing identifier, why not run the XMPP service yourself? We realised that running an XMPP server locally would address many of the problems we've identified. You load up your XMPP client, it connects to a local XMPP server which can only communicate via Tor to other hidden services. Instead of user@domain.com, you have user@onionaddress.onion.

We will prevent the local XMPP service from connecting to anything that isn't a Tor hidden service, and Bob's your mother's brother, the federation feature of XMPP takes care of the rest.

The nice thing is XMPP federation will launch an outbound connection from the system that is initiating the chat session to the destination party's XMPP service listening on a hidden service. It's a client-server connection. This is why our "anonymous mode" (See How will people use Invisible.im?) can work even when the anonymous party doesn't have a hidden service running.

We've protoyped this and much to our shock it actually works. OTR, OpenPGP, buddy lists and status all work. For some inexplicable reason the first few messages in a chat session just disappear into the ether. Where they go, nobody knows. If you've seen our missing messages, please do let us know.

Now that we have a working protoype we're looking at exactly what we'll need to do to turn it into a fully functioning, useable package.

A: There are several use cases for Invisible.im, but it's primarily been designed as a tool to help journalists to converse with and receive information from sources who wish to stay completely anonymous. In fact, this project was partially inspired by a conversation Patrick Gray had with Australian federal senator Scott Ludlam (Greens). Scott asked Patrick if there was an easy, secure way for him to anonymously converse with and receive information from whistleblowers in Australian government departments. While there are some technologies that facilitate this already, like SecureDrop, they're a bit fiddly.

What Scott was after is a simple tool anyone could download and use. That's what Invisible.im is designed to be.

A journalist (or minor party senator) using this technology will generate a cryptographically verifiable identity that is used, in turn, to verify their Tor hidden service, as well as their OTR and PGP keys. If someone wishes to contact them, they simply download the software, choose to connect in "anonymous mode", which generates single-use, ephemeral OTR keys, and then enter the hidden service address of the person they wish to communicate with.

Invisible.im is also seriously considering establishing a "help bot" service to help members of the public find contact addresses for verified journalists and public interest groups. The help bot will be a pre-installed, verified hidden service address that contains a directory of verified contacts. It will be in everyone's "buddy list" by default.

Under this architecture it's possible for a member of the public, without establishing their own hidden service, to communicate with a journalist with a hidden service address/verifiable identity. This means the anonymous party can verify the journalist, but the journalist can't verify the anonymous party.

Where it gets interesting is when two parties operating in "journalist mode" start communicating. Under our model, both parties are cryptographically verified, their messages are unreadable and encrypted, and no one can tell that they are on each other's "buddy lists", or that they have ever had a conversation, let alone when.

As we now know, thanks to Edward Snowden's leaks, intelligence agencies like Britain's GCHQ and America's NSA love to scoop up users' buddy lists so they can figure out who knows who.

But they will not be able to infer relationships between users of Invisible.im by passively observing Internet traffic.

Invisible.im is a nightmare for any agency running a mass surveillance program, so for that reason we suspect many people will be interested in running Invisible.IM in "journalist mode" as a replacement to their regular IM client.

A: In short, probably, yes.

When Tor hidden services came along they were pretty much designed to run websites anonymously. The Silk Road website is a great example of this. It's a service that's always up and reachable, and needs to stay hidden unless its operators want to wind up in prison.

Tor hidden services were not designed to be handed out as readily as IM account IDs. Initial conversations with people who know a lot more about Tor than us suggest that hidden services don't really scale that well. If Invisible.im releases a stable, useable package that becomes popular, it's conceivable that we'll slow down hidden service enrolment to a crawl. That would be bad for everyone.

But! The nice part is if we have a lot of users, we have a lot of endpoints to play with. We want to get in touch with Tor to find out if there are resources we can deploy across the Invisible.im userbase that will ease the hidden service bottleneck.

We are aware that running an exit node or a relay node on the same system as a hidden service is considered a bad idea because it may make it possible for attackers to determine the location of a hidden service address, but we're still keen to explore how we might be able to use any install base we wind up with to contribute to the Tor resource pool.

We're genuinely interested in having Tor people (contributors, users, people who just know a lot about it) tell us why our ideas are awful and how we could achieve the same aims differently.

A: Invisible.im forces OTR encryption for all chats. All traffic between a client and a Tor hidden service is already encrypted, but an additional layer of encryption is particularly vital in our case.

It's entirely possible and very easy to spoof a hidden service address when launching an out-bound connection from a locally-hosted XMPP service. The XMPP service accepting the inbound connection will do nothing to verify the source of that connection, thus spoofing is a real risk.

OTR gets us around this. This is why we'll be forcing OTR for all chat sessions.

It must also be noted that the presence of identifying OTR key material on the source's system may be a liability. If those keys are recovered from that system and the journalist's computer is also seized, it will be possible to prove those two people had communicated. This is why we generate one-time, ephemeral OTR keys in anonymous mode.

Invisible.im will scrub those keys from the user's system when the chat session ends or the software is exited.

A. The problem Invisible.im seeks to solve is the retrospective identification of the source of a media leak.

Invisible.im makes it possible for any member of the public to communicate with a journalist (or indeed, anyone) without leaving a retrospectively recoverable forensic trail behind on third-party servers.

In the case of a traditional instant messenger conversation, the service provider (Yahoo, Microsoft, Google, AOL etc) will have records of which user accounts have communicated with each other and when.

Invisible.im leaves behind no such trail. It also doesn't log messages on either end, and when used in anonymous/unauthenticated mode the software will leave behind very little (and eventually, we hope, no) forensic evidence linking a user to a conversation.

Keep in mind the presence of this software on a source's computer, along with leaked documents that have found their way to the press, may be enough to implicate them. But because Invisible.im makes the identifying a leaker much more difficult in the first place, sources are less likely to be identified as suspects and come under scrutiny to begin with.

A: If a source is already the subject of targeted surveillance, Invisible.im cannot facilitate secure, anonymous chats. This is not the problem it is seeking to solve. A law enforcement approach may be as simple as taking a time-stamped video recording of both ends of the conversation to prove that a chat is occurring.

There is no technological solution to this challenge. Invisible.im is designed to stop sources being identified via a metadata trail retrospectively. It cannot protect a source that has already been identified.

Further, Invisible.im cannot leave absolutely no trail. It will be possible for law enforcement to retrospectively determine whether the Tor network has been accessed from a nominated connection. It is a single data point, but a meaningful one. Our hope is that as Tor usage grows, connections to the anonymity network won't "stick out" or become incriminating on their own.

• Private key jacking: The theft of a user's private key will result in the attacker being able to impersonate that user.
• SPAM/phishing/malware: The spam challenge will be significant if the uptake of this service is successful. It is, after all, designed to allow anonymous parties to contact users.
• Security vulnerabilities in components used by Invisible.im: A vulnerability that allowed an attacker to take control of a user's Invisible.im software would be catastrophic. Regular code audits and a rolling bug bounty program are vital to the success of the project.

A: We hope Invisible.im (or something like it) will become the de facto standard for instant message conversations on the Internet. There is no reason people need to expose their conversations to mass surveillance, interception by their service providers, law enforcement or intelligence agencies. Not in 2014.

We want to make absolute privacy from mass surveillance the default.