Device Data and Security

Any program running on a machine can ask the operating system a long list of questions about the hardware it is running on, and the operating system will answer most of them without a prompt to the user. The model of the graphics adapter, the amount of installed memory, the processor family, the screen resolution, the operating system build number and the installed language are all readable by ordinary software with no special permission. None of that is secret, and almost all of it exists so that software can adapt itself.

A second group of values is more specific: the identifying number a drive reports, the identifier assigned to a network adapter, or an installation identifier that the operating system generated when it was first set up. These are more stable and more particular to one machine, so they are treated with more care. Modern operating systems have been steadily restricting access to them, and several now require an explicit permission or return a value that is unique to each application rather than to the machine.

The important distinction is between values that describe a class of hardware and values that identify one specific unit. Knowing that a machine has a mid-range graphics adapter and eight gigabytes of memory says nothing about who owns it. Knowing a stable per-machine identifier does. Well designed software asks for the first kind routinely and the second kind rarely, and a privacy policy that distinguishes between them is a reasonable sign that the people who wrote it understood the difference.

The first reason is configuration. A game that knows the adapter model and the available memory can choose sensible default settings instead of starting at maximum and stuttering. It can also work around specific faults, because graphics drivers have bugs and a studio often ships a list of known problem combinations with an automatic fix for each. Without hardware reporting, every player would have to find those settings alone.

The second is diagnosis. When a game crashes, the report that gets sent back usually contains the hardware description, the driver version and a stack trace, because a crash that happens only on one adapter family is otherwise impossible to reproduce. This is the single most valuable use of device data for a studio, and it is also the one players benefit from most directly, since it is how a patch gets written.

The third is planning. Aggregate hardware data tells a studio what its audience actually owns, which decides the minimum specification for the next release and whether an expensive rendering feature is worth building. A studio reading its own telemetry usually finds its audience is running older hardware than its designers assumed, and that finding changes roadmaps.

When a player signs in, the password is checked once and then set aside. What the client keeps afterwards is a session token, a long random string that the server recognises. Every later request carries the token instead of the password, which means the password is transmitted rarely and stored nowhere on the device. A server never stores the password itself either, only a slow one-way hash of it, so a stolen database does not hand an attacker a list of logins.

Tokens expire on purpose. A short-lived access token paired with a longer-lived refresh token is the common arrangement: the short one does the work and becomes useless quickly, and the long one can be revoked centrally the moment something looks wrong. This is why signing out of all devices works, and why a compromised session can be cut off without forcing every player to change a password.

The weak point in this design is not cryptographic, it is human. Tokens can be stolen from a machine by software the player installed themselves, which is how most account takeovers actually happen. This is why the strongest single protection remains a second factor at sign-in, and why an unexpected sign-in notification is worth reading rather than dismissing.

A typical online match produces a stream of events: positions at a fixed tick rate, actions taken, damage applied, latency samples and frame timings. Most of it exists so the server can keep every client showing the same world, and it is discarded within minutes. A smaller, longer-lived stream records outcomes, progression and purchases, because those have to survive the session.

Performance data is the part players rarely think about. Frame time histograms, memory pressure and load durations are gathered continuously in many titles, because average frame rate hides the stutters that actually ruin a match. A studio that only measured averages would never find the problem affecting one player in fifty, and that class of bug is exactly what telemetry exists to catch.

What is generally not collected, despite persistent belief, is the contents of a machine: browsing history, documents, or files unrelated to the game. Reading those would breach both platform rules and data protection law, and the reputational cost of being caught is far beyond any value. The reasonable posture is to read the published policy, which for large studios is specific and enforceable, rather than to guess.

Once data leaves a machine it lands in a pipeline: a collector that accepts events, a queue that absorbs bursts, and storage split by how long each class needs to live. Match telemetry usually goes to a warehouse designed for large volumes of short-lived records. Account and transaction data goes to a conventional database with backups. Crash reports often go to a separate system entirely, because they can contain fragments of memory and are treated as more sensitive.

Retention is the part worth reading. A mature policy states a period for each class and deletes on schedule: raw telemetry measured in days or weeks, aggregated statistics kept far longer because they no longer identify anyone, financial records kept for the years that tax law requires. A policy that says data is kept as long as necessary and stops there is telling you nothing.

Deletion is harder than it sounds, which is why honest policies distinguish between deleting a record and deleting it from every backup. Backups are written to be immutable, so the standard approach is to delete from live systems immediately and let backups expire on their own cycle. A policy that explains that distinction is usually a policy written by someone who has actually done it.

Traffic between a client and a server is protected in transit by the same family of protocols that secures the web. A handshake establishes a shared key, a certificate proves the server is who it claims, and everything after that is unreadable to anything in between. This is why a hostile network can see that a connection exists and roughly how much data it carries, but not what is in it.

Data at rest is a separate problem. Disk-level encryption protects against a stolen drive and nothing else, since a running system decrypts transparently. Protecting a specific sensitive field, such as a stored payment reference, requires encrypting that field with a key held somewhere the database itself cannot reach, usually a key management service. That is what makes a stolen database dump much less useful than it sounds.

The recurring failure in practice is not the cryptography, it is the keys. Keys committed into source code, left in a configuration file readable by every process, or shared across environments have caused far more breaches than any weakness in an algorithm. The discipline that matters is rotation, restriction and keeping keys out of anything that gets copied.

In an authoritative architecture the client is a renderer and an input device, nothing more. It sends what the player pressed; the server decides what happened and sends the result back. A client that lies about its own position is simply corrected, because its claim was never trusted. This single design decision removes an entire category of manipulation, and it is the reason competitive titles invest so heavily in it.

The cost is latency and infrastructure. Waiting for a server to confirm every action feels sluggish, so clients predict the likely outcome locally and reconcile when the authoritative answer arrives. Getting that reconciliation smooth is one of the harder problems in the field, and doing it badly produces the rubber-banding that players recognise instantly.

What server authority cannot fix is information. A client must be told enough to draw the world, and anything it has been told can in principle be read. The answer is to send less: relevance filtering that transmits only what a player could plausibly perceive. That is why modern titles cull aggressively by line of sight and distance, and it is a design improvement as much as a protective one, since it also saves bandwidth.

Every mainstream platform signs its game binaries. The studio holds a private key, the platform holds the matching public one, and the launcher refuses to run anything whose signature does not verify. This is what stops a modified copy of a game from being distributed as the real thing, and it is why an installation that has been altered will often simply refuse to start rather than explain itself.

Updates use the same machinery with an extra step. A patch is downloaded, its hash is checked against a signed manifest, and only then is it applied. The manifest matters as much as the signature, because it pins the exact contents of every file: an attacker who could substitute one file inside an otherwise genuine update would otherwise have a direct path onto every player machine.

This is also why studios treat their build systems as the crown jewels. A compromised signing key or a compromised build server does not just leak data, it lets an attacker ship signed software to the entire player base. The industry answer is hardware-held keys, signing performed by a restricted service rather than by a person, and reproducible builds so that the output can be independently checked.

Fair play systems are usually described as detectors, but most of their work is measurement. They collect signals: how a player aims over thousands of engagements, how reaction times are distributed, how often impossible sequences of inputs appear, and how those numbers compare with a population of similar players. A single suspicious match means very little; a distribution that does not resemble any human distribution means rather more.

Because these systems produce probabilities rather than certainties, the responsible ones are built around thresholds and review rather than instant action. A high confidence signal may trigger a restriction while a human or a slower automated process examines the case. This is deliberate: a false positive costs a real player their account and costs the studio a public argument it will usually lose.

Player reports still matter, not because a report is evidence, but because it directs attention. The common design uses reports to prioritise which recordings get examined, and the examination is where the decision actually comes from. This is also why the gap between reporting someone and seeing an outcome is measured in days: the queue is real work, not an automatic switch.

Under the European framework and the similar regimes that followed it, a company processing personal data needs a lawful basis, has to say what it collects and why, and has to honour a set of rights. The two most useful to a player are access, meaning a copy of what is held about them, and erasure, meaning deletion where no other legal duty requires retention. Both are free to exercise and both carry a response deadline.

Access requests are more informative than people expect. The response typically lists account records, purchase history, session logs and the categories of telemetry held, which is a far better answer to what does this game know about me than any amount of speculation. It is also the fastest way to discover that the answer is usually duller than assumed.

The limits are worth knowing too. Erasure does not override retention that law requires, so financial records survive a deletion request. Data that has been aggregated to the point where it identifies nobody is generally out of scope, because it is no longer personal data. And a request for data about another player will be refused, since their rights apply equally.

Breaches happen to competent organisations. What separates them is the response: how quickly it is detected, how honestly it is described, and how completely it is remediated. Regulators in several jurisdictions impose a notification deadline measured in days once a breach is known, and that clock is one of the more effective pieces of security regulation because it makes silence expensive.

A good disclosure states what was taken and what was not, when it happened, what the operator has done, and what the reader should do. A poor one uses the passive voice, avoids numbers, and describes hashed passwords as if hashing made the loss harmless, which depends entirely on the algorithm and whether each record was salted. Old fast hashes offer very little protection; modern slow ones offer a great deal.

For a player the practical response is unchanged and unglamorous: a unique password per service so one loss cannot cascade, a second factor on the account and on the email behind it, and a look at active sessions after any incident. Nothing about that advice has changed in a decade, which is itself a sign that it works.

Use a distinct password for every service and keep them in a manager. Reuse is the mechanism behind most account takeovers, because attackers take credentials leaked from one breached service and try them everywhere else automatically. That single change defeats the whole technique, and it costs a few minutes to set up.

Put a second factor on the game account and, more importantly, on the email address behind it. Whoever controls that inbox can usually reset everything pointed at it, which makes it the most valuable account a player owns and the one most often left unprotected. An authenticator application is meaningfully stronger than a code sent by message, because phone numbers can be redirected.

Be careful about what you install. Software promising an advantage in a game is the most reliable delivery route for programs that read saved passwords and session tokens straight out of a browser profile, which is how a login gets taken without a password ever being typed anywhere. Finally, review active sessions and authorised applications occasionally and remove what you no longer recognise.