last updated 2026-11-03 · aerology.ai and app.aerology.ai
As of the date above there is no account here, we do not ask who you are, and the only thing you tell us is which flights you are asking about. What follows is what actually happens to that — read off the code and the infrastructure on that date, not off a template.
A forecast needs the flights in your trip, and — only if you move it — the minimum connection time you want us to assume. That is the entire input. Nothing else about you is collected or required.
Today there is no account and no password. No form on either site asks for your
name or your email address. The addresses on the landing page are ordinary
mailto: links: if you write to us, we have your mail, the same as any
other correspondence.
One of them is the waitlist. Joining it means writing to waitlist@aerology.ai from your own mail; nothing is sent to you automatically. We keep your address and your message to write to you when programmatic access opens, and for nothing else. To be taken off the list, write to the same address or to privacy@aerology.ai, and we delete your mail.
The app gives your browser a cookie holding a random number (below, under cookies), and keeps under that number the trips that browser has looked up, as fingerprints (the same fingerprint as the log line below). That record is a short travel history keyed to a cookie, in our database and nowhere else. It expires 24 hours after it is made, and our database deletes it within about a day of expiring.
The app also works out a key from your network address — the address Google's front end saw, the same one its web-server log records (below), and for an IPv6 address only its first half (the /64), which a home or a phone network shares — and counts how many different trips that key has asked about that day. The key is a keyed hash that takes in the day (by UTC) as well as the address, so one day's key cannot be matched to another's, and the address itself is never written down. The key cannot be turned back into the address by anyone who held our database, because the secret that makes it is kept apart from it. Each key and its count expire after 24 hours and are deleted within about a day of expiring. The count is there so that one source cannot ask about thousands of trips by clearing its cookies; the level is in the hundreds of different trips a day, so it should never meet one person.
The network key above also counts how many new browser identities first appeared under it that day, which is what clearing cookies to look again looks like. To count a browser identity once, its own 24-hour record notes the network key it first appeared under (the key, never the address). The count is kept the way the trip count is, for the same 24 hours, and used the same way: to see what a shared network looks like before any limit is set on it.
When the app answers a forecast, it writes one line to its own log:
That line carries no name, no account, no cookie value and nothing derived from your IP address. The fingerprint is a property of the itinerary, not of you: two strangers looking up the same trip produce the same one.
Those lines are copied into a data warehouse we own, where each day's rows are deleted 365 days after they arrive. We keep them to answer two questions: how much the service is being used, and whether anyone moves the connection minimum.
The app writes a few other kinds of line to the same log, and they are copied to the warehouse too: for the results page's history chart, the same fingerprint and leg count as a forecast; when you look up flights, the two airports you asked about; when it loads the national figures on the front page, whether it could read them and how old they were; when it turns away a request that did not come from one of its own pages, which address was asked for and which request headers were missing or pointed elsewhere; and, once a minute, how many browsers and how many network keys (above) asked about how many different trips, and how many network keys saw how many new browser identities, which is how we learn where the limits should sit. None of these lines carries a name, an account, a cookie value or anything derived from your IP address, except that each minute's count says how many network keys reached each number of trips or of new browser identities, and never names one.
The door through which assistants will connect to an account writes a line when an assistant registers, when a person allows or declines one, when a code is exchanged for access and when access is ended, saying which of these happened and never which assistant or whose account. Once a minute it also counts the requests it turned away because a web page sent them, because the assistant named itself by a web address, or because it asked to be sent back somewhere other than a secure web address, with the name of the site each came from or the kind of link, and never an address, a path or anything about you.
From a device set to a US time zone, the app's pages also send a short report of their own. It says how long the page took to draw and to respond; whether it hit an error, by the kind of error and where the page caught it, never the error's message; which of the page's layouts was showing and whether the screen is touch or mouse; and which of a few steps the visit reached: the front page, opening a leg, adding a connection, asking for the odds, the results drawing, their history drawing, and moving the delay slider. It carries no flight, no address and nothing about your browser beyond those. Each report carries a random number made when the page loads, so the steps of one visit can be read together. It is never stored in your browser and is gone when you close or reload the page. The reports are copied to the warehouse and deleted after 365 days, like the lines above. They arrive like any other request, so the web-server log below notes each one's IP address for its 30 days; we never use that to tie a report to anyone. From a device set to any other time zone, the pages send nothing.
Two things that are true and easy to leave out. When a flight cannot be resolved at all, the app logs that flight's reference so we can report it upstream. And Google Cloud keeps its own web-server log for the app, the way any web server does: your IP address, your browser's user-agent string, the page that linked you here, and the URL you asked for — which, for a forecast, contains the flight references. We do not copy that log into the warehouse; it stays in Google Cloud Logging, where this project's default bucket keeps 30 days. We query it where it stays, to count visits by page, by the site that linked to us and by kind of device, and to tell people from automated clients. Those counts use nothing derived from your IP address and keep nothing about any request.
This landing site has a web-server log too. Firebase Hosting writes it to the same
bucket, where it is kept for 30 days: your IP address, your browser's user-agent
string, the page that linked you here, the URL you asked for, and the country and
city Google works out from your IP address. It is not copied into the warehouse
either, and we count from it the same way, using nothing derived from your IP
address. /llms.txt, a machine-readable descriptor for automated
clients, is served by a small service of ours and is logged like the app.
The app sets one cookie of its own, on app.aerology.ai alone — never
on .aerology.ai, so this site and the logbook never receive it — and
it holds a random number and nothing else:
aer_anon, set the first time a page of the app loads: a random
number that lets the app count the trips one browser looks up (above), kept out
of reach of scripts on the page. It lasts 24 hours.
Beyond it, the app keeps nothing about you in your browser — no local storage. This site sets no cookies at all.
aerology.ai as a whole is not cookie-free, though, and we would
rather say so than write a sentence we would have to defend. Our newsletter,
logbook.aerology.ai, is hosted by Substack and sets
_gcl_au on .aerology.ai itself — a Google Ads cookie,
about 90 days — so your browser sends it to every subdomain, this one and the app
included. Substack controls the tags on that page; we do not.
If you ever visited at-booking.aerology.ai, a page left over from the
site before this one and since retired, your browser may still hold the Google
Analytics cookies it set on .aerology.ai, and send them here until
they expire.
Nothing we run reads any of them: the app reads only its own cookie above.
storage.googleapis.com.
The forecasts themselves are ours. They are computed by our own model service, in our own Google Cloud projects, from the flights you gave us. Your trip is not sent to a third party to be answered.
A few things on this page describe the beta (the research preview) as it stands rather than what comes next:
If any of this changes, this page changes first, and the date at the top says when.
Write to privacy@aerology.ai. If anything on this page turns out not to match what the software does, that is a bug — tell us, and we will fix the page or the code, whichever is at fault.
To report a security problem, write to
security@aerology.ai, as
/.well-known/security.txt on both sites says.