Privacy, in plain terms.

The longer version, in the same order. The visibility screen asks for your location, precise if you allow it, and what it reads never leaves the phone. The one location-shaped thing that is sent needs no permission: while usage counting is on, Google Analytics places your connection to a region, a province or state, not a town. Your follows, filters and alert history stay on your phone, with one follow-shaped exception held at Google: following a launch subscribes your phone to that launch's push channel, so a scrub correction can reach it. Google holds which channels this phone joined; our server addresses a channel blind and never learns who follows what. Of the three streams, the delivery record says whether each alert arrived and what kind of phone it was on, so we can publish a per-brand delivery record; the usage counts say which screens get opened; crash reports cannot be switched off, and the reason is below. The iPhone's delivery record counts only fires the phone could prove afterwards, and the delivery section says exactly what that means.

The website

These pages are static files served from Firebase Hosting, and as of 18 August 2026 they fetch nothing at all. The launch board and the accuracy record moved into the app, and the pages that read them are switched off rather than deleted. Like any web host, Google's infrastructure records standard server logs to deliver the content: your IP address and browser user-agent. We add nothing on top: no analytics scripts, no cookies, no fingerprinting, no tracking pixels. The site works identically with every consent banner you have ever refused, which is why it does not need one. The analytics described further down runs in the apps; none of it runs on these pages.

The app, on your device

The app keeps its state locally, in the phone's app storage:

• the missions you follow, your range filters, and alert preferences;
• an offline copy of the launch board, so the app works without signal;
• a log of the alerts it posted: when each fired, how late it was, and the device conditions at that moment (on Android: standby bucket, battery-optimization state, manufacturer, Android version; on iOS: whether background refresh was on). This exists so the app can warn you when your phone is limiting it. iOS runs none of the app's code at the moment a scheduled alert fires, so an iPhone row exists only once the fire could be proved afterwards: seen, tapped, alarm stopped, or still in Notification Center at the next open;
• the bookkeeping that stops duplicate notifications.

None of this is transmitted except the streams described next, and each of them is a narrow slice of it. One shadow is worth naming: every follow on that list is mirrored by a push subscription at Google, which is not a stream and has its own section below.

The alert-delivery record (optional, and you can turn it off)

Android cannot guarantee that an alert arrives. Manufacturers throttle background apps in ways no app can detect, and we refuse to claim a delivery rate we have not measured. So the app measures it, and we publish the result per phone brand on the app's own Stats tab, including the brands that do badly.

On iOS the record measures proven deliveries, and says so. When a scheduled alert fires on an iPhone with the app closed, none of our code runs at that moment, because iOS has no equivalent of Android's fire-time check. What the iPhone app sends instead is what it can prove afterwards: an alert counts as delivered only once you saw it in the open app, tapped it, stopped the alarm, or it was still sitting in Notification Center the next time the app ran. A fire you cleared without the app ever running again is real and uncounted, and any published Apple number carries that asterisk rather than hiding it. What travels is the same schedule-free set as Android's: the alert type, how late, whether the schedule had already changed, which instant the alarm counted from (the listing's target or the window's open, never which launch), and the phone's model and iOS version. Never which launch you follow, never a location, no account. The same switch governs it, on both platforms.

What is sent. Three kinds of small record: that an alarm was scheduled (and for when), that an alert fired (and how many milliseconds late), and a periodic note that the app is still installed. Each carries your phone's make, model, operating-system version, and the app version, plus the conditions that decide whether alerts can work at all: on Android the standby bucket, battery-optimization and hibernation exemptions, notification state and the precise-alarm grant; on iOS the notification state and whether Background App Refresh was on. Since 23 August 2026 an armed or fired record also says which instant the alarm counted from — the listing's target or the range window's open, the choice under Settings → Alert types — because the published stale-alert rate has to keep those two promises apart. It is one of two words, and it says nothing about which launch.

