Trust center
Trust Center
Review the InCase File local-first privacy model, safe-use rules, encryption boundaries, file handling limits, and feedback policy before using sensitive financial tools.
The Trust Center explains how InCase File handles sensitive financial work, what stays in the browser, what should never be entered, how encrypted backups work, and how to send feedback safely.
What stays on the device
The emergency workbook, statement analyzer, CSV Doctor, and document pack builder are designed to run in the browser. Workbook exports, encrypted backups, repaired CSV files, XLSX reports, and organized ZIP packs are generated locally after the user chooses the input. The core tools do not require an account, bank login, account linking, or server-side storage of workbook contents.
A local-first tool still depends on the user device. Browser extensions, shared computers, compromised devices, copied clipboard data, screenshots, printers, downloads folders, and cloud-sync folders can still expose private information. The product reduces unnecessary application-server exposure, but it cannot make an unsafe device safe.
- No account required for the core tools
- No bank login or account linking
- No application upload endpoint for workbook contents or statement text
- No plaintext email export for sensitive files
- No passphrase storage in the app
What never belongs in a family-facing file
The safest emergency file points to official records and safe recovery instructions. It should not become a master secret document. A family handoff workbook is safer when it contains institution names, partial references, document locations, support contacts, review dates, and next actions instead of raw credentials.
The app includes safety checks for dangerous patterns, but automated checks cannot understand every private value. Users should review notes before exporting, printing, storing, or sharing any file. If a field would let an unauthorized person take over an account, it does not belong in the workbook.
- Do not enter passwords, PINs, OTPs, CVV values, private keys, or recovery seed phrases
- Avoid full bank account, card, tax, identity, or policy numbers when a partial reference is enough
- Do not submit private statements or workbook exports through the feedback form
- Keep encrypted files and passphrases in separate places
Encryption boundaries
Encrypted spreadsheet exports and editable backups are encrypted in the browser using a passphrase-derived AES-GCM key. The passphrase is needed later to decrypt or restore the file. If the passphrase is lost, the app cannot recover the encrypted file.
Encryption protects the downloaded encrypted file only after it is created. It does not protect a weak passphrase, an unlocked computer, a malicious browser extension, screenshots, a copied clipboard, printed pages, plaintext files, or files saved into unsafe folders. Users should do a restore test before relying on an encrypted backup.
- Use a long passphrase that is not reused elsewhere
- Store the passphrase separately from the encrypted file
- Do a restore test before relying on an encrypted backup
- Delete temporary plaintext exports if they are no longer needed
Privacy-safe feedback
Feedback should help improve the product without sharing private data. Users can report missing bank labels, CSV formats, unclear instructions, accessibility issues, content corrections, or site questions with fake or masked examples.
Do not attach private PDFs, spreadsheets, encrypted backups, ZIP packs, bank statements, tax files, or family records to feedback. Never send a passphrase with an encrypted file. If a screenshot is useful, names, account references, file names, phone numbers, addresses, financial values, and family-specific details should be hidden first.
- Use fake data when reporting parser issues
- Mask screenshots before sharing
- Never send passwords, PINs, OTPs, CVV values, or recovery phrases
- Keep support messages separate from sensitive files