fix(privacy): redactie liet de afbeelding gewoon staan #372
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
release-blocker
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!372
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/image-redaction"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Twee dingen: de gemelde bug, en de CI/module-vraag.
De bug
De beeldcontrole meldt keurig een herkenbaar gezicht, je zet de slide op
redact— en de foto blijft staan. Detectie zonder consequentie is erger dan geen detectie, want de auteur denkt dat het geregeld is.De oorzaak is architectonisch: de projectie is synchroon en redigeert tekstvelden, terwijl de beeldbevindingen uit een asynchrone provider komen en als kwaliteitsmelding eindigen. De projectie zag ze nooit.
Op een geredigeerde slide verdwijnt nu de héle mediaverwijzing — afbeelding, tweede afbeelding, video en audio. De bestaande placeholder toont een zichtbaar vak, zodat de ontvanger ziet dát er iets weg is. De bron blijft ongemoeid.
Waarom niet alleen het gezicht zwart maken. Dat zou aantrekkelijker lijken en is precies de val. De detector vindt gezichten en mist er aantoonbaar; hij leest geen HEIC, ziet geen tekst in beeld — een gefotografeerd formulier met een BSN erop dus niet — en de gebruiker mag hem uitzetten. Het resultaat zou een afbeelding zijn die eruitziet alsof ze is afgehandeld, met een gemist gezicht er nog op. Dezelfde fout als het zwarte blok op "diagnose" dat niets verborg. De afweging staat al in
statementSpan: te ruim redigeren is hinderlijk, te krap redigeren is een lek.Een tweede lek van dezelfde soort, onderweg gevonden
struct.user_pathdetecteert een gebruikersnaam in een mediapad. Het ontwerp meldde die wel maar redigeerde hem niet, omdat een pad met blokjes erin een kapotte verwijzing oplevert. Die redenering klopt — maar het gevolg was dat op eenredact-slide/Users/<voornaam.achternaam>/…letterlijk in de geëxporteerde markdown belandde. Gedetecteerd, gemeld, en vervolgens meegeleverd. Gemeten, niet vermoed.De test die dat oude gedrag vastlegde is omgedraaid met de reden erbij, en er staat een tweede test naast die bewaakt dat zonder redactie het pad wél ongemoeid blijft.
CI: Linux en Windows erbij
De Linux-gate draait al de volledige suite, dus daar hoefde alleen de build ervoor plus de apt-pakketten. Windows krijgt hetzelfde patroon als macOS met een ander pad (CMake in plaats van CocoaPods). Beide falen hard als de bibliotheek er niet staat.
Module-selectie: uitgezocht, niet aangezet
En hier moet ik een correctie maken op wat ik zelf in §13.8 had opgeschreven. Ik gaf
include_modulesals recept. Dat doet niets. Uitgen_cmake_vars.dart:Alleen
exclude_moduleszet een module uit;include_modulesbeschermt er één tégen uitsluiting. Wie mijn oude tekst volgde kreeg een build die er geconfigureerd uitzag en niets uitsloot. De juiste vorm staat er nu, met de acht modules die eruit mogen — afgeleid uitdefaultModuleSettings, niet uit een blogpost.Bewust nog niet aangezet. Ik kon het niet meten: geen Linux- of Windows-machine. En een uitgesloten module houdt zijn Dart-API maar gooit "symbol not found" bij aanroep — blind aanzetten zou precies de stille runtimefout zetten die hier al twee keer is voorgekomen. Het experiment staat in vier stappen beschreven, inclusief de verificatie die je niet mag overslaan: bouwen is geen bewijs.
Ook vastgelegd: macOS en iOS krijgen een voorgebouwde CocoaPod en kunnen sowieso niet snoeien. De 27 MB daar blijft.
make checkgroen.🤖 Generated with Claude Code