The privacy of needing a toilet

Your bathroom searches are your business.

A toilet search can be part of a family outing, a familiar journey or a personal health need. Phoo does not need to know which one to help you find nearby options.

That is why nearby ranking happens on your phone and the app does not keep a movement history. Here is what that means in practice.

What Phoo does instead

The distance is calculated on your phone. Your coordinates are not sent to a server to be sorted into nearest-first order. The app already has the city’s listings, so it does the arithmetic locally and the server never learns which of them you were closest to. When you open a specific toilet, one routed walking estimate is requested from Apple’s maps stack for that one destination.

Location is requested while the app is open, and only then. There is no background permission, so there is no continuous trail to accumulate. The permission dialog appears when the value of granting it is on screen, not on first launch as a toll.

There is no account. Not for browsing, not for filtering, not for directions, and not for reporting a problem. There is nothing to sign into, so there is no identity for a search to attach itself to. Contributions are rate-limited and checked for integrity by other means.

Nothing is retained as history. The app does not keep a list of the places you looked at, and the backend does not receive one. The app caches the last city’s directory, alongside local settings and a contribution identifier. The directory is a public file, rather than a record of your movements.

There is no advertising surface. No ad SDK, no analytics profile keyed to a person, nothing that would create a commercial incentive to know more about you than the app needs.

Why this is a design constraint rather than a policy

Policies change with ownership. Architecture is harder to reverse.

If ranking happened on a server, the server would need your position, and then privacy would rest on a promise not to keep it. Because ranking happens on the phone, there is no promise to break: the data never arrives. The same is true of the account we did not build and the history table that does not exist.

It also cost something. Server-side ranking would let us return a smaller payload, and an account would let people sync favourites across devices, which is a reasonable thing to want. We do not have either, and both absences are load-bearing.

What we do see

Being straight about the other side of it. A directory snapshot request reaches our infrastructure, which means a request for a city’s file, at a time, from an IP address. That is the minimum a client-server app can do while still working, and it is a request for a public file rather than a personal query — the same bytes for every visitor in the city, which is exactly what makes it cacheable.

Contribution flows are the one place data is deliberately submitted: what you reported, about which listing. Contributor information is minimised and retention-limited, because a report about a broken lock does not need to be traceable to a person forever.

This website, including this page, counts page views. That is the site rather than the app, and it is worth saying here rather than leaving it to be discovered. The count carries the path, the site that linked you and your browser language, and no cookie or identifier, because there is none to send — the visitor number is worked out at the processor’s end and mixed with a value that changes every day. Anything a person chose is stripped before the count leaves the browser, which on the access card page means the reason you need a toilet never travels. The privacy page lists every field and carries a switch that stops it.

The dignity argument

The engineering reason for all this is that toilet searches are sensitive data and sensitive data is a liability.

The real reason is simpler. Needing a toilet is an ordinary part of a day. Helping you find one should not require keeping a record of your movements.