Four Categories and the Cost of Refusing Each
This document is a working structure dated 29 October 2026 and is not final. It is replaced by the operator’s own policy once the brand agreement is signed, or by a lawyer’s adaptation.
1.1. This policy defines the operational classifications, lifecycle durations, and governance protocols applicable to local data storage mechanisms deployed across the platform. The platform categorises small data files stored on the client terminal into four distinct functional tiers, each performing specific technical or operational assignments.
| Category | What it does | Can you switch it off | What breaks if you do |
|---|---|---|---|
| Strictly necessary | Maintains session security, client authentication states, and system load distribution | No | Account sign-in, protected transactions, and session navigation fail entirely |
| Functional | Stores client interface preferences, including language selection, volume states, and lobby filters | Yes | Display preferences, search filtering history, and balance formatting reset on page refresh |
| Analytics | Measures navigation paths, error frequencies, latency, and feature usage across sessions | Yes | No platform functionality breaks; data reporting ceases for that client session |
| Advertising | Tracks conversion attribution, incoming promotional links, and campaign performance indicators | Yes | No platform functionality breaks; outbound referral metrics cease reporting |
1.2. Strictly necessary mechanisms remain permanently active during user interaction with platform interfaces. These files execute cryptographic session management, maintain user authentication tokens across server requests, and ensure balance integrity between transaction calls. Deactivation of strictly necessary items via third-party browser interventions renders account access, verification uploads, and cashier routing non-functional, as the platform cannot maintain state security across disparate endpoints.
1.3. Functional storage elements retain user-selected configuration parameters across consecutive requests. When a user configures view filters in the gaming catalogue or adjusts audio thresholds within software products, functional keys preserve these settings within client storage. Terminating functional storage mechanisms forces the user interface to return to baseline defaults upon every navigation event, requiring manual reselection of all session preferences.
1.4. Analytics and advertising files evaluate technical system health, page transfer velocities, and acquisition channel provenance. These records do not facilitate real-time access control or transaction clearance. Restricting analytics or promotional identifiers produces no adverse effect on interactive gaming, balance management, document verification procedures, or payment dispatch, operating entirely independently of core transaction processing.
Cookie Inventory
2.1. The provisional registry below documents the standardised technical definitions, persistence metrics, and administrative designations applied across web assets. The table sets out each cookie group by its operational purpose rather than by file name; the exact technical names are reconciled with the site’s actual scripts before publication, ensuring complete operational correspondence between server headers and this published policy.
| Cookie group | Category | Purpose | Lifetime | Origin |
|---|---|---|---|---|
| Session identifier | Strictly necessary | Preserves encrypted player session identifier and sign-in state | Session | First-party |
| Request-forgery token | Strictly necessary | Prevents cross-site request forgery attacks on account forms | Session | First-party |
| Load-balancing marker | Strictly necessary | Manages server routing and load balancing distribution | 24 hours | First-party |
| Interface preference record | Functional | Stores client-selected lobby filter parameters and view preferences | 30 days | First-party |
| Language and locale preference | Functional | Retains language preferences and cashier presentation flags | 365 days | First-party |
| Analytics identifier | Analytics | Records navigation latency, page transition durations, and interface errors | 90 days | First-party |
| Attribution identifier | Advertising | Documents inbound partner attribution and initial landing tags | 30 days | First-party |
2.2. Identifier classification adheres to strict functional containment. Session-bound items marked under first-party origin terminate automatically upon closing the client software interface or completing an explicit account log-out procedure. Persistent identifiers, by contrast, remain retained within the local user filesystem until expiration of the designated lifetime duration or manual purging by the user.
2.3. The designated lifetimes represent upper retention boundaries. No functional or performance item remains stored beyond the stated calendar window without receiving fresh timestamp updates resulting from deliberate user engagement. First-party identifiers are scoped strictly to the platform domain, precluding cross-domain execution, lateral tracking across unrelated commercial websites, or external extraction of local data stores.
2.4. Third-party inclusions necessary for game engine loading, streaming feeds, and financial transaction interfaces may introduce transient technical tokens within secure frames. These external data keys remain confined to the specific operational window required by the active software component and do not bridge into general account tracking or peripheral profiling operations.
Changing or Withdrawing Consent
3.1. Users maintain the right to adjust, withdraw, or re-establish preferences regarding non-essential storage categories at any juncture. Initial preferences recorded via the consent interface may be revised through the account settings portal, where functional, analytics, and advertising categories can be enabled or disabled individually.
3.2. Browser-level controls provide an additional, independent mechanism for managing local storage items across all web interactions. In Google Chrome, users manage local storage permissions via the Privacy and Security sub-menu under Site Settings, where files can be viewed, blocked, or deleted on a domain-specific basis. In Apple Safari, storage policies are configured through Preferences under the Privacy tab, allowing users to block local files entirely or inspect and delete cached data per domain. In Mozilla Firefox, local records are governed under the Privacy and Security panel within the Cookies and Site Data section, permitting custom exceptions, automatic deletion upon exit, or global blocking.
3.3. A fundamental technical distinction exists between clearing browser-stored files and updating recorded service-side consent. Manually purging cookies within client software removes local data files from the current device but does not alter the formal consent register stored in platform account records; upon subsequent visits, the platform may present a fresh consent prompt or re-apply default system values. Conversely, toggling consent settings within the platform interface instructs backend services to cease reading or dispatching future non-essential files, but does not automatically excise legacy files already deposited in the local browser cache. Comprehensive configuration requires updating preferences within account settings followed by a manual cache clearance within the client browser.
3.4. Restricting technical storage parameters through global browser commands may impair critical security tokens. Disabling local storage indiscriminately disables the transmission of the cross-site request forgery token and the authentication header, resulting in immediate termination of the active user session and preventing the submission of registration, deposit, or document verification requests.