OpenLoRA Cookie and Local Storage Policy
DRAFT FOR REVIEW — NOT YET EFFECTIVE. Draft version: 2026-10-29-v1.1. Effective date: [TO CONFIRM: publication and effective date].
OpenLoRA uses cookies and similar browser storage for the purposes below. The responsible operator is [TO CONFIRM: legal name and public address]. Contact: mail@openlora.org. This policy supplements our Privacy Policy.
1. Technologies and purposes
A cookie is information a website asks a browser to store and return with later requests. Local storage keeps information in that browser until removed by the website, you or browser settings; it does not have a built-in expiry. Similar legal rules can apply to both technologies.
| Technology/name | Purpose | Persistence and control |
|---|---|---|
__Host-openlora_beta_session cookie | Maintain the server-managed session, protect authentication and associate requested actions with the right account | Secure, HttpOnly, SameSite=Lax, site-wide cookie. Anonymous sessions expire after 30 minutes idle or eight hours from creation. Signed-in sessions expire after 30 days idle or 90 days from sign-in, whichever comes first; the signed-in cookie can persist after the browser closes. Logging out ends the session. |
__Host-openlora_admin_return cookie | Return an administrator to invitation management after age confirmation or sign-in | Secure, HttpOnly, SameSite=Lax, site-wide; expires after ten minutes or is cleared when the return is completed or the user logs out. |
openlora.auth.changed local storage | Notify other tabs that account status changed so they recheck the server | Updated when account state changes; remains until overwritten or cleared; does not contain a Google password |
openlora.language local storage | Remember a language you choose | Until changed or cleared |
| Account/environment-scoped generation and payment request markers | Resume your requested work, reconcile status and reduce accidental duplicate submissions | Until completed/cleared by the relevant flow or cleared in browser storage; exact key suffixes can include an account and environment identifier |
| Server-side age/acceptance evidence associated with the existing session cookie | Record the age declaration, policy version and registration acceptance | No separate age cookie or browser storage key. Session evidence follows the current session lifetime above; account acceptance is stored server-side. [TO CONFIRM: retention of account evidence and infrastructure records] |
| Hosting, security and identity-provider technologies | Deliver and protect the service or complete a sign-in you choose | [TO CONFIRM: inventory actual names, domains, purposes and lifetimes from production and provider settings] |
Language memory and task markers must be assessed for their actual function and local consent rules. Being first-party or described as useful does not automatically make storage strictly necessary.
2. Choices and consent
Storage strictly necessary for a service you explicitly request may be used without consent where law permits. Where consent is required for optional storage, it must be obtained before that storage is set or accessed. Optional categories must start off; rejecting them must be as easy as accepting them, and withdrawing a choice must be possible without losing unrelated functionality.
The intended launch policy is not to add advertising or optional analytics trackers. [TO CONFIRM: source inspection found no familiar analytics tags, but a production browser/network and infrastructure audit is still required. Do not advertise an all-essential/no-banner conclusion until that audit and local assessment are complete.] If optional tracking is introduced later, this policy and an effective preference control must be provided before it starts. Agreement to service terms or an 18+ declaration is not cookie consent.
You can clear or block cookies and site storage in your browser. Doing so can sign you out, reset language choices and remove local recovery markers. Server task or accounting records are not deleted merely by clearing the browser. Before resubmitting a paid request, check its original status to avoid duplicates.
3. Third-party sign-in and signals
When you deliberately continue to Google, its sign-in service may use its own cookies and notices. An external identity provider's practices should not be described as OpenLoRA's own cookie inventory. Embedded third-party tracking, if ever introduced, requires its own assessment and choices.
We will honor browser privacy signals where law requires and where relevant processing occurs. Do Not Track and legally recognized universal opt-out signals are different mechanisms; neither a blanket claim of universal support nor a blanket disregard is appropriate without checking the actual implementation.
4. Updates and questions
We will update this policy when the technologies or purposes change. For questions, an accessible explanation or a storage/consent complaint, contact mail@openlora.org. The Privacy Policy explains personal-information rights and requests.