Security & FAQ

Threat Model

Haamly is designed to reduce spam and protect message confidentiality. This is an honest overview of our security model and limitations.

Participants:
-----------
[Sender Device]    [Haamly Server]    [Haamly Datastore]    [Recipient Device]
     |                   |                     |                      |
     |                   |                     |                      |
     |-- metadata ------>|                     |                      |
     |   (encrypted)     |                     |                      |
     |                   |-- approval? ------->|                      |
     |-- message ------->|                     |                      |
     |   (encrypted)     |                     |                      |
     |                   |                     |<-- download ---------|  
     |                   |                     |    (encrypted)       |
     |                   |                     |                      |

Message Flow:
-------------
1. Sender encrypts metadata + message separately
2. Haamly Server reads encrypted metadata 
3. Haamly Server enforces approval rules
4. Approved messages and metadata stored in Haamly Datastore
5. Recipient Device downloads metadata and message and decrypts locally

Trust & Access Boundaries:
--------------------------
Sender Device:
- Generates keys locally
- Encrypts metadata and message separately before send
- Only recipient can decrypt message

Haamly Server:
- Reads encrypted metadata
- Enforces sender approval rules
- Routes approved encrypted payloads to datastore
- Cannot read message content

Haamly Datastore:
- Stores encrypted metadata and messages
- Cannot decrypt any data
- Only serves encrypted payloads to authorized recipients

Recipient Device:
- Holds decryption keys
- Downloads encrypted data from datastore
- Decrypts metadata and messages locally
- Manages contact approvals

Threat Actors Considered:
-------------------------
- Network attacker (MITM)
- Malicious server operator
- Compromised datastore
- Compromised email provider
- Passive metadata observer

Threat Actors NOT Trusted:
--------------------------
- Haamly infrastructure
- Haamly datastore
- Cloud providers
- Email identity providers (Gmail, Outlook)

Threat Actors Trusted:
----------------------
- User's own devices

This is closer to a messaging threat model than traditional email.

What Haamly Does NOT Protect Against

No system is magic. Here are the things Haamly explicitly does not claim to solve.

❌ Compromised Devices

If an attacker controls your device (malware, keylogger, malicious browser extension), they can read your messages.

Haamly assumes:

Your device OS is trusted
Your local key storage is secure

This is a limitation of all end-to-end encrypted systems, including Signal.

❌ Social Engineering

If you approve a sender you shouldn't have, Haamly cannot save you.

Consent is enforced technically—but judgment is still human.

❌ Identity Spoofing Outside the Haamly Network

Haamly protects messages inside its encrypted system.

It does not prevent:

Someone impersonating you on legacy email
Phishing attempts outside Haamly

❌ Traffic Analysis by a Global Adversary

Haamly does not claim resistance to:

Nation-state–level global traffic correlation
Timing analysis across the entire internet

This would require Tor-like infrastructure and comes with major usability tradeoffs.

❌ Denial-of-Service Attacks

While unapproved senders cannot reach your inbox, Haamly does not prevent:

Flooding of sender requests
Infrastructure-level DoS attacks

These are handled operationally, not cryptographically.

❌ Legal Compulsion of Users

Haamly cannot protect users from:

Being compelled to unlock their own devices
Providing access under local laws

Haamly can only truthfully say:

We cannot decrypt your data ourselves.

What Haamly Does Protect Against

✓ Spam and unwanted messages by default
✓ Server-side message inspection
✓ Provider-based email scanning
✓ Retrospective decryption after key compromise (forward secrecy via X3DH)

How Haamly Works

1. Your inbox is closed by default

Unlike traditional email where anyone can message you, Haamly requires explicit approval.

2. New senders request permission

When someone tries to email you for the first time, their message waits in a pending queue.

3. Once approved, messages are encrypted

Messages use X3DH (Extended Triple Diffie-Hellman) key exchange from the Signal Protocol for end-to-end encryption.

4. Unapproved senders never reach your inbox

Spam is prevented by design, not filtering after the fact.

Design Goals

→ Prevent spam by design, not filtering
→ Zero-knowledge message storage
→ Multi-device support
→ Fully open source (GPLv3)
→ Use existing email identity without giving providers access to encrypted messages

Why This Section Matters

Haamly is designed in public. We believe in being honest about:

What our system can and cannot do
The real-world threat model we address
The tradeoffs we've made for usability

We're not overselling cryptography. We're building for adults who understand that security is about reducing risk, not eliminating it.

Signal Protocol Usage

Haamly implements the Signal Protocol (including X3DH and Double Ratchet) as an open cryptographic standard. "Signal Protocol" is a trademark of Signal Messenger, LLC. Haamly is an independent, open-source project and is not affiliated with, endorsed by, or operated by Signal Messenger or the Signal Foundation.

Haamly Security & FAQ