Data Protection Impact Assessment

Last updated:

A Data Protection Impact Assessment (DPIA) under UK GDPR Art. 35 is required when processing is likely to result in a high risk to people's rights and freedoms — typically large-scale automated profiling, systematic monitoring, or large-scale processing of special-category data. This page records why the high-risk threshold is not met today, the data-flow assessment that supports that conclusion, and the precise point at which a full DPIA becomes required.

Scope and conclusion

proof. is a personal cookbook tool. It stores and versions content the user writes, rendering and exporting it on their request. There is no automated profiling, no behavioural tracking, and no special-category data processed by design. Processing is confined to providing the service the user explicitly asked for.

One optional feature sends recipe text to a language model: the assistant, which converts a pasted recipe into proof. syntax or rewrites a draft the user runs an operation on. It is off by default and requires a per-user opt-in, made in Settings, or at the point the user first uses an assistant feature; with the opt-in off, nothing is sent. With it on, only the text the user submits for that operation is sent — the pasted text, the draft the operation is run on, and the user's own library settings. The model runs on Cloudflare Workers AI, routed through Cloudflare's AI Gateway, so the processing stays inside proof.'s existing infrastructure provider and adds no new sub-processor. Cloudflare states it does not use this content to train models. Prompt and response payloads are not retained in the gateway logs, which keep metadata only (token counts, model, status, cost); a proposed result is held for at most 48 hours so the user can accept or discard it. The model never writes to a recipe directly.

On that basis the Art. 35 high-risk threshold is not met, and a full DPIA is not triggered. The assessment below documents the data flows so the conclusion is auditable, and the trigger condition is stated so a DPIA is started before — not after — the threshold is crossed.

Data-flow assessment

The data flows present today, with their controls:

  • Account and authentication — email and display name, session cookie. Stored per-user; access gated by session. Minimal identity data, contractually necessary.
  • Recipe content, cook logs, outcomes, media — user-authored content, isolated per user. Not shared with any third party unless the user publishes a recipe link themselves. Exportable and deletable by the user.
  • Feedback to GitHub — the one external flow that carries a user identifier. The issue body carries an opaque synthetic account identifier only; email and display name are excluded. Screenshots are stored separately and referenced by opaque key. The data-minimised design keeps this a low-risk flow.
  • Crash telemetry — sanitised server-side (emails, tokens, and session identifiers stripped) before it is logged. Not linked to user identity beyond the sanitised payload.
  • Waitlist email — single email address, consent-based, auto-purged after rejection or expiry.
  • Assistant (optional, opt-in) — when the user turns it on — in Settings, or at first use of an assistant feature — and then runs an operation, the text for that operation is sent to a language model on Cloudflare Workers AI, through Cloudflare's AI Gateway. What is sent: the pasted recipe text, or the draft the operation is run on, plus the user's library settings as context. What is not sent: account identity beyond an opaque per-user tag used for cost attribution, other users' content, media files, and anything from a recipe the operation was not run on. The lawful basis is consent; it can be withdrawn at any time, and withdrawal takes effect before the next operation. Cloudflare states it does not train on this content. Gateway logs keep metadata only, not the text. A proposed result is stored for at most 48 hours, then expires; it is applied only if the user accepts it.

Identified residual risks are limited and mitigated: data minimisation on the GitHub boundary, sanitisation on telemetry, per-user isolation of content, opt-in and off-by-default assistant processing under user control, self-serve export and erasure, and a single essential cookie with no third-party tracking. None rises to the Art. 35 high-risk threshold.

When a full DPIA becomes required

The assistant described above was assessed before it was enabled, and that assessment is what this page states. Two expansions are outside it, and either one requires a full DPIA before it ships:

  • A model provider outside Cloudflare. Today the model runs on Cloudflare, which already processes all of proof.'s data as its hosting provider, so no new sub-processor receives user content. Sending recipe content to any other provider — including a user-supplied key to a third-party model — adds a sub-processor and changes the risk profile.
  • An autonomous pathway. Today no assistant result reaches a recipe without the user accepting it, and nothing is processed that the user did not submit for that operation. A pathway that acts on a user's library without an explicit accept removes that control and must be assessed on its own terms.

The DPIA for either expansion will document the processor, the data sent and its retention, the legal basis, the user-facing disclosure, and the controls. This page is updated at that time. Neither exists today; nothing on this page describes a feature that is not built.

Contact

Data-protection questions: privacy@proofcook.com. No Data Protection Officer is appointed; for a solo project of this scope none is required.