Threat Model

Quick summary

Assume a buyer controls their browser and can inspect, patch, copy, or replay client-side code. The safe boundary is a server that validates permission and performs the protected operation.

Read this before making claims about code secrecy or device security. Protection reduces specific risks, not every form of copying.

Summarized from experiments/auto-protection/docs/THREAT_MODEL.md (the normative attacker model) and docs/product/trust-model.md (the product-level responsibility split). Those files are authoritative; this page is the readable digest.

The attacker

An end user who has not purchased the protected feature (or bought once and wants to distribute the value) — and who fully controls their own browser environment. Concretely, they can:

• Download and statically analyze every artifact served to the browser (JS, WASM, HTML, source maps).
• Inspect memory at any execution point — including the moment a secret-dependent value is in RAM.
• Patch, re-bundle, or remove any license-/integrity-check code path.
• MITM their own traffic: observe, record, modify, drop, replay.
• Clone the environment: copy storage, tokens, IndexedDB, the whole profile.
• Relay through a cooperating paying user's session.
• Reuse/redistribute any result the client legitimately receives.

Out of scope: server compromise, attacks on other users' devices, physical/ hardware attacks, DoS.

Trusted vs not trusted

Trusted: the server and its runtime integrity; server-held secrets; the entitlement ledger (licenses/revocations/usage); server-side authorization checks; standard cryptography.

Not trusted:

Component	Why
Client-held keys	Anything the client holds, the attacker holds.
Non-extractable WebCrypto keys	extractable:false blocks naive extraction, not abuse-in-place (sign() is callable by hostile code in the same environment) nor wholesale profile clone — demonstrated limitation, not a fix.
Obfuscation / WASM opacity	Raises analysis cost — measured minutes-to-tens-of-minutes, not months.
Self-integrity checks	The checker runs in the same attacker-controlled context; removable.
TEE/TPM/WebAuthn	Not relied on in this model.

TLS protects bytes in transit between honest endpoints — the attacker is one of the endpoints. "TLS terminated" is where attacker access begins.

The public-client-cloneable limitation

This is the headline honesty point, stated plainly:

If the value is computable from shipped artifacts alone, every clone of those artifacts works by definition. A fully client-side asset cannot be copy-proofed; "copy protection" without a server dependency collapses to license enforcement, not a technical barrier.

Corollaries that shape every honest claim on this site:

• Anything shipped to the browser is public at delivery time — algorithms, constants, embedded "secrets", WASM internals.
• At-runtime confidentiality of delivered material does not exist — a key delivered to the client yields attacker-observable plaintext.
• Delivered results are reshareable (the analog hole) — only post-hoc tracing/watermarking applies, a different discipline.
• A cooperating paying user relaying F_k queries is exercising authorized access — mitigation is metering/rate-limiting, partial only.
• Delay and cost-raising are real but must never be mislabeled as prevention. Docs say delay when they mean delay.
• "Cannot clone the key" ≠ "cannot clone the setup" — non-extractable keys raise the bar for naive duplication but the whole profile is copyable in principle.

What is protectable

The dividing question: does obtaining the value require the server to do something it would refuse for an unentitled requester? When yes:

• Server-side secrets stay secret (never shipped).
• Grants are entitlement-gated server-side (proven shape: prior experiment blocked all attempted unauthorized executions).
• Per-use accountability via atomic capability consumption and metering on the ledger — not on a client counter.
• Unentitled clients cannot independently produce F_k(x) iff F_k is a genuinely keyed function (experiments/auto-protection/docs/PARTITION-MODEL.md) and oracle abuse is bounded — that is the claim the experiments test, not assume.

Three-party responsibility split

From docs/product/trust-model.md: DevPay is the license/entitlement authority (meters only what it observes — BYOS executions are structurally invisible); the seller owns the software, the feature namespace, and the BYOS enforcement server (seller-side tamper is out of platform scope — enforcement bounds the buyer-facing contract); the buyer holds key + device keypair inside a controlled environment.