Why we built it to never receive your file.
This started from a habit we kept seeing on real engagements: skilled engineers hand-scrubbing configs before sharing them — find-and-replacing IPs in a text editor, missing an object name, missing a serial in an HA alias, and never quite sure they'd caught everything. The manual approach is slow and it leaks, because a config has more identifying surface than a human reliably tracks.
The obvious fix is a web tool you upload to. We rejected that, because it has the same flaw as the problem: now two parties hold the sensitive file instead of one. A privacy tool that takes custody of your data to protect it has quietly become another place your data can leak from.
So the design constraint came first, before any code: the tool must never receive the configuration. Everything downstream followed from that — Python compiled to WebAssembly, both vendor engines running client-side, the file never crossing the network. The privacy claim isn't a policy you have to trust. It's an architecture you can verify.
FortiGate serial numbers hiding in HA aliases and Security Fabric device references — customer-identifying tokens that survive a naive IP scrub. Closing that taught us the real surface area.
Object names. Prod-DB, Riyadh-Branch, jdoe — arbitrary strings that match no IP or pattern, so they pass straight through unless something looks for them. We built a pre-scan that flags them and asks you to confirm.
Even after removing the client name from NorthBay-SCADA-DMZ, the remainder SCADA-DMZ still leaks the environment. Whole-name mode replaces the entire name — consistently, across every reference — so the structure goes too.