What this dataset records#
One atomic fact observation per service, attribute, and lifecycle stage (signup / continued use / payment / recovery / deletion). Each observation stores the requirement as the provider states it, how the data is collected and verified, what it becomes linked to (session, device, account, billing, parent-company profile, downstream provider), the surfaces it applies to (web / API / free / paid), and the evidence behind it. Observations are append-only: when a policy changes, a new observation is added and the old one becomes history — that history is the point of the dataset. The name is the thesis: requirements drift.
What it deliberately does not measure#
- Network anonymity. IP addresses, device fingerprinting, Tor/VPN treatment, and site analytics are a different layer. Where a provider’s documents state network-layer collection we record it — under a separate “network layer” label — because pretending it doesn’t exist would be dishonest. But no value in this dataset says anything about whether you are anonymous on the wire.
- Payment-intermediary exposure. “Accepts cryptocurrency” is a provider fact; what your payment processor knows about you is out of scope.
- Legal-process access. Jurisdiction is recorded as a fact (who the stated data controller is, where). What a subpoena or national-security process can reach is your threat model’s question, not a cell in a table.
- Enforcement. Every value is what the provider states. An archived policy proves the provider published those words on that date — it does not prove the systems behave that way.
Where values come from#
Sources are ranked. When they disagree, the higher rank is shown as the value and the disagreement is displayed, never silently resolved:
- Official policy, terms, and help-center pages (provider-stated)
- In-product observed flow (interface-observed — labeled as such)
- Provider support statements
- Archived UI copies
- Third-party reports (never the sole basis of a value)
Two things that look alike are kept apart: “the policy says it collects X” and “the signup flow requires X.” A privacy policy’s collection wording is recorded as collection; a requirement is only recorded as required when the provider’s own documents say must/require/verify — or when the flow itself demonstrably refuses to proceed without it.
The vocabulary#
Cells never guess. The full controlled vocabulary: required · optional · conditional · available · collected-if-provided · may-collect · not-disclosed · not-assessed · conflicting · region-dependent · plan-dependent · not-applicable. Three deserve emphasis:
- not-disclosed — the provider’s documents do not state it. We never infer “none” from silence.
- not-assessed — we have not extracted it yet. Absence of a value is not evidence of absence of a requirement.
- conflicting — sources disagree; both positions are shown with rank and date.
Evidence and integrity#
- Archive-first. We do not crawl providers from our own infrastructure; pages are captured through web archives, and the archived copy is what we cite.
- Content verification. A capture only counts as evidence if the claim-supporting text is actually present in the decoded archived body. A hash alone proves bytes existed — not that they say anything.
- What the hash proves. Each evidence record carries the sha256 of the decoded archived body. It proves these bytes existed at capture time. It does not, by itself, prove who published them — that link comes from the archive’s record of the source URL.
- Quotes. Short, plain-text, sanitized excerpts (≤280 characters), reproduced in the original language only — quotes are evidence, and translating evidence would manufacture it.
- Local retention. Independent copies of every relied-upon capture are retained, so integrity remains provable even if an archive link stops resolving.
Conflicts, drift, corrections#
Conflicting sources are displayed as a conflict (“official states X; a third-party report claims Y; unverified”), not resolved by editorial preference. Requirement changes are kept as history with the interval we can honestly bracket — a snapshot date is never passed off as the change date. Errors we make are corrected in place and the correction is recorded publicly; providers can object via editor@cypherpunkguide.com and receive a first response within 14 days, with the disputed value marked while under review.
Update cadence and its limits#
All source documents are re-checked on a monthly cycle, with human adjudication of detected changes within 14 days. Between checks, values can go stale — which is why every fact shows its own last-verified date instead of a page-level freshness claim. Coverage is uneven and shown honestly: some services currently have far fewer assessed dimensions than others, and the per-service pages say so.
Why there are no scores#
Scores are how comparison sites quietly become recommendation engines. A composite “privacy score” would (a) smuggle our threat model into your decision, (b) turn factual reporting into inducement, and (c) erase exactly the nuance this dataset exists to preserve — a phone requirement that one reader shrugs at is disqualifying for another. So: facts, dates, sources, and their disagreements. Ranking them is your job, because only you know what you are defending against.
Selection and licensing#
The current eight services were selected for independent multi-source presence and passive verifiability (documents that can be captured and cited without interacting with the service). The set is not exhaustive and does not claim to be. Our metadata and annotations are CC BY 4.0; quoted provider text remains the provider’s. The machine-readable export lives at /en/data/kyc-drift/index.json.