Alby96andClaude Opus 5
b4b8d089e6
Puts the controls that change what the map is looking at over the map itself, where they act, and gives them something to search. Search is one field, not two. A string either parses as coordinates or it does not, and the answer is obvious from the text, so making the user declare up front which kind of thing they are looking for would be asking them to do the program's job. Coordinates accept decimal and degrees-minutes-seconds, comma or space separated, with hemisphere letters — including the Italian O for ovest, because someone reading an Italian map will type it and silently reading it as east would put them the wrong side of Greenwich. The 1180 Piedmont municipalities are bundled rather than geocoded online. The app is region-scoped, so a list of one region's towns is small enough to ship (100 KB) and beats a geocoder on every axis that matters: instant, offline, no API key, no rate limit, and it cannot return a result somewhere the app has no radar for. Matching folds accents, so "aglie" finds "Agliè", and prefix matches outrank substring ones — typing "tor" should surface Torino, not the first alphabetical name that happens to contain those letters. tool/generate_places.py derives the list from Istat boundary shapefiles (CC BY 4.0). Two properties of that file cost time and are now written down: the geometry is UTM 32N rather than degrees, and the DBF is UTF-8 despite one bilingual Friulian record that makes strict cp1252 fail. A terminal renders utf-8 and latin-1 output identically, so the encoding cannot be settled by looking at printed text — it took dumping codepoints. A guard in the generator and a test against the shipped asset both check for mojibake now, and the guard caught a real mistake the moment it was written. The target selector switches between following the device, a saved place, and the whole region, and the selection doubles as what the app reopens on: "the place I marked" and "what I see when I open the app" are one idea to the person using it. Dragging the map while it is following stops the camera chasing them but leaves that preference alone, because looking somewhere else now is not the same as changing their mind about next launch. The position marker and the following are MapLibre's own, driven by onCameraTrackingDismissed, so there is no second location stream to keep in step with the map. A test asserts that all 1180 municipalities fall inside the region bounds, which is what actually validates the UTM-to-degrees conversion end to end. Verified on the emulator: the dropdown lists follow, region and both saved places; "aglie" finds Agliè; "44.3841 7.5426" offers the coordinate jump and lands on Cuneo at town-reading zoom; selecting follow moves the map to the device position with the blue dot on it and changes the recentre button to match. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
122 lines
5.5 KiB
Markdown
122 lines
5.5 KiB
Markdown
# 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:
|
|
|
|
```xml
|
|
<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.
|
|
|
|
### Following, and continuous updates
|
|
|
|
Selecting "segui la mia posizione" hands tracking to the map's own location
|
|
component, which receives updates continuously while the app is in the
|
|
foreground. That is more than the single fix everything else needs, so it is
|
|
opt-in, it is visible — the chip at the top of the map says so — and it stops the
|
|
moment the user drags the map away.
|
|
|
|
It never runs in the background: there is no background location permission and
|
|
no foreground service, so closing the app ends it.
|
|
|
|
### 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](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.
|