Safety you can verify, not just trust

On both iOS and Android the app is built with background location explicitly disabled and only the “when in use” permission string declared. The only background mode the app registers is receiving push notifications — never location. In code, the app requests foreground-only permission and never starts a background location task.

In practice that means: when the app is backgrounded or closed, it does not — and technically cannot — read your position.

Emergency location capture is wired to fire only once an escalation has actually reached the stage where your emergency contact has already been alerted (Stage 3), and again at the watchdog stage (Stage 4) — at most two captures per incident. It is never called on a schedule, never at the earlier stages, and never when you've checked in on time. Live trip sharing is the only continuous case, and it runs only while you have a trip switched on.

Coordinates are rounded to 4 decimal places (roughly 11 metres at the equator) before storage — we never keep raw GPS. The rounded value and its address summary are encrypted at the column level using pgcrypto's pgp_sym_encrypt with a passphrase held in a separate Supabase Vault, so the key never lives in the app or in our logs.

Each record carries a purge deadline set to 72 hours after the moment of capture; once that window passes, the ciphertext is overwritten and only non-sensitive metadata (incident id, stage, timestamp) can remain. Because the backend service role must be able to decrypt in order to dispatch help, we do not — and will not — describe this as end-to-end or zero-knowledge encryption.

A shared trip link carries a 128-bit, URL-safe token. While the trip is live, the link returns your position rounded to about 100 metres plus your first name — never your exact location, phone, email, destination, or battery level. Stopping the trip clears the token immediately, which instantly and permanently kills the link.

If you forget to stop it, the share expires on its own — after 72 hours, or 24 hours on a taster trip — and stops returning any position at all.

Row-level security policies live in the database itself, below our application code — so a bug in the app can't make the database hand you another person's row. The stored procedures that carry emergency data, personal information, SOS, or billing entitlements are executable only by our backend's service role; execute rights are revoked from anonymous and ordinary authenticated callers.

The handful of functions the app is allowed to call directly re-verify that the requesting account matches the account being asked about, and reject the request outright on a mismatch.

When your contact taps the link in an alert, the token is HMAC-signed so it can't be tampered with, carries an expiry of 48 hours or less, and is matched by a one-way SHA-256 hash rather than by its raw value. It is single-use: once followed, it's consumed and can't be replayed.

The self-test runs against a synthetic, immediately-deleted test incident, so it exercises the real delivery path to your own device without ever paging your real emergency contacts. The status screen marks each feature “Verified” only if it was actually proven within the last 90 days — otherwise it asks you to re-prove it, so a stale green is never shown.

Email alerts go out through a primary provider (Amazon SES). A circuit breaker watches the failure rate; if the primary starts failing, sending is automatically rerouted to a second provider (Resend). Anything that still can't be delivered is written to a dead-letter queue and pages our on-call — with the recipient's personal details scrubbed from the page — so a failed alert is retried and seen by a human, never silently dropped.

Deleting your account runs a two-phase erasure. First, a soft-delete neutralizes the record immediately — it stops all outbound contact and releases your email address, phone number, and push token. Then, within 30 days of deletion, the record and everything linked to it are permanently purged (cascade), leaving only a minimal audit entry keyed by an internal id with no personal identifiers.

We describe this honestly as designed to honor — not to automatically certify — your erasure rights under GDPR, CCPA, and the DPDP Act. You can start deletion yourself from Settings, in the app.

Product analytics is keyed to a pseudonymous account identifier rather than your name, email, or phone number, and personally identifying information is redacted from our error and crash logs before it's recorded. For the full list of processors we use and exactly what each one receives, see our Privacy Policy.

Our specifications cover data classification, encryption, row-level security and grants, edge functions, magic-link tokens, and logging & PII handling. The July 2026 internal review flagged a set of issues; the high-severity ones — a way to forge our safety-call webhooks, an over-permissive database function, and a webhook host check — have fixes written and tested and are being rolled out to production, and we're working through the medium-severity findings now.

This is our own program, measured against our own written specifications — not an audit by an outside firm and not a formal certification. We would rather tell you that plainly than imply a badge we don't hold.