Location: a forecast request and a movement record

Checking tomorrow's weather for Groningen tells a server something different from repeatedly uploading your phone's current GPS coordinates. A selected town is not proof of where you are. A sequence of precise coordinates, times, speed and heading describes movement much more closely.

Ask these questions about a location field

• Did you select a place, or did the app read the device's position?
• Is the value a town, rounded position or precise coordinate?
• Is it sent once when you request a service, or repeatedly in the background?
• Is it attached to a persistent installation, session or account identifier?
• Is the purpose a forecast, navigation, warning, analytics or marketing?

What we found

In Buienradar, the audit traces a background location upload containing latitude, longitude and the Swrve user ID. The default tracking control retains it; a separate option removes it at the cost of weather alerts.

In Flitsmeister, the FCD path collects GPS batches with timing, speed, heading and session identifiers. The tracking patch stops its startup, timer and upload. Live CITS connected-warning location exchange remains. These paths have different roles and are documented separately.

These findings come from the app-specific audits, not a general assumption that every location-enabled app sends every field.

What can remain after patching?

Maps and routing can still need location requests. Weather alerts can require notification registration and requested places. A server normally sees the network IP address of the connection reaching it. Retaining a service can therefore retain data exposure even if optional analytics is removed.

The app pages say which exchanges remain and which have not been classified confidently. A patch name does not establish that location never leaves your phone. Evidence and limits.