1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
VOIDERATION V26: PRE-SCENE INTEGRITY GATE + ENFORCEMENT
Date: 2026-10-30
Scope: Research/planning only. No code, Unity, revision, API, dashboard or
production changes. Reuses V22/V23/V25 and local source bundle.
RECOMMENDED ARCHITECTURE
Use two layers, with distinct security roles:
1. Unity bootstrap for user experience and accidental-failure detection. A
`RuntimeInitializeOnLoadMethod(BeforeSceneLoad)` entry creates a persistent
bootstrap/guard before first-scene objects. It checks required local
components/config, initializes Voideration, and holds a loading overlay until
trusted verification completes. A first build scene can be a dedicated
bootstrap, but changing current startup/build order is a separate compatibility
decision. `DontDestroyOnLoad` singleton and scene-load callbacks detect
duplicates/transitions and report missing components.
2. Trusted backend admission/enforcement. Worker validates a trusted session,
checks PlayFab ban, Voideration D1 ban and PendingReview restriction, and
Photon custom authentication denies admission unless allowed. This is the
actual security boundary. A modified client can remove local guard, patch
callbacks, forge local component checks, alter scenes or ignore `Application.Quit`.
Client bootstrap is not proof of integrity and cannot securely prevent a
modified client from reaching Photon on its own.
Project inspection confirms Unity 2021.3.32f1; enabled build scenes currently
start with `YesNewTut`, followed by TOS, Menu and Game. No BadGuyScene or
PendingReview enforcement was found in searched local scenes/source. Oculus XR
packages are present; cold-start ordering on Quest has not been runtime-tested.
Prefer integrating with existing login/XR init and avoid changing build order
until device tests preserve first launch and tutorials.
STARTUP / SCENE FLOW
1. App launch: before first normal scene, initialize a single persistent
Voideration bootstrap; validate local required configuration/components and
show a non-interactive loading gate. Local checks catch missing/accidental
components only; no client-side hash alone proves code integrity.
2. Obtain normal PlayFab login/session (and Meta proof only if the chosen
verified identity flow is available). Worker validates server credential,
creates a short-lived startup/session challenge, checks one-use nonce,
expiry, app/build/rule version and session sequence/idempotency. Never trust
client PlayFabId, client result, local approval, or replayed startup response.
3. Backend returns minimal signed/opaque session result: verification success,
canonical identity, policy/version and access disposition. Client keeps
session credential protected as feasible and does not persist an allow result
across fresh auth. Exact Meta attestation capability and secure Quest device
attestation are UNVERIFIED; startup handshake is protocol verification, not
proof that binary is unmodified.
4. Outcomes: Approved/no active restriction -> continue existing TOS/tutorial/
menu flow. PendingReview restriction -> `BadGuyScene` with pending status and
review instructions; backend also denies Photon auth. Active PlayFab or
Voideration ban -> `BadGuyScene` with issuing system, reason, expiry/permanent
display; Photon gate independently denies. Hard-fail rule -> durable incident
submission/receipt first, then request `Application.Quit()`.
5. Scene changes: persistent bootstrap observes `SceneManager` load callbacks,
rechecks required local components/state, prevents accidental progression in
normal client flow and confirms singleton remains alive. Reverify short-lived
backend session on re-authentication/expiry; do not request a full startup
attestation for every scene. Backend admission is checked on every Photon
connect/reconnect/quick rejoin, not inferred from current scene.
HARD-FAIL DETECTION POLICY / INCIDENT DELIVERY
- Hard-fail is opt-in per named, versioned rule and owner-configured. Restrict to
high-confidence server-verifiable violations (for example repeated invalid
authenticated challenge/sequence replay after identity/session is established).
Do not hard-fail on lag, tracking loss, frame spikes, normal movement variance,
weak behavior suspicion, missing heartbeat, ordinary timeout or backend outage.
- On trigger, client/backend submits bounded schema and evidence reference using
a short-lived Worker session capability; backend derives identity, validates
size/rate/rule and writes incident plus alert-outbox row to D1 atomically. Owner
dashboard polling sees durable incident immediately. Optional Discord alert
is asynchronous and secondary. Unity waits only for a bounded deadline and
treats only an explicit durable receipt/incident ID as accepted.
- Retry a small bounded number with backoff/idempotency key while app remains
alive. Do not block quit forever. If Worker/D1 unavailable or deadline expires,
no durable receipt exists: show/record “submission unconfirmed”, optionally
retain a minimal encrypted local retry item for next launch (best effort only;
user can delete/modify it), then call `Application.Quit()` because hard-fail
policy explicitly selected that response. Never claim the owner was alerted or
apply a ban because delivery failed. On next launch retry idempotently after
backend authentication; do not let local queue determine access.
- Reliable delivery cannot be guaranteed offline or during Worker/D1 outage.
Durable backend receipt guarantees incident persistence, not immediate Discord
delivery. Outbox retries/deduplicates notification; dashboard remains primary.
Existing Worker lacks D1 incident intake/outbox; `/updateplayers` is a no-op
and is not a safe reporting route.
- `Application.Quit()` requests app exit; on Quest/mobile it is best-effort and
not an enforcement boundary. Do not wait for Discord acknowledgement. Server
must independently deny subsequent Photon admission if the rule also imposes
a backend restriction/ban.
PENDING REVIEW, DUAL BANS AND PHOTON
- Keep independent state: incident review (`PendingReview`, `Approved`,
`Rejected/Dismissed`); temporary PendingReview restriction; PlayFab ban;
Voideration D1 ban; hard-fail incident. Approval clears only PendingReview
restriction and allows rejoin after authoritative backend confirms. Dismissal
closes false-positive incident without ban. Bans remain until expiry/revocation.
- Backend is authoritative for all access states. On each new Photon auth,
validate Photon credential using supported PlayFab/Photon contract, derive
canonical PlayFabId, check PlayFab effective bans, D1 bans and active review
restriction; deny if any apply. Never trust client scene selection or cached
approval. Close anonymous Photon access and every Unity unauthenticated
fallback before claiming enforcement. Exact Worker-to-PlayFab Photon proxy
contract and dashboard settings are still staging blockers (V22/V25).
- If either ban/restriction service is unavailable, fail closed for new Photon
admission with retryable service error, not a ban verdict. Do not fall back to
anonymous auth. Existing Photon sessions may remain connected: ordinary Worker
request / connection-time custom auth does not reliably kick an actor already
in PUN Cloud. Client self-quit/disconnect is cooperative only. Never disrupt an
entire room or claim kicked without observing it.
FAILURE / FALSE-POSITIVE HANDLING
- Local component missing/corrupt, build mismatch or failed startup handshake:
show recovery/service error and hold normal progression until required online
verification succeeds. Distinguish backend unavailable from confirmed ban or
anti-cheat detection. Use bounded retry/backoff and visible retry state; no
hard-fail quit for infrastructure failure.
- If offline play is supported, owner must decide whether it can enter a limited
non-Photon mode. Default for protected multiplayer is fail closed; no offline
or cached admission to Photon. Do not break local tutorial solely due to an
optional backend outage unless that is explicitly the product policy.
- Sensor/tracking/latency uncertainty lowers confidence and routes to incident
review only. Hard-fail requires corroborated high-confidence server evidence;
no permanent ban from client-only movement or tracking signals.
- Duplicate/replayed startup requests use session ID, monotonic sequence, short
expiry, nonce and idempotency key. Repeated identical submission returns same
incident receipt, not duplicate alert/ban. Reject stale challenges; outages are
not replay evidence.
SECURITY LIMITS / DEPENDENCIES
- Unity early init, scene callback and component-presence checks improve startup
integrity/UX but a modified Quest build can bypass them. If a stronger hardware/
binary signal is required, verify Meta App Attestation/entitlement availability
and server verification for this app; it is not established and still does not
replace trusted backend authorization. Do not label a local checksum as secure.
- Required before implementation: prove Worker/PlayFab Photon auth adapter;
implement authenticated incident intake and D1/outbox; define build/rule policy,
nonce/session expiration and evidence retention; decide offline tutorial policy;
validate Meta proof/attestation eligibility; choose BadGuyScene flow and preserve
current scene/build ordering; remove anonymous fallback only after staging.
- Existing `BadGuyScene`, PendingReview route and global bootstrap are not present
in inspected local project. V24-V25 ban display and dual-ban checks remain
designs, not implemented controls.
REGRESSION TESTS
1. Quest cold start through current first scene/TOS/tutorial/menu; verify XR
initialization order, no blank/frozen screen, resume/suspend, and normal login.
2. Missing component/config, duplicate bootstrap, scene load/unload, Game/PVP
return, level transitions and attempts to bypass local scene guard. Confirm
backend still denies a modified/bypassed client at Photon auth.
3. Valid Approved user proceeds; PendingReview routes to BadGuyScene and cannot
reconnect; PlayFab-only and D1-only bans show correct source/reason/expiry and
are denied; expired/revoked status restores access only after backend confirms.
4. Startup nonce replay, duplicate request, stale session, wrong credential,
forged PlayFabId, build/version mismatch, malformed response and Worker/D1/
PlayFab outage; no false ban label or silent multiplayer allow.
5. Hard-fail triggers only for configured rule; incident receipt appears in
dashboard before quit; timeout/offline shows unconfirmed, boundedly retries,
exits best-effort and never reports false success. Discord outage does not
lose durable incident.
6. `Application.Quit()` behavior on Quest and editor/device; verify no reliance
on it for server enforcement and no lost receipt due to immediate process exit.
7. Preserve Oculus/PCDEBUG login, Photon rooms/Voice/reconnect, inventory,
currency/purchases, `/link`, MOTD, CCU, Tag/Infection, PVP, locomotion,
Sandbox/welding, horror hub/LVL1-7 and all existing transitions.
Evidence reused: `research/VOIDERATION_FINAL_ARCHITECTURE_V22_2026-10-30.txt`,
`research/VOIDERATION_DASHBOARD_DESIGN_V23.txt`,
`research/VOIDERATION_DUAL_BAN_V25.txt`, V19/V21/V24, local Unity build settings,
`PhotonVRManager.cs` and `worker.js`. No implementation or production changes.
END OF REPORT
|
Pastebin