Watermarking

When a buyer downloads a paid module, CodeSCE embeds an invisible, per-buyer trace into their copy. If that copy is ever leaked, the trace identifies who it came from. Watermarking is a deterrent and a forensic tool — it never changes how the module runs.

Two layers

Each download is watermarked at two independent levels, so removing one still leaves the other.

1. ZIP-level watermark

A hidden record is embedded into the delivered ZIP at .sce/watermark.json, containing the buyer's identity for that purchase:

• userId — the buyer
• orderId — the specific order
• moduleId — the module
• downloadedAt — when it was delivered

This is generated per purchase as a temporary copy that's streamed to the buyer and then discarded — copies are never shared between users.

Non-destructive by design

The original ZIP is never modified. The watermark is appended as a new archive entry without rewriting existing files, so the module stays byte-for-byte intact and fully valid. If anything about the archive is unusual, the system falls back to serving the original — watermarking never breaks a download.

To make casual removal harder, the ZIP layer can also add an opaque trace tag and an extra hidden marker file, and lightly rename a single documentation file (e.g. README.md → README_.md) — none of which affect the code.

2. In-code watermark

Text source files are marked in two ways at once:

• A visible notice — a comment reading Licensed to <buyer> (traceable). This is both a deterrent and honest disclosure that the file is traceable.
• An invisible mark — the buyer's trace id encoded as zero-width characters hidden inside that same comment. Even if someone deletes the visible notice, the invisible mark can survive, and it lives in a comment so it can never affect execution.

This is applied only to file types with a known comment syntax — .js, .css, and .html — and it carefully preserves things like a leading BOM or a #! shebang line, so code keeps working exactly as before. Unknown or binary files are left untouched.

Why it exists

• Deterrence — buyers are told, in plain text, that their copy is traceable.
• Accountability — a leaked paid module can be traced to the account that downloaded it.
• Author protection — it raises the cost and risk of redistributing paid code.

Traceability — how a leak is traced

The in-code trace id is a one-way HMAC of the buyer and module (HMAC-SHA256 of userId:moduleId). This has two useful properties:

• Nothing is stored per-buyer. The id is deterministic, so it can always be recomputed — the platform doesn't keep a database of watermarks.
• It can't be reversed or forged. The buyer's identity can't be derived from the id, and no valid mark can be produced without the secret.

To trace a leak, CodeSCE reads the mark from the leaked file and recomputes the expected mark for each buyer of that module until it finds the match. The watermark secret is kept separate from the login/session secret, so even a leak of one doesn't enable forging the other.

Next step

Continue to Fraud Protection →.