clothy.co Privacy Policy

not been reviewed by qualified legal counsel and must not be published, linked, relied upon, or represented to any user, regulator, partner or court until it has been. It contains [CONFIRM: ...] markers where a factual input is missing, and a "Notes for Counsel" section at the end recording judgement calls and open questions.

Version: 0.1 (draft) Policy version identifier: [CONFIRM: the policy version string that will be written into the consent_records.policy_version column] Effective date: [CONFIRM] Last updated: [CONFIRM]

Part A. Plain-language summary

This summary is not the policy. It is here so you can understand the shape of what we do in under two minutes. The operative text begins at Part B and governs if the two ever differ.

What clothy.co is. You show us a clothing listing and one full-body photograph of yourself. We work out the real measurements of the garment from the brand's published size chart, we estimate your body measurements from your photograph, and we tell you how the garment would fit you, region by region. We also render a picture of the garment on you.

The important data. The two pieces of data that matter most are your full-body photograph and the body measurements we derive from it. We treat both as highly sensitive. We are open in section 5 about the fact that lawyers and regulators disagree about whether measurements taken from a photograph are "biometric data", and we explain the position we take and why.

What we do with your photograph. We use it to measure you and to render the try-on image. We do not use it to work out who you are. We do not run face recognition. We do not build a faceprint. We do not sell it. We do not use your data to train AI models, and we require our AI provider by contract not to train on it either.

How long we keep it. By default, uploaded images are deleted after 30 days and derived body measurements are deleted after 30 days. Sessions expire after 30 days of inactivity and after 180 days no matter what. A sweep runs every hour to purge what has expired.

How it is protected. Every user's sensitive data is encrypted with a key that belongs only to that user. That key is itself encrypted by a master key. If you delete your account we destroy your key, which makes your data permanently unreadable even in backups we cannot edit. We call this crypto-shredding and we explain it in plain terms in section 8.

Can a human at clothy.co look at my body data? Only under a time-boxed, approved access grant, and for body measurements, photographs and try-on outputs a second, different member of staff has to approve it. Every single decryption is logged, and you get a record of it that you can see in your account. Section 9 is entirely about this.

Is a computer deciding something about me? Yes, in a limited sense. The fit verdict is produced by an AI model. We do not think it is the kind of decision that has legal or similarly significant effects on you, and section 6 sets out our reasoning honestly, including the argument against us. You can hand-correct every single measurement, and that correction overrides the model.

What you can do. You can see your data, correct it, export it free of charge, delete it, withdraw your consent, and complain to a regulator. Sections 11 and the jurisdiction annexes explain how, and what deadlines apply where you live.

Who to contact. [CONFIRM: privacy contact email address].

Part B. The policy

1. Who we are, and who is responsible for your data

1.1 The controller

The organisation responsible for the personal data described in this policy is:

In this policy, "we", "us" and "our" mean that entity. "You" means the individual whose personal data we process.

1.2 Controller and processor analysis

For the purposes of the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR") Article 4(7) and the UK GDPR, we are the controller of all personal data described in section 4. We determine the purposes and the means of the processing. Nobody else instructs us on what to collect or why.

The third parties listed in section 7 act as processors under GDPR Article 4(8) and Article 28, meaning they process personal data only on our documented instructions, with the exception noted below.

Under the California Consumer Privacy Act as amended (Cal. Civ. Code § 1798.100 et seq., "CCPA"), we are a business. The parties above that act on our instructions and are bound by CCPA-compliant contract terms are service providers or contractors as defined in Cal. Civ. Code § 1798.140(ag) and (j). Whop's status under the CCPA is [CONFIRM].

Under the Washington My Health My Data Act (RCW ch. 19.373, "MHMD") we are a regulated entity in respect of Washington consumers, unless we fall within the "small business" definition in RCW 19.373.010, which we [CONFIRM: assess as / do not assess as] applicable.

1.3 Representatives and Data Protection Officer

1.4 Where the service is offered

[CONFIRM: the list of countries and US states in which the service is intentionally offered, and whether EEA and UK users are intentionally served. This determines which of the annexes in Part C actually bind us, and whether an Art. 27 representative is required.]

We collect your residency country and, where relevant, state, and record the source of that information as one of: attested by you, inferred from IP address, or taken from your billing details. We use this to apply the correct set of legal rights to your account.

2. Scope of this policy

2.1 What this policy covers

This policy covers personal data we process when you visit clothy.co, create an account, use the try-on service, correspond with us, or pay us.

2.2 Documents that sit alongside this one

The Consumer Health Data Privacy Policy is reproduced at Annex C of this document for drafting convenience. It must be published as its own page with its own homepage link. Publishing it only as a section of this policy does not satisfy RCW 19.373.020(2).

2.3 Age of users

This service is intended only for adults. You must be at least [CONFIRM: MIN_AGE. The .env.example file states 18. The running development configuration states 16. This is a material discrepancy. This draft is written on the basis of 18. See section 13 and Notes for Counsel, item 1.] years old to create an account.

3. How we describe lawful bases

Where this policy cites a lawful basis, it is citing GDPR Article 6(1) and, for special category data, Article 9(2). Those provisions do not apply outside the EEA and the UK, but we have used the same analysis to structure the whole service, so the table in section 4 is a fair description of why we process your data wherever you live.

4. Complete table of the data we process

This table is exhaustive as against the product brief. If we begin processing a category of data that is not in this table, we will update the table before we do so, and where the law requires it we will obtain fresh consent first. That commitment is not merely good practice: under RCW 19.373.020(3) we may not collect, use or share a category of consumer health data not disclosed in our policy without first disclosing it and obtaining affirmative consent.

4.1 Account and identity data

4.2 Uploaded imagery

All uploaded imagery is stored encrypted. See section 8.

4.3 Derived body data

All derived body data is stored encrypted. See section 8.

4.4 Derived garment data

4.5 Fit reports

Fit reports are stored encrypted. See section 8.

4.6 Session, device and security data

4.7 Consent records

We keep a record of each consent so that we can prove, as GDPR Article 7(1) requires, that you actually consented, and so that you can see what you agreed to.

4.8 Usage, quota and billing data

4.9 Staff access, audit and transparency data

4.10 Correspondence

4.11 Data we deliberately do not collect

For the avoidance of doubt, we do not collect, and this policy does not authorise the collection of:

• precise geolocation;
• payment card numbers (Whop holds these, we do not);
• government identity documents;
• race, ethnicity, religion, political opinion, trade union membership, sex life or sexual orientation;
• health records, diagnoses, treatments or medication data;
• a faceprint, face template, or any other identification template;
• any biometric identifier used for the purpose of identifying or authenticating you.

Note on how this list is worded. Each entry describes an operation we do not perform, not a legal category we assert we fall outside. That is deliberate. Whether a given piece of data is "biometric data" in a given state is a contested legal question, and a flat statement that we do not hold biometric data would be a factual claim about a contested category. If it turned out to be wrong, it would convert a privacy question into a deception claim under section 5 of the FTC Act and state unfair and deceptive practices law. So we tell you what we do, and we let the legal labels be applied jurisdiction by jurisdiction in Part C.

HIPAA does not apply to us. We are not a health plan, a health care clearinghouse, or a health care provider transmitting standard transactions, and we are not a business associate of one. We do not claim HIPAA compliance, and nothing in this policy should be read as such a claim.

If any of this becomes false, this section must be amended before the change ships.

5. Body photographs and body measurements: the analysis in full

This is the most legally contested part of what we do. We would rather set out the reasoning openly, including the arguments against our position, than assert a conclusion.

5.1 What actually happens, mechanically

