kotiko

git, hosted on GitHub: https://github.com/ScriptKittyOS/kotiko

The ScriptKittyOS GitHub organization requires two-factor authentication for every member, so nobody can push to the repository, change its settings or read private vulnerability reports without it. GOVERNANCE.md requires it for store accounts too.

GOVERNANCE.md requires maintainers (and a steward, if one is named) to protect their GitHub and store accounts with a passkey, a security key or an authenticator app, not SMS.

docs/CODE_REVIEW.md documents how code review is done and what is required: CI's required checks pass first; a reviewer who isn't the author reads the whole diff and approves or requests changes line by line; every review thread is resolved before merging; and a checklist of what must be true (does what it says and matches its spec, tested with a regression test for each fix, trust boundaries and input validation hold, no HTML from data, privacy inventory updated, dependencies within the license and dependency policy, no English or single-language assumption, accessibility and size budgets, docs and changelog, DCO sign-off), plus the standard of evidence for any claim. CONTRIBUTING.md links it. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/CODE_REVIEW.md

The extension zips, the only built release files, are reproducible by anyone: the build uses entries sorted by path, the commit's timestamp, fixed permissions and a pinned pure-JavaScript deflate, so the bytes don't depend on the machine or time zone. The release workflow builds twice and compares, and docs/reproducible-builds.md shows how to rebuild a release from its tag and check it against the published SHA256SUMS. The server is released as source. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/reproducible-builds.md

npm test (Node's built-in test runner) for the extension and mix test for the server, the standard commands of each ecosystem; npm run e2e runs the Playwright end-to-end tests. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#setup

Every change reaches main through a short-lived pull request, and GitHub Actions runs every test suite, the linters and the audits on each pull request and each push to main; main requires 8 checks to pass. https://github.com/ScriptKittyOS/kotiko/actions/workflows/ci.yml

Statement coverage is above 90 % and enforced by FLOSS tools in CI and in the release workflow: the server's ExUnit suite covers 91.6 % of lines and fails below 90 % (mix test --cover, threshold in mix.exs), and the extension's Node test suites cover 93.9 % of lines and fail below 90 % (npm run coverage). https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests

The extension's Node test suites cover 84.5 % of branches and fail below 80 % (npm run coverage, node --test with --test-coverage-branches=80), in CI and before every release. For the Elixir server no FLOSS tool measures branch coverage (Erlang's cover tool counts lines only), so its 90 % line gate applies instead. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests

Kotiko's own outbound traffic uses HTTPS by default: model providers, OpenRouter, Telegram and Wiktionary. The server listens on 127.0.0.1 by default, so its plain-HTTP API doesn't leave the computer unless the owner sets BIND to another address; then the server logs a warning at start (daily for a public address), and the extension warns under the address field when the token would cross a network unencrypted. A plain-HTTP model endpoint (such as a local Ollama) is used only when the user enters one.

TLS comes from Erlang/OTP (26 and newer, which offer TLS 1.2 and 1.3 by default) for the server's outbound requests and from the browser for the extension. Kotiko never sets or lowers the TLS version.

Extension pages run under an explicit content security policy (script-src 'self'; object-src 'self') with no inline scripts, and ESLint forbids HTML string sinks (innerHTML, outerHTML, insertAdjacentHTML) so a bug can't turn word data into markup. The server checks the Host header against an allowlist before anything else (against DNS rebinding), caps request bodies, sends no CORS headers, marks answers no-store, binds to loopback by default, compares tokens in constant time, and filters secrets out of logs. Planned: X-Content-Type-Options and similar headers on server responses, and a sandboxed systemd unit. Evidence: https://github.com/ScriptKittyOS/kotiko/blob/main/extension/manifest.json and https://github.com/ScriptKittyOS/kotiko/blob/main/docs/security/assurance-case.md

Property-based testing is the dynamic analysis, and it runs on every pull request and again in the release workflow before anything is built. The extension's pure code (the page matcher, URL checks, bulk-add parsing, backup read and restore, casing, the word-list check) is tested with fast-check, and the server's request validation, word spec, settings parsing, language tags, text cleaning, redaction and backup round trips with StreamData; each run uses a new seed, and a failing seed can be replayed. It has found real defects: a word with Å or Ņ made the server answer 500, a repeated query parameter did the same, and a re-add brought back a form the learner had removed; each was fixed with a regression test. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests

Under test, the extension runs with an assertion mode (globalThis.KOTIKO_ASSERT, set only by the test harness and never by the shipped extension): the matcher checks every scan's matches (bounds, text, order, no overlap), the backup restore plan checks its counts and that it never writes a deleted word, and the word-list check verifies every word is kept or counted. The property-based tests drive these paths with generated input. The server relies on Elixir's pattern matches and guards, which already stop on a broken invariant in production. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests