DataTalksClub / DataTalksClub/website
Epic: Implement privacy rights, retention, erasure, and propagation
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Product outcome
People with or without an account can exercise access, portable export, correction, restriction, objection, and full-erasure rights through one auditable privacy-request lifecycle. Every owning domain contributes data through an explicit adapter; retention, erasure, cache/projection invalidation, processor propagation, and restored-backup fencing are idempotent, bounded, fail closed, and independently verifiable without exposing another person's data or resurrecting erased processing.
#64 is the cross-domain parent epic and final privacy/HUMAN acceptance record. It is not one engineer-sized change. It coordinates seven runtime children plus separately delivered non-activating interface prerequisites; every issue advances only when its current labels and artifact-based dependencies permit, through the full role-separated lifecycle in _docs/PROCESS.md.
Parent epic: #8.
Normative authority
_docs/PROCESS.md: issue lifecycle, role separation, verification evidence, and sensitive-artifact rules._docs/specs/01-platform-architecture.mdand_docs/architecture/app-boundaries.md: domain ownership and service/adaptor boundaries._docs/specs/04-courses-and-cohorts.mdand05-events-registration-email.md: educational, event, consent, delivery, and Relay-owned records._docs/specs/06-studio-and-admin-api.md: capability/queryset authorization, revision/idempotency, audit, export, and Studio/API parity._docs/specs/07-security-privacy-operations.md: privacy baseline, approved default retention, rights, erasure, propagation, cache/log redaction, and restore-tombstone rules._docs/specs/09-migration-rollout-roadmap.md: production-data, cutover, rollback, and reconciliation gates._docs/specs/10-verification-strategy.md: privacy, security, accessibility, processor-failure, and restore evidence._docs/specs/open-decisions.md, resolved decision 12, and closed #23: privacy contact, minors treatment, full-erasure direction, approved default periods, and the issued real-name certificate exception._docs/legal/data-flow-inventory.mdand the public legal pages: useful source inventories and HUMAN gaps, not permission to infer missing legal facts.
Superseded dependency status
The old statement “Depends on #23” is stale. #23 is closed with owner direction:
- privacy contact: Alexey Grigorev,
alexey@datatalks.club; - no age gate or special minors workflow; age is not verified and no differential treatment is inferred;
- a learner request means full erasure of personal data, not a generic anonymize-and-retain default;
- the provisional periods in spec 07 are approved defaults;
- an already-issued certificate that used an explicitly chosen real name remains as issued, while ordinary leaderboard/certificate display uses the anonymous generated-name behavior.
Engineering may derive service boundaries, state machines, idempotency, redaction, adapter interfaces, tombstone fencing, and verification from the architecture. It may not invent the remaining HUMAN/legal records below.
Remaining HUMAN/legal decisions
The parent retains decision and human until an authorized owner/legal reviewer records exact versioned answers:
- verified controller/operator legal identity, address, authorized representative, complaint/contact details, applicable tax/registration data, and final Impressum/Terms/Privacy wording and displayed effective date;
- complete controller/processor/subprocessor register with processing regions, international-transfer mechanism/safeguards, contract owner, incident contact, and review/expiry dates;
- purpose and lawful basis by data field/integration, including service performance, legitimate interest, legal obligation, publication, optional marketing/analytics consent, withdrawal, suppression, restriction, and objection handling;
- approved notice/consent versions and migration/provenance rules for current legacy combined newsletter evidence without inferring new consent;
- the exact “educational record active” end trigger and post-active schedule, production log period, legal/security/abuse hold matrix, and implementation of the narrow already-issued real-name certificate exception;
- accountless identity-proof/recovery requirements, request/appeal/escalation deadlines, restriction/objection behavior, competent supervisory-authority wording, and safe evidence returned to the requester;
- processor propagation confirmation/receipt requirements, retry/escalation deadlines, tombstone expiry/legal-hold interaction, and which non-PII proof may be retained after erasure.
Raw children remain needs grooming wherever one of these decisions affects acceptance. Synthetic architectural work may be groomed independently only when it cannot prejudge the missing legal answer or activate production processing.
Child delivery map
- #254 — Authority, inventory, notice, and retention-register reconciliation. Deliver the bounded source-only register slice with
Refs #254; #254 remains open withdecision/humanuntil authorized legal copy and HUMAN acceptance are complete. - #255 — Privacy-request aggregate and domain-adapter kernel. Runtime kernel only after the accepted #281 input contract; no domain PII logic or requester/staff surface.
- #256 — Export artifacts and correction orchestration. Runtime orchestration only after accepted #255 and #285; production adapters, private storage, and HUMAN activation remain separate.
- #257 — Retention registry and runner. Runtime foundation only after accepted #255 and #283; every production row remains disabled until its later domain/control activation issue.
- #258 — Erasure tombstone and restore fence. Re-groom only after accepted #255/#257 and the recovery interfaces described below; live startup/release remains coordinated with #66 and HUMAN authority.
- #259 — Projection/cache/search/export invalidation and processor receipts. Re-groom only after accepted #282 and all source-operation runtimes; production email/processor activation additionally requires #49 and HUMAN authority.
- #260 — Self/accountless and Studio/admin privacy surfaces. Last runtime child, after accepted services, required production domain adapters, #32/#33, and applicable HUMAN/legal decisions.
Non-activating interface prerequisites
These issues are separately delivered source contracts, not additional runtime children and not production authority:
- #281 follows the accepted/merged/green #254 source-only slice and supplies the non-activating kernel input consumed by #255.
- #283 follows #281 and supplies the non-activating retention manifest consumed by #257.
- #285 follows #281 and supplies the non-activating export/correction input consumed by #256.
- #282 follows the accepted runtime interfaces #255–#258 and supplies the non-activating propagation input consumed by #259.
- #284 is an email/recovery interface outside the seven privacy runtime children. It follows #264 and feeds the recovery-specific #49 implementation that #258 must consume.
Domain adapters are separate delivery issues
The kernel owns only the protocol, orchestration, common state, bounded evidence, and fail-closed behavior. Each domain owns its data inventory, authorization, export/correction/retention/erasure implementation, and adapter tests. Do not put all domain logic into child 2.
- #251 is the raw
accounts/MemberProfile/Slack-state adapter shared with parent #108. It remainsneeds groomingand consumes accepted #64 primitives; it is not replaced or silently absorbed by this epic. - Separate domain-adapter issues are required as their models stabilize for accounts/identity beyond #251, courses/learners/submissions/reviews/certificates, events/accountless registration/attendance, email/delivery/suppression, content/public contributions, audit/security/logs, and any enabled search/analytics/provider projection.
- Domain adapters depend on their owning model/service issue. #64 does not authorize an accounts→courses import, direct cross-domain mutation, cascade erasure, or fabricated placeholder implementation.
- The parent closes only after every production personal-data domain in the accepted inventory has an accepted adapter or an explicit HUMAN-approved not-applicable row.
Cross-child architecture and security invariants
- A
PrivacyRequesthas an opaque stable ID, subject class, verified ownership/identity-proof status, requested rights, policy/notice version, lifecycle revision, deadlines, legal-hold/exception state, per-domain progress, requester-safe result, and redacted audit. It never stores credentials, raw tokens, provider payloads, or unnecessary copies of requested data. - Public/self, Studio, admin API, jobs, commands, restore tooling, and processor callbacks are adapters over shared application services. Each domain mutation occurs only through that domain's service.
- Account and accountless identity proof is purpose-bound, expiring, rate-limited, non-enumerating, and replay-safe. Staff access is deny-by-default at function, object, and sensitive-field level.
- Export artifacts are encrypted/private, short-lived, one-subject scoped, bounded, formula-safe where tabular, and excluded from caches, logs, browser history, screenshots, issue evidence, backups beyond policy, and public storage.
- Full erasure is the default approved disposition. Only a versioned legal/security/educational exception may retain the minimum explicit field; it leaves bounded non-PII reconciliation evidence and never becomes a generic anonymize-and-retain escape hatch.
- Retention and erasure commands are dry-run-capable, deterministic for a pinned policy/input identity, resumable, idempotent, concurrency-safe, and fail closed on unknown domains, stale revisions, checksum/policy drift, partial processor failure, or unresolved holds.
- Tombstones survive ordinary restore horizons and gate workers, sends, authentication/use, projections, cache/search rebuilds, exports, and deployment activation until replay and processor/outbox reconciliation pass.
- Marketing/analytics consent is separate, optional, versioned, and withdrawable for future processing. Historical combined/boolean evidence is preserved with provenance but never upgraded into new consent.
- Logs, metrics, traces, audits, reports, screenshots, OpenAPI examples, and issue artifacts contain only bounded safe categories/opaque IDs/counts. No real or reversible PII, credentials, tokens, message bodies, Slack URL, raw provider event, or production export is accepted as evidence.
Dependencies and ordering
The authoritative delivery DAG is artifact-based. An issue that intentionally remains open for HUMAN closure does not block a downstream source/runtime contract once its bounded prerequisite slice has passed independent testing, PM acceptance, merge/push, and green on-call with an immutable identity. A frozen candidate, issue prose, branch, or provisional digest is not consumable authority.
- Deliver the #254 source-only slice with
Refs #254; keep #254 open for its legal/HUMAN closure. - Deliver #281 against the exact accepted #254 identity.
- After #281 is green, proceed independently in parallel: PM re-grooms and delivers #255; deliver #283; deliver #285.
- After those inputs converge, #255 + #285 feed re-groomed #256, while #255 + #283 feed re-groomed #257. #256 and #257 may proceed in parallel once their own gates are met.
- Independently, the recovery lane is #264 → #284 → the recovery-specific #49 implementation. Ordinary #49 delivery work retains its own prerequisites; #281/#283 are not email-state authority.
- Re-groom #258 only after accepted #255/#257 and the exact accepted #264/#284/#49 recovery interfaces. #258 owns the privacy tombstone/fence receipt; #66 alone owns live restore/startup release and the combined rehearsal.
- Deliver #282 only after accepted #255, #256, #257, and #258 interfaces exist, then re-groom #259 against #282 and those exact merged identities.
- Re-groom #260 last, after accepted #255–#259 services, every required production domain adapter, #32/#33, and the applicable HUMAN/legal authority.
#251 and every other domain adapter remain separately groomed after their owning models/services. Missing domain models, adapters, private artifact infrastructure, Relay/provider contracts, or HUMAN values are real fail-closed dependencies; no child may fabricate them.
Source-only contracts (#254 bounded slice and #281/#282/#283/#284/#285) define and validate disabled interfaces only. They do not activate privacy processing, inspect protected data, authorize public legal copy, contact processors, release restored workloads, or satisfy production/HUMAN closure.
Production/protected-data execution, real processor contact, public legal acceptance, and release/cutover remain disabled until the applicable HUMAN decisions and normal role-separated release gates pass.
Parent acceptance criteria
- All seven runtime children, every required non-activating interface prerequisite, and every accepted-inventory domain adapter are filed, independently groomed, delivered, tested, PM-accepted, merged, and observed in the authoritative dependency order.
- The authority register incorporates #23 exactly and every remaining HUMAN/legal decision has a named owner, accepted version, effective/review date, and redacted evidence; repository notices match it without stale “provisional” claims.
- One privacy-request aggregate/kernel supports account and accountless rights, exact state/revision/idempotency/deadline/audit behavior, per-domain adapter progress, partial failure, retry/resume, and safe requester results.
- Portable export and correction cover every accepted domain without disclosing third-party/shared-record data, secrets, internal-only identifiers, or formula/executable content.
- Retention enforces the accepted versioned triggers/periods/holds/exceptions through deterministic dry-run and bounded resumable jobs with reconciliation counts and no sensitive output.
- Full erasure propagates across source records, projections, caches, search, exports, queues, Relay/processors, suppression where legally permitted, and restored backups; the issued-certificate exception is narrow and testable.
- Restore/startup fencing proves a pre-erasure backup cannot resurrect account use, public output, export, projection, cache/search results, or historical sends before tombstone/outbox/processor reconciliation.
- Self/accountless and Studio/admin surfaces are accessible, private/no-store/noindex, non-enumerating, masked by default, revision/idempotency protected, and exactly authorized through #32/#33 capabilities.
- SQLite and production-like PostgreSQL constraint/concurrency tests, migration forward/reverse/apply-twice, focused domain/security tests, processor/restore fault injection, and graph-selected full verification pass with versioned plans and independent tester evidence.
- Browser-owning children pass independent desktop/mobile Playwright with synthetic identities and inspected redacted screenshots; backend-only screenshots are
not_applicableonly when the graph proves no render impact. - [HUMAN] Authorized legal/privacy review confirms the displayed controller/contact/notices/rights/retention/transfer wording and effective date; an authorized synthetic production-like request/erasure/restore rehearsal confirms deadlines and no PII/secret exposure, resend, or resurrection.
Required scenario families
- Account owner, accountless event registrant, absorbed/disabled/quarantined account, missing/expired/replayed proof, duplicate/concurrent request, staff-denied/cross-object access, and deadline/escalation states.
- Empty/one/many domains; third-party/shared peer-review and certificate relations; active/expired holds; narrow issued-certificate exception; missing/unknown adapter; stale policy/revision; crash/retry/resume/cancel.
- Export creation/download/expiry/replay, object-storage denial, formula/Unicode/size boundaries, partial domain failure, correction conflict, and no browser/cache/log leakage.
- Every retention boundary and time-zone edge; dry-run/apply twice; late-arriving data; concurrent writer; changed register/input digest; legal hold; safe aggregate reconciliation.
- Erasure before/during queued/in-flight/ambiguous delivery, projection rebuild, cache fill, search indexing, export creation, backup, restore, rollback, and worker startup; prove fail-closed behavior and no historical resend.
- Processor success/transient/permanent/ambiguous/missing receipt, withdrawal/suppression constraints, Relay outage/callback replay, retry escalation, and no direct provider fallback.
- Desktop/mobile self/accountless intake/status/download and Studio/admin search/detail/action flows: accessible errors/focus/status, safe denials/non-enumeration, masked/full-PII capabilities, confirmation, stale revision, partial failure, and private caching/history.
Explicit non-goals
- No policy invention, legal advice, processor contract approval, production PII inspection/import/export, real requester action, real provider mutation, or production erasure during ordinary engineering/testing.
- No monolithic cross-domain service, direct model mutation outside owning services, accounts→courses runtime import, cascade deletion, or silent anonymization/retention exception.
- No new domain models or product behavior owned by #108/#251, course/cohort issues, event registration issues, #49, #32/#33, #66, search, analytics, or content publishing.
- No deletion of immutable public Git history; public-source correction/removal follows the accepted content/source workflow and legal decision.
- No claim that expiring backups are sufficient without tombstone replay, or that a provider request succeeded without an accepted receipt/reconciliation state.
Delivery convention
Child and adapter commits close only their own accepted issue after normal gates and reference #64 for coordination. Because final legal wording and production-like privacy/restore acceptance remain HUMAN, #64 keeps human and stays open until those redacted checks are recorded.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with _docs/PROCESS.md, the listed privacy architecture and verification specs, and the child delivery map for #254–#260 and prerequisites #281–#285. This is a cross-domain parent epic, not a standalone change; completion requires accepted runtime children, domain adapters or HUMAN-approved not-applicable rows, artifact-based verification, and the remaining legal decisions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100