Is Face Recognition in Photo Galleries Safe for Guests?

Face search on clientgallery.io has two halves that happen at different times, on different machines. Almost every privacy question about this feature is really a question about which half you are asking about.

The practical consequence is worth stating in the plainest possible way. We do not have a copy of the guest's face. We never received one. There is no image of the guest on our server that came from the selfie step, because that step never sends an image anywhere.

The stored thing is a list of numbers per detected face, computed from the gallery's photos in the photographer's browser at upload time. It is attached to the photo, not to a person. Nobody types a name next to it. Nothing links it to an account, an email address or a phone. It exists so that a comparison can happen without shipping a face somewhere to be identified.

• It is gated by the gallery password on the server. If the photographer has set a password on the gallery, the descriptors are behind it in the same way the gallery page, the whole-gallery ZIP, the full-resolution ZIP and the comments are. Face search on a section link does not exist at all; it works on the parent gallery link only.
• It dies with the photo. Delete the photo and its descriptors go. Delete the gallery and all of them go. There is no separate face table that outlives the images.
• It is off unless the photographer chose it. Face search is off by default and switched on per gallery. A photographer who never touches the setting never generates the feature for a client.

One honest note on the password, because it matters more than the face feature itself. A gallery password gates the gallery page and the things listed above. It does not retroactively protect an individual proof image URL that somebody already has, because those URLs are public and do not expire. That is a property of the whole gallery, not of face search, and you should know it either way.

These are the limits. They are not edge cases and they are not coming later in this page as a footnote. If you are asking this question on behalf of a client, an organiser or a compliance department, this section is the one that decides your answer.

• There is no guest-facing delete control. A guest cannot open the gallery and self-serve a request to remove face data. There is no button for it. The photographer controls the gallery, and deleting a photo or the gallery is what removes the descriptors.
• There is no consent checkbox. Consent here is the guest reading the explanation on the screen, which appears before any selfie is given, and choosing to continue or not. We do not collect a recorded, auditable agreement, and we do not pretend that a tap is one.
• Switching face search off is not a purge. Turning the setting off for a gallery stops the feature working. It is not, by itself, a deletion of descriptors that were already computed for the photos in that gallery. If the goal is removal rather than switching off, the photo or the gallery has to go.

We would rather write those three sentences than let somebody discover them after promising a guest something we do not do.

Pic-Time's privacy policy is the only competitor page we could find that documents biometric handling in its own words. On several points it documents more than we operate, and the fair thing is to say so rather than to grade ourselves.

On what is stored, Pic-Time describes a 512-dimensional numerical feature vector, an abstract mathematical embedding used solely for clustering and search within the specific Gallery, and states that It is never used, or will be used, to verify a person's identity or to enable face recognition outside the context of the relevant Gallery. On defaults it says the feature is by default disabled, if enabled it is at Photographers explicit opt-in consent. It also describes obtaining a written or electronic release, states that on withdrawal Face Grouping will be disabled and associated biometric data will be deleted, and for selfie search that Once the Guest leaves the Gallery the Face Data is deleted.

Read that table honestly and it splits. Our architecture keeps the selfie on the guest's device, which is a meaningful advantage and not a wording choice. Their policy documents a consent release and an explicit withdrawal-deletion path that we do not have. If your requirement is a recorded consent and a documented deletion request, they publish that and we do not, and you should weigh that accordingly.

The feature is off until you turn it on, so the decision is genuinely yours, per gallery. Three habits cover almost every situation.

• Ask the person who owns the event. The couple, the organiser, the company running the conference. They know their guests and their own obligations better than you do.
• Tell guests it is there and what it does. One line in the delivery email is enough: there is a button to find your own photos with a selfie, the selfie stays on your phone, and you do not have to use it.
• Leave it off when you are unsure. The gallery works perfectly without it. A guest who cannot use face search scrolls, which is what they did before the feature existed. There is no cost to leaving it off and there is a real cost to switching it on for a group that would not have wanted it.

Corporate, medical, legal, minors, and anything involving people who did not choose to be at the event are the obvious cases for leaving it off. So is any gallery where you would not be comfortable explaining the feature out loud to the room.

Rules on biometric data differ by jurisdiction, and they differ in ways that change the answer rather than just the paperwork. What counts as biometric data, whether consent has to be recorded before processing, who is responsible for obtaining it, and what a deletion request must produce are not the same everywhere.

This page describes how our feature is built. It does not tell you whether using it is lawful for your shoot, in your region, for your client. A photographer working under a specific biometric statute should get advice from someone qualified in that jurisdiction rather than relying on any vendor page, ours included. A vendor has an interest in the answer being yes.

• Pic-Time privacy policy, quoted phrases on face data, the 512-dimensional feature vector, default state, written or electronic release, withdrawal deletion, and selfie-search deletion. https://www.pic-time.com/privacypolicy (fetched 8 September 2026)
• Pic-Time pricing, the Advanced plan price and Smart Search including selfie search. https://www.pic-time.com/pricing (fetched 8 September 2026)
• clientgallery.io behaviour described here was read in the product's own code on 8 September 2026: on-device selfie processing, in-browser comparison, descriptors computed at upload and attached to photos, server-side gating by the gallery password, deletion with the photo or gallery, the per-gallery off-by-default switch, and the plan price.