From 3ce3d46baad0c3e85b6e6603628ea777e8d0b9e0 Mon Sep 17 00:00:00 2001
From: Abdullah Sultan <abdullahmsultan1@gmail.com>
Date: Thu, 6 Aug 2026 12:49:52 -0500
Subject: [PATCH] Add DMCA and EU DSA safe-harbor pages, plus an internal abuse
 runbook
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Crosscode stores files users upload, which makes the provider a hosting
service. Both the US §512(c) safe harbor and the DSA hosting regime attach
only if specific things are done in advance, and both are conditional on
actually acting on a notice.

- docs/dmca.md: the six §512(c)(3)(A) notice elements, the designated agent's
  contact, the §512(g)(3) counter-notice procedure and its 10-14 business day
  statutory window, and a three-strike repeat-infringer policy. Flags that
  registering the agent with the Copyright Office is an owner action, not a
  code change, and that the registration expires after three years — an
  expired one is legally identical to none.
- docs/dsa-contact.md: Art. 11/12 single point of contact (abuse@, English),
  Art. 16 notice-and-action, Art. 17 statement of reasons, and the Art. 15(2)
  micro-enterprise transparency exemption stated rather than assumed. Art. 13
  EU legal representative marked as consciously deferred.
- docs/abuse-handling.md: internal runbook, repo-only, not registered in
  GENERATED_PAGES and not linked from the footer. Names the actual tables and
  statements a takedown needs, and ends with ten capability gaps the service
  cannot currently close — most importantly that deleting one file's changes
  from the middle of a room's sequence silently breaks the contiguity
  listChanges relies on, so whole-project deletion is the only safe
  granularity today.

Plumbing: both public pages registered in GENERATED_PAGES, the docs sidebar,
the vite rollup inputs, the landing footer's Trust column, and .gitignore
(the generated HTML is build output like every other page's).

generate-docs.mjs now strips HTML comments before rendering. The renderer runs
with html:false, so a `<!-- LAWYER: ... -->` note left in a source file was
being escaped and printed on the published page as visible text.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 apps/docs-site/.gitignore                |   2 +
 apps/docs-site/index.html                |   2 +
 apps/docs-site/scripts/generate-docs.mjs |  32 ++-
 apps/docs-site/vite.config.js            |   2 +
 docs/abuse-handling.md                   | 288 +++++++++++++++++++++++
 docs/dmca.md                             | 148 ++++++++++++
 docs/dsa-contact.md                      | 149 ++++++++++++
 7 files changed, 620 insertions(+), 3 deletions(-)
 create mode 100644 docs/abuse-handling.md
 create mode 100644 docs/dmca.md
 create mode 100644 docs/dsa-contact.md

diff --git a/apps/docs-site/.gitignore b/apps/docs-site/.gitignore
index 8bba99b..5280e74 100644
--- a/apps/docs-site/.gitignore
+++ b/apps/docs-site/.gitignore
@@ -11,6 +11,8 @@ dist
 /docs/support.html
 /docs/terms.html
 /docs/refund-policy.html
+/docs/dmca.html
+/docs/dsa-contact.html
 /public/docs/
 /public/llms.txt
 /public/llms-full.txt
diff --git a/apps/docs-site/index.html b/apps/docs-site/index.html
index e906507..0e98395 100644
--- a/apps/docs-site/index.html
+++ b/apps/docs-site/index.html
@@ -502,6 +502,8 @@ <h2>Trust</h2>
         <a href="/docs/privacy.html">Privacy</a>
         <a href="/docs/limitations.html">Limitations</a>
         <a href="/docs/terms.html">Terms</a>
+        <a href="/docs/dmca.html">Copyright and DMCA</a>
+        <a href="/docs/dsa-contact.html">EU DSA contact</a>
         <a href="/docs/support.html">Support</a>
       </nav>
       <nav class="footer-col" aria-label="More">
diff --git a/apps/docs-site/scripts/generate-docs.mjs b/apps/docs-site/scripts/generate-docs.mjs
index b65cc09..7576729 100644
--- a/apps/docs-site/scripts/generate-docs.mjs
+++ b/apps/docs-site/scripts/generate-docs.mjs
@@ -97,7 +97,9 @@ const NAV_GROUPS = [
     label: "Support & legal",
     links: [
       { href: "/docs/support.html", label: "Support", key: "support" },
-      { href: "/docs/terms.html", label: "Terms of Service", key: "terms" }
+      { href: "/docs/terms.html", label: "Terms of Service", key: "terms" },
+      { href: "/docs/dmca.html", label: "Copyright and DMCA", key: "dmca" },
+      { href: "/docs/dsa-contact.html", label: "EU DSA contact", key: "dsa-contact" }
     ]
   }
 ];
