Guidelines for Law Enforcement.

• A private messaging app. People sign up with a username and a password, with no phone number, no email and no real name. They write one on one and in private groups of up to 1,000 members, send voice messages, and share photos and documents. There are no voice or video calls and no public channels.
• Sealed end to end. Messages, voice messages, photos and files are encrypted on people’s devices, and only the devices in the conversation can open them. Our servers pass them along without a key. Each one goes to a mailbox our servers can’t link to an account, and the sender’s name travels only inside the sealed envelope.
• Made by Murmur Labs LLC. Murmur Labs LLC makes the Murmur apps and runs the servers they use. Requests go to Murmur Labs LLC, at [email protected].

Our public position is that we hold no message content and no keys. We hold the metadata listed in our public table, and it can be compelled.

We can’t hand over what we don’t have. We don’t have:

• The content of messages, voice messages, photos and files, their names and types, reactions, poll votes or todo lists. We hold them only encrypted, with no key to open them. We keep messages for 30 days at most (a scheduled message waits for its time first, a year at most), files for 30 days unless pinned, and the text backups people choose to keep, which only their own Recovery Key opens.
• Keys we can use, passwords or Recovery Keys. Passwords never leave people’s devices. Private keys reach our servers only sealed, either in an account’s Recovery Key data, which only that person’s Recovery Key opens, or for a few minutes, in the box that carries them to a new device the person links.
• Profiles, contacts, blocks and most settings (the few our servers apply are listed below), or group names, pictures and descriptions. We store them only encrypted, and we can’t open them.
• Who sent a message. The sender’s name travels only inside the sealed envelope.
• Who talks to whom, including who has a one-on-one chat with whom.
• Who is in which group, their roles, or who added or removed whom. The one exception is a group admin who asked us for community passes (see “Links and passes” below).
• IP addresses, or any log that ties an address to an account.
• A phone number, an email address, a real name, a date of birth, a location, device models, an address book or a payment identity. We never ask for them. The only email addresses we hold are those of people who write to us, kept with their message.

We can look up an account only by its exact username (number included), its account ID, or a contact link that points to it. We can’t search by phone number, real name or IP address, or by email address, except for people who wrote to us by email.

Here is what our servers hold that can be tied to an account. None of it is a name, a phone number, an email address or an IP address, and none of it says who the account talks to, apart from what people choose to send us themselves, like the messages in a report, or an email with its address.

The list follows our public table, which is checked against our code at every release, and our Privacy Policy.

We also store data we can’t open. For it, we see only sizes and times, and what each line below says:

• Waiting messages, in mailboxes our servers can’t link to an account, are kept encrypted until each device has fetched them, 30 days at most (in large groups, until their 30 days are up, even after delivery), with a copy in our encrypted backups for up to 14 days. We also see the version of the chat’s keys, whether to wake a device, and whether it’s a direct chat or a group.
• Scheduled messages are sealed envelopes that wait until a set time for the devices that will receive them, with a rounded size, never who scheduled them. Kept until that time, a year at most, then delivered like any message. A record that one went out or was cancelled stays 30 days more.
• Once-a-day “last seen” signs are sealed, carrying only the day. Held a random 1 to 12 hours, then delivered like any message.
• Files, voice messages included, are kept encrypted for 30 days unless pinned. No sender or chat is tied to a file, except that a pinned file is tied to its group, never to its members, to count the group’s quota.
• History sent to a new device or to a group’s new members is kept encrypted, 24 hours at most.
• Group changes, for a group mailbox our servers can’t link to its members. We keep each change, sealed for the members, with its order number (30 days), the group’s count of changes for the day (1 day), and whether the group has more than 256 devices.
• Encrypted records of profiles, account states and groups.
• Text backups people choose to keep, which only their own Recovery Key opens.

Some records point to no account. They are markers that a chat’s mailbox is muted, the sign-up token service’s used tokens (until its monthly key change) and per-device counts (30 days), and totals (the ones we count, and the ones a group’s admins or our panel members choose to share).

