Privacy Limitations
An honest assessment of privacy tradeoffs.
Harbor provides strong privacy for message contents, but using a public blockchain for message delivery creates inherent metadata exposure. This page documents these limitations honestly so you can make informed decisions.
What is Private
| Data | Visibility |
|---|---|
| Message contents | Private (encrypted) |
| Private keys | Private (never transmitted) |
| Recipient identity | Private (commitment scheme) |
| Message history | Private (stored locally, encrypted) |
What is NOT Private
| Data | Visibility | Reason |
|---|---|---|
| Sender address | Public | Required for blockchain transactions |
| Transaction timing | Public | Block timestamps are public |
| Device count | Public | KeyRegistry stores device public keys |
| Public keys | Public | Required for encryption |
| Message size (buckets) | Public | Encrypted payload visible on-chain |
Detailed Analysis
Sender Address Visibility
Every blockchain transaction requires a sender address. When you send a message, your wallet address is visible in the transaction. This means:
- Anyone can see that your address sent a message
- Your messaging activity is linked to your wallet
- If your wallet is linked to your real identity, your messaging activity is too
Mitigation: Use a wallet address not linked to your real identity for Harbor. However, be aware that blockchain analysis may still correlate addresses.
Transaction Timing
Block timestamps reveal when messages are sent:
- Observers can see when you're active
- Patterns in timing may reveal habits or timezone
- Correlation attacks can link sender to recipient by timing
Mitigation: Harbor does not currently implement timing obfuscation. Be aware that your activity timing is visible.
Device Count Leakage
The KeyRegistry contract stores public keys for each device:
// Anyone can query function getKeyCount(address user) public view returns (uint256)
This reveals:
- How many devices you have registered
- When devices are added or revoked
- Device key changes over time
Communication Graph
While recipient identity is protected by commitments, determined adversaries may attempt correlation attacks:
- Timing correlation between sender transactions and recipient activity
- Payment patterns if sender and recipient transact
- Social graph analysis from on-chain activity
Harbor's commitment scheme makes casual observation difficult, but it doesn't provide strong anonymity against determined analysis.
Message Size
Messages are padded to bucket sizes (256B, 1KB, 4KB, 16KB), but:
- The bucket size is visible from the encrypted payload
- Very long messages may stand out
- Patterns in message sizes over time may be revealing
Comparison to Other Systems
| System | Sender Privacy | Recipient Privacy | Timing Privacy |
|---|---|---|---|
| Signal | Medium (phone number) | Medium (phone number) | Low (server sees timing) |
| Harbor | Low (wallet address) | Medium (commitments) | None (on-chain) |
| Low (email address) | None (visible) | None (headers) |
Who Should Use Harbor
Harbor is appropriate when:
- You want self-custody of encryption keys
- You want censorship-resistant message delivery
- You're comfortable with on-chain metadata exposure
- You can maintain operational security around your wallet address
Harbor may NOT be appropriate when:
- You need strong sender anonymity
- You need to hide that you're communicating at all
- You face adversaries who can perform blockchain analysis
- Your threat model requires timing obfuscation
Future Improvements
We're exploring improvements to privacy:
- Stealth addresses for recipient privacy
- Batched transactions to obscure timing
- Zero-knowledge proofs for metadata privacy
These features are not yet implemented. The current privacy limitations will remain until they are.
Learn More
- Threat Model — Security analysis
- Security — Security overview
- Privacy Policy — Legal privacy policy