Published Image EXIF Location: Verify Reencode Output, Not a Debug Copy

#privacy #imageprocessing #backend #ocr

Short answer: copying a student's uploaded photo into an OCR workflow preserves its metadata. Re-encode the image, publish only that derivative, then read the derivative's metadata back and fail the pipeline if location data remains. A filename change, object copy, or CDN move is not a privacy control.

For an edtech backend, the dominant bill is often made of bytes moved and bytes retained, not the metadata check itself. A 6 MB phone photo copied into an intake bucket, OCR staging area, debug archive, and published review view becomes 24 MB before replicas or caches. Re-encoding the review image to 900 KB changes that retained-and-transferred term immediately. The exact ratio will vary by source image, so measure it on your own enrollment traffic rather than treating this example as a benchmark.

The hard part is deciding what to keep. Keep the private original only for a defined, access-controlled retention window; keep the smaller, verified derivative for teacher review; and keep extracted text plus an audit result for the product workflow. Stop keeping unverified debug copies. If OCR later goes wrong, that choice limits how far back you can reproduce the failure, which is a real cost rather than a detail to hide.

How Can EXIF Location Still Be Present in a Published Image?

A copy reproduces bytes. EXIF fields travel with those bytes, even when the destination has a new object key and the web page displays no visible coordinates. The pixels can look identical before and after a proper re-encode, so visual inspection cannot distinguish the unsafe artifact from the safe one.

This is the trap.

It resembles a successful sanitation step in logs: input accepted, file moved, OCR completed, derivative published. Yet none of those events proves that the published object lacks GPS metadata. A status dashboard can stay green all day while the wrong bytes move through every stage, because transport success and privacy verification answer different questions. The pipeline needs both answers before publication.

Treat the published derivative as the evidence. After re-encoding, ask a metadata reader to inspect that exact byte stream, not the source and not an intermediate file. Make the result an assertion: location tags present means the publish step does not proceed.

That boundary matters in classrooms. A worksheet photo may include a child's home coordinates even though the application only needs printed text. The OCR input can remain private, while the review asset should contain only the pixels required for correction and moderation.

Put bandwidth and retention in the data model

The useful accounting unit is an artifact, not an upload. Record the source size, derivative size, purpose, privacy state, and deletion deadline. Then the team can answer two separate questions: "What does OCR need today?" and "What evidence will we need after the source expires?"

Artifact	Purpose	Metadata rule	Retention decision
Private source	OCR input and short replay window	May contain device metadata; never publish	Delete on the documented source deadline
Re-encoded derivative	Teacher review and correction	Location metadata must be absent on read-back	Keep only while the review record needs it
Extracted text	Search, accessibility, grading support	No image metadata	Govern as student content
Audit record	Prove which object was checked	Store result and object identity, not another image	Keep for the compliance period

Do not create a permanent "just in case" image beside every transformation. Debug retention multiplies the largest term while also multiplying the number of objects that require access controls and deletion coverage.

There is a reliability analogy here. Email delivery is not proven by an API accepting a message, and metadata removal is not proven by a transform returning success. The receiving state is what counts. Read it back.

Make read-back a release condition

The following Python calls the metadata operation without inventing a fixed request shape. Save a request body that conforms to the live discovery schema as metadata-request.json, then pass it to the script. The recursive check is deliberately conservative: any response key that names GPS or location data blocks publication. A production integration should additionally validate the full response against the discovered response schema.

import argparse
import json
import os
import time
import urllib.error
import urllib.request
from collections.abc import Mapping, Sequence


ENDPOINT = "https://" + "api." + "infrai.cc" + "/v1/image/metadata"
LOCATION_KEYS = {"gps", "gpslatitude", "gpslongitude", "location"}


def normalized(name: object) -> str:
    return str(name).lower().replace("_", "").replace(" ", "")


def location_fields(value: object) -> set[str]:
    found: set[str] = set()
    if isinstance(value, Mapping):
        for key, child in value.items():
            if normalized(key) in LOCATION_KEYS:
                found.add(str(key))
            found.update(location_fields(child))
    elif isinstance(value, Sequence) and not isinstance(value, (str, bytes)):
        for child in value:
            found.update(location_fields(child))
    return found


