[Docs] The EXIF-stripping claim covers the HTML export only, minus GIF and SVG #643

New issue

Closed

opened 2026-07-22 16:23:39 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 16:23:39 +00:00

Owner

Found in the pre-publication claim audit.

The claim — README.md:36: "…Images are re-encoded to screen size on the way in … and their EXIF — GPS, timestamp, camera serial — is stripped."

Evidence: the only code that clears EXIF is lib/services/html_image_embedder.dart:97 — scaled.exif = img.ExifData(); — reached exclusively from the HTML export (lib/services/export_service.dart:30, lib/services/marp_html_service.dart:168). Two gaps:

html_image_embedder.dart:32 — const _passThrough = {".svg": "image/svg+xml", ".gif": "image/gif"}; those enter the document byte-for-byte via :57-58, with no metadata removal.
There is no re-encode on import at all — lib/services/image_service.dart:466 does await src.copy(dest.file.path), so the image in the project images/ folder and inside the .ocideck package keeps its full EXIF. grep -n "copyResize\|encodeJpg" over lib/ returns only html_image_embedder.dart, image_alt_ai_service.dart and export_service.dart — no import path.

Why this matters: "on the way in" is grammatically about the HTML document, but sits in a bullet that also talks about "a deck of photos", so the natural reading is "OciDeck strips EXIF from my images". Anyone who hands over an .ocideck package or the images/ folder on that reading ships GPS coordinates. Severity is lower only because the strongest surface — the export a client receives — genuinely is clean.

Proposal: "…and in the HTML export each image is re-encoded, which drops its EXIF (GPS, timestamp, camera serial); GIF and SVG travel unchanged, and the images inside your own project folder and .ocideck package keep their original metadata — the source is never rewritten." That last clause is consistent with the project own source-side rule, so it reads as a design choice rather than an omission.

Found in the pre-publication claim audit. **The claim** — `README.md:36`: "…**Images are re-encoded to screen size on the way in** … and **their EXIF — GPS, timestamp, camera serial — is stripped**." **Evidence:** the only code that clears EXIF is `lib/services/html_image_embedder.dart:97` — `scaled.exif = img.ExifData();` — reached exclusively from the HTML export (`lib/services/export_service.dart:30`, `lib/services/marp_html_service.dart:168`). Two gaps: 1. `html_image_embedder.dart:32` — `const _passThrough = {".svg": "image/svg+xml", ".gif": "image/gif"}`; those enter the document byte-for-byte via `:57-58`, with no metadata removal. 2. There is no re-encode on import at all — `lib/services/image_service.dart:466` does `await src.copy(dest.file.path)`, so the image in the project `images/` folder and inside the `.ocideck` package keeps its full EXIF. `grep -n "copyResize\|encodeJpg"` over `lib/` returns only `html_image_embedder.dart`, `image_alt_ai_service.dart` and `export_service.dart` — no import path. **Why this matters:** "on the way in" is grammatically about the HTML document, but sits in a bullet that also talks about "a deck of photos", so the natural reading is "OciDeck strips EXIF from my images". Anyone who hands over an `.ocideck` package or the `images/` folder on that reading ships GPS coordinates. Severity is lower only because the strongest surface — the export a client receives — genuinely is clean. **Proposal:** "…and in the HTML export each image is re-encoded, which drops its EXIF (GPS, timestamp, camera serial); GIF and SVG travel unchanged, and the images inside your own project folder and `.ocideck` package keep their original metadata — the source is never rewritten." That last clause is consistent with the project own source-side rule, so it reads as a design choice rather than an omission.

brenno added the

privacy

docs

labels

2026-07-22 16:23:39 +00:00

brenno referenced this issue from a commit

2026-07-22 17:01:56 +00:00

docs(privacy): breng vier beloftes terug naar wat de code doet

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

2026-07-22 17:02:16 +00:00

docs(privacy): breng vier beloftes terug naar wat de code doet (#603, #628, #643, #644) #653

brenno closed this issue