Privacy & Security Assessment
This is the engineering counterpart to our Privacy Policy. It records what the product can and cannot claim today — scoped to the current Android and iOS state, not the full roadmap.
Effective date: 17 July 2026
System and trust boundaries
Close2Me is offline-first. A device owns its identity and local history, discovers peers over Bluetooth, establishes authenticated Noise XX sessions, and exchanges typed packets. Direct streams carry calls and file transfers only between connected peers. Flood/relay routing may forward packets through other Close2Me devices. Firebase exists at the Android/iOS application edge for product telemetry and configuration; shared communication modules do not depend on it.
The current trust boundaries are the local device and app-private storage; Bluetooth and nearby observers; the recipient device; any intermediate Close2Me mesh relay; and Firebase/Google for bounded telemetry and diagnostics. There is no shipping Nostr transport, geohash channel, courier pool, Tor path, or Close2Me account server in this assessed phase.
Phase-accurate claims
The table below is the source of truth for what we may claim publicly. Marketing copy on this site is written not to exceed it.
| Claim or control | Status | What is true now | Residual limit / next phase |
|---|---|---|---|
| Direct nearby content is encrypted in transit | Landed | Noise XX establishes an authenticated ChaCha20-Poly1305 channel per connected link. Immutable headers are authenticated as associated data. | Packet headers, traffic timing, signal strength, and proximity remain observable. |
| A direct peer’s identity is authenticated | Landed | Ed25519 identity proof is bound into the Noise handshake and fingerprints can be compared / QR-verified. The private identity key lives in Android Keystore-wrapped storage or the iOS Keychain. | Trust still depends on verifying the intended fingerprint. A compromised unlocked process can ask the platform store to use app-accessible key material. |
| Multi-hop mesh content is end-to-end encrypted | Not landed | Each hop is encrypted on the radio link. | A relay opens and re-seals packets, so the relay device sees forwarded plaintext. Destination-bound async encryption is future work. |
| Received attachment files are sealed at rest | Landed, partial | A versioned XChaCha20-Poly1305 envelope with a fresh nonce is applied before backing-store writes. Startup migrates pre-sealing files with size validation; authenticated files are never later accepted as plaintext. | Missing or inconsistent legacy files stay explicitly unmigrated. External viewers necessarily receive plaintext, and a copy already opened by another app cannot be revoked. |
| All databases are encrypted at rest | Not landed | SQLDelight uses platform SQLite drivers. | SQLCipher (or a reviewed equivalent), migrations, backup/restore tests, and key-loss behavior are needed before this claim. |
| The local identity key is platform protected | Landed | Android encrypts the identity secret under a non-exportable Keystore AES-GCM key; iOS stores it in a this-device-only Keychain item. Missing/undecryptable state fails closed. | This does not encrypt conversation/transfer databases, require user presence, or withstand arbitrary code execution in an unlocked process. |
| A panic wipe removes sensitive state | Not landed | OS app-data clearing / uninstall is available, subject to backups. | A transactional wipe of keys, databases, attachments, outbox, and local metrics is backlog work. |
| Internet fallback and private relay DMs exist | Not landed | Architecture and sequencing are documented only. | Nostr, NIP-17/59, relay policy, and the Double Ratchet decision remain scoped. Public relays would see IP/timing metadata. |
| Offline courier mail exists | Candidate only | No device carries sealed mail for an absent third party. | Spray-and-wait limits, rotating tags, expiry, and abuse resistance need a separate decision. |
| Exact location is collected for channels | Not landed | The nearby flow uses Bluetooth; older Android may gate scanning behind location permission. | Geohash channels are future opt-in work and must default coarse with ephemeral area keys. |
| Telemetry excludes communication content and identifiers | Landed w/ dependency | Typed analytics prohibit messages, peer IDs, keys, names, Bluetooth addresses, exact location, and attachment names/URIs. | Firebase automatic collection, console settings, crash review, retention, and consent remain operational controls. |
| Advertising profiles nearby behavior | Not present | No advertising SDK is installed and ads are disabled. | Future ads would require consent/privacy controls and must not use peer or communication data. |
Adversaries and failure cases
Nearby passive or active observer
Can detect Bluetooth activity, timing, approximate proximity, signal strength, packet sizes, and possibly stable radio characteristics; may advertise compatible services, inject malformed packets, jam, or exhaust resources. Link encryption protects content after a secure session forms — it does not hide Bluetooth use, prevent denial of service, or make an unverified new identity trustworthy.
Intermediate mesh relay
The relay boundary is hop-by-hop. A relay can read forwarded payload plaintext, observe headers, delay or drop packets, and correlate traffic. “End-to-end encrypted” claims are limited to direct established links until destination-bound sealing lands.
Lost, seized, or compromised local device
App-private storage and OS sandboxing help against ordinary cross-app access. Attachment blobs are sealed and the identity secret is platform-protected, but conversation, transfer, and profile databases remain plaintext today, so database extraction can expose history and metadata. An unlocked device, root/debugger access, or arbitrary code execution can still ask the app to decrypt data or use its identity.
Compromised recipient
The recipient necessarily receives plaintext and can retain, copy, screenshot, record, or disclose messages, calls, SOS details, and files. Cryptography cannot revoke delivered knowledge.
Telemetry processor or console operator
Firebase receives the product events and automatic diagnostics enabled in each build. The typed schema reduces accidental collection but does not control every SDK-generated field or console export. Release owners must review DebugView, crash samples, retention, access roles, exports, and consent.
Future internet relay operator
Not currently in the data path. If Nostr ships, relays could log IP addresses, connection timing, subscriptions, event sizes, and availability windows. NIP-17/59 can hide DM sender/content at the event layer but cannot promise network anonymity; timing correlation remains possible.
Data minimization rules
- Keep sensitive content inside encrypted payloads; headers contain only routing necessities.
- Never put messages, peer identifiers, keys, fingerprints, names, Bluetooth addresses, exact locations, or attachment paths into telemetry.
- Default discovery and future internet/location features to off or coarse explicit choices.
- Treat transport acceptance as sent-to-transport, never proof a person received or read it.
- Do not add voice or file transfer to public relays without a new assessment.
- New stores must document encryption, retention, deletion, backup, and migration.
Release blockers and review triggers
Before a public claim of comprehensive at-rest protection, we must:
- land and test SQLCipher (or equivalent) for every sensitive SQLDelight database;
- validate Android Keystore / iOS Keychain migration, backup, and key-loss behavior on release devices;
- review any legacy attachment migration failures on upgrade and explicitly expire or remove files that cannot be validated;
- maintain a monitored privacy contact; and
- validate Firebase payloads and console retention/consent settings on release builds.
This assessment is re-run when adding internet relays, geohash channels, couriers, push notifications, cloud backup, panic wipe, ads, new analytics fields, or any new permission.
For a plain-language summary of these practices, see our Privacy Policy. Privacy questions can be sent to privacy@close2me.app.