Tilqos reads every key you press, system-wide, in order to notice a wrong keyboard layout. That makes the line between "a privacy bug" and "a security bug" very thin: a privacy bug is a security bug. The promises the app makes are written down precisely in docs/PRIVACY.md; anything that makes the app behave worse than that page says is in scope here.

Please do not open a public issue for security or privacy problems. Use GitHub's private reporting instead: Security tab → "Report a vulnerability" (private vulnerability reporting for elapen/tilqos). Include the Tilqos version (Settings → General, or the DMG name), your macOS or Windows version, and steps to reproduce. Please do not include text you actually typed; invented examples are enough.

You will get an answer within a week. Fixes are released as soon as they are verified, and reporters are credited in the release notes unless they prefer otherwise. Only the latest release is supported; because the app has no updater, fixed versions are announced on the Releases page.

Anything that makes the app read, keep, log or send more than docs/PRIVACY.md allows, or that lets someone else do so. For example:

• typed text, clipboard content or window titles reaching a log, a file, the pasteboard history, a crash report or the network;
• the keystroke buffer, the undo list or the clipboard copy surviving longer than documented (the 5-second idle reset, the 2-minute undo expiry, lock/sleep/app-switch wipes, clipboard restore);
• keys being read, buffered or logged while Secure Event Input is on, in a password manager that is meant to be excluded, or from input injected by another program;
• reading a clipboard that is flagged concealed or transient, or acting on text above the 10,000-character limit;
• the learned vocabulary or the exception lists exposing more than documented (for example plaintext where hashes are promised);
• any network access at all, any telemetry, any auto-update mechanism;
• the app's synthetic key events being exploitable (for example feeding itself in a loop, or injecting text into a different app than the one you were typing in);
• the replacement logic writing to a field it did not verify;
• the build and packaging scripts shipping an unverified binary, a personal signing identity, secrets, or a licence-relevant file missing from the release (LICENSE, THIRD_PARTY_NOTICES.md, LICENSES/);
• the language data files: crafted *.bin files that crash or compromise the app when loaded (they are bundled with the app and not user-supplied, but the loaders should still reject malformed input);
• on Windows: anything in the hooks, SendInput, clipboard or file handling that goes beyond the documented behaviour.

These are documented limits, not vulnerabilities. A report that finds the behaviour worse than documented is still welcome.

• Other software with Accessibility or Input Monitoring permission (or a keyboard hook on Windows) can see what Tilqos sees. Tilqos cannot prevent that.
• Release builds are ad-hoc signed and not notarized. macOS shows a Gatekeeper prompt on first launch, and Accessibility must be re-approved after an update because the code identity changes. Windows builds are unsigned and SmartScreen warns. Verify downloads against the checksums in the release notes, or build from source (docs/BUILDING.md).
• Exception words, transliteration overrides and "do not convert" words are stored as plain text, on purpose, so that you can see and edit them. The learned vocabulary is hashed with a salted 64-bit FNV-1a, which is not cryptographically irreversible: whoever can read the file can guess short, common words. Both are documented in docs/PRIVACY.md.
• Password fields that do not enable macOS Secure Event Input (some custom-drawn fields, Electron or Java apps, virtual-machine windows) are not recognised. On Windows only standard Win32 password edit controls are recognised.
• Physical access to an unlocked machine, an administrator or root on your machine, malware running as you.
• Crash dumps and swap written by the operating system may contain process memory.
• The experimental Windows port has never been run on real Windows by its author; bugs there are welcome as ordinary issues unless they are privacy problems.

The macOS app has no third-party code dependencies (it links Apple system frameworks only), and the Windows port uses only the Go standard library (windows/go.mod has no require). The only third-party material in the repository is the language data derived from open dictionaries (THIRD_PARTY_NOTICES.md), generated by generate-models.sh, which warns when the downloaded inputs differ from the pinned checksums. Please report anything that makes that chain less trustworthy than it sounds.