Privacy policies are usually written by lawyers, for other lawyers, and read by no one. That is a problem, because the actual decisions that determine whether a game respects your privacy are not legal decisions — they are engineering decisions made long before the policy is published. This article is an attempt to explain ours in plain language: what we do, what we deliberately do not do, and why we believe the trade-offs are worth it.

The headline is simple. Every game on HKQS Games — from Smash Blocks to Puzzle Hex to Royal Match: King's Tale — can be played in full without creating an account, without logging in, and without accepting a tracking prompt. Your progress is saved locally on your device. We do not follow you across other websites. We do not sell any data, because we do not collect any data worth selling. The rest of this piece explains how that actually works, and where the few exceptions are.

Why We Made This Choice

The default model for free-to-play games, for most of the last decade, has been the opposite of this. Sign up, accept tracking, let the ad network build a profile of you, and in exchange get a "personalized" experience that is mostly personalized advertising. That model works commercially, which is why it became the default. But it has a cost that is rarely discussed: it treats the player as a resource to be measured rather than a guest to be entertained.

We built HKQS Games on a different premise. A casual puzzle player who shows up for five minutes during a lunch break is not asking us to remember them. They are asking us to entertain them and then let them leave. The most respectful thing we can do is exactly that — entertain them, and let them leave, without keeping a file on them. As the GDPR framework makes clear, data minimization is not just a legal best practice; it is the cleanest engineering posture, because data you never collect is data that cannot leak, be breached, or be misused.

The cheapest, safest, and most private database is the one you never built. Every record you choose not to store is a record no attacker can steal and no future policy change can compromise. — Maya Sari, privacy & platform lead

The Privacy Cost of Free Games

Free-to-play has been the dominant casual gaming business model for over a decade, and the cost of "free" is well documented. The Electronic Frontier Foundation's privacy work has tracked the long shadow of ad-supported mobile apps: cross-site identifiers, device fingerprinting, location tracking, and the steady accumulation of behavioral profiles that follow players across the web. The casual gaming category has been one of the most aggressive users of these techniques, because casual players are the least likely to push back.

The numbers are striking. According to Statista's mobile privacy data, the average free-to-play mobile game in 2024 transmitted data to an average of 17 third-party SDKs, with some titles integrating over 40. The same data shows that over 70 percent of those SDKs had at least some ad-targeting purpose, and roughly 35 percent transmitted data that the player had no reasonable way to know was being collected. The GDPR framework was designed precisely to push back against this default, but enforcement remains uneven and casual gaming is one of the categories where compliance is weakest.

The cost of "free"
17 SDKs

Average number of third-party SDKs integrated into a free-to-play mobile game in 2024, per Statista. Each SDK is a potential data pipeline. The privacy cost of "free" is paid in the silent accumulation of these pipelines — and the player usually never knows.

It is worth being honest about why this happened. Free-to-play is hard economics. Acquiring a player costs money, monetization per player is low, and the only way to make the unit economics work is to maximize the lifetime value of each player who does install. That pressure pushes publishers toward deeper data collection: more knowledge about the player means better ad targeting, which means more revenue per session, which means the math works. The model is internally coherent. The cost is externalized — onto the player's privacy, onto their attention, onto their trust in the broader category. Think with Google's marketing research covers the publisher side of this tension; the player side is what we care about.

The privacy cost of free games is not paid in money. It is paid in data the player did not know they were giving, in profiles they did not consent to, in trust they were never asked for. The question is not whether free games can be made without this cost — they can — but whether publishers are willing to do the work to make them that way. — Maya Sari, privacy & platform lead

What We Do Not Collect

It is easier to start with what we do not do, because the list is shorter and more meaningful.

The minimization test

Before any new feature ships, it has to pass a simple internal test: what data does this require, and can we build it without that data? If the answer is "we could build it without the data, but it would be slightly more convenient with it," the answer is always to build it without. Convenience is not a justification for collection.

What We Do Collect, and Why

