[Docs] Say a build gate enforces the projection boundary, not the type system #601

New issue

Closed

opened 2026-07-22 16:18:17 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 16:18:17 +00:00

Owner

Found in the pre-publication claim audit.

The claim — README.md:27: personal data is "removed at a single projection boundary that the type system enforces, so no render surface can forget it — screen, presenter, audience window, PDF, PPTX, HTML, speaker notes, document metadata." The same wording sits in lib/services/privacy/privacy_projection.dart:12-16.

What the project own gate says: tool/check_audience_boundary.dart:5-9 — "SECURITY_DESIGN §8 belooft een compile-time garantie … De compiler houdt die belofte — maar alleen voor de functies die het type ook echt eisen. De vraag die daaronder ligt is welke functies dat zijn, en die stond hier als een lijst van vier hard-gecodeerde instappunten. Een vijfde uitvoeroppervlak werd niet gezien."

What actually prevents a forgotten surface is a hand-maintained registry (:70-158, ~18 entries) plus an AST heuristic that fires only when a declaration both takes a Deck/AudienceDeck and contains one of six artefact primitives in its own body (:161-170), with the blind spot stated at :31-35: a surface that delegates the writing to a helper two layers down is not seen.

Why this matters now: "the type system enforces it" is the strongest security sentence in the README, and the first one a security reviewer will test. The truth is still good — a private constructor plus a build-breaking registry gate is more than most tools do — but the inference "so no render surface can forget it" does not follow from the private constructor, and the repository own tool header says so.

Proposal: adjust the claim, leave the code alone. "…removed at a single projection boundary: AudienceDeck has a private constructor, so only the projection can produce one, and a build gate (tool/check_audience_boundary.dart) forces every new output surface to be classified as audience-side or source-side before it can land." Defensible, checkable, and still impressive.

Found in the pre-publication claim audit. **The claim** — `README.md:27`: personal data is "removed at a single **projection boundary** that the type system enforces, **so no render surface can forget it** — screen, presenter, audience window, PDF, PPTX, HTML, speaker notes, document metadata." The same wording sits in `lib/services/privacy/privacy_projection.dart:12-16`. **What the project own gate says:** `tool/check_audience_boundary.dart:5-9` — "SECURITY_DESIGN §8 belooft een compile-time garantie … De compiler houdt die belofte — **maar alleen voor de functies die het type ook echt eisen**. De vraag die daaronder ligt is *welke* functies dat zijn, en die stond hier als een lijst van vier hard-gecodeerde instappunten. Een vijfde uitvoeroppervlak werd niet gezien." What actually prevents a forgotten surface is a hand-maintained registry (`:70-158`, ~18 entries) plus an AST heuristic that fires only when a declaration both takes a `Deck`/`AudienceDeck` *and* contains one of six artefact primitives in its own body (`:161-170`), with the blind spot stated at `:31-35`: a surface that delegates the writing to a helper two layers down is not seen. **Why this matters now:** "the type system enforces it" is the strongest security sentence in the README, and the first one a security reviewer will test. The truth is still good — a private constructor plus a build-breaking registry gate is more than most tools do — but the inference "so no render surface can forget it" does not follow from the private constructor, and the repository own tool header says so. **Proposal:** adjust the claim, leave the code alone. "…removed at a single projection boundary: `AudienceDeck` has a private constructor, so only the projection can produce one, and a build gate (`tool/check_audience_boundary.dart`) forces every new output surface to be classified as audience-side or source-side before it can land." Defensible, checkable, and still impressive.

brenno added the

docs

security

labels

2026-07-22 16:18:17 +00:00

brenno referenced this issue from a commit

2026-07-22 17:12:00 +00:00

docs: corrigeer de projectiegrens-claim, en markeer het dode meldadres

brenno referenced this issue from a pull request that will close it,

2026-07-22 17:12:23 +00:00

test+docs: bytecap en omleidingsweigering echt getoetst, projectiegrens-claim recht (#618, #601, #645) #654

brenno closed this issue