attachments: strip EXIF metadata from image attachments
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
Research direction
Start by locating IncidentFile's add path and tracing how image bytes are stored and passed to sync and PDF generation. Check existing image-processing dependencies and tests; the issue gives no specific test file. Done means metadata is stripped on ingest across supported image formats while orientation is preserved, and merged PDF metadata remains out of scope unless inexpensive.
Written by the indexing model from the issue text.
Description
What
Lagebuch does not strip EXIF metadata from attached images. A repo-wide search for exif over src/ returns nothing; image bytes go into the .files folder verbatim and into the PDF report verbatim.
Why it matters
A photo taken with a Diensthandy at the Einsatzstelle typically carries GPS coordinates, the exact capture timestamp, and the device model. All of that travels with the attachment: into the incident's .files folder, over the sync connection to every joined device, and into the exported PDF that goes to the Akte and the Kreisbrandinspektion.
The coordinates are usually the address of a private property, and often the address of the person whose name is already in the CO-Messprotokoll. Nothing about the app's UI suggests a photo carries anything beyond what is visible in it.
docs/datenschutz-und-sicherheit.md (#380) names this as a known limit, which is the honest short-term answer, but stripping is the right one.
Shape
Strip on ingest, in IncidentFile's add path, so it applies uniformly to the local store, the sync payload and the PDF — rather than at export, which would leave the stored copy untouched.
Decide deliberately what to keep: orientation must survive or photos display rotated. Everything else (GPS, timestamps, device, serial numbers, thumbnails — which can themselves contain a pre-edit image) can go.
PNG/WebP/GIF carry metadata chunks too and should be handled in the same pass. Merged PDF attachments have their own metadata; out of scope here unless it is cheap.
- Dominant language
- C#
- Stars
- 1
- Forks
- 3
- Avg merge
- 4h 34m
- Merged PRs (30d)
- 182
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeForFire/lagebuch
-
bug ux
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CodeForFire/lagebuch#714 ·
Maintainers usually reply within 1 day
-
bug ux
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
CodeForFire/lagebuch#713 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
CodeForFire/lagebuch#405 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
CodeForFire/lagebuch#349 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
CodeForFire/lagebuch#348 ·
Maintainers usually reply within 1 day
All issues in CodeForFire/lagebuch
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug priority: P2
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
IridiumIO/CompactGUI#699 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day