Privacy Policy

This policy is written from the code, not from intent. Every claim below was checked against the table it lives in, the endpoint that writes it, or the build output that proves its absence. Where something is planned but not built, it says so rather than describing it in the present tense.

Scope

Waygate Technologies LLC is the controller for everything described here.

This policy covers three things: the TallyAir app for iPhone and iPad, the website at tallyair.app, and the email waitlist. They collect very different amounts of data, so they are kept separate throughout — the website collects nothing at all, and the waitlist collects one field.

It does not cover the upstream data providers listed on the data sources page. Those are independent third parties that TallyAir reads from, not subprocessors acting on its behalf. TallyAir sends them nothing about you: it requests public aircraft data and displays what comes back. Their terms govern their own conduct, not this policy.

What TallyAir collects

This section matches the App Store privacy nutrition label field for field. The label declares:

Data used to track you: none. TallyAir contains no advertising identifier, no third-party SDK of any kind, and no cross-app or cross-site tracking. The app requests no App Tracking Transparency permission because there is nothing to request it for.

Data linked to you: Contact Info (email address, name), User Content, Identifiers (user ID, device ID).

Data not linked to you: none.

Data not collected: location, contacts, health and fitness, financial info, browsing history, search history, usage data, diagnostics, purchases, and sensitive info. The two entries most worth explaining — location and usage data — have their own sections below.

Account data

Sign in with Apple is the only way to sign in. There is no password, no email and password form, and no other identity provider.

What is stored when you sign in:

• Apple’s subject identifier for you. A stable, app-specific string Apple issues. It is how a returning sign-in resolves to an existing account, and it is meaningless outside TallyAir.
• An account id generated by TallyAir.
• Your email address, if Apple sends one. Apple only ever provides this on your first authorization for the app, never afterwards. If you chose to hide your address, what arrives is an Apple private relay address (@privaterelay.appleid.com), and that relay address is what gets stored — TallyAir neither receives nor attempts to resolve your real one.
• A display name. If Apple provides your name on that first authorization it becomes your display name; otherwise you get a generated placeholder in the form “Pilot 1A8C”.

An account works perfectly well with no email address at all. The field is nullable and stays empty if Apple sends nothing. Nothing in the app requires an address to function, and no email is ever sent to it — the waitlist below is a separate list you opt into yourself.

Your profile

The profile is optional and starts empty. It holds a real name, a call sign, a home airport, and a short bio, all free text and all blank until you write them.

One thing here deserves a plain warning. If you fill in a call sign, that call sign becomes the name shown next to your comments. If you fill in a real name and no call sign, your real name becomes the name shown next to your comments, which are publicly readable. This is not obvious from the form. If you do not want your real name public, set a call sign, or leave both blank and keep the generated placeholder.

The home airport and bio are stored but are not currently displayed to anyone but you.

Follows, and what is actually social

This is the section people ask about, so it is worth being exact, including about what does not exist.

You follow aircraft, not people. A follow is a row pairing your account with an aircraft’s ICAO24 address, plus a flag for whether you want push alerts about it. There is no user-to-user follow in TallyAir. You cannot follow another person, nobody can follow you, there are no followers, and there is no social graph between accounts.

Your log is derived, not authored. The log is not a diary you write entries into. It is a view: every flight of every aircraft you follow, newest first, computed from your follows at the moment you open it. There is no log entry record, so there is nothing to make private or public, nothing to share, and nothing to delete individually. Stop following an aircraft and its flights leave your log.

What you can post is public. The genuinely user-authored content is comments on flights and on live events, plus kudos and aircraft claims. Comments are readable without signing in. Treat anything you type into a comment as public, because it is.

Blocking. You can block another account. Blocking hides that account’s comments from you. It is one-directional: the other account is not notified, and blocking does not stop them seeing what you have posted. The block is stored as a pair of account ids and is removed when either account is deleted.

Reporting. Any comment can be reported, with a reason of spam, harassment, inappropriate, or other. A report stores who reported, who was reported, and what was reported.

Not yet built. An earlier version of the TallyAir website described a spotting log with optional notes, an attachable named place, entries that stay private until shared, and a follow graph between spotters. None of that is implemented. It is a design for a future version, and this policy will be updated in the same commit that ships it — before it ships, not after.

Push notification tokens

If you enable notifications, an APNs device token is stored against your account so alerts can be delivered to the right device.

Stored alongside it is an installation identifier: a random UUID the app generates on first launch and keeps in the Keychain. Its only job is to answer “is this the same install?” so that when iOS rotates your push token, the stale row is replaced instead of accumulating. The server compares it for equality and never does anything else with it. It is not Apple’s advertising identifier, not identifierForVendor, not shared with any other app, and not derivable from your device — a fresh install produces a fresh value.

Both are declared under Identifiers on the nutrition label. The installation identifier is per-install rather than per-device, but it is declared as a device identifier anyway: under-declaring is the worse error.

Tokens are deleted when you turn off notifications for that device, when you sign out, when Apple reports the token as no longer valid, and when you delete your account.

Notification content is generated on the server from public ADS-B broadcasts — an aircraft you follow went active, squawked an emergency code, or landed. It contains no information about you.

Analytics and diagnostics

There are none. This is a checked claim, not an intention:

• The app has no third-party dependencies at all — no analytics SDK, no crash reporter, no attribution or advertising framework. There is nothing in it that could report on your usage.
• The backend has no telemetry or analytics dependency.
• The website loads zero third-party resources. Fonts are self-hosted from the repository, not fetched from a font CDN. There is no tag manager, no pixel, and no script from any other origin.

