Back to Home
Privacy Notice

Privacy Policy

This Privacy Policy explains how Crisis Connect handles information when you use the mobile app, the public website, and related rescue coordination features. It distinguishes between two main contexts: standard user use of local nearby communication features, and optional online or authorized rescue-coordination workflows. That distinction matters because core messaging is designed to work without a named cloud account, while certain support, profile, map, diagnostics, and rescue features rely on Firebase and related services.

Last updated: March 7, 2026

Contents

Offline-first, not cloud-only

Core chats stay on devices, while sign-in, diagnostics, rescue sync, and map downloads may use online services.

1. Information We Process

The information we process depends on which features you use. Some data stays only on your device, some data is exchanged directly with nearby devices, and some data is sent to cloud services when online features are enabled.

1.1. Anonymous Service Identity, Optional Sign-In, and Rescue Accounts

For most users, core nearby messaging does not require a named cloud profile. When online support is available, the app may create an anonymous Firebase identity in the background to initialize limited online capabilities. We do not treat every installation as a fully registered user account. Google or email-password sign-in is optional for most users and is mainly relevant when you choose profile-linked features or when an organization or authorized rescue workflow requires authentication. In those cases, we may process your Firebase user ID, sign-in method, email address, display name or username, country, role, verification status, and related agency metadata.

1.2. Local App Data

Messages, contact entries, locally stored encryption material, profile photos, attachments, offline map regions, settings, and similar app content are primarily stored on your device. In ordinary use, message history is not mirrored to a centralized message server.

1.3. Device, Connectivity, and Nearby Device Data

To operate Bluetooth and nearby communication features, the app may process device capabilities, Bluetooth and Wi-Fi Aware state, nearby device discoveries, signal strength, temporary session identifiers, device model, operating system version, app version, language, and country settings.

1.4. Media, Location, and Sensor Data

If you use optional features, the app may process voice recordings, photos, QR scans, shared location messages, live location for rescue coordination, and sensor-derived data used by tools such as compass, signal finder, or map-related features. Location is processed only when a feature requires it or when you choose to share it.

1.5. Diagnostics, Analytics, and Website Logs

We use Firebase and Google services for crash reporting, performance monitoring, analytics, app integrity checks, authentication, and website hosting. These services may process technical telemetry such as app instance identifiers, device and app metadata, error logs, performance traces, IP address, browser details, and related diagnostic events.

1.6. Rescue Coordination Data

If authorized rescue features such as Crisis Link are enabled, the app may sync responder identity and authorization metadata, device identifiers, agency details, active signal observations, optional GPS snapshots, and related operational metrics to Firestore or connected backend services so authorized teams can coordinate field activity.

2. Device Permissions

Crisis Connect requests permissions that match the features you choose to use:

  • Bluetooth, Nearby Devices, and nearby Wi-Fi permissions are used for local discovery, pairing, messaging, and nearby device communication.
  • Location permission is used for Android Bluetooth discovery requirements, optional map and location features, and authorized rescue coordination workflows.
  • Camera access is used for QR scanning and taking photos to share in conversations.
  • Microphone access is used for voice notes and voice-call features.
  • Notification permission is used for incoming messages, SOS activity, ongoing communication services, and download or rescue-status updates.
  • Internet and network-state access are used for sign-in, role verification, diagnostics, website delivery, map downloads, and rescue synchronization when those features are available.

3. How We Use Information

We use information only to operate, secure, support, and improve Crisis Connect and related services. The exact use depends on whether you are using standard local features or restricted online or rescue features. Additional uses include:

  • Establishing nearby device connections and routing messages or SOS data.
  • Storing local history, settings, attachments, and offline resources on your device.
  • Authenticating users and determining eligibility for restricted rescue features.
  • Syncing responder and signal data for authorized rescue coordination workflows.
  • Monitoring crashes, abuse, fraud, app integrity, and service performance.
  • Delivering website pages, downloads, and support channels.

We do not sell message content or personal information, and we do not use chat content for advertising.

4. Offline-First Design and Cloud-Connected Features

Core one-to-one and nearby communication features are designed to work directly between devices and to keep message history primarily on-device. Ordinary users can complete local onboarding and use core nearby communication without creating a named online account. Crisis Connect is not a purely serverless product, however. Anonymous background identity, optional profile sign-in, role verification, diagnostics, website hosting, offline map downloads, and authorized rescue coordination may use internet-connected services when available.

