Security & Privacy Whitepaper (Overview)Appendix

Appendix: Claim IDs Index (Single Source of Truth)

This appendix is the single source of truth for all Claim IDs in the whitepaper. Each claim has a unique, stable identifier and anchor, and is presented in a single line with a Statement and Evidence. Evidence links only to repeatably verifiable authoritative references (chapter anchors or status/third-party report entry points) and does not link to screenshots or re-hosted content.

Maintenance rules

MUST: Claim IDs are unique and stable; once published, they are never reused.
MUST: Each claim’s Evidence must be repeatably verifiable (chapter anchors or authoritative third-party entry points).
MUST: Statements must only assert what the evidence supports; avoid “absolute security” language.
SHOULD: When implementation or policy changes affect a claim, record it in the changelog and link the impacted Claim IDs.

Chapters 1–4 (Scope, Threat Model, Architecture, AuthZ)

SCOPE-01

Statement: The document clearly defines in-scope vs out-of-scope risks and the system security boundary. Evidence:1.3， 1.4

THREAT-01

Statement: The threat model covers network attacks, unauthorized downloads, storage/server-side read attempts, and browser-side attackers. Evidence:2.2

BOUNDARY-01

Statement: Trust boundaries clearly separate responsibilities across client, server, object storage, and external environment; the server MUST NOT obtain CEK. Evidence:2.4

FAILCLOSE-01

Statement: On authentication failure or inconsistent context, the system must fail closed and output no partial plaintext. Evidence:2.5

ARCH-01

Statement: Core data objects are clearly separated: encrypted chunks, manifest, and audit data are isolated from each other. Evidence:3.2

FLOW-UP-01

Statement: The upload flow includes creating a transferId and issuing short-lived access tokens (lookup-based session tokens) with strict scope and expiry controls. Evidence:3.3

FLOW-DL-01

Statement: Downloads parse the URL fragment to obtain CEK; manifest and chunk reads use different scoped tokens; auth failures fail closed. Evidence:3.4， 2.5

AUTH-TOKEN-01

Statement: Short-lived access tokens are server-side session tokens (lookup-based) that expire and are used for access control to ciphertext and manifests. Evidence:4.2

AUTH-SCOPE-01

Statement: Tokens are separated by scopes such as read_manifest / read_chunk / upload_chunk and are strictly validated. Evidence:4.3， 4.4， 3.4

AUTH-PAID-01

Statement: Paid users log in via a one-time magic link and obtain a long-lived client-held token for sender-side management actions. Evidence:4.1， 3.5

REVOKE-01

Statement: The sender can revoke access: deleting a transfer or removing files makes downloads invalid early and denies subsequent access. Evidence:4.5

AUDIT-01

Statement: Audit data such as download counts and progress is visible only to the sender and not to the receiver. Evidence:4.6， 3.5

LOG-01

Statement: Client and server logs/telemetry do not include CEK, URL fragments, or any derivable key material. Evidence:4.7， 10.2

Chapter 5 (Cryptography & Key Management)

CRYPTO-ZK-01

Statement: CEK is generated only in the browser and distributed via the URL fragment; the server never generates a full download link containing CEK. Evidence:5.3.1， 5.3.2

CRYPTO-ZK-02

Statement: The server does not receive/store/log CEK; object storage stores only encrypted chunks. Evidence:5.0， 5.5.1

CRYPTO-E2EE-01

Statement: Chunks use AES-128-GCM; authentication failure must fail closed and output no partial plaintext. Evidence:5.4.2， 5.8.4

CRYPTO-CHUNK-01

Statement: chunkSize is fixed at 16MB (16777216). Evidence:5.4.1， 5.8.1

CRYPTO-NONCE-01

Statement: IV is derived as noncePrefix(8B)||uint32_be(chunkIndex) and must not repeat under the same CEK. Evidence:5.4.3， 5.8.1

CRYPTO-AAD-01

Statement: AAD is bound to transferId + fileId + chunkIndex and encoded via EncodeAAD_v1. Evidence:5.4.4

CRYPTO-CLIENT-01

Statement: Download/decrypt pages load no third-party scripts; client logs/telemetry do not include fragments or key material. Evidence:5.6， 10.2

CRYPTO-TLS-01

Statement: Site-wide HTTPS is enforced; TLS configuration is verifiable via public third-party reports. Evidence:5.1.2， /status#tls-configuration

Chapters 6–7 (Data Lifecycle / Abuse Defense)

LIFECYCLE-01

Statement: Expiry and user-initiated deletion trigger cleanup; revocation is supported to invalidate downloads early. Evidence:6.2， 6.3， 4.5

ABUSE-01

Statement: Abuse defense uses rate limiting and tiered controls, operating without breaking the zero-knowledge boundary. Evidence:7.2， 7.4

Chapters 8–9 (Privacy / Web Security & Isolation)

PRIVACY-01

Statement: The zero-knowledge definition and commitments are explicit: CEK is generated and used only on the client; the server cannot recover the key. Evidence:8.1

PRIVACY-02

Statement: Privacy implications of URL fragments (copy/paste, referrer leakage, logging) are documented with mitigations. Evidence:8.2， 10.2

WEB-01

Statement: Key pages enforce strict CSP and resource boundaries to reduce injection and clickjacking risk. Evidence:9.1， 9.3

WEB-HEADERS-01

Statement: Security headers baseline is verifiable via public third-party reports. Evidence:/status#security-headers

WEB-OBS-01

Statement: The site can be checked via public third-party best-practice scans. Evidence:/status#http-observatory

Chapters 10–12 (Logging & IR / Vulnerability Disclosure / Evidence)

OBS-01

Statement: Observability follows a minimal principle, covering only operations/security needs and using aggregation/sampling strategies. Evidence:10.1

IR-01

Statement: A security incident response process is defined (severity, containment, postmortem, remediation, and public notice). Evidence:10.4

VDP-01

Statement: A vulnerability disclosure process exists and prioritizes issues that could affect the zero-knowledge boundary. Evidence:11.2

EV-01

Statement: The status page aggregates third-party evidence entry points; evidence links to authoritative sources and clarifies applicability boundaries. Evidence:12.2， 12.6