The netcanon demo never keeps your config — here's the proof

Network configs are sensitive. A running-config can contain your addressing plan, SNMP strings, usernames, and topology. So the netcanon demo runs your session in a throwaway instance that self-destructs within 15 minutes, built so that retaining your data is not just against policy — it is architecturally unavailable. This page maps every claim to the exact control that enforces it and a procedure anyone can use to verify it.

The entire deployment is open source: github.com/netcanon/netcanon. The running system is reproducible from that repo, and its image digests, lockfile hash, and compose-file hash are published in the reproducibility block below.

This document is the in-repo template. The reproducibility block carries placeholders that the deploy step fills with the exact digests, hashes, and date of the running bundle. The live copy at /whitepaper describes the running system; this repo copy describes the mechanism. Every procedure below is a copy-paste command in the repo's VERIFY.md.

Threat model

We defend the visitor's pasted data against: (a) operator retention (us, by design), (b) cross-visitor leakage, (c) post-session forensic recovery from the host, (d) log-based leakage at any layer, (e) a compromised or buggy demo application instance. Out of scope: a fully compromised host kernel/hypervisor (no hosted demo can defend that — if your config is that sensitive, run netcanon locally: docker run --rm -p 8000:8000 ghcr.io/netcanon/netcanon; we make that path one click away).

Trusted Computing Base

Every claim below rests on a small set of components we ask you to trust: the warden (session manager + reverse proxy), the socket-proxy + create-body authz shim (the capability filter that fronts the Docker socket), Caddy (TLS termination), dockerd (the container runtime), and the host kernel/OS. These are the TCB. A compromise of any of them — most sharply the warden, which reaches the Docker socket — is host root, and host root voids all ten claims below. We do not pretend otherwise; we make the TCB as small and as auditable as we can:

• The warden is ≤ 500 lines you can read end to end

(demo/warden/app.py, source: github.com/netcanon/netcanon).

• It runs as a non-root, read-only container and reaches Docker only through

