Finding “the nearest one” without ever sending location to a server
Sending location to the server is the easy path. Not sending it is an architectural decision rather than a line of code — and the bill is downloading the entire province list.
The standard shape of a “nearest pharmacy” feature is this: the device sends its coordinates to the server, and the server returns the list sorted by distance. Simple, fast, what everybody does.
Eczanow does not do that. When location permission is granted, the coordinates are sent nowhere: the pharmacy list for the selected province is downloaded to the device and the sorting happens inside the phone. The server never learns where anyone is.
Why
A pharmacy finder has no need to know where anyone is. Sending location to the server creates data that then has to be stored, disclosed and defended — for no benefit at all.
The “no benefit” part matters. The only thing collecting and keeping location adds to the product is the server’s ability to do the sorting. But the phone can do that sorting too; it is a few hundred distance calculations, not a measurable load on a modern device.
All that is left is a difference in where the data sits.
The cost: computing distance on the device means downloading the entire province list. You cannot ask the server for “I am here, give me the nearest five”.
Why it is affordable: a single province’s list is small enough, and it is cached anyway. The user picks a province once and the list refreshes daily.
⚠️ This trade does not hold for every product. With hundreds of thousands of records, or data that changes by the minute, the arithmetic reverses.
The payoff is not only privacy
The most concrete return on this decision shows up in the store forms. Play’s Data safety section asks whether you collect location, and your answer has to match your published privacy policy exactly; a contradiction is treated as a violation.
When location is never collected:
- The declaration is short and defensible — “we do not collect it” is a far easier sentence than “we collect it but protect it like this”.
- Retention periods, deletion requests and third-party transfer questions all fall out of scope.
- The odds of a future release contradicting the policy drop: data that is never collected cannot be logged by accident.
That third point looks small and is in practice the most valuable one. Data you do collect can quietly end up somewhere else through a log line somebody adds while debugging. Data you never collect does not carry that risk.
The product’s second country keeps the same decision
The app also runs in Germany, where the logic differs: instead of a duty roster, pharmacy opening hours are interpreted and each card gets an open / closed / unknown badge. But the location side does not change — distance is still computed on the device.
That is exactly where the worth of a privacy decision gets measured: if it stops being negotiable as the product grows, it was a decision; otherwise it was a preference.
What to take from it
- “Let the server do it” is a choice, not a default. Where the computation happens should follow from what the product needs, not from habit.
- You do not have to protect data you never collect. The cheapest security control is the data not existing.
- Privacy decisions get cashed in on store forms. A short declaration is easier both to fill in and to defend.
- Write the trade down explicitly. Here the cost is downloading a whole province list; without that note, somebody asks six months later why we do not just request one record.
Eczanow