[Bug] The privacy scanner flags OciDeck own cache path as a possible personal data leak #608

New issue

Closed

opened 2026-07-22 16:19:52 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 16:19:52 +00:00

Owner

Found in the pre-publication first-run review.

Reproduce:

New presentation.
Add a "Large image" slide.
Choose "From computer…" and pick any image.
Click "Quality".

What you see: Slide 3 · Privacy · Image — Possible personal data — user path containing a name (/…r). Consider redacting it with [[double square brackets]]. The path it found is /Users/<name>/Library/Caches/com.dewinter.ocideck/ocideck_staging/deck_XXXX/images/… — created by OciDeck itself. The only action offered is "Never report this rule again", a global switch. The finding disappears only after saving, when the path becomes relative.

Why this matters now: this is the very first privacy finding a new user ever sees, and it is a false positive about a path they did not type. The advice is impossible to follow — you cannot wrap an image path in [[ ]]. The masked value (/…r) is too short to clarify anything. The lesson the user takes away is that these findings are noise, which is the exact opposite of what the scanner needs to achieve — and this project documentation is explicit that false positives are the real enemy.

Proposal: exclude the app own staging and cache path from the user-path rule, and offer "dismiss this finding" alongside "never report this rule again".

Found in the pre-publication first-run review. **Reproduce:** 1. New presentation. 2. Add a "Large image" slide. 3. Choose "From computer…" and pick any image. 4. Click "Quality". **What you see:** `Slide 3 · Privacy · Image — Possible personal data — user path containing a name (/…r). Consider redacting it with [[double square brackets]].` The path it found is `/Users/<name>/Library/Caches/com.dewinter.ocideck/ocideck_staging/deck_XXXX/images/…` — created by OciDeck itself. The only action offered is "Never report this rule again", a global switch. The finding disappears only after saving, when the path becomes relative. **Why this matters now:** this is the very first privacy finding a new user ever sees, and it is a false positive about a path they did not type. The advice is impossible to follow — you cannot wrap an image path in `[[ ]]`. The masked value `(/…r)` is too short to clarify anything. The lesson the user takes away is that these findings are noise, which is the exact opposite of what the scanner needs to achieve — and this project documentation is explicit that false positives are the real enemy. **Proposal:** exclude the app own staging and cache path from the user-path rule, and offer "dismiss this finding" alongside "never report this rule again".

brenno added the

privacy

bug

labels

2026-07-22 16:19:52 +00:00

brenno referenced this issue from a commit

2026-07-22 16:49:08 +00:00

fix(privacy): meld het eigen werkmap-pad niet als mogelijk lek

brenno referenced this issue from a pull request that will close it,

2026-07-22 16:49:32 +00:00

fix(privacy): meld het eigen werkmap-pad niet als mogelijk lek (#608) #650

brenno closed this issue