Seven questions to ask any location-sharing app
Over the past two months, this series has walked through how Fenzly is designed: the encryption, the blind server, the backups, the business model. This post turns all of it into something you can carry with you: a short list of questions worth asking of any app before you trust it with your family’s movements.
They apply to ours too. For each one we’ve linked where we answer it, so you can hold us to the same standard.
1. Who can read my position?
Not “who does the company say reads it”, but who can. If your coordinates reach the company’s servers in readable form, then employees, attackers and courts all become possible readers, whatever the policy says. The strongest answer is end-to-end encryption, where only the people you chose can open what you share. That difference between a policy and a property is where we started the series: what end-to-end encryption actually means.
2. What does the server keep, and for how long?
Even with good encryption in transit, the question is what accumulates server-side. A position kept for a day is a convenience; a position kept for years is a diary of your life exposed to a breach, a legal request or a change of policy. Ask whether a location history exists on the company’s servers at all. Our answer is the blind server: sealed blobs, short expiries, no archive.
3. Does it need my address book?
“Allow access to contacts” often means your entire address book is uploaded, including everyone in it who never consented. There are ways to find friends without taking the list; ask which one your app uses. Ours is hash-based matching, and the contacts never leave your phone.
4. What happens if I lose my phone?
This one cuts in both directions. If the answer is “log in again and everything is back”, ask how: it usually means the company holds a readable copy of everything. If the answer is “everything is gone”, ask whether there’s a backup you control. Our trade-off is explicit: no master key exists, so backup is on you, and here’s how it works.
5. Does it work without a network?
A safety app that goes blank in a tunnel, a parking garage or a mountain valley fails exactly where safety matters. Ask what still works offline and what happens to events that occur while disconnected. Our answer: nearly everything works, and what must reach others waits in a queue.
6. Whose law governs my data?
Not just “where are the servers”, but who controls them: a datacenter in Europe operated by a US-controlled company remains within reach of US legal process. Ask about the operator’s jurisdiction, and what the local law actually provides. Our answer, including its limits: Swiss company, Swiss infrastructure, Swiss law.
7. Who pays for it?
Infrastructure always has to be paid for, so ask how: a subscription, advertising, data partnerships, or a larger business that absorbs the cost. None of these is wrong in itself. What matters is that the answer is stated clearly, and that you are comfortable with it. Ours is a subscription, and nothing else.
The pattern behind the questions
You’ll have noticed the questions share a shape: they distrust promises and look for properties. A policy can change with an acquisition, a pivot or a quarter of bad revenue. An architecture can’t change quietly, because the app stops working without it.
No app will score perfectly, ours included: we’ve been open about metadata, push notifications and what encryption can’t do. But an app that answers all seven questions in writing, limits included, is telling you something just as important as the answers themselves: that it expects to be checked.
This closes the foundations chapter of the series. Next we move under the hood: how a location app can run all day without draining your battery, and the machinery that wakes the GPS only when it’s worth waking.