Client Delivery·Guide
Asset delivery economics
“Secure delivery” is not one product. On one side of the boundary, the storage host can read your objects (standard cloud storage with TLS and provider encryption). On the other side, only the client’s key unlocks the files (zero-knowledge). Most photography platforms, including ArtInStack, live on the first side. What studios usually buy next is entitlement and brand: who gets into the portal, what you put in the download response, and whether you hand out a permanent CDN URL or a short-lived one.
What “secure” must specify
Four questions before you trust a delivery link
Who holds the key
Provider-managed encryption at rest is normal. Zero-knowledge means the host cannot decrypt. Do not score them as the same checkbox.
Public CDN vs gated download
A public object URL on a CDN hostname is world-readable if someone has the path. A portal download that issues a short-lived signed URL is a different product surface, not magic privacy on the same public object.
Who is entitled
Invite-plus-access-code, a shared password, or an anonymous transfer link create different leak surfaces.
Where the brand sits
A transfer page that looks like someone else’s product trains clients that the job is temporary and optional.
The boundary the hero draws
Left of the line: the storage provider (and usually the SaaS) can access plaintext objects. Files travel over TLS; at rest they use provider keys. Access control is the product story: who may enter the portal, which grant they hold, and what URL shape you return for a download.
Right of the line: zero-knowledge or end-to-end models where the service never holds a usable key. That class exists in niche file products. It is almost never what “client gallery software” means in photography marketing, even when the landing page says encrypted.
ArtInStack is honest about the left side. We do not claim zero-knowledge. If a job truly requires that the host cannot decrypt, you need a different product class, not a prettier gallery.
Why zip links still feel cheap
WeTransfer-style handoffs optimize for one-shot archive moves. They are fine when proofing is already finished and you only need bytes to leave the building. They fail as a delivery system: no entitlement model tied to a client, no studio queue, no quiet path back into print or a branded portal.
The economic waste is rematch labor and brand erosion. You already paid to shoot and edit. Paying again in email archaeology (“which folder?”) and in a third-party download page that looks nothing like the site they hired is how a finished job still feels unfinished.
Replace the zip ritual with a portal grant when the client still needs to decide, shortlist, or return later. Keep a transfer link for the rare case where the only remaining job is “here is the archive.”
What ArtInStack actually delivers
Display and marketing surfaces often use a public R2 custom domain: anyone who has the object path can fetch that URL. That is a deliberate CDN model for portfolios and site images, not a claim that every object is private.
Client Portal downloads are a different surface. The client must pass invitation auth and an entitlement check first. The API then returns a short-lived signed GET for the archival file (RAW when present, otherwise the raster master), instead of emailing a permanent CDN link as the only access path. Purchase downloads follow the same idea: token route, then a signed redirect.
So what is the point of signing if the same key can also exist on a public hostname? Signing does not make a public object secret. It is the gated handoff pattern: do not publish a permanent download URL in the portal response; expire the link you did hand out; keep the path ready if the bucket later goes private. Real exclusivity still comes from not exposing the public path, opaque key names, and (when you need it) a private bucket. Do not confuse that with zero-knowledge, and do not confuse a watermarked public preview with archival delivery.
| Model | Who can decrypt | Studio reality |
|---|---|---|
| Anonymous transfer link | Provider + anyone with the link | Fast archive dump; weak entitlement |
| Invitation portal + signed handoff | Provider + whoever can reach the object URL | ArtInStack: auth gate first; signed download response (public CDN may still serve the same key) |
| Zero-knowledge vault | Client key holders only | Rare in photo delivery; different product |
Where each option actually fits
Choose ArtInStack when delivery must sit on the same spine as proofing and the public site: branded portal, granted downloads, and a path back to print without rematching files.
Choose a zero-knowledge file product when the contract literally requires that the host cannot decrypt. Expect a second system beside your gallery.
Use a plain transfer link only for one-shot archives after decisions are closed. It is logistics, not a client room.
Deliver files without the zip ritual
Invite the client. Grant the download. Prefer a short-lived handoff over a permanent CDN link in email. Keep the masters on the same spine as the gallery.
Also in Guides: Client galleries that convert · Client experience architecture · The myth of unlimited storage