Threat model
What OSL defends against, and what it doesn't.
What OSL defends against #
OSL protects the content of supported direct messages against the following adversaries. Group chats, server channels, and other unsupported connectors are not covered.
- A connected social or email service reading supported protected message content. For those direct messages it receives ciphertext only; service metadata remains visible.
- Service employees with access to stored message data. They see the same ciphertext.
- Attackers who breach the connected service's infrastructure.
- Network eavesdroppers, including an ISP, public Wi-Fi snooper, or government tapping the wire. They see encrypted network traffic carrying ciphertext.
- Anyone using legal process to obtain stored data from the connected service. For supported protected direct messages, the content in that data is ciphertext.
What OSL does NOT defend against #
OSL is not a complete privacy solution. It does not protect against:
- Metadata. A connected service can see recipients, timing, message frequency, message sizes, and account or group membership. OSL hides supported content, not the existence of the activity.
- A compromised computer. Source and focused-test evidence covers device-sealed private identity keys and sealed message-store values, not every local record: SQLite structure remains visible, while conditional JSON, Hub configuration, renderer localStorage, provider-managed profiles, the active-slot marker, and a fixed-label startup trace can be plaintext. At-rest protection also does not protect text while it is being read or typed, and it does not stop malware, keyloggers, screen recorders, swap, crash dumps, backups, or compromise of the operating-system credential boundary.
- The other side leaking. The person you're talking to can screenshot, copy-paste, or otherwise share your messages. Encryption defends against third parties, not against your recipient.
- Voice and video calls. OSL does not encrypt them. The connected service's normal infrastructure handles those.
- Service moderation. A moderator or administrator who receives a report or has legitimate access can still act on it.
Specific concerns #
Can a connected service restrict my account?
Possibly. Rules differ by provider, and some prohibit modified clients or automated interaction. Experimental interaction modes are off by default. Do not connect an account you cannot afford to lose without reviewing that service's current rules.
Can a government obtain my messages from a service?
A provider may be compelled to hand over what it has. For supported direct-message content protected by OSL, the provider has ciphertext made of random-looking bytes. Decrypting it requires keys the provider does not have.
Can the government compel ME to hand over my password?
Depending on jurisdiction, possibly. Some legal systems can compel you to disclose passwords; others can't (or it's unsettled law). OSL doesn't protect against legal coercion or physical compulsion. If you're in a high-risk situation, consult a lawyer and consider whether OSL alone is enough.
Is OSL right for you? #
OSL is appropriate for:
- Everyday privacy. You do not want a social service, email provider, employer, or ISP reading supported protected content.
- Communities discussing sensitive topics (health, identity, politics, finances) without changing platforms.
- Anyone who wants end-to-end encryption added to conversations they're already having.
OSL is not appropriate for: