Trust Center
We back our security claims with verifiable resources, not badges. This page gathers our policies, live system status, technical architecture, and the service providers we work with in one place — and states plainly what we do not yet have.
Verification resources
To check a claim, don't read marketing copy — go to the sources below.
Vulnerability Disclosure
Scope, safe-harbor principles, and the private reporting process.
Live System Status
Current service health and 90 days of uptime history.
Technical Architecture
Encryption details, threat model, and known limits of both the offline Bluetooth path and the internet layer.
Privacy Policy
What data lives where, when it is shared, and how it is deleted.
security.txt
RFC 9116-compliant, machine-readable security contact record.
Open Source Code
The mobile client is on GitHub under AGPL-3.0; claims can be audited from the code itself.
Contact the Security Team
Direct channel for security findings: security@crisisconnect.network
Our security practices
- Messaging is end-to-end encrypted on both supported paths: internet messages travel as encrypted envelopes the server cannot read, and Bluetooth messages go directly device to device.
- In ordinary civilian nearby messaging, message history is not mirrored to a central server; data primarily stays on your device.
- The mobile client's source code is public under the AGPL-3.0 license; encryption claims can be reviewed independently.
- An RFC 9116 security.txt record and a published vulnerability disclosure policy give researchers a defined reporting path.
- System health is published on a live status page fed by public endpoints.
- There are no ads, no tracking-based revenue model, and no selling of data.
Encryption and protocols
The protocols in use, not a label. The full threat model, known limits, and design decisions are documented on the technical architecture page.
Internet messaging (messages, voice notes, attachments)
Signal protocol (libsignal): Double Ratchet with post-quantum PQXDH key agreement, providing forward secrecy. For compatibility with older clients, an authenticated ECIES envelope (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) is used; that path does not provide forward secrecy, and downgrade attempts are rejected once a Signal session is established.
Voice and video calls (one-to-one)
WebRTC DTLS-SRTP. For one-to-one calls, signaling never crosses the server in plaintext — it travels inside end-to-end encrypted message envelopes — and the TURN relay cannot decrypt media. Calls on authorized agency channels use a separate path whose signaling passes through membership-gated panel infrastructure.
Nearby (Bluetooth) messaging
AES-256-GCM (96-bit IV, 128-bit auth tag) for QR-paired contacts. Authorized responder flows use ephemeral ECDH P-256 + HKDF-SHA-256 session keys and ECDSA P-256 role certificates validated offline.
Identity and verification
The legacy P-256 identity key is held in hardware-backed AndroidKeyStore on supported devices. The Signal identity key runs in software for ratchet operations and is stored encrypted at rest under a Keystore key — a deliberate design trade-off for forward secrecy. Contacts can be verified by comparing 60-digit safety numbers.
What is not end-to-end encrypted
The SOS report to authorized response panels — deliberately readable so teams can act on it — and delivery/signaling metadata (identifiers, timestamps, IPs). We do not hide this; the details live in the technical architecture and the privacy policy.
Review the full threat model in the technical architecture →
Service providers and hosting
We work with the following third-party service providers (subprocessors) to deliver the service. End-to-end encrypted content cannot be read by these providers; this page is updated when the list changes.
| Provider | Purpose | Location |
|---|---|---|
| Google Firebase (Google LLC) | Authentication, database, storage, cloud functions, notifications, website hosting, analytics, and crash reporting | USA (us-central1) |
| Cloudflare, Inc. | TURN media relay for internet calls | Global anycast network (US-based) |
| MapTiler AG | Map tile delivery | Switzerland (global CDN) |
| CARTO | Base map tiles for the web dashboard maps | Global CDN |
| Google Play · Apple App Store | App distribution and updates | Global |
What we don't have yet
We won't claim what we don't have. As of today:
- We have not yet published an independent security audit or penetration-test report; it is the top trust investment on our roadmap.
- We hold no ISO 27001 or SOC 2 certification.
- We do not run a paid bug bounty program; the responsible disclosure process is defined on the security page.
This page makes no new claims; it only gathers existing, verifiable resources in one place.