The Pin on the Map Is Deliberately Wrong
Everybody does the circle. Almost nobody explains it.
You’ve seen it on every listing site: a shaded circle on the map instead of a pin, with a line underneath saying the exact location is shared after booking. It’s so familiar that most people never ask what it’s actually protecting against.
It’s protecting against something quite specific. A public listing page tells a stranger the following, all at once: here is a building, here are photographs of its interior, here is a calendar showing precisely which nights nobody will be in it. Add an exact address to that set and you have published something closer to an opportunity than an advertisement.
That’s the case for approximate locations. The case for doing it properly is different, and it’s the one worth writing about, because the obvious implementation doesn’t work.
The obvious version doesn’t work
The obvious way to build this is to keep the real coordinates in the property record, and have your public pages draw a circle instead of a pin.
This is theatre. The true position is still sitting in the data that the public page fetched in order to draw its circle. Anyone who opens the browser’s network tab, or reads the page source, or calls the same public endpoint directly, has the exact location. The circle is a drawing, and the truth was shipped alongside it.
Ours would have been exactly this. We found out because we built it in stages and checked between them. After the first stages, a host could set their property to approximate, the setting saved correctly, and the map drew the circle — and switching it on changed nothing at all publicly, because every public surface was still reading the raw coordinate columns: the marketplace search, the planner pins, the property page’s map embed, the structured data on the booking page, the written directions. Five different readers, all correct in their own terms, all reading the truth.
So we moved the truth
The fix was to change what the public columns mean.
The exact coordinates now live in a separate table that only trusted server-side code can read. The columns that every public page already reads hold the public pair — which is the true position when a property is set to exact, and an approximate centre when it isn’t.
The practical consequence, and the thing we had to write down for ourselves so we never forget it: the latitude and longitude on a property are the public pair. Never read them expecting the truth.
Two details that matter:
The offset is deterministic, not random. The approximate centre is derived from the property’s own identifier, between 150 and 350 metres from the real position. It’s essential that it doesn’t change between requests. An offset regenerated each time would let anyone average a handful of page loads back to the true centre — the scatter would be centred exactly on your front door. A single fixed offset gives them one wrong point, forever.
Writers still write the truth. Your address, your map pin, your directions — you enter them normally. The substitution happens on the way out, not on the way in, so you never have to maintain two versions of where you live. As the host you always see the real thing; the approximation is a fact about what strangers are given.
We chose this shape over the more surgical alternative of restricting access to individual columns, for a boring and decisive reason: the marketplace and the booking-page servers fetch whole property records rather than named fields. Any column-level restriction would have broken them or, worse, appeared to work while the data still flowed. And there’s a related trap we’d already been bitten by — revoking access to a single column does nothing at all while access to the whole table stands. It silently succeeds and changes nothing.
Who gets the real address, and when
Privacy that can’t be switched off isn’t useful either. A guest with a suitcase at 9pm needs the actual house.
So there’s an unlock rule, set per property:
- On confirmation — the moment the booking is confirmed.
- On payment — when the money has arrived.
- A set number of days before arrival — you choose how many.
When the rule is met, the guest’s portal serves the true coordinates and the real address. Until then, they see the same approximate area a stranger sees, with a line explaining that the exact location follows.
Trips keep their pins throughout, with an “approximate until confirmed” note, so a traveller planning a route still sees roughly where everything is relative to everything else — which is the actual thing they need at planning time.
The defaults, and why they’re asymmetric
Existing listings stayed exact. New listings default to approximate.
That asymmetry is deliberate. Silently moving a live listing’s map pin 250 metres is a change to how that host’s business appears in public, and it is not our call to make on their behalf — someone’s directions page, someone’s guest emails, someone’s expectations. Existing hosts choose.
New listings get the safer default, because a host setting up their first property has enough decisions in front of them without having to know that this one exists and matters.
Some things are always exact and always will be: publicly-listed places that aren’t private homes, and anything a host has explicitly set to exact.
How we checked it was real
Because this is the kind of feature that can look finished and be decorative, the verification is worth stating.
A real property was flipped to approximate, and then every public reader was checked directly — the marketplace’s public data, the planner, the booking-page server. All three served the offset centre. The exact pair was absent, not merely unrendered. The private table refused the request outright. Then it was flipped back, and the truth returned everywhere, with the related records still in agreement.
That last part matters as much as the first. A privacy feature that can’t be switched off cleanly is a trap of a different kind.
One phase is still open: a standing verification script that re-runs those checks automatically, plus the notice that tells existing hosts this setting now exists and they may want it. The protection is live; the routine that proves it’s still live next month isn’t.
The general rule
We wrote up the broader version of this thinking in Security First: A 27-Point Audit, and it applies here exactly:
If you don’t want data to be public, don’t send it to the public page. Not hidden, not greyed out, not restricted at the last moment before display — not sent. Every other approach is a promise about what a page will choose to draw, and a page is not a place to keep a secret.
Your address isn’t marketing collateral. It’s the thing a guest needs once, at the end, when they’ve told you who they are. That’s the only moment it should leave the building.
Related: Held for 10 Minutes: How Airflow Stops Double Bookings on a similar “the obvious version doesn’t work” problem, and Your Cleaning Team Can See Your Revenue on who sees what inside your own account. Or read about how Airflow works.