The face matching runson our servers.
An earlier version of this page told you the opposite. It said face processing happened in the guest’s browser and that raw face images never left the device. That described a pipeline we removed, and it was wrong about the product as it ships today. This page is the correction, written out in full — including the parts that are less flattering than the sentence they replace.
Windows desktop app and Android. macOS and iOS in development.
What we used to say, and what is actually true.
The old claim
- Withdrawn: Face detection and descriptor extraction happen in the browser
- Withdrawn: Raw face images never leave the device
- Withdrawn: We never store raw biometric data on our servers
- Withdrawn: Embeddings are anonymised and cannot be reversed
What ships
- True today: The selfie is uploaded and embedded on our servers
- True today: The selfie image itself is stored in our cloud storage
- True today: The embedding is held against a user account, so it is personal data
- True today: We make no irreversibility claim about the vector
The old sentence was the better sentence. It was also the wrong one — and a privacy page that misstates where processing happens is itself a compliance failure, not just bad copy.
The legacy on-device pipeline was a 128-dimension face-api.js model. It has been removed from the product. Nothing in Studioshare computes a face descriptor in a browser today.
Selfie to matched set
Six stages. Exactly one of them happens on the guest’s phone, and it is the part that takes the photo.
| 1. The browser | Captures a single JPEG and uploads it. That is the browser’s entire role — it runs no model, computes no descriptor and makes no matching decision. |
|---|---|
| 2. Our API | Receives the frame on an authenticated route and hands it to the face service. Requests without a verified Firebase ID token are rejected before anything is processed. |
| 3. The face service | A private Cloud Run service running the AuraFace ONNX pipeline. It returns a 512-dimension, L2-normalised embedding of the primary face. It is deployed with no unauthenticated access. |
| 4. The vector store | The embedding is written to Firestore as a vector on the guest’s own user record, alongside the model’s estimated age and sex. |
| 5. Gallery ingestion | Every photograph in the event is embedded the same way as it is ingested, into a per-event collection of face vectors. |
| 6. The match | A Firestore nearest-neighbour query over that event’s collection using cosine distance, narrowed first by the estimated age band and sex, capped at a distance cutoff we tune. |
What we store, and where it sits
Written out with the actual record paths, so that you or your client’s legal team can hold the page to the product rather than to an adjective.
| The selfie | Written to Firebase Storage under the guest’s own account path (usr/{uid}/pro). It is a photograph of a face on our servers, and we are not going to describe it as anything else. |
|---|---|
| The face embedding | A 512-number vector at usr/{uid}/v1/fi in Firestore, with the estimated age and sex used to narrow the search. Tied to an account id, so it is personal data — not anonymised data. |
| Gallery face vectors | One document per detected face at studios/{studio}/events/{event}/face, carrying the vector and the id of the photo it came from. |
| The photographs | Firebase Storage, under the studio and event they belong to. Delivered over HTTPS through Google’s storage hosts. |
| Photo grouping | Firebase Realtime Database holds which frames belong together, so a burst resolves to one card in a gallery rather than nine. |
Fixed, not selectable
Our Firestore database, the Realtime Database instance and the face service each run in a fixed Google Cloud region in Asia. There is no region picker in the product, and we do not offer a contractual data-residency commitment. If your client requires one in writing, tell us before you sign anything.
By request, not by timer
There is no automatic expiry of face data when an event closes, and no setting that creates one — an earlier version of this page said there was. Deletion is a request you or a guest makes to us, handled by a person. The retention terms that do apply are in the privacy policy.
Specific, checkable, boring
Not a posture, not a philosophy. Six things that are true of the code, each of which you could ask us to demonstrate.
No passwords
There is no email-and-password sign-in anywhere in Studioshare, so there is no password database to leak. Sign-in is a phone OTP, Google or Apple, through Firebase Auth.
Token-checked APIs
Routes that touch studio or event data require a Firebase ID token, verified server-side on every request by a shared guard rather than per-route by hand.
The face service is private
It rejects unauthenticated callers. Our backend mints a short-lived identity token per request from the cloud metadata server to call it. There is no public endpoint to point a scraper at.
Fetch allow-list
When the face service is asked to fetch an image by URL, that URL is restricted to our own storage hosts over HTTPS — so the parameter cannot be turned into a request against internal infrastructure.
Signed payment webhooks
The Razorpay webhook verifies an HMAC-SHA256 signature with a constant-time comparison before it will credit an account.
Studio-scoped ownership
Billing and destructive studio actions check that the caller actually owns the studio, not merely that they are signed in.
Consent to find your photos is not consent to be marketed to.
This is the single most important paragraph on the page, and it is the one the rest of the delivery category has no commercial reason to write.
India’s Digital Personal Data Protection Act, 2023 turns on purpose limitation: personal data may be processed only for the specific purpose the person consented to. Not a related purpose. Not a purpose the same company happens to also have. The one that was described when consent was taken.
When a guest takes a selfie at a wedding, the purpose they are agreeing to is narrow and obvious: match this face against this one event’s gallery so I can see the photographs I am in. That is the whole of it. It is not agreement to be added to a list, to receive an offer three months later, or to have their face carried forward into somebody else’s marketing.
Those are two different purposes, so under the Act they need two different consents. The failure mode the category will drift into is the bundled one — a single checkbox that reads “find my photos and hear from the photographer”, where declining costs you your own pictures. That is not consent. It is a toll.
It is also worth being blunt about what the vector is. A face embedding held against a user account is biometric personal data. Calling it anonymised does not make it so, and the fact that it is a list of numbers rather than a picture does not put it outside the Act.
The Guest Graph
A separate, explicit, easy-to-decline opt-in that lets a guest hear from you later — kept legally distinct from the consent that powers "find my photos".
It does not exist in Studioshare today. No guest data is being collected for it today, and nothing described here is currently in operation. We are telling you about it early because you should be able to judge the boundary before it is load-bearing, not after.
What the opt-in will have to be
- Asked separately, on its own, never bundled into the step that finds your photos.
- Worded in plain language, naming who would contact you and what for.
- Easy to decline — and declining changes nothing about your ability to find, view or download your own photographs.
- Withdrawable afterwards, by writing to us.
Building it this way is slower, and it will convert worse than a bundled checkbox — which is exactly why it is the only version that survives contact with a school’s or a corporate’s legal team.
What we do not have, said out loud
Most security pages are a list of things a company holds. This half of ours is a list of things we do not, because the previous version of this page claimed several of them and a certification you have not earned is a legal exposure rather than a marketing flourish.
- Not held: No SOC 2 report. We are not audited, and we are not “SOC 2 ready” either — that phrase means nothing.
- Not held: No ISO 27001 certification.
- Not held: No “GDPR certified” badge. GDPR certification of this kind does not exist, and we hold no attestation.
- Not held: No HIPAA claim of any sort. Do not put protected health information into Studioshare.
- Not held: No uptime SLA. Not 99.9%, not any number. If you need a contractual SLA, we do not have one to give you.
- Not held: No penetration test or third-party security audit we can hand you, because none has been done.
- Not held: No end-to-end encryption. Storage and transport encryption are Google Cloud defaults, not an extra layer we built.
- Not held: No watermarking, no download restrictions, no expiring links and no audit log.
- Not held: No data processing agreement template on file, and no region selector for where your data lives.
If your client’s procurement process requires any of the above, we will fail it, and we would rather you learn that here than in a vendor questionnaire two weeks before the shoot.
Ask the awkward question first.
If where the maths runs, what we retain, or what we cannot certify is a decision factor, put it to us before you build an event around it.
Windows desktop app and Android. macOS and iOS in development.