Legal
Privacy Policy
Iris.Art turns biometric captures into music. This page explains, in specific terms, what we collect, how it's encrypted, who else touches it, and how to get it deleted.
Not legal advice. This document is a plain-language description of how Iris.Art actually works, written from the codebase rather than a template. It has not yet been reviewed by counsel — treat it as a working draft until it has been.
This Privacy Policy covers Iris.Art(“Iris.Art,” “we,” “us”), the biometric music platform at iris.art, its iOS and Android apps, and the REST API those apps use. By using any capture flow, you agree to the practices described here and to the versioned consent text you accept at /consent before your first upload.
What we collect, per modality
Iris.Art currently supports nine capture modalities. Each one collects a specific kind of raw biometric media, which our ML service turns into a set of documented, interpretable measurements:
| Modality | Raw capture | Example extracted features |
|---|---|---|
| Iris | Left/right eye close-up photographs | Crypt/texture pattern statistics, pupil-to-iris ratio |
| Periocular | Eye + surrounding region photograph | Derived from the same capture as iris (a paired fusion) |
| Voice | 3–30 second audio recording | Pitch, formants, spectral shape |
| Pulse | ~10 second smartphone-camera PPG video | Heart rate, heart-rate variability |
| Face | Facial photograph | Landmark geometry, proportion ratios |
| rPPG-face | ~15 second facial video | Remote-photoplethysmography heart rate, derived from the same capture as face |
| Handwriting | Photograph of a handwriting/signature sample | Stroke geometry, pressure-proxy metrics |
| Fingerprint | Photograph of all five fingertips (multi-finger) | Per-finger ridge pattern & density, democratically blended |
| Palmprint | Palm photograph | Palm-line geometry statistics |
We also collect ordinary account data (email address, OAuth provider identity from Google or Apple), payment metadata handled by Stripe (see Sub-processors), and device push-notification tokens if you enable notifications on mobile.
How a capture becomes a composition (and why that matters for privacy)
Iris.Art is built around a two-layer interpretability model, and it's relevant to privacy because it constrains what we can and can't do with your data:
- Layer A — deterministic, documented features. The measurements in the table above are computed with classical computer-vision equations, not opaque model inference. These equations, and the mapping from a specific measurement to a specific musical decision (a pitch, a rhythm, an instrument), are what the derivation table on your composition page shows you. The same capture, run through the same model version, always produces the same features and the same MIDI.
- Layer B — foundation-model embeddings, side-channel only. See the next section.
We do not use your biometric data for identity verification, surveillance, law-enforcement cooperation, advertising profiling, or any purpose other than generating the composition and report you asked for.
Layer B: foundation-model embeddings
In addition to the deterministic Layer A features, several modalities are also run through a pretrained foundation model (DINOv2 for iris, ArcFace for face, WavLM for voice, TrOCR for handwriting, plus a classical-bootstrap refinement pass for pulse) to produce a numeric embedding vector. These models run as ONNX Runtime inference on our own ML service — the image, audio, or video is not sent to the model vendor.
These embeddings are stored (append-only, versioned per model name and version) and used only as a side channel: nearest- neighbour comparison panels on your composition page, and groundwork for future style-conditioning features. An embedding never drives a musical decision directly — per the interpretability rule above, only Layer A does that.
Encryption at rest
Every raw biometric file — the photo, audio, or video you capture — is encrypted with AES-256-GCM before it is written to storage, using a per-record initialization vector. The encryption key is held server-side only; it is never shipped to the web client or to the mobile apps. Mobile captures are uploaded over HTTPS to our REST API and encrypted server-side on arrival, the same as a web capture.
Derived feature vectors and embeddings are stored in our database (not separately encrypted at the application layer — they sit behind Postgres row-level security so only the owning account can read them, plus the service-role access our own backend needs to run the pipeline).
DNA fusion (separate opt-in)
If you also have a DNA profile with our sibling product, LifeSong, on the same shared database infrastructure, you can optionally link the two. This is off by default and requires two separate steps: a per-account toggle at /account, and — the first time you turn it on — accepting a dedicated genetic-data consent (the current text is versioned; ask support if you'd like a copy).
When enabled, our composition worker reads and decrypts the relevant DNA-derived features from the shared database using a privileged service-role connection, extracts a small set of features, and applies a deterministic modulation to the composition. Genetic data is never sent to musicapi.ai, Google Gemini, or any other sub-processor — it stays inside our own infrastructure. The composition record stores which snapshot of your DNA profile and which algorithm version were used, so the same DNA plus the same biometric capture always produces the same result. Turning the toggle off stops future compositions from using DNA fusion; it does not retroactively alter compositions already generated.
Because DNA is subject to additional regulation in some jurisdictions (see Illinois, below), DNA-fusion endpoints are geoblocked separately from the rest of the product.
Retention
We do not currently enforce an automatic time-based deletion of your account, raw captures, or compositions — they are retained until you request deletion, or until an anonymous/sample composition's short-lived cache entry expires (this does not apply to captures tied to a real account). This is a deliberate product choice, not an oversight: your dashboard is meant to be a durable archive of everything you've made. If that changes, we'll update this section and the date above before it takes effect.
Deletion & erasure
You can request full account deletion from /account, or by emailing support@iris.art. Requesting deletion immediately signs you out and marks your account for erasure. A daily background job (it runs once every 24 hours) then:
- permanently deletes every encrypted raw biometric file you've ever uploaded from storage;
- deletes your account row, which cascades to your consent records, embeddings, compositions, and composition-to-sample links; and
- logs a hashed (not plaintext) record that an erasure occurred, for our own audit trail.
In practice this means deletion completes within roughly 24 hours of your request, not instantly — we tell you this explicitly in the deletion confirmation so the timing isn't a surprise.
Sub-processors
The following third parties process data on our behalf:
| Sub-processor | What it sees |
|---|---|
| Supabase | Encrypted raw biometric files, derived features, embeddings, account and consent records. This database is shared infrastructure across our products (Iris.Art plus two sibling products); each product's data lives in its own database schema. |
| Railway | Hosts our web app, worker, and ML service. Sees encrypted data in transit and at rest on its infrastructure. |
| Google (Gemini API) | Receives your raw, unencrypted capture file momentarily before the pipeline starts, to check that the right kind of capture was made (e.g., that an eye is actually visible and open, that handwriting is upright) and reject an obviously bad upload before it's encrypted and processed. If the guardrail is unavailable or misconfigured, uploads proceed without this check rather than being blocked. Processing of this data by Google is governed by Google's own API terms. Two modalities never reach it: pulse (numeric signal data, not an image) and rPPG-face (a video, checked downstream by our own ML service instead). |
| musicapi.ai | Receives only derived musical parameters (key, tempo, instrumentation, a text description) to render audio — never the raw biometric file or the extracted feature values themselves. |
| Stripe | Payment processing for the Pro subscription. Receives your email and payment details; never receives biometric data. |
| Expo | Delivers push notifications to the mobile apps using your device's push token. Does not receive biometric data. |
| Resend | Sends our transactional email — sign-up welcome, composition finished or failed, account-deletion confirmation, and both halves of a support conversation. Receives your email address and the contents of those messages, including anything you type into the support form. Never receives biometric data. |
| ipwho.is (IP geolocation) | Receives your IP address when you request a capture or consent page, or change the DNA-fusion setting, so we can resolve the region for the Illinois block described below. Our host sets no geolocation header of its own, so this lookup is what the block actually runs on. No other page triggers it, and it receives nothing but the IP address. |
Illinois (BIPA / GIPA)
The Illinois Biometric Information Privacy Act (BIPA) imposes specific written-consent, retention-schedule, and disclosure requirements on companies that collect biometric identifiers from Illinois residents, with a private right of action for violations. Rather than build a separate compliance track for Illinois, we currently block access to capture and consent flows for requests that our infrastructure identifies as originating from Illinois — you'll see an explicit message rather than a silent failure.
Because DNA fusion additionally touches genetic data, the Illinois Genetic Information Privacy Act (GIPA) applies there too, and the DNA-fusion toggle endpoints carry the same geoblock.
This block is based on network-level region signals and is not perfect — it can be wrong at the margins (VPNs, misreported headers). If you believe you were blocked incorrectly, or blocked while physically outside Illinois, contact support.
Other biometric privacy laws
Texas (CUBI), Washington (My Health My Data Act, for some health- adjacent inferences), and several other states have their own biometric or sensitive-data statutes, and more states are actively legislating in this area. We have not built a state-by-state compliance matrix for every one of them. If you have a specific concern tied to your state's law, tell us at support and we'll look into it directly rather than give you a generic answer here.
Your rights
Regardless of where you live, you can:
- Access & export — download a JSON archive of your account and every composition from /account (backed by
GET /api/account/export). For a read-only summary without downloading anything — your consent history and a per-modality count of the captures we hold — see Data & Privacy in your account. - Delete — request full account and data erasure from /account (backed by
POST /api/account/delete); see Deletion & erasure above for timing. - Withdraw consent — for biometric processing generally, withdrawing consent means requesting deletion (we don't currently support "pause processing, keep the account"). For DNA fusion specifically, you can revoke it independently at any time via the toggle at /account without deleting your whole account.
- Correct — if any account-level information (like your email) is wrong, update it via your OAuth provider or contact support; biometric feature values are derived facts about a capture, not editable fields.
We do not sell or share your personal information with third parties for their own advertising or marketing purposes.
Children
Iris.Art is not directed to children, and the consent flow at /consent requires confirming you are at least the age stated in the current consent text before any capture is accepted.
Changes to this policy
If we make a material change to this policy, we'll update the date at the top of this page. Continued use of Iris.Art after a change means you accept the updated policy. The biometric processing consent you accept at /consent is separately versioned (currently v1-biometric-processing) — a change there is tracked and re-prompted independently of edits to this page.
Contact
Questions about this policy, or a request to exercise any right above: support@iris.art or the support page.