Metadata Privacy

To protect the privacy of your communications, metadata privacy is complementary to end-to-end encryption (E2EE). Even if others can’t read my messages, can they tell who I’m talking to and when? Metadata privacy is a challenging, layered problem that informs the design of our transport architecture. In this post we describe the metadata protections that are in place today, and how our architecture lays the groundwork for structural improvements in metadata privacy.

Assurances

Our app makes the following assurances for metadata privacy:

• The only metadata for end-to-end encrypted ciphertexts you transmit in our transport layer (within TLS) is the message’s destination address.
  • Header encryption provides confidentiality of Messaging Layer Security (MLS) private message metadata, including the group identifier and epoch counter.
  • The identities you use within the app are not transmitted in plaintext metadata, nor are linkable by Germ to message destinations
  • Senders do not identify themselves to send a message
  • Destination addresses generally route to a specific device, especially if users wish to receive push notifications, so messages in transit necessarily have some traceability to a destination.
• Message destination identifiers are rotated frequently per conversation
• The link between a message destination identifier and a conversation is known only to the members of the conversation.

Internet Protocol (IP) address privacy

While our transport layer transmits no sender identity, the IP layer transmits an IP address that is visible to Germ. Germ’s server software does not process or store IP addresses. Users themselves can modify the IP address that is visible to Germ with technologies such as a VPN. We plan to further limit Germ’s exposure to users’ IP addresses by:

• allowing users to route messages independently of Germ’s servers
• limiting Germ servers’ visibility of user IP addresses with the use of standard protocols such as OHTTP and MASQUE

Transport Architecture

Conceptually, Germ operates a mailbox service on behalf of each user of our app. We receive messages at these mailboxes and deliver them to you, identifying the mailbox that each message arrived at. The app regularly uses many mailboxes among your conversations, to reduce the observable inferences one can make about any one mailbox.

We previously detailed our transport architecture in this blog post. In the context of metadata privacy:

Ephemeral Addresses

Our main transport is via an ephemeral address--the “mailboxes” mentioned above. Your app requests batches of them, and distributes them within an E2EE channel to your correspondents. In this way, the link between an address that the server must process, and your conversation, is only known to the members of that conversation. Your app sends fresh addresses with each message — ideally you choose unused addresses when sending a message.

Rendezvous

These addresses do expire, and operationally we’ve found it useful to have fallback channels that do not expire. We do so with the concept of rendezvous, in which one party registers with our backend to listen for messages at a specified address. The other party can then visit the rendezvous and leave a message. This forms a 1-way channel using a stable identifier.

We derive rendezvous identifiers in each direction from the MLS epoch — so that only members of the MLS group can derive these values, and they change with each epoch (in practice, a round trip).

In this way, two parties who have not conversed in some time, and whose addresses have expired, can still reconnect using shared secrets from their MLS group. These secrets will expire as soon as they exchange messages and advance their MLS state.

Architectural Goals

Our transport architecture is designed with these principles in mind:

Simple

Our transport architecture processes the minimum information it needs to deliver messages. Since our transport layer does not handle identity or group state (as a centralized MLS Delivery Service might), our servers do not need to know that information.

Diverse

We aim to have a diversity of transport providers, so that users have reliability and redundancy for staying connected. A simple transport allows for more diverse implementations - for example through peer to peer network topologies. Diversity also ensures that no one provider can observe all message traffic. Our goal is that your messages do not need to be transmitted through Germ’s servers.

Autonomous

In our architecture, users can make independent choices about which transport providers they use. Germ’s app and protocol are designed so that in the future, you can choose how you want to receive messages, and express that automatically to people you connect to and are in conversation with. This lets users make independent tradeoffs, for example between latency and metadata privacy.

The Road Ahead

Metadata privacy is not a binary assurance like confidentiality or authenticity. We’re wary of overpromising total metadata privacy - because there are many layers of defense against active and passive attacks in transit. We’ve already carefully constructed our transport protocol to limit the information our servers process. There’s a lot more potential for further metadata privacy in our architecture, particularly in users’ agency over the routing of their messages. We look forward to drawing on research in this space to ship innovative solutions. If you have ideas you’d like, please reach out to us!