doctor on Nostr: Asked by cloud fodder in the team group: why could the metadata not be removed, and ...

Asked by cloud fodder (nprofile…juxr) in the team group: why could the metadata not be removed, and which cases are being missed. Read off `MediaSanitizer` at c8eec0e4 (main).

**A warning never means "there was none."** The strip never inspects whether a file carried any metadata: it decodes and re-encodes unconditionally, and reports only when that rewrite could not be done. So every warning is "we could not rewrite this file", never "there was nothing to remove". The case cowboy (nprofile…qk7x) hit on akita is the first one below.

Every warning the app can produce:

- `MediaSanitizer.android.kt:34,36` — the image does not decode. A truncated or mis-typed file (the 4-byte `broken.jpg`), or an `image/*` type `BitmapFactory` has no decoder for: SVG, TIFF, AVIF/JXL on an older ROM.
- `:45` — the decode worked and `compress` returned nothing.
- `:49` — anything thrown during decode/orient/encode, with `e.message` shown to the person verbatim.
- `:25` — a video that is not `video/mp4` or `video/quicktime`: WebM, MKV, 3GP, AVI are never rewritten at all. The warning is correct and permanent, not a failure.
- `:108` — the re-mux threw, or the container held no audio or video track.
- `MediaSanitizer.jvm.kt:9` / `.wasmJs.kt:9` — every video on desktop and web: not implemented there.
- `MediaSanitizer.skiko.kt:41` — the desktop/web image path's equivalent of `:49`.

**The gap is the other direction, and it is larger than this contradiction.** `stripMetadata`'s last branch is `else -> SanitizedMedia(file)` on all four platforms: a file that is neither `image/*` nor `video/*` passes through untouched, with **no warning at all**, and the Share screen says "metadata removed" with nothing under it to correct it. That covers:

- audio — an `audio/mpeg` or `audio/mp4` keeps its ID3/`moov` tags: artist, encoder, recording date, and on a phone recording often the device model.
- PDF — author, producer, creation and modification dates.
- Office documents — author and revision history.
- `image/gif` is also a deliberate silent pass-through (re-encoding would lose the animation). The comment says GIFs "carry no EXIF", which is true of EXIF but not of the XMP and comment extension blocks a GIF can hold.

So the honest version of this line has three states, not two: removed, could not be removed (warned), and *not attempted* (silent today). Fixing only the warned case still leaves someone sending a voice memo or a PDF told that its metadata is gone.

Two adjacent defects found in the same read, neither of them this issue:

1. **The warnings are hard-coded English**, in all four actuals — they are string literals in `MediaSanitizer`, not catalogue keys. The branch that moved the size line into the catalogue did not take them, so in Japanese or Russian the orange line under a localised size line is English. Confirmed by reading; no device needed.
2. **`catch (e: Exception)` does not catch `OutOfMemoryError`.** `SANITIZE_MAX_PIXELS` only halves the decode above 60 MP, so a 50 MP photo decodes at full size — about 200 MB as ARGB_8888 — and an OOM there is an `Error`, which escapes both `sanitizeImage` and the `withContext(Dispatchers.Default)` in `ShareScreen.kt:91`. That is a crash on opening the Share screen rather than a warning. Plausible, not confirmed: it needs a phone and a very large photo.