COOKIE POLICY Last updated: August 25, 2026 1. PURPOSE AND SCOPE This Cookie Policy explains the cookies, local storage, session storage, authentication persistence, service-worker caches, and similar browser technologies used on pages controlled by DeCode. Cookies are not the same as every other browser or payment technology. This Policy identifies local storage, session storage, caches, redirect links, payment tokens, and server logs separately where that distinction matters. When a user leaves DeCode for a separately hosted sign-in, connector, checkout, receipt, or customer-portal page, that provider controls the technologies on its page under its own privacy disclosures. 2. CURRENT PAYMENT-BROWSER IMPLEMENTATION The current DeCode integration uses Creem for eligible payment flows: - DeCode creates a Creem Checkout session on its server and redirects the top-level browser to Creem's separately hosted checkout; - Settings → Billing → Customer Portal or Add or edit requests a Creem portal link from the DeCode server and then performs a full-page redirect; - a billing profile identified as Creem is redirected to the separately hosted Creem Customer Portal; and - DeCode does not load a Creem checkout SDK, checkout script, overlay, or embedded checkout on a DeCode-controlled page. 3. ESSENTIAL AUTHENTICATION STORAGE DeCode configures Firebase Authentication to use browser-local persistence so that an authenticated session can continue across page loads and browser restarts where the browser permits it. Firebase Authentication and an enabled sign-in provider may use tokens, browser storage, or provider-hosted cookies needed to complete sign-in and maintain the session. Passkey authentication uses the browser's WebAuthn interface and the device or password manager selected by the user. A passkey private key and local biometric verification remain with that device or provider. Authenticator-app codes and email verification codes are submitted for server-side verification and are not stored as persistent DeCode preferences. Blocking authentication persistence may prevent sign-in, cause repeated sign-outs, interrupt password reset or verification, or prevent sensitive Account actions. 4. ESSENTIAL SECURITY TECHNOLOGIES DeCode loads Cloudflare Turnstile on login, signup, and public support forms to verify that a request is not automated. Turnstile may use browser and network information needed to perform that security check under Cloudflare's own disclosures. DeCode sends the resulting short-lived verification token to the server for validation. DeCode also uses server-side session records, rate limits, OAuth state checks, and billing authorization checks. Those server records are not cookies merely because they support a browser request. 5. DECODE LOCAL STORAGE DeCode's application code uses local storage for limited functional state, including: - the interface language and temporary language-sync state; - selected or default AI model and reasoning-effort preferences; - the selected realtime persona; - a random device-session identifier used to register and recognise a browser session; and - a user-configured Roblox Studio bridge address. The random device-session identifier is not a password, passkey private key, complete payment credential, or advertising identifier. These values generally remain until changed, replaced, or cleared in the browser. DeCode does not assign an invented fixed expiry period to them in this Policy. 6. DECODE SESSION STORAGE DeCode uses session storage for temporary browser-session state, including: - OAuth state, nonce, eligibility state, proof-key material, callback results, and callback errors for enabled sign-in or connector flows; - Roblox bridge or plugin session details; and - a one-time service-worker reset marker. Session storage is separate from cookies and is generally removed when the relevant browser session ends, although browser behaviour can vary. 7. SERVICE WORKERS AND BROWSER CACHE DeCode registers a service worker and may use browser caches for application files and assets. This supports loading and application behaviour; it is not used by the current implementation to build an advertising profile. Clearing the cache may require application files to be downloaded again. 8. CREEM HOSTED CHECKOUT REDIRECT When an authenticated user starts a new eligible subscription checkout, DeCode's server creates a Creem Checkout session and returns only the hosted checkout URL and limited session information needed for the redirect. The browser then leaves DeCode for a Creem-hosted page on creem.io or one of its subdomains. DeCode does not embed Creem checkout or load a Creem checkout SDK on the DeCode page. Creem controls the cookies, checkout session state, payment tokens, device or log data, and similar technologies used on its hosted page under Creem's Privacy Notice at https://www.creem.io/privacy. DeCode does not read or store complete payment-card numbers or card security codes from Creem checkout. Blocking technologies required on Creem's page may prevent checkout from loading or completing. 9. CREEM CUSTOMER PORTAL REDIRECT For a DeCode billing profile actually identified as Creem, DeCode's authenticated server sends the stored Creem customer identifier to Creem's billing API, receives a generated Customer Portal link, returns that link to the browser, and redirects the top-level page to a separately hosted creem.io page. The current frontend does not embed that portal in an iframe and does not load a Creem browser SDK or Creem checkout script on the DeCode page. DeCode does not claim that Creem sets a cookie on decodeai.net merely because the user can follow this redirect. Once the user reaches a Creem-controlled page, Creem may use its own cookies, payment tokens, log data, device data, and Website Usage Data as described in Creem's Privacy Notice at https://www.creem.io/privacy. Creem's current Customer Portal flow is described at https://docs.creem.io/features/customer-portal. DeCode does not invent or publish Creem cookie names, domains, or expiry periods that the implementation does not establish. A generated Customer Portal URL provides authenticated access and should be treated as sensitive rather than placed in public pages or unrelated logs. Blocking technologies required on Creem's page may prevent the Customer Portal from working. 10. OTHER BROWSER-FACING PROVIDERS Depending on the feature deliberately used, a browser may interact with Google Firebase, Google sign-in, Microsoft sign-in, Cloudflare Turnstile, a user-authorised connector provider, or Creem Checkout and Customer Portal pages. Each separately hosted provider page applies its own privacy and browser-storage practices. External AI processing used by DeCode's server is not described as a browser cookie merely because an AI provider helps deliver a feature. 11. ANALYTICS AND ADVERTISING As of the date of this Policy, the current DeCode application does not initialize Firebase Analytics, a behavioural-advertising SDK, cross-site advertising profiles, third-party ad-network tags, or the sale of browsing behaviour to advertisers. A Firebase measurement configuration field by itself does not initialize analytics. Creem describes analytics and marketing cookies used on Creem's own Website in its Privacy Notice. That does not mean those Creem cookies are loaded on a DeCode-controlled page. DeCode may still process essential operational and security information, including request metadata, application errors, usage totals, fraud signals, and security events. Those server-side records are not automatically cookies or advertising tracking. 12. COOKIE NOTICE AND OPTIONAL CONSENT DeCode does not currently include a non-essential analytics or advertising cookie initializer, an optional-cookie preference center, or an accept/reject cookie banner. The absence of an optional-cookie rejection switch does not cause DeCode's essential account or billing functions to depend on acceptance of non-essential DeCode tracking, because no such tracking is currently enabled. If DeCode later adds browser tracking for which consent or another choice is required, DeCode will update this Policy and add the required controls before activating that tracking. Essential authentication, security, user-requested functional storage, and provider technologies needed to complete a requested checkout or portal visit may remain necessary for those functions. 13. BROWSER CONTROLS AND EFFECTS Users can clear or block browser storage through browser settings. Doing so may sign the user out, remove language or model preferences, break OAuth or connector callbacks, disable Turnstile checks, reset the Roblox bridge, reload cached assets, or prevent checkout or a customer portal from working. Clearing browser data does not delete the DeCode Account, server-side Memory, Credit balance, billing records, or subscription. Account deletion and subscription cancellation are separate actions described in the Privacy Policy and Cancellation Policy. 14. STORAGE DURATION Duration depends on the technology and purpose. Session-storage values are temporary browser-session state. DeCode local-storage preferences and the device-session identifier may remain until changed, replaced, or cleared. Authentication persistence may last until expiry, sign-out, revocation, or browser clearing. Cached files remain according to browser and service-worker cache behaviour. Creem applies its own retention practices to technologies and information it controls. See its current privacy notice rather than relying on an expiry period invented by DeCode. 15. PAYMENT AND SECURITY RECORDS THAT ARE NOT COOKIES For the current Creem flow, DeCode may record Creem checkout, order, Transaction, customer, subscription, Product, refund, dispute, and signed webhook-event identifiers and limited status, amount, currency, period, reconciliation, or security information. For a portal request, DeCode processes the Creem customer identifier and the fact that an authenticated user requested a portal link. These records support authentication, entitlements, billing access, fraud prevention, reconciliation, or support. They are server-side records, not browser cookies, and should not contain complete payment-card numbers or card security codes. 16. DO NOT TRACK Because DeCode does not currently use behavioural advertising as described above, browser "Do Not Track" signals do not change DeCode advertising behaviour. DeCode will review this position if its tracking practices change or a legally binding signal applies. 17. INTERNATIONAL PROVIDERS Some browser-facing Providers may process technical information outside the user's country. DeCode's Privacy Policy and each Provider's privacy notice describe their respective processing in more detail. 18. CHANGES DeCode may update this Policy when browser technologies, payment integrations, Providers, tracking practices, or law changes. 19. CONTACT Email: hello@decodeai.net Website: https://decodeai.net