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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
VOIDERATION STAGE 0: IMPLEMENTATION PREFLIGHT
Date: 2026-10-30
Scope: Read-only source/research review. No dashboard or production access was
used; no code, settings or services changed. V22 is the proposed baseline, not
deployed. Do not send secret values; record only names/status and redacted IDs.
STATUS KEY
Known = established from reviewed source/shared records. Unverified = requires
owner dashboard inspection or staging test. “Blocks Stage 1” means do not ship
that implementation until resolved; optional items are identified.
1. PLAYFAB
Moderator UserData permissions
- Known: Unity `Oculus_Login.CreateKeyIfNot()` reads/writes ordinary UserData
key `Moderator`; client sets missing key to FALSE and locally trusts TRUE.
V08 draft has ReadOnlyData helper but does not consistently use it in
`ReportPlayer`. No verified server-owned moderator source found.
- Unverified: current Title API policy, deployed role source, deployed CloudScript
revision, external operator checks.
- Inspect: Game Manager > Title Settings > API Features/Policies (client
`UpdateUserData` access); Player Data/UserData permissions; Automation > Cloud
Script (deployed revision and registered handlers); any Azure Functions and
role data access.
- Secure target: no client-writable role authority. Use server-only InternalData
or role store; ReadOnlyData only for display. Every privileged handler derives
caller identity server-side and checks role. Never trust ReporterId/client role.
- Blocks Stage 1 moderator migration/actions: yes. Do not bulk-promote based on
current writable Moderator values.
CloudScript deployment
- Known: checked-in `revisions/SCREECHVR_PLAYFAB_REVISION_V08_2026-10-29.js`
says DRAFT - NOT DEPLOYED. It contains client-supplied ReportPlayer identity,
ServerGrantCurrency without role auth, and OnPurchaseItem using client Price.
- Unverified: whether another revision/function is live and callable; PlayStream
event rules.
- Inspect: Automation > Cloud Script > revisions/deployments/registered
functions; Azure Functions registrations/auth; PlayStream > Rules/event
triggers; Title API Policies for ExecuteCloudScript/function access.
- Secure target: inventory every deployed handler and caller; server-check caller,
validate inputs, idempotency, audit; staged revision and rollback plan.
- Blocks Stage 1 backend changes: yes.
Currency APIs
- Known: Unity has multiple direct client `AddUserVirtualCurrency` callers via
`Oculus_Login.AddCurrency` (ore, daily reward, Meta IAP/ATM, bundle); V08
`ServerGrantCurrency` has no role check. Source proves calls, not live policy.
- Unverified: client API restrictions, currency/catalog settings, other live
grants, deployed server enforcement.
- Inspect: Game Manager > Title Settings > API Features/Policies for Client
`AddUserVirtualCurrency`/economy access; Economy > Currencies; CloudScript/
Functions deployment and access policy.
- Secure target: migrate legitimate rewards first; backend derives player and
eligibility, bounds amount, unique request/idempotency key, server grant and
audit. Restrict direct client grants only after staged compatibility tests.
- Blocks Stage 1 economy migration: yes.
Purchases and validation
- Known: PlayFab client `PurchaseItem` is used for catalog cosmetics/bundles;
its Legacy API checks submitted expected price against catalog/store price.
V08 custom OnPurchaseItem does not call that API and accepts `args.Price`.
Meta IAP callbacks grant in Unity without source-found server verification;
`OWNED_IAP` is ordinary client UserData.
- Unverified: deployed handlers, catalog/store/currency configuration, Meta
product/SKU mappings and any external receipt-validation service.
- Inspect: Economy > Catalog/Stores/Virtual Currencies and purchase rules; Meta
IAP setup separately. In PlayFab inspect deployed receipt-validation callers
and API policies.
- Secure target: PlayFab catalog price on server; Meta S2S entitlement check,
server SKU/reward map, durable idempotency ledger, consumable consumed after
fulfillment, durable restore idempotently. Preserve every SKU/item/entitlement.
- Blocks Stage 1 purchase migration: yes; do not disable current paths first.
2. PHOTON
- Known: Unity obtains PlayFab Photon token and passes PlayFab ID as username,
token as Photon `token`; this is distinct from PlayFab SessionTicket.
`PhotonVRManager` falls back after 20 seconds by clearing AuthValues and
connecting unauthenticated. No dashboard read was performed.
- Unverified: Custom Server provider/URL, anonymous-client admission, failure
policy, Realtime/Voice app ID mapping, current PUN/Voice versions, reconnect
behavior and any targeted disconnect capability.
- Inspect: Photon Dashboard > Realtime App > Manage/Authentication (Custom
Server URL/provider, “Allow anonymous clients…” and failure behavior); confirm
PlayFab Photon add-on association and app ID. Inspect Voice app/auth separately.
In Unity project settings/package list, record the configured app IDs and PUN/
Voice versions without publishing full IDs.
- Secure target: supported PlayFab custom auth, anonymous clients disabled,
auth failure never downgraded; Unity retries without anonymous fallback.
Restriction enforcement needs a staging-proven Worker adapter that validates
Photon’s token contract and checks D1. Never send a Photon token to
AuthenticateSessionTicket. Exact Worker-to-PlayFab proxy request/response
contract is unverified and must not be guessed.
- Blocks Stage 1 auth/rejoin enforcement: yes. Capture settings first; staging
proof of provider contract and Voice/reconnect required before release.
3. META
User Verification
- Known: current client reads Meta user ID and uses it as PlayFab Custom ID;
no server-side proof validation in inspected flow. V15 docs describe one-use
GetUserProof nonce verified by trusted server-to-server call.
- Unverified: app eligibility, User ID DUC permission, API credentials access,
Unity Platform SDK method availability/build compatibility with Unity 2021.3.32f1,
account-link migration choice.
- Inspect: Meta Developer Dashboard > app > Requirements/Data Use Checkup (User
ID permission/status); API/app settings and product/platform eligibility. Do
not copy app secret into report or client.
- Secure target: backend validates proof nonce/user ID via Meta S2S, replay-safe,
binds verified identity to existing PlayFab account. Proof does not attest
hardware and does not replace entitlement check.
- Blocks: blocks using Meta proof as Stage 1 identity factor; does not block
staging other auth tests if the fallback is not represented as verified.
App Attestation
- Known: no source implementation found; V22 makes it optional.
- Unverified: app/product eligibility, signing/package setup, SDK/API/build
support and server verification access.
- Inspect: Meta Developer Dashboard > app integrity/attestation features and
Unity Platform SDK package/API reference.
- Secure target: optional integrity signal, backend-verifiable fresh challenge;
service outage = unknown, never automatic ban.
- Blocks Stage 1: no, unless owner explicitly makes it a release requirement.
4. CLOUDFLARE
- Known: local Worker has `/redeem`, `/motd`, Photon webhook, Discord interaction,
export/setup/health routes; `/updateplayers` is a no-op. `/redeem` validates
PlayFab tickets for linking only. No D1 binding, heartbeat or incident routes
found in reviewed Worker. Secrets are environment-bound in source conventions;
actual deployed values were not read.
- Unverified: deployed Worker/version, routes/hostnames, bindings, secret names
and rotation status, account plan and aggregate requests/rows, D1 existence,
quota headroom. Query-string keys are present in some routes in source.
- Inspect: Cloudflare Dashboard > Workers & Pages > Worker > Deployments, Routes,
Settings/Bindings (names only); Workers & Pages > D1 databases/bindings; account
plan and Analytics/Metrics > Workers and D1 row metrics. Inspect secrets without
revealing or copying values. Verify domains/route consumers.
- Secure target: server secrets only in Worker secret bindings, never Unity/source;
avoid URL secrets; D1-backed incidents/restrictions/audit with conditional
atomic updates; no KV writes per heartbeat; per-route auth and redacted logs.
- Capacity: V19 model at 100 players/5-minute heartbeat is 28,800 Worker requests
and about 28,800 D1 row updates/day before other traffic. Free quotas are shared;
measure current account headroom. €0 recurring is plausible, not guaranteed.
- Blocks Stage 1 incident/rejoin enforcement: yes, until deployed bindings,
capacity and exact Photon adapter are validated in staging.
5. DISCORD
- Known: shared records name `admin-logs` as current admin log channel. Prior
audit (2026-10-20/21) noted `#mod-logs` Staff-view/send and `#audit-logs`
staff-view-only with a Dyno webhook; status may be stale. No verified private
Voideration alert destination or delivery test.
- Unverified: current channel existence/effective permissions, bot/webhook path,
secret owner, who can view incident evidence, rate/alert behavior.
- Inspect: Discord channel/category permission overwrites for @everyone, member,
staff and bot roles; channel View/Send/History/Embed permissions; Integrations
> Webhooks (names/owner/destination, never reveal URL/token); bot role/channel
permissions. Check moderation/AutoMod alert destinations only if reused.
- Secure target: dedicated owner/staff-only channel; narrow bot identity with
send/view/history/embed only; webhook/bot credentials server-side; redacted,
deduplicated alerts after incident persistence. Confirm access with effective
permissions and a staging test.
- Blocks Stage 1 alert delivery: yes until private destination and posting
mechanism are verified. Do not create/change it during preflight.
6. VOIDERATION OWNER REVIEW / LOCAL DASHBOARD
- Known: no dashboard, incident store, owner approval API, restriction store or
D1 implementation found. V22 is a design only. Existing Worker Discord
interactions have signature validation and OWNER_ID checks for commands.
- Unverified: owner identity binding, local host/device, authentication and
recovery, browser security, review SLA, expiry/appeal/retention policy.
- Inspect/decide: owner-controlled account/identity source; machine/OS where
dashboard will run; loopback bind/firewall; secret storage. No cloud dashboard
settings exist to verify today.
- Secure target: dashboard binds 127.0.0.1 only; owner-authenticated, CSRF-safe
actions call Worker APIs, never direct browser-to-D1; server verifies owner on
every transition. Every attempt/action audited. Incident review state is
separate from player restriction; only owner clears/restricts/bans.
- Blocks Stage 1 incident/review deployment: yes. Decide account method, review
policy, evidence access/retention and restriction expiry before implementation.
STAGE 1 ENTRY: DECISIONS / APPROVALS REQUIRED FROM OWNER
1. Approve the V22 architecture for staging only; production remains unchanged.
2. Authorize read-only inspection of the listed PlayFab, Photon, Meta, Cloudflare
and Discord dashboard settings; provide access through the relevant dashboard,
never by sending secrets in chat. Approve redacted settings inventory.
3. Choose whether Meta User Verification is mandatory, optional, or deferred;
approve identity migration/linking policy that preserves current PlayFab IDs.
4. Approve a staging Photon Realtime/Voice app and test accounts. Decide whether
to investigate the Worker custom-auth proxy contract; no adapter implementation
until the official wire contract is proven.
5. Approve disabling the anonymous fallback only after staging confirms normal
login, room join, reconnect, server switch and Voice; production change requires
separate explicit approval.
6. Approve secure migration of Moderator roles, currency grants, PlayFab purchases
and Meta IAP; confirm product/entitlement preservation and staging test scope.
7. Decide incident severity/rules that may trigger temporary rejoin restriction;
approve PendingReview/Approved/Rejected semantics, confirmed restriction,
expiry/release, separate ban authority, appeals and review SLA. Weak movement,
latency or tracking signals do not auto-restrict or auto-ban.
8. Approve private Discord alert channel/identity after reviewing its effective
permissions. Approve local dashboard device, owner auth, recovery and retention.
9. Confirm €0 additional recurring target is a constraint, and authorize checking
aggregate Cloudflare Workers/D1 quotas; acknowledge a paid tier or authoritative
game server may be needed if quotas/security requirements exceed Free/PUN.
10. Approve Stage 1 scope and release gates; implementation and any production
deployment/settings change require separate explicit approval.
No secret values requested or exposed. No dashboard setting was changed or
verified in this preflight. V22 remains a proposed baseline.
END OF REPORT
|
Pastebin