fix(privacy): haal het privé-adres en het echte domein uit de voorbeelden (#571) #647

Merged

brenno merged 1 commit from fix/privacy-voorbeeldadres into main 2026-07-22 16:29:06 +00:00

Conversation 0 Commits 1 Files changed 52 +198 -156

brenno commented 2026-07-22 16:28:55 +00:00

Owner

Copy link

Het invoerveld bij Je eigen gegevens toonde het e-mailadres van de beheerder als placeholder, en de uitleg erboven gebruikte politie.nl als illustratie. Allebei via l10n.d(), dus in alle 31 vertaalbestanden.

In een programma waarvan de kernfunctie het herkennen en beschermen van persoonsgegevens is, is dat de verkeerde eerste indruk. Nu staat er wat RFC 2606 daarvoor reserveert.

Wat het schrijven opleverde

De scanner blijkt example.org bewust te negeren (privacy_allowlist.dart, RFC 2606). Dat maakt het een goede placeholder én een slechte testfixture.

Mijn eerste poging verving de adressen dan ook in de tests, en die werden daardoor tandeloos: de contrastgevallen "eigen adres" versus "andermans adres" vonden allebei niets meer, want de scanner kijkt per ontwerp niet naar gereserveerde domeinen. Twee tests werden rood, en dat was terecht.

Teruggedraaid en opnieuw gedaan mét behoud van het contrast: eigen domein en andermans domein zijn nu allebei fictief maar niet-gereserveerd, en de look-alike-vallen (nietandersbureau.nl, mijnandersbureau.nl) zijn meeveranderd — anders toetsen die niets meer, want ze bestaan juist om te bewijzen dat een substring-match niet volstaat.

Ook meegenomen

• De testfixtures droegen hetzelfde privé-adres; die zijn mee opgeschoond.
• Twee regels op de witte lijsten in app_localizations_test.dart hielden het adres óók nog vast, en die waren bovendien verweesd.
• De interne doc-commentaren in privacy_own_identity.dart gebruikten hetzelfde adres en domein.

31 vertalingen bijgewerkt: de placeholder is nieuw vertaald (alleen naam is vertaalbaar; example.org blijft overal letterlijk), en bij de uitlegzin is uitsluitend het domein gewisseld zodat er geen stilistische drift ontstaat.

make check groen.

Closes #571

Het invoerveld bij *Je eigen gegevens* toonde het e-mailadres van de beheerder als placeholder, en de uitleg erboven gebruikte `politie.nl` als illustratie. Allebei via `l10n.d()`, dus in alle 31 vertaalbestanden. In een programma waarvan de kernfunctie het herkennen en beschermen van persoonsgegevens is, is dat de verkeerde eerste indruk. Nu staat er wat RFC 2606 daarvoor reserveert. ## Wat het schrijven opleverde De scanner blijkt `example.org` **bewust te negeren** (`privacy_allowlist.dart`, RFC 2606). Dat maakt het een goede placeholder én een slechte testfixture. Mijn eerste poging verving de adressen dan ook in de tests, en die werden daardoor tandeloos: de contrastgevallen "eigen adres" versus "andermans adres" vonden allebei niets meer, want de scanner kijkt per ontwerp niet naar gereserveerde domeinen. Twee tests werden rood, en dat was terecht. Teruggedraaid en opnieuw gedaan **mét** behoud van het contrast: eigen domein en andermans domein zijn nu allebei fictief maar niet-gereserveerd, en de look-alike-vallen (`nietandersbureau.nl`, `mijnandersbureau.nl`) zijn meeveranderd — anders toetsen die niets meer, want ze bestaan juist om te bewijzen dat een substring-match niet volstaat. ## Ook meegenomen - De testfixtures droegen hetzelfde privé-adres; die zijn mee opgeschoond. - Twee regels op de witte lijsten in `app_localizations_test.dart` hielden het adres óók nog vast, en die waren bovendien verweesd. - De interne doc-commentaren in `privacy_own_identity.dart` gebruikten hetzelfde adres en domein. 31 vertalingen bijgewerkt: de placeholder is nieuw vertaald (alleen `naam` is vertaalbaar; `example.org` blijft overal letterlijk), en bij de uitlegzin is uitsluitend het domein gewisseld zodat er geen stilistische drift ontstaat. `make check` groen. Closes #571

brenno added 1 commit 2026-07-22 16:28:55 +00:00

fix(privacy): haal het privé-adres en het echte domein uit de voorbeelden ... 5527a92fd4

Gevonden bij de eerste-indruk-review vóór publicatie. Het invoerveld bij "Je
eigen gegevens" toonde het e-mailadres van de beheerder als placeholder, en de
uitleg erboven gebruikte politie.nl als voorbeeld — allebei via l10n.d(), dus
in alle 31 vertaalbestanden.

In een programma waarvan de kernfunctie het herkennen en beschermen van
persoonsgegevens is, is dat de verkeerde eerste indruk. Nu staat er wat RFC
2606 daarvoor reserveert.

Onderweg bleek de scanner example.org bewust te negeren (privacy_allowlist.dart,
RFC 2606). Dat maakt het een goede placeholder én een slechte testfixture: mijn
eerste poging verving de adressen ook in de tests, en die werden daardoor
tandeloos — de scanner vindt daar per ontwerp niets meer. Teruggedraaid en
opnieuw gedaan mét behoud van het contrast: eigen domein en andermans domein
zijn nu allebei fictief maar niet-gereserveerd, en de look-alike-vallen
(nietandersbureau.nl) zijn meeveranderd, anders toetsen die niets meer.

De testfixtures droegen hetzelfde privé-adres, dus die gaan mee. Twee
witte-lijstregels in app_localizations_test.dart hielden het adres ook nog vast;
die waren bovendien verweesd.

Closes #571

brenno merged commit a188e87070 into main 2026-07-22 16:29:06 +00:00

brenno referenced this pull request from a commit 2026-07-22 16:29:08 +00:00

Merge pull request 'fix(privacy): haal het privé-adres en het echte domein uit de voorbeelden (#571)' (#647) from fix/privacy-voorbeeldadres into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

accepted

Assessed and will be built

  

bug

Something is broken

  

declined

Assessed and will not be built

  

docs

Documentation only

  

duplicate

Already tracked elsewhere

  

enhancement

New feature or improvement request

  

good first issue

Small, self-contained, and a good place to start

  

in-progress

Someone is working on this right now. Do not start it in parallel.

  

needs-info

Waiting for the reporter

  

privacy

Personal data can leak. Handled before anything else.

  

security

A weakness someone could use. Handled before anything else.

  

triage

Awaiting assessment

No labels

accepted

bug

declined

docs

duplicate

enhancement

good first issue

in-progress

needs-info

privacy

security

triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

LibreKAT/Ocideck!647

No description provided.