A policy and an architecture are different answers

Search for storage that keeps AI away from your photographs and you will find a great many pages saying some version of we do not use AI on your files. Almost all of them are describing a policy — a decision the provider has made and could unmake, in a paragraph they wrote and can rewrite.

A policy is worth something. It is not the same kind of fact as an architecture. If a provider holds files it can open, then the only thing standing between your photographs and a training run is that paragraph, plus whoever owns the company next year. If a provider holds files it was never given the keys to, the paragraph matters less, because the option is harder to take.

This page is about telling those two answers apart — including on this site. PhotoLog makes both kinds of statement below, and they are labelled.

What PhotoLog does, as conduct

PhotoLog does not run image recognition, content analysis, tagging, face detection or model training over customer media, and does not supply customer media to anyone else for those purposes.

That is a claim about conduct, and the evidence for it is negative and checkable: no machine-learning, image-recognition or content-analysis library appears in the dependency manifests of PhotoLog’s API, platform or web application. The only media-handling libraries declared anywhere in them are an image resizer and a video transcoder — code that changes a file’s dimensions or container, not code that reads a picture for meaning.

Negative evidence has a shape worth stating plainly: it shows that the capability is not installed, on the day it was checked, in the repositories this project can read. It is not a proof about every future release. It is, however, the sort of thing you can ask any provider for and check — which is more than a paragraph of policy offers.

What PhotoLog does, as mechanism

Your photos and videos are encrypted in your browser before they are uploaded, so PhotoLog’s servers only ever hold ciphertext. The encrypted bytes go from your device straight to object storage using a short-lived, single-use link, rather than passing through PhotoLog’s own application servers on the way. How encryption works sets out the key hierarchy in full.

This is deliberately phrased as a statement about where encryption happens, not as a statement about what PhotoLog is unable to do. Those are different claims, and the second one is not one this project is willing to make: encryption and decryption run inside PhotoLog’s own application, so an operator able to serve a modified copy of that application to one device would see whatever that copy sees. Today’s web application has no mechanism that would let your device prove it is running the genuine, unmodified version. That limit is real, it is stated in full on the encryption page, and no reading of this page should smooth it over.

What PhotoLog’s servers do hold

Contents are encrypted. The facts around them are not. PhotoLog’s servers see a file’s size and when it was uploaded, which studio and vault an item belongs to, who belongs to a studio, and when a share link is used. That is ordinary operational information of the kind any hosted service has about what it stores and serves.

It is worth naming because “your photos are encrypted” is a claim about the contents of files, and not a claim that a provider holds nothing at all about your account or your activity. Both things are true at once, and a page that only tells you the first has told you half of it.

Older galleries created before this system are locked with a shared passphrase rather than per-user encryption, and they are being replaced.

Four questions that separate a policy from an architecture

These work on any provider, including this one. What you are listening for is whether the answer describes a mechanism or restates an intention.

1. Where does encryption happen — on my device, or on your servers? “Encrypted in transit and at rest” is the answer that means the provider holds the keys. It is not a bad answer; it is a different answer, and it means the files can be opened server-side, whether or not anyone intends to. Ask where the encryption runs, not whether encryption exists.

2. If I open a support ticket about a specific photo, can your staff look at it? This is the practical version of the same question, and it is harder to deflect. A provider whose staff can open a file to help you is a provider whose staff can open a file. Both models are legitimate; only one of them is compatible with “no system of ours could analyse this.”

3. What does the licence clause in your terms actually grant? Every hosting service needs some licence from you to store and transmit your files — that part is unavoidable and not sinister. Read what it is limited to. A licence scoped to operating the service reads very differently from one that includes improving, developing or training the provider’s products. The word to search for in a terms page is “improve”.

4. What happens to the files when I close the account, and how would I know? Deletion policy is where a storage claim gets tested, because it is the one part a customer can observe. Ask what is deleted, on what timetable, and what remains — backups and logs usually outlive the account by some interval, and a provider willing to tell you that interval is telling you something real.

What this page does not claim

Not a claim about what PhotoLog is unable to do. See “as mechanism,” above: the honest statement is about where encryption happens. An unqualified claim about inability is one this project’s own non-claims register forbids, and it is forbidden for a reason that is written down rather than assumed.
Not a claim that PhotoLog’s design has been independently reviewed. No outside security firm has reviewed the encryption design or its implementation, no independent audit exists, and none is currently planned. What exists is internal review, differential testing against published test vectors, and internal adversarial review — none of which is a substitute for outside audit.
Not a claim about any other provider. The four questions above are questions, not findings. This page does not report what any named competitor does with customer media, because this project has not tested any of them, and a page that ranked other services on evidence it does not hold would be exactly the kind of writing this site is replacing.
Not a claim that encryption protects availability. It protects what is inside a file from being read. Keep your own copies of anything irreplaceable — see backing up your storage.
Not a claim about storage volume. PhotoLog’s plans are metered — see pricing for current limits.

How we verified this

Every statement above was checked against PhotoLog's own source and documentation on the date shown. Where the source did not settle a question, the page says so rather than filling the gap.

No machine-learning, image-recognition or content-analysis dependency appears in PhotoLog's API dependency manifest; the only media-handling libraries declared are an image resizer and a video transcoder (verified 2026-09-01)
No machine-learning, image-recognition or content-analysis dependency appears in PhotoLog's web application dependency manifest (verified 2026-09-01)
No machine-learning, image-recognition or content-analysis dependency appears in PhotoLog's platform dependency manifest; the only media-handling libraries declared are an image resizer and a video transcoder (verified 2026-09-01)
Photos and videos are encrypted in the browser before they are uploaded, so PhotoLog's servers only ever hold ciphertext — the approved wording for this claim, and the reason the unqualified form is not used (verified 2026-09-01)
What PhotoLog's servers store and can see per studio, vault and item, versus what they never hold (verified 2026-09-01)
Older galleries created before this system are locked with a shared passphrase rather than per-user encryption, and are being replaced (verified 2026-09-01)
No outside security firm has reviewed PhotoLog's encryption design or its implementation, no independent audit exists, and none is currently planned (verified 2026-09-01)

No-AI storage: what the claim means and how to check it