Skip to content
42nd Design

Privacy Policy for Skewt

Last updated: 13 August 2026

Skewt is published by 42ndDesign. This policy explains exactly what the app does with your data. It is short because the app collects very little.

The short version

Skewt has no accounts and shows you no advertising, and it does not build a profile of you. To draw a weather sounding it has to ask a weather service what the atmosphere is doing above a particular point, so a coordinate leaves your device each time you look at a location — but we do not store it, and we do not keep a record of the places you have looked at.

To keep the app working we also need to know when it breaks: the app sends a report when it crashes, and our server reports its own failures. Both are stripped of your location and your search text first. We may in future also measure how the service is performing and see which channels installs arrive from. What all of that covers, what it deliberately excludes, and which parts are running today, is set out under “Diagnostics, crash reporting, and attribution” below.

What the app sends, and when

A location coordinate. Every sounding is for a point on the earth, so fetching one sends that point’s latitude and longitude to our server. The coordinate is rounded to two decimal places — roughly a 1 km grid square — at the moment it is sent, so this holds however you picked the location: a point you tapped on the map, a place you searched for, a location you saved, or a reading taken from your device’s GPS.

A place-name search. If you search for a place by name, the text you typed is sent to our server, which forwards it to a geocoding service to turn it into candidate coordinates.

A crash report, when the app crashes. Nothing is sent while the app is working normally. What a report contains, and what it does not, is described in full in the next section.

That is the complete list of what the app sends. It sends no account, no email address, no contacts, and no photos, and there is no analytics of any kind anywhere in the app — we gather no usage statistics about you. Diagnostics, crash reporting, and install attribution are a separate matter and have their own section below. The Mapbox map SDK does send Mapbox its own usage counter (a count of how many times the map widget was created, with no location data); see “Who else sees your data” below.

Diagnostics, crash reporting, and attribution

An earlier version of this policy promised that Skewt contained no analytics, diagnostics, or crash reporting of any kind. That promise has been withdrawn, and we would rather say so plainly than quietly drop the sentence. Software with no way to report that it is failing cannot be kept reliable, and we were not willing to stay blind to crashes and performance problems in an app pilots rely on.

Crash reports from the app — running today. When the app crashes or hits an unexpected internal error, it sends a report to Sentry, a crash-reporting service that processes it on our behalf. This is how a bug that only happens on someone else’s phone becomes fixable.

A report carries the failure itself — the error and the stack trace of the code that failed — plus the app version, the Android version, and the device model and its state at the time (things like free memory and battery level). It also carries a short trail of what the app was doing beforehand: which of our endpoints it called and whether they failed.

What it does not carry is where you are. Coordinates are the one thing a crash report could plausibly leak, because the app’s requests contain them, so they are removed before the report leaves your device: every web address is stripped of everything after the ?, and every remaining message is re-scanned for anything shaped like a coordinate or a search term and blanked out. The same strip removes the text you typed into place search. There is no account or user ID attached, no advertising ID, no session or installation identifier, no screenshot, and no view of what was on screen. The app attaches no IP address to a report — though because the report is sent from your phone, Sentry’s servers see your device’s address when it connects, the way any service you send data to does.

Crash reporting is not switched on in development builds — only in the app you install from the store. Because there is no identifier in a report, there is nothing to switch off per person and nothing to delete on request; what protects you is that the report contains nothing about you in the first place.

Error reports from our server — running today. Separately, when our server hits a bug while handling a request, it sends the technical details of that failure to the same service. Your coordinate, your search text, and the request itself — including the headers that carry your IP address — are stripped before it is sent. The detail is under “What we keep” below.

Performance and reliability measurement — not yet. Counts and timings showing whether requests are succeeding and how quickly the service responds. These would be measurements of the service in aggregate, not a record of you, and they would carry no location as a label or dimension.

How an installation arrived — not yet. If you install Skewt after following a link or a campaign, the app store may tell us which campaign, link, or source it came from. This tells us which channels are worth continuing; it does not tell us who you are, and it is not joined to the locations you look at.