5. Storage and Retention

Retention depends on where the data lives and which features you use.

5.1. Local Retention

Messages, attachments, contacts, local keys, settings, profile images, and offline maps generally remain on your device until you delete them, clear app storage, replace them, or uninstall the app.

5.2. Cloud and Service-Provider Retention

Account records, rescue-authorization metadata, responder coordination data, crash reports, analytics events, performance traces, and website or server logs may be retained by us or our service providers for as long as needed to operate the service, investigate incidents, comply with law, or satisfy provider retention windows.

6. When We Share Information

We share information only in limited situations relevant to the service:

6.1. Direct Device-to-Device Sharing

Nearby communication features share the minimum data needed to discover peers, establish sessions, exchange messages, transfer attachments, or broadcast SOS and rescue-related payloads.

6.2. Service Providers

We use third-party infrastructure and SDKs such as Firebase Authentication, Firestore, Functions, App Check, Analytics, Crashlytics, Performance Monitoring, Google sign-in services, Firebase Hosting, and MapTiler or MapLibre-related map delivery. Those providers process data under their own terms and privacy commitments.

6.3. Authorized Rescue Coordination

If rescue coordination features are enabled by an authorized responder or organization, responder identity data, agency context, signal observations, and optional location data may be shared with authorized rescue panels or backend services to support coordination.

6.4. Legal and Safety Disclosures

We may disclose information when required by law, to respond to lawful requests, to protect users or the public, or to investigate fraud, abuse, or security incidents.

7. Security Measures

We use layered technical and organizational safeguards appropriate to an emergency communication product:

  • Local encryption and protected storage for sensitive app data on supported devices.
  • Cryptographic protections for supported message, identity, and rescue communication paths.
  • Role-based authorization controls for restricted rescue workflows.
  • Firebase App Check, authentication controls, and service-side access rules for supported online features.
  • Operational monitoring through crash, performance, and security diagnostics.

No transmission or storage system is absolutely secure. Bluetooth, Wi-Fi, local device security, and internet-connected services each carry inherent risk.

8. Your Choices and Rights

You can manage much of your data directly in the product: review and delete local message history, revoke permissions, remove offline maps, sign out, clear local storage, or uninstall the app. Deleting the app removes local data stored on that device, but may not remove cloud records created for account, diagnostics, or rescue coordination purposes. If you need access, correction, or deletion help for cloud-held data, contact us.

9. Children's Privacy

Crisis Connect is not directed to children under 13 and is not intended to be used by minors without appropriate permission where required by law. We do not knowingly design the service to solicit children's personal information for commercial purposes.

10. Changes to This Privacy Policy

We may update this Privacy Policy to reflect product changes, legal requirements, or operational needs. Material changes may be communicated through the app, the website, release notes, or other appropriate notices. The version date above shows when this policy was last revised.

11. Contact Information

For privacy questions, data requests, or legal concerns about this policy, contact:

Auralis Privacy Team

Privacy Team

privacy@crisisconnect.network

12. Emergency-Use Summary

At a high level, Crisis Connect handles data differently depending on the workflow.

  • Standard users can use core nearby messaging after local onboarding, without creating a named cloud profile.
  • Online support features may still use anonymous app identity, map delivery, website hosting, and crash or performance diagnostics.
  • Authorized rescue workflows may require authentication, role verification, and backend synchronization for operational coordination.

13. SOS and Rescue Feature Handling

Emergency workflows deserve separate notice because they may involve broader operational data handling than standard chat.

13.1. Local Emergency Broadcasts

The SOS feature can broadcast distress information to nearby devices so other users or responders can detect an emergency event even when normal infrastructure is unavailable.

13.2. Location and Status Data

If you attach location or status information to an SOS event, that information is processed to support response and may be displayed to nearby devices or authorized rescue systems involved in that workflow.

13.3. Responder Authentication

Restricted rescue tools may rely on signed role credentials, token claims, or related authorization checks before giving access to protected coordination functions.

13.4. Operational Retention

Local SOS content remains on participating devices unless a connected rescue workflow uploads related observations. Authorized rescue sync records may remain in backend systems for incident coordination, audit, or legal purposes.

13.5. Misuse Prevention

We may use technical controls such as authorization checks, rate limits, integrity checks, and incident logging to reduce false alerts, abuse, or unauthorized rescue access.

Crisis Connect