We are not zero-data. A platform with absolutely no telemetry cannot fix bugs, cannot understand which games are failing to load, and cannot tell whether a change made things better or worse. So we collect a small, deliberately limited set of operational data, and we are explicit about what it is.

The data we collect is aggregated and anonymized at the source. We count how many sessions a game received, what type of device and browser was used (in broad categories, not unique identifiers), whether the session ended in an error, and roughly how long it lasted. None of this is tied to a personal identity, because there is no identity to tie it to — there is no account. The purpose is purely operational: to know whether the site is healthy and whether the games are loading. This is the kind of telemetry the Electronic Frontier Foundation describes as privacy-respecting when it is aggregated, ephemeral, and not used for ad targeting.

How progress is saved without an account

This is the question we get most often. If there is no account, how does your progress persist? The answer is local storage in your browser. When you complete a level in Block Puzzle: Save Girl, the game writes your progress to your device's local storage. When you come back, it reads it back. The data never leaves your device, which means it cannot be lost in a breach on our end — but it also means it will not follow you to a new device unless you explicitly export it.

This is a deliberate trade-off. An account-based sync would be more convenient, but it would require us to hold your progress data centrally, which means protecting it, securing it, and being responsible for it. We chose the model that minimizes our custody of your data, even at the cost of some convenience. For the vast majority of casual players — who play on one or two devices and do not need decade-long progress archives — this is the right trade.

GDPR, CCPA, and the Compliance Reality

Privacy regulation has matured significantly over the past decade. The European Union's GDPR, California's CCPA and CPRA, Brazil's LGPD, and a growing list of state-level U.S. laws have collectively raised the floor for what "responsible data handling" means. The GDPR framework, in particular, introduced three principles that we treat as defaults rather than obligations: purpose limitation (data should be used only for the purpose it was collected for), data minimization (collect only what you need), and storage limitation (do not keep it longer than necessary). These principles are now treated as the global benchmark, even where they are not legally enforced.

The compliance numbers tell a story about how unevenly the industry has caught up. According to enforcement data tracked by the GDPR enforcement tracker, over €2.9 billion in fines had been issued across the EU by mid-2024, with the average fine for a serious infringement exceeding €30 million. The biggest categories of violation — inadequate legal basis for processing, insufficient transparency, and violating data subject rights — are precisely the categories that casual gaming publishers have historically struggled with, because their entire business model is built on processing behavioral data that is hard to justify under a strict legal basis.

Why we exceed the floor
0 requests

The number of "data subject access requests" we have to process per player, because we hold no personal data to begin with. GDPR Article 15 guarantees users the right to access the data a company holds on them. We sidestep the entire class of risk by holding nothing to access — a structural answer rather than a procedural one.

It is also worth being clear about what compliance does not guarantee. A platform can be nominally GDPR-compliant and still run a deeply invasive tracking operation, because consent dialogs and cookie banners can be designed to extract compliant-looking "yes" clicks without genuinely informed agreement. The Electronic Frontier Foundation has documented this pattern repeatedly: dark patterns in consent flows that push users toward "accept all" by making the alternative a four-step opt-out. Compliance is a floor, not a ceiling, and we treat it as such. Our choices are designed to satisfy the spirit of the regulations, not just the letter.

Compliance is the floor that the worst-behaved companies are forced to reach. The ceiling is what a company chooses to do when no one is watching. We are much more interested in the ceiling than in the floor. — Maya Sari, privacy & platform lead

How Advertising Works Here

Advertising is how the platform stays free, and we want to be honest about that. But the way advertising works on HKQS Games is deliberately constrained. We do not run the kind of programmatic ad networks that build cross-site profiles. The ads you see, where you see them, are not the result of tracking your behavior across the web. They are contextual — based on the page you are on, not the person you are.

Concretely, this means a few things. We do not use third-party cookies for ad personalization. We do not pass any identifier to ad partners that could be used to recognize you on another site. And we hold ad density to a level that does not break the game experience, because a privacy promise means little if the cost is an unplayable game. The GDPR's core principles — lawfulness, fairness, transparency, purpose limitation — are a useful checklist here, and we apply them even where we are not strictly legally required to.