Where this stands today. Crash reporting is live, on both sides, as described above. Performance measurement and install attribution are not: as of the date at the top of this policy the app and server ship no such component, and no timing, counter, or attribution data is collected. When either is in place we will name the services involved in “Who else sees your data” below and update the app’s Play Data safety declaration to match it, before the change reaches you.

What has not changed, and is not going to as part of this: we still keep no history of the places you look at, we still build no profile of you, and none of the above is sold or handed to data brokers.

Using your device’s location

The app can fill in your current location when you tap the “use my location” control. That is the only thing the location permission is used for:

  • The permission is requested when you tap that control, never at launch, and the app works fully without it — you can pan the map or search for a place instead.
  • The coordinate is rounded to two decimal places before it is sent to our server. On the server it is used only to fetch that one sounding.
  • The app does not track you in the background and does not watch your location while it is closed: it reads your position once, when you tap the control. There is no continuous or repeating location request anywhere in the app. A location enters the on-device recent list only when you tap Save and show. Using a location once does not add it to Saved or Recent.

What we keep

On our server: no record of you. Your coordinate is used to fetch the sounding for that request and then discarded. There is no database, no user record, and no history of requested locations — nothing that could be assembled into a picture of where you look. The three things that do exist for a short while are described next, and none of them is a record of you: an operational log line when something fails, an error report when the server hits a bug, and an in-memory abuse counter.

Our operational logs record failures — that an upstream weather service was unreachable and what kind of failure it was, or that a sounding calculation was skipped. They contain no coordinates, no search text, and no IP addresses, and that is enforced by tests rather than by review (backend/tests/test_log_privacy.py).

When the server hits an unexpected error while handling a request — a bug on our side, rather than a weather service being unavailable — it sends a report of that error to Sentry, an error-tracking service, so that we find out about it and can fix it. The report describes the failure, not the request: the type of exception, the stack trace through our own code, and which route was being served. Everything the request itself carried is taken out before the report leaves our server — the query string, the request body, cookies, and the request headers (which carry your IP address) are dropped whole, coordinates, place-name search text and our own upstream API keys are redacted from every remaining piece of text (including the ones buried inside chained error messages), and the local variables of each stack frame, where a coordinate would otherwise sit, are removed. As with the logs, this is enforced by tests rather than by review (backend/tests/test_sentry.py). Reporting is active only on our deployed server.

To stop abuse, the server counts recent requests per IP address in memory only. A counter stops counting after a minute and is deleted the next time the server handles a request — so on an idle server the last one can sit in memory until that next request arrives. It is never written to disk, never logged, and never joined to a coordinate or to anything else about the request, and it disappears entirely when the server process is recycled.

On your device: your own lists. Locations for which you tap Save and show, and up to twelve such recent saves, are stored in the app’s private storage on your phone so they are there next time. Locations used without saving are not added to either list. The lists themselves are never uploaded — no network call sends your saved or recent locations as a list, so we never receive your location history or learn how many places you have saved.

The app also stores the start time, elapsed time, and last clock reading for its 14-day free trial. These three numbers contain no location or device identifier and are never sent to us. They remain in the same private app storage as your settings and location lists.

What is sent is the single location you are currently looking at. Opening a saved or recent entry fetches its sounding, and when the app starts it reopens the most recently saved place, which fetches that one — so the coordinate of a stored location is sent, rounded to two decimal places, at the moment you view it, exactly as if you had just picked it. Over time our server therefore sees the places you look at as a stream of one-off, unlinked requests; what it never receives is the stored list itself, and it keeps none of them (see below).

There is one caveat, and it is worth being straightforward about because it is easy to assume otherwise. If you have your device’s own backup switched on, the platform — not Skewt — includes the app’s private storage in that backup, so a copy of your saved and recent locations can be uploaded to your platform account and restored onto a new device or after you reinstall the app.

On Android, that is Android Auto Backup, and the copy goes to your Google account. On iOS, the same list is kept in the system preferences store, which your iPhone or iPad includes in a device or iCloud backup, and the copy goes to your Apple account.

