Privacy Policy · EU/US/IL

Data controller: ⟦РЕШЕНИЕ: IL-юрлицо / название / реквизиты — владелец продукта⟧ Governing law: GDPR (EU users) · US: state privacy / biometric laws (BIPA-style for biometrics; CCPA/CPRA and equivalents for general personal data ⟦охват — юрист⟧) · IL Privacy Protection Law (plus the Privacy Protection Regulations on data security). Data protection contact / DPO: ⟦РЕШЕНИЕ: e-mail + ответственное лицо / нужен ли формальный DPO по GDPR ст. 37 — юрист⟧ Effective date: ⟦РЕШЕНИЕ: дата публикации⟧

1. What data we process

1a. What stays in your browser

While you are setting up a shoot and have not signed in yet, your answers (height, clothing size, body type, gender, the chosen shoot and outfits) are kept in your own browser, on your device — so that you can step away and come back without filling everything in again. These answers reach our servers only together with the order, when you place it.

This data is not sent anywhere automatically and is visible only to you. It is erased when the shoot is delivered, when you sign out, and also if you clear the site data in your browser. The same place holds small things such as your chosen language.

⚠️ If you are setting up a shoot on someone else's or a shared device, sign out when you are done — that way your answers are not left for whoever opens the site next.

_(Note for the lawyer: this section describes browser-side storage and was added together with the change that extended the lifetime of this data from "the tab" to "the device". The cookie banner and the basis for analytics remain open item 3.3 and are not decided here.)_

Payment: payments are processed by Lemon Squeezy (Merchant of Record) — it acts as the seller and independently processes the payment data (the card number never reaches us) and taxes (EU VAT / US sales tax). We receive the payment status and the accounting metadata of the order.

1b. Two data-minimisation changes made in S26 (2026-08-14)

① We no longer ask for weight. The questionnaire used to collect height and weight; it now collects height, clothing size (XXS…3XL) and body type (one of six, including "I'd rather not say"). The reason is factual rather than legal, and therefore more robust: weight does not translate into body shape — the same mass produces different silhouettes, so the data was being collected without any benefit to the result. Less data at the same quality of service is data minimisation in practice, not a gesture.

② The launch-waiting-list email is collected only in the ◨ web channel and only via a separate checkbox. The men's shoot is not available yet (it is being prepared); those interested are offered the chance to leave an address in order to receive the launch announcement. The conditions: the box is not pre-ticked, the email is optional, and declining does not prevent use of the service. In the ◧ bot no email is collected at all — there is already an open communication channel there, and creating a new class of data just for a notification is unnecessary. This is a deliberate asymmetry between surfaces: one process (registering interest), different means. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: срок хранения адреса ожидания и порядок отписки — отдельной строкой в §6, либо привязать к «удалить после отправки письма о запуске»⟧

1a. The consent log (how we record acceptance)

Before uploading photos, the User ticks three consents: being of age (18+), acceptance of the Terms and of this Policy, and biometric processing. Each is stored as a separate record stating the version of the document, the date and time, and the IP address at the moment of acceptance.

• The "18+" and "biometrics" consents relate to the User's identity and are recorded once — they apply to all of their shoots.
• Acceptance of the Terms and of this Policy is recorded for each order: the version of a document may change between shoots, and we must know which version the User agreed to.

The consent log is kept for as long as it is necessary to defend the rights of the parties. When an account is deleted, the log records themselves are deleted, but a de-identified snapshot of the fact of consent (the type, the document version and the date — without the IP or any other PII) is retained in the deletion record as evidence that the processing was lawful (see §6a–§6c). ⟦РЕШЕНИЕ: срок хранения снимка согласий после удаления аккаунта — юрист⟧

2. Biometrics — handled separately

The processing of a facial image is governed by a separate consent — Consent to biometric data processing. This Policy describes the general framework; as regards biometrics, the consent takes precedence.

3. Analytics (PostHog) and the Telegram identifier

3.1. PostHog is used for product analytics (the FromFrame project, US region). Usage events and technical properties are collected.

3.2. ⚠️ Open privacy question (privacy trigger, backlog E10): at present tg_user_id is sent to PostHog as a person property. A Telegram id is an identifier of a person. ⟦РЕШЕНИЕ: передавать ли tg_user_id (и email из OAuth) в PostHog вообще; варианты — (а) не передавать, (б) передавать хеш/псевдоним, (в) передавать только при отдельном согласии на аналитику. — владелец продукта + юрист⟧

⚠️ GOVERNANCE FLAG: until the question in 3.2 is decided, sending a raw tg_user_id to a third-party analytics service is a potential divergence from the data-minimisation principle. To be reconciled with the consent policy before production (see the "Privacy" backlog). The implementation (hashing / switching off) is NOT coded here — what is fixed here is the requirement.

