Prove Your Mobile Upload Removed EXIF GPS Before the Retry Queue Keeps a Copy
A user selects a photo containing GPS coordinates, capture time, and orientation. The preview looks clean, but the background retry queue still holds the original file and uploads it after restart. Build privac
A user selects a photo containing GPS coordinates, capture time, and orientation. The preview looks clean, but the background retry queue still holds the original file and uploads it after restart.
Build privacy fixtures
Create synthetic JPEG and HEIC samples with known metadataβnever personal photos. Record expected orientation and a fake GPS location such as 0.0, 0.0 plus an unmistakable fixture marker.
select original -> normalize orientation -> strip metadata
-> write sanitized temp file -> enqueue sanitized path -> upload
| Path | Pass condition |
|---|---|
| foreground upload | intercepted bytes contain no GPS/time |
| background retry | queue references sanitized file |
| app restart | original path is not restored |
| thumbnail | no metadata copied back |
| upload failure | both files follow declared cleanup policy |
Intercept the request in a test server and inspect the uploaded bytes, not only the UI preview. Compare pixel orientation separately from metadata removal; stripping orientation without rotating pixels can produce a sideways image.
Record device, OS, framework, image type, permission state, and app build. Verify temporary files are excluded from cloud backup and deleted after success or expiry.
This protocol covers selected JPEG/HEIC fixtures, not every vendor codec or edited media format. Platform image APIs may change metadata behavior across OS versions. Which artifact is riskier in your app: the upload body, retry queue, thumbnail cache, or backup?
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.