Personal Data Rights Workbench

Turn a vague “delete my data” request into a transparent plan that shows what can go, what must stay, and why.

Comment

Delete What You Can, Explain What You Must Keep

1. What we built

The Personal Data Rights Workbench makes a synthetic account's data footprint legible before consequential actions commit. A person or browser agent can inspect a 14-category inventory, read four consent choices and two retention constraints, simulate a complete data-minimization partition, understand feature trade-offs, and stage consent, erasure, or portability actions.

The responsive data map reorganizes into Delete, Retained by rule, and Kept by choice. The headline fixture shows exactly 9 / 2 / 3 categories and an honest 92.6% reduction of deterministic demo bytes. The review matrix shows the exact staged action IDs and values. Commitment through the normal visible page control updates inventory and consent, clears staging, and creates an immutable synthetic receipt.

2. How we used WebMCP

The top-level page registers nine imperative JavaScript tools for inventory, consent, retention, simulation, plan-bound staging, cancellation, and receipt reading. It prefers document.modelContext and retains navigator.modelContext only for older Chrome preview builds.

Registration is scoped with an AbortController and atomic: all nine calls are initiated in one synchronous task, then awaited as a group. If any call throws or rejects, every attempted name is removed, the lifecycle is aborted, and readiness rejects. Tool callbacks use execute(input, { signal }), while tolerating older callers that omit options. Inputs are validated in code, every non-retained category must be explicitly classified, plans receive unique IDs, and all staging is bound to the exact current plan.

No consequential commit tool is exposed through WebMCP. Final commitment uses the normal visible page control and remains subject to Codex/browser safety confirmation; ordinary browser actuation may still reach visible controls. The read-only receipt tool returns only after commitment.

3. Why it matters

Privacy controls often split one intention across opaque settings, retention language, and destructive forms. This workbench explores a more inspectable model: structured agent assistance for inventory and planning, explicit user intent for every category, visible consequences, version-bound staging, and a clear commit point.

The demo does not determine legal rights or establish compliance. It demonstrates how WebMCP can make a complex workflow composable, visible, and truthful before and after commitment.

4. What we learned

Tool quality is inseparable from visible state. The same domain service powers the UI, WebMCP tools, and deterministic rehearsal. A mutating callback rejects if already cancelled, then commits state, synchronously flushes the React subscription update, and returns without awaiting post-mutation work. Confirmed receipts also close every staging path.

We also learned that schemas are routing guidance, not authorization; omitted categories must not be interpreted as user intent; every staged action needs a plan version; partial tool registration is unsafe; and receipts should describe only actions that actually committed. For compatibility with the client used in the demo, tools are registered imperatively in the top-level page.

How we used AI and Codex

This is a new project created during the challenge period. I used Codex while working on the project. The recorded walkthrough uses Codex Site Tools to discover the nine page tools, inspect the synthetic account, simulate and stage the plan, and read the receipt after visible confirmation. Codex also helped prepare the project write-up and testing instructions and run the automated checks. The application itself uses deterministic client-side logic, not an embedded language-model backend.

Testing instructions

No account, credentials, payment, or real personal data is required.

  1. Open https://webmaxru.github.io/webmcp-data-rights-workbench/ directly as the top-level HTTPS page in a WebMCP-capable client. The repository documents Codex Site Tools, ChatGPT's in-app browser, and Chrome with WebMCP enabled; client availability is environment-dependent.
  2. Verify the page reports nine native WebMCP tools ready. If native WebMCP is unavailable, the labelled rehearsal can illustrate the UI but does not establish native tool discovery or invocation.
  3. Ask the agent to inspect inventory, consent, and retention constraints.
  4. Request the deterministic headline plan: keep account_profile, tax_invoices, and saved_delivery_addresses; delete the other nine non-retained categories; leave the two retained categories classified by their rules; and set sale_or_sharing to false.
  5. Have the agent simulate and stage that plan without committing. Verify 9 / 2 / 3, 92.6%, two feature effects, and the exact staged consent and erasure details. All staging must use the returned current plan_id.
  6. Review the visible staged actions and activate Confirm staged actions. Verify nine inventory records become erased, sale-or-sharing consent is false, and staging is cleared.
  7. Ask the agent for get_privacy_receipt. It should match the visible confirmed result. Additional staging, cancellation, or re-confirmation must fail until the synthetic demo is reset.
  8. Refresh for a fresh in-memory account. For negative cases and the consent-only/export-only paths, follow the testing guide.

Known Limitations

  • All records, identities, sizes, retention rules, dates, and receipts are deterministic synthetic fixtures.
  • The 92.6% figure is demo-byte selection, not measured deletion from a real service or proof of privacy improvement.
  • State and receipt immutability are scoped to the in-memory demo session. Refreshing resets the account.
  • Portability is a staged synthetic export request, not a real downloadable data export.
  • There is no identity proofing, legal eligibility engine, production deletion queue, external account connection, analytics, or persistent backend.
  • Browser-preview support and agent safety behavior are outside this app's control; the visible confirmation button is not an authorization boundary that prevents all browser automation.

Links

Built With

Share this project:

Updates

Submission history