Consent changes mid-session and what quietly breaks

Consent handling in most games is a startup concern. The game launches, checks the stored consent state, configures what data flows accordingly, and proceeds.

That model assumes consent does not change during a session. It does — a player can open settings and withdraw it, or be prompted again after a policy change, or have it changed on another device — and the assumption is where problems accumulate.

What is already running when it changes

By the time a player withdraws consent mid-session, several things are in flight.

Events already queued locally, waiting to be sent. These were collected under consent and are about to be transmitted under withdrawal. Whether they should be sent is a real question with a real answer, and most implementations do not ask it.

Anything configured at startup based on the previous state. If a component was initialised with permission to collect, it generally keeps collecting until something tells it otherwise, and "something tells it otherwise" is the code path that usually does not exist.

Data already sent. Withdrawal is generally forward-looking, but a request for deletion is not, and the two arrive through the same settings screen from the player's perspective.

The result is a window — from the moment of withdrawal to the next launch — where behaviour does not match the player's stated preference. In most games that window is the rest of the session.

The propagation problem

The harder version of this appears when more than one component is involved.

A game typically has several things that collect or transmit data, each configured independently. Consent state has to reach all of them, and each has its own way of being told.

If consent changes and only some of them are updated, the ones that were missed carry on. This is not a hypothetical — it is the most common finding when anyone actually tests the behaviour, because the update path was written for the components that existed when it was written and later additions were wired to read consent at startup only.

The test that finds it is straightforward and rarely run: change consent mid-session and observe what is still transmitting. Anything that continues is a component that did not receive the change.

Designing for it

The pattern that holds up is to treat consent as a value that anything reads at the point of use, rather than a configuration applied once.

If every collection point checks current consent state when it acts, a change takes effect immediately everywhere with no propagation required. This is slightly more work per event and removes the entire class of missed-component bugs.

For queued data the decision needs to be explicit rather than incidental. The defensible position for most purposes is that data collected under consent may be sent, and data collected after withdrawal may not — but that requires knowing when each queued item was collected, which means recording it, which is not usually done.

The simpler and more conservative position is to discard the queue on withdrawal. It loses some legitimately-collected data and it is trivially explainable, which has value in itself.

See how consent state flows through the collection path →

The cross-device case

The version that catches teams out is consent changed somewhere else — on another device, or through a web privacy request.

A game that only reads consent from local storage will not know. The player believes they have withdrawn consent globally; one of their devices continues as before, potentially for a long time if that device is used infrequently.

Handling this requires consent state to be checked against a server rather than only locally, at least periodically. That is a small piece of work and it is frequently skipped because the local-only version appears to work.

The related case is a player who exercises a deletion right. That is a different obligation from consent withdrawal — it looks backward as well as forward — and it needs a path that reaches everything holding their data, including anything passed to third parties. Games that can withdraw consent but cannot answer a deletion request have addressed the easier half.

None of this is technically difficult. It is a set of code paths that are easy to omit because omitting them produces software that appears to work correctly, and the gap only becomes visible when someone tests the transition rather than the states either side of it.

This is general commentary rather than legal advice; obligations vary by market and are worth confirming with counsel.

The other thing worth building early is a way to observe current state. A game where nobody can answer "what is this player's consent state right now, and what is each component doing about it" has no way to verify the behaviour is correct, and no way to investigate when someone asks. A simple internal view showing the current value and what each collection point last did with it turns an unanswerable question into a lookup, and it is the same view that makes the mid-session test above practical to run at all.

Talk to us about privacy-aware telemetry →