Alby96/Europa
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Narrow scope to radar, and put the app on a real OpenStreetMap base map

Browse Source 
Drops forecasts, lightning, the home-screen widget and advertising. What
remains is radar on a map, the official ARPA alert bulletin, and rain
notifications.

The base map is now OpenFreeMap's Positron style: real OpenStreetMap vector
tiles with no API key, no registration, no request limits and commercial use
permitted. Every other free tier — MapTiler, Stadia, Jawg, Thunderforest —
needs a key, which is a secret to manage, a quota to outgrow and a signup to
complete before anyone can build the project, and the map is the one thing the
app cannot work without. Positron rather than Liberty or Bright because the
radar overlay has to be the loudest thing on screen, and a desaturated grey
base is built to sit under data.

Its style JSON carries no `attribution` field, so MapLibre displays no credits
by itself. The app renders them from the region config instead: the two
mandatory credits, OpenStreetMap and OpenMapTiles, go in the always-visible
bar, and OpenFreeMap's own credit — optional by their terms — is listed on the
Sources screen with the rest. The bundled offline style is still reachable with
MAP_STYLE_URL=offline, and still claims no base map attribution, because
crediting OpenStreetMap while showing it would be a false claim.

Radar-DPC stays the source. ARPA Piemonte's own radar remains a disabled stub
for two reasons that belong to the project owner, not to the code: the
real-time access link is only issued by email, and the open-data page states
the data is "gratuiti" and nothing else. Free of charge is not a licence, and
rendering those volumes into frames served from a CDN is redistribution. Both
questions go in the same email. An earlier draft of the docs recorded ARPA
radar as CC BY 4.0; the source page does not support that, so the claim is
removed rather than carried forward.

The documentation is updated throughout rather than annotated: CLAUDE.md gains
an explicit scope boundary, data-sources drops MET Norway and ISTAT and gains
the base map, licenses records that free of charge is not a licence, privacy
loses the whole advertising section, and the roadmap is renumbered so the
backend worker is next — until it exists, DpcRadarSource has nothing to read.

licenses.md keeps Open-Meteo and Blitzortung listed as excluded even though the
features that would have used them are gone: both are non-commercial-only, ads
are a plausible future, and neither should be adopted on the grounds that there
are none today.

Verified: analyze clean, 130 tests passing, and on the emulator the radar
overlay sits correctly over Piedmont on real OSM tiles with Turin, Milan and
Genoa labelled, the age reads "Aggiornato 4 minuti fa", and the Sources screen
lists all five credits with their licences.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Alby96
2026-09-10 16:10:29 +02:00
co-authored by Claude Opus 5
parent 91f9ac0fbf
commit f3a0e3794a
20 changed files with 430 additions and 350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Nuvolari/docs/privacy.md
+27 -28
View File
@@ -1,7 +1,7 @@
# Privacy design
This is the engineering note. The user-facing privacy policy is drafted in M9 and must
stay consistent with what is written here.
This is the engineering note. The user-facing privacy policy is drafted before release
and must stay consistent with what is written here.
## Principle
@@ -9,20 +9,22 @@ The backend holds no user data of any kind. There is no account, no device regis
no user table. This is not a policy promise — it is a property of the architecture,
and it is what makes the Data safety declaration simple and honest.
With advertising out of scope, there is currently **no third party that receives anything
about the user at all**. The only outbound requests are for map tiles and radar frames,
neither of which carries a user identity.
## Location
The device may ask for location permission to centre the map and to pick a forecast
point. When it does:
The device may ask for location permission to centre the map. When it does:
- **Prominent disclosure** is shown before the system permission dialog, stating what
the location is used for, as Google Play requires.
- The permission is optional. Declining leaves the app fully usable: the map opens on
the region centre from the region config and the forecast point is chosen manually.
- The coordinates stay on the device. They are used to render the map and to build the
MET Norway request, and are never sent to our backend.
the region centre from the region config.
- The coordinates stay on the device. They are used to position the map and nothing
else, and are never sent to our backend.
MET Norway does receive coordinates — it cannot return a forecast otherwise. This is
disclosed on the Sources screen, and the coordinates are rounded before being sent.
There is no forecast provider, so no coordinates leave the device for one.
## Rain notifications without a server-side location
@@ -37,31 +39,28 @@ area, not a household.
**Never** replace this with device tokens registered against coordinates. It would be
simpler and it would destroy the property.
## Advertising and consent
AdMob is initialised only after the UMP consent flow completes:
- The consent form is shown before **any** ad request.
- Declining consent yields non-personalised ads. It never yields no app.
- The consent choice is revocable from the settings screen.
- A Google-certified CMP (UMP) is used, IAB TCF 2.3.
Only test ad unit IDs are used in development. Real IDs arrive through `env.json`,
which is git-ignored.
## Caching on the device
Radar frames and forecast responses are cached on disk under the app's private
directory. The cache holds published weather data only — no personal data — and is
cleared with the app.
Radar frames are cached in memory while the app runs. The cache holds published weather
imagery only — no personal data — and does not outlive the process.
## Third parties that receive data
## What each third party receives
| Party | What it receives | Why |
|---|---|---|
| MET Norway | rounded coordinates, User-Agent | to return a forecast |
| Google AdMob | ad request data per the consent choice | monetisation |
| Firebase Cloud Messaging | topic subscriptions (no coordinates) | rain notifications |
| OpenFreeMap | tile requests for the area being viewed | to draw the base map |
| Our CDN | frame and manifest requests | radar imagery |
| Firebase Cloud Messaging | topic subscriptions, no coordinates | rain notifications |
Map tile requests inevitably reveal roughly where the map is looking, to whoever serves
the tiles. That is inherent to any hosted base map; the alternative is self-hosting, which
is noted in [stack-decisions.md](stack-decisions.md) as the escape hatch if it ever
matters enough.
Our own backend receives nothing that identifies a user, by construction.
## Out of scope, and therefore absent
No advertising, no consent management platform, no IAB TCF, no ad identifiers, no
forecast provider. If advertising returns, this document and the privacy policy must be
revised **before** the SDK is added, not after.