Sept. 10, 2026

We removed the location lock

Until late August, YGOOW had a condition you could attach to a message or to the app-lock: only opens near a place. Set a point and a radius, and the message stayed a locked block anywhere else. It was on the home page, in the FAQ, and in the whitepaper. It is gone now, from all of them — and from the app, the permissions manifest, and the message format. This post is the reason, written down rather than quietly edited away.

What we found

To evaluate the condition, the app has to know where the phone is. On Android, the honest way to ask for a fast position is the platform’s location manager, and the code asked it for both providers: the satellite one (GPS_PROVIDER) and the “network” one (NETWORK_PROVIDER).

On a phone with Google Play Services, the network provider does not compute a position. It scans the Wi-Fi networks and cell towers around you and sends that list to Google’s location servers, which reply with a fix. That request goes out through the system network stack — not through the app’s SOCKS proxy, not through Tor, not through anything we control.

So every time a recipient opened a location-locked message, their device made an attributed, un-anonymised request to a third party, at the exact moment of reading. The same applies to assisted GPS on a cold fix, which talks to a SUPL server the same way.

Everything the transport layer does — the onion service, one Tor circuit per identity, size buckets, cover traffic, rotating addresses — sat underneath a feature that walked around it with one call.

Why it was worse than it looked

Two things made this more than a bug to patch.

The feature bought nothing it could keep. A location condition is a policy the recipient’s device enforces — a patched client simply skips it. We say that plainly about all of our conditions: they guard against a phone seized later, not against a determined holder. So against the one adversary who could replace the client, the condition guaranteed nothing, while against everyone else it cost a network leak on every read.

The condition itself is metadata. “You must be at place P to read this” hands anyone who learns the rule a way to tie network activity to geography. Location data from any source — a carrier, a data broker, a signalling-network lookup — intersected with the times a message was opened gives a match. A physical predicate on reading shrinks the set of people you could be, which is the opposite of what an anonymity layer is for.

Fixing the provider alone would have removed the first problem and left the second. So the feature went.

What we took out

The condition’s identifier in the format stays permanently retired — it will never be reused for another condition, because an older client would evaluate it with the old meaning. An app-lock that was saved with a location condition opens with the secret alone; the app no longer holds anything that says the gate existed.

The lesson we are keeping

The transport layer was never the problem. The problem was a product feature that asked the operating system for something, and the operating system answered by talking to someone else. That is the shape of most real leaks: not the cipher, not the network design — a call in a feature that nobody measured. It is how EncroChat fell and how Ricochet fell, and it would have been how a location-locked message fell.

So the rule now applies to every feature, not just the transport: nothing in the app may make a network request that does not go through the same proxy as everything else — and any feature that needs the operating system to look outward is a feature we would rather not have.

The remaining conditions — a lifetime, an open-after date, burn-after-read — need nothing but a clock. They stay.

Your key, your rules — everything else is redacted.

← Back to blog