The credential worth stealing
The thing an attacker wants out of a travel database is not a password. It is the airline's manage-booking pair: a record locator and the passenger's last name. With both, anyone can view, change, or cancel a flight from the carrier's own website.
Stub has to store record locators. So the design goal is to make the other half unobtainable. A copy of Stub's database should not be enough to alter anyone's travel. That is a goal, not a guarantee. The rest of this page is what backs it, and what does not.
Never collected
- Date of birth
- Never collected
- Passport number
- Never collected
- Known Traveler / Global Entry
- Never collected
- Loyalty membership number
- Never collected
The email extractor is told never to emit these, and the ingest boundary copies fields by name, so a key nobody asked for is dropped rather than stored. A test holds the line: a hostile message volunteers all of them under ten spellings, and the test then walks every table of the resulting database and fails if one survived.
Read, then dropped
A forwarded email is read in memory and never written to the database. Only the structured facts survive it.
On the way in it passes through a Cloudflare Worker and sits in a replay buffer whose objects expire on their own, currently after 30 days. Full names do not survive either: every traveler name the extractor captures is reduced to a given name and one initial, Given L., before anything is stored. The evidence quotes the extractor takes from the email are discarded once checked.
What is stored
Itinerary facts, including confirmation numbers and record locators. Minimized name fragments. And an account row: an identifier from Miles, your email addresses as ciphertext — the one you sign in with, plus any you've verified as also yours — and a display name that is a given name and nothing else. More addresses on file means more identity at rest; unverified ones are deleted after seven days. The address you sign in with need not say anything about who you are.
Key custody
Two things are encrypted at rest: your Miles tokens, and your email addresses.
Vault mints a 256-bit data key and returns it wrapped by a key that was generated inside Vault and cannot leave it. The application can ask Vault to unwrap. It cannot read or copy the wrapping key, and every unwrap is an audit event. An unwrapped data key lives in memory for at most 5 minutes.
If Vault is unreachable, nothing falls back to a weaker key or to plaintext. Your Miles wallet goes empty until it recovers. Signing in still works, existing sessions keep working, and trips and search are untouched.
Sign-in, and where it runs
There are no passwords. Sign-in is Sign in with Miles, OAuth 2.1 with PKCE, and the token exchange is server to server, so Miles tokens never touch your browser. Stub's session cookie is a 256-bit random value stored only as a hash.
Stub runs on a small computer I have physical control of, alongside Miles, reached through a Cloudflare tunnel. The database is one SQLite file, replicated to Cloudflare R2 with 7 days of retention, protected there by R2's own at-rest encryption rather than by a key of mine.
The volume that machine runs from is encrypted, and it unlocks by hand rather than on its own. After a power cut it stays locked at the login screen, and Stub is down until a person unlocks it.
A forwarding address is a capability, not an identity: u- and 16 random hex characters, never derived from your name. Regenerating it kills the old one permanently, and mail from a sender other than one of your verified addresses is never trusted.
What this does not protect against
Minimization protects against a copy of the database. It does not protect against any of these.
- The disk, while it is running. Full-volume encryption covers a machine that is powered off. While it is serving, the volume is unlocked and your trips are ordinary rows to anything running on that machine. The name half of the booking pair is minimized away rather than merely encrypted for that reason.
- Your trips. Only tokens and your email are encrypted by the application. Trips, items, notes, and confirmation numbers are ordinary rows. Per-account keys, and destroying one so a deleted account becomes unreadable, are deferred.
- Me. I run the service, so I can read your trips. I do it to debug something or when you ask for help. Nothing enforces that, and you should weigh it.
- A legal order. I can be compelled to produce what I hold, and I hold your itineraries in a form I can read.
- Links you hand out. Share links and calendar links are 256 random bits, but they sit in the database as-is, and anyone holding one can read it until you revoke it.
- The extraction log. Every message Stub reads leaves a line in a server log that still records the sender's full address and the subject line. Subject lines carry record locators. Trimming it to outcomes only is planned, not done.
- Things you removed. An item you remove from a trip is not erased. It moves to that trip's removals drawer and stays indefinitely so you can put it back. A deleted trip leaves a dump of itself behind too.
- Deleting somewhere else. Deleting your Miles account does not delete your Stub trips. Nothing propagates either way.
- Deletion here. There is no delete button and no export button. Both are requests you make to me, carried out by hand.
What Stub deliberately does not do
Stub does not encrypt your trips with a key only you hold.
Its value is that a booking can arrive at 3 a.m. and be read before you wake up. The server has to be able to read while you are asleep. Apple leaves Mail, Calendar, and Contacts out of Advanced Data Protection for the same reason. So rather than make a guarantee it cannot keep, Stub refuses to store the fields that guarantee would have protected.
Reporting a problem
Email support@askmiles.ai. There is no bug bounty, and I am glad to credit you. The same address handles export and deletion requests for Stub; Miles and Stub still keep separate data.
Stub is built and run by one person, Andy Assareh. This page says “I” because there is no company. It has not been reviewed by anyone qualified. Privacy says what Stub keeps.