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

New issue

Closed

opened 2026-07-22 16:15:24 +00:00 by brenno · 2 comments

brenno commented

2026-07-22 16:15:24 +00:00

Owner

Found in the pre-publication legal and privacy review.

Evidence: grep -rni "controller|verwerkingsverantwoordelijk|processor|verwerker|art. 28" across docs/*.md and the root *.md returns zero hits in a GDPR sense. docs/PRIVACY.md:371-374 treats the user solely as a data subject ("your files are yours") and never as a controller. Meanwhile README.md:28 markets the product for penetration-test reports, and docs/PRIVACY.md:266-268 describes "the single finding you are editing (all of its fields)" being sent to a cloud endpoint.

Why this matters: the core promise — that OciDeck is not a processor — rests on a role division that is written down nowhere. A tester who switches on an S3 bucket, a git forge or a cloud AI endpoint becomes a controller towards their own client and needs an art. 28 agreement with that third party. Nothing in the public text says so.

Why this must be fixed before publication: for a tool that positions itself as a privacy tool, this is the most predictable criticism from the first reader with GDPR knowledge. It is also about twenty lines of text — nothing needs to be built.

Proposal: three sentences in docs/PRIVACY.md under Your rights and this tool: (1) the data in your deck belongs to other people and you are the controller for it; (2) LibreKAT is not a processor and therefore offers no processing agreement; (3) if you enable a cloud AI endpoint, S3, WebDAV or a forge, you arrange the processing agreement with that party yourself.

Found in the pre-publication legal and privacy review. **Evidence:** `grep -rni "controller|verwerkingsverantwoordelijk|processor|verwerker|art. 28"` across `docs/*.md` and the root `*.md` returns **zero** hits in a GDPR sense. `docs/PRIVACY.md:371-374` treats the user solely as a data subject ("your files are yours") and never as a controller. Meanwhile `README.md:28` markets the product for penetration-test reports, and `docs/PRIVACY.md:266-268` describes "the single finding you are editing (all of its fields)" being sent to a cloud endpoint. **Why this matters:** the core promise — that OciDeck is not a processor — rests on a role division that is written down nowhere. A tester who switches on an S3 bucket, a git forge or a cloud AI endpoint becomes a controller towards their own client and needs an art. 28 agreement with that third party. Nothing in the public text says so. **Why this must be fixed before publication:** for a tool that positions itself as a privacy tool, this is the most predictable criticism from the first reader with GDPR knowledge. It is also about twenty lines of text — nothing needs to be built. **Proposal:** three sentences in `docs/PRIVACY.md` under *Your rights and this tool*: (1) the data in your deck belongs to other people and you are the controller for it; (2) LibreKAT is not a processor and therefore offers no processing agreement; (3) if you enable a cloud AI endpoint, S3, WebDAV or a forge, you arrange the processing agreement with *that* party yourself.

brenno added the

privacy

docs

labels

2026-07-22 16:15:24 +00:00

brenno added the

in-progress

label

2026-07-22 19:28:18 +00:00

brenno commented

2026-07-22 19:28:18 +00:00

Author

Owner

Opgepakt. Tak: docs/privacy-rolverdeling-580. Reikwijdte: docs/PRIVACY.md, een nieuwe subsectie onder Your rights and this tool.

Opgepakt. Tak: `docs/privacy-rolverdeling-580`. Reikwijdte: `docs/PRIVACY.md`, een nieuwe subsectie onder *Your rights and this tool*.

brenno referenced this issue from a commit

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

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

brenno referenced this issue

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

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

brenno referenced this issue 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 removed the

in-progress

label

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

brenno commented

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

Author

Owner

Opgelost in 9387d417 (PR #675), op main sinds 3d32fe4d.

docs/PRIVACY.md heeft een subsectie Who is controller, and who is not onder Your rights and this tool, met de drie regels uit je voorstel plus twee die er tijdens de juridische toets bij kwamen.

Wat er anders is dan je voorstel. Jouw eerste zin was "the data in your deck belongs to other people and you are the controller for it". Dat is te plat voor precies de gebruiker waar dit gereedschap voor wordt aangeprezen: wie in opdracht test, en waarbij de klant besloot dát er getest zou worden, kan diens verwerker zijn of gezamenlijk verantwoordelijke (art. 26). Dat verschil is niet academisch — een verwerker mag een sub-verwerker niet inschakelen zonder voorafgaande toestemming (art. 28(2)), en dat gaat rechtstreeks over de derde bullet, het AI-eindpunt en de S3-bucket. De tekst zegt nu welke van de drie het is uit de opdracht volgt, en wat dat concreet betekent. Ook art. 29 staat erbij: wie OciDeck als werknemer gebruikt, is niet zelf verantwoordelijke.

Tweede toevoeging: doorgifte. Je derde punt beloofde de lezer dat hij ziet "which contract you need", en noemde alleen art. 28. Voor een cloud-eindpunt of een bucket buiten de EER is dat de helft; hoofdstuk V is de andere, en die ontbrak in de hele PRIVACY.md.

En een correctie op mezelf. Mijn eerste versie schreef over de CVE-spiegel dat je de instelling kunt "repoint at your own mirror or at nothing at all". Dat is aantoonbaar onjuist, twee keer: het veld leegmaken zet de spiegel terug op cveapi.librekat.nl (cve_picker.dart:73-75), en ENISA en MITRE staan ingebakken achter je eigen spiegel (cve_search_service.dart:227-234). Beide beperkingen staan er nu bij, samen met wat wél waar is: met de lokale CVE-database wordt de online keten helemaal niet gebruikt, ook niet als de lokale zoekactie niets vindt.

Wat er níét in zit: wat cveapi.librekat.nl vastlegt en hoe lang. De tekst zegt dat dat niet gepubliceerd is en dat je tot die tijd niets over de bewaartermijn moet aannemen — een termijn verzinnen die nog niet vaststaat zou een belofte zijn in plaats van een beschrijving. Dat blijft #579.

Opgelost in `9387d417` (PR #675), op main sinds `3d32fe4d`. `docs/PRIVACY.md` heeft een subsectie *Who is controller, and who is not* onder *Your rights and this tool*, met de drie regels uit je voorstel plus twee die er tijdens de juridische toets bij kwamen. **Wat er anders is dan je voorstel.** Jouw eerste zin was "the data in your deck belongs to other people and you are the controller for it". Dat is te plat voor precies de gebruiker waar dit gereedschap voor wordt aangeprezen: wie in opdracht test, en waarbij de klant besloot dát er getest zou worden, kan diens **verwerker** zijn of gezamenlijk verantwoordelijke (art. 26). Dat verschil is niet academisch — een verwerker mag een sub-verwerker niet inschakelen zonder voorafgaande toestemming (art. 28(2)), en dat gaat rechtstreeks over de derde bullet, het AI-eindpunt en de S3-bucket. De tekst zegt nu welke van de drie het is uit de opdracht volgt, en wat dat concreet betekent. Ook art. 29 staat erbij: wie OciDeck als werknemer gebruikt, is niet zelf verantwoordelijke. Tweede toevoeging: doorgifte. Je derde punt beloofde de lezer dat hij ziet "which contract you need", en noemde alleen art. 28. Voor een cloud-eindpunt of een bucket buiten de EER is dat de helft; hoofdstuk V is de andere, en die ontbrak in de hele `PRIVACY.md`. **En een correctie op mezelf.** Mijn eerste versie schreef over de CVE-spiegel dat je de instelling kunt "repoint at your own mirror or at nothing at all". Dat is aantoonbaar onjuist, twee keer: het veld leegmaken zet de spiegel terug op `cveapi.librekat.nl` (`cve_picker.dart:73-75`), en ENISA en MITRE staan ingebakken achter je eigen spiegel (`cve_search_service.dart:227-234`). Beide beperkingen staan er nu bij, samen met wat wél waar is: met de lokale CVE-database wordt de online keten helemaal niet gebruikt, ook niet als de lokale zoekactie niets vindt. **Wat er níét in zit:** wat `cveapi.librekat.nl` vastlegt en hoe lang. De tekst zegt dat dat niet gepubliceerd is en dat je tot die tijd niets over de bewaartermijn moet aannemen — een termijn verzinnen die nog niet vaststaat zou een belofte zijn in plaats van een beschrijving. Dat blijft #579.

brenno closed this issue

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