Privacy notice
Effective August 29, 2026 · public website scopeThe public site uses limited first-party measurement and keeps founding applications separate.
This notice describes the current public website, first-party launch measurement, founding applications, and restricted Platform Admin authentication. Future creator accounts, identity, asset, payment, transaction, and other higher-risk services will require additional notices and consent.
Information collected
The site records bounded visit context; an application adds only the information you choose to submit.
Depending on the application path, Image Rights Vault may collect a working or business name, email, optional phone number, broad service region, public portfolio links, role, interests, intended-use information, professional preferences, referral source, campaign code, and free-text responses. An application record also includes the application type, submission time, landing and submission paths, a limited external referrer reduced to origin and path, its hostname, and available UTM source, medium, campaign, content, and term values. Query strings and fragments are removed from the referrer.
The public forms do not request Social Security numbers, government identification, ID images, full birthdates, banking or payment information, precise street addresses, biometric information, private image libraries, or private source files. Please do not submit those items or place personal or confidential information in campaign links.
First-party launch measurement
Measurement uses bounded first-party events and pseudonymous browser and session values.
When Production launch measurement is enabled, the site records an allowlisted event name, a known public path and page category, optional audience or content category, server timestamps, a tab-scoped first-touch landing estimate, external referrer hostname, bounded client-supplied UTM source, medium, campaign, content, and term values, and a coarse mobile, tablet, desktop, or unknown category derived from request headers. Event-specific fields can include a CTA identifier and destination category; application kind, validation-error count, response status, and bounded error class; active foreground engagement seconds and page-depth percentage for Learn and audience pages; the fictional sample identifier; and named home-section views. A browser-generated event identifier is stored to prevent duplicate event inserts. Application names, email addresses, phone numbers, free-text responses, form values, keystrokes, and private evidence are not intentionally copied into analytics events.
After a measurement event is accepted, the server may set a random first-party visitor cookie for up to 30 days after the last accepted event and a random session cookie for up to 30 minutes after the last accepted event. On the public HTTPS site, these cookies are HttpOnly, Secure, and SameSite=Lax. Their raw values are hashed with a server-only salt before analytics database storage. The resulting counts estimate browsers and sessions; they do not identify unique people.
Tab-scoped browser session storage may remember a first-touch estimate consisting of the landing path, an external referrer reduced to origin and path, and available UTM values. It is not lifetime or person-level attribution and can span a different interval than the 30-minute analytics session cookie. Analytics receives the referrer hostname rather than the referrer path. If a person submits an application, bounded attribution may be stored with that application, but analytics visitor and session identifiers are not copied into the application row.
How information is used
Applications support founding-access review; measurement supports launch operations.
Image Rights Vault uses application information to assess fit, understand founding demand, identify possible participants or partners, prevent duplicate and abusive submissions, maintain a consent and review history, and contact applicants when an appropriate next step exists.
First-party measurement is used to estimate traffic and sessions, understand public content and application journeys, identify operational errors, and prepare private Platform Admin reports. It is not designed for advertising, sale of audience data, or cross-site profiling, and the checked-in launch code does not install a third-party advertising analytics SDK.
Submitting an application does not transfer copyright, likeness, publicity, portfolio, commercial, or AI rights. It does not initiate identity verification, create an account, collect payment information, or authorize use of an applicant's images or identity.
Storage and providers
Application, measurement, and private operational access have separate boundaries.
Application and analytics information is sent through same-origin server endpoints and stored with the Production database provider. Anonymous browsers cannot list application, analytics-session, analytics-event, or weekly-report rows and do not receive direct write access to those tables.
The private Platform Admin dashboard combines aggregate measurement with authorized application-pipeline information, including application references and display names. It is not a public analytics view. Longer-lived weekly reports store the generating administrator's user identifier, report dates and schema version, aggregate snapshots, repeated bounded dimension labels, and generated Markdown; they exclude the recent-applicant rows shown in the live private dashboard.
Hosting and database providers may process network metadata, including an IP address, cookies, and request headers, to deliver, secure, and troubleshoot the service. For endpoint abuse controls, the server may derive namespace-specific salted digests from a request address when available. Raw request addresses and raw user-agent strings are not persisted in application rows or analytics event and session rows; the user-agent string is reduced to a coarse device category for measurement.
Private administrator authentication
Restricted administrator sign-in and MFA use separate account records.
The Production administrator path may send a Supabase Auth sign-in link to an approved administrator email address and use provider session cookies to maintain the signed-in session. Public signup remains disabled. Application follow-up email is a separate capability and is not connected by this authentication path.
For privileged access, the authentication provider stores TOTP factor metadata and assurance state. Image Rights Vault stores a durable MFA status, verification time, and a salted evidence fingerprint derived from the administrator user and verified factor identifiers, together with restricted audit records. The public site does not expose the authenticator secret, factor identifier, session token, or durable MFA evidence.
After successful MFA reconciliation or an authorized dashboard visit, the application normally issues a one-year HttpOnly, Secure, SameSite=Lax analytics-exclusion cookie. Any analytics request that presents the expected exclusion value is ignored; the cookie itself is an exclusion flag, not proof of identity. Authentication alone does not set it, and earlier public browsing is not retroactively attributable to or removable as administrator traffic.
Sharing
Application information is not published or provided to an advertising network.
Application information may be accessed by authorized Image Rights Vault reviewers and by service providers that host or secure the website and database. It may also be disclosed to professional advisers, authorities, or another party when reasonably necessary to protect rights, comply with law, or address a security or legal issue.
Application rows and private measurement rows are not available to anonymous visitors. Public verification is separate and, at launch, contains only one unmistakably fictional sample record.
Security and retention
Controls reduce risk; they cannot eliminate it.
Current safeguards include same-origin endpoints, server-side validation, bounded event and data schemas, data-size limits, duplicate protection, honeypot and abuse controls, project pinning, restricted database functions, forced row-level security, safe error messages, and separation between Production and Staging. No internet service can promise absolute security.
Application records are retained while needed to review and respond to founding interest, protect the service, maintain consent and audit integrity, or meet legal obligations. Analytics session and event rows and Platform Admin weekly reports do not yet have an active deletion schedule. A retention review is registered, but deletion remains inactive until an operationally and legally reviewed schedule is approved and implemented. Short-window abuse-limiter entries are governed separately and stale entries are removed opportunistically. Administrator Auth and MFA evidence are not exposed through a public self-service deletion workflow.
Requests and future services
Privacy requests require a verified channel; public forms are not a substitute.
A dedicated public privacy-request channel and a public analytics preference control are not yet connected. Do not send a privacy request, identity document, or other sensitive evidence through a founding application. Keep any application reference you received and revisit this notice for a verified request channel. A future request may be limited when retention is required for security, legal obligations, or another person's rights.
Future creator accounts, identity verification, asset onboarding, licensing, payments, physical production, AI permissions, and other higher-risk services remain disabled. If any opens later, Image Rights Vault will provide additional notices, choices, and consents appropriate to the actual data flow.