Our server logs hold a closed list of fields, never account, device or group IDs, IP addresses or tokens, and they’re kept 7 days. While we handle an outage, traces of a small sample of requests use the same closed list and are kept 72 hours. Nothing in them points to an account.

• Valid legal process. Apart from the child-safety reports the law requires, we disclose data only under valid legal process that binds Murmur Labs LLC, such as a warrant or another order from a judge or a court. We don’t answer informal requests, except in an emergency (see below).
• From any country. We treat every authority the same way, whatever country it’s in. When its own order doesn’t bind us, it goes through the channels the law gives it, such as mutual legal assistance between governments, which leads to an order that does.
• Orders sent to us directly. Where a law lets an authority send its order straight to a company like ours, it can send it to our legal representative there, where we have one, or to [email protected]. We check each one the same way, give only data that exists, tell the person unless the order forbids it, and count it in our transparency report.
• Civil cases. The same rule applies, so we need a valid court order that binds us.
• Specific requests only. A request must name the exact username, account ID or contact link, the data needed and the period. We disclose only what the order covers, and only data that exists. We challenge orders that are too broad, and non-disclosure orders we believe aren’t justified.

Write to [email protected], in English or in French. Please include:

• the name of your authority or agency;
• your name, your badge or ID number, and your official email address and phone number;
• the legal basis, with a copy of the signed order;
• the exact username, account ID or contact link concerned (or several);
• the data you are asking for, and the period it covers;
• any deadline, and why.

• Only when a life is at stake, meaning a danger of death or serious physical harm that is imminent.
• Write to [email protected] with “Emergency” in the subject. Tell us what the danger is, who is at risk, why it can’t wait for an order, and what data you need.
• Where the law allows it, we may then disclose, without an order, the minimum we hold that’s needed to prevent the harm.

• When we receive a valid preservation demand or order, we preserve what exists about the account at that moment, for the period it sets, while you obtain an order.
• We can’t preserve what we never had, and much of what we hold doesn’t last long, with waiting messages kept 30 days at most, server backups 14 days, notification tokens 30 days after a device’s last activity, and server logs 7 days, with no account in them.
• For child sexual abuse, we preserve the report and related data for 1 year on our own, as the law requires.

• We tell the person before we disclose their data, so they can challenge the request. We tell them in the app, because we have no email address or phone number for them.
• We don’t tell them when a law or a court order forbids it, or in cases of child sexual exploitation. After an emergency, we tell them once the danger has passed, if the law allows it.
• We challenge non-disclosure orders we believe aren’t justified.

We don’t wait to be asked. We report child sexual abuse to the bodies the law requires, such as the CyberTipline of the National Center for Missing & Exploited Children (NCMEC), with the data we actually hold. Our Child Safety Standards explain how.

Twice a year, we publish a transparency report at murmur.free/transparency, with the requests we received and the data we handed over, by country and type, the child safety reports we made, and the accounts we acted on.

• We can’t decrypt messages, photos or files, hand over keys, or give anyone access to content, ever.
• We can’t see inside a group or tell who is in it.
• We can’t identify the person behind an account from an IP address.
• We can’t remove a message from the devices of the people who received it.
• Apple and Google hold their purchase records and the link between a notification token and their own customer’s account. Ask them directly.

Murmur is built without backdoors. There is no spare copy of anyone’s keys on our side, no hook to scan content, and no backup, search or “admin recovery” our servers can read. The first two are on our list of things we will never build.

We can’t change the app’s code remotely. Desktop builds from our site and the direct-download Android app are recorded in a public log, so a version made for one person would show. App store builds can’t be checked this way, and we say so in the app too.

We will contest any order that would create a systemic vulnerability, and we would shut down the affected feature rather than ship a backdoor.

Legal and law enforcement requests, emergencies included

[email protected]

Child safety

[email protected]

People asking about their own data

[email protected]