The server stores
The minimum needed to run a Plan
- Plan events under random identifiers, including deadlines and status changes
- An optional encrypted note
- Integrity records for checking Plan history
Privacy & safety
What BackBy knows about your trip.
BackBy is designed to keep routes, companions, and notes encrypted while giving a trusted Backer the details needed to respond. The server sees Plan timing and events, not a readable trip plan.
The server does not store
Your identity, your route, or your people
- No readable legal name, phone number, or address book
- No list of your Backers
- No readable route, trailhead, vehicle, or pin. Those travel inside the encrypted note.
- No cookies, analytics, or login sessions. The hosting design calls for no retained IP records.
Your trip plan
You choose when your Backer can read it.
The note holds the route, return options, companions, and agreed contact steps. An optional fixed pin can mark a trailhead or take-out; it does not track the traveler.
Emergency Only is the default
BackBy is designed to keep the note locked until the Plan needs attention, you ask for help, or a completion carries the private safety signal. A normal completion keeps it locked.
Right Away is optional
Right Away is designed to let Backers read the note as soon as the Plan starts. It also shares any legal name, phone number, or map pin you add. Choose it only if you want those details shared immediately. You cannot take back a copy someone has read.
Important limits
Where privacy has limits.
Check-in times can reveal a routine
The server sees Plan deadlines and may infer routines from their timing. Repeat labels are encrypted for paired Backers. Minimizing connection records throughout the hosting stack is part of the privacy design.
Optional maps share data with a map provider
Maps are off by default. Loading a map can share your IP address and the area you view with the map provider. Read the privacy notice before turning maps on.
Someone with access to your phone may see details
Lock-screen notifications show details by default, with a generic-text option in Settings. Device passcodes and encrypted storage help protect local records; they cannot stop malware already on a phone.
BackBy is not a rescue service
The server does not call search and rescue, a ranger, the sheriff, or your family. BackBy is not a personal locator beacon or a satellite messenger. Your Backer decides how to respond using the plan you prepared. Carry a beacon or messenger where you need one.
Checking in needs a connection
Create the Plan while connected and wait for confirmation before going offline. I’m safe and Add time also need confirmation. Backers need a connection to fetch updates, and notifications may be delayed or missed.
Legal process
What a records request could reveal.
The design limits stored records to Plan events, encrypted notes, and integrity records. Readable notes and Backer lists stay off the server. The privacy policy and data inventory describe the intended records and their handling.
How long records stay
Encrypted notes expire under rules that keep them available through the Plan’s attention window. Plan events under random identifiers are kept permanently. The data inventory explains the retention rules.
For reviewers
Explore the design.
How note encryption works
The design encrypts notes on the phone with AES-GCM and uses state-controlled key capsules to govern access. Pairing gives Backers the secrets needed to read authorized notes. The protocol explains the full design.
How state reads are protected
The design requires a secret credential for each Plan read. Missing, wrong, or expired credentials receive the same response as missing data.
How history is meant to be checked
The design adds each change to Plan history and publishes signed proofs so independent reviewers can check for tampering.
How private completion is designed to work
The private completion path is designed to show ordinary success to the Planner and “Confirm they’re OK” to an authorized Backer. The Backer cannot tell why it happened. The protocol and threat model explain the design.