What is never sent. Which launch you follow. A scheduled and a fired record are matched to each other by a random token the app generates on your device for that one alert; the mission name, the notice number, and the window are not part of it and never reach us. (The one place a followed mission's identity exists off your phone is the push subscription at Google, in its own section below, never in these records.) There is also no location in it, no email or name, no contacts, and no advertising identifier. The app does hold a location permission now, for the visibility screen described below, but nothing that screen reads reaches this record, or leaves the phone at all.

There is an anonymous identifier behind all of this. So that your phone can write only its own records, and so a subscription has something to attach to if you ever buy one, the app signs in to Firebase anonymously on both platforms. That produces a random identifier tied to the app installation, not to you: it has no email, no name, and nothing links it to a person. On Android, clearing the app's storage or uninstalling breaks it permanently, and a fresh install gets a new one. iOS keeps it in the system keychain, which Apple can preserve across a delete-and-reinstall, so a fresh install there may wake up with the same random identifier rather than a new one; it still names no person, and the retention section below returns to this.

Subscribing does not change this. There is no account to create and none to sign in to. A Scrubline PRO purchase belongs to your Google Play or App Store account and is held there, so we are never told a name or an email address — what reaches us is the store's own purchase receipt and an anonymous customer identifier, which is the same shape of random string as the one above. The trade is stated rather than hidden: because nothing durable of yours is held here, a new phone, a reinstall or a factory reset needs one tap on Restore a purchase to bring PRO back. That asks the store, which does remember, rather than us.

Delivery records sent since 18 August 2026 are keyed by a random installation identifier that is deliberately not a sign-in identifier. One honest exception, for the short period before that date: the record then used the anonymous sign-in identifier as its key. Those rows carry no email and are joined to nothing — there has never been an account for them to be joined to.

Where it goes and how long it stays. Records land in Firebase (Google Cloud, United States), are moved promptly into our own private database, and are deleted from Firebase as they move. What we publish is only ever aggregate data. The visible record is counts per brand across OS versions, with sample sizes, and no rate at all where a group is too small to say anything honest. During a staged app migration, the public payload also retains the old per-brand, per-OS-version aggregate rows needed by installed readers; it never exposes a per-installation row. Apple rows are published under the proven-fires method stated above, with that method printed beside them. The raw per-installation rows stay private and are never published, sold, or shared.

How to switch it off. Open the app, tap Settings, then What you share, and turn off “Contribute to the delivery record”. Nothing is collected from then on: the app stops recording as well as stops sending, so there is no backlog waiting to go. Everything else in the app works exactly the same, and the local alert log that warns you about your own phone keeps working, because it never depended on this.

It is on by default, deliberately: a reliability record assembled only from people who went looking for a switch is not a reliability record. If that reasoning does not persuade you, the switch is three taps away.

Anonymous usage counts (optional, and you can turn them off)

The app uses Firebase Analytics, on Android and (as of 19 August 2026) on iOS, to count how it is actually used. This is a separate switch from the delivery record above, because they are separate questions and turning one off should not silence the other. Both platforms carry the same closed list of events, the same switch, and the same advertising-signal settings: off, with no identifier for advertisers on either.

What is counted. Which screen you opened: the board, a ladder, can-I-see-it, lens and exposure, the scorecard, settings and its four sub-screens (display, alert types, what you share, sources), alert health, device checks, and the open-source licences. Never which ladder, and never where you were standing. Whether you added or removed a follow, and how many you now have, but never which mission. Whether an alert-type or night-mode switch moved, which instant you chose for alerts to count from (the listing's target or the window's open), whether you changed the units between miles, kilometres and following your device, and whether you set explanations to Basic or Full: the setting only, never a position, and never which explanation you opened. Whether a board refresh failed, and our own one-word reason for it. Whether you opened the device-checks screen and how many problems it found. Whether you tapped a button that sends you into the system's settings (and on Android, which of the five such buttons). How the notification-permission request resolved. And whether you switched this counting off, recorded at the moment you do it, because afterwards nothing is recorded at all and we would otherwise be unable to tell an opt-out from an uninstall.

That is the complete list. A build check enforces it: if the app tried to send anything outside that list, it would not build. That is how the list is still true a year from now.

The SDK adds things we do not choose. Firebase Analytics collects session and engagement events, your app version, Android version, and a random identifier for this app installation. It also works out roughly where you are, from the IP address your connection arrives on.

By default that is city-level, which is precise enough to name a town of a few thousand people. We have switched Google's “granular location and device data” setting off, so what is collected now stops at region: a province or state. That is still a location and we are not going to call it anything else, but it is the coarsest Google offers, and nothing in Scrubline uses it. The same setting also turned off the detailed device fields, so Analytics no longer receives your device brand and model either; the per-brand delivery record above still does, because that measurement is the entire point of it and it has its own switch. Google states that it does not log or store the IP address itself; it derives the location and discards the address. That region is worked out from your IP address, not from your phone's own location. The app does hold a location permission, for the visibility screen described below, and nothing it reads there is transmitted anywhere, not to us and not to Google. Turning the switch below off stops all of this along with everything else in this section.

What is never counted. Which launch you follow, any mission or notice number, your precise or device-reported location, an email or name, and, specifically, no advertising identifier. Adding Analytics normally pulls in two Android permissions that grant access to the advertising ID; both are stripped out of our app at build time, the build fails if either reappears, and every advertising-consent signal the SDK offers is set to off with no way to turn it on. We do not use this data for advertising, we do not have an ads product, and the permissions are gone so that this paragraph cannot quietly stop being true.

How to switch it off. Open the app, tap Settings, then What you share, and turn off “Share how the app is used”. Collection stops in the SDK itself, not just the sending. It is on by default for the same reason as the delivery record, and off is three taps away.

Where you are standing (used on your phone, never sent)

The visibility screen answers “can I see this launch from here”: which direction to face, how high the rocket has to climb before it clears your horizon, and whether its plume will still be in sunlight while you are in the dark. All of that is geometry between where you are standing and the pad, so the app asks the phone for your location, on Android and on iOS alike.

It is never transmitted. The calculation happens on your phone, the answer is drawn on your screen, and the position is not sent to us, to Google, or to anyone else. There is no request carrying it, because there is nothing we need a server to work out. If you decline the permission the rest of the app is unaffected; only that one screen needs it.

It asks for precise location, and not because the bearing needs it. This changed, and the reason is worth stating because the obvious assumption is wrong. Horizontally, precision really does not matter: a pad is tens to hundreds of kilometres away, so a 2 km fix and a 10 m fix give the same bearing to within a fraction of a degree. What precise location buys is the third dimension. Android deliberately strips altitude out of an approximate fix before an app can see it, a reduced-accuracy fix on iOS carries no height worth using either, and how high you are standing is the single biggest influence on this calculation: 100 metres of elevation changes the answer by more than 90% at short range. Asking only for approximate meant the app was quietly telling everyone they were at sea level.

You can still say no to the precise half. Android's permission dialog offers Precise and Approximate, and iOS puts a Precise Location switch on its dialog; either way the app is built specifically so that choosing the reduced option still works: you get the bearing, the distance and the twilight window, and the screen assumes sea level and says on its face that it is doing so. Nothing about this changes what is transmitted, because nothing is transmitted either way.

The cloud cover on that screen is the sky over the launch pad, taken from the same public forecast the rest of the app uses, not the sky above you. Telling you about your own sky would mean sending your position to a weather service, and we would rather show you a labelled approximation than quietly start transmitting where you are. The screen says which one it is showing.

Crash reports (not optional, and here is why)

The app uses Firebase Crashlytics, and this one has no switch. The whole function of Scrubline is a notification arriving at a particular second, and an alert that never arrived because the app crashed is a failure you have no way to report and we have no other way to see. A crash reporter that the people experiencing crashes have turned off is not a crash reporter.

What is sent. When the app crashes: the stack trace, the error type and message, which threads were running, your app version, device model, Android version, available memory and storage, screen orientation, and how long the app had been running. Alongside it, the same phone-condition fields the delivery record already sends — manufacturer, Android version, standby bucket, battery and hibernation exemptions, whether precise alarms are permitted — because the same crash means something different on a throttled phone than on an unthrottled one; and two yes-or-no facts of ours that this page should have listed when they arrived: whether this install was attested at the time (the same bit described under “What the app fetches” below, since 18 August) and whether the phone's clock could be checked against a trusted time source (since 19 August). Neither says anything about you or about which launch. The app also reports a handful of failures it recovered from, such as being unable to save a freshly downloaded launch board, a refused purchase (with the store's own reason), or a delivery record it could not send.

