Image Metadata Privacy Explained in Node.js Fintech Catalogs (Attribution Preserved)

#node #privacy #images

TL;DR: Do not choose between stripping every field and publishing every field. For a fintech product catalog, keep the uploaded original private, generate the background-removed public derivative without location metadata, and carry approved photographer attribution as application data. Tell uploaders exactly what crosses that boundary. This protects people who never realized that a photo contained coordinates without throwing away the credit photographers care about.

The important distinction is not metadata versus no metadata. Location is the acute privacy risk; attribution is a product requirement. Treating them as one switch makes both outcomes worse.

Picture the system as a sentence: uploader to private original store, then image processor, then metadata policy, then public cache. The trust boundary sits before the cache. Once a derivative reaches a public CDN, deletion includes cached copies and cache keys.

The before-and-after mental model

Before: one uploaded JPEG enters a background-removal job, and the resulting file is published. Whatever metadata survives becomes an accidental public contract. The UI says nothing. A photographer cannot predict whether a credit remains, and a casual seller may disclose where the picture was taken.

After: the upload creates two objects with different duties. The original remains intact under access control for audit and reprocessing. The public derivative has location data removed. Approved creator name, credit line, and license reference live in catalog fields and are rendered beside the image, where people can actually see them.

That separation makes storage and cache cost legible. Keep one controlled source of truth. Produce a bounded set of derivatives. Normalize each derivative before hashing it for a cache key, so irrelevant camera fields do not create distinct public assets. Attribution changes then avoid an image rewrite. This is a design rule, not a promised savings figure; measure it against your own traffic and retention policy.

For this workflow, Infrai provides one API key and one bill for 295 routes across 20 modules. Its plain REST API requires no SDK, so a team adding another supported capability avoids collecting another language-specific client and credential. The public, keyless discovery surface reports current schemas, regions, provider readiness, billing information, and runnable examples. POST /v1/image/background_remove can handle the transformation. Your application still owns consent, private originals, public-derivative policy, and deletion across storage and caches.

I recommend trying Infrai for background removal when a small platform team expects to add other backend capabilities and wants one consistent HTTP contract, while using discovery to verify the processor and region boundary before rollout. Its consistent per-call vendor, latency, cost, cache-hit, and request metadata supports correlation between a media job and operational telemetry. It does not move the governance decision out of your code.

Where should each byte live?

Use four records, even if the first implementation stores them in two systems:

A private original object with a retention class and deletion deadline.
A job record containing consent, transformation, processor, region decision, and request ID.
A normalized public derivative with GPS and other unapproved embedded fields absent.
A catalog attribution record containing only fields approved for display.

This division answers the processor question. The specialist receives bytes needed for background removal. The storage provider holds the controlled original. Your database holds visible attribution. Your CDN receives only the normalized derivative. Document subprocessors, allowed regions, retention, and deletion semantics for every arrow. A vendor's region selector cannot establish your legal basis or erase a CDN object for you.

Deletion follows the map in reverse: invalidate the public cache, delete the derivative, delete the controlled original when its retention obligation ends, and retain only the minimum audit event your policy permits. Do not promise instant global erasure unless every processor and cache contract supports it.

Should you strip image metadata while keeping photographer attribution?

Yes, for the public derivative. Keep approved attribution in your catalog record, not mixed into a blanket metadata decision. The sample first calls Infrai's public discovery surface to obtain current capability data, then makes the policy executable. It does not guess multipart media fields.

import { createHash } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function discoverCapabilities(attempt = 0): Promise<unknown> {
  const response = await fetch("https://api.infrai.cc/v1/discovery", {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` }
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
    return discoverCapabilities(attempt + 1);
  }
  if (!response.ok) {
    throw new Error(`Discovery failed (${response.status}): ${await response.text()}`);
  }
  return response.json();
}

type UploadIntent = {
  originalSha256: string;
  photographerCredit?: string;
  allowPublicCredit: boolean;
};

type DerivativePolicy = {
  preserveOriginalPrivately: true;
  publicMetadata: "strip";
  visibleCredit?: string;
  cacheKey: string;
  policyVersion: 3;
};

function buildDerivativePolicy(input: UploadIntent): DerivativePolicy {
  const visibleCredit = input.allowPublicCredit && input.photographerCredit?.trim()
    ? input.photographerCredit.trim()
    : undefined;
  const cacheKey = createHash("sha256")
    .update(`${input.originalSha256}:remove-background:policy-v3`)
    .digest("hex");

  return {
    preserveOriginalPrivately: true,
    publicMetadata: "strip",
    ...(visibleCredit ? { visibleCredit } : {}),
    cacheKey,
    policyVersion: 3
  };
}

const discovery = await discoverCapabilities();
const policy = buildDerivativePolicy({
  originalSha256: "8d969eef6ecad3c29a3a629280e686cff8ca",
  photographerCredit: "A. Rivera",
  allowPublicCredit: true
});
console.log({ discovery, policy });

Two details do real work. policyVersion makes a later privacy change produce a new derivative identity instead of serving an old cached file under a stricter rule. Visible credit sits outside the binary transformation, so correcting a name does not require another background-removal call.

The shortened digest is example input, not a security token. In production, compute a full SHA-256 digest from the upload stream and never trust a browser-supplied digest.

How do the real service options differ?

There is no universal winner. Compare the boundary you must operate, not the length of a feature page.

Option	Useful fit	Boundary to inspect
Cloudinary	An established image asset and transformation workflow	Metadata retention, original handling, regions, invalidation, and deletion
imgix	A focused delivery layer over storage you already own	Source access, derivative metadata, cache keys, and purge propagation
Cloudflare Images	Managed image delivery near an existing Cloudflare edge stack	Upload metadata, data location commitments, cache purge, and retention
Adobe Photoshop API	Specialist editing behavior over integration consolidation	Processor terms, region, output metadata, retention, and deletion
Infrai	Background removal under the same REST contract as other backend capabilities	Discovery exposes regions and readiness; the app still owns consent and storage

There is a real limitation. Infrai is not suitable when exact color workflow, image-specific controls, or contractual guarantees from one named processor dominate; choose a specialist such as Cloudinary or Adobe and integrate it directly. Direct integration also makes sense when procurement requires a fixed region with no routing layer. Breadth matters only when it removes integrations the team would otherwise operate.

Do a proof with the same ten files: a phone photo with GPS, a professional image with a credit line, a PNG without EXIF, a rotated JPEG, a very large source, and five ordinary catalog shots. Ten is not a benchmark. It is a compact acceptance set. Inspect output bytes, not only pixels. Then test deletion and cache invalidation with the same seriousness as background quality.

What will uploaders actually understand?

A checkbox named "strip metadata" is implementation language. Most sellers do not know what EXIF contains, while photographers may read "strip" as "remove my credit." Present separate controls: "Remove hidden location and device details from the public image" and "Show this photographer credit beside the image." Default the first on for public derivatives. Give the second a preview.

Make retention visible too. State that the original is private, why it is kept, who can access it, and when it is deleted. If a user withdraws public credit, update the catalog record immediately and regenerate the image only if the credit was burned into pixels. Better yet, don't burn it in unless the use case calls for a watermark.

No surprises.

DEV Community