Alby96andClaude Opus 5
f3a0e3794a
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>
2.9 KiB
Privacy design
This is the engineering note. The user-facing privacy policy is drafted before release and must stay consistent with what is written here.
Principle
The backend holds no user data of any kind. There is no account, no device registry, 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. 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.
- The coordinates stay on the device. They are used to position the map and nothing else, and are never sent to our backend.
There is no forecast provider, so no coordinates leave the device for one.
Rain notifications without a server-side location
The worker computes rain per geographic cell and publishes per-cell state. The device decides which cells it cares about and subscribes to the matching FCM topics itself.
The consequence is that the server never learns which cell any user is in — it publishes to topics, not to devices. There is nothing to correlate, nothing to subpoena, and nothing to breach. Cell size is coarse enough that a cell identifies an area, not a household.
Never replace this with device tokens registered against coordinates. It would be simpler and it would destroy the property.
Caching on the device
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.
What each third party receives
| Party | What it receives | Why |
|---|---|---|
| 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 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.