The iOS report is smaller. This is the one stream both apps send, and the switchlessness and its reason are identical. An iPhone crash report carries the crash itself and the device basics — model, iOS version, app version, memory and storage state — plus two things of ours: whether this install was attested at the time, the same yes-or-no described under “What the app fetches” below, and, like Android, reports of a handful of failures the app recovered from, marked with where they happened. iOS has no standby buckets or battery exemptions to record.

Identifiers. Crashlytics attaches a random identifier for this app installation, so several reports from one phone can be recognised as related. We never set a user identifier, and we deliberately do not connect crash reports to the anonymous identifier used by the delivery record; the two cannot be joined. On Android, clearing the app's storage or uninstalling breaks it permanently; on iOS part of it can outlive a delete-and-reinstall in the system keychain, as the retention section below states plainly.

What is never sent. Which launch you follow, your location, your name or email, the contents of the launch board, or an advertising identifier. In development builds, on Android and on iOS alike, crash reporting is also switched off entirely, so what reaches us is field evidence rather than our own noise.

What the app fetches

The app downloads the launch board as JSON from Google Cloud Storage — the board itself, the accuracy record, a small catalog of pad positions and elevations, and (since 23 August 2026) the orbital elements for what recent launches put up, all of them the same files for every reader — so Google's servers see your IP address the way any file host does. Nothing about you is in the request: it is a plain download with the attestation token described below, and for PRO the anonymous sign-in token the subscription section already described. Links out to webcasts, an operator's site or Launch Library open in your browser and are governed by those sites' own policies.