a socket-proxy / authz filter that permits just create, start, list (GET /containers/json, including label filters), inspect, and remove — denying everything else (exec, commit, build, images, networks, volumes, …), not the arbitrary, root-equivalent Docker API. Because the socket proxy cannot inspect a create body, a small create-body authz shim (demo/warden/authz_shim.py) in front of it enforces a whole-body default-deny allowlist on every POST /containers/create: the raw wire body may contain only the fields of the canonical create-body template (the spec in demo/warden/constants.py serialized through the pinned Docker SDK), each pinned to that template (image digest, read-only rootfs, the tmpfs set, no bind mount, network mode, memory/pids/cpu caps, CapDrop: [ALL] with no CapAdd, security-opts) — any other field, in any letter case, is rejected, so an added Privileged, CapAdd, bind mount, or NetworkMode: host cannot slip through. Only the demo.* labels and the two per-instance random env keys may differ. This shim is counted in the Trusted Computing Base alongside the ≤ 500-line warden. (The case-fold is load-bearing: Docker's Go JSON decoder matches struct fields case-insensitively, so the allowlist folds every key to lower case before checking — a lowercase binds cannot smuggle a host mount past it.)

• It never execs into an instance and never reads instance memory or

tmpfs; its only contact with your instance is proxying HTTP to it.

• Caddy and dockerd are stock, pinned by digest (below); the host is a single

small VPS whose configuration lives in the same public repo.

If you cannot extend that trust, the honest answer is the one on the front page: run netcanon locally with docker run … and trust nothing of ours.

Claims, controls, proofs

Tier — how far you have to trust us. V = visitor-verifiable now: you can confirm it from your own browser, on the live site, trusting nothing of ours. O = operator-attested + locally reproducible: confirming it needs host access, so we commit the exact command output in VERIFY.md — and, because no hosted demo can remotely prove its own runtime, you can reproduce every O row yourself by running the identical stack locally with docker run …. make verify attests the published repo/artifact, not this live host. A row marked V·O carries both components: claim 1 is the case — you can watch the instance-id chip differ and the dead-cookie 404 from your own browser (V), while "never a shared instance" is attested at the container boundary (O).

What we do see

Honesty section — required. We (the operator) can observe: standard host operational metadata (session count, lifecycle timestamps, destroy reasons, status codes), our host provider's infrastructure-level traffic metadata, and whatever a TLS-terminating proxy inherently sees in memory while streaming your request. Two more things, stated outright:

• A warden-set routing cookie. netcanon's UI uses absolute URLs

(fetch('/api/v1/migration/plan'), href="/migrate") and has no root-path support, so the warden routes you to your one instance by session, not by path. To do that it sets a single cookie — Set-Cookie: nc_route=<token>; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=900 — carrying only the opaque session token. That token is a bearer credential valid for the life of the session (not single-use), which is exactly why the cookie is HttpOnly, Secure, and SameSite=Strict — JS cannot read or forge it. It is not an analytics identifier and it dies with your session. Because the cookie is browser-global, a browser holds exactly one live session (a fresh mint replaces the previous one); the ≤ 2-concurrent-sessions-per-IP cap is a separate guardrail bounding distinct devices behind one IP. The demo page itself still sets nothing (claim 10).

• Per-IP session state, in RAM only. To enforce the per-IP

concurrent-session cap (≤ 2 concurrent sessions per IP) and a sliding-window mint rate limit (≤ 30 mints / 600 s per IP), the warden keeps a small per-IP record in memory only — never logged, held in memory for up to 10 minutes after your last request, never written to disk, gone on warden restart. A rate limiter must outlive any single session, so the record is evicted 10 min after your last request rather than on session end.

We keep none of the in-memory transit category — the controls above are what make that checkable rather than a promise. If you cannot accept in-memory transit through our proxy, run netcanon locally; that path is on the demo's front page.

Reproducibility block

The deploy step fills these tokens for the running bundle. In this repo template they are placeholders; the live /whitepaper shows the real values, and make verify (run from deploy/) prints the same digests + compose hash for you to compare.

netcanon image    : ghcr.io/netcanon/netcanon@sha256:<NETCANON_IMAGE_DIGEST>   (base python:3.14-slim-bookworm)
requirements.lock : sha256:<REQUIREMENTS_LOCK_SHA>   (hash-locked; glibc/manylinux wheels — not Alpine/musl)
warden image      : <WARDEN_IMAGE_REF>@sha256:<WARDEN_IMAGE_DIGEST>
socket-proxy image: <SOCKET_PROXY_IMAGE_REF>@sha256:<SOCKET_PROXY_IMAGE_DIGEST>   (TCB component — the capability filter fronting docker.sock)
caddy image       : <CADDY_IMAGE_REF>@sha256:<CADDY_IMAGE_DIGEST>
compose sha256    : <COMPOSE_SHA256>
deployed          : <DEPLOY_DATE>   hard TTL: 900s (15 min)   idle TTL: 600s (10 min)   instance cap (MAX_ACTIVE): 32

Residual risks, stated plainly

Trusted Computing Base — the honest worst case

The sharpest residual risk is not exotic: it is us. The warden, the socket-proxy + authz shim, Caddy, dockerd, and the host are trusted (see the threat model's TCB subsection). A compromise of the warden — which holds the Docker socket — is host root, and host root voids all ten claims above: it could snapshot RAM, disable the reaper, or read into any instance. We bound (not eliminate) this by keeping the warden tiny (≤ 500 auditable lines), non-root, read-only, reachable to Docker only through a capability-filtered socket proxy plus a small create-body authz shim that whole-body default-deny-validates every POST /containers/create against the canonical instance spec (both counted in the TCB), so create is not the arbitrary, root-equivalent Docker API — and never execing into instances — all of it in the public repo. If that residual is unacceptable for your data, run netcanon locally and trust none of it.

• A kernel- or hypervisor-level compromise of the host likewise defeats all

guarantees (out of scope in the threat model).

• sendBeacon on pagehide is best-effort; when it doesn't fire, the

heartbeat-timeout path reclaims your instance in ≤ 2 min for a closed foreground tab, ≤ ~4 min for a throttled background tab, and a tab left open but untouched is reclaimed at the 10-minute idle TTL (sooner under heavy load). Both of those only ever shorten the session. The guarantee that requires nothing from your browser — no beacon, no heartbeat, no activity — is the hard TTL, enforced across two independent enforcement domains (the warden and host systemd), three mechanisms, with two honest bounds: while the warden is live it destroys your instance ≤ 15 minutes after it was assigned to you; and even if the warden crashes, an independent host systemd timer (swept every 60 s) force-removes any demo.*-labeled container ≤ ~20 minutes after it was created (older than HARD_TTL + POOL_MAX_AGE = 1200 s). A crash can therefore widen the ceiling from 15 to at most ~20 minutes — it can never lift it; nothing keeps your instance alive indefinitely.

• We can change this deployment. That's why the digests and hash are published:

trust the artifact you can verify today, not us.