diff --git a/HANDOFF.md b/HANDOFF.md new file mode 100644 index 0000000..3d5f70d --- /dev/null +++ b/HANDOFF.md @@ -0,0 +1,61 @@ +# Handoff from workstream B (privacy suite) + +Changes I wanted to make in files another workstream owns. Not made. + +## `docs/terms.md` — workstream A + +1. **Incorporate the DPA by reference.** `docs/dpa.md` is written to apply automatically + ("accept-by-reference from the terms"), but nothing in the terms currently says so, which + means it does not actually apply. Add to §5 (*Your content, and who owns it*) or §1: + + > Where the files you sync contain personal data belonging to other people, you are the + > controller of that data and we are your processor. The [Data Processing + > Agreement](/docs/dpa.html) sets out the terms on which we process it and forms part of + > these terms. You do not need to sign or request it. + +2. **Point at the new privacy pages.** §6 and the closing links reference + `docs/privacy.md` only. Add `/docs/privacy-policy.html`, `/docs/cookies.html` and + `/docs/subprocessors.html`. + +3. **Age.** `docs/privacy-policy.md` §11 states minimum age 16 and cites terms §3. Keep the + two in step if §3 changes. + +## `docs/privacy.md` — a claim I could not verify + +Under *How long it is kept*: "Older changes are deleted by a scheduled job." + +**There is no such job in this repository.** I grepped the source tree for a cron entry, a +Vercel cron config, a scheduled function and a `DELETE FROM file_versions`, and queried +`cron.job` on the production Supabase database — the `pg_cron` schema does not exist there. +What the code does enforce is the *serving* side: `listChanges` refuses a cursor pointing at +history older than what survives, and reports `retentionDays: 7` +(`apps/service/src/store.ts:458`). + +I did not edit `privacy.md` beyond the cross-links my brief allows. I documented the gap +honestly in `docs/privacy-policy.md` §8 and flagged it with a `` comment. +Someone should either land the sweep as a scheduled job with a test, or soften the sentence +in `privacy.md`. + +## `apps/docs-site/scripts/generate-docs.mjs` — `stripHtmlComments`, shared with workstream C + +Workstream C's edits arrived in this worktree mid-run (Crosscode was syncing the two +checkouts). I removed C's page registrations from my branch so it builds standalone, but I +**kept** C's `stripHtmlComments()` helper — without it the `` notes in +my four pages render as escaped visible text on the published site, because the renderer +runs with `html: false`. If C's branch merges first, this is the same function twice and +the merge is a no-op. If mine merges first, C's is redundant. Either way, keep exactly one. + +## `docs/support.md` — whoever owns it + +It still contains the literal placeholder `[SUPPORT EMAIL]` in three table rows. The real +address is `support@getcrosscode.dev`. + +## `apps/docs-site/src/analytics.js` — workstream E + +`docs/cookies.md` is written for the post-removal state of `crosscode_distinct_id`, as my +brief instructs. If that removal does not land, the cookies page is wrong. Its "Before this +takes effect" checklist says so. + +Same file: `docs/observability.md` notes the module is not included on +`apps/docs-site/auth/signup.html`, so `sign_up_completed` never fires. Not mine to fix, but +it affects what the analytics section of the privacy policy describes. diff --git a/apps/docs-site/.gitignore b/apps/docs-site/.gitignore index 8bba99b..3c91044 100644 --- a/apps/docs-site/.gitignore +++ b/apps/docs-site/.gitignore @@ -11,6 +11,10 @@ dist /docs/support.html /docs/terms.html /docs/refund-policy.html +/docs/privacy-policy.html +/docs/cookies.html +/docs/subprocessors.html +/docs/dpa.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..f40cfae 100644 --- a/apps/docs-site/index.html +++ b/apps/docs-site/index.html @@ -500,6 +500,10 @@

Docs

Trust