The app also asks the internet what time it is. An alarm scheduled on a phone whose clock is wrong fires at the wrong moment, so the app checks the phone's clock against a time source: on Android that is a Google Play services facility (Google, already on this page), and on iOS it is one small standard time query (NTP) to the public pool.ntp.org service on each launch. That query is the same packet every phone's own clock uses, it carries no identifier and nothing about you. The time server sees an IP address asking for the time, and answers it. The result stays on the phone and moves alarms only when the clock is provably off.

Since 18 August 2026 that download carries an app-attestation token, and what follows is the plain description of it. The launch board used to be readable by anyone with the address; it now requires a token from Firebase App Check, issued after the platform checks that the app is an unmodified copy on a genuine device. Google Play makes that check on Android, and Apple's App Attest makes it on iPhone. The check is a conversation between the app and its platform, and it is worth being precise about both halves of what that means:

• The token is not you. It is short-lived, it says "this is a real copy of Scrubline", and it carries no account, no name, no advertising ID and nothing you have done in the app. It cannot be used to recognise you on a later visit.
• Your platform evaluates your device to issue it. That is what Play Integrity is on Android, and what App Attest is on iOS. Google and Apple already run these checks for their own stores; what is new here is that this app asks for the result. We never see it; we see only whether a request arrived with a valid token or without one.
• If your device cannot be attested, the app still works. A rooted or jailbroken phone, a sideloaded copy, an emulator or an out-of-date Play Store means the board will not refresh, and the app says so on its face and keeps showing the last board it fetched, with its age. Alerts you have already set still fire, because they are scheduled on the device rather than delivered from a server.

The reason for the change is not about readers: the assembled board — the parsing, the matching, the forecast join, the record behind the scorecard — is the work this project does, and leaving it open to anonymous bulk collection meant giving that work away. The sources themselves are public and stay public; the terms say where to get them in bulk.

Push, and the one follow-shaped thing held off your phone

Alerts are not delivered from a server. They fire from alarms the app schedules on the phone itself, which is why they work in a tunnel. Push exists as the correction channel: when a launch window moves, a message nudges the app to fix its schedule. Since 26 August 2026 the same channel also carries one announcement rather than a correction — a quiet notification when a launch you follow has lifted off — which changes nothing about what is held or sent, and is mentioned because this page describes what the channel is for. On both platforms those messages ride Firebase Cloud Messaging, Google's push service. Two things have to exist for that to work, and this section is the honest account of both.

First, an address. When the app first runs, the phone gets a push address from Google: one more of the random per-installation identifiers this page keeps describing, naming the app install and nothing about you. On both platforms the app also registers that address in our own device registry, together with the make, model, operating-system version and build string the crash stream already carries, so that when a correction goes unacknowledged we can see which kinds of phone we are failing to reach. That registration has no switch, because it is how the correction channel exists at all, and it contains no follows, no location, no name. It is rewritten each time the app comes to the foreground; a row for an install that never returns — an uninstalled app — is a dead address with a device model beside it, and we do not yet sweep those, which is stated here rather than implied.

