The Cookie Protocol

A Methodological Note on Evaluation

Our approach to data collection via cookies is evaluated on three axes: necessity, transparency, and user agency. We treat every cookie as a potential system liability—a point of failure or a privacy risk. A cookie is only retained if it directly enables a core function (like maintaining your session during a ranked match) or provides anonymized, aggregated data that demonstrably improves app performance for all users.

The Robustness Test: If disabling a specific cookie class breaks the app's core functionality for an engaged user, its necessity is validated. However, if its absence only degrades a marginal feature (like a cosmetic preference), it moves to the optional tier. We audit our cookie set quarterly, mapping each to a specific engineering ticket. This isn't a "set it and forget it" policy; it's an active inventory.

The Limits: No system is perfect. We cannot guarantee that every cookie is strictly essential, as some may be required by third-party services we integrate (e.g., cloud save providers). For those, we require contractual guarantees of data minimization. Our primary constraint is always the user's hardware: we avoid cookies that inflate payloads or cause unnecessary network requests, as every byte matters on a mobile connection.