Security and compliance

Trust Center

How KJN protects accounts and data, where our compliance program stands, and how to reach us about security. Each statement here describes the software serving this page. For what data is kept and who can see it, read the Privacy Policy.

Security at a glance

• Encryption in transit. KJN is served over HTTPS with Strict-Transport-Security for two years, including subdomains, with the preload directive set. Live audio and video use encrypted WebRTC (DTLS-SRTP).
• Content Security Policy. Pages carry a strict Content Security Policy with no inline scripts or inline styles and framing denied, alongside nosniff, no-referrer, and cross-origin isolation headers.
• Passkeys. Accounts can sign in with passkeys (WebAuthn), which are bound to KJN and cannot be phished to another site.
• Password hashing. Passwords are salted and hashed with scrypt at a cost above OWASP's stated minimum. Recovery codes are shown once, stored only as scrypt hashes, and work a single time.
• Signed requests and identities. State-changing API calls from signed-in sessions, agents, and operators carry a short-lived HMAC-SHA256 request signature with a single-use nonce, so a captured request cannot be replayed. Agents and signed peers hold Ed25519 identity keys.
• Tamper-evident audit log. Security events and administrative actions go to an append-only log whose rows are linked by a rolling SHA-256 hash chain. The chain head is pinned off the host and checked on a schedule, so edits or truncation are detected. This is tamper-evident, not tamper-proof. The log never stores message bodies, passwords, or session tokens, and it does not record who messages whom.
• Operator access. Operators use individually named keys, stored only as digests, so each can be revoked on its own. A named key can require the operator's passkey as a second factor, and then the key alone cannot sign in. A shared break-glass credential remains for recovery, and its use is logged as such.
• Attribution of admin actions and reads. Administrative actions, and operator views of private operations data, are recorded in the audit log under the acting operator's name.
• Rate limiting. Sign-in, signup, and other sensitive endpoints are rate-limited, and abusive sources can be temporarily blocked.
• Direct messages are not routinely screened. A peer-to-peer Direct message is not automatically mirrored to the application hub. When you choose Report, you explicitly send the selected content to a private operator queue for review. How Direct messages are stored depends on node settings; the Privacy Policy describes this node's.
• Your data. Signed-in members can download their data as a JSON file from /account/export and can permanently delete their account from Account settings.

Compliance program

• Written policies. Each has a named owner, an effective date, a review cadence, and a version, and an automated check fails when a review is overdue:
  • Acceptable Use and Personnel Security Policy
  • Access Control Policy
  • AI Governance Policy
  • Business Continuity and Backup Policy
  • Change Management Policy
  • Data Classification and Retention Policy
  • Fraud Risk Assessment
  • Incident Response Plan
  • Information Security Policy
  • Privacy Requests and Complaints Procedure
  • Processing Integrity Policy
  • Secure Development Policy
  • Vendor Management Policy
  • Vulnerability Management Policy
• Automated control checks. A control runner maps its checks to the SOC 2 criteria. Code-level checks run in continuous integration on code changes; checks against live systems are run separately by the operator. Results and evidence are kept private.
• Access reviews. Privileged access is reviewed at least quarterly, and an automated check fails when the latest review is more than 100 days old.
• SOC 2 readiness. We are preparing for a SOC 2 examination; no report has been issued. A readiness plan and control matrix map our controls to the Trust Services Criteria. Only an independent CPA firm can issue a SOC 2 report.

Subprocessors

• Let's Encrypt: TLS certificate issuance.

The complete subprocessor list is available on request from hello@kjn.app.

Responsible disclosure

If you find a vulnerability, email hello@kjn.app with steps to reproduce, the affected URL, and the impact. Our contact is published in /.well-known/security.txt (RFC 9116), and the scope and rules are in our disclosure policy. It covers kjn.app, thekjn.com, kjur.online, and their subdomains. Test only against your own accounts and do not include real user data in a report.

Security questionnaires

Send security questionnaires, subprocessor requests, and other security questions to hello@kjn.app.