The website claim is enforced rather than promised. pnpm build runs a check that scans the built output for any resource loading from a host that is not explicitly allowed, and fails the build if it finds one. Adding a third party to this site requires editing that allowlist, which is deliberately the same commit where this paragraph would have to change.

The server keeps ordinary access logs. A log line records the HTTP method, the path, the response status, how long it took, and a random per-request id. It does not record the query string, your IP address, or your account id — so the map area you were looking at and anything you searched for are used to answer the request and then gone.

Location

The app asks for location once, when in use, for one purpose: centering the map on where you are. The permission string says so, and it is the only location permission requested — there is no always-on and no background location.

Your location never leaves your device as a location. It is not stored on the server, not attached to anything, and not present in any database column; no table in TallyAir has a user coordinate in it.

The one thing worth being straight about: the app asks the server for aircraft inside the map’s current bounding box, and if you have centered the map on yourself then that box is loosely near you. It is a map viewport, not a position — it is whatever rectangle you are looking at, at whatever zoom, and panning away changes it. As noted above, query strings are not logged, so these boxes are not written down anywhere. You can decline the location permission and use the app by panning the map yourself; nothing else depends on it.

What is not collected

Stated specifically, because a vague version of this list would be worthless:

• No advertising identifier, and no advertising.
• No contacts, photos, microphone, camera, calendar, or health data. The app requests none of these permissions.
• No browsing or search history. Aircraft searches are answered and not retained.
• No usage analytics, no session recording, no heatmaps.
• No password, because there isn’t one.
• No payment or financial information. There are no purchases in the app.

The website

tallyair.app collects nothing. It sets no cookies, uses no local storage for tracking, and runs no analytics. It is static files. There is no server-side session, no log-in, and nothing that identifies a visitor.

The single exception is the waitlist form below, which does nothing at all until you type an address into it and submit it.

The waitlist, and your GDPR / CCPA rights

The waitlist is operated separately from the app and has no connection to any account.

Controller and processor. Waygate Technologies LLC is the controller. Buttondown is the processor that stores the list and sends the messages.

What is submitted. Exactly three things: the email address you type, a fixed tag identifying which site the signup came from (tallyair-app), and the timestamp Buttondown records on receipt. There is no name field, no hidden field, and no profiling.

Lawful basis (GDPR Art. 6). Consent, given by submitting the form. Submitting is the entire consent record — there is no pre-ticked box and no bundled agreement. Withdraw it with the unsubscribe link in any message. No account is needed to unsubscribe, and unsubscribing needs no explanation.

What it is used for. One message when TestFlight opens, and release notes afterwards. The list is not used for anything else, and it is not merged with app account data.

Not sold, not shared. The list is not sold, rented, or shared for cross-context behavioral advertising, which is the CCPA/CPRA term of art. It has never been and there is no mechanism by which it could be.

Your rights. Access, correction, deletion, portability, and objection under GDPR; access, deletion, correction, and opt-out under CCPA/CPRA. Use the contact address below. Unsubscribing is always the fastest route for the waitlist specifically, since it needs no identity check.

Open before publication. Buttondown’s current DPA, subprocessor list, data location, and the transfer mechanism for EEA/UK subscribers have to be read and summarized here rather than assumed, along with how long Buttondown retains an unsubscribed address. Ticket #51 verifies the list end to end; this paragraph is written when that lands.

Children

TallyAir is for adults. You must be 18 or older to use it, as the terms of use require.

TallyAir is not directed to children, has no child-directed features, and collects nothing knowingly from anyone under 18. Because the service is not directed to children and no under-13 use is permitted, COPPA does not apply to it.

If we learn that an account belongs to someone under 18, the account is closed and its data deleted — the same hard delete described below, not a flag on a row.

Open before publication. The App Store age rating in App Store Connect has to be set to 17+, which is the highest rating Apple offers and the only one consistent with an 18+ requirement. Verify it is set before submission; a lower rating contradicts this paragraph and the terms of use.

Requests, deletion, and contact

Deleting your account. The app has an in-app account deletion path, as Apple requires. Deletion is immediate and permanent — a hard delete in a single transaction, not a flag and not an anonymization pass. It removes, in one go: your account row, your Apple identity record and the email address on it, your sessions, your profile, your aircraft follows and claims, your comments on flights and events, your kudos, your flight corrections, your notifications and their delivery log, your device tokens, every block in either direction, and every report you filed or that named you.

There is no archive holding a copy afterwards. Ordinary encrypted database backups are the one exception, and they age out on their own retention cycle.

Retention while the account is open. Most of what is stored is kept for as long as you keep it — a follow lasts until you unfollow, a comment until you delete it. Four things expire on their own, without you asking:

• Sessions are deleted shortly after they expire.
• Push delivery records are deleted after a fixed window; they exist only to stop the same alert being sent twice.
• Read in-app notifications are deleted after a window. An unread one is never removed out from under you.
• Aircraft sighting counts, which are not linked to any account, are deleted once they are older than the rarity calculation looks back.

Open before publication. A real monitored contact address, the response window committed to for a rights request, and how identity is verified for a request that is not simply “unsubscribe”. These need to be decided rather than invented, and the address has to exist and be watched before this document publishes.

Changes to this policy

The date at the top of this page is the effective date. Material changes — a new category of collected data, a new processor, a new purpose — are announced on the waitlist before they take effect, and this page always describes what the current release actually does.

The commitment behind that is procedural, not aspirational: this document is written from the code, and it is checked against the code when the code changes. The build-time third-party check exists so the website half of it cannot drift silently.