3.8 KiB
Privacy and security
Data handling
Files are read with browser file APIs and transferred to an in-page worker. There is no upload endpoint, account, telemetry, analytics, remote metadata lookup, or automatic persistence. Temporary object URLs exist only for the legacy image-element decode fallback and are revoked immediately after decode. Download object URLs are created and revoked by the shared helper. Refreshing or closing the page discards application state.
Service-worker support may fetch and cache the same-origin application shell; it does not cache imported files, metadata findings, reports, or generated images. Metadata URLs and XMP/XML markup are inert text and are never fetched or rendered as HTML.
What is inspected
Every file receives byte-signature inventory and SHA-256. Static JPEG, PNG, and WebP receive project-owned deep container parsing plus ExifReader. TIFF, HEIC/HEIF, AVIF, and JPEG XL receive best-effort ExifReader inspection only. GIF and document/archive formats receive inventory only. Exact per-format fields are listed in the README support table.
All parsers are bounded, but a “complete” scan means complete for implemented structures—not proof that no steganographic or novel carrier exists. Unknown private chunks and trailing bytes are surfaced. ExifReader failures and format limitations remain visible in coverage.
Re-encoded outputs
Only complete, static, dimension-bounded JPEG/PNG/WebP project scans are eligible. The application decodes pixels, normalizes display orientation, and uses Canvas to encode a new file of the detected type. It does not selectively strip GPS while copying everything else, because duplicated values can live in multiple namespaces and embedded previews. It copies no source metadata block.
The output is always scanned and hashed again. Sensitive or provenance findings, partial project coverage, or an oriented-dimension mismatch produce a failed gate. Secondary-parser limitations and provenance invalidation produce explicit warnings. JPEG and lossy WebP may change pixels; profiles, resolution metadata, thumbnails, comments, and application history may be lost. PNG is expected to preserve decoded pixels, subject to browser colour management.
C2PA/JUMBF carries authenticity/provenance claims. Re-encoding normally removes or invalidates those claims. The tool reports that effect rather than describing it as an ordinary privacy win.
What this cannot promise
No result promises anonymity or safe publication. The tool does not remove or detect visible faces/text/locations, steganography, invisible watermarks, camera-pattern or image fingerprints, reverse-image matches, sidecar files, filesystem metadata, clipboard/history records, application caches, backed-up originals, or cloud/recipient copies. Review the visible output, destination, report, and surrounding files yourself.
The detailed JSON report is sensitive by design: it can include original filenames, hashes, timestamps, metadata values, offsets, and parser notes. Share or retain it only intentionally. The separate safe-share report replaces file identity with sequential pseudonyms and omits those source identifiers and raw values. It retains formats, dimensions, coverage states, note counts, and finding-category totals so it is useful for review without claiming anonymity. Safe-share ZIPs likewise use generic sequential output names.
Selective-removal policy evidence follows the same pseudonymization boundary. It can show which finding categories a policy would remove, preserve, or send for review, but it never upgrades inspection coverage and never calls a format safe when no verified output exists. A requested “location-only” policy is therefore non-executable with the current all-metadata pixel re-encode; users receive evidence rather than a misleading partially preserved output.