72-Hour Auto-Delete, Not 'Retention Policy'

Q: How do I verify the 72-hour delete actually ran on my data?

You can request a data export at any time (privacy@imalive.co). The export enumerates every row that currently has content for you — if you had an incident 73 hours ago, its location fields will be NULL in the export. If you had an incident 71 hours ago, it will still be there.

Q: Does 'resolved' mean when I check in, or when my contact presses a button?

Either, whichever comes first. If you check in on the app, the incident resolves immediately. If your contact uses the link from their email or SMS to confirm you're safe, the incident also resolves. The 72-hour clock starts from that moment, not from when the incident started.

Q: What if the daily purge job itself fails?

The job is idempotent — running it twice in the same day is fine. If one run fails, the next one covers the same rows (the WHERE clause uses `purged_at IS NULL` as the filter). We monitor job success in our observability dashboard; a missed run in PROD is alertable.

Q: Does this retention policy apply to my account data or just location?

This policy is specifically about emergency location snapshots. Your account record, check-in schedule, contacts, and notifications follow their own retention (described in our privacy policy at imalive.co/privacy-policy). Account deletion removes all of it including the purged shells.

Every emergency location snapshot has an expiration baked in. A daily scheduled job wipes the encrypted columns 72 hours after the incident resolves — the row shell survives for analytics, the content does not.

Download Free Learn More

Average lifetime of a location snapshot in our database: 72 hours. Maximum lifetime: 72 hours from incident resolution. There is no 'archive after 90 days' tier, no 'export on request' clause, no tape backups that outlive the retention.

The Challenge

Most apps' privacy pages claim 'we may retain data as needed for legitimate business purposes' — open-ended language that usually means forever

Unbounded retention is the single biggest factor in breach severity: the leaked database of a service you stopped using five years ago is still a live threat

Short-TTL claims are cheap to make and hard to verify; most users have no way to prove retention policies are actually enforced

How I'm Alive Helps

Enforced TTL at the database layer, not the application layer: purge_expired_location_snapshots() runs daily and rewrites ciphertext columns to NULL in a single transaction

Verifiable via SQL: the decrypted view shows NULL for expired rows, and the raw table shows NULL in the ciphertext columns — not 'looks encrypted still'

Short enough that even a data request during the 72-hour window contains only one active incident's worth of coordinates

Documented in our public product spec (19-location.md §5.8) — we describe it here the same way we describe it to ourselves

The exact mechanism, stage by stage

When the mobile app calls the capture endpoint, the server sets `purge_after = now() + interval '72 hours'` on the row as part of the insert. That column is indexed so our daily cron job can find expired rows efficiently without scanning the whole table. Every morning at 03:00 UTC, a postgres-scheduled function called `alive.purge_expired_location_snapshots()` runs. It is a SECURITY DEFINER function — meaning it runs with elevated privileges — and it performs a single UPDATE: for every row where `purge_after < now() AND purged_at IS NULL`, it overwrites the three encrypted columns (`approx_lat`, `approx_lng`, `address_summary`) to NULL and stamps a `purged_at` timestamp. The row itself stays: this preserves the aggregate counts we use to audit the system. The function returns the number of rows purged, which gets logged. We review the number as part of our weekly safety reviews — if it's much higher than expected, that tells us incidents are spiking; if it's zero when we know incidents happened, it tells us the purge broke.

Why overwrite-to-NULL instead of DELETE

DELETE would throw the row away entirely. The consequence: we cannot answer basic questions like "how many Family Plus users had a location captured in the last 90 days" because the raw event is gone. Overwriting to NULL is a middle ground. The sensitive content — the ciphertext of the coordinates, the address — becomes literally NULL bytes. No decryption key can turn NULL back into a location. But the structural fact that a row existed, tied to a specific user and incident at a specific time, remains queryable by our service role. This is useful for: Reliability auditing. We can confirm each Family Plus escalation produced the expected one-or-two snapshots. If an incident has zero, the capture pipeline failed and we need to know. Country-level analytics, which help us size the operational pipeline for new regions. We do not, at any point, run queries that join this table against user identity for advertising, resale, or any commercial purpose. The trade-off of keeping the row shell is small — it holds an incident UUID, user UUID, timestamp, source ('ios'/'android') — and it cannot be turned into a location ever again.

Backups, restore, and the 30-day shadow window

Any serious database has point-in-time recovery that can restore the database to a state before a purge. Ours is no different; our managed Supabase DB has 30 days of PITR. If a row was still live at the moment of a backup snapshot, restoring that snapshot brings the ciphertext back. However: the Vault key used to encrypt it might not come with. We rotate the `location_passphrase_v1` Vault key on a 90-day cadence (documented), and we retain the previous version only for the backup-recovery window (30 days). After that, a restored ciphertext is unreadable garbage — no key in the system can decrypt it. This is the backup-specific trade-off we took to limit the realistic blast radius of a 30-day-old backup to readable data no older than the key that still exists. The net result: your 72-hour live TTL is backed by a 30-day maximum theoretical window in the worst case of a backup restore inside the key rotation window, and zero beyond 30 days. No data will be recoverable from the 2026 Q2 backups by 2027 — the keys to read them will be gone.

Get safety tips delivered to your inbox

Frequently Asked Questions

How do I verify the 72-hour delete actually ran on my data?

You can request a data export at any time (privacy@imalive.co). The export enumerates every row that currently has content for you — if you had an incident 73 hours ago, its location fields will be NULL in the export. If you had an incident 71 hours ago, it will still be there.

Does 'resolved' mean when I check in, or when my contact presses a button?

Either, whichever comes first. If you check in on the app, the incident resolves immediately. If your contact uses the link from their email or SMS to confirm you're safe, the incident also resolves. The 72-hour clock starts from that moment, not from when the incident started.

What if the daily purge job itself fails?

The job is idempotent — running it twice in the same day is fine. If one run fails, the next one covers the same rows (the WHERE clause uses `purged_at IS NULL` as the filter). We monitor job success in our observability dashboard; a missed run in PROD is alertable.

Does this retention policy apply to my account data or just location?

This policy is specifically about emergency location snapshots. Your account record, check-in schedule, contacts, and notifications follow their own retention (described in our privacy policy at imalive.co/privacy-policy). Account deletion removes all of it including the purged shells.