LibreKAT/Ocideck

Watch

Fork 0

docs(privacy): zeg wie verwerkingsverantwoordelijke is voor wat in een deck staat (#580) #675

Merged

brenno merged 1 commit from docs/privacy-rolverdeling-580 into main

2026-07-22 19:41:06 +00:00

brenno commented

2026-07-22 19:41:00 +00:00

Owner

Sluit #580.

docs/PRIVACY.md behandelde de lezer alleen als betrokkene — "your files are yours" — en nergens als de verwerkingsverantwoordelijke die hij is zodra zijn deck andermans naam draagt. Voor een gereedschap dat wordt aangeprezen voor pentestrapportage is dat het eerste gat dat een lezer met AVG-kennis vindt. Een grep op controller|verwerkingsverantwoordelijk|processor|verwerker|art. 28 over docs/*.md en de wortel-*.md gaf nul treffers in AVG-zin.

Nieuwe subsectie Who is controller, and who is not onder Your rights and this tool:

de gebruiker is verantwoordelijke voor wat er in zijn deck zit — tenzij zijn opdracht hem iets anders maakt: wie in opdracht test kan verwerker van zijn klant zijn, of gezamenlijk verantwoordelijke (art. 26). Dat is niet academisch: een verwerker mag een sub-verwerker niet inschakelen zonder voorafgaande toestemming (art. 28(2)), en dat gaat precies over de derde bullet;
Stichting LibreKAT is geen verwerker en biedt dus geen verwerkersovereenkomst — niet als weigering, maar omdat de uitgever geen deck ontvangt;
de partijen die je zélf aanzet verwerken wél namens jou; die art. 28-afspraak is van jou met hen, en zit die partij buiten de EER, dan is art. 28 de helft — hoofdstuk V is de andere.

En één pad past niet in die verdeling: de CVE-spiegel van de uitgever. Wie hem gebruikt stuurt zijn zoekterm naar de uitgever, en daarvoor is de stichting zelf verwerkingsverantwoordelijke. Wat die spiegel vastlegt en hoe lang is niet gepubliceerd; dat staat er zo bij, zonder een termijn te verzinnen die nog niet vaststaat (zie #579).

Wat de jurist eruit haalde

De rolblik-jurist draaide over de eerste versie en vond één aantoonbaar onjuiste bewering die ik zelf had geschreven: "the address is a setting you can repoint at your own mirror or at nothing at all". Getoetst aan de code klopt dat twee keer niet:

lib/widgets/dialogs/cve_picker.dart:73-75 — het veld leegmaken zet de spiegel stilzwijgend terug op cveapi.librekat.nl. Wie de zin letterlijk volgde om niets meer te sturen, stuurde alsnog;
lib/services/cve_search_service.dart:227-234 — ENISA en MITRE staan ingebakken achter je eigen spiegel en zijn geen instelling.

Beide staan nu genoemd, mét wat wél waar is: met de lokale CVE-database geïnstalleerd wordt de online keten helemaal niet gebruikt, ook niet als de lokale zoekactie niets oplevert (cve_picker.dart:55-69).

Poort

make check groen (niet door tail gepijpt): opmaak, analyse, conventies, privacyprojectie, methodelengte, dode code, hardgecodeerde tekst, de volledige testsuite, dekkingsvloer en per-bestandsvloer.

Alleen documentatie, geen code — geen SBOM, geen l10n. make check-secrets en make sast zijn niet gedraaid; deze wijziging voegt geen afhankelijkheid, geen sleutel en geen uitgaand verkeer toe.

Sluit #580. `docs/PRIVACY.md` behandelde de lezer alleen als *betrokkene* — "your files are yours" — en nergens als de **verwerkingsverantwoordelijke** die hij is zodra zijn deck andermans naam draagt. Voor een gereedschap dat wordt aangeprezen voor pentestrapportage is dat het eerste gat dat een lezer met AVG-kennis vindt. Een `grep` op `controller|verwerkingsverantwoordelijk|processor|verwerker|art. 28` over `docs/*.md` en de wortel-`*.md` gaf nul treffers in AVG-zin. Nieuwe subsectie *Who is controller, and who is not* onder *Your rights and this tool*: - de gebruiker is verantwoordelijke voor wat er in zijn deck zit — **tenzij zijn opdracht hem iets anders maakt**: wie in opdracht test kan verwerker van zijn klant zijn, of gezamenlijk verantwoordelijke (art. 26). Dat is niet academisch: een verwerker mag een sub-verwerker niet inschakelen zonder voorafgaande toestemming (art. 28(2)), en dat gaat precies over de derde bullet; - Stichting LibreKAT is geen verwerker en biedt dus geen verwerkersovereenkomst — niet als weigering, maar omdat de uitgever geen deck ontvangt; - de partijen die je zélf aanzet verwerken wél namens jou; die art. 28-afspraak is van jou met hen, en zit die partij buiten de EER, dan is art. 28 de helft — hoofdstuk V is de andere. En één pad past niet in die verdeling: de **CVE-spiegel** van de uitgever. Wie hem gebruikt stuurt zijn zoekterm naar de uitgever, en daarvoor is de stichting zelf verwerkingsverantwoordelijke. Wat die spiegel vastlegt en hoe lang is niet gepubliceerd; dat staat er zo bij, zonder een termijn te verzinnen die nog niet vaststaat (zie #579). ## Wat de jurist eruit haalde De rolblik-jurist draaide over de eerste versie en vond één **aantoonbaar onjuiste** bewering die ik zelf had geschreven: "the address is a setting you can repoint at your own mirror **or at nothing at all**". Getoetst aan de code klopt dat twee keer niet: - `lib/widgets/dialogs/cve_picker.dart:73-75` — het veld leegmaken zet de spiegel stilzwijgend terug op `cveapi.librekat.nl`. Wie de zin letterlijk volgde om niets meer te sturen, stuurde alsnog; - `lib/services/cve_search_service.dart:227-234` — ENISA en MITRE staan ingebakken achter je eigen spiegel en zijn geen instelling. Beide staan nu genoemd, mét wat wél waar is: met de **lokale CVE-database** geïnstalleerd wordt de online keten helemaal niet gebruikt, ook niet als de lokale zoekactie niets oplevert (`cve_picker.dart:55-69`). ## Poort `make check` groen (niet door `tail` gepijpt): opmaak, analyse, conventies, privacyprojectie, methodelengte, dode code, hardgecodeerde tekst, de volledige testsuite, dekkingsvloer en per-bestandsvloer. Alleen documentatie, geen code — geen SBOM, geen l10n. `make check-secrets` en `make sast` zijn niet gedraaid; deze wijziging voegt geen afhankelijkheid, geen sleutel en geen uitgaand verkeer toe.

brenno added 1 commit

2026-07-22 19:41:00 +00:00

docs(privacy): zeg wie verwerkingsverantwoordelijke is voor wat in een deck staat (#580 )

CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 25s

Details

CI / Web hardening (push) Failing after 24s

Details

CI / Docs links (push) Failing after 27s

Details

CI / Supply-chain (Trivy · advisory) (push) Failing after 30s

Details

CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 27s

Details

CI / Web hardening (pull_request) Failing after 27s

Details

CI / Docs links (pull_request) Failing after 26s

Details

CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 27s

Details

CI / Test (macos-latest) (push) Has been cancelled

Details

CI / Test (windows-latest) (push) Has been cancelled

Details

CI / Test (macos-latest) (pull_request) Has been cancelled

Details

CI / Test (windows-latest) (pull_request) Has been cancelled

Details

9387d417a8

PRIVACY.md behandelde de lezer alleen als betrokkene — "your files are
yours" — en nergens als de verwerkingsverantwoordelijke die hij is zodra
zijn deck andermans naam draagt. Voor een gereedschap dat wordt aangeprezen
voor pentestrapportage is dat het eerste gat dat een lezer met AVG-kennis
vindt, en het kost tekst, geen bouwwerk.

Drie regels, en een vierde die niet gladgestreken wordt:

- de gebruiker is verwerkingsverantwoordelijke voor wat er in zijn deck zit;
- LibreKAT is geen verwerker en biedt dus geen verwerkersovereenkomst — niet
  als weigering, maar omdat de uitgever geen deck ontvangt;
- de partijen die je zélf aanzet (AI-eindpunt, S3, WebDAV, forge) verwerken
  wél namens jou; die art. 28-afspraak is van jou met hen;
- en de CVE-spiegel van de uitgever past niet netjes in die verdeling. Wie
  hem gebruikt, stuurt zijn zoekterm naar de uitgever. Dat staat er nu bij.

Sluit #580.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 3d32fe4dff into main

2026-07-22 19:41:06 +00:00

brenno referenced this pull request from a commit

2026-07-22 19:41:08 +00:00

Merge pull request 'docs(privacy): zeg wie verwerkingsverantwoordelijke is voor wat in een deck staat (#580)' (#675) from docs/privacy-rolverdeling-580 into main

brenno referenced this pull request

2026-07-22 19:41:40 +00:00

[Privacy] No public document says who is controller for the personal data in a deck #580