Safety model Privacy + Privacy Policy + Cookies + Subprocessors + Data Processing Agreement Limitations Terms Support diff --git a/apps/docs-site/scripts/generate-docs.mjs b/apps/docs-site/scripts/generate-docs.mjs index b65cc09..2ab40ae 100644 --- a/apps/docs-site/scripts/generate-docs.mjs +++ b/apps/docs-site/scripts/generate-docs.mjs @@ -97,7 +97,11 @@ 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/privacy-policy.html", label: "Privacy Policy", key: "privacy-policy" }, + { href: "/docs/cookies.html", label: "Cookies", key: "cookies" }, + { href: "/docs/subprocessors.html", label: "Subprocessors", key: "subprocessors" }, + { href: "/docs/dpa.html", label: "Data Processing Agreement", key: "dpa" } ] } ]; @@ -159,6 +163,38 @@ const GENERATED_PAGES = [ title: "Terms of Service", mdFile: "terms.md", htmlOut: "terms.html", + nextHref: "/docs/privacy-policy.html", + nextLabel: "Privacy Policy" + }, + { + key: "privacy-policy", + title: "Privacy Policy", + mdFile: "privacy-policy.md", + htmlOut: "privacy-policy.html", + nextHref: "/docs/cookies.html", + nextLabel: "Cookies and local storage" + }, + { + key: "cookies", + title: "Cookies and local storage", + mdFile: "cookies.md", + htmlOut: "cookies.html", + nextHref: "/docs/subprocessors.html", + nextLabel: "Subprocessors" + }, + { + key: "subprocessors", + title: "Subprocessors", + mdFile: "subprocessors.md", + htmlOut: "subprocessors.html", + nextHref: "/docs/dpa.html", + nextLabel: "Data Processing Agreement" + }, + { + key: "dpa", + title: "Data Processing Agreement", + mdFile: "dpa.md", + htmlOut: "dpa.html", nextHref: "/docs/index.html", nextLabel: "Docs overview" } @@ -241,19 +277,34 @@ ${bodyHtml} `; } +// Legal docs carry `` 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]*[ \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 +411,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("---", "", ``, "", content.trimEnd(), ""); } diff --git a/apps/docs-site/vite.config.js b/apps/docs-site/vite.config.js index 04801a3..bd5f82f 100644 --- a/apps/docs-site/vite.config.js +++ b/apps/docs-site/vite.config.js @@ -23,6 +23,10 @@ export default defineConfig({ limitations: resolve(root, "docs/limitations.html"), support: resolve(root, "docs/support.html"), terms: resolve(root, "docs/terms.html"), + privacyPolicy: resolve(root, "docs/privacy-policy.html"), + cookies: resolve(root, "docs/cookies.html"), + subprocessors: resolve(root, "docs/subprocessors.html"), + dpa: resolve(root, "docs/dpa.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.** + + + +**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/cookies.md b/docs/cookies.md new file mode 100644 index 0000000..0a14c99 --- /dev/null +++ b/docs/cookies.md @@ -0,0 +1,85 @@ +# Cookies and local storage + +> **Draft.** Not yet in force. See the checklist at the end. + +There is no cookie banner on this site, and this page still has to exist. The ePrivacy +Directive governs *any* storing of or access to information on your device — `localStorage` +and `sessionStorage` are covered exactly as cookies are — and disclosure is required even +where the item is strictly necessary and consent is not. + +So: every item, what it is for, how long it lasts, and whether it needs your consent. + +Effective from {{EFFECTIVE_DATE}}. + +## What we set + +| Name | Type | Set by | Purpose | Duration | Strictly necessary? | +| --- | --- | --- | --- | --- | --- | +| `sb-rzsslbmahvoesjxmgefr-auth-token` | `localStorage` | Supabase Auth (`@supabase/supabase-js`), on the sign-in, sign-up, reset, join and device pages | Holds your session and refresh token so you stay signed in across pages and can complete a CLI device sign-in | Until you sign out or the refresh token is revoked | **Yes.** Consent-exempt: without it there is no sign-in | +| `crosscode_analytics_once:` | `sessionStorage` | `apps/docs-site/src/analytics.js` | Marks that a funnel event (`sign_up_started`, `sign_up_completed`) has already been counted in this tab, so two triggers do not count it twice | Until the browser tab is closed | **No.** See "Why there is no banner" below | +| `__cf_bm` | Cookie, on `supabase.co` | Cloudflare, in front of Supabase | Bot management on the auth API the sign-in pages call | 30 minutes | **Yes.** Set by Supabase's infrastructure, not by Crosscode, and not readable by this site | + +That is the whole list. There is no analytics cookie, no advertising cookie, no +session-recording script, no chat widget, no CDN font, and no third-party tag: the only +external hostname in this site's HTML is `github.com`. + +## What we used to set, and no longer do + +`crosscode_distinct_id` — a random UUID in `localStorage` that gave each browser a stable +identity across visits, so PostHog could tell a returning visitor from a new one. + +It has been removed. Website analytics events now go out with no persistent identifier, +which means they cannot be linked into a per-visitor history. It is a real loss of signal +and worth it on a site whose pitch is that we hold your code and would rather say so +plainly than track you around a page about it. + +If you visited before the change, the old value may still be sitting in your browser's +local storage. Nothing reads it any more. Clearing site data removes it. + +## Why there is no banner + +Strictly necessary items are consent-exempt, so the auth token and `__cf_bm` need no +banner. + +That leaves `crosscode_analytics_once:*`. It is a per-tab flag holding the string `"1"`; it +identifies nobody, carries no identifier, is deleted when the tab closes, and exists solely +to stop one event being counted twice. + + + +## Turning it off + +- **Analytics:** any content blocker that blocks `us.i.posthog.com` stops the events. So + does denying storage for this site — the code falls back and sends the event without the + dedup flag rather than breaking. A build with no PostHog key installs no listeners and + sends nothing at all, which is what a fork or a local `pnpm docs:dev` runs. +- **The auth token:** clearing site data signs you out. There is no way to stay signed in + without it. +- **Do Not Track / Global Privacy Control:** not currently honoured as a signal. Stated + because claiming otherwise without the code to back it would be worse. + +## The CLI and daemon + +Not a browser, no cookies. The CLI stores your session in +`/crosscode/config.json` at mode `0600`, preferring the OS keychain for the +refresh token where one exists (macOS `security`, Linux `secret-tool`). See the +[security model](/docs/safety.html). + +## Related + +- [Privacy Policy](./privacy-policy.md) — the complete Art. 13/14 notice +- [Privacy: what we can and can't see](./privacy.md) — the plain-language summary +- [Subprocessors](./subprocessors.md) — who else touches this data + +## Before this takes effect + +- `{{EFFECTIVE_DATE}}` — the date this page takes effect. +- Confirm the `crosscode_distinct_id` removal has actually shipped to production before + publishing. This page describes the post-removal state. +- Resolve the `` note above on `crosscode_analytics_once:*`. +- If the Supabase project ref ever changes, the auth token key name in the table changes + with it — it is `sb--auth-token`. 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. + + + +## 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 + . 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 , 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/dpa.md b/docs/dpa.md new file mode 100644 index 0000000..4eb86e2 --- /dev/null +++ b/docs/dpa.md @@ -0,0 +1,322 @@ +# Data Processing Agreement + +> **Draft.** Not yet in force. The double-brace placeholders are unfilled and the SCC annex in +> §13 is a placeholder. Do not rely on this as a signed agreement until the checklist at the +> end is done. + +This is the Article 28 agreement between you and Crosscode for the personal data that ends +up inside the files you sync. It applies automatically when you use the hosted service — +you do not have to sign, request or negotiate anything. If you need a counter-signed copy +for your own records, write to **legal@getcrosscode.dev**. + +It is short on purpose. Everything in it is a commitment a one-person project can actually +keep. + +Effective from {{EFFECTIVE_DATE}}. + +## 1. Parties and roles + +- **Controller:** you — the account holder, or the organisation you sync on behalf of. +- **Processor:** {{PROVIDER_NAME}}, an individual acting as a sole proprietor, at + {{PROVIDER_ADDRESS}} ("Crosscode"). + +You decide why and how the personal data inside your repositories is processed. Crosscode +processes it only to run the sync service, on your instructions. + +For your own account data — your email, your GitHub identity, your projects — Crosscode is +the **controller**, not your processor, and the [Privacy Policy](./privacy-policy.md) +governs instead. This agreement covers only the data inside your files. + +## 2. Subject matter, nature and purpose + +**Subject matter.** Real-time synchronisation of uncommitted working-tree files between Git +checkouts of the same repository. + +**Nature of the processing.** Receiving file changes from your checkouts, storing them, +relaying them to your other checkouts and to members you have invited, and deleting them +when the retention window passes. Also: authenticating your users, deciding who may sync +with whom, recording errors, and counting usage. + +**Purpose.** To perform the sync service for you. Nothing else. In particular the data is +never used to train a model, is never sold or shared with advertisers, and is never +processed for Crosscode's own purposes beyond the security, error-monitoring and +usage-counting described in §5 of the [Privacy Policy](./privacy-policy.md). + +**Duration.** From when you first sync until you stop and ask for deletion, or the account +ends. + +## 3. Types of personal data + +Whatever your repositories contain. Crosscode does not inspect file contents and cannot +categorise them, so this is stated by shape rather than by list: + +- Personal data written into source code and configuration: names and email addresses in + comments, `CODEOWNERS`, authorship metadata. +- Personal data in test fixtures, seed data, sample payloads, screenshots and database + dumps: names, email addresses, postal addresses, order and customer records, and anything + else that ends up in a fixture. +- Anything else a tracked file happens to hold. + +**Two limits that reduce this materially.** Only files Git already *tracks* are ever sent — +untracked files never leave the machine. And a path denylist drops `.env*`, `.envrc`, +`.npmrc`, `.netrc`, `credentials*`, `secret*`, SSH private keys, and `*.pem` / `*.key` / +`*.p12` / `*.pfx` / `*.jks` / `*.keystore` before a change is captured, rather than +filtering them later. `packages/core/src/index.ts` is the authoritative list. + +**Special category data (Art. 9) and criminal offence data (Art. 10) are outside the scope +of this agreement.** The service is not designed for them and you must not sync +repositories that contain them. + +## 4. Categories of data subject + +Whoever your repositories describe: your customers and end users, your employees and +contributors, and third parties named in code, fixtures or documentation. + +## 5. Your instructions + +Crosscode processes the data only on your documented instructions. Using the service is +the instruction: syncing a checkout instructs us to store and relay its tracked file +changes. + +Further instructions go to **privacy@getcrosscode.dev**. We will follow reasonable ones +that the service is technically capable of. If an instruction would require a feature that +does not exist, we will say so rather than agree and not do it. + +If an instruction would breach data protection law, we will tell you and may pause that +processing. + +Crosscode will not transfer the data to a third country except as described in §7 and §13, +and will tell you if legally required to do so unless the law forbids the telling. + +## 6. Confidentiality + +Exactly one person has production access: {{PROVIDER_NAME}}. There is no team, so there is +no list of authorised personnel to maintain and nobody else to bind. That person is bound +to confidentiality by this agreement. + +If that ever stops being true — a second maintainer, a contractor with production access — +each such person will be under a written confidentiality obligation before they get access, +and this section will be updated to say so. + +## 7. Security measures (Art. 32) + +What the code actually does. Written to be checkable against the repository, not to sound +reassuring. + +### 7.1 The one thing to understand first + +**There is no end-to-end encryption.** Files are encrypted in transit and at rest, but +under keys Crosscode manages, which means someone with production access could read your +file contents. A DPA that implied otherwise would be worse than no DPA. + +Crosscode built E2E encryption once and removed it: it cost a device-pairing ceremony, a +keyring, epochs, rotation and recovery paths, for a product whose durable artifact is a Git +repository you already have. That trade is stated openly in the +[security model](/docs/safety.html) and it is the trade you are accepting here. + +If a repository cannot be read by us, do not sync it. + +### 7.2 Encryption + +- **In transit:** TLS everywhere. Database connections require `sslmode=verify-full` — both + certificate chain and hostname are verified, with a private root supplied where the + managed provider uses one. A non-loopback connection string without `verify-full` is + refused at startup, not warned about. +- **At rest:** provider-managed encryption on Supabase's storage layer. + +### 7.3 Minimisation before capture + +- **Tracked files only.** Untracked files are never eligible. +- **The secret denylist in §3**, enforced before a change is captured rather than filtered + after. +- **Nothing outside the working tree.** Symlinks that leave the checkout are refused. +- **Retention.** Change history is kept for about 7 days + (`HISTORY_RETENTION_DAYS = 7`) and then deleted. See the honest note in §8 of the + [Privacy Policy](./privacy-policy.md) about the state of the deletion job. + +### 7.4 Access control + +- Sign-in is GitHub OAuth or email/password through Supabase Auth. The service verifies + access tokens against Supabase's JWKS and takes identity from the verified claims, never + from anything the client asserts. +- Project membership is re-derived server-side on **every** request rather than trusted from + a scope in the token, so a removed member loses access on their next request. +- Invite redemption verifies through GitHub that the redeeming account can actually read + the repository. A valid code held by someone without repo access is refused. +- CLI sign-in is a device-code handshake: no local listener, two codes of deliberately + unequal power, only a SHA-256 of the device code is stored, ~15-minute expiry, + single-use, and the poll route is rate-limited. +- Row Level Security is on from the first migration. The service connects with a + least-privilege role that cannot UPDATE, DELETE or TRUNCATE the change log; retention + runs on a separate connection. + +### 7.5 Integrity + +The receiving daemon verifies every change before applying it: content must hash to the +`contentHash` on the wire, and the merge base must resolve to the `baseHash` the sender +recorded. A change failing either is not applied. The check is deliberately the receiver's +— a service willing to substitute content would substitute the hash beside it. + +### 7.6 Telemetry hygiene + +Error reports are built field by field from an allowlist. The message goes through +`redact()`, which strips quoted spans, anything path-shaped, filenames with a known +extension, and runs of 24+ opaque characters. Routes are templated so identifiers become +`:id`. Request bodies, headers, cookies and environment are never read. Analytics +properties are allowlisted and carry no content, paths, branch names, repository names, +emails or GitHub logins. + +### 7.7 What is not in place + +Stated because omitting it is the thing that makes a security annex dishonest: + +- No SOC 2, ISO 27001 or any third-party audit. +- No penetration test. +- No formal business continuity or disaster recovery plan beyond the managed provider's + automated backups. +- No 24/7 on-call. One person, best effort. +- Availability, resilience and restore testing (Art. 32(1)(b)–(c)) rest on Supabase's and + Vercel's platform guarantees, not on anything Crosscode operates. + +## 8. Sub-processors + +You give **general written authorisation** for the sub-processors listed on +[Subprocessors](./subprocessors.md), and for changes to that list on the terms stated +there: **30 days' advance notice**, a right to object within that window, and emergency +replacement with notice within 3 business days where a vendor fails or must be dropped for +a security reason. + +Each sub-processor is engaged under a written agreement imposing data protection +obligations no less protective than these. Crosscode remains fully liable to you for their +performance. + +## 9. Assisting you + +**Data subject requests.** If a data subject contacts Crosscode about data inside your +repository, we will not respond substantively — we will tell them to contact you, and tell +you within **5 business days** if we can identify you. Realistically we usually cannot +identify whose data is in a file, because identifying it would mean reading your files. + +We will help you answer a request as far as the service technically allows. In practice +that means deleting a project, deleting an account, or deleting the change history attached +to either. Crosscode cannot search inside stored file contents for one person's data, and +would not, because doing so means reading your code. + +**DPIAs and prior consultation.** We will give you the information described in this +agreement and in the [Privacy Policy](./privacy-policy.md) to support an Art. 35 assessment +or an Art. 36 consultation. That information is this documentation; there is no +questionnaire desk behind it. + +## 10. Personal data breach + +**Crosscode will notify you without undue delay and in any event within 48 hours** of +becoming aware of a personal data breach affecting your data. 48 hours, not 72, so that you +retain time inside your own 72-hour Art. 33 clock. + +The notification will describe the nature of the breach, the categories and approximate +number of data subjects and records affected, the likely consequences, and the measures +taken or proposed — or, where the facts are not yet established, what is known so far, +followed by updates as the picture firms up. Notice goes to the email address on the +account, from **security@getcrosscode.dev**. + +Notifying **your** supervisory authority and **your** data subjects is your decision and +your obligation as controller. Crosscode will give you what you need to make it. + +The breach runbook that produces this notification is in the +[security model](/docs/safety.html#breach-response-runbook). + +## 11. Deletion and return + +On termination, or on your request at any time, Crosscode will delete your projects, their +change history, and your account records. + +**Return.** There is nothing to hand back. The data Crosscode holds is a ~7-day log of +changes to files you already have, in a repository on your own disk that is the durable +artifact the whole time. If you want an export anyway, ask within 30 days of termination +and we will provide what the service can produce. + +**The limits, stated plainly:** + +- **Backups.** Deleted rows survive in the managed provider's automated backups until those + backups age out on the provider's schedule. They are not restored except to recover from + a failure, and if a restore ever reinstates deleted data it is re-deleted. +- **Copies teammates already hold.** Every member of a project had a full checkout. + Deletion here cannot reach a copy someone already has, and no product can. + +## 12. Audit + +You may verify compliance with this agreement by: + +1. **Reading the source.** Crosscode is MIT licensed and public at + `github.com/amsultan2010/crosscode`. Every security claim in §7 names the file that + implements it. This is a stronger audit right than most processors offer and it costs + you nothing. +2. **Asking.** Written questions to **privacy@getcrosscode.dev** get a written answer + within 30 days, at most once per 12 months absent a breach or a regulator's demand. +3. **Sub-processor reports.** We will pass on whatever certifications and audit reports + Supabase and Vercel make available to their customers. + +**On-site inspection is not offered.** There is no site — one person, no office, no +datacentre of our own. An on-premises audit right would be a promise that could not be +kept. If your compliance programme requires one, Crosscode is not a suitable processor for +that workload, and it is better that you learn it here than after signing. + +## 13. International transfers + +Sub-processors are in the United States and Canada; the per-vendor detail and mechanism is +on [Subprocessors](./subprocessors.md). + +Where the EU Standard Contractual Clauses are needed for a transfer under this agreement, +Module Three (processor to sub-processor) applies, together with the UK Addendum for UK +transfers, and they are incorporated by reference with the annexes completed as follows: + +- **Annex I(A), Parties** — you as data exporter; {{PROVIDER_NAME}}, {{PROVIDER_ADDRESS}} + as data importer. +- **Annex I(B), Description of transfer** — §§2, 3 and 4 of this agreement. +- **Annex I(C), Competent supervisory authority** — the authority competent for you as + controller. +- **Annex II, Technical and organisational measures** — §7 of this agreement, in full, + including §7.7. +- **Annex III, Sub-processors** — the [Subprocessors](./subprocessors.md) page as it stands + from time to time. + + + +## 14. General + +**Governing law and venue:** {{JURISDICTION}}. Where the SCCs apply, their own governing +law and forum clauses prevail over this section for the transfers they cover. + +**Precedence.** For the personal data inside your files, this agreement prevails over the +[Terms of Service](./terms.md) if the two conflict. For everything else the Terms govern. + +**Changes.** Material changes get 30 days' notice by the same route as §8. Every version of +this page is in the repository's Git history. + +**Liability.** The limitation of liability in the [Terms of Service](./terms.md) applies to +this agreement, except where the GDPR or the SCCs make a limitation unenforceable, in which +case the statutory position governs. + +## Before this takes effect + +Fill in, in this file: + +- `{{PROVIDER_NAME}}` — appears in §1, §6, and Annex I(A) in §13 +- `{{PROVIDER_ADDRESS}}` — appears in §1 and Annex I(A) in §13 +- `{{JURISDICTION}}` — §14 +- `{{EFFECTIVE_DATE}}` — the header + +And resolve, before publishing: + +- The `` note in §13 on the SCC annexes and the missing transfer impact + assessment. +- Add an accept-by-reference clause to the [Terms of Service](./terms.md) pointing here, so + this agreement is actually incorporated. That file is owned by another workstream — see + `HANDOFF.md`. +- Decide whether the 48-hour breach deadline in §10 is one you can meet as a single person. + It is deliberately tighter than the 72 hours the law gives your controller. If it is not + realistic, change it before publishing rather than miss it later. 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 — — 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. + + + +## 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. diff --git a/docs/privacy-policy.md b/docs/privacy-policy.md new file mode 100644 index 0000000..86e2938 --- /dev/null +++ b/docs/privacy-policy.md @@ -0,0 +1,291 @@ +# Privacy Policy + +> **Draft.** This page is written but not yet in force. The double-brace placeholders below are +> unfilled. Do not rely on it as a legal document until the checklist at the end is done. + +This is the complete notice required by Articles 13 and 14 of the UK/EU GDPR. It is long +because those articles are long. + +If you want the short honest version — what the service can and cannot see — read +[Privacy: what we can and can't see](./privacy.md). That page is the summary; this page is +the complete one. Where the two disagree, this page governs, but they are not meant to +disagree. + +Effective from {{EFFECTIVE_DATE}}. + +## 1. Who is responsible + +The controller for the hosted Crosscode coordination service is {{PROVIDER_NAME}}, an +individual acting as a sole proprietor, at {{PROVIDER_ADDRESS}}. + +There is no company. Crosscode is a pre-1.0 side project run by one person, and that person +is the one who answers privacy mail. + +Contact: **privacy@getcrosscode.dev** + +There is no Data Protection Officer. The service does not meet any of the Art. 37(1) +thresholds that would require one. + + + +## 2. What this covers + +The **hosted coordination service** at `www.getcrosscode.dev`: the website, the sign-in +flow, the API the daemon talks to, and the docs site. + +It does not cover the Crosscode software itself. The CLI, daemon and MCP server are MIT +licensed and run on your machine. Running them without signing in sends nothing anywhere. + +## 3. Categories of personal data + +### 3.1 Data about you, the account holder + +| Category | What exactly | Where in the code | +| --- | --- | --- | +| Account identity | Supabase user id (UUID), email address, GitHub numeric id, GitHub login | `users` table, `apps/service/migrations/001_sync.sql` | +| Authentication records | Email address, password hash if you used the email/password path, GitHub OAuth identity, session and refresh tokens | Supabase Auth | +| Pending sign-in | SHA-256 of the device code, the short user code you type, and — while the handshake is open — the session it will hand to your terminal | `device_codes` table, `apps/service/src/store.ts` | +| Project records | Project name, repository as `owner/repo`, your role, who created what, invite codes and who redeemed them | `projects`, `project_members`, `invites` | +| Checkout records | A replica id per checkout, the branch it is on, when it was last seen | `replicas` | +| Presence | Which branch you are on and which paths you touched recently. Held in memory in the websocket gateway, never written to the database | `apps/service/src/ws.ts` | +| Usage events | Seven named events (`user_activated`, `device_authorized`, `project_created`, `invite_created`, `invite_redeemed`, `replica_registered`, `changes_published`), each carrying your Supabase user id, a timestamp, and at most a file-version count and a new-user flag | `apps/service/src/analytics.ts` | +| Website analytics | Four page events with no account id and no persistent identifier attached — see [Cookies and local storage](./cookies.md) | `apps/docs-site/src/analytics.js` | +| Error reports | Route template, HTTP method, status, a platform request id, and a redacted error message | `apps/service/src/observability.ts` | +| Server logs | Standard request logs kept by Vercel and Supabase, which include IP addresses | Vercel and Supabase platform defaults | + +### 3.2 The file contents + +**We hold the contents of the files you sync.** There is no end-to-end encryption. Files +are encrypted in transit (TLS) and at rest under keys the service manages, which means +someone with production access could read them. + +What is stored for each change: the path, the content, the hashes either side merged +against, whether it was a modify or a delete, a timestamp, a size, and a sequence number. + +Only files Git already tracks are ever sent. Untracked files never leave your machine, and +a hard denylist drops `.env*`, `.envrc`, `.npmrc`, `.netrc`, `credentials*`, `secret*`, +SSH private keys, and `*.pem` / `*.key` / `*.p12` / `*.pfx` / `*.jks` / `*.keystore` before +a change is captured — see `packages/core/src/index.ts`. + +### 3.3 Personal data belonging to other people, inside your files + +This is the exposure most policies leave out, so it is stated first-class here. + +Source code routinely contains other people's personal data: names and email addresses in +comments, `git blame` context and `CODEOWNERS`; real email addresses in test fixtures; +customer names, addresses or order records in seed data and database dumps; screenshots and +sample payloads. + +When you sync a repository, that data passes through and is stored by the coordination +service in exactly the same way as the rest of the file content. Neither of us can filter +it — the denylist matches paths, not contents, and nothing inspects what your files say. + +For that data, **you are the controller and Crosscode is your processor.** The +[Data Processing Agreement](./dpa.md) is the terms on which we process it, offered +accept-by-reference so nobody has to negotiate one. + +If you cannot make that commitment for a given repository, do not sync it. Crosscode is +opt-in per checkout and stopping it leaves an ordinary Git repository behind. + +## 4. Categories of data subject + +- **Account holders**: people who sign in and sync. +- **Third parties whose personal data sits inside synced files**: everyone described in + §3.3. They have no relationship with Crosscode and no way to know their data is here, + which is precisely why §3.3 exists. + +## 5. Why we process it, and on what legal basis + +### 5.1 Providing the service — Art. 6(1)(b), contract + +Storing and relaying your file changes, keeping your account and projects, running the +device sign-in handshake, and deciding who may sync with whom. Without this there is no +product to perform. + +### 5.2 Security, abuse prevention and error monitoring — Art. 6(1)(f), legitimate interests + +Rate limiting, invite and device-code expiry, the append-only change log, server logs, and +error reports. + +*Balancing note.* The interest is keeping a service that holds plaintext source code from +being broken into or abused, which is as much your interest as ours. The data used is +narrow: error reports carry a route template, a method, a status, a platform request id and +an error message that has been run through `redact()` — which strips quoted spans, +anything path-shaped, filenames, and long opaque runs — plus stack frames from our own code +by basename only. Request bodies, headers, cookies and environment are never read. Server +logs carry IP addresses, which is unavoidable for any hosted service. Nobody is profiled, +no decision is made about anybody, and none of it is combined with anything else. A user +would expect a service holding their code to watch for intrusions. We consider the interest +to prevail; if you disagree, see §9 on objection. + +### 5.3 Product analytics — Art. 6(1)(f), legitimate interests + +Counting how many people reach the service and whether they get as far as syncing. + +*Balancing note.* Server-side events are keyed on your Supabase user id, carry no file +paths, no content, no branch or repository names, no email and no GitHub login, and are +built from a two-property allowlist rather than spread from an object. Website events carry +no account id and — once the change described in [Cookies and local storage](./cookies.md) +ships — no persistent identifier at all, so they cannot be linked across visits. Nothing is +sold, nothing is shared with advertisers, and no profile is built. The intrusion is close +to nil and the alternative is having no idea whether the project is used at all. We +consider the interest to prevail. + +### 5.4 Legal compliance — Art. 6(1)(c), legal obligation + +Responding to lawful requests, keeping records where the law requires it, and handling +notice-and-takedown. + +### 5.5 Data inside your files — you decide + +For the third-party personal data in §3.3, Crosscode does not choose a legal basis: you do, +as controller. We process it only on your instructions, under the [DPA](./dpa.md). + +## 6. Who receives it + +Vendors we use to run the service, listed with what each one gets, where it sits, and under +what transfer mechanism, on the [Subprocessors](./subprocessors.md) page. That page is the +authoritative list and it changes with 30 days' notice. + +Beyond that: nobody. Your data is not sold, not rented, not shared with advertisers, and +**never used to train an AI model** — ours or anyone else's. Crosscode has no AI features +and stores no model provider credentials. The only agent involved is the one already on +your machine, reading your files locally. + +We disclose data to a public authority only where legally compelled, and will tell you +unless the law forbids it. + +## 7. International transfers + +The provider is a sole proprietor and every vendor is outside the UK/EEA. Details per +vendor are on [Subprocessors](./subprocessors.md); the mechanisms in use are: + +- **Canada** (Supabase's database and auth run in AWS `ca-central-1`, Montréal): covered by + the European Commission's adequacy decision for Canadian commercial organisations, with + Supabase's Standard Contractual Clauses as a belt-and-braces backstop. +- **United States** (Vercel, PostHog, Sentry, GitHub, npm): each vendor's Data Processing + Addendum, incorporating the EU Standard Contractual Clauses; several are additionally + certified under the EU–US Data Privacy Framework. + + + +## 8. How long we keep it + +| Category | Retention | Basis | +| --- | --- | --- | +| File change history | About 7 days, then deleted | `HISTORY_RETENTION_DAYS = 7`, `apps/service/src/store.ts`. The window exists so a checkout that was offline can replay what it missed; one away longer resynchronizes from full content instead. **The sweep that performs the deletion is not yet automated in this repository** — see the note below. | +| Account record, projects, memberships | Until you ask us to delete them | Needed to perform the contract | +| Supabase Auth records (email, password hash, GitHub identity, sessions) | Until account deletion; refresh tokens expire or are revoked on sign-out | Needed to perform the contract | +| Device sign-in codes | About 15 minutes, and consumed on first successful poll. Rows older than an hour are deleted at the start of the next handshake; the session payload is nulled the moment the terminal collects it | `apps/service/src/store.ts` | +| Invite codes | Until they expire or are redeemed; the row survives to record that it was used | `invites` table | +| Replica records | Until the project is deleted | `replicas` table | +| Presence | In memory only. Gone when the connection closes or the process restarts | `apps/service/src/ws.ts` | +| Server-side analytics events | PostHog's project retention setting, currently the plan default | PostHog | +| Website analytics events | As above | PostHog | +| Error reports | Sentry's project retention setting, currently the plan default (90 days on Sentry's standard plans) | Sentry | +| Server and platform logs | Vercel's and Supabase's own log retention, which is days, not months, on their current plans | Vercel, Supabase | +| Database backups | Supabase's automated backups, on the plan's schedule. Deleted data survives in a backup until that backup ages out | Supabase | + +**Honest note on the 7 days.** The service enforces the window on the way *out*: a cursor +pointing at history older than what survives is refused rather than answered with a partial +page, and the daemon resynchronizes from full content. The deletion job itself is operated +outside this repository — there is no cron entry or scheduled function in the source tree +that performs it. Treat "about 7 days" as the retention *target* and the serving guarantee, +not as a verified automated delete. + + + +## 9. Your rights + +Under the UK/EU GDPR you can ask for: + +- **Access** — a copy of the personal data we hold about you. +- **Rectification** — correction of anything inaccurate. +- **Erasure** — deletion of your account, your projects, and the change history attached to + them. Your repositories are unaffected, because they were never ours. +- **Restriction** — that we stop processing while a dispute is resolved. +- **Portability** — the data you gave us, in a machine-readable form. +- **Objection** — to anything done on legitimate interests (§5.2, §5.3). Say so and we + stop, unless we can show compelling grounds that override your interests. +- **Withdrawal of consent** — where we ever rely on consent. Today we do not; if that + changes, withdrawing is as easy as giving it and does not affect what came before. + +**How to exercise them:** email **privacy@getcrosscode.dev**. We respond within one month +of receipt, extendable by two further months for genuinely complex requests, in which case +we will tell you inside the first month and say why. + +Requests are free. We may ask you to prove you control the account before acting on one — +handing someone else's source code to whoever asked is the failure mode a policy like this +exists to prevent. + +**One limit, stated plainly.** Removing a member from a project ends their access +immediately, but it cannot un-share what they already have: they had a full checkout of the +repository. No product can reach into a copy someone already holds. + +### If you are one of the third parties in §3.3 + +Your data reached us inside someone else's repository. We usually cannot identify you, and +searching stored file contents to find you would mean reading them, which is worse than the +problem. Ask the person or team that syncs the repository — they are the controller. If you +tell us who they are at **privacy@getcrosscode.dev**, we will pass the request on. + +### Complaints + +Tell us first if you are willing — **privacy@getcrosscode.dev** — but you do not have to. +You can complain to a supervisory authority in the EU/EEA member state where you live, +work, or where you think something went wrong. In the UK that is the Information +Commissioner's Office (`ico.org.uk`). + +## 10. Automated decision-making + +There is none. No automated decision produces legal or similarly significant effects about +anybody, and there is no profiling. Nothing in the service scores, ranks, or classifies +users. The analytics events in §3.1 are counted in aggregate and are not used to make +decisions about individuals. + +## 11. Age + +You must be at least 16 to use Crosscode, or the age of digital consent in your country if +that is higher. This matches §3 of the [Terms of Service](./terms.md). The service is not +directed at children and collects no data knowingly from them. If you believe a child's +data is here, write to **privacy@getcrosscode.dev** and it will be deleted. + +## 12. Is any of this required of you? + +Providing an email address and a GitHub identity is a condition of having an account — +without them there is nobody to authorise and no way to check repository access at invite +redemption. Not providing them means not using the hosted service. The software still works +locally. + +Syncing any given repository is entirely your choice, per checkout. + +## 13. Changes to this policy + +Every version of this page is in the repository's Git history, so what changed and when is +public and checkable. + +For material changes — a new purpose, a new legal basis, a new category of data — we will +give at least **30 days' notice** by email to account holders and by a dated note at the top +of this page, before the change takes effect. Corrections and clarifications go live +immediately and are visible in the Git history. + +## Before this takes effect + +Fill in, in this file: + +- `{{PROVIDER_NAME}}` — the legal name of the individual provider +- `{{PROVIDER_ADDRESS}}` — a postal address for legal notices +- `{{EFFECTIVE_DATE}}` — the date this policy takes effect + +And resolve, before publishing: + +- The retention-sweep gap in §8. Either automate the delete or soften the claim. +- The two `` notes in §1 and §7. +- Confirm the actual retention settings configured in the PostHog and Sentry projects and + replace "the plan default" in §8 with the number. diff --git a/docs/privacy.md b/docs/privacy.md index 1a8b587..e12e7ee 100644 --- a/docs/privacy.md +++ b/docs/privacy.md @@ -3,6 +3,12 @@ Crosscode syncs your uncommitted edits between checkouts, so those files pass through our coordination service. This page says exactly what that service holds. +This is the honest summary. The complete, formal notice — legal bases, retention per +category, your rights and how to exercise them — is the +[Privacy Policy](./privacy-policy.md). Alongside it: [Cookies and local +storage](./cookies.md), [Subprocessors](./subprocessors.md), and the [Data Processing +Agreement](./dpa.md) for personal data that sits inside the files you sync. + **We hold your file contents.** There is no end-to-end encryption. Files are encrypted in transit (TLS) and at rest, under keys we manage, which means a Crosscode engineer with production access could read them. We would rather say that plainly than imply otherwise. @@ -64,3 +70,7 @@ tell you that than let you believe otherwise. Ask us and we delete your account, your projects, and the change history attached to them. See [support](./support.md). Your repositories are unaffected, because they were never ours. + +Your other rights — access, rectification, restriction, portability, objection — and the +one-month response time are in §9 of the [Privacy Policy](./privacy-policy.md). Write to +privacy@getcrosscode.dev for any of them. diff --git a/docs/security.md b/docs/security.md index 6806c42..217a43d 100644 --- a/docs/security.md +++ b/docs/security.md @@ -139,3 +139,210 @@ large your changes are. Report vulnerabilities per [SECURITY.md](https://github.com/amsultan2010/crosscode/blob/main/SECURITY.md), never in a public issue. + +## Breach response runbook + +Crosscode stores plaintext customer source code. A breach here is severe by definition — +there is no "only metadata was exposed" outcome available. Assume the worst category until +the evidence rules it out. + +The GDPR clock is **72 hours** to notify a supervisory authority, and Crosscode's +[DPA](./dpa.md) promises controllers notice within **48 hours**. Both clocks start at +*awareness*, not at containment. + +**Who decides: the project owner.** One person, named in the +[privacy policy](./privacy-policy.md), owns every call below — severity, notification, +disclosure. There is no committee to convene and no escalation path. If the owner is +unreachable, the breach waits, which is a real risk of a one-person project and is stated +rather than papered over. + +### 1. Detection + +Where a breach realistically surfaces: + +- **Sentry** — a spike in 5xx, an unfamiliar error type, or auth errors from a route that + should not produce them. +- **The uptime workflow** (`.github/workflows/uptime.yml`) — opens a GitHub issue on two + consecutive failed probes. An outage is not a breach, but they arrive together often + enough that this is a trigger to look. +- **A user or researcher emailing `security@getcrosscode.dev`**, per + [SECURITY.md](https://github.com/amsultan2010/crosscode/blob/main/SECURITY.md). This is + the most likely source. Treat it as credible until disproven. +- **Vercel or Supabase telling you** — a provider security notice, or an unrecognised login + to either dashboard. +- **Anomalies you notice yourself**: unexpected rows in `device_codes`, invites redeemed by + accounts you do not recognise, egress or database size that does not match usage. + +**Awareness starts** when you have a reasonable degree of certainty that a security +incident occurred and it involved personal data. Not when you finish investigating. Write +the timestamp down the moment you reach it — the 72 hours is measured from there and you +will be asked to evidence it. + +### 2. First 60 minutes — contain, then preserve + +In this order: + +1. **Stop the bleeding.** Rotate what is exposed: Supabase service role key and database + password, `SENTRY_DSN`, `POSTHOG_KEY`, and any GitHub OAuth app secret. If a deployment + is the cause, promote the last known good one from the Vercel dashboard — a promotion + takes seconds and a diagnosis does not. +2. **Do not delete anything.** Not logs, not rows, not the bad deployment. Evidence first; + see step 3. +3. **Revoke sessions** if account takeover is plausible — Supabase Auth, sign out all users + on the affected accounts. +4. **Write down the clock**: when it started, and how you know. + +### 3. Preserve evidence + +Before anything ages out. Vercel and Supabase log retention is days, not months, so this is +genuinely urgent: + +- Export Vercel function logs for the window (**Vercel → project → Logs**, filter and + export). +- Export Supabase Postgres logs and the auth audit log for the window. +- Export the Sentry issues involved, including the full event JSON, not just the title. +- Snapshot the database if data was modified — Supabase's dashboard can take one on demand. +- Note the deployment SHA in production at the time (`VERCEL_GIT_COMMIT_SHA`). +- Keep the original report email intact, headers included. + +Put all of it in one dated folder outside the repository. Do not commit evidence containing +personal data to a public repo. + +### 4. Assess severity + +| Level | What it means | Examples | +| --- | --- | --- | +| **P1 — file contents exposed** | Someone who should not have been able to read stored file contents did, or plausibly could have | Database credential leak, RLS bypass, a route serving another project's changes, backup left readable | +| **P2 — account or auth compromise** | Identity or session data exposed, without confirmed content access | Device-code or session token leak, OAuth secret exposure, account takeover | +| **P3 — metadata exposure** | Records about accounts and projects, no file contents | Email addresses, GitHub logins, `owner/repo` names, project membership | +| **P4 — no personal data** | A security issue with no personal data involved | A vulnerability reported and fixed before exploitation, with logs showing no access | + +**P1 and P2 are notifiable.** P3 usually is — repository names alone can be commercially +sensitive, and the honest reading is that `owner/repo` plus membership tells an attacker who +works on what. P4 is not notifiable, but write it up anyway. + +The three questions that decide it: *Was personal data involved? Could someone unauthorised +have accessed it? Is there a risk to those people's rights and freedoms?* If you cannot +answer the second one "no" with evidence, treat it as yes. + +### 5. Notify + +**Supervisory authority — within 72 hours of awareness.** Late is better than never: a late +notification must explain the delay, so file within the window even if the picture is +incomplete. Art. 33(4) explicitly allows notifying in phases. + +```text +Subject: Personal data breach notification — Crosscode + +1. Nature of the breach + What happened, in two sentences. When it started, when it was discovered, whether it is + contained now. + +2. Categories and approximate number of data subjects + Account holders affected: N. + Third parties whose personal data was inside the affected repositories: unknown — + Crosscode does not inspect file contents and cannot enumerate them. See the privacy + policy, §3.3. + +3. Categories and approximate number of records + Which of: file contents and paths; account records (email, GitHub identity); + authentication records; project and membership records; analytics or error reports. + Number of file versions, projects and accounts, as best established. + +4. Likely consequences + For a P1: source code, and any personal data inside it, was readable by an unauthorised + party. Downstream risk to the affected users' own customers, which those users must + assess as controllers. + +5. Measures taken and proposed + Containment already done, credentials rotated, fix deployed, notifications sent, changes + to prevent recurrence. + +6. Contact + {{PROVIDER_NAME}}, privacy@getcrosscode.dev + +7. What is not yet known + State it explicitly, with the date by which you expect to know. +``` + +**Affected users — without undue delay, where there is high risk to their rights and +freedoms.** For a P1, assume there is. Send from `security@getcrosscode.dev`: + +```text +Subject: Security incident affecting your Crosscode data — action needed + +What happened + On . We discovered it on + at