The test we use is simple: if a player read exactly what we do with their data, would they still want to play? If the answer requires us to hope they do not read it, we are doing something wrong. — Internal privacy review standard, HKQS Games

Our Technical Approach to Privacy Engineering

A privacy promise is only as good as the engineering that backs it, and the engineering is harder than the policy. The web platform gives developers powerful tools for collecting data — third-party cookies, fingerprinting surfaces, device sensors — and the default behavior of most modern web frameworks is to use them. Privacy engineering is, in practice, the discipline of not using what you could. Web.dev's guidance on privacy-preserving web development describes the modern toolkit: Privacy Sandbox APIs, the SameSite cookie attribute, the Referrer-Policy header, and the gradual phasing out of third-party cookies that the industry is now in the middle of.

Concretely, our technical approach rests on five engineering choices, each of which has a measurable effect on what we can and cannot know about a player. The first is local-first storage: progress and preferences live in your browser's localStorage and never touch our servers unless you explicitly export a save. The second is no third-party cookies: we do not set them, and we set a SameSite=Lax policy on our own cookies to prevent implicit cross-site flows. The third is referrer policy restriction: outbound links carry rel="noopener noreferrer" and our Referrer-Policy is set to strict-origin-when-cross-origin, which means we do not leak the page you came from to destinations that have no business knowing it.

The five engineering choices

Five structural decisions, applied uniformly across the platform: (1) local-first storage, (2) no third-party cookies, (3) strict referrer policy, (4) no behavioral ad SDKs, and (5) ephemeral operational telemetry that is aggregated at the source and rolled off within days. None of these is novel — they are all standard web platform best practices — but applying them consistently is the difference between a privacy policy and a privacy practice.

The fourth choice — no behavioral ad SDKs — is the most consequential, because it is the one that most directly affects revenue. Behavioral ad networks pay more per impression, because they can carry targeted creative. Contextual ads pay less, because they only know what page you are on, not who you are. The Think with Google research library has published extensively on this gap and how the industry is trying to close it through Privacy Sandbox techniques like Topics and Protected Audiences. We watch this work closely, because if the contextual-versus-behavioral revenue gap narrows, the economic argument for behavioral tracking weakens — and that would be a structural win for player privacy across the entire web.

The fifth choice, ephemeral telemetry, is the one we revisit most often. We need some signal to know whether a game is loading correctly, whether a build is causing errors, and whether a feature is being used. The hard part is keeping that signal coarse enough that it cannot be reverse-engineered into a behavioral profile. We aggregate by hour, by country-level geolocation (no city, no postal code), and by broad device class (no unique identifiers). Records roll off after a fixed retention window. The EFF's guidance on telemetry treats this kind of coarse, ephemeral aggregation as acceptable, with the caveat that the line between "aggregated enough" and "still identifiable" is one that has to be re-examined as the surrounding data landscape evolves.

The hardest part of privacy engineering is not the choices you make once. It is the choices you keep making, every quarter, when a new feature lands with a perfectly reasonable argument for "just a little more data" — and you have to keep saying no. — Engineering review note, HKQS Games

What Happens When You Leave

Privacy is not just about what happens while you are playing. It is also about what happens when you stop. Because we do not hold an account for you, leaving is genuinely leaving. Clear your browser storage, close the tab, and from our perspective you were never here. There is no "deactivate your account" flow because there is no account to deactivate. There is no residual profile sitting in a database waiting to be breached. The relationship ends when you close the tab.

This is, again, a trade-off. If you want your progress to survive a device wipe, you have to manage that yourself — by exporting your local save, or by simply accepting that casual game progress is, in the grand scheme, ephemeral. We think that is the right posture for the kind of games we make. A five-minute puzzle does not need a permanent record. Treating it as if it does is where most of the privacy harm in casual gaming comes from.

A concrete number
0

The number of personal data fields we store on a typical player. No email, no name, no user ID, no device ID, no advertising ID. The only thing tied to your play session is a short-lived, anonymized telemetry record that expires within days and is never linked back to you.

