Security
Security architecture
Section titled “Security architecture”fialr is designed with security as a structural property, not an afterthought.
Tier-gated data protection. Tier 1 (RESTRICTED) file content, filenames, metadata, and derived artifacts are never transmitted to any external service. This is enforced in the enrichment orchestrator, not the provider layer. Tier 2–3 files default to local enrichment via Ollama; cloud AI (Claude API, BYOK) is available as an opt-in configuration.
Sensitivity tiering. Files are classified into three sensitivity tiers during the classification phase. Tier 1 (RESTRICTED) files — government identifiers, credentials, financial account numbers — are enriched by local AI (Ollama) with results routed to the review queue; cloud enrichment requires two-step confirmation. Classification uses structural signals only, never file content.
Integrity verification. Every file operation is hash-verified before and after execution. BLAKE3 content hashes serve as the canonical file identifier. The SQLite operations table provides an append-only audit ledger that cannot be modified or deleted.
Safety by default. Every module operates in dry-run mode by default. No destructive operation runs without explicit human approval. Jobs generate a pre-flight manifest before touching any files.
Binary distribution. fialr is distributed as compiled binaries. Source code is not publicly available. This reduces the attack surface for supply chain attacks and makes it harder for malicious actors to identify and exploit implementation-specific vulnerabilities.
License activation security
Section titled “License activation security”License activation makes a single HTTPS request to api.fialr.com to validate the license key and bind it to a machine identifier. After activation:
- No further network requests are made
- The license is validated locally using cryptographic verification
- The license file is stored at
~/.config/fialr/license.json - Tampering with the license file invalidates it
Responsible disclosure
Section titled “Responsible disclosure”If you discover a security vulnerability in fialr, report it responsibly.
Do not open a public GitHub issue for security vulnerabilities.
Contact:
Include:
- Description of the vulnerability
- Steps to reproduce
- Affected versions
- Any potential impact assessment
We aim to acknowledge receipt promptly and will provide an initial assessment as soon as practical.
The following are in scope for security reports:
- Vulnerabilities in fialr software that could lead to data loss, data corruption, or unauthorized file access
- Bypass of sensitivity tier enforcement (Tier 1 content reaching the enrichment pipeline)
- Bypass of the dry-run / reviewed flag safety gates
- SQLite injection or operations ledger tampering
- XATTR manipulation that could cause incorrect file handling
- License validation bypass
The following are out of scope:
- Vulnerabilities in third-party dependencies (report these upstream)
- Issues requiring physical access to the machine
- Social engineering
- This documentation website