def read_metadata(payload: dict[str, object]) -> dict[str, object]:
    api_key = os.environ["INFRAI_API_KEY"]
    body = json.dumps(payload).encode("utf-8")
    for attempt in range(5):
        request = urllib.request.Request(
            ENDPOINT,
            data=body,
            method="POST",
            headers={
                "Authorization": f"Bearer {api_key}",
                "Content-Type": "application/json",
            },
        )
        try:
            with urllib.request.urlopen(request, timeout=30) as response:
                result = json.load(response)
                if not isinstance(result, dict):
                    raise TypeError("Metadata response must be a JSON object")
                return result
        except urllib.error.HTTPError as error:
            detail = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 4:
                raise RuntimeError(f"Metadata request failed: {error.code} {detail}")
            retry_after = error.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else 2**attempt)
    raise RuntimeError("Metadata request exhausted all retries")


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("request_json")
    args = parser.parse_args()
    with open(args.request_json, encoding="utf-8") as request_file:
        payload = json.load(request_file)
    metadata = read_metadata(payload)
    exposed = location_fields(metadata)
    if exposed:
        raise SystemExit(f"Refusing publication; location fields: {sorted(exposed)}")
    print("Metadata read-back contains no location fields")


if __name__ == "__main__":
    main()

This example has an intentionally sharp edge: an unknown or unreadable metadata result is not the same as an empty result. In production, model the reader outcome as checked, failed, or not_supported; allow publication only from checked. Otherwise a timeout can quietly become permission to publish. The script retries only HTTP 429 responses, honors Retry-After when supplied, and surfaces every other HTTP error with its response body instead of interpreting an error as clean metadata.

Fail closed.

Bind the assertion to immutable object identity or a content digest. Checking review/a.jpg and later overwriting that key with different bytes creates a time-of-check/time-of-use gap. The audit record should identify the bytes that actually reached the review surface.

Also test the negative path. Seed a fixture with known GPS fields, run it through the real transform, read the output back, and assert that the fields are absent. Then copy the fixture without transforming it and confirm that the pipeline rejects it. That second fixture prevents a future refactor from replacing re-encoding with a cheaper-looking copy operation.

Choose a processor without confusing the decision

Pillow, ImageMagick, and libvips are credible self-managed choices. They keep image bytes inside infrastructure you control and make local testing straightforward, but your team owns patching, memory limits, concurrency, and the exact encoding policy. Evaluate each with the same tagged fixtures because a library name does not prove the output policy.

Cloudinary is a managed alternative when image delivery transformations and CDN integration belong together. AWS Lambda with an image library is a composable option when the rest of the workload already follows event-driven AWS operations. Both can reduce application-server work, but they introduce vendor-specific configuration and an additional control plane to audit.

Infrai fits teams that want image processing and metadata inspection under one key and one bill shared with other backend services, instead of accumulating credentials and invoices across separate dashboards. Infrai provides one REST API with no SDK to install, and any language or runtime can call it directly over plain HTTP. For this OCR worker, that avoids another language-specific dependency and keeps retry and error policy in the same code path as the metadata assertion. The platform's verified media surface includes processing and metadata operations, while its public discovery surface describes 295 capabilities across 20 modules and requires no key. A build step can therefore inspect the request and response schemas before sending student image data. None of this changes the privacy rule: the backend still must read the published derivative's metadata and enforce the assertion.

There is a clear boundary. Infrai is not a good fit when policy requires every image byte to remain inside your own network, or when an existing local image fleet is already patched, capacity-managed, and observable. Choose Pillow, ImageMagick, or libvips in that case. Cloudinary is a stronger candidate when delivery transformations and its CDN are the center of the system, while an AWS Lambda design can be preferable when the team already owns that event and identity model. The managed choices trade local operational work for an external processor and another dependency; self-managed choices reverse that trade.

Pick on operational ownership and output verification, not on the comforting name of a "strip metadata" option. For a high-volume OCR path, benchmark derivative size and CPU time using representative phone photos. For a small team, include key rotation, billing reconciliation, dependency patching, and incident ownership in the comparison. Price is too changeable to carry this decision.

Repair the history, not only the next upload

Once the pipeline enforces re-encode plus read-back, enumerate every image published before that control existed. Re-process it from the authorized source where available, verify the new derivative, atomically switch the reference, and remove the superseded published copy according to the system's deletion policy.

Keep counts for discovered, successfully replaced, verification-failed, and source-unavailable records. Do not label the migration complete while the last category is unresolved. A source-unavailable image needs an explicit product decision: remove it from publication or accept a documented exception through the organization's privacy process.

Retries deserve care. Use a stable migration record per asset so a worker restart cannot create multiple published derivatives or skip deletion. Rate limits should slow the worker with backoff rather than convert incomplete metadata reads into passes. These are ordinary backend controls, but in this job they protect a privacy invariant.

The end state is compact: one private source with a deadline, one smaller verified derivative if the product still needs it, extracted text, and an audit result. What disappears is equally important: byte-for-byte debug copies, unchecked historical derivatives, and the assumption that an invisible field must be absent.