1. You upload one full-body photograph.
2. An AI vision model estimates a set of body dimensions from that image: chest, shoulder, sleeve, waist, hem, neck, cuff, inseam, thigh and length.
3. You may hand-correct any of those numbers.
4. The resolved set of numbers is compared against the garment's real measurements in centimetres, taken from the brand's published size chart.
5. A render and a written fit verdict are produced.

At no point does the system attempt to answer the question "who is this person?". There is no enrolment database, no gallery, no one-to-many search, no one-to-one verification, no face template, no similarity threshold, and no re-identification step. The output of the measurement stage is a list of distances in centimetres.

5.2 Is this biometric data under the GDPR?

GDPR Article 4(14) defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person.

GDPR Article 9(1) then makes special category data only the processing of "biometric data for the purpose of uniquely identifying a natural person".

Two thresholds therefore have to be crossed before Article 9 bites: the data must be capable of unique identification, and the processing must be for the purpose of unique identification.

Our position. Our processing does not cross the second threshold and we doubt it crosses the first. We process the image to measure, not to identify. This is the same distinction the European Data Protection Board drew in its Guidelines 3/2019 on processing of personal data through video devices, where it said that photographs are not systematically special category data, and are covered only when processed through specific technical means allowing unique identification or authentication, and that processing intended to distinguish one category of people from another without identifying anyone does not fall under Article 9. The ICO's biometric recognition guidance takes the same line: it is the biometric recognition purpose that engages Article 9.

Where regulators and courts may disagree with us, and we accept these are real arguments:

• The identifiability argument. A precise ten-dimension body measurement vector is close to unique. Combined with a photograph, it is arguably capable of identifying you even without a face. A regulator could say the Article 4(14) capability threshold is met on the data alone, regardless of our intentions.
• The image itself. We hold a full-body photograph of you. Even setting aside the derived measurements, an identifiable photograph is plainly personal data, and if a face is present it is capable of supporting recognition, whether or not we perform recognition.
• The health data argument. GDPR Article 4(15) defines data concerning health broadly, and the Court of Justice has been expansive: in Case C-21/23 Lindenapotheke (Grand Chamber, 4 October 2024) the Court held that data submitted when ordering non-prescription pharmacy products is health data, because it may reveal something about health status even where it does not do so reliably. Applying that reasoning, a body measurement set arguably reveals or permits inference about body composition, weight and therefore health status. This is the strongest argument against us, and it does not depend on the word "biometric" at all.
• Inference risk. Measurements over time could reveal weight change, and weight change can correlate with pregnancy, eating disorders or illness. We do not draw those inferences, but the data supports them.
• The revelation argument, which is stronger still. In Case C-184/20 OT v Vyriausioji tarnybines etikos komisija (1 August 2022) the Court of Justice held that data from which special category data may be revealed indirectly, by an intellectual operation of comparison or deduction, is itself special category data. That is a capability test, not a purpose test, and it does not care what we intend. A full-body photograph of a person can reveal, on its face, apparent racial or ethnic origin, religious belief through visible religious dress, pregnancy, disability, limb difference, the use of mobility aids, visible medical devices, and gender presentation. On OT, the photograph is arguably Article 9 data before we do anything to it at all. We regard this as the single strongest argument that we process Article 9 data, and it applies to the image rather than to the measurements.
• The face detection step. To suppress a face we must first locate one. Locating a face is detection, not recognition: it answers "is there a face here", not "whose face is this", and it produces a bounding box or coarse landmark set rather than an identity template. But in Illinois plaintiffs have repeatedly pleaded that software which locates facial features has performed a "scan of face geometry" within 740 ILCS 14/10. The defence is that a biometric identifier must be capable of identifying someone, which a bounding box is not, and that is the reasoning of Martell v. X Corp., 2024 WL 3011353 (N.D. Ill. 13 June 2024). But there is no appellate authority and the district courts are split: Rivera v. Google Inc., 238 F. Supp. 3d 1088 (N.D. Ill. 2017) allowed a claim over a template mapping facial measurements and rejected the argument that BIPA does not reach scans derived from photographs. There is a real irony here, and we would rather name it than hide it: the step that exists purely to protect you is the step that carries the most US statutory risk. We are not going to remove it for that reason.

Note also what the absence of harm does not do for us. Under Rosenbach v. Six Flags Entertainment Corp., 2019 IL 123186, a BIPA claimant need not plead any injury beyond the statutory violation itself. Careful handling is not a defence to a procedural failure.

What we do about the disagreement. We do not rely on winning the argument. We apply the Article 9 standard as if it applied:

1. We take explicit consent for the upload of your body photograph and the derivation of body measurements. That is the Article 9(2)(a) condition, applied on a precautionary basis. It is separate from, and additional to, agreeing to the Terms of Service.
2. We do not bundle that consent with anything else. Refusing it does not stop you having an account.
3. You can withdraw it at any time, and withdrawal deletes the underlying data.
4. Body data gets the strongest technical controls we operate: per-user encryption keys, the two-person rule for staff access, and a user-visible access record.
5. We treat body data as sensitive personal information under the CCPA and as consumer health data under the Washington My Health My Data Act and the Nevada consumer health data law, without arguing about it. See Annexes B and C.

The practical effect is that our compliance posture does not change if the argument goes against us. That is deliberate.

5.3 Is this a biometric identifier under US state biometric statutes?

The US statutes are drafted differently from each other and differently from the GDPR.

Illinois BIPA (740 ILCS 14). "Biometric identifier" is a closed list: a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry. BIPA then expressly excludes photographs from the definition. A scan of body geometry is not on the list. On the statutory text, an estimate of chest and inseam length from a photograph is not a biometric identifier.

However, Illinois federal courts have repeatedly declined to let the photograph exclusion do too much work, holding that data derived from a photograph by scanning facial geometry can be a biometric identifier notwithstanding the exclusion. And there has been a wave of BIPA class actions against retailers offering virtual try-on features, with at least one significant settlement receiving final approval. Those cases mostly involve face geometry, which we do not extract. But we are not willing to bet a class action on the distinction.

Texas CUBI (Tex. Bus. & Com. Code ch. 503). The same closed list: retina or iris scan, fingerprint, voiceprint, or record of hand or face geometry. Body measurements are not on it. Texas HB 149 (the Texas Responsible Artificial Intelligence Governance Act, effective 1 January 2026) amended CUBI to add a limited exemption for training, processing or storing biometric identifiers in developing or offering AI systems, unless the system is used to uniquely identify a specific individual. We do not use it to identify individuals. Note that the exemption does not apply if a biometric identifier captured for AI training is later used for a commercial purpose outside the exemption.

Washington HB 1493 (RCW ch. 19.375). "Biometric identifier" means data generated by automatic measurement of biological characteristics used to identify an individual, and the statute expressly excludes a physical or digital photograph. The trigger is enrolment in a database for a commercial purpose. We do not enrol.

Washington My Health My Data (RCW ch. 19.373). Different and much broader. Its definition of biometric data is not the RCW 19.375 one, and its definition of consumer health data expressly includes biometric data and information about "bodily functions" and physical health status. We do not contest MHMD coverage. We treat body data as consumer health data. See Annex C.

Colorado (Colo. Rev. Stat. § 6-1-1314, as amended by HB 24-1130, effective 1 July 2025). Broader again, and it independently requires a written, publicly available biometric policy with a retention schedule, a destruction protocol and a biometric breach response protocol. See the separate Biometric and Body Data Policy.

