Threat Model
What Harbor protects against and known limitations.
Security Goals
Harbor aims to provide:
- Message confidentiality — Only sender and recipient can read messages
- Message authenticity — Recipients can verify message origin
- Forward secrecy — Past messages remain secure if keys are compromised
- Self-custody — No third party holds your keys
Adversary Model
Harbor considers the following adversaries:
Network Observer
An adversary who can observe network traffic between you and the blockchain.
Protection
Message contents are encrypted end-to-end. Network observers cannot read messages.
Blockchain Observer
An adversary who monitors blockchain transactions and events.
Protection
Message contents are encrypted. Recipient identity is protected by commitments.
Limitation
Sender address, timing, and transaction metadata are visible on-chain.
Malicious Contact
An adversary who is one of your contacts and tries to compromise your security.
Protection
Per-contact sessions isolate compromise. A malicious contact cannot read your messages with other contacts.
Compromised Device
An adversary who gains access to one of your devices.
Limitation
Device compromise exposes device keys and decrypted message history on that device. Forward secrecy protects past messages on other devices. Revoke compromised devices immediately.
What Harbor Protects
| Threat | Protection |
|---|---|
| Message interception | End-to-end encryption |
| Message tampering | Authenticated encryption (Poly1305) |
| Key theft (server-side) | Self-custody — no server holds keys |
| Account lockout | Self-custody — your keys are your access |
| Future key compromise | Forward secrecy via Double Ratchet |
| Message replay | On-chain nullifiers |
What Harbor Does NOT Protect
| Threat | Reason |
|---|---|
| Sender identity | Sender address is visible on-chain |
| Message timing | Transaction timestamps are public |
| Device count | Key registry reveals registered devices |
| Communication patterns | On-chain activity is observable |
| Device compromise | Local keys can be extracted |
| Browser compromise | XSS or malicious extensions can access keys |
Trust Assumptions
Harbor's security relies on the following assumptions:
- Cryptographic assumptions — X25519, Ed25519, XChaCha20-Poly1305, and SHA-256 are secure
- Random number generation — Browser's crypto.getRandomValues() provides cryptographically secure randomness
- Client integrity — The Harbor client code you run is not modified
- Device security — Your device is not compromised by malware
- Blockchain liveness — Base L2 continues to operate and process transactions
Known Vulnerabilities
Browser Trust Model
As a web application, Harbor inherits browser security limitations:
- XSS attacks could potentially access keys in memory
- Malicious browser extensions could intercept keys
- Users must trust the served JavaScript
Mitigations:
- Strict Content Security Policy
- No inline scripts
- Keys stored in IndexedDB (not accessible to page scripts directly)
Metadata Leakage
On-chain storage means certain metadata is public:
- Sender wallet address
- Transaction timing
- Number of registered devices
See Privacy Limitations for details.
Recommendations
- Create a backup — Export your identity and store it securely
- Use a secure device — Keep your device free of malware
- Monitor devices — Revoke devices you no longer control
- Verify identities — Confirm contact identities through out-of-band channels
Learn More
- Privacy Limitations — Detailed privacy analysis
- Security — Security overview
- Encryption — Cryptographic details