Either way the backup belongs to you and to the platform, not to us: it is made to your own account under that platform’s terms, and we cannot reach it or read it. On Android 9 and later it is encrypted with your device’s PIN, pattern, or password, which means Google cannot read it either; an iCloud backup is encrypted in Apple’s custody, and switching on Advanced Data Protection makes it end-to-end encrypted so that Apple cannot read it either. You control it in your device settings — Settings → Google → Backup on Android, Settings → [your name] → iCloud on iOS — where you can switch it off and delete a backup that already exists.

Whichever platform you are on, what a backup can contain is the same coarse ~1 km coordinates the app stores — from the first time the app reads each list. The recent list is normalised at launch; the saved list is normalised the first time you open the location picker, so a backup made before that first picker open may contain saved locations at their original precision.

Who else sees your data

ServiceWhat it receivesWhy
Amazon Web Services (AWS Lambda, US East region)Our server runs here, so AWS necessarily handles the requests it processes, including the coordinate in transit and your IP address as the caller.Hosting.
Open-MeteoThe rounded coordinate, or the place name you typed. It is sent by our server, not your phone — so Open-Meteo sees our server’s address, not yours, and cannot connect the request to you or to your other requests.Forecast soundings and place-name lookup.
Iowa Environmental MesonetThe identifier of a weather-balloon station and a range of times. Not your coordinate. Stations are typically many tens of kilometres apart, and the request comes from our server, not your phone.Real observed soundings.
Sentry (Functional Software, Inc.)Technical details of failures, from two places. From your phone: a crash report — the error and stack trace, app and Android version, device model and state, and which endpoints were called. Because that report goes straight from your phone rather than through our server, Sentry also sees your device’s IP address as network metadata; the app attaches none, but the connection itself reveals it, as it does to any service you send data to. From our server: the exception type, the stack trace through our code, and the route being served — sent by our server, so your address is not involved. In neither case a coordinate, your search text, or the request itself: those are stripped first (see “Diagnostics, crash reporting, and attribution” and “What we keep”). No account, advertising, session, or installation identifier is attached to either. Sentry’s privacy policy: https://sentry.io/privacy/Finding and fixing crashes and server-side bugs.
MapboxYour device’s IP address, the map tiles fetched while the picker is open, and an SDK-level count of how many times the map widget was created. When you use GPS, tap an unnamed map point, or reopen a saved location that has no name, our server sends the coordinate rounded to two decimal places to Mapbox to resolve a city or locality name. Map tiles also reveal which region you are browsing. Mapbox’s privacy policy: https://www.mapbox.com/legal/privacyThe map you pick locations on.

We do not sell your data, and we do not share it with advertisers or data brokers. Everyone in the table above is a service provider handling data on our behalf, under our instructions, for the purpose named beside them — not for its own advertising. Any measurement or attribution provider we later use will be listed in the table above once it is in place.

Security

Traffic between the app and our server is encrypted with HTTPS.

Children

Skewt is a tool for pilots, forecasters, and weather enthusiasts. It is not directed at children and we do not knowingly collect anything from children.

Your choices and your rights

There is no account to close, and we hold no archive of the places you have looked at — on that, a deletion request has nothing on our side to act on. If diagnostic or crash data relating to you is ever held and you want it erased, write to the address at the end of this policy and we will deal with it.

What exists is on your phone, and you control it there:

  • Saved locations can be removed one at a time in the app: open the location picker, select a saved place, and tap Remove saved location.
  • Recent locations cannot be deleted individually in the app today. The list keeps only the last twelve, so older entries fall off it as you use the app. To clear it outright, clear the app’s storage from your device settings (on Android: Settings → Apps → Skewt → Storage → Clear data) or uninstall the app.
  • An Android backup made earlier is separate. Clearing the app’s storage and uninstalling both act on the copy that is on the device now; neither deletes a device backup that already holds these lists, so with device backup on a reinstall can bring them back. Delete the backup itself in Settings → Google → Backup, or switch device backup off there first.

You can withdraw the location permission at any time in your device settings, and the app will keep working without it.

Changes

If this policy changes, the date at the top changes with it. Material changes will be noted in the app’s release notes.

Contact

Questions about this policy: privacy@42nddesign.com
42nd Design — publisher of Skewt.