Privacy Policy
Last updated: 2026-09-27 (added contact records in §3.10, with the matching changes in §4, §5, §7, §10 and §12)
Squawkr, by RW 03 AB · Version 1.1 · Effective date: 2026-09-27
Squawkr tells pilots where a restriction area is and its current status, and what the weather conditions are at the airfield. This requires minimal personal data, as set out below.
The short version
- We hold your email address if you joined the early-access list or created an account.
- We store a random identifier on your device from the moment you first open the app. It is not linked to your name (§6).
- We record what you opened — an airfield code, an area designator, a rough region of the map — never where you are, never a trail of where you have been.
- We count how often each place is opened, across everyone, to run and improve the service (§3.5). We do not build a profile of how you use the app.
- If we are in touch with you, as a user or as a club, partner or journalist, we keep a contact record with your details and notes of our conversations (§3.10). It never includes what you open in the app.
- We do not sell anything about you, run advertising, or put a third-party tracker on any page.
- Your device fetches map tiles and satellite imagery directly from third parties (§3.8).
1. Data controller
RW 03 AB (org. nr 559537-8331), Björngränd 4, 621 57 Visby, Sweden, is the data
controller for everything described here.
Contact for anything in this notice, including exercising your rights: privacy@squawkr.net.
We are a small company and we are not required to appoint a Data Protection Officer, so we have not. Daniel Freeman answers privacy mail personally.
2. Outbound data
- Requests to our own API (
api.squawkr.net/api.squawkr.se) carry what you asked for — an airfield, a map area — and, once you have an account, your authentication token (§3.2). Our servers see your IP address in order to respond, and do not store it. - Aviation data sources are never contacted by your device. LFV, aviationweather.gov and the rest are fetched by our server and cached. They do not see you at all.
- Map tiles and satellite imagery are contacted by your device directly. Those two providers see your IP address and which tiles you requested (§3.8).
- The signup form additionally loads Cloudflare Turnstile, the bot check (§3.7).
3. Data we collect
3.1 Early-access list
If you enter your email address on our website:
| We store | Why |
|---|---|
| Your email address, normalised (trimmed, lowercased) | to send the early-access updates and launch notification you signed up for |
| The exact consent wording you were shown, in the language you were shown it in | so we can demonstrate what you agreed to, rather than merely that you ticked something |
| The time you agreed | to record when consent was given, evidencing it alongside the wording above |
| Your language and the page you came from | so emails arrive in the right language, and so we can tell which page prompted the signup |
| A one-way hash of your confirmation link's token | so a leaked backup cannot be used to confirm or unsubscribe anyone |
We deliberately do not store your IP address, your name, or any tracking field alongside it.
Double opt-in. We email you a confirmation link. If you never click it, your row is deleted automatically when the link expires after seven days — someone who never clicked never consented, so there is no basis to keep holding their address.
What we use it for, precisely, is what the consent sentence says: occasional updates on how Squawkr is coming along, and an email when early access opens. The list is also the seed of the account system: when accounts open, someone on the list who registers with the same address becomes an account holder without re-entering anything. If you never register, your row stays a mailing-list row and nothing else.
3.2 Account data
When accounts open, an account holds:
| We store | Why |
|---|---|
| Your email address | it is how you sign in, and it is the contact channel |
| An optional display name | only if you choose to add one; you can change or remove it at any time, and we ask for nothing else |
| Your language preference | so the emails we send you, and the sign-in page, are in the language you read the app in |
| Session records and an authentication token stored on your device | to keep you signed in — necessary for the service, issued only once you sign in |
| Single-use sign-in link tokens (stored hashed), with a short expiry | passwordless sign-in |
| Account creation and last sign-in times | to run the service and to count active accounts |
| A link between your account and the device identifier in §3.3 | so your free-view count and your account are the same account |
Sign-in is passwordless — a link sent by email — so we never hold a password. The only required field is your email address; a name is optional and yours to add, edit or clear.
An account is free. We ask for it because it gives us a way to reach you, an honest count of how many people actually use Squawkr, and — as the service evolves — a basis for personalisation features we may build later.
3.3 Device identifier
From the first time you open the app, before you have been asked anything, we generate a
random value and store it on your device (in localStorage, mirrored in IndexedDB because some
browsers evict the first after a week of not being used).
This identifier has three relevant properties:
- It is random. It is not derived from your IP address, browser, fonts, screen, or any other device characteristic — we do not fingerprint. A derived identifier could not be cleared by you and would be less reliable for us.
- It is personal data. It singles out one device, which is sufficient under GDPR, and we treat it as personal data throughout this notice.
- It serves two purposes, both described in §6.
You can delete it at any time by clearing site data for Squawkr in your browser, or by uninstalling the app. Doing so resets your free-view count in your favour, which we have decided is the harmless direction to be wrong in.
3.4 Usage data
When you use the app it sends us small usage events. Every event carries the device identifier, your account id if you have one, a session id, the app version, the territory, and a timestamp that our server assigns (not your device's clock).
Only a fixed list of event types is ever recorded — anything else is dropped. They record things like: the app was opened; an area was viewed, with its designator and whether it was active, scheduled or neither; a schedule was opened; an airfield or its weather was viewed; the map moved to a coarse region; we had to tell you we have no data for where you are; we had to show you data older than we would like; a source failed; and each step of registration.
Two specific points:
- Map position is stored as a coarse geohash — roughly 150 km squares — and at most once every 30 seconds. That is enough to say "people are looking at Stockholm" and not enough to say where anyone was standing.
- Searches that returned nothing are stored as text, normalised and truncated to 32 characters, for 30 days. This is the only free text we keep, and it is here because a search that found nothing is a coverage gap described in your own words, which is how we decide which country to cover next. Searches that found something record only what you chose, never what you typed.
We do not store your coordinates and we do not build a movement history.
3.5 Aggregate statistics
We combine the events in §3.4 across all users into statistics about places and times — for example, how many devices opened a given airfield, at what hours of what days, and how that number moves through a season. These statistics are used only to run and improve the service.
- The inputs are usage records from everybody.
- The outputs are about places and times, not about people.
- We rely on our legitimate interest to do this (§5). You can ask us to explain, correct or delete this data at any time — see your rights in §10.
- Daily counts per airfield or area carry no device or account identifier, are not personal data, and are kept indefinitely. The device-linked records in §3.4 have a much shorter retention (§7).
3.6 Correspondence
If you email support, or use the in-app "report a problem" form, we hold what you sent — including any email address you gave us so we could reply, and the technical context the form attaches automatically. That context is:
| Attached to a problem report | Why |
|---|---|
| The app version and build you were running | so we can tell whether the problem was already fixed |
| Which area or airfield you were looking at, by its name or code — never a position | it is what your report is about |
| The status we were showing you, and the activation times we were showing you | it is the claim you are disputing, and the thing we have to check |
| When we last fetched that data, and how old it was | it separates "we were wrong" from "we were out of date and said so" |
| Which source the data came from, and which time zone we showed it in | so we can find the fault |
| A short excerpt (at most 8 KB) of the data we actually sent your app | published aviation data changes and disappears; without a copy of what we showed you, a safety report cannot be checked more than a day later |
| Whether your device was online, whether you were using the installed app, and which browser family it is | some faults only happen in one of those |
| The device identifier from §3.3, so the report can be matched to the technical error record |
We do not attach your location or coordinates, your IP address, a screenshot, or a log of your device's activity. There is nowhere in our system to put any of them.
The report is stored in our own database first, and a copy is emailed to our support mailbox so we can work on it and reply to you. Replies are ordinary email between you and us.
Data-accuracy reports are safety-relevant; we keep the substance of confirmed ones in our own notes so that the same mistake is not made twice, without the reporter's contact details attached.
3.7 Security and abuse prevention
Cloudflare serves every request and sees your IP address in order to do so. Our systems do not store or register your IP address. We derive only your country from the connection, so that we can say which territories people are asking for coverage in.
The signup form runs Cloudflare Turnstile, a bot check. Your browser loads it from Cloudflare, which means Cloudflare sees the request. Turnstile is used because a public form with no bot check is found and abused, and it is preferred over storing IP addresses and building rate-limit histories against them.
3.8 Third-party requests
- Map tiles come from
tile.openstreetmap.org, operated by the OpenStreetMap Foundation. - Satellite imagery comes from
server.arcgisonline.com, operated by Esri.
In both cases your browser makes the request, so both providers see your IP address and which tiles or which airfield view you asked for. We do not send them anything else, and they are not acting on our instructions — they are separate services your device is talking to. Their own terms and privacy notices apply to those requests.
3.9 Pre-authentication cookie
Our website stores a single small cookie, squawkr_lang, for a year. It holds only the
language you last chose — English or Swedish — so the right one loads next time. It carries no
identifier and is not used to recognise or track you. We set no other cookies: no session
cookie, no advertising, analytics or third-party cookies. Sign-in uses an authentication token
stored in your browser's local storage (§3.2), not a cookie, and the device identifier in §3.3
is stored the same way.
3.10 Contact records
We keep a contact record for each person we are in touch with, so that we can follow up and know who we are talking to.
| We store | Where it comes from |
|---|---|
| Your name, email address, phone number, organisation and role | You, or what your organisation publishes on its own website or in a public club directory |
| Your stage between signing up and having an account, such as "confirmed signup" or "account created" | We derive it from §3.1 and §3.2 and do not store it twice |
| Notes of our conversations with you, and a date to follow up | Us |
The record never includes what you open in the app, how often you use it, your device identifier or your free-view count (§3.3, §3.4). Usage stays aggregate-only (§3.5).
We keep the record in our EU database (§9). We also keep a working copy in a CRM that we run ourselves, on our own server in the EU. No third-party CRM service holds it.
4. Data we do not collect
- No coordinates or movement history. Places are recorded as the named thing you opened, not where you were standing.
- No stored IP addresses. Cloudflare sees your IP address to deliver the page; our systems do not store or register it. We derive only your country from it.
- No fingerprinting. The identifier is one we mint, not one we derive from your device.
- No third-party analytics, advertising, session recording or heatmapping. The whole pipeline is ours.
- No search text, except the one 30-day exception in §3.4.
- Email address only, mandatorily. We do not currently require your name, phone number or address — an optional display name (§3.2) is the only other thing we ask for.
- No individual usage dashboards. Nothing shows one person's history in the app. The contact record in §3.10 holds how to reach you and our conversations, not what you did in the app.
5. Legal basis
| What | Basis under GDPR Art. 6 |
|---|---|
| Email list and the emails we send you | Consent, Art. 6(1)(a), and Swedish marketing law for email marketing. You can withdraw it at any time; withdrawal does not affect what we sent before. |
| Storing the consent wording and timestamp | Legal obligation / accountability, Art. 6(1)(c) with Art. 7(1) — we have to be able to show what you agreed to |
| Your account, sign-in and sessions | Contract, Art. 6(1)(b) — you asked for an account and we provide it |
| Storing and reading the device identifier on your device | Strictly necessary for a service you requested under the Swedish Electronic Communications Act (implementing the ePrivacy Directive), because it is how the free-view allowance works — see §6. As personal data, Art. 6(1)(b) for enforcing that allowance. |
| Usage events and how we analyse them | Legitimate interest, Art. 6(1)(f): understanding whether the service works and where it is needed |
| Aggregate statistics | Legitimate interest, Art. 6(1)(f), and a compatible further purpose under Art. 6(4) — the output is aggregated and statistical. You can object under Art. 21 — see §10. |
| A problem report you send us, and the technical context attached to it | Legitimate interest, Art. 6(1)(f) — you asked us to look at something and we cannot without it. For a report that the app told you something untrue about airspace, also our interest, and yours, in the safety of a service pilots rely on |
| Keeping a confirmed safety finding after erasing who reported it | Legitimate interest, Art. 6(1)(f) — once anonymised it is no longer about you, and it is what stops us repeating a mistake that could put someone in active airspace |
| Technical error records from the app (§8, Sentry) | Legitimate interest, Art. 6(1)(f) — finding faults that nobody reports. It carries no contact detail and no location |
| Bot protection, rate limiting, security | Legitimate interest, Art. 6(1)(f) |
| Keeping an unsubscribed address on a suppression list | Legitimate interest, Art. 6(1)(f) — so that we do not email you again by accident. See §7. |
| Contact records (§3.10), including details we took from an organisation's own website | Legitimate interest, Art. 6(1)(f). We need to know who we are talking to, and we tell flying clubs and aviation organisations about a service built for their members. We write to the addresses an organisation publishes for contact. We never add anyone to our mailing list (§3.1) without their consent. You can object at any time (§10). |
| Personalisation features (not built today) | Not yet applicable. Before any such feature ships we will name its basis here — most likely Consent, Art. 6(1)(a), since personalising to an individual is a different purpose than the aggregate, legitimate-interest use above and needs its own footing. |
Where we rely on legitimate interest we have weighed it against your interests, and the design reflects the outcome: no fingerprinting, no coordinates, no third parties, no individual profiles, aggregate-only output. You can object to any legitimate-interest processing by deleting your account or your device data — see §10.
6. Device identifier and cookie exemption
The identifier has two jobs: gating the free-view allowance, and letting us count devices rather than page loads for usage statistics.
No banner, because of job 1. EU/Swedish ePrivacy rules require consent to store or read information on your device unless it is strictly necessary for a service you explicitly requested. Gating the free view is exactly that, so storing the identifier is exempt.
Job 2 runs on a different basis. Counting usage isn't covered by that exemption — it relies on legitimate interest (§5) instead. There is no separate control for turning job 2 off on its own; objecting to it means deleting your account or your device data (§10), which stops both.
Risk. Job 1 is clearly exempt. Job 2 uses the same identifier, and a regulator could decide that sharing it this way isn't allowed — meaning job 2 would need its own consent step. If that happens, we will add one.
7. Retention
| Data | Kept for |
|---|---|
| Unconfirmed early-access signup | Until the seven-day confirmation link expires, then deleted automatically by a daily job |
| Confirmed early-access subscriber | Until you unsubscribe or ask us to erase you |
| An unsubscribed address | Kept as a suppression record, so that a later import cannot email you again. Not used for anything else. Ask us to erase you and it goes entirely — see §10. |
| Consent wording and timestamp | For as long as we hold the row it belongs to |
| Account and profile (including the optional name) | While the account exists. When you close it, deleted immediately — there is no grace period — and we email you to confirm it is gone |
| Session and sign-in link records | Sessions until they expire or you sign out; sign-in links are single-use and short-lived |
| Device identifier and the one row per device per active day | While the device is active, then 24 months |
| Usage events | 90 days, in a database we can and do delete from on request |
| Zero-result search text | 30 days |
| Aggregate daily counts per airfield or area (no device or account identifier) | Indefinitely — they are not about you and cannot be traced back to you |
| Support email and problem reports — what you wrote, and the technical context in §3.6 | 24 months, then the text is deleted and only the classification remains |
| An email address you gave with an anonymous problem report | Deleted 90 days after the thread is closed. The report itself remains, with your address and every identifier stripped from it — see below |
| Rate-limiting counters (so one device cannot flood the report form) | 48 hours |
| A contact record for a user (§3.10) | We delete it with your account, or when you ask us to erase your signup. We delete it from our database and from our own CRM copy. |
| A contact record for someone who is not a user, such as a club official, partner or journalist | We review it every year. We delete it after 24 months without contact, or at once if you ask. |
Why these numbers (recommended levels). Retention is set to the shortest window that still does the job, per GDPR storage-limitation:
- Support & problem reports — 24 months. Long enough to recognise a problem that recurs across seasons and to answer a follow-up from the same person; short enough not to become an archive of correspondence. (Matches the 24-month tail a comparable Gotland SaaS, Scopes, uses.)
- A safety report outlives the correspondence about it, without outliving your privacy. If you told us we showed you something untrue about airspace, and we confirmed it, that is a fact about our data rather than about you. So when you ask us to erase you — or when the 90-day clock runs out on an anonymous report — we anonymise that report instead of deleting it: your address and every identifier are removed, and the finding stays, so we do not make the same mistake twice. Every other kind of report from you is deleted outright, along with the whole message thread.
- Usage events — 90 days, then only aggregates. The raw per-view rows are deletable and short-lived; what persists indefinitely is non-identifying daily counts per airfield/area that cannot be traced to a device or person.
- Device identifier & one-row-per-active-day — 24 months. Covers a full year-over-year comparison with margin, then the device ages out.
- Account & profile — deleted immediately on close, no grace period; early-access address — until you unsubscribe or erase, then only a minimal suppression record so a later import cannot re-mail you.
8. Processors
We use as few suppliers as possible, and each one is under a data-processing agreement.
| Supplier | What they do | Where |
|---|---|---|
| Cloudflare (Cloudflare, Inc., US, and Cloudflare's EU entity) | Hosting and infrastructure, including the databases holding your account and usage data | Data pinned to the EU — see §9 |
| Resend (Resend, Inc., US) | Sending account, support and mailing-list emails | Sent via an EU region; stored in the US — see §9 |
| Sentry (Functional Software, Inc., US) | Records technical errors in the app — the equivalent of a crash report — so we can find faults nobody reports | An EU-region project; see §9. It receives the error, the code it happened in, your browser and app version, and the device identifier from §3.3 — never your email address, your account, or any location. Session recording and screen replay are switched off, and it is not loaded at all unless it is switched on for the build you are running |
| Google (Google Ireland Limited, with Google LLC, US) | Hosts the support mailbox that receives problem reports and the correspondence that follows (§3.6) | Google Workspace; see §9. It holds whatever the message contains — what you wrote, the technical context §3.6 lists, and your address if you gave one — for as long as §7 says |
They act on our instructions and may not use your data for their own purposes. We use no third-party analytics provider — Sentry is an error tracker, not an analytics one, and it is configured with performance tracing and session replay disabled.
The OpenStreetMap Foundation and Esri (§3.8) are not processors for us — your device contacts them directly, and their own terms govern those requests.
9. International transfers
- Your email address, your account and your usage data are held in the EU by design, under Cloudflare's EU data-locality guarantee.
- Cloudflare, Inc. is nonetheless a US company, so residual US access cannot be ruled out. That risk is covered by Cloudflare's data processing addendum, which relies primarily on its EU–U.S. Data Privacy Framework certification (with the Swiss–U.S. DPF and UK extension), falling back to the EU Standard Contractual Clauses if that certification ever lapses.
- Resend routes and sends our mail via its EU region, but stores account and message data — including delivery logs — in the United States. That transfer is covered by Standard Contractual Clauses in Resend's data processing agreement, alongside Resend's own EU–U.S. Data Privacy Framework certification.
- Sentry is configured as an EU-region project, so error records are stored in the European Union. Sentry's own company is US-based, so residual US access cannot be ruled out; that is covered by Standard Contractual Clauses in its data processing agreement.
- Google hosts our support mailbox, so a problem report you send us — and any reply — is stored in Google Workspace. Our agreement is with Google Ireland Limited, but Google LLC in the United States may access the data in the course of providing the service. That transfer is covered by the Standard Contractual Clauses in Google's data processing agreement, alongside Google LLC's EU–U.S. Data Privacy Framework certification.
10. Your rights
Under GDPR you can ask us to:
- Tell you what we hold about you, and give you a copy (Art. 15).
- Correct anything wrong (Art. 16).
- Delete it (Art. 17).
- Restrict what we do with it while something is being sorted out (Art. 18).
- Give you a portable copy of what you gave us (Art. 20).
- Object, where we rely on legitimate interest — including the usage data and the aggregate statistics in §3.5 (Art. 21). We do this by deleting your account or your device data; there is no separate setting that stops it while leaving the account active.
- Withdraw consent for the mailing list, at any time, without giving a reason (Art. 7(3)).
Write to privacy@squawkr.net. We answer within one month, and will ask you to confirm you control the email address in question before we act on your request.
Unsubscribing and erasure are different things, on purpose. Unsubscribing stops the email and keeps a suppression record so we cannot accidentally mail you again. Erasure deletes everything, including the suppression record — which also means that if you sign up again afterwards, nothing remembers that you once left.
Erasure reaches your usage data. Your usage events are held in our own EU database, not in a system we cannot delete from, so an erasure request is honoured in full. If you ask us to erase you — or close your account, which does the same thing — we immediately delete your account, your optional name, your subscriber row, your device rows, your usage events and your membership of the day-by-day roll-ups. Closing your account is a direct deletion with no grace period, and we email you to confirm it has happened. The only thing that survives is the anonymous daily counts per airfield or area (§3.5), which carry no identifier and cannot be traced back to you.
Limitation. If you have used the app anonymously and never created an account, your device identifier is not connected to your name or your address, and we have no way to find out which one is yours. We cannot answer an access or erasure request about it, because we cannot verify it is yours and we cannot look it up. What you can do is clear the app's site data or uninstall it, which deletes the identifier from your device.
If we found your details ourselves. You may hold a role at a flying club or an aviation organisation. If so, we may have taken your name and role from what that organisation publishes on its own website or in a public club directory. We use them only to contact the organisation about Squawkr. To stop this, reply to any email from us or write to privacy@squawkr.net. We will delete the record, or keep a do-not-contact note if you want us never to write again.
Complaints. If you think we have got this wrong, you can complain to the Swedish Authority for Privacy Protection — Integritetsskyddsmyndigheten (IMY), imy.se — or to the supervisory authority where you live. We would appreciate the chance to fix it first.
11. Children
Squawkr is for people who fly aircraft or operate drones, and it is not aimed at children. You must be 16 or older to create an account or join the mailing list. If you are under 18, ask whoever is responsible for you before you sign up for anything that costs money. If you believe a child has given us their details, write to privacy@squawkr.net and we will delete them.
12. Automated decisions and profiling
We do not make any decision about you by automated means that has a legal or similarly significant effect. We do not build a profile of how you use the app. If we introduce personalisation features that would, we will update this notice first, rely on an appropriate legal basis — most likely consent (§5) — and tell you before it applies to you. The only thing currently counted against your device is its non-registered usage.
13. Security
Sign-in link tokens and confirmation tokens are stored only as one-way hashes, so a leaked database copy cannot be used to confirm, unsubscribe or sign in as anybody. Confirmation links are single-use and expire in seven days. Everything travels over HTTPS. We collect as little as possible in the first place, which is the security measure that works even when the others fail.
If a breach happens that puts you at risk, we will tell IMY within 72 hours and tell you without undue delay.
14. Amendments
We will change this as Squawkr changes — features described here before they exist will get more specific as they ship.
- Every version carries a date and a version number at the top.
- Material changes — a new purpose, a new category of data, a new recipient — are announced before they take effect: by email to everyone on the list or with an account, and with a notice in the app, at least 14 days ahead.
- Wording and clarity fixes are made as we notice them, and the date is updated.
- Previous versions are available on request.
15. Contact
RW 03 AB · org. nr 559537-8331 · Björngränd 4, 621 57 Visby, Sweden
privacy@squawkr.net
Related documents: User Terms · Service Terms