docs(ontwerp): een privacybevinding terzijde leggen, per deck (#651) #734

Merged
brenno merged 1 commit from design/privacy-terzijdelegging-651 into main 2026-07-23 12:08:53 +00:00
Owner

Het besluit is genomen — per deck, niet per gebruiker — en dat betekent een sidecar, en dus een formaatwijziging. Deze repo hoort daar eerst een afgetoetst ontwerp voor te hebben. Dit is dat ontwerp; er staat nog geen regel code in.

De premisse van het issue klopte niet, en dat scheelt werk

Het issue zegt dat een privacybevinding maar één actie kent: "Never report this rule again", een globale schakelaar. Er bestaan er drie:

Hendel Reikwijdte
PrivacyDisposition op het deck elke bevinding in het deck
PrivacyDisposition op een slide elke bevinding op die slide
"Deze regel nooit meer melden" die regel, in elk deck, voorgoed

accept op een slide is dus al een oordeel per deck dat andere slides en andere decks met rust laat.

Wat werkelijk ontbreekt zit één stap fijner: binnen één slide. Een slide met twee bevindingen — een collega-naam die er hoort en een adres dat er niet hoort — kent alleen alles-of-niets. Dát is het gat, en het is kleiner dan het issue suggereert.

Wat het ontwerp vastlegt

  • Een sidecar <naam>.privacy-dismissals.json, niet een sleutel in de front matter. Om dezelfde reden die in 0.1.0 zeven sleutels uit de front matter haalde: het .md blijft leesbaar en uitwisselbaar. Een disposition is één woord en leest prima; een salted commitment is precies de base64-achtige ruis waar dat besluit over ging.
  • Identiteit = regel-id + slide-id + een salted commitment over de match-span. Nooit de ruwe waarde: die span ís de persoonsgegevens, en een kale hash van een naam is één woordenboek van die naam verwijderd.
  • Verandert de tekst, dan vervalt de terzijdelegging en komt de bevinding terug. Dat is de veilige richting, en het is geen nieuw begrip: de notitiecodec doet al precies dit met een inhoudsvingerafdruk.
  • De scanner blijft vinden. Het paneel verbergt; privacyRawScanProvider verandert niet, dus MIAUW EIS 1.1 en de exportsamenvatting zien het volle aantal.
  • Voor de exportpoort telt het wél als afgehandeld, net als accept. Anders houdt de auteur een permanent geblokkeerde export met als enige uitweg de globale schakelaar — precies wat deze functie moet voorkomen. Staat als besluit opgeschreven, niet als bijzaak.

Drie lessen die deze repo al betaald heeft, hergebruikt in plaats van opnieuw ontdekt: het salted commitment (redactiemanifest), de grafsteen bij ongedaan maken in plaats van verwijderen (inklaag, D7), en één regel per entry zodat git's tekst-merge werkt (notities, #541).

Eén vraag blijft open

OQ-1 — overleeft een terzijdelegging een wijziging van de regel zelf? Het antwoord staat er met de reden bij, want iemand gaat de andere kant voorstellen (ankeren op de regelversie), en dat laat terzijdeleggingen bij elke catalogusverversing verlopen. Bevestigen of verwerpen vóór de bouw.

Poort: make check groen. Geregistreerd in pubspec.yaml, de lezertegel en 31 taaltitels.

Refs #651

Het besluit is genomen — **per deck, niet per gebruiker** — en dat betekent een sidecar, en dus een formaatwijziging. Deze repo hoort daar eerst een afgetoetst ontwerp voor te hebben. Dit is dat ontwerp; **er staat nog geen regel code in.** ## De premisse van het issue klopte niet, en dat scheelt werk Het issue zegt dat een privacybevinding maar één actie kent: *"Never report this rule again"*, een globale schakelaar. Er bestaan er drie: | Hendel | Reikwijdte | |---|---| | `PrivacyDisposition` op het **deck** | elke bevinding in het deck | | `PrivacyDisposition` op een **slide** | elke bevinding op die slide | | *"Deze regel nooit meer melden"* | die regel, in **elk** deck, voorgoed | `accept` op een slide is dus al een oordeel per deck dat andere slides en andere decks met rust laat. Wat werkelijk ontbreekt zit **één stap fijner: binnen één slide**. Een slide met twee bevindingen — een collega-naam die er hoort en een adres dat er niet hoort — kent alleen alles-of-niets. Dát is het gat, en het is kleiner dan het issue suggereert. ## Wat het ontwerp vastlegt - **Een sidecar** `<naam>.privacy-dismissals.json`, niet een sleutel in de front matter. Om dezelfde reden die in 0.1.0 zeven sleutels uit de front matter haalde: het `.md` blijft leesbaar en uitwisselbaar. Een disposition is één woord en leest prima; een salted commitment is precies de base64-achtige ruis waar dat besluit over ging. - **Identiteit** = regel-id + slide-id + een salted commitment over de match-span. Nooit de ruwe waarde: die span *ís* de persoonsgegevens, en een kale hash van een naam is één woordenboek van die naam verwijderd. - **Verandert de tekst, dan vervalt de terzijdelegging** en komt de bevinding terug. Dat is de veilige richting, en het is geen nieuw begrip: de notitiecodec doet al precies dit met een inhoudsvingerafdruk. - **De scanner blijft vinden.** Het paneel verbergt; `privacyRawScanProvider` verandert niet, dus MIAUW EIS 1.1 en de exportsamenvatting zien het volle aantal. - **Voor de exportpoort telt het wél als afgehandeld**, net als `accept`. Anders houdt de auteur een permanent geblokkeerde export met als enige uitweg de globale schakelaar — precies wat deze functie moet voorkomen. Staat als besluit opgeschreven, niet als bijzaak. Drie lessen die deze repo al betaald heeft, hergebruikt in plaats van opnieuw ontdekt: het salted commitment (redactiemanifest), de grafsteen bij ongedaan maken in plaats van verwijderen (inklaag, D7), en één regel per entry zodat git's tekst-merge werkt (notities, #541). ## Eén vraag blijft open **OQ-1 — overleeft een terzijdelegging een wijziging van de regel zelf?** Het antwoord staat er met de reden bij, want iemand gaat de andere kant voorstellen (ankeren op de regelversie), en dat laat terzijdeleggingen bij elke catalogusverversing verlopen. Bevestigen of verwerpen vóór de bouw. Poort: `make check` groen. Geregistreerd in `pubspec.yaml`, de lezertegel en 31 taaltitels. Refs #651
Het besluit is genomen — per deck, niet per gebruiker — en dat betekent een
sidecar, en dus een formaatwijziging. Deze repo hoort daar eerst een afgetoetst
ontwerp voor te hebben, dus dat is dit. Er staat nog geen regel code.

**Onderweg bleek de premisse van het issue niet te kloppen, en dat scheelt in
wat er gebouwd moet worden.** Het issue zegt dat een bevinding maar één actie
kent, "deze regel nooit meer melden", een globale schakelaar. Er bestaan er
drie: die globale schakelaar, én een PrivacyDisposition per deck, én een per
slide. `accept` op een slide is al een oordeel per deck dat andere slides en
andere decks met rust laat.

Wat werkelijk ontbreekt zit één stap fijner: binnen één slide. Een slide met
twee bevindingen — een collega-naam die er hoort en een adres dat er niet
hoort — kent alleen alles-of-niets. Dát is het gat, en het is kleiner dan het
issue suggereert.

**Wat het ontwerp vastlegt.** Een sidecar `<naam>.privacy-dismissals.json` en
niet een sleutel in de front matter, om de reden die in 0.1.0 zeven sleutels uit
de front matter haalde: het `.md` blijft leesbaar en uitwisselbaar, en een
salted commitment is precies de base64-achtige ruis waar dat over ging.

Drie lessen die deze repo al betaald heeft, hergebruikt in plaats van opnieuw
ontdekt: het anker is een salted commitment en nooit de ruwe waarde (zoals het
redactiemanifest), ongedaan maken laat een grafsteen achter in plaats van te
verwijderen (zoals de inklaag in D7), en het bestand wordt per regel geschreven
zodat de tekst-merge van git werkt (zoals de notities in #541).

Eén vraag blijft bewust open (OQ-1): overleeft een terzijdelegging een wijziging
van de regel zelf. Het antwoord staat erbij met de reden, want iemand gaat de
andere kant voorstellen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
brenno merged commit c5b2d50f8a into main 2026-07-23 12:08:53 +00:00
Sign in to join this conversation.
No description provided.