@@ -159,6 +161,22 @@ const GENERATED_PAGES = [
     title: "Terms of Service",
     mdFile: "terms.md",
     htmlOut: "terms.html",
+    nextHref: "/docs/dmca.html",
+    nextLabel: "Copyright and DMCA"
+  },
+  {
+    key: "dmca",
+    title: "Copyright and DMCA",
+    mdFile: "dmca.md",
+    htmlOut: "dmca.html",
+    nextHref: "/docs/dsa-contact.html",
+    nextLabel: "EU DSA contact"
+  },
+  {
+    key: "dsa-contact",
+    title: "EU DSA contact",
+    mdFile: "dsa-contact.md",
+    htmlOut: "dsa-contact.html",
     nextHref: "/docs/index.html",
     nextLabel: "Docs overview"
   }
@@ -247,13 +265,21 @@ ${bodyHtml}
 `;
 }
 
+// Legal docs carry `<!-- LAWYER: ... -->` notes flagging choices that need review. The
+// renderer runs with html:false, so a comment left in would be escaped and printed on the
+// page as visible text. Strip them from everything published; the repo's docs/*.md keeps
+// them, which is where they are meant to be read.
+function stripHtmlComments(markdown) {
+  return markdown.replace(/^[ \t]*<!--[\s\S]*?-->[ \t]*\r?\n?/gm, "");
+}
+
 function generateDocPages() {
   mkdirSync(siteDocsDir, { recursive: true });
   mkdirSync(publicDocsDir, { recursive: true });
 
   for (const p of GENERATED_PAGES) {
     const mdPath = path.join(rootDocsDir, p.mdFile);
-    const mdContent = readFileSync(mdPath, "utf8");
+    const mdContent = stripHtmlComments(readFileSync(mdPath, "utf8"));
     const bodyHtml = md.render(mdContent);
     const mdOutName = p.mdOutName ?? p.mdFile;
     const mdHref = `/docs/${mdOutName}`;
@@ -360,7 +386,7 @@ function generateLlmsFullTxt() {
   ];
 
   for (const s of sections) {
-    const content = readFileSync(path.join(rootDocsDir, s.file), "utf8");
+    const content = stripHtmlComments(readFileSync(path.join(rootDocsDir, s.file), "utf8"));
     parts.push("---", "", `<!-- source: docs/${s.file} -->`, "", content.trimEnd(), "");
   }
 
diff --git a/apps/docs-site/vite.config.js b/apps/docs-site/vite.config.js
index 04801a3..5726ee6 100644
--- a/apps/docs-site/vite.config.js
+++ b/apps/docs-site/vite.config.js
@@ -23,6 +23,8 @@ export default defineConfig({
         limitations: resolve(root, "docs/limitations.html"),
         support: resolve(root, "docs/support.html"),
         terms: resolve(root, "docs/terms.html"),
+        dmca: resolve(root, "docs/dmca.html"),
+        dsaContact: resolve(root, "docs/dsa-contact.html"),
         signin: resolve(root, "auth/signin.html"),
         signup: resolve(root, "auth/signup.html"),
         passwordReset: resolve(root, "auth/reset.html"),
diff --git a/docs/abuse-handling.md b/docs/abuse-handling.md
new file mode 100644
index 0000000..b58c7f7
--- /dev/null
+++ b/docs/abuse-handling.md
@@ -0,0 +1,288 @@
+# Abuse handling runbook (internal)
+
+**Internal document. Not published to the docs site, not linked from the footer.** It stays
+in the repository because it needs to be version-controlled and reviewable, not because it is
+for users. The user-facing pages are [Copyright and DMCA](./dmca.md) and
+[EU DSA contact](./dsa-contact.md).
+
+Both safe harbors those pages rely on are conditional on **actually acting**. §512(c) needs
+expeditious action and a reasonably implemented repeat-infringer policy; DSA Art. 6 protects
+only until you have actual knowledge and then do nothing. This file is the procedure that
+makes those true. It is also honest about what the service cannot currently do — the
+[gap list](#capability-gaps) at the end is the most useful part of this document.
+
+---
+
+## 1. A notice arrives
+
+| Inbox | What it is | Page |
+| --- | --- | --- |
+| `legal@getcrosscode.dev` | US copyright takedown, counter-notice | [dmca.md](./dmca.md) |
+| `abuse@getcrosscode.dev` | Illegal content under the DSA, and authority contact | [dsa-contact.md](./dsa-contact.md) |
+| `security@getcrosscode.dev` | Vulnerability disclosure — **not this runbook**, see SECURITY.md | — |
+| `support@getcrosscode.dev` | Ordinary support — **not this runbook** | [support.md](./support.md) |
+
+All of these forward to one personal inbox. Misrouted mail is common; route it by what the
+notice actually asks for, not by which address it arrived at.
+
+**First action, same day, always: acknowledge receipt.** Reply from the address it came to,
+say it was received, say a decision follows within 3 business days. The acknowledgement is
+required by DSA Art. 16(4) and it is the single cheapest thing that makes the rest of the
+process defensible. Do it before you start assessing.
+
+## 2. Validate the notice
+
+Check it against the statutory elements. Do not skip this: acting on an invalid notice is how
+you end up removing content you had no basis to remove, and §512(g)(1)/(4) only protects
+good-faith removal made in response to a notice.
+
+- **Copyright** — the six elements of §512(c)(3)(A), enumerated in [dmca.md](./dmca.md#how-to-send-a-notice).
+- **Illegal content** — the four elements of DSA Art. 16(2), enumerated in
+  [dsa-contact.md](./dsa-contact.md#reporting-illegal-content-article-16).
+
+If an element is missing, reply naming **which** element and what would fix it. Do not act on
+the notice yet, and do not silently drop it. Log the exchange either way.
+
+**Locating the content.** Every valid notice must give you `owner/repo`, the branch, and the
+file paths, because that is what the data is keyed on. With those:
+
+```sql
+-- Which project is it?
+SELECT id, name, repo, created_by, created_at FROM projects WHERE repo = $1;
+
+-- Who is in it?
+SELECT m.user_id, m.role, u.github_login, u.email
+  FROM project_members m JOIN users u ON u.id = m.user_id
+ WHERE m.project_id = $1;
+
+-- The changes themselves. File content lives only in file_versions.version (jsonb):
+-- {path, op, baseHash, contentHash, content | patch}.
+SELECT sequence, replica_id, created_at,
+       version->>'path' AS path, version->>'op' AS op,
+       length(version->>'content') AS content_bytes
+  FROM file_versions
+ WHERE project_id = $1 AND branch = $2 AND version->>'path' = ANY($3)
+ ORDER BY sequence;
+```
+
+Run these against production Postgres (Supabase SQL editor). There is no admin API and no
+`crosscode admin` command — see [gap G1](#capability-gaps).
+
+**Expect the content to be gone already.** The change log is retained about 7 days
+(`HISTORY_RETENTION_DAYS` in `apps/service/src/store.ts`). A notice about a change from last
+month is a notice about rows that no longer exist. That is a legitimate and complete answer
+to a takedown — say so, and say that the user's own Git repository is not ours and is not
+affected. Check [gap G9](#capability-gaps) before relying on the 7 days as fact.
+
+## 3. Disable access to the content
+
+Ordered from the operation the service actually supports well to the one it barely supports.
+Read [gap G3](#capability-gaps) before doing anything at file granularity.
+
+**a. Delete the whole project — the only clean operation.**
+
+```sql
+DELETE FROM projects WHERE id = $1;
+```
+
+`project_members`, `invites`, `replicas`, and `file_versions` are all
+`REFERENCES projects (id) ON DELETE CASCADE` (`apps/service/migrations/001_sync.sql`), so one
+statement removes every stored byte for that project. Members' daemons then fail
+`requireMembership` on their next request. This is the operation to prefer when the whole
+project is the problem.
+
+**b. Remove one member's access.**
+
+```sql
+DELETE FROM project_members WHERE project_id = $1 AND user_id = $2;
+```
+
+`PgStore.requireMembership` is the single authorization check on every project-scoped route
+(`store.ts`), so their next HTTP request is refused. It does **not** close an open websocket —
+membership is checked once at subscribe and never again ([gap G7](#capability-gaps)). Follow
+it with a service redeploy if the removal needs to bite immediately.
+
+**c. Delete specific changes — only if you have read G3.**
+
+```sql
+DELETE FROM file_versions
+ WHERE project_id = $1 AND branch = $2 AND version->>'path' = ANY($3);
+```
+
+This removes the content but can silently break the room for everyone in it. Prefer (a) or
+(b) unless the notice is genuinely narrow and the project is otherwise legitimate; if you do
+run it, tell the project's members that they should stop and restart their daemons so they
+resynchronize from full content.
+
+**Privileges.** The runtime role deliberately has no `UPDATE`/`DELETE`/`TRUNCATE` on
+`file_versions`; `assertRuntimePrivileges()` refuses to start the service if it does. Every
+statement above therefore runs as the **migration role**, not the role the service uses. That
+is the right security posture and it means the takedown path is not exercised by anything
+routine — see [gap G2](#capability-gaps).
+
+## 4. Record the strike
+
+There is no strikes table ([gap G5](#capability-gaps)). Until there is, keep the record in a
+private repository or a file the operator controls, one row per action, containing:
+
+- date received, date acted, inbox it arrived at
+- notice sender and the full text of the notice
+- `owner/repo`, branch, paths, project id, and the user id acted against
+- the decision, and the reason for it
+- whether a counter-notice or appeal followed, and how it resolved
+- whether the strike was later removed, and why
+
+Strike accounting is in [dmca.md](./dmca.md#repeat-infringers): a strike is recorded on a
+valid, unwithdrawn, un-reversed takedown; **three strikes** against one account, or one
+deliberate and clear-cut infringement, terminates it. That threshold is only meaningful if
+the record above actually exists, which is the whole reason §512(i) says "reasonably
+implemented" rather than "adopted".
+
+## 5. Terminate an account
+
+Order matters — `users.id` is referenced by `projects.created_by`, `invites.created_by`,
+`invites.redeemed_by`, `replicas.user_id`, and `project_members.user_id`, and **none of those
+cascade**. A bare `DELETE FROM users` fails on a foreign key.
+
+```sql
+-- 1. their projects (cascades to members, invites, replicas, file_versions)
+DELETE FROM projects WHERE created_by = $1;
+-- 2. memberships and checkouts in other people's projects
+DELETE FROM replicas WHERE user_id = $1;
+DELETE FROM project_members WHERE user_id = $1;
+-- 3. invites they created or redeemed
+DELETE FROM invites WHERE created_by = $1;
+UPDATE invites SET redeemed_by = NULL WHERE redeemed_by = $1;
+-- 4. finally the row itself
+DELETE FROM users WHERE id = $1;
+```
+
+**Then delete the identity in Supabase Auth** (dashboard → Authentication → Users). Skipping
+this means they sign in again and `upsertUser` recreates the row on their first request, so
+the termination undoes itself. Even with it done, an access token already issued keeps
+working until it expires: verification is a local JWKS check in `apps/service/src/auth.ts`
+with no revocation lookup ([gap G6](#capability-gaps)). Project-scoped routes still fail,
+because those hit `requireMembership` against the database on every request.
+
+This same procedure is what answers a user's own deletion request under
+[privacy.md](./privacy.md#deleting-your-data). It is the only account-deletion path there is.
+
+## 6. Issue the statement of reasons
+
+Required by DSA Art. 17 for **every** restriction — content removal, project deletion,
+account suspension or termination — whatever prompted it. Email it to the address on the
+account. Contents are listed in
+[dsa-contact.md](./dsa-contact.md#statement-of-reasons-article-17): what was restricted,
+whether it is permanent, the facts relied on, the legal or contractual ground, and how to
+appeal. State explicitly that no automated means were used, because none are.
+
+For copyright specifically, also send the complainant's notice to the affected user and point
+them at the [counter-notice procedure](./dmca.md#counter-notice). If a counter-notice arrives,
+forward it to the complainant and hold restoration for **not less than 10 and not more than 14
+business days** unless they file suit. Diary the date; the window is statutory.
+
+We do **not** submit statements of reasons to the Commission's DSA Transparency Database:
+Art. 24(5) requires it, Art. 19 exempts micro enterprises, and the exemption is relied on.
+
+## 7. Keep the record
+
+Keep everything in step 4 — notices, decisions, statements of reasons, dates — for **three
+years** from the date of the action. Reasons, in order of how much they matter:
+
+- The repeat-infringer policy is worthless without a history to count strikes against.
+- §512(f) misrepresentation claims and DSA appeals both look backwards.
+- If Crosscode ever crosses the micro-enterprise threshold, DSA Art. 15 transparency
+  reporting starts, and it is asked for the counts this record already holds.
+
+Note the asymmetry: the *content* is gone in ~7 days, but the *record about the content*
+lives three years. That is intentional and worth keeping intentional — the record should hold
+paths, hashes, and decisions, **not** copies of the file contents themselves.
+
+---
+
+## Capability gaps
+
+Operations this runbook needs that the service cannot currently perform. Written down rather
+than designed around, because an honest gap list is what makes the procedure usable under
+time pressure.
+
+**G1 — No admin surface at all.** The routes in `apps/service/src/http.ts` are health, the
+three device-auth routes, create project, create invite, redeem invite, register replica, and
+publish/list changes. There is no admin route, no `crosscode admin` subcommand, and no
+moderation UI. Every operation in this runbook is hand-written SQL typed into a production
+database console: no dry-run, no confirmation, no undo, and no audit trail of what the
+operator did.
+
+**G2 — The takedown path runs on an elevated credential and is never exercised.** The runtime
+role cannot delete from `file_versions` by design (`assertRuntimePrivileges`). Correct
+posture, but it means every deletion here needs the migration role, and nothing in CI or in
+normal operation ever runs these statements. The first time they are used will be under a
+legal deadline.
+
+**G3 — No way to disable one file without risking the room.** This is the significant one.
+`listChanges` assumes retention only ever deletes a *prefix* of a room's sequence: it derives
+`resyncFrom` from `min(sequence)` and answers `cursor-too-old` only when a cursor falls below
+it. Deleting a row from the *middle* produces a hole that is served as an ordinary page with
+the row simply absent — replicas never see that change and are never told to resynchronize.
+Worse, a later change may be a `patch` chained through the deleted version's `contentHash`
+(`packages/protocol/src/sync.ts`), and that patch can no longer be applied. Net effect: a
+per-file takedown can silently corrupt a project for every member. **Today the only safe
+takedown granularity is the whole project.** Fixing this properly means either a tombstone
+(replace `version` with a redacted marker at the same sequence, preserving contiguity) or a
+`resyncFrom` watermark the service can raise by hand.
+
+**G4 — Nothing prevents re-publication.** There is no per-project or per-path blocklist.
+Delete the rows and the same daemon republishes the same file on its next settled edit. Access
+removal (project deletion or member removal) is the only durable stop, which is why step 3
+prefers it.
+
+**G5 — No strike, suspension, or termination state in the database.** No column, no table, no
+audit log. `projects.plan` exists and is unread, but nothing records that an account was
+warned, struck, or terminated. The repeat-infringer policy in `dmca.md` is therefore
+implemented entirely outside the system, in whatever record step 4 is kept in.
+
+**G6 — Termination is not immediate.** Supabase access tokens are verified locally against
+the JWKS (`apps/service/src/auth.ts`) with no revocation check on the request path. A deleted
+user's existing token stays valid until it expires; the access-token lifetime is set in the
+Supabase project, not in this repository. Project-scoped routes do fail immediately, because
+`requireMembership` reads the database on every request.
+
+**G7 — Open websockets survive membership removal.** `subscribe()` in
+`apps/service/src/ws.ts` calls `requireMembership` once during the handshake and never again.
+A removed member with a live socket keeps receiving the room's broadcasts until the socket
+drops or the service redeploys. There is no way to kick a connection.
+
+**G8 — Account deletion is a multi-statement manual sequence with no cascade.** Step 5 exists
+only because `users` has no cascading deletes. It is easy to get wrong under pressure and it
+is the same path that answers a user's privacy request, so it is not only a moderation
+concern.
+
+**G9 — There is no retention job in this repository.** `docs/privacy.md` and
+`docs/terms.md` both say change history is pruned after about seven days by a scheduled job.
+`HISTORY_RETENTION_DAYS = 7` exists in `store.ts` and `file_versions_created_at_idx` exists to
+support the sweep, but there is no `pg_cron` migration, no Vercel cron entry
+(`apps/docs-site/vercel.json` has none), and no GitHub Actions workflow that deletes from
+`file_versions` — the three workflows are `ci`, `smoke`, and `uptime`. Either the job runs
+somewhere outside version control, in which case it should be recorded here, or content is
+being retained longer than the privacy page promises. **Confirm this before telling any
+notice-sender that content has aged out.**
+
+<!-- LAWYER: G9 is the one with legal exposure beyond this runbook — docs/privacy.md makes a
+     retention promise to users, and a promise a system does not keep is a
+     misrepresentation question, not just a bug. Flag to whoever owns the privacy suite. -->
+
+**G10 — No trusted-flagger or authority-verification path.** DSA Art. 22 trusted flaggers are
+an online-platform obligation and do not apply here, but there is also no way to verify that
+a message claiming to be from a Member State authority is one. At this scale that is a
+judgement call made by reading the email; it is listed so the absence is deliberate.
+
+## Before this is relied on
+
+This runbook uses no placeholder tokens of its own. It does depend on things that are not
+done yet:
+
+- The DMCA designated agent must be **registered** — see the checklist at the end of
+  [dmca.md](./dmca.md#before-this-takes-effect). Until then this procedure is good practice
+  rather than a safe harbor.
+- Decide where the step 4 record lives, and write the location into this file.
+- Resolve **G9** — find the retention job or build it — before the first notice arrives.
diff --git a/docs/dmca.md b/docs/dmca.md
new file mode 100644
index 0000000..7c1f592
--- /dev/null
+++ b/docs/dmca.md
@@ -0,0 +1,148 @@
+# Copyright and DMCA
+
+Crosscode's hosted coordination service stores files that users choose to sync. If you
+believe something stored there infringes your copyright, this page is how you tell us, and
+what we do about it.
+
+> **Not yet in force.** The designated agent below has **not yet been registered** with the
+> US Copyright Office. Until that registration exists, the §512(c) safe harbor does not
+> attach, no matter what this page says. See
+> [Before this takes effect](#before-this-takes-effect).
+
+- **Effective date:** {{EFFECTIVE_DATE}}
+- **Designated agent:** {{PROVIDER_NAME}}
+- **Address for notices:** {{PROVIDER_ADDRESS}}
+- **Email:** `legal@getcrosscode.dev`
+
+## What this page covers, and what it does not
+
+It covers **content users store on the hosted service**: the uncommitted working-tree files
+their daemons publish, and the project and repository names attached to them. That is
+material stored at a user's direction, which is what 17 U.S.C. §512(c) is about.
+
+It does **not** cover Crosscode's own software. The CLI, daemon, and MCP server are ours and
+are published under the MIT Licence. A complaint about that code is an ordinary dispute with
+us, not a takedown request, and belongs at `legal@getcrosscode.dev` in plain prose.
+
+It also does not reach copies we never had. Crosscode syncs between checkouts; every member
+of a project holds a full Git repository on their own disk. Removing content from our
+service removes it from our service. It cannot un-copy what someone already cloned. We would
+rather say that here than let a notice-sender believe otherwise.
+
+## How to send a notice
+
+Email `legal@getcrosscode.dev`, or post to the address above. A notice must include all six
+elements that §512(c)(3)(A) requires. A notice missing any of them is not a valid notice, and
+we will tell you which element is missing rather than ignoring it.
+
+1. **A signature** — physical or electronic — of the copyright owner, or of a person
+   authorised to act for them.
+2. **Identification of the copyrighted work** you say is infringed. If several works on the
+   same project are covered, a representative list is enough.
+3. **Identification of the infringing material**, with enough detail for us to find it. For
+   Crosscode that means: the repository as `owner/repo`, the branch, and the file paths. We
+   store changes keyed on exactly those three things, so a notice giving them is one we can
+   act on and a notice without them usually is not.
+4. **Your contact details**: address, telephone number, and email.
+5. **A statement** that you believe in good faith that the use is not authorised by the
+   copyright owner, its agent, or the law.
+6. **A statement that the information in the notice is accurate**, and — under penalty of
+   perjury — that you are the owner or are authorised to act for them.
+
+Misrepresenting that material is infringing carries liability for damages under §512(f). We
+mention it because it is a real provision, not to discourage a genuine notice.
+
+## What we do when a notice arrives
+
+- **We acknowledge receipt by email**, to the address in the notice.
+- **We act expeditiously.** In practice: a valid notice is assessed and access to the
+  identified material disabled **within 3 business days** of receipt. Crosscode is run by one
+  person, and 3 business days is what one person can honestly commit to; if a notice arrives
+  during an absence long enough to break that, the acknowledgement will say so.
+- **We notify the affected user** with the reason, the material affected, and a copy of the
+  notice, and we tell them how to counter-notify.
+- **We record a strike** against the account.
+- **We keep the notice, our decision, and the dates**, so a pattern of repeat infringement is
+  something we can actually establish rather than assert.
+
+The internal procedure is written down in `docs/abuse-handling.md` in the repository,
+including where it is currently thin. An undocumented procedure is one that fails the first
+time it is needed.
+
+## Counter-notice
+
+If your content was removed and you believe that was a mistake or a misidentification, send a
+counter-notice to `legal@getcrosscode.dev`. Under §512(g)(3) it must contain:
+
+1. **Your signature**, physical or electronic.
+2. **Identification of the material** that was removed, and where it was before removal —
+   again `owner/repo`, branch, and paths.
+3. **A statement under penalty of perjury** that you have a good-faith belief the material
+   was removed as a result of mistake or misidentification.
+4. **Your name, address, and telephone number**, plus your consent to the jurisdiction of the
+   US Federal District Court for the district of your address — or, if your address is
+   outside the United States, of any district in which we may be found — and your consent to
+   accept service of process from the person who sent the original notice.
+
+On receiving a valid counter-notice we forward it to the original complainant and tell them
+we will restore the material in **not less than 10 and not more than 14 business days**,
+unless they first tell us they have filed a court action seeking to restrain the activity.
+That window is statutory, not a policy of ours, and we cannot shorten it.
+
+<!-- LAWYER: §512(g) restoration assumes the material still exists to restore. Change
+     history is pruned after about 7 days, so by the end of a 10-14 business day window the
+     removed changes are gone regardless of the outcome. The counter-notifier's working tree
+     still holds their own work, so nothing of theirs is actually lost — but the sentence
+     "we will restore" may need rewording to "we will re-enable syncing for" to stay
+     accurate. Confirm the phrasing. -->
+
+## Repeat infringers
+
+We terminate the accounts of repeat infringers in appropriate circumstances, as §512(i)
+requires. Concretely:
+
+- A **strike** is recorded when we disable access to content in response to a valid notice
+  that is not withdrawn and not reversed by a counter-notice.
+- **Three strikes** against one account, or a single deliberate and clear-cut infringement,
+  results in termination of that account and of the projects it owns.
+- A strike is removed if the notice behind it is withdrawn, if a counter-notice restores the
+  material and the complainant does not sue, or if we conclude the notice was wrong.
+- **Terminated means terminated**: the account and its projects are deleted, not suspended
+  pending appeal. You may write to `legal@getcrosscode.dev` to contest it, and we will
+  answer.
+
+A project's owner is accountable for content their project stores, but a strike attaches to
+the account that published the change, because that is what our change log records.
+
+## Registration — an owner action, not a code change
+
+Two of the four things §512(c) requires cannot be done by editing this repository. They are
+the ones providers most often skip, and skipping either means the safe harbor never attaches
+at all:
+
+1. **Register the designated agent** with the US Copyright Office at
+   <https://www.copyright.gov/dmca-directory/>. It costs about $6 and takes half an hour. It
+   requires a **public physical address** — the address in the directory is published, so it
+   must be one you are willing to have on a public register.
+2. **Renew it every three years.** The registration expires. An **expired registration is
+   legally identical to no registration**, and the expiry is silent: nothing breaks, no
+   deploy fails, no alert fires. A provider who registered once and forgot is a provider with
+   no safe harbor, and that is the usual way it is lost.
+
+Publishing this page satisfies the second requirement of §512(c) (the agent's contact
+information must be available on the service). Having a repeat-infringer policy and acting on
+notices are the other two, and they are only real if the procedure in
+`docs/abuse-handling.md` is actually followed.
+
+## Before this takes effect
+
+- `{{PROVIDER_NAME}}` — the legal name of the individual provider, matching the name filed
+  with the Copyright Office.
+- `{{PROVIDER_ADDRESS}}` — the public postal address for legal notices, matching the address
+  filed with the Copyright Office.
+- `{{EFFECTIVE_DATE}}` — the date this page takes effect. Set it no earlier than the date the
+  Copyright Office registration is confirmed.
+- **Register the designated agent** at <https://www.copyright.gov/dmca-directory/>, and put a
+  calendar reminder **three years out** for renewal.
+- **Remove the "Not yet in force" banner** at the top of this page once the registration is
+  confirmed.
diff --git a/docs/dsa-contact.md b/docs/dsa-contact.md
new file mode 100644
index 0000000..a8b072d
--- /dev/null
+++ b/docs/dsa-contact.md
@@ -0,0 +1,149 @@
+# EU Digital Services Act: contact and notice-and-action
+
+Crosscode's hosted service stores files at the request of the people who use it. Under
+Regulation (EU) 2022/2065 (the Digital Services Act) that makes it a **hosting service**, and
+a handful of obligations follow regardless of how small the provider is. This page is how we
+meet them.
+
+- **Effective date:** {{EFFECTIVE_DATE}}
+- **Provider:** {{PROVIDER_NAME}}, an individual acting as a sole proprietor
+- **Postal address:** {{PROVIDER_ADDRESS}}
+- **Single point of contact:** `abuse@getcrosscode.dev`
+
+Crosscode is not established in the EU. The DSA applies anyway, because the service is
+offered to users in the EU.
+
+## Single point of contact (Articles 11 and 12)
+
+`abuse@getcrosscode.dev` is the single electronic point of contact for **both**:
+
+- **Member State authorities, the Commission, and the European Board for Digital Services**
+  (Art. 11), and
+- **users of the service** (Art. 12).
+
+There is one address rather than two because there is one person reading it. Splitting it
+would create a second inbox that is checked less often, which is worse for everyone.
+
+**Language:** notices and correspondence are accepted and answered in **English**. This is
+the only language the provider speaks well enough to act on a legal notice in, and Art. 11(3)
+and 12(3) require us to say so rather than leave you to guess.
+
+This is a direct communication channel with a human, not a bot, and not a route into a
+support queue. So that it can be found without having to ask for it, the same address is
+published as a plain `mailto:` link — <mailto:abuse@getcrosscode.dev> — on this page, in the
+site footer under "Trust", and as raw markdown at `/docs/dsa-contact.md`.
+
+## Reporting illegal content (Article 16)
+
+Anyone — you do not need an account — may report content stored by Crosscode that they
+believe is illegal. Email `abuse@getcrosscode.dev`.
+
+**What your notice must contain.** Art. 16(2) sets this out, and a notice with all four
+elements is one we can act on:
+
+1. **A sufficiently substantiated explanation** of why you believe the content is illegal.
+2. **A clear indication of the exact location** of the content. For Crosscode that is: the
+   repository as `owner/repo`, the branch, and the file paths. Our change log is keyed on
+   those three, so a notice without them usually cannot be acted on.
+3. **Your name and email**, unless the report concerns child sexual abuse material or one of
+   the other offences in Articles 3 to 7 of Directive 2011/93/EU, where you may report
+   anonymously.
+4. **A statement** that you believe in good faith that the information in the notice is
+   accurate and complete.
+
+**What happens next.**
+
+- We **confirm receipt** by email, without undue delay, to the address in the notice.
+- We **assess** the notice against the elements above and against what the content actually
+  is.
+- We **tell you the decision** and the reasons for it, and note any use of automated means in
+  reaching it. There are none: every decision here is made by a person reading the notice.
+- If we act, the affected user gets a **statement of reasons** (below).
+
+A notice that gives us actual knowledge of illegal content is what removes the Art. 6 hosting
+liability shield if we do nothing about it. That is the whole reason this address exists and
+is monitored.
+
+**No ticketing system.** Reports arrive by email and are worked through a written internal
+procedure (`docs/abuse-handling.md` in the repository). Art. 16 requires a mechanism that is
+easy to access and user-friendly and allows notices to be submitted electronically; email
+plus a documented procedure is that, at this scale. We would rather describe what exists than
+name a system we have not built.
+
+## Statement of reasons (Article 17)
+
+Whenever we restrict content or an account — remove or disable access to specific files,
+suspend or terminate an account or a project — the affected user receives a clear and
+specific statement of reasons, by email to the address on their account. It says:
+
+- **What was restricted**: the repository, branch, and paths, or the account.
+- **Whether it is still visible to others**, and whether the restriction is temporary or
+  permanent.
+- **The facts and circumstances** we relied on, including whether the decision followed a
+  notice from someone else, and whether automated means were used. They were not.
+- **The legal ground** — the specific provision the content is said to break, and why we
+  consider it applicable — **or the contractual ground**, meaning the clause of the
+  [Terms of Service](/docs/terms.html) relied on, and why.
+- **How to appeal**: reply to the email, or write to `legal@getcrosscode.dev`. We answer.
+  Users also keep their right to go to a court, and Art. 21 out-of-court dispute settlement
+  is unaffected by anything we say here.
+
+We do not submit these statements to the Commission's DSA Transparency Database. Art. 24(5)
+requires that, but Art. 19 exempts micro and small enterprises from that Section, and
+Crosscode is one person with no employees and no revenue.
+
+## Transparency reports (Article 15) — exemption relied on
+
+We do not publish annual transparency reports. **Art. 15(2) exempts micro and small
+enterprises**, and Crosscode qualifies: it is run by a single individual, with no employees,
+and it earns nothing — well under the Commission Recommendation 2003/361/EC thresholds for a
+micro enterprise (fewer than 10 staff and turnover at or below €2 million).
+
+We are stating the exemption rather than staying quiet about it, because the exemption stops
+applying the moment the business grows past the threshold, and a documented reliance is
+easier to revisit than an unexplained silence. If Crosscode ever employs anyone or takes
+revenue, this section is the thing to re-check.
+
+We keep the underlying records anyway — notices received, actions taken, dates — because
+`docs/abuse-handling.md` requires it and because the count is the first thing anyone will ask
+for. See that runbook for the retention period.
+
+## Deferred: EU legal representative (Article 13)
+
+Article 13 requires a provider that is not established in the EU but offers services there to
+**designate a legal or natural person in a Member State as its legal representative**, and to
+notify their details to that Member State's Digital Services Coordinator.
+
+**We have not done this, and the decision is deliberate.** Designating a representative means
+a paid service provider in an EU state and an ongoing cost, for a free, pre-1.0 side project
+with no EU user base to speak of. The provider has accepted that exposure knowingly rather
+than overlooked it.
+
+<!-- LAWYER: Art. 13 has no micro-enterprise exemption — unlike Art. 15 and the Section 3
+     obligations, it applies on its face to every non-EU provider offering services in the
+     EU, and the representative can be held liable for non-compliance. The judgement being
+     made is a risk one (enforcement against a free, no-revenue, sub-100-user project is
+     unlikely) rather than a legal one. Confirm that framing, and confirm the trigger for
+     revisiting it: first paying EU user, or first EU enforcement contact, whichever is
+     first. -->
+
+## What this page is not
+
+It is not a route for copyright takedowns under US law — those go to `legal@getcrosscode.dev`
+and are described in [Copyright and DMCA](/docs/dmca.html). It is not support:
+`support@getcrosscode.dev` is for that. It is not security disclosure:
+`security@getcrosscode.dev` and
+[SECURITY.md](https://github.com/amsultan2010/crosscode/blob/main/SECURITY.md) are for that.
+
+Crosscode is a coordination service, not a public platform. There is no feed, no public
+content, no recommender system, and no advertising, so the DSA obligations attached to online
+platforms and to very large ones do not apply. What does apply is what is on this page.
+
+## Before this takes effect
+
+- `{{PROVIDER_NAME}}` — the legal name of the individual provider.
+- `{{PROVIDER_ADDRESS}}` — the postal address for legal notices.
+- `{{EFFECTIVE_DATE}}` — the date this page takes effect.
+- Confirm the **Art. 15(2) micro-enterprise exemption** still holds on the effective date.
+- Confirm the **Art. 13 legal representative** deferral is still the decision, and record the
+  trigger for revisiting it.