Second, routing, and this is the follow-shaped part. Following a launch subscribes your phone to that launch's own push channel: the app tells Google's push service “this device wants messages about this launch”. Unfollowing unsubscribes. This is deliberate, and it is the design that keeps your follow list out of our hands: when a window moves, our server addresses one message to that channel, blind, and Google fans it out. We hold no list of who follows what, we cannot ask Google for one (the push service gives a sender no way to enumerate a channel's subscribers), and every “never includes which launch you follow” on this page stays exactly true, because those sentences are about what reaches us.

The honest cost is that Google holds the routing list. For such a message to reach you, Google's servers must know that your phone's push address is subscribed to the channels of the launches you follow, and they hold exactly that, for as long as the follow lasts. It is keyed to the push address, not to you: no account, no name, no advertising identifier. Google processes it as our service provider, like the rest of Firebase on this page. Unfollow and the subscription is removed; uninstall and the address behind every subscription breaks. Follow nothing, and there is nothing to hold.

What we do not have, and the one exception

• No accounts, no passwords, no sign-up, no name and no email address — not for free readers and not for subscribers. The only identifiers are the per-installation ones described above, and nothing links them to a person. Nothing links them to each other either, with the one exception the subscription paragraph states: for a subscriber, the claim service pairs the store's anonymous customer identifier (hashed) with the anonymous sign-in identifiers it was seen on, so that a refund reaches every install that claimed the purchase. That pairing names no person and touches neither the delivery record nor the crash reports.
• The app asks for location, once, for the visibility screen, and nothing it reads there ever leaves your phone. It asks for the precise variant because Android removes altitude from approximate fixes and the calculation needs your elevation; declining the precise half still leaves a working screen. See the section above.
• The one location-shaped thing that is transmitted needs no permission at all: while usage counting is on, Google Analytics places your IP address to a region, on Android and on iOS alike. The switch under Settings ends it on either.
• No contacts, no camera, no microphone.
• No advertising identifier, and no advertising SDK. On Android, both advertising-ID permissions that arrive with Firebase Analytics are removed at build time, and a build that reintroduces either one fails. On iOS the same SDK ships with every advertising signal switched off in its configuration, and the app never shows Apple's tracking prompt because it tracks nothing and has nothing to ask about.
• No data sales, no data sharing beyond the processors named on this page, and no profiling. The delivery record is used to publish per-brand delivery statistics; the usage counts and crash reports are used to fix and shape the app. Nothing is used for advertising or sold to anyone.

The launch data itself

Everything Scrubline shows is derived from public operational sources: US Coast Guard Broadcast Notices to Mariners, Launch Library 2, NOAA / National Weather Service forecasts, FAA temporary flight restrictions, the USGS elevation model (for pad elevation) and, after a launch, the public satellite catalog at Space-Track.org (the orbital elements of what it put up; the passes over you are worked out on your phone, from your position, which as the visibility section says never leaves it). It is information about rockets, reserved stretches of ocean and objects in orbit. It contains no personal data. The full list, each source linked to where it is published, is under Settings → Sources in the app and in the terms.

Retention and your choices

On Android, uninstalling the app, or clearing its storage in Android settings, deletes everything it held on the device and breaks every per-installation identifier for good. On iOS, deleting the app deletes everything in its container too, with one platform honesty worth stating: iOS keeps small system-keychain entries — the ones behind the anonymous sign-in and installation identifiers — and Apple can preserve those across a delete-and-reinstall, so a fresh install may carry the same random identifiers rather than new ones. They contain nothing that identifies you either way, and there is no account behind them to delete. Records already contributed cannot be traced back to you to be withdrawn individually: there is nothing in them that identifies you, which is the same property that makes withdrawal impossible; if you would rather contribute nothing, the two switches under Settings are the way. Crash reports are retained by Firebase for 90 days. The website stores nothing on your machine beyond your browser's ordinary HTTP cache.

Who is responsible, and the legal basis

The controller is Scrubline, operated by an individual based in Poland. Questions, requests and objections all go to scrublineapp@gmail.com, which is the same address the Play listing carries.

Three of the four things we process rest on legitimate interest, and the fourth on your contract with us. Legitimate interest is a real legal basis and it comes with a real counterweight: you can object, and an objection has to be honoured. Where an objection is a switch rather than an email, we say so.

• The alert-delivery record — so we can measure, and publish, whether alerts actually arrive on each kind of phone. Object with the switch in Settings → What you share → Contribute to the delivery record. It takes effect immediately and nothing further is sent.
• Anonymous usage counts — so the app can be shaped around how it is used. Object with the switch in Settings → What you share, beside the one above. The two are independent: turning off either leaves the other running.
• Crash reports — so a crash that costs someone an alert can be found and fixed. This one has no switch, for the reason given above, so the objection route is email. Write to us and we will stop processing yours and delete what is held.
• Your subscription, if you buy one — performance of a contract. What that involves is the store's receipt and an anonymous customer identifier; there is no account, no name and no email address in it.

No decisions are made about you automatically, and nobody is profiled. The app predicts whether a rocket will fly. It makes no prediction, score or inference about any person, and nothing it holds is used to treat one reader differently from another.

Where the data goes. Most of the services above are Google's (Firebase and Google Cloud), and processing happens in the United States. Those transfers run on Google's own standard contractual clauses and its certification under the EU–US Data Privacy Framework. One more processor exists, for subscribers only: RevenueCat (RevenueCat, Inc., United States) manages the subscription itself. It receives the purchase receipt from the store you bought in, Google Play or Apple's App Store, and an anonymous customer identifier it generates itself. It never receives an email address, a name, your location, the delivery record or the usage counts, and it shows us purchase state, not payment details. Card numbers stay with Google Play or Apple. RevenueCat also tells our own small claim service when a purchase, renewal, expiry, refund or transfer happens — the event, its time and that anonymous customer identifier are what it acts on; the same message also names the product and the price the store charged, which the service reads past and does not keep — so PRO can be switched on or off without the app having to ask. Since 22 August 2026 that service keeps exactly one small record per subscriber: a one-way hash of the RevenueCat customer identifier, the last few (at most five) anonymous sign-in identifiers it has been seen on, and a timestamp. It exists so that a refund or an expiry reaches every install that claimed the purchase, not only the most recent one; it holds no entitlement, no receipt and nothing that names a person, it is stored in Firebase like the streams above, and no app or rule can read it. We hold no servers of our own outside that.

Your rights. You can ask for a copy of what is held about you, ask for it to be corrected or deleted, ask us to restrict how it is used, ask for it in a portable form, and object to any of the processing above. Email the address at the top of this section; we answer within 30 days. One honest limit, already stated above: records that carry nothing identifying you cannot be found in order to be handed over or removed, and that is a property of how they are built rather than a policy we chose.

If you think we have got this wrong, you can complain to the Polish supervisory authority — Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl — or to the authority where you live.

Age. Scrubline is not directed at children and we do not knowingly collect anything from anyone under 13. There is no profile and no social surface, and no sign-up of any kind, so there is nothing here for a child to fill in. If you believe a child has contributed something, write to us and we will remove it.

What changed, and when

27 August 2026. One addition, and it is not a new kind of data about you. Since 26 August the push channel this page already describes also carries a notification when a launch you follow has lifted off, alongside the window corrections it was built for. Nothing about it is new to this page's subject matter — the routing, the identifiers and what Google holds are exactly as the push section already described them — but that section says what the channel is for, and it had become an incomplete answer. No stream changed, no switch changed, and nothing further is collected.

23 August 2026. Four things, none of them a new kind of data about you. (1) Alerts now count, by default, from the listing's target rather than the window's open, and you can choose between the two in Settings; the choice travels twice, as one word on an armed or fired delivery record (so the published stale-alert rate can keep the two promises apart) and as a usage-count event when you change it. The delivery-record and usage-count sections above say so. (2) The app now reads one more public source after a launch, the satellite catalog at Space-Track.org, as a file that is the same for every reader; the fetch and launch-data sections name it, and the USGS elevation model, read since 18 August, is named beside it. (3) The usage-count section's list of screens grew by the settings sub-screens and the open-source licences screen, which it should have listed as they were added. (4) A correction: the Android crash-report paragraph omitted two yes-or-no facts the reports have carried since 18 and 19 August — whether the install was attested and whether the clock could be checked against a trusted time source. Both are now listed. The iPhone paragraph already said the first.

22 August 2026, the claim service. Until this date our claim service kept nothing at rest, and this page said so. It now keeps one small record per subscriber — a hashed customer identifier, the anonymous sign-in identifiers it was seen on, a timestamp — because without it a refund or an expiry could not be withdrawn from an install that had already moved on to a new anonymous identifier. The subscription paragraph above describes it, and this entry exists because the sentence it replaces was a promise.

20 August 2026, accounts removed. For one day this page described an optional account a PRO subscriber could attach — a Google account on Android, an Apple ID on iPhone through Sign in with Apple — so that a purchase survived a new phone. That is gone, along with the sign-in sheets, the account rows in Settings and the deletion page that existed for them. Scrubline now holds no name and no email address for anybody, subscriber or not, and there is nothing to sign up for. The cost of that is stated rather than buried: a new phone, a reinstall or a factory reset needs one tap on Restore a purchase, which asks the store — Google Play or the App Store — because the store is what remembers. Everything the entries below claim about an attached email or name is false as of this one, and the sections above have been rewritten rather than annotated.

19 August 2026. Subscriptions arrived. RevenueCat joined the processor list, receiving the purchase receipt and an anonymous customer identifier and nothing else.

19 August 2026, the iOS app. Scrubline is being prepared for iPhone, and this page now covers both apps rather than naming Android alone. This entry was written twice in one day, and honestly so: the morning version said the iOS app sent only crash reports, and by the evening that was out of date, because the same three streams now exist on both platforms. The iPhone's delivery record is the proven-fires variant its section describes (iOS runs no app code at the fire instant, so only fires the phone could prove afterwards are counted, and the published Apple rows say so); its usage counting is the same closed list with the same switch and every advertising signal off; its push address joins the same device registry. The visibility screen's position stays on the phone on both platforms; attestation runs on Apple's rails (App Attest) instead of Google's; and the iPhone app asks pool.ntp.org for the time, as the fetch section states. As always, this page moved before that build ships anywhere.

19 August 2026, the push channel. A section was added saying something this page should have said from the start: following a launch subscribes your phone, at Google, to that launch's push topic. That is the routing that lets a scrub correction arrive without our server ever holding a list of who follows what. The app also registers its push address, with the device basics, in our own registry. Neither practice is new and neither changed; the description of them was missing. A page that lists three streams and stays quiet about the one follow-shaped fact held at Google would be making exactly the mistake it exists to prevent, so both now have their own section above.

18 August 2026. The app now includes Firebase Analytics and Firebase Crashlytics. Until this date it included neither, and this page said so in those words. Analytics is optional and on by default; crash reporting is not optional. Both are described in their own sections above, and the sentence that used to promise no crash reporter is gone rather than quietly reworded. One correction the same day, recorded because it is the kind of thing this page exists to not hide: a first draft said Google Analytics derived only a country-level location from your IP address. That was wrong: Google collects city level by default, precise enough to name a small town. We found out by looking at the map in our own analytics console. So we switched that setting off; collection now stops at region, and the usage-counts section above describes what is left.

The same day, the app gained a visibility screen and, with it, the first location permission it has ever asked for. It asks for the precise variant, and the reason is counter-intuitive enough to state plainly: not because the bearing needs precision, which it does not, but because Android strips altitude out of an approximate fix, and how high you are standing changes the answer by more than 90% at short range. Declining the precise half still leaves a working screen. What it reads stays on the phone either way; the visibility section above says so in detail. This page changed before that build shipped, which is the promise directly below.

17 August 2026. Until that date the app had no upload path at all, and this page said so. It gained one: the optional delivery record above. We said we would change this page before shipping a build that transmits anything, so it changed ahead of that release.

Changes and contact

If practice changes at all, a new upload path or a new SDK, this page changes before the build that does it ships, and the effective date above moves. That promise has been kept on 17, 18, 19, 20, 23 and 27 August 2026, and missed once: the claim service's record of 22 August reached this page a day late (the entry above), recorded here rather than smoothed over. Every change is listed above. Questions to scrublineapp@gmail.com.