You took a photo of your living room to sell a couch online. You posted it. What you didn't post - but uploaded anyway - was a set of GPS coordinates accurate enough to drop a pin on your front door.
That's the uncomfortable reality of file metadata privacy. The data inside your files is only half the story. The other half is the invisible trail wrapped around it: where a photo was taken, what camera shot it, who authored a document, what software produced a PDF, and what a filename like aws-prod-keys.env announces to anyone who can see it. Most people never look. This post is about looking.
A single holiday photo can carry the exact coordinates of your home. A PDF can name its author and the software they used. An unencrypted .env file can sit in a shared bucket for years. You can't fix what you can't see - so the first step is auditing what your own clouds are exposing.
Every file you create carries more than its contents. Cameras, phones, scanners, office suites, and design tools all stamp extra information into the files they produce. That information is convenient - it's how your photo app sorts pictures by date and shows them on a map - but it travels with the file wherever it goes.
When you upload that file to Google Drive, OneDrive, S3, Backblaze, or even a synced local folder, the metadata goes along for the ride. Share the file, make a bucket public, hand a folder to a collaborator, or simply forget about an old archive, and that trail is now exposed to whoever can reach it. The leak isn't dramatic. It's quiet, cumulative, and almost always unintentional.
There are three categories worth caring about, and each one leaks something different.
This is the big one for personal privacy. Most phones and many cameras embed EXIF metadata into every photo. That can include the GPS latitude and longitude where the shot was taken - often precise to a few meters. It also includes the camera or phone make and model, lens, exposure settings, and the exact timestamp.
Put a few geotagged photos together and you can reconstruct where someone lives, works, drops their kids off, and vacations. The camera make and model acts as a device fingerprint that links otherwise unrelated photos back to the same phone. EXIF GPS privacy is not a hypothetical - it's the single most common way ordinary files reveal more than their owners intend.
PDFs, Office documents, and exported design files routinely embed the author's name, organization, the software and version that produced them, and creation and modification timestamps. A PDF you thought was anonymous may quietly name you and the exact application you used. For documents shared publicly or with clients, that's an attribution you never chose to make.
The most embarrassing leaks need no special tooling at all - they're written right in the filename. passwords.xlsx, prod.env, backup-2019-ssn.csv, aws-keys.txt. These names are a roadmap for anyone browsing a shared folder or a misconfigured bucket. And the file behind a name like that is exactly the file you least want sitting around unencrypted.
You might delete a risky file from one cloud and forget the copy in another. Metadata doesn't expire when you stop thinking about it. The only way to know what's exposed across every provider is to inventory it - which is precisely the kind of cross-cloud audit FileFortress is built for.
FileFortress indexes the metadata of your files into a local, on-device search index. Once you've scanned (and enriched) your remotes, that index lets you ask pointed questions across Google Drive, OneDrive, S3, Backblaze, and Local in one place - so you can audit cloud files for exactly the risks above.
Here are three audits worth running today.
The --has-geo true filter surfaces every file that carries GPS coordinates in its photo EXIF. That single query tells you how much of your library is quietly broadcasting location.
# Every photo that carries GPS coordinates, across all remotes
filefortress search --has-geo true --media-type images
# Narrow to a single provider
filefortress search --has-geo true --remote my-gdrive
# Pin down a specific device by its camera fingerprint
filefortress search --camera-make Canon
filefortress search --meta "exif.cameraMake=Canon"Search by a plain term or use --path-filter with a wildcard to find files whose names give them away. Run a few passes for the words that matter to you - password, secret, key, env, backup.
# Filenames that scream "secret"
filefortress search --path-filter "*password*"
filefortress search --path-filter "*.env"
# Or just search the term directly
filefortress search secretThe riskiest combination is a sensitive file that is also stored in the clear. Use --encrypted false to find unencrypted files across your clouds, then combine it with the filters above to spot the worst offenders.
# Everything stored without client-side encryption
filefortress search --encrypted false
# The danger zone: sensitive names, stored in the clear
filefortress search --path-filter "*.env" --encrypted false
# Geotagged photos sitting unencrypted in one bucket
filefortress search --has-geo true --encrypted false --remote my-s3These filters compose freely. Stack --media-type, --remote, --encrypted, and --has-geo to drill straight to the files that matter. The full list lives in the Structured Filters reference.
Auditing tells you where the risk is. Acting on it comes down to two moves.
For files that must live in the cloud but should never be readable by anyone but you, configure client-side encryption on the remote that holds them. FileFortress supports per-remote, RClone-compatible AES-256 encryption: files are encrypted on your device before they ever leave it, so the provider stores ciphertext it cannot read - and neither can anyone who stumbles into a misconfigured bucket. Encrypting a remote doesn't strip the metadata, but it does put the file's contents behind a key only you hold. See the Remote Encryption guide to set it up.
Be clear on this: FileFortress finds metadata so you can see what you're exposing - it does not remove or strip it. There is no "remove EXIF" feature. To actually scrub GPS or author tags from a file, you need an external tool such as exiftool. FileFortress points you at the risky files; the stripping itself is a step you perform with a dedicated utility.
For photos you're about to post publicly, run them through a metadata-removal tool first. exiftool is the standard choice and can clear GPS, camera, and timestamp tags in a single pass. The workflow is simple: use FileFortress to identify which files carry geotags, then strip those tags with exiftool before the file goes anywhere it shouldn't. Two tools, two jobs - audit, then act.
There's an irony lurking in any privacy audit: a cloud-based "find my exposed metadata" service would have to collect all that sensitive metadata to search it. You'd be handing a third party the very map of your secrets you were trying to protect.
FileFortress avoids that entirely. The index it builds lives on your device. When you run --has-geo true or --encrypted false, the query runs locally against your local index. Your audit - the list of where your secrets and geotags live - never leaves your machine. That's not a setting you toggle on; it's the architecture.
Your metadata index is built and queried locally. The map of which files leak GPS, which names scream "secret," and which sensitive files sit unencrypted is yours alone - it is never uploaded to FileFortress or anyone else.
Audit every cloud for geotagged photos, sensitive filenames, and unencrypted files - from one local index that never leaves your device.