FileGriffon's Approach to Privacy and Data Handling

A tool that watches your files for corruption ends up in an interesting position: it touches almost everything on a drive, file names, folder structure, the contents themselves, which means how it handles all of that matters just as much as whether it catches a bad file. We spent real design effort on the “how it handles it” half, and figured it was worth writing up plainly instead of burying it in a privacy policy nobody reads until something goes wrong.

Here’s what that looks like in practice, with specifics rather than a vague “we care about your privacy” line.

Your files stay exactly where they already are

Scanning a drive with FileGriffon doesn’t look anything like scanning a drive with a cloud backup tool. The scanning engine, the hashing logic, and the database layer run entirely locally, there’s no code path in any of them that sends a file, a file name, or a folder structure anywhere. Your vaults, the file hashes, and the event history all live in a local database on your own machine, by default under C:/ProgramData/FileGriffon/. Nothing about your files ever needs to reach a server for the core protection to work.

What does talk to the network, and exactly what it sends

FileGriffon being local-first doesn’t mean it’s disconnected from the internet entirely, so it’s worth being specific about the handful of things that do involve a network call, rather than just saying “barely any of it” and leaving it there.

• License activation. Confirms your license key against our server. Nothing about your files or vaults is part of this exchange. A fully offline activation path (for machines that never touch the internet at all) is also planned.
• Update checks. Sends your current version number and OS platform, so the app can tell you if a newer release exists.
• Optional alerts. If you turn on email or ntfy notifications (a Pro feature), FileGriffon sends the alert itself, since that’s the point of the feature, but only for events you’ve opted into, and only through the channel you configured.
• Telemetry, off by default. If you explicitly opt in, FileGriffon sends a small, fixed set of anonymized usage events, “a vault was created,” “a scan ran,” that kind of thing. File names, paths, and hashes are never part of that list. Nothing is sent at all unless you turn this on yourself.

That’s the complete list. No analytics SDK running quietly in the background, no sync layer, nothing buried in fine print. The full breakdown lives in the privacy policy if you want the exact wording.

The database can be encrypted, and the hashes have an extra layer of protection too

Turn on database encryption in Settings and the local database file is encrypted on disk continuously, page by page, for as long as the feature stays on. There’s no plaintext working copy created while FileGriffon runs and no separate decrypt/re-lock step: the file on disk is encrypted whether FileGriffon is running, idle, or not running at all, so a copied or stolen database file is unreadable without your passphrase, full stop. That part’s fairly standard for anything handling sensitive data. The more unusual part is what FileGriffon does with the hashes themselves.

By default, file hashes aren’t stored as plain checksums. They’re run through HMAC, keyed with a secret unique to your install, before being saved, a mode FileGriffon calls “Protected” hashing, and it’s the default for new vaults. That secret is held by your operating system’s own secure credential storage rather than sitting in the database file next to the hashes it protects. The practical benefit: a copy of your database on its own isn’t enough to figure out whether a specific file exists somewhere in your vault, since that check also needs your installation’s own secret. A plain checksum gives that away for free. A keyed one doesn’t.

(If you’d rather have directly comparable checksums instead, for scripting or cross-checking against another tool, a “Raw” mode is available too. That’s a choice you get to make per vault, based on what you actually need.)

Old history doesn’t hang around forever

FileGriffon doesn’t keep an ever-growing, permanent record of exactly which files existed at exactly which paths. Once an event in your history passes a configurable retention window, the underlying path text gets cleared from that older entry automatically. The event itself stays in your history, just without the specific path detail sitting there indefinitely.

When troubleshooting needs a look at your logs, they’re scrubbed first

Sometimes getting support genuinely requires a look at what happened. FileGriffon has a “Diagnostic Logs” toggle for exactly that, off by default, and even once it’s on, nothing is ever sent automatically. You export a bundle yourself, only if and when you choose to attach it to a support request.

That bundle is kept deliberately narrow: log text only, never your database, file list, settings, license key, or encryption secrets. Vault names and file paths inside those logs are redacted twice over, once as they’re written to the log in the first place, and again at export time, where vaults get relabeled VAULT_1, VAULT_2, and so on. The goal is a bundle that’s genuinely fine to hand to a stranger for support, not just “probably fine, don’t look too closely.”

The honest limits

None of the above adds up to “unhackable,” and it would undercut the point of this post to pretend otherwise.

Encryption at rest protects a copied or stolen database file, not a machine that’s already logged in and unlocked, that’s true of any app that needs to keep running in the background. Full-disk encryption, a strong Windows account password, and physical security of the device itself are still worth having on top of this, not instead of it. And if you lose your database encryption passphrase, there’s genuinely no recovery: it’s a one-way key derivation by design, which is exactly what makes it real protection rather than a backdoor with extra steps.

More broadly, worth saying plainly: no software, ours included, can promise absolute safety. Even billion-dollar companies with dedicated security teams regularly get breached. That’s not a reason to be careless about any of the choices above, it’s the reason we made them in the first place, but it is a reason to be honest about what “secure” can and can’t mean. Reasonable precautions reduce risk, they don’t eliminate it, and deciding how much risk is acceptable for your own files, on any piece of software or hardware, is ultimately a judgment call only you can make.

Why this got the extra effort

None of this was strictly necessary to build a tool that catches file corruption. A simpler version could hash your files, store plain checksums, skip the encryption option, and still do that job just fine. The reason it doesn’t work that way is that watching over files people genuinely care about, photo archives, years of project work, things with no second copy, felt like it should come with the same care on the handling side as on the detection side. Catching a corrupted file is the headline feature. What happens to your data while FileGriffon is doing that felt like it deserved just as much attention, even if it’s a much quieter part of the story.