Alby96andClaude Opus 5
06ab816ebe
A saved place is a named point the user keeps: it frames the map now, and once the worker publishes station data it is what the nearest-station readings and, later, the rain notifications will hang off. Free points rather than stations, because people think in terms of home and work, not in terms of which weather station happens to represent them. Everything stays on the device. Places live in SharedPreferences under a versioned key, and there is no account to attach them to and no server that would accept them. That is what keeps the Data safety declaration able to say no location is collected, and it must survive the notification work: the device will subscribe to the topic for the cell containing a place, so the link between a person and a place never leaves their phone. Location is coarse only, and that took enforcing. geolocator declares ACCESS_FINE_LOCATION in its own manifest and the merger pulls it in, so the system dialog offered "Precise" despite the app asking for nothing of the sort; the manifest now removes it with tools:node="remove", and the dialog reads "approximate location" with no choice offered. Requests also go through the platform LocationManager rather than the Play Services fused provider, which prompts about Location Accuracy and, when declined, returns no fix at all — an absurd outcome for an app that only ever wanted an approximate one, and one that also tied location to Play Services being present. The prominent disclosure comes before the system dialog, as Play requires, and is repeated in Settings so someone who already answered can still read what the permission is for. Declining leaves the app fully usable. Two more defects found by running it and by a test: - MapLibreMap leaves cameraPosition null unless trackCameraPosition is set, so "save the map centre" silently saved the region default rather than what the user was looking at. - Place ids came straight from the microsecond clock, so two places saved in the same microsecond shared an id and rename, remove and the duplicate-name check all acted on the wrong one. A test caught it on a fast machine. Saving refuses points outside the region rather than accepting them: a place in Rome would look like it worked and then show nothing forever. Also corrects CLAUDE.md, which still said ARPA states no licence, and records the ARPA realtime API there with the property that governs how it may be used — it lags about 4.5 hours, so it is an observation archive and must never sit next to 5-minute radar looking current. Verified: analyze clean, 158 tests passing, and on the emulator the disclosure precedes the system dialog, the dialog asks only for approximate location, a place survives restart and reinstall, and tapping one moves the map onto it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.0 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 position is used to centre the map and, once the worker publishes station data, to pick the nearest measuring station. It is optional throughout.
Coarse only, and enforced
The app declares ACCESS_COARSE_LOCATION and nothing else. Stations are kilometres
apart and the map is looked at, not navigated by, so street-level precision would buy
nothing and cost a more invasive permission.
This takes active enforcement. The geolocator plugin declares
ACCESS_FINE_LOCATION in its own manifest, and the merger pulls it into ours. Left
alone the system dialog offers "Precise", Play Services nags about Location Accuracy,
and the Data safety form has to declare precise location — all for accuracy the app
never asks for. The app manifest therefore removes it explicitly:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
tools:node="remove"/>
Verified on a device: the system dialog reads "access this device's approximate location" and offers no Precise option. Do not add the fine permission back without a feature that genuinely needs it and a Data safety update to match.
No Play Services in the path
Location requests use the platform LocationManager
(AndroidSettings(forceLocationManager: true)) rather than the Google Play Services
fused provider. The fused provider prompts "your device will need to use Location
Accuracy", and declining it yields no fix at all — an absurd outcome for an app
that only ever wanted an approximate one. It also means location works on devices
without Play Services.
The permission flow
- A prominent disclosure is shown before the system dialog, as Google Play requires, stating what is used, why, and that it stays on the device. The same text is repeated in Settings so someone who already answered can still read it.
- Declining leaves the app fully usable: the map opens on the region centre and places are chosen by hand.
- The coordinates never leave the device.
Saved places
A saved place — a name and a point — is the closest thing this app has to a home
address. It is stored in SharedPreferences on the device only, under a versioned
key, and is never uploaded, backed up to our servers or shared. There is no account to
attach it to and no server that would accept it.
Places are what the rain notifications will eventually key off, and that must not change where the data lives: the device will subscribe to the topic for the cell containing the place, so the correspondence between a person and a place stays on their phone.
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.
Saved places are the only thing written to persistent storage, and only locally.
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.