Security, honestly.
This page splits security into what's shipped today and what's on the roadmap. We'd rather lose a prospect to honesty than win one to marketing.
-
End-to-end encrypted DMs, by default
Every 1:1 DM is encrypted in the sender's browser using the Internet Computer's vetKD protocol before it reaches the canister. Senders encrypt against the recipient's principal; only the recipient can decrypt. Neither the foundation nor any admin can read DM content — no backdoor, no compliance-mode override, by cryptographic construction. Legal response to subpoena: ciphertext and metadata available; plaintext cannot be produced.
-
Append-only audit log
Admin actions — member changes, permission edits, webhook creation, retention updates, data exports — are written to a per-workspace log inside the canister. There is no delete method for log entries. Admins can view, filter, and export but cannot rewrite.
-
Rate limiting on write endpoints
Message sends, file uploads, admin mutations, and auth-sensitive actions are rate-limited per principal at the canister boundary. Not every public function is rate-limited — read-only queries are not — but the blast-radius paths are.
-
HMAC-verified inbound webhooks
GitHub, GitLab, Jira, Linear, PagerDuty, and generic webhooks verify HMAC-SHA256 signatures in constant time before any side effect. Bodies are capped at 1 MB and user-controlled text is sanitized against markdown break-out.
-
Strict script CSP
script-src 'self' https://accounts.google.com— no inline scripts, nounsafe-inline, nounsafe-eval. Frame-ancestors DENY. HSTS, X-Content-Type-Options, and strict Referrer-Policy on every response. -
IP allowlist (workspace-scoped)
Workspace admins can define a CIDR allowlist for admin-console access. Requests outside the list are rejected before any mutating action runs.
-
Retention & legal hold
Workspace-level retention policies automatically purge old messages on a timer. Channel-level legal hold overrides retention when a compliance investigation needs to preserve specific content.
-
Data export & erasure
Admins can export an entire workspace as JSON at any time. GDPR erasure requests are fulfilled by deleting the relevant records directly from the canister — no backup copies to chase down.
-
Per-workspace canister (factory pattern)
Today: all workspaces run on a shared Foundation-operated backend canister with per-workspace access control enforced in Motoko. Logical isolation, not physical.
Coming: a factory canister that mints a fresh backend canister per workspace and registers the workspace owner's Internet Identity principal as a canister controller. Your canister, your keys, no Foundation involvement in the upgrade path. -
Device-loss key recovery
DM encryption is live. Recovery after losing every Internet Identity device is still lossy — same constraint as Signal. Export-to-recovery-file and multi-device key sync via II's existing add-device flow are in progress.
-
Style-src CSP hardening
Our
style-srcstill allows'unsafe-inline'because of Tailwind's runtime style injection. Migrating to nonce-based or hash-based styles is planned before GA. -
Outbound integrations via per-user vetKey token storage
Today we receive webhooks inbound only. Outbound GitHub / Linear / Jira actions (slash commands, URL unfurling, closing issues from chat) arrive with the factory canister + OAuth broker, with tokens encrypted per-user via vetKeys.
-
SOC 2 Type II
Compliance posture is strong but the formal SOC 2 Type II audit is on the roadmap. GDPR is supported today.
Responsible disclosure
Found a security issue? Email hello@nib.chat. We commit to:
- Acknowledge your report within 48 hours.
- Confirm the issue and share a timeline within 5 business days.
- Not take legal action against researchers acting in good faith within this policy.
- Credit you publicly on fix (or keep you anonymous if you prefer).
Please don't test against other customers' workspaces, exfiltrate more data than needed to demonstrate the issue, or disclose before we've shipped a fix.