Our conclusion, stated plainly. We do not believe our body measurements are a "biometric identifier" under the closed-list statutes of Illinois, Texas or Washington RCW 19.375, because we do not scan face or hand geometry and we do not identify anyone. We accept without argument that they are consumer health data under Washington MHMD and Nevada SB 370, and sensitive personal information under the CCPA and the newer state comprehensive laws. We nevertheless publish a BIPA-standard written policy, take a BIPA-standard written release, and operate a BIPA-standard retention and destruction schedule, because the cost of doing so is low and the cost of being wrong is not. That policy is the Biometric and Body Data Policy.

How the labels are applied in this document. Where a statute attaches obligations to a legal category, we apply that category conditionally and by jurisdiction, in the annexes at Part C, in the form "to the extent any information we process is a biometric identifier under [statute], the following applies". We do not adopt a legal label globally in the body text, and we do not make a global denial either. Section 4.11 explains why.

5.4 Faces

Where a face is present in an uploaded image, our system records face_detected, face_suppressed, suppression_method and suppressed_at. The intent of the design is that faces are suppressed before any image is sent to a third-party AI processor.

[CONFIRM: **critical**. Whether face suppression happens (a) in your browser before the image is transmitted to us, or (b) on our servers after receipt. This draft states only what is verified. The landing page currently says "Your face never leaves your device". If suppression is server-side, that sentence is false and must be changed before launch, because an inaccurate privacy claim is itself an unfair or deceptive practice under section 5 of the FTC Act, and the FTC's Policy Statement on Biometric Information and Section 5 of the FTC Act (18 May 2023) expressly identifies deceptive statements about the collection and use of biometric information as an enforcement priority. See Notes for Counsel, item 2.]

What we can state now, and are willing to be held to:

• We do not extract, compute, store or compare a face template, faceprint or face geometry scan.
• We do not perform face recognition, face matching or face verification.
• We do not use your face to identify you.
• Where a face is detected, suppression is applied before the image is sent to a third-party AI processor.

Detection is not recognition. To hide a face we have to find it first. Finding one answers the question "is there a face in this image", and produces a region of the picture to obscure. Recognition would answer the question "whose face is this", and would require building a template and comparing it against something. We do the first and not the second. We build nothing to compare against, and we keep nothing that could be compared. See section 5.2 for why this distinction, despite being technically clear, is legally contested in Illinois.

6. Automated decision-making and profiling

6.1 What is automated

The estimation of your body measurements from your photograph, and the production of the written fit verdict, are performed by AI models without a human reviewing each result. That is automated processing. To the extent it evaluates personal aspects relating to you (your physical characteristics), it is also profiling within GDPR Article 4(4).

6.2 Does GDPR Article 22 apply?

Article 22(1) gives you the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning you or similarly significantly affects you.

Our position: Article 22 is not engaged. Our reasoning:

• No legal effect. A statement that a jacket will be tight across the shoulders does not alter your legal rights, status or obligations. It is not a credit decision, an insurance decision, an employment decision, a benefits decision or an eligibility decision.
• No similarly significant effect. The Article 29 Working Party guidance on automated individual decision-making and profiling (WP251rev.01, endorsed by the EDPB) sets the "similarly significant" threshold deliberately high: the effect must be equivalent in impact to a legal effect, such as denial of credit, of employment, or of access to a service, or something that significantly affects circumstances, behaviour or choices, or leads to exclusion or discrimination. A shopping recommendation about garment fit does not reach that threshold. Nothing is withheld from you. No door closes. You remain free to buy the garment.
• Not solely automated in the operative sense. You can hand-correct every single measurement, and your correction, not the model's estimate, is what feeds the fit calculation. The human in the loop is you, and your intervention is not token: it changes the output.

The argument against us, stated fairly. A user could argue that a fit verdict influences a purchasing decision, and that a systematically inaccurate model that mis-sizes a particular body type produces a discriminatory exclusion effect, which WP251 does treat as relevant. We think this fails on the facts because we do not gate the purchase and we do not gate access to the service on the verdict. But we do not treat the point as frivolous.

6.3 What we disclose anyway

Because we would rather be transparent than rely on a threshold argument, we disclose the Article 13(2)(f) and 15(1)(h) content whether or not Article 22 applies.

The logic involved.

1. Your uploaded photograph is passed to an AI vision model, which returns an estimate, in centimetres, for each of the ten body regions we use.
2. Those estimates are shown to you, editable.
3. The garment's real measurements in centimetres are read from the brand's published size chart for the brand, item and listed size we identified from your listing.
4. For each region, the system compares your resolved measurement against the garment's measurement for that region and expresses the difference as a fit outcome for that region.
5. The written verdict is a rendering of those per-region differences.
6. The try-on image is generated by an AI image model from your photograph and the garment photograph.

The significance and envisaged consequences. The output is advisory. It tells you how a garment is likely to fit. It does not affect your price, your access to the service, your account standing, or anything outside the sizing advice itself.

Known limitations, disclosed honestly. The measurement estimate is an estimate from a single two-dimensional photograph. Its accuracy varies with pose, camera angle, distance, lighting, clothing worn in the photograph and body type. Published brand size charts are themselves inconsistent between brands and sometimes wrong. [CONFIRM: whether we have measured accuracy, and whether accuracy varies materially across body types, sizes, skin tones or genders. If we have not tested for differential accuracy, we should, because the FTC's May 2023 biometric policy statement treats failure to assess foreseeable harms including bias before deployment as a potential unfair practice, and unsubstantiated accuracy claims as a potential deceptive practice.]

Your safeguards.

• Correct it yourself. Every estimated measurement is editable, and your value overrides the model's.
• Ask for a human. You may ask us to have a member of staff review a fit result. Contact [CONFIRM: email]. Note that reviewing your body data engages the two-person approval rule in section 9, and you will see a record of the access.
• Contest it. You may tell us you disagree with a result and why, and we will consider it.
• Refuse it. You may decline to use the automated measurement feature and enter your measurements by hand from the start. [CONFIRM: whether a fully manual entry path exists in the product. If it does not, this sentence must be removed or the feature built. See Notes for Counsel, item 5.]

Under Quebec's Law 25 (Act respecting the protection of personal information in the private sector, s. 12.1) and Brazil's LGPD Article 20, you have specific rights in relation to decisions based on automated processing. See Annexes F and G.

7. AI processing: what leaves our systems

7.1 The provider

We use a third-party AI provider for image generation and computer vision.

[CONFIRM: **The intended provider is OpenAI but it is NOT yet contracted or integrated.** Do not name a provider in the published policy until the contract is signed. Assume a US-based provider for the transfer analysis in section 10.]

7.2 What is sent

7.3 The commitments we require of the provider

These are the terms we require. They are stated here as commitments to you.

1. No training. The provider is contractually prohibited from using your data to train, fine-tune or improve its models or any other model.
2. Zero retention. The provider is required to operate zero data retention, meaning your image is processed and not persisted beyond the duration of the request. [CONFIRM: the exact retention term actually agreed, including any abuse-monitoring retention window the provider carves out. Many providers retain for a short period for abuse monitoring unless zero-retention is specifically enabled on the account. Do not publish "zero retention" unless it is contractually true.]
3. Processor status. The provider acts only on our instructions, under a data processing agreement meeting GDPR Article 28(3), and CCPA service provider terms meeting Cal. Civ. Code § 1798.140(ag).
4. No sale, no sharing. The provider may not sell or share your data, and may not use it for its own purposes or for cross-context behavioural advertising.
5. Subprocessors. The provider must maintain a public subprocessor list and give notice of changes.
6. Transfers. Transfers out of the EEA and UK are covered by the mechanism recorded in section 10.

7.4 We do not train on your data

We do not use your photographs, your body measurements, your fit reports or your renders to train, fine-tune or evaluate any model, our own or anyone else's. We do not use them to build a general body-measurement dataset. If we ever wanted to, we would have to come back and ask you, separately and specifically, and you would be free to say no.

7.4a The render is a synthetic image of you

The try-on image is not a photograph. It is an AI-generated image depicting a real, identifiable person, namely you, wearing something you were not wearing. We label it as AI-generated in the product [CONFIRM: verify that the render is visibly and durably labelled, and whether machine- readable provenance marking such as C2PA content credentials is applied].

Two consequences follow that are not data protection points but belong here for completeness:

• EU AI Act, Regulation (EU) 2024/1689, Article 50. Providers and deployers of systems that generate or manipulate image content constituting a deep fake are subject to transparency and marking obligations. [CONFIRM: whether the render falls within the Art. 50(4) deep fake disclosure duty or the Art. 50(2) machine-readable marking duty for synthetic content, and the applicable compliance date. Counsel should assess our role as provider, deployer, or both.]
• Misuse of the render by others. Because the render depicts a real person, misuse of the feature to generate imagery of someone other than the uploader raises non-consensual intimate imagery, right of publicity and platform liability questions. Those are addressed in the Acceptable Use Policy and the Content Moderation and Safety Policy rather than here.

7.5 What we do not claim

We do not claim that the AI processing happens on your device. It does not. Your photograph is transmitted to our servers and, for the measurement and render steps, to the AI provider. [CONFIRM: whether face suppression is the one step that happens on-device. See section 5.4.]

7.6 The full processor register

We maintain an internal processor register recording, for each processor: name, role, purpose, country, transfer mechanism, Data Privacy Framework verification date, data processing agreement signature date, DPA URL, subprocessor list URL, whether training on our data is contractually prohibited, retention period, and the reference of the relevant transfer impact assessment.

[CONFIRM: this table must be completed and verified before publication. An incomplete recipient disclosure fails GDPR Art. 13(1)(e) and Cal. Civ. Code § 1798.130(a)(5)(C).]

7.7 Other disclosures

We may also disclose personal data:

• to professional advisers (lawyers, auditors, accountants) under a duty of confidentiality;
• where required by law, court order, or a valid, binding legal demand, and where we are permitted to do so we will tell you first;
• to establish, exercise or defend legal claims;
• to protect the vital interests of you or another person;
• to a buyer or successor in a merger, acquisition or asset sale, subject to this policy continuing to apply and, for body data, to obtaining fresh consent where the law requires it. [CONFIRM: a body-data sale in an M&A context needs specific analysis. BIPA prohibits profiting from biometric data outright, and RCW 19.373.050 requires a signed authorisation to sell consumer health data. See the Biometric and Body Data Policy, section 7.]

7.8 We do not sell or share your data

We do not sell your personal data, we do not share it for cross-context behavioural advertising, and we have not done either in the preceding twelve months. We do not use third-party advertising trackers. See Annex B for the CCPA-specific statements this requires.

8. Retention and deletion

8.1 The schedule

The configured values are the environment values in force. If we change them we will update this table. [CONFIRM: whether the live production values match the defaults stated here. Publishing a 30-day figure while running a longer value would be a deceptive statement.]

8.2 The hourly sweep

Records past their retention date are purged by an automated sweep that runs every hour. There is therefore a window of up to one hour between a record expiring and it being purged.

8.3 Deleting your account

You can delete your account from within the product. [CONFIRM: the exact in-product path.] Deletion:

1. removes your account record and the data associated with it;
2. destroys your per-user data encryption key;
3. writes a tombstone entry to a shredded_keys register.

8.4 Crypto-shredding, in plain terms

Backups exist so that we can recover from a disaster. A backup is, by design, a frozen copy that cannot be edited. That creates a genuine problem for deletion rights: we cannot reach into a backup and surgically remove one person's rows.

Our answer is to make the data unreadable rather than to try to remove it.

• Each user's sensitive data is encrypted under a data encryption key that belongs to that user alone.
• That key is itself encrypted ("wrapped") by a versioned master key held by the application. This arrangement is called envelope encryption.
• When you delete your account, we destroy your data encryption key.
• The encrypted data that remains in any backup is then permanently unreadable. There is no copy of the key anywhere that could decrypt it. The data is, for every practical purpose, destroyed.
• We record the destroyed key in a shredded_keys register. That register is reconciled every hour, so that if a backup were ever restored and brought a shredded key back with it, the key would be destroyed again automatically. A restore cannot resurrect deleted data.

We consider this to satisfy the erasure obligation in GDPR Article 17 and the deletion obligations in Cal. Civ. Code § 1798.105, RCW 19.373.040(1)(c) and the equivalent provisions in other US state laws, and to constitute permanent destruction for the purposes of 740 ILCS 14/15(a).

8.5 What survives deletion, and why

A small set of records survives account deletion, because the law requires it or because deleting it would defeat a legal duty.

This is a permitted narrowing of the erasure right under GDPR Article 17(3)(b) and (e), and falls within the exceptions in Cal. Civ. Code § 1798.105(d).

9. Security

9.1 Encryption

All sensitive derived data and all imagery is encrypted at rest using AES-256-GCM, an authenticated encryption algorithm, under an envelope encryption scheme:

• a per-user data encryption key protects that user's data and nobody else's;
• that key is wrapped by a versioned master key held by the application, so master keys can be rotated without re-encrypting every record;
• the practical consequence is blast-radius containment. Compromising one user's key does not expose another user's data.

[CONFIRM: where the master key is held, and whether it is held in a hardware security module or a managed key service. This materially affects the security representation and the transfer impact assessment.]

9.2 Authentication

• Passwords are stored as bcrypt hashes. We never store, log or transmit your password in a form we can read.
• Registration requires email verification by one-time code and phone verification by one-time code.
• Cloudflare Turnstile guards signup, login and password reset against automated abuse.
• Rate limiting and throttling are applied to all authentication endpoints.
• Session cookies are HttpOnly, restricted by SameSite, and in production are marked Secure and use the __Host- or __Secure- cookie name prefixes. See the Cookie Policy.

9.3 Administrative separation

• Staff and administrator accounts are a separate authentication realm from customer accounts. An admin account is not a customer account with a flag set.
• Two-factor authentication using a time-based one-time password (TOTP) is mandatory for administrator accounts.
• Administrator sessions are short: 120 minutes idle, 12 hours absolute.

9.4 The audit log

We maintain a tamper-evident, hash-chained administrative audit log. Each entry incorporates a cryptographic hash of the preceding entry, so that removing or altering a historical entry breaks the chain and is detectable. The point is not that the log cannot be attacked, it is that an attack on the log leaves a mark.

9.5 Access transparency

Every decryption of your data by a member of staff is logged individually, and generates a privacy_events record that you can see. This is set out in full in section 10 below.

9.6 What we do not claim

We do not claim our systems are unbreachable, because no one can. We describe what we have built so that you can judge it. If you believe you have found a vulnerability, please contact [CONFIRM: security contact address, and whether a responsible disclosure policy exists].

10. Staff access to your body data

This section exists because we think you are entitled to a straight answer to the question "can someone at your company look at my photograph?".

10.1 The answer

Yes, in narrow circumstances, and only under controls that we can prove operated.

10.2 When it can happen

Staff access to encrypted user data requires an approved, time-boxed access grant. A grant records who is asking, what they want to access, why, who approved it, and when it expires. It is not a standing permission. [CONFIRM: the maximum grant duration configured.]

The circumstances in which a grant would be sought are:

• you asked us for support with a specific try-on and we cannot help without looking;
• you asked us to review an automated fit result under section 6.3;
• we are investigating a security incident, fraud, or abuse of the service;
• we are responding to a legal demand we are required to comply with;
• we are investigating a genuine defect that we cannot reproduce any other way.

[CONFIRM: whether this list matches the operational reality and the approval policy.]

10.3 The two-person rule

For body measurements, photographs and try-on outputs, an access grant must be approved by a second, different member of staff. One person cannot self-approve access to your body data. This is the strongest control we operate and it applies specifically to the most sensitive categories.

10.4 Every decryption is logged

Each individual decryption event is logged separately. The log records the access, not the content. Access grants and decryption events feed the hash-chained audit log described in section 9.4.

10.5 You will see it

When a member of staff decrypts your data, a privacy_events record is generated for you. You can see that record in your account. [CONFIRM: the in-product location, and whether the record is pushed to you by email or notification as well as being visible on request. A record you have to go looking for is weaker than one you are told about.]

We are aware of one honest limitation: if we are compelled by law not to disclose a particular access, for example under a non-disclosure order accompanying a legal demand, we may be legally barred from generating a visible record at that time. [CONFIRM: whether the system can suppress a privacy_events record, who can authorise that, and whether the suppression itself is logged. If it cannot be suppressed, say so, because that is a stronger commitment.]

11. International transfers

11.1 Where your data goes

[CONFIRM: the definitive list. On current assumptions, personal data is processed in the United States by the AI provider, by Cloudflare, and by Whop, and in a location yet to be chosen for hosting and object storage.]

11.2 The mechanisms we rely on

For transfers of personal data out of the EEA, the UK or Switzerland, we rely on one of the following, recorded per processor in the register at section 7.6:

11.3 Transfer impact assessments

Following Data Protection Commissioner v Facebook Ireland and Schrems (Case C-311/18), where we rely on Standard Contractual Clauses or the UK Addendum we carry out a transfer impact assessment before the transfer begins, and record its reference against the processor in our register. The assessment considers the laws of the destination country, the practical likelihood of government access to the specific data at issue, and the supplementary measures in place.

Our position on supplementary measures for body data is that envelope encryption with per-user keys, combined with face suppression, is a material supplementary measure, because the volume of data exposed by any single key compromise is one user, and because the data sent to the AI provider is de-identified to the extent face suppression achieves it.

[CONFIRM: this is an argument, not a completed assessment. A real TIA must be written for each transfer before launch. Note in particular that a body photograph transferred to a US processor for real-time processing is not encrypted from that processor's point of view, since the processor must be able to see it in order to process it. Encryption in transit and at rest does not answer the government-access question for data in use. Counsel should assess whether zero-retention materially reduces the government-access risk, which we believe it does, since there is no store to compel.]

12. Your rights

12.1 The rights themselves

Which of these you have depends on where you live. The annexes in Part C set out the position for each jurisdiction. The mechanism is the same for all of them.

12.2 How to exercise them

12.3 Verification

Before we act on a request about a specific account we have to be reasonably sure it is you asking. Normally, being signed in to the account is sufficient. For a request that would disclose body data, or that would be irreversible, we may ask for additional confirmation, for example confirming a code sent to your verified email address or phone number. We will not ask you for new categories of personal data in order to verify you, and any data collected purely for verification is used only for that and then deleted.

If we cannot verify you, we will tell you why, and we will not simply ignore the request.

12.4 Deadlines

Where deadlines differ, we apply the shortest one that applies to you.

12.5 Cost

Exercising your rights is free. Data export is always free. We may charge a reasonable fee, or refuse, only where a request is manifestly unfounded or excessive, in particular because it is repetitive, and if we do we will explain why and tell you how to challenge it (GDPR Art. 12(5); Cal. Civ. Code § 1798.145(g)(3); RCW 19.373.040(3)(b) permits a fee for the third and subsequent request in a twelve-month period).

12.6 Appeals

If we refuse a request, we will tell you why and how to appeal. [CONFIRM: the appeal address.] We will respond to an appeal within [CONFIRM: 45 days in Virginia, Colorado, Connecticut and most other US states; 60 days in Colorado for the appeal decision. Set a single internal standard of 45 days.] and, where the law requires it, we will give you a method to contact your state attorney general if the appeal is denied.

13. Children's privacy

The service is intended only for adults, and we require you to be at least [CONFIRM: MIN_AGE] years old.

This draft is written on the basis of 18. `[CONFIRM: material discrepancy. The .env.example file states a minimum age of 18. The running development configuration states 16. These lead to different legal outcomes:

• At 18+, we do not knowingly process children's data at all, the analysis is simple, and no parental consent machinery is needed.
• At 16+, GDPR Art. 8 is satisfied in every EU member state, since 16 is the maximum digital age of consent, but we would be knowingly processing the data of minors, which changes the UK position materially: the ICO's Age Appropriate Design Code applies to services likely to be accessed by children under 18, and would require a DPIA framed around children, high-privacy defaults, and age assurance proportionate to the risk. It would also make the Article 9 body data analysis considerably more sensitive, and would engage a number of US state laws on minors and on age-appropriate design. Resolve this before publication. See Notes for Counsel, item 1.]`

We do not knowingly collect personal data from anyone under the minimum age. We ask you to confirm your age at registration and record that confirmation. If we learn that we hold data from someone under the minimum age, we will delete the account and shred the key promptly.

If you are a parent or guardian and believe your child has created an account, contact [CONFIRM: email] and we will act on it.

We do not sell the personal data of minors and we do not seek opt-in consent to do so, because we do not sell personal data at all (Cal. Civ. Code § 1798.120(c)).

14. Data breaches

14.1 What we commit to

If a breach of security leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, your personal data, we will:

14.2 What we will tell you

A notice to you will describe, in plain language: what happened; which categories of your data were involved and specifically whether body photographs or body measurements were involved; the likely consequences; what we have done; what we recommend you do; and how to contact us.

14.3 The specific commitment on body data

If body photographs or body measurements are involved in a breach, we will notify affected users directly, regardless of whether a legal notification threshold is met. We do not want to be in a position of arguing about whether a body photograph breach is high risk.

Colorado law separately requires our biometric policy to contain a protocol for responding to a breach of biometric data (Colo. Rev. Stat. § 6-1-1314(1)(a)(III)). That protocol is in the Biometric and Body Data Policy.

15. Changes to this policy

We will update this policy when what we do changes. When we do:

• we will change the version identifier and the "last updated" date at the top;
• we will keep and publish previous versions, so you can see what changed [CONFIRM: whether a version archive will be published];
• for a material change, we will give you notice before it takes effect, by email to your registered address and by an in-product notice, and we will give at least [CONFIRM: 14 or 30 days] notice;
• where a change means we want to use your data for a new purpose not disclosed here, or collect a new category of data, we will ask for your consent first where the law requires it. For consumer health data this is not optional: RCW 19.373.020(3) prohibits collecting, using or sharing an undisclosed category or for an undisclosed purpose without first disclosing it and obtaining affirmative consent;
• your consent records store the policy version in force when you consented, so we can always tell which version you agreed to.

Continuing to use the service after a change takes effect does not, by itself, constitute consent to a new use of body data. We will ask separately.

16. Contact and complaints

16.1 Contact us

Please tell us first. We would rather fix something than have you find out from a regulator that we would not.

16.2 Your right to complain to a regulator

You can complain to a data protection or consumer protection authority. You do not have to contact us first, although we would appreciate the chance to put things right.

Part C. Jurisdiction annexes

Each annex is drafted to the specific content its own law mandates. Where an annex conflicts with Part B for a resident of that jurisdiction, the annex governs.

Annex A. European Economic Area, United Kingdom and Switzerland

Drafted to satisfy GDPR Articles 12 to 22 and Articles 13 and 14, and their UK GDPR equivalents.

A.1 Controller and representative

See sections 1.1 and 1.3. [CONFIRM: if we are not established in the EEA and we offer the service to people in the EEA, an Article 27 representative is mandatory unless the narrow Art. 27(2) exemption applies. It will not apply here, because the processing is not occasional and it includes data treated as special category on a large scale.]

A.2 Purposes and lawful bases

The complete table is at section 4. Every row states the Article 6(1) basis and the Article 9(2) condition.

A.3 Legitimate interests

Where we rely on Article 6(1)(f), our legitimate interests are: keeping the service secure and available; preventing fraud, abuse and automated attack; controlling the cost of AI inference; understanding how the product is used so we can improve it; and establishing, exercising or defending legal claims. We have documented a balancing assessment for each. You may ask for a summary of the assessment, and you may object under Article 21.

A.4 Special category data

We apply Article 9(2)(a) explicit consent to body photographs, derived body measurements, renders and fit reports, on a precautionary basis, for the reasons set out in section 5.2. Where a special category question arises in the context of a legal claim, we rely on Article 9(2)(f).

A.5 Consent, and the conditions on it (Art. 7)

• Consent is requested separately from the Terms of Service, and separately from account creation. Refusing does not stop you having an account.
• Consent is an affirmative act. There are no pre-ticked boxes.
• Consent is granular. You are asked separately for the body-data upload and for anything else that requires consent.
• Withdrawal is as easy as giving consent, and is available in the product at any time.
• We record what you were shown, including a SHA-256 hash of the exact consent text, its version, the surface, the mechanism and the locale, so that we can meet the Article 7(1) burden of demonstrating consent.

A.6 Automated decision-making (Art. 22)

See section 6, which sets out our position, the argument against it, and the Article 13(2)(f) and 15(1)(h) disclosures we make regardless.

A.7 Your rights

A.8 Transfers

See section 11. The mechanism per processor is in the register at section 7.6.

A.9 Data protection impact assessment (Art. 35)

A DPIA is required here. The processing involves data treated as special category, on a large scale, using new technology, including automated processing that evaluates personal aspects. It sits squarely within Article 35(3)(b) and within several criteria in the Article 29 Working Party DPIA guidelines (WP248rev.01), and it appears on the mandatory-DPIA lists published by several national supervisory authorities for processing of biometric or body-derived data.

[CONFIRM: a DPIA must be completed and documented before launch, and reviewed if the AI provider changes. If the DPIA identifies a high residual risk that we cannot mitigate, prior consultation with the supervisory authority under Art. 36 is mandatory.]

A.10 Records of processing (Art. 30)

We maintain an Article 30 record of processing activities. [CONFIRM: it exists and is current.]

A.11 UK specifics

The UK GDPR and the Data Protection Act 2018 apply on the same terms. For special category data the DPA 2018 Schedule 1 conditions may also be relevant, and an Appropriate Policy Document is required for certain Schedule 1 conditions. We rely on explicit consent, which does not require an Appropriate Policy Document, but [CONFIRM: whether we rely on any Schedule 1 condition that does, in particular for legal claims or for the prevention or detection of unlawful acts].

A.12 Switzerland

The revised Swiss Federal Act on Data Protection applies to Swiss residents on broadly similar terms. Biometric data that uniquely identifies a person is sensitive personal data under Art. 5(c)(4) FADP. Swiss residents may complain to the FDPIC.

Annex B. California

Drafted to satisfy the notice at collection and privacy policy requirements of the California Consumer Privacy Act as amended by the California Privacy Rights Act, Cal. Civ. Code §§ 1798.100, 1798.105, 1798.106, 1798.110, 1798.115, 1798.120, 1798.121, 1798.125, 1798.130 and 1798.135, and the CPPA regulations at 11 CCR §§ 7011, 7012, 7013, 7014, 7026, 7027 and 7102.

B.1 Notice at collection

Required by Cal. Civ. Code § 1798.100(a) and 11 CCR § 7012. This notice is given at or before the point of collection.

At or before the point at which we collect personal information from you, we tell you:

1. the categories of personal information we collect, and which of them are sensitive personal information;
2. the purposes for which each category is collected and used;
3. whether each category is sold or shared (it is not);
4. how long we intend to keep each category, or the criteria we use;
5. a link to this policy;
6. and, because we collect sensitive personal information, a link to our Notice of Right to Limit, at section B.7.

[CONFIRM: the notice at collection must actually appear at the collection point in the product, not only in this policy. A privacy policy link alone does not satisfy § 1798.100(a) at the point of collection. In particular, the body-photograph upload screen needs its own just-in-time notice. See Notes for Counsel, item 6.]

B.2 Categories of personal information, using the statutory names

Cal. Civ. Code § 1798.140(v)(1). The categories below use the statute's own lettered categories.

B.3 Sensitive personal information

Cal. Civ. Code § 1798.140(ae) and § 1798.121.

The sensitive personal information we collect is:

How we use sensitive personal information. We use it only to perform the service you asked for, to secure the service, and for the other purposes permitted by Cal. Civ. Code § 1798.121(a) and 11 CCR § 7027(m). We do not use or disclose it to infer characteristics about you. We do not sell it. We do not share it for cross-context behavioural advertising.

B.4 Sale and sharing

Cal. Civ. Code § 1798.115, § 1798.120, § 1798.130(a)(5)(C) and (D).

• We have not sold personal information in the preceding twelve months.
• We have not shared personal information for cross-context behavioural advertising in the preceding twelve months.
• We have not sold or shared the personal information of consumers we know to be under 16, and we do not knowingly serve anyone under [CONFIRM: MIN_AGE].
• We have disclosed personal information for a business purpose to the categories of service provider set out in section 7.6 and in the table at B.2.

B.5 The twelve-month disclosures

Cal. Civ. Code § 1798.130(a)(5).

In the twelve months preceding the date at the top of this policy:

[CONFIRM: if the service has not yet launched, this section should say so, rather than making twelve-month statements about a period in which nothing happened. Replace with "The service has not yet operated for twelve months. As at the date of this policy we have not sold or shared any personal information." once the launch date is fixed.]

B.6 Your California rights

Cal. Civ. Code §§ 1798.100, 1798.105, 1798.106, 1798.110, 1798.115, 1798.120, 1798.121.

B.7 "Do Not Sell or Share My Personal Information" and "Limit the Use of My Sensitive Personal Information"

Cal. Civ. Code § 1798.135 and 11 CCR §§ 7013 and 7014.

Statement made in reliance on § 1798.135(b)(3): We do not sell or share personal information, and we do not use or disclose sensitive personal information beyond the purposes permitted by § 1798.121(a).

B.8 Opt-out preference signals and Global Privacy Control

11 CCR § 7025.

We honour opt-out preference signals, including the Global Privacy Control (GPC), as a valid request to opt out of the sale and sharing of personal information. We process the signal frictionlessly, without requiring you to create an account, provide additional information, or navigate a further interface, and we apply it to the browser or device from which it is sent, and to your account if you are signed in.

Because we do not sell or share personal information, a GPC signal does not change what we do. We honour it anyway and we do not require you to prove anything to send it.

[CONFIRM: verify the front end actually reads navigator.globalPrivacyControl and the Sec-GPC header, and records the fact. A stated commitment we do not implement is a deceptive practice. Note that in August 2026 the CPPA voted to begin formal rulemaking to name GPC explicitly in the CCPA regulations, so this is likely to become an express requirement rather than an interpretation.]

B.9 Non-discrimination

Cal. Civ. Code § 1798.125.

We will not deny you goods or services, charge you a different price, provide a different level or quality of service, or suggest that we will, because you exercised a California privacy right.

We do not operate a financial incentive programme or a loyalty programme, so no notice of financial incentive under § 1798.125(b)(2) is required.

One honest note: if you withdraw consent to body data processing, or delete your body data, we cannot produce a fit result for you, because we would have nothing to measure against. That is a direct technical consequence of the data no longer existing, not a penalty, and it is expressly permitted by § 1798.125(a)(2), which allows a difference in service where it is reasonably related to the value provided by the consumer's data. All other parts of your account continue to work.

B.10 Retention

Cal. Civ. Code § 1798.100(a)(3).

We do not keep personal information for longer than reasonably necessary for the purpose disclosed. The retention period for each category is in the table at B.2 and in the schedule at section 8.1.

B.11 Authorised agents

11 CCR § 7063.

You may use an authorised agent to make a request. We will ask for:

1. written permission signed by you authorising the agent to act, or a power of attorney under Cal. Prob. Code §§ 4000 to 4465;
2. verification of the agent's own identity; and
3. verification of your identity directly with us, unless a power of attorney is provided.

We may deny a request from an agent who cannot provide these.

B.12 Metrics disclosure

11 CCR § 7102.

The metrics disclosure requirement applies to a business that knows or reasonably should know that it buys, receives for commercial purposes, sells or shares the personal information of 10,000,000 or more California residents in a calendar year.

We are not such a business, and we do not sell, share or buy personal information at all. Accordingly no metrics disclosure is required. [CONFIRM: revisit if scale changes.]

B.13 California "Shine the Light"

Cal. Civ. Code § 1798.83.

We do not disclose personal information to third parties for their own direct marketing purposes. California residents may request confirmation of this once per year by writing to [CONFIRM: address].

B.14 Notice regarding CIPA and session recording

[CONFIRM: whether any session replay, chat widget, analytics pixel or third-party script that observes user interaction is in use. There is active California Invasion of Privacy Act, Cal. Penal Code § 631, litigation about such tools. On the current facts we believe none is in use, but this must be verified against the shipped front end.]

Annex C. Washington Consumer Health Data Privacy Policy

Drafted to satisfy RCW 19.373.020. This annex must be published as a separate, standalone page with its own prominent link on the homepage, distinct from the general privacy policy link. RCW 19.373.020(2) requires a regulated entity to prominently publish a link to its consumer health data privacy policy on its homepage, and the CPPA of Washington's position, and the prevailing practice, is that a section inside a general privacy policy does not satisfy this.

This annex also serves as our disclosure under the Nevada consumer health data law, Nev. Rev. Stat. ch. 603A as amended by SB 370 (2023), which imposes closely parallel obligations on regulated entities collecting consumer health data about Nevada consumers.

C.1 Plain-language summary

We estimate your body measurements from a photograph you upload, so that we can tell you how a garment will fit. Washington and Nevada law treat body-derived data of this kind as consumer health data. This page tells you exactly what we collect, why, who sees it, and how to make us stop and delete it. We do not sell it, and under Washington law we could not sell it without a signed authorisation from you, which we will never ask for.

C.2 Categories of consumer health data collected

RCW 19.373.020(1)(a).

We do not collect: health conditions, diagnoses, treatments, medications, symptoms, surgeries or procedures; reproductive or sexual health information; gender-affirming care information; genetic data; precise location information that could reasonably indicate an attempt to acquire health services; or data purchased from third parties.

C.3 The purposes for which we collect and use it

RCW 19.373.020(1)(a).

1. To estimate your body measurements from your photograph.
2. To compare those measurements against a garment's real measurements taken from the brand's published size chart.
3. To produce a written fit assessment by body region.
4. To render an image of the garment on you.
5. To let you correct a measurement and re-run the assessment.
6. To secure the service and prevent abuse of it.
7. To respond to you when you ask us for support about a specific result.
8. To comply with law and to establish, exercise or defend legal claims.

We do not use consumer health data for advertising, for profiling unrelated to fit, to infer health conditions, to train AI models, or for any purpose not listed above. Under RCW 19.373.020(3) we may not use it for a purpose not disclosed here without first disclosing the purpose and obtaining your affirmative consent, and we will not.

C.4 The categories of sources from which it is collected

RCW 19.373.020(1)(b).

We do not buy consumer health data. We do not obtain it from data brokers, from other apps, from advertising networks, from your social media, or from any source other than you and our own derivation from what you gave us.

C.5 The categories of consumer health data that are shared

RCW 19.373.020(1)(c).

Note on terminology: RCW 19.373.010 defines "share" broadly enough to capture disclosure to a processor. We disclose the above on that basis, for completeness, even though these parties act only on our instructions and cannot use the data for their own purposes.

We do not share consumer health data with advertisers, data brokers, analytics providers, insurers, employers, marketers, or anyone else.

C.6 The specific third parties and affiliates with whom it is shared

RCW 19.373.020(1)(d). Washington requires a list of specific parties, not merely categories.

Cloudflare, our SMTP provider, our SMS provider and Whop do not receive consumer health data. They receive account, session and billing data only.

C.7 How to exercise your rights

RCW 19.373.020(1)(e) and RCW 19.373.040.

The first two requests in any twelve-month period are free. We may charge a reasonable fee for the third and subsequent requests, or for manifestly unfounded or excessive requests (RCW 19.373.040(3)(b)).

Notification of deletion downstream. If you ask us to delete, we will notify our processors of the deletion request, and we will delete the data from all our systems including backups, in accordance with RCW 19.373.040(1)(c)(i) to (iii).

C.8 Consent

RCW 19.373.030.

We collect your consumer health data only after obtaining your affirmative consent, given freely, and separately from any other agreement. Before you consent we tell you:

• the categories of consumer health data to be collected;
• the purposes for the collection, including the specific ways it will be used;
• the categories of entities with whom it will be shared; and
• how you can withdraw consent.

Consent to collection and consent to sharing are requested separately and distinctly, as RCW 19.373.030(1) and (2) require. Consent is not obtained by a pre-ticked box, by acceptance of a general terms of use, by hovering, muting, pausing or closing a piece of content, or by any other means that is not a clear affirmative act.

We record the consent, including the SHA-256 hash of the exact text you were shown, its version, where in the product it was shown, the mechanism by which you gave it, the locale, and the time.

C.9 Sale of consumer health data

RCW 19.373.050.

We do not sell consumer health data, and we will not.

Washington law makes it unlawful to sell consumer health data without a valid, signed authorisation containing the elements set out in RCW 19.373.050(2). We do not seek and will never seek such an authorisation. If that position ever changed, it would require a specific, separate, signed authorisation from you, we could not condition the service on your signing it, you could revoke it, and it would expire after one year.

C.10 Geofencing

RCW 19.373.060.

We do not use geofences. We do not implement a virtual boundary around any health care facility, and we do not use location to identify or track anyone seeking health services, to collect consumer health data, or to send anyone health-related advertising.

C.11 Enforcement

A violation of the My Health My Data Act is an unfair or deceptive act under the Washington Consumer Protection Act, RCW ch. 19.86 (RCW 19.373.900), which is enforceable by the Washington Attorney General and by private action.

C.12 Nevada

Nevada's consumer health data law (Nev. Rev. Stat. ch. 603A, as amended by SB 370 (2023)) imposes closely parallel obligations: a distinct consumer health data privacy policy, affirmative consent before collection and separate consent before sharing, rights of confirmation, access, deletion and withdrawal, and a prohibition on selling consumer health data without a signed authorisation. This annex is our Nevada consumer health data privacy policy as well as our Washington one. Nevada does not create a private right of action; enforcement is by the Nevada Attorney General.

[CONFIRM: there are drafting differences between the two statutes, notably in the definitions of "regulated entity" and "consumer" and in the geofencing provisions. Counsel should confirm that a single combined policy is acceptable, or split it into two pages.]

C.13 Contact

[CONFIRM: dedicated contact route for consumer health data requests.]

Annex D. Other United States states

Covering the state comprehensive privacy laws in force. This annex addresses only the differences that matter. Everything else is in Part B.

D.1 Which states this annex covers

Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Texas (TDPSA), Oregon, Montana, Florida, Delaware, Iowa, Nebraska, New Hampshire, New Jersey, Tennessee, Minnesota, Maryland (MODPA), Indiana, Kentucky, Rhode Island, and any further state law in force at the date of this policy.

[CONFIRM: the exact list in force at publication, and whether we exceed each state's applicability threshold. Most thresholds are based on the number of residents whose data is processed, commonly 100,000, or 25,000 combined with deriving revenue from the sale of personal data. Several states, notably Texas and Nebraska, have no numeric threshold and apply to any business that is not a small business under the federal Small Business Administration definition. Colorado, Maryland, Oregon and several others have lower thresholds for **sensitive data**. Because we process data that is sensitive in every one of these states, assume coverage.]

D.2 The rights, which are broadly common

Response deadline is 45 days in every state listed, extendable once by a further 45 days with notice, except that appeal decisions in Colorado are due within 45 days and in some states 60. [CONFIRM: we adopt a single internal standard of 45 days for requests and 45 days for appeals.]

D.3 Sensitive data consent

Every state in this annex except Utah and Iowa requires opt-in consent before processing sensitive data. Utah and Iowa require notice and an opportunity to opt out.

In all of these states, "sensitive data" includes biometric data processed for the purpose of uniquely identifying an individual, and, more importantly for us, personal data concerning a consumer's physical or mental health condition or diagnosis. We treat body measurements as falling within the sensitive data definition, and we take opt-in consent everywhere, which satisfies the stricter standard and also satisfies Utah and Iowa.

D.4 Data protection assessments

Colorado, Connecticut, Virginia, Texas, Oregon, Montana, Delaware, New Hampshire, New Jersey, Minnesota, Maryland, Nebraska, Rhode Island, Indiana, Kentucky and Tennessee require a data protection assessment for processing sensitive data, for targeted advertising, for sale, and for certain profiling. We process sensitive data. [CONFIRM: a data protection assessment must be completed and retained before launch. The GDPR DPIA at Annex A.9 can be structured so it also satisfies these state requirements, which most of the state statutes expressly permit.]

D.5 The state-specific points that actually matter

D.6 No private right of action

Except in Illinois under BIPA, in Washington under MHMD via the Consumer Protection Act, and in California for certain data breaches under Cal. Civ. Code § 1798.150, the state comprehensive privacy laws in this annex are enforceable only by the state attorney general. Several give a cure period before enforcement.

Annex E. Canada

Personal Information Protection and Electronic Documents Act (PIPEDA), and the provincial laws of Quebec, Alberta and British Columbia.

E.1 Consent

PIPEDA requires meaningful consent. Consent for sensitive information must be express, not implied. The Office of the Privacy Commissioner's Guidelines for obtaining meaningful consent require that we highlight, separately from a general policy: what we collect, who it goes to, the purposes, and the risk of harm. We do that at the point of the body-data upload, not only here.

Body photographs and body measurements are sensitive information. We take express opt-in consent.

E.2 The ten fair information principles

Our compliance with Schedule 1 of PIPEDA is as follows: accountability rests with the contact at section 16.1; purposes are identified at section 4; consent is addressed above; collection is limited to what is necessary; use, disclosure and retention are limited as set out at sections 7 and 8; accuracy is supported by letting you correct measurements yourself; safeguards are at section 9; openness is this document; individual access is at section 12; and challenging compliance is at section 16.2.

E.3 Quebec, Law 25

E.4 Alberta and British Columbia

Alberta's Personal Information Protection Act and British Columbia's Personal Information Protection Act apply to organisations operating in those provinces on broadly similar terms. Alberta requires notification to its Commissioner of a breach posing a real risk of significant harm.

Annex F. Australia

Privacy Act 1988 (Cth) and the Australian Privacy Principles.

F.1 Sensitive information

Biometric information collected for the purpose of automated biometric verification or identification, and biometric templates, are "sensitive information" under s. 6(1) of the Privacy Act. We do not collect for verification or identification purposes and we do not create templates. However, "health information" is also sensitive information and is defined broadly to include information about an individual's health, including their physical condition.

We therefore treat body photographs and body measurements as sensitive information, and we collect them only with your consent, as APP 3.3 requires.

F.2 The Australian Privacy Principles

F.3 Notifiable data breaches

Part IIIC of the Privacy Act requires assessment of a suspected eligible data breach within 30 days, and notification to the Office of the Australian Information Commissioner and affected individuals as soon as practicable where the breach is likely to result in serious harm.

F.4 Applicability

[CONFIRM: whether we carry on business in Australia and therefore fall within s. 5B of the Privacy Act. Note that from December 2024 the Privacy Act was amended to include a statutory tort for serious invasions of privacy, in force from June 2025, and the small business exemption is under active reform. Counsel should confirm the current position at the time of publication.]

Annex G. Brazil

Lei Geral de Protecao de Dados Pessoais, Lei No. 13.709/2018 (LGPD).

G.1 Sensitive personal data

LGPD Article 5(II) expressly lists biometric data as sensitive personal data ("dado pessoal sensivel"), and does so without the GDPR's "for the purpose of uniquely identifying" qualifier. The Brazilian definition is therefore broader than the European one, and our section 5.2 argument does not transfer.

We accordingly treat body photographs and body measurements as sensitive personal data in Brazil without argument. Under Article 11(I), processing requires specific and highlighted consent for specific purposes, given separately. Our consent flow meets that standard.

G.2 Legal bases

G.3 Your rights, Article 18

Confirmation of processing; access; correction; anonymisation, blocking or deletion of unnecessary or excessive data or data processed unlawfully; portability; deletion of data processed on consent; information about public and private entities with which we have shared data; information about the possibility of refusing consent and the consequences of refusal; and revocation of consent.

We respond to an access request in simplified form immediately, or in full within 15 days (Art. 19).

G.4 Automated decisions, Article 20

You have the right to request review of decisions taken solely on the basis of automated processing that affect your interests, including decisions intended to define your personal, professional, consumer or credit profile, or aspects of your personality. On request we will provide clear and adequate information about the criteria and procedures used, subject to commercial and industrial secrecy. See section 6.3, which discloses the logic in any event.

G.5 International transfers

Transfers out of Brazil rely on ANPD-approved standard contractual clauses under ANPD Resolution CD/ANPD No. 19/2023, or on your specific and highlighted consent to the transfer, or on another Article 33 basis. [CONFIRM: which mechanism, and note that the ANPD SCCs had a compliance deadline in August 2025.]

G.6 Data protection officer

LGPD Article 41 requires the appointment and publication of a data protection officer ("encarregado"). [CONFIRM: appointment and contact details.]

G.7 Breach notification

LGPD Article 48 requires notification to the ANPD and to affected data subjects. [CONFIRM: ANPD Resolution CD/ANPD No. 15/2024 sets the deadline at 3 working days from knowledge of the incident.]