3.3. ⟦РЕШЕНИЕ: cookie-баннер / consent на аналитику и cookie для веб-канала (GDPR + ePrivacy; для US-штатов — opt-out-механики) — юрист⟧

4. Recipients / sub-processors

• The external provider that trains the Likeness model (Higgsfield, jurisdiction ⟦уточнить — юрист⟧, probably US) — a sub-processor of BIOMETRICS: the Source materials (the facial image) are transferred to it in order to train the Likeness model (soul_id) and to generate the Result. The provider processes the data on our instructions, is obliged not to use it for its own purposes and not to pass it to third parties, and to delete it on our request with confirmation. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: эти гарантии подлежат закреплению в DPA с провайдером и НЕ декларируются как факт до его подписания (задача DPA — backlog)⟧
• AI providers for generation (NanoBanana, GPT Image, Seedream and others, predominantly US) — processing the image in order to generate.
• "Redressing" (the second AI pass, Spec 004) — NanoBanana via Higgsfield: the generated frames (which carry the User's face), together with an image of the garment, are transferred a second time in order to compose the final look. This introduces no new recipients (Higgsfield / NanoBanana are listed above), but it is a second instance of transferring the face to those same providers. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: раскрыть двухпроходность; отразить в DPA/SCC (см. Согласие на обработку биометрии, §2.4/§4.1a)⟧
• Cloud storage — Cloudflare R2 (S3-compatible, with the bucket in an EU jurisdiction) + a CDN; personal objects are delivered only through signed links (a public CDN was rejected).
• Lemon Squeezy — Merchant of Record: payments, taxes, receipts.
• Google — OAuth authentication on the website (we receive the verified email; the password is never passed to us).
• An email service (SES / Postmark — ⟦РЕШЕНИЕ: финальный провайдер — при реализации E4/E10⟧) — delivery codes and reminders.
• PostHog — product analytics (US).
• ⟦РЕШЕНИЕ: полный перечень суб-обработчиков + их юрисдикции + DPA/условия передачи — юрист⟧

5. Cross-border transfers

5.1. The controller is an IL legal entity: Israel holds an EU adequacy decision — transfers EU → IL require no additional mechanisms ⟦подтвердить актуальность — юрист⟧.

5.2. Transfers to the US (the external provider that trains the Likeness model, PostHog, the AI providers, the email service): ⟦РЕШЕНИЕ: EU-US Data Privacy Framework (для сертифицированных) / SCC — по каждому получателю — юрист⟧. The transfer of BIOMETRICS (the facial image) to the external training provider is a cross-border transfer of a special category of data: the transfer mechanism and the DPA are critical. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ⟧

5.3. Photo storage is in an EU jurisdiction (R2), see §4.

6. Retention periods and deletion

6.1. Personal data — the Likeness model (soul_id at the external provider), the Source photographs (with us, including the reduced copy used for analysis) and the profile (height, clothing size, build, gender) ⟦исправлено 2026-10-08, сверка канона B-TXT-01; юрист смотрит после⟧ are kept for 30 days after the User's last action with them (uploading photos, editing the profile, paying for a shoot, a message in the order chat; on the Service's side — delivering an order or a request to the User). While the User has an order on which the next step is the Service's (paid, in production, in review, a revision), the period does not run. On expiry — deletion at the provider with confirmation of deletion (a log entry plus the request forwarded to the provider) and deletion at our end; the account and the list of orders are retained. Order data — the finished Results and the order correspondence are kept for 30 days after the last action on the order (delivery; the Service's request for photos; cancellation; for an unpaid draft — the last message). While the order is paid and in production, in review or in revision (including an open revision request), the period does not run. Then deletion from storage with CDN cache invalidation and a log of the deletion; the order itself and the payment are retained. Reminders — 7 days and 3 days before, and on the day of deletion (bot / email, and in the account). The User can extend storage by 30 days by an explicit action (a click = opt-in; the period is added to the deletion date; there is no limit on the number of extensions) or delete the data right away. On replacement of the Likeness model with a new one, the previous model is unlinked and deleted once a recovery window of about 5 days has passed. ⚠️ Changed on 2026-10-06 (owner's decision, S56): previously — four separate periods with different starting points (training · delivery · upload) and a single reminder 3–5 days before. The wording was brought into line with the fact by us and IS AWAITING THE LAWYER'S REVIEW. Details — the Data Retention and Deletion Policy. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: два срока от последнего действия + доказательство удаления у суб-обработчика⟧

6.2. Other categories during the ordinary lifecycle (while the account is active): order records and payment statuses are kept for as long as necessary to provide the service and to meet the tax and accounting obligations of the IL legal entity; analytics — for the product analytics period; the consent log — as evidence that the processing was lawful. ⟦РЕШЕНИЕ: конкретные сроки по каждой категории — юрист⟧

6a. Account deletion ("the right to be forgotten")

On the User's request (◨ a button in the web personal account; a support operator can submit the same request) the account is deleted according to the following mechanics (implemented — spec 002):

• (a) Immediate erasure, no cancellation window. Once the User has confirmed the deletion, sign-in and access to data stop immediately and erasure starts immediately; the deletion cannot be cancelled and the account cannot be recovered. The only wait: if a shoot step is running at that moment (a paid call has already been sent to the provider), it is allowed to finish (minutes), no new steps start, and then everything is erased.
• (b) What is erased completely: the source photos; the Likeness model (soul_id) — with the deletion request forwarded to the external provider (Higgsfield) and confirmed; sessions; confirmation codes (OTP); identifying profile fields (email, Google identifier, Telegram identifier, questionnaire). Deletion covers both channels — bot and web (a single identity). Finished Results in storage are deleted by the same cascade.
• (c) Payment records are NOT deleted; they are de-identified (see §6b): this is a lawful exception.
• (d) The consent log: the records themselves are deleted, but evidence of the fact of consent is retained in de-identified form in the deletion record (see §6c) — the type of consent, the document version and the date, without PII.
• (e) A deletion receipt. The fact of deletion is recorded as a de-identified entry (§6c) as evidence that the policy was followed; the identity cannot be reconstructed from it. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: отсутствие окна отмены при удалении аккаунта; достаточность обезличивания платежей и снимка согласий вместо полного удаления; текст уведомления Пользователю о том, что именно сохраняется после удаления⟧

6b. Payment records after deletion — de-identification, not deletion

Payment data (amount, currency, date, the provider's transaction identifier, the provider) is retained after the account is deleted, but is unlinked from the User and the order (de-identified) and is no longer connected to an identity. The basis is GDPR Art. 17(3)(b) (processing is necessary for compliance with a legal obligation — the tax and accounting records of the IL legal entity; sales accounting on the Lemon Squeezy side as Merchant of Record). The right to erasure is limited by law in this respect; we minimise the data by removing the link to the identity while retaining a de-identified financial record. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: корректность опоры на ст. 17(3)(b) и достаточность обезличивания для EU/US/IL⟧

6c. The deletion receipt — evidence without PII

Every deletion is recorded as a de-identified entry: an irreversible hash of the account identifier, the dates of the request and of the erasure, counters of what was deleted (models / photos / de-identified payments) and a snapshot of the consents (type, document version, date — WITHOUT the IP, the signature or any PII). Its purpose is to prove to a regulator that the deletion happened and that the processing (including of biometrics) was lawful; the identity cannot be reconstructed from the entry. ⟦НА РЕВЬЮ ЮРИСТУ ПЕРЕД ПРОДОМ: состав записи об удалении и срок её хранения⟧

7. Rights of the data subject

The User has the right to: obtain access to their data; request correction or deletion; withdraw consent; restrict or object to processing; data portability (GDPR); and lodge a complaint with a supervisory authority (an EU DPA / the IL Privacy Protection Authority; for US states — the mechanisms of the relevant law, including a private right of action under Illinois BIPA).

• How to make a request: through the identity channel — ◧ a command in the bot / ◨ the personal account (Google OAuth) / the support email ⟦РЕШЕНИЕ: финальный канал + срок ответа (GDPR — 1 месяц) — владелец продукта⟧
• Account deletion follows the mechanics in §6a (immediate erasure, no cancellation window → irreversible erasure of PII, photos and the Likeness model across all channels). Important: the right to erasure does not extend to payment records — they are retained in de-identified form on tax grounds (§6b). The fact of deletion is recorded as a de-identified entry (§6c).

8. Security

Organisational and technical protective measures are applied: server-side access to storage by key, isolation of orders by session (S1), delivery only through short-lived signed URLs, and a mandatory second factor (a code from an email) for the first download of biometric results on the website. ⟦РЕШЕНИЕ: детализация мер под IL Privacy Protection Regulations (уровни безопасности БД) — юрист⟧

9. Children

The Service is not intended for persons under 18; data of minors is not knowingly processed.

10. Changes

The current version is published within the Service. ⟦РЕШЕНИЕ: порядок уведомления — юрист⟧

Open decisions (summary)

• The operator (IL legal entity), contacts, whether a formal DPO is required (GDPR Art. 37), the date.
• The legal basis for analytics processing; cookie consent (EU) / opt-out (US) for the web.
• `tg_user_id` / email → PostHog: send at all / hash / only with consent (privacy trigger).
• The full list of sub-processors + cross-border mechanisms (DPF/SCC; EU→IL adequacy).
• Retention periods for the non-biometric categories; the channel and deadline for responding to data subject requests.
• The coverage of US general privacy law (CCPA/CPRA equivalents) beyond biometrics.