Security Model

In a nutshell: Versia is designed to guarantee the integrity and origin of messages between instances, but not end-to-end confidentiality. This means that you can trust which instance sent a message, but you should not assume that its contents are private, or that the instance was honest about them. TLS protects messages in transit, but every instance that handles a message can read it.

Security Concerns

All data that your instance federates, including but not limited to DMs and private posts, is assumed to be accessible by the following parties:

• Your instance administrator.
• The administrators of any instance that receives it.
• Any party that has access to the data in transit (and can break through TLS).

Data that your instance does not federate, such as your password, is only exposed to your instance.

Security Guarantees

Versia’s security model provides the following guarantees:

• Integrity: A message cannot be changed in transit without its signature failing to verify. If the signature is valid, the message is the one its signer sent.
• Authenticity: A valid signature proves which instance sent a message. As an entity’s author must belong to the signing instance, an instance cannot speak for another instance’s users.

What Signatures Do Not Prove

• Which user wrote something: Signatures identify an instance, not a user. An instance can create or change entities in the name of any of its own users, and other instances cannot tell.
• Where an entity came from later on: A signature covers one HTTP message, and is not part of the entities in it. Once an entity has been stored, nothing in it proves its origin, so it cannot be passed on to a third party as evidence.
• That an instance’s key is genuine, without TLS: Public keys are fetched from the instance over TLS, so a party that can break TLS can also replace a key.

Why No End-to-End Confidentiality?

End-to-end confidentiality is not part of this specification. Most federated platforms, such as ActivityPub and email, do not provide it either.

It requires a different set of tools and assumptions, which are hard to implement reliably in a federated system. The added cryptography would also make the specification harder to implement for smaller developers.

Platforms such as Signal already do this well, so Versia leaves confidentiality to them.

Remote Content

Validation has the rules for rendering remote HTML and for fetching what remote data names.

Reporting a Vulnerability

Report a flaw in this specification privately on GitHub. Report a flaw in an implementation to its maintainers. For anything that does not need to stay private, open an issue.