Information and where it lives
Browser-local information can include preferences, Local canvas boards, editor history, export history, imported media bytes, folders, and recovery data. It belongs to the current origin and browser profile.
Server information can include guest or linked-account identifiers, username, optional email and phone metadata, approved beta email addresses and Key IDs, server projects, revisions, Live state and events, creator submissions, installed package records, and security or service logs.
Current purposes
The application uses this information to provide editing, save and recovery, account access, sharing or export actions, Live event access, creator intake, abuse prevention, and service diagnostics.
No advertising network, behavioural ad profile, or data-broker integration is implemented in the current application. This draft does not make a legal conclusion about every statutory definition of sale or sharing.
Private beta access and measurement
When the private beta gate is enabled, an approved email is associated with a stable, non-secret Key ID. The service records allowlist changes, access-email requests, email-provider acceptance or failure, successful one-time-link verification, revocation, and coarse page-surface impressions so the operator can secure and evaluate the beta.
One-time link tokens are stored only as hashes and are not copied into activity records. Impression records use normalized surfaces such as the gate, Studio, or administration area; they do not store raw IP addresses, user-agent strings, referrers, query strings, full URLs, or project identifiers. Anonymous gate impressions use a rotating keyed digest and are not turned into cross-session profiles.
The application does not add an open-tracking pixel, session replay, or behavioural advertising identifier. A configured email provider receives the approved address, message content, and its Key ID tag in order to process the access message. Provider acceptance means the provider accepted the request; it is not represented as proof of inbox delivery.
Region, language, and browser detection
The current app can use browser language and timezone settings to suggest a regional presentation default. It does not request precise browser location, coordinates, or an IP-location lookup.
The regional preference retains only a resolved supported region and its detection source, not the raw browser signals. A user can choose a region manually. The preference is not proof of citizenship, residence, tax status, or governing law.
Retention and user choices
Browser-local information normally remains until the application or user removes it, the browser clears it, or the origin/profile is lost. Server projects and account-linked records remain until the applicable deletion path or an approved operational retention process removes them. Raw private-beta access and impression events are bounded to 90 days by default; an operator may configure 7 through 365 days. Revoked allowlist records retain the email and stable Key ID for audit continuity while their sessions and unused links are invalidated.
Production still needs verified access, correction, export, deletion, complaint, legal-hold, backup-expiry, and incident procedures for each launch region.
Security and contact
The application uses bounded inputs, origin checks, session controls, hashed one-time links and Live capabilities, revocable access keys, and fail-closed internal documentation. These controls reduce risk but do not guarantee security.
Do not send passwords, private keys, Live bearer values, or other secrets through an ordinary privacy request. The configured contact below must be replaced with a monitored production channel.
Regional review notes
These notes identify launch-review work; they are not legal conclusions. The app’s selected region is a presentation preference and does not establish residence, citizenship, governing law, tax position, or entitlement.
en-CA · CADFederal or substantially similar provincial privacy rules may apply depending on the operator, activity, province, and data flow. The production notice needs a named privacy contact and verified request process.
en-US · USDFederal sector rules and state privacy laws vary. A production notice needs a launch-state assessment rather than treating a United States preference as proof of residence.
en-GB · GBPThe production service needs a documented controller role, lawful-purpose analysis, retention schedule, rights workflow, processor inventory, and international-transfer review.
ja-JP · JPYThe production notice needs an APPI-specific review of purpose notices, cross-border handling, third-party provision, security, and request procedures.
en-NG · NGNThe production notice needs a Nigeria Data Protection Act assessment, a named controller/contact, verified rights handling, and cross-border processing review.
Operator and contact
Operator: Operator legal name not configured. Placeholder identity or contact values are a production launch blocker, not anonymous legal terms.
This draft should not be relied on as final assent, a waiver of mandatory rights, or a substitute for qualified advice in a launch jurisdiction.
Legal and privacy contact not configured