Photo metadata: what a classifieds site actually leaks about where its advertisers live
An advertiser building a new listing does the obvious thing: pulls up the camera app, takes a few photos in good light, uploads them to the account, publishes the listing. Nothing about that process feels like a security decision. It feels like the fastest way to get a page live, and on most sites it is exactly that fast, with nothing standing between the photo taken five minutes ago and the photo a stranger sees on the page.
What that stranger can see is not limited to what is visible in the frame. Smartphone cameras that have permission to use location, which is most of them, most of the time, write the exact latitude and longitude of where the photo was taken into a data block inside the file itself, called EXIF metadata. The coordinates travel with the file through upload, storage, and publication, unless something in that chain deliberately removes them. A photo taken in an advertiser's own bedroom, for a listing meant to show a bedroom, carries the address of that bedroom inside it by default.
This is not a theoretical flaw discovered by a security researcher. It is the same design decision every phone maker made for photographers who want their vacation pictures organized by location, applied without exception to a photo meant for a completely different audience. The camera does not know, and cannot know, that this particular photo is going somewhere the person who took it would very much not want their home address attached.
What a phone quietly writes into every photo
The technical detail worth understanding, because it decides what a fix actually has to do, is that EXIF data sits inside the image file itself, in a section the eye never sees and most photo viewers never show unless asked. It is not a caption, a filename, or anything an advertiser would type. It appears the moment the shutter closes, added automatically by the operating system, and it survives being renamed, moved, or emailed as an attachment. What does reliably remove it is re-encoding the image: taking the pixel data apart and writing a new file, which strips old metadata unless a tool is specifically told to preserve it.
The one situation almost everyone has already run into, without knowing why it worked, is that a screenshot of a photo has no location data, because a screenshot is a brand-new image of what the screen displayed, with none of the original file's hidden data attached. That is also why a well-meaning advertiser cannot reliably protect themselves by simply turning off location services after the fact: any photo already taken with the setting on already has the coordinates baked in, and turning the setting off only changes what happens to the next photo, not the ones already sitting in a camera roll waiting to be uploaded.
None of this is new or obscure. A 2012 research project out of the University of Colorado Boulder examined ninety dating websites and found that twenty-one of them, most run by the same company, published user photos without stripping the location data embedded in them. That is not a fringe result from a single bad actor. It is roughly a quarter of an entire industry, over a decade ago, quietly handing out home addresses through a feature nobody using the site had asked for or knew existed.
Why this failure means something different here
On a general classifieds site, this kind of leak is embarrassing. On a site where the person in the photo is an independent provider whose income depends on being reachable but whose safety depends on not being findable, the same leak is a different category of problem entirely. The address is not incidental information about a seller of a used couch. It is the one piece of information a listing is specifically designed never to reveal, sitting quietly in the file underneath the photo the advertiser did choose to show.
The scale of what a single exposure can carry became concrete in July 2025, when the dating-safety app Tea disclosed that hackers had accessed roughly 72,000 images from an exposed database: about 13,000 selfies and photo IDs submitted for account verification, and about 59,000 images pulled from posts, comments, and direct messages. The company said no emails or phone numbers were exposed, and that only accounts created before February 2024 were affected. Nobody has claimed the attackers specifically went hunting for embedded location data in that haul, and this piece is not claiming that either.
What the Tea breach actually demonstrates is narrower and more useful: once a platform stores and serves the raw, unprocessed file an app or a browser originally uploaded, whatever that file happens to contain travels along with it into every place the file later ends up, breach or no breach. A classifieds listing does not need a hacker for this to happen. The platform hands the file to the public itself, on purpose, every single time a photo goes live without the metadata having been removed first.
An old, boring, already-solved problem
The reassuring part is that this is not a hard engineering problem, and it has not been one for a long time. Facebook and Instagram strip location metadata from the copy of a photo they serve publicly, and have for years, precisely because a platform with hundreds of millions of daily uploads cannot afford to have this conversation with each user individually. It is handled once, centrally, in the code path every photo already passes through on its way to being published, and nobody uploading a birthday photo ever has to think about it.
The failure shows up, predictably, on smaller and more specialized platforms that never built that step in, because nobody on a small team was assigned to own it and no user ever files a support ticket asking for a feature they do not know they are missing. A 2024 academic paper examining location-based dating apps found that one of the services studied, MeetMe, still shipped photos with the original EXIF metadata intact, while every other app in the same study had properly stripped it. The gap between the platforms that solved this and the ones that never got around to it has nothing to do with how sensitive the content is. It has to do with whether anyone on the engineering side ever put a checkbox next to it.
That gap matters legally as well as practically. Precise location data of this kind is treated as its own protected category under privacy law in multiple jurisdictions, and California's privacy statute specifically lists precise geolocation, defined as data that places someone within about 1,850 feet, as sensitive personal information subject to its own rules. A classifieds operator publishing that data by accident, embedded in a photo nobody looked at closely, is not exempt from those rules just because the exposure was unintentional.
Why the advertiser cannot fix this alone
The obvious response, telling advertisers to turn off geotagging themselves, sounds reasonable and does not work in practice. Most people have never opened the setting that controls this, do not know it exists, and have no reason to go looking for it until something has already gone wrong. The ones who do know tend to forget it every time they get a new phone, because the setting resets with the device, and a habit that has to be remembered correctly forever, by every advertiser, on every device, without exception, is not a safety measure. It is a wish.
This is the same blind spot that shows up wherever a platform hands responsibility for a technical safeguard to the person least equipped to enforce it consistently. The operator ends up being the only party positioned to guarantee a safeguard actually happens for every file, every time, the same way nobody decided on purpose how long a submitted ID document should sit on a server, except here the decision that never got made is whether a published photo should still be able to point back to a front door.
What the upload pipeline actually needs to do
The fix belongs entirely on the server side, in the code that already processes every photo before it goes live, not in a setting an advertiser has to remember. Re-encoding an image, which most upload pipelines already do to resize it and generate the smaller versions a site needs for thumbnails and previews, strips EXIF data as a side effect in some tools and not in others: the popular Sharp library removes it by default during that process, while ImageMagick, just as popular, keeps it unless the operation explicitly passes the flag that tells it to strip metadata. The two tools do not behave the same way out of the box, which is exactly why this cannot be assumed just because a resize step already exists.
The only way to know which behavior a given pipeline actually has is to test it directly: take a photo with a phone that has location enabled, upload it through the exact same path a real advertiser would use, then download the file the site actually serves to the public and check its metadata with any free EXIF viewer. If the coordinates are still there, the resize step is not doing the job it was assumed to be doing, whatever library sits behind it.
Two shortcuts fail in the same way and for the same reason. Stripping metadata in the browser with client-side code looks like it works until an upload comes through a mobile app, a bulk-import tool, or a direct call to the same upload endpoint, none of which run that browser code at all. And trusting a third-party upload widget to have already handled this is a guess, not a verification, until someone has actually run the test in the previous paragraph against it and looked at the result.
None of this requires new legal advice or a security consultant. It requires someone to run one test this week: upload a geotagged photo through the real listing flow, pull the version the site serves back down, and open its metadata. If the coordinates come back clean, the pipeline already does its job and nothing else needs to change. If they do not, that is the one fix on this list worth doing before the next listing goes live, because the alternative is publishing a home address every time an advertiser posts a photo, and calling it a feature nobody asked for.
