A storage tool's whole job is to read a map of everything on your disk — folder names, file names, sizes, sometimes paths that reveal what projects you're working on or what you've downloaded. That makes it one of the more privacy-sensitive categories of app you'll install, and yet most people install one without checking what it actually does with what it reads. This article is about how to check, not just how to ask.
Why "it's local" claims deserve scrutiny
Every storage tool's marketing page will tell you it works locally, because in the narrow sense that it scans your disk rather than someone else's, that's trivially true. The claim worth checking is narrower and more useful: does the app make any network connection at all while it's running, for any reason — licence checks, crash reporting, usage analytics, or an update check that also happens to phone home with more than a version number?
None of those are necessarily malicious. Crash reporting and update checks are extremely common and mostly benign. But "local" and "no network code" are different claims, and only the second one is verifiable without trusting the vendor's word.
How to check for yourself with a firewall tool
The most direct method is a per-app firewall like Little Snitch, or the built-in macOS firewall's more limited controls, run while you actually use the storage tool.
- Install and open Little Snitch (or a similar tool — LuLu is a free, open-source alternative).
- Launch the storage tool and let it scan a real folder.
- Watch for any connection attempt Little Snitch flags. If the tool has genuinely no network code, you should see nothing at all, even on first launch.
- If a connection does appear, look at where it's going. A connection to an update-check or licence-verification domain is a different thing from a connection to an analytics or telemetry endpoint mid-scan — and either way, the tool's own documentation should already have told you to expect it.
This test takes about five minutes and requires no technical background beyond installing one small utility. It's the single most useful thing you can do before trusting any Mac app with disk-wide read access, not just a storage tool specifically.
The blunter version: pull the network
If you don't want to install a monitoring tool, a rougher but still useful test is to turn off Wi-Fi (and unplug Ethernet if you have it) and then use the app normally. Scanning, browsing folders, and searching are all tasks that only require reading your local disk. If any of those break without a network connection, the app was depending on a remote service for something that should have been entirely local — worth understanding before you trust it with a full-disk scan.
This test has a caveat: it won't catch an app that queues data to send later, once connectivity returns. The Little Snitch method above is more thorough because it watches for the connection attempt itself, whenever it happens.
What "telemetry" actually covers
Telemetry is a broad label, and tools differ a lot in what they mean by it. It can range from anonymous, aggregated usage counts (how many times a button was clicked) to detailed crash reports that include stack traces, to — in the most invasive case — data derived from what the app scanned, such as folder names or file type breakdowns. The privacy-relevant question isn't just "does it have telemetry" but "what specifically does the telemetry contain, and does it include anything derived from your files."
A tool's privacy policy should answer this directly. If it doesn't, that absence is itself informative.
Account requirements as a privacy signal
A storage tool that requires you to create an account and sign in before you can scan a folder is making a design choice worth noticing. It's not automatically a red flag — licence management for paid tiers sometimes uses accounts — but it does mean the vendor now has, at minimum, an email address tied to your usage of the app, and potentially more depending on what the account system syncs. If a free scan-and-browse tier requires an account for basic functionality, ask what that account is actually needed for.
Reading a privacy policy for what it doesn't say
Most app privacy policies are written to satisfy a legal requirement, not to give you a fast answer. When you read one for a storage tool, look specifically for what's absent rather than only what's present. A policy that carefully describes how crash reports are anonymised but never mentions file names, paths, or folder structure at all has likely just not addressed the question you actually care about — which is different from having addressed it and confirmed nothing is collected. If a policy is silent on whether file-derived data (names, paths, extensions, sizes) ever leaves the device, treat that silence as an open question worth asking the vendor directly, not as an implicit "no."
It's also worth checking whether the privacy policy is specific to the app itself or is a generic company-wide policy covering a website, a newsletter, and every product the vendor makes. A generic policy is a weaker signal than one written specifically about what the storage tool does with what it scans.
What a security researcher would check that you might not
If you want to go further than the tests above, tools exist for inspecting an app's actual network behaviour at a lower level than a firewall's per-connection log — traffic inspection tools that show the actual contents of any request an app makes, not just its destination. This is well beyond what most people need to do, and Little Snitch's connection-level visibility is sufficient for the overwhelming majority of privacy questions about a storage tool. But it's worth knowing this deeper level of verification exists, in case a connection you weren't expecting shows up and you want to understand exactly what it's sending, not just where it's going.
A short checklist
- Does the app require an internet connection for scanning, browsing, or search? If yes, why?
- Does a firewall tool show any outbound connection during normal use?
- Does the privacy policy specifically address whether file names, paths, or hashes ever leave the device?
- Is an account required for the free tier's core functionality?
- Does the app request Full Disk Access, and does it explain what that unlocks?
None of these questions require trusting anyone's marketing copy. Each one is independently checkable in under ten minutes.
Where VolumeLens fits
VolumeLens has no network code at all — not for licence checks, not for crash reporting, not for anything. You can verify this yourself with Little Snitch or by disconnecting entirely: every feature in the free tier, including scanning, browsing, search, and cleanup, works with no internet connection, because none of it was ever built to need one. There's no account and no sync for file-derived data.
We built it this way because we didn't want to be in a position of asking you to trust a claim we couldn't back up with something you could check yourself. You can read more about how the app is built on the home page, see what's included in each tier on pricing, or download it and run the Little Snitch test yourself before you decide whether to trust it with anything else.