# NoData — What's Open, What's Closed, and Why **Version:** 1.0 (April 2026) We are deliberate about what we publish and what we keep private. This document is a single-page answer to *"what part of NoData can I read?"* and *"why isn't the rest open?"*. We publish this list not because we have to, but because the absence of one is itself a smell. --- ## The two-line summary **Open:** every cryptographic primitive, every protocol, every algorithm choice, every spec that an auditor needs to evaluate the security of the system. **Closed:** the operational regime — the production state machine, the multi-tenant isolation enforcement, the anti-abuse logic, the customer-facing scaling decisions. These are commercial assets and live-fire defenses; opening them would weaken every customer's posture, not strengthen it. --- ## What's open ### 1. The CLI: [`@nodatachat/protect`](https://www.npmjs.com/package/@nodatachat/protect) **License:** MIT (until April 25 2026), proprietary thereafter for new versions; archived MIT versions remain freely usable **Where:** `npm i -g @nodatachat/protect` · source on github.com/daviderez4/nodatachat-core **What it contains:** - All client-side cryptographic operations (encrypt, decrypt, sign, verify) - The Merkle tree construction for folder signing - The region-marker parsing for intra-file signing - The receipt-verification logic against the public API - Sample workflows and CI integration You can run, audit, and patch the entire client. Your local install handles all your data — the only network call is to fetch / verify receipts. ### 2. Threat model and crypto specs (this kit) - `architecture-and-threat-model.md` — adversaries, what we defeat, what we don't - `crypto-primitives.md` — exact algorithms, parameters, libraries - `audit-chain-spec.md` — chain construction and verification math ### 3. Public verification API - `/api/verify`, `/api/verify-tree`, `/api/proof/chain`, `/api/proof/`, `/api/proof-certificate` - All publicly callable, IP rate-limited, returning JSON - Source: open in `nodatachat-core` ### 4. The audit-export ZIP format - `summary.html`, `events.json`, `receipt-chain.csv`, `manifest.txt` - Generation logic and integrity-hash construction documented in `audit-chain-spec.md` §5 - Sample available for download from `/kit` ### 5. SECURITY.md and disclosure policy - github.com/daviderez4/nodatachat-core/blob/main/SECURITY.md - 90-day coordinated disclosure window, bounty program for severity-rated issues --- ## What's closed ### 1. Server-side KEK derivation chain **Why closed:** the KEK derivation pipeline binds tenant identity, master secrets, and HSM hooks. Publishing the exact code path would aid targeted attacks against specific tenants without helping defenders. **What's published instead:** the KDF (HKDF-SHA-256), the domain separation rules, the rotation policy. An auditor under NDA can review the full path. ### 2. Multi-tenant isolation enforcement **Why closed:** this is the core of the operational moat. Knowing exactly how we partition request routing, key access, and chain serialization across tenants gives an attacker the map of what to bypass. **What's published instead:** that we use Postgres-level tenant filtering, advisory locks per tenant for chain appends, and KEK isolation at the KMS layer. An auditor under NDA gets the per-table filters, RLS policies, and the proof of tenant non-bleed-through. ### 3. Anti-replay state machine **Why closed:** publishing the exact replay-detection logic gives an attacker the precise window and gap they could exploit. This is live-fire defense. **What's published instead:** that we use server-assigned monotonic `chain_index` + idempotency keys + per-tenant tail pointer. The math is in `audit-chain-spec.md` §6. ### 4. Production scan engines (Capsule, Guard) **Why closed:** the scanners detect specific PII surfaces, secret patterns, and configuration vulnerabilities across customer codebases. Publishing the rule set tells an attacker exactly what we look for. **What's published instead:** sample scan outputs (in this kit), the migration-SQL format generator, the public-facing report card. ### 5. Customer schemas, data, and operational logs **Why closed:** trivially obvious; this is customer property. **What's published instead:** zero — this never leaves customer control. Even *we* don't have access to content; only to event metadata under §audit chain. ### 6. Roadmap, pricing internals, contract terms **Why closed:** standard commercial reasons. **What's published instead:** public pricing tiers (Free / Business $29 / Capsule $199 / Enterprise — see `/pricing`). --- ## How we decide A simple test: > *"Does publishing this give a defender more than it gives an attacker?"* If yes → open. If no → closed. If genuinely ambiguous → we err open and watch for abuse. This is the same test used by: - Linux kernel cryptographic primitive choices - Postgres RLS and security barrier views - The Tor protocol vs. the Tor consensus operation - Certificate Transparency (the protocol is public; the operators' anti-abuse logic is not) It is **not** the test used by "we won't tell you because it's secret" vendors. We owe you a reasoned answer for every closed item; the list above is that answer. --- ## What you can do under NDA After scope-of-engagement is agreed (typically: a POC scope letter, mutual NDA, named technical reviewers), we open: - The KEK derivation source path in full - The multi-tenant isolation enforcement (RLS, locks, KMS partitioning) - The anti-replay state machine - Production logs (redacted) for incident timeline review - A test tenant on a separate isolation domain with read access to chain internals This is the same rhythm every serious security vendor follows. We name it explicitly because hand-waving the boundary is itself a smell. --- ## What you should challenge If you have read this far, the right question to ask us is: 1. *"Show me the multi-tenant isolation code path under NDA. I want to see the actual `WHERE tenant_id = ?` in production queries."* 2. *"What was your last security incident, and how did you detect it?"* 3. *"What would you change about your own threat model if you had unlimited budget?"* We have answers for each. We are happy to be challenged on the closed parts; the test of a good vendor is whether the boundary stands up to that challenge — not whether the boundary exists. --- *Email security@nodatacapsule.com to start a closed-scope review.* *All five sections above are signed; verify their hash against `kit-manifest.txt`.*