The Limits of Our Promise

Honesty requires naming the limits. We do not control the browser you use, the operating system you run, or the network you connect through — each of which may collect their own data independently of us. We do not control the ad partners we work with to the level of auditing every line of their code, though we choose partners whose stated practices align with ours. And we cannot promise that a sufficiently determined adversary could never correlate anonymized telemetry, which is why we keep that telemetry as coarse and as short-lived as we do.

What we can promise is narrower and more honest: within the parts of the system we control, we have made — and continue to make — the choices that minimize what we know about you. When we change something material, we will say so here and in our privacy policy, not bury it in a terms update. If a future feature would require us to collect more, we will make that optional and explain the trade-off rather than defaulting you into it.

Industry Comparison: How We Differ

It is useful to compare what we do against what the rest of the casual gaming industry does, because the comparison makes the choices concrete. The dominant model in free-to-play casual gaming, as documented by Statista and other market research firms, is built on three pillars: mandatory account creation (used to build a player identity for cross-game progression and ad targeting), cross-app behavioral tracking (the device advertising ID, plus a network of SDK partners), and contextual ad inventory layered on top of behavioral targeting for incremental revenue. The first two are where most of the privacy cost lives.

According to Statista tracking of mobile gaming SDKs in 2024, the average free-to-play casual game integrated between 12 and 17 third-party data-sharing SDKs, with the top quartile integrating 25 or more. The four most common categories were: analytics (used by 92 percent of titles), ad attribution (used by 88 percent), crash reporting (used by 71 percent), and behavioral advertising (used by 67 percent). Of these, only crash reporting is structurally similar to the operational telemetry we run — and even there, our version is aggregated and ephemeral in a way that the standard SDK-based approach is not.

Where the cost accumulates
12-17 SDKs

The average number of third-party data-sharing SDKs integrated into a free-to-play casual game in 2024, per Statista. Against this, our platform integrates zero behavioral tracking SDKs. The trade is asymmetric: we give up the targeting revenue they generate, and in exchange we hold nothing that could leak.

The structural difference shows up most clearly in two operational metrics. The first is the size of the data footprint per player. A typical behavioral ad SDK in a free-to-play game transmits between 5 and 15 data points per session, including a stable identifier, device characteristics, app list signals, and increasingly precise location if the game requests it. Our per-session footprint, by contrast, is one coarse telemetry record with no stable identifier. The second is the retention window. The industry default for raw behavioral data is 90 to 400 days, because behavioral targeting gets more valuable with history. Our operational telemetry rolls off within days, because its purpose is purely to detect outages, and longer history adds no operational value.

The honest version of this comparison is that we are not claiming to be unique. There are other publishers — particularly in the indie and educational gaming space — who have made similar choices. What we are claiming is that the choices are concrete, the trade-offs are visible, and the implementation is auditable. A privacy promise is verifiable only to the extent that the engineering behind it is, and that is the standard we hold ourselves to.

Most privacy differences in this industry are differences of degree — fewer SDKs, shorter retention, slightly less invasive ad networks. Ours is closer to a difference of kind: no account, no tracking, no behavioral data. The cost is real. So is the ceiling. — Maya Sari, privacy & platform lead

Why This Matters for Casual Games Specifically

It is fair to ask why any of this matters for a five-minute puzzle. The answer is that the casual gaming audience is, by a wide margin, the least interested in being tracked and the least equipped to push back when they are. The player who installs a puzzle on their phone to relax during a commute is not reading privacy policies. They are trusting the platform to do the right thing by default. That trust is exactly what makes it important to do the right thing by default.

Most of the privacy harm in the casual gaming ecosystem does not come from overt malice. It comes from defaults — from the assumption that of course you will sign up, of course you will accept tracking, of course the ad network will follow you home. Changing those defaults is not a technical achievement. It is a series of small, deliberate choices, made over and over, to collect less than we could. That is the whole practice. We will keep making those choices, and we will keep explaining them, because a promise you cannot explain is a promise you cannot keep.