Layers, Trust, and Review

Keyboard shortcuts

×

?

Open this guide

Alt + B

Show or hide the lesson list

Alt + O

Show or fold the lesson outline

Alt + N

Open or close notes

Alt + H

Toggle semantic colours

Alt + D

Toggle page brightness

Alt + C

Toggle code brightness

← →

Move through a focused code trace

Home End

First or final step in a focused trace

Escape

Close this guide or an open panel

Reader shortcuts pause while you type in a text field.

Cheatsheet for Lesson 15.5Key ideas, reference and questions

A one-page summary of “Layers, Trust, and Review” you can keep beside your notes. Plain Markdown.

Lesson 15.5 — Layers, Trust, and Review: cheatsheet

• Remember: A match can have several protection layers. The game validates actions against its authoritative state.
• Also useful: Preserve the original event identity across services. Combine its context before deciding how much weight it deserves.

Key terms

• Correlation: Correlation means observations vary together.
• intersection: Their intersection is the two cases shared by both sets.
• union: Their union is the nine distinct cases flagged by at least one: six plus five minus the two counted twice.

Review

• Q: Game logging, a plugin, and a report describe event A. A later record describes event B. How many distinct events does the ledger contain? A: Two events, after merging the three reports about A
• Q: Which layer owns accepted inventory and simulation? A: The authoritative game server

Download cheatsheet (.md)

Download cheatsheet (.md)

A match can have several protection layers. The game validates actions against its authoritative state. A platform provides account and service signals. A league may add its own client requirements and review process. A community server may run plugins with local policies. These layers need not see the same facts or impose the same consequences.

Know which observation a layer owns

The game server knows its accepted inventory and simulation. Client protection sees parts of the local software environment. An account service can know historical enforcement records. A replay reviewer sees whatever the recording retained. Each observation has a time, scope, and source.

Provenance records where information came from and how it was obtained. Keep the originating event identifier, game version, server state, and detector version when forwarding a signal. Otherwise, a later service may misinterpret a copied report as a new measurement.

Three reports can describe one event

Label a toy event A. The game logs it, a plugin forwards it, and a player report references it. That creates three notifications. Their common origin means they still describe one event.

Watch it happenMerge reports about the same event

Three deliveries describe 1 event identities; a later B leaves 2 total. Distinct identities alone do not establish independence or guilt.

Read the steps

1. The system observes one event, labelled A.
2. Game, plugin and report deliveries carry A, A, A. Three notifications can describe one or several event identities.
3. Merge by event identity: A: 1 event. Repeated copies do not create more events.
4. A later delivery carries B. That identity is new; keep its own provenance and context.
5. The ledger now holds A, B: 2 events. Separate records still do not establish statistical independence or guilt.

A, B and C are chosen event identifiers, not confidence scores.

Clarification: A different event identifier means another record. It does not show that the two events have unrelated causes, or that either event proves cheating.

This simulation needs JavaScript. The lesson text around it works through the same numbers.

A later event B adds another observation. Now there are two distinct events. Distinct does not automatically mean statistically independent: both might have been affected by the same game bug or network condition.

Three notifications can describe one eventCounting reports is not counting events. Distinct events still need their own evidence.

1. 1 Event A happens once; three reports describe it

   Reports of event A

   game log

   plugin forward

   player reference

   What was counted

   notifications: 3

   events: 1

   The game log, a plugin forward and a player reference each mention the one event A.

2. 2 A later distinct event B makes two

   Events

   event A

   event Bevents: 2

   Two distinct events is a different count, but it does not prove they are statistically independent.

Counting reports is not counting events. Distinct events still need their own evidence.

Correlation means observations vary together. When several detectors share inputs or assumptions, their mistakes can occur together too. Count unique events and evaluate the combined policy on legitimate cases. Do not turn a copied signal into extra confidence merely by routing it through additional services.

Alternative: Preserve the original event identity across services. Combine its context before deciding how much weight it deserves.

Count overlapping signals once

Suppose twenty observed cases contain four flagged only by signal A, two flagged by both A and B, three flagged only by B, and eleven flagged by neither. A flags six cases and B flags five. Their intersection is the two cases shared by both sets. Their union is the nine distinct cases flagged by at least one: six plus five minus the two counted twice.

This simulation needs JavaScript. The lesson text around it works through the same numbers.

P(B given A) asks a narrower question: among the six cases already flagged by A, how many were also flagged by B? Here it is two out of six, not two out of twenty. Changing the overlap changes that answer. These counts describe an invented sample; they do not prove that any case is cheating. Multiplying P(A) by P(B) gives the intersection only when the events are independent, an assumption shared detector inputs can violate.

Matchmaking risk is different from a cheating verdict

A trust score summarizes risk or expected match quality for a policy. It may guide matchmaking or prioritize review. It is not necessarily an assertion that the account cheated in a particular match.

Valve’s published CS:GO Trust Factor explanation illustrates that distinction: it describes matchmaking using account and play observations, while leaving changing details undisclosed. An account score does not replace an explanation of which check failed in an enforcement decision.

New accounts, shared hardware, changing devices, and unusual but permitted play can complicate such signals. Keep the scope of a consequence tied to the evidence and documented enforcement policy. A community server’s local removal is different from a platform-wide sanction.

Why online services ban modified consoles

A console proves what software it booted with a signed report from its security processor, the remote attestation that Lesson 13.6 follows. A console running modified software cannot produce a valid report, because the modified software cannot reach the signing key and cannot make the boot measurements match software it is not.

Why ban the console rather than just ignore the report? A modified console can run cheats in matches with other people, run pirated games, and send the service messages that genuine software never would, so nothing it says can be trusted. Banning it by its unique ID, and sometimes the account, protects other players and the store. The ban is the service’s decision under the terms of service the owner accepted, not a technical malfunction.

Attestation is one layer, not the whole defence. Well-designed online games still check every action on the server, as Chapter 9 describes, because no check on the client is perfect. A server that believes a console’s claim about where a player is standing has the same weakness as one that believes a PC’s.

Delayed enforcement has tradeoffs

A ban wave applies accumulated enforcement decisions in a batch. Grouping cases can give investigators time to validate them and make immediate detector feedback less revealing. The delay also allows further harm unless other controls prevent or mitigate it.

Use durable case records and preserve the version of the check that led to each decision. If an update causes a false-positive cluster, pause enforcement based on the affected check, investigate its shared cause, and correct affected cases. A general recovery process should exist before a large batch is applied.

Review queues need clear prioritization and limited data access. A report can be valuable without being sufficient evidence for a ban. Repeated reports from the same source or the same incident should not automatically increase the penalty. The purpose of layering is to add useful coverage and context, not to hide responsibility behind a majority of flags.

🧩

Knowledge check

Follow event identity

Game logging, a plugin, and a report describe event A. A later record describes event B. How many distinct events does the ledger contain?

1Two events, after merging the three reports about A2Four events, because each notification supplies another event3Three events, after ignoring the later report about B4One event, because all reports concern the same player

Check answer

Finished Lesson 15.5?

Mark it done and the lesson list shows a ✓ beside it. A chapter whose lessons are all done is marked done too. Progress is saved in this browser only.

Mark lesson doneLesson done. Mark it not done

Chapter 15: 10 lessons

📝 Notes