Fair Poker — AI / Crawler Consolidated Index

Fair Poker 是研究德州扑克可验证公平的非营利开源密码学研究项目。研究演示需要 JavaScript，向公众开放；透明度报告、源码发布和独立验证指南可以作为静态文档访问。

Fair Poker · 德州扑克公平性开源密码学研究

Fair Poker 是一个非营利、纯兴趣的开源学术研究项目，研究一个问题：没有发牌服务器、没有中心牌库时，线上德州扑克能不能做到可验证的公平？牌堆由玩家浏览器共同加密洗牌，中继只转发消息、不发牌、不开牌；每一手都生成可下载、可本地重放复验的签名证据。我们只做能被你亲手验证的承诺。

这不是一个游戏平台

本项目不对公众提供任何游戏服务，也不是完备的商业产品。在线演示向公众开放，用于协议自测与体验；演示内筹码为虚拟测试筹码，无任何现实价值，不可充值、提现或兑换。想研究或体验的朋友，请下载

全部开源代码，在自己的电脑上搭建运行——我们提供思路与代码，不提供服务。

运行时权力边界（可在源码里查到）

官方零裁判、零踢人：Cloudflare Worker 只为签名消息排序、转发，并报告谁在线——它不计算座位、回合、轮到谁、赢家或筹码（这些牌局逻辑已从中继移除，可在源码 buildRoomState 里查到只剩在线状态）。没有任何协议路径把玩家踢出牌局、没收筹码或改写赢家。掉线只会触发自动重连，决定权始终在你的签名行动、共识超时或共识作废。

浏览器即唯一权威：每个浏览器用同一套确定性 reducer，从那条签名事件日志算出全部牌桌状态（座位 / 底池 / 轮到谁 / 赢家 / 战绩）。两个浏览器读同一份日志，算出的状态必然一致；刷新或瞬时断网回归后，浏览器从日志重新算出完全相同的状态——不会把你"瞬移"到观战席，下注也不会两边对不上。战绩本地留存，刷新不丢。

中继永远看不到底牌：私有发牌的逐卡解密钥用收牌方公钥端到端密封（RSA-OAEP），并绑定 sender / recipient / round / cardOffset；重发到任何其它收件人或卡位都会被拒。中继全程只看到密文。

解密钥只在本手牌期间暂存：每张牌的逐卡解密钥仅在你正在进行的这一手牌期间暂存于本机，断线/刷新/关闭后重连能恢复这一手；牌局一结束即删除，不长期保留。

每一局都自带证据

每手 4 灯公平校验：每局结束自动跑 4 项校验——牌堆完整 · 全员参与洗牌 · 记录指纹一致 · 签名齐全。通过亮"已验证"印，异常红灯并提示下载证据。

每手签名 hash-chain transcript：事件顺序、签名、下注、奖池、公共牌、摊牌全部进入哈希链，可下载、可本地 verifier 重放复验。

客户端 CID 实时校验：浏览器运行时从 ai.json 拉权威 CID，与当前页面 CID 比对，安全面板显示「已锁定 / 不符 / 未固定」。

每事件签名 + 默认拒收未签名：GameRoom 默认 rejectUnsignedEvents = true；签名绑定 tableId，跨桌重放被拒；每会话绑定 sessionNonce 防同会话重放/乱序。

验证器与现场算账逐分一致：可下载的离线验证器和现场用的是同一套规则算筹码结果——弃牌结束与摊牌（含边池/比牌赢家）两条路径都有 CI 测试逐分对齐，二者永远不会悄悄分叉。

桌面控制按钮越权可追责：协议层动不了你的筹码或牌（那些必须本人签名）；若有人非房主擅自改设置 / 重开报名，离线验证器会在可复验记录里标注出来、追责到具体签名者。

已堵上的漏洞

密码永不出本机：登录改发浏览器派生的 authSecret，服务端只存其哈希，永远不接触明文密码；密钥库用密码派生密钥本地加密，密文上传，永不解密。

中继 token 出 URL：鉴权 token 改走 WebSocket 子协议，不再进代理、CDN 或访问日志（同时兼容 Chrome 149+ 强制 echo 握手）。

1024 位 SRA 加密 + 二次剩余编码：发牌加密用 1024 位 mental-poker 参数（2048 位模数），并设 2048 位上限防超大参数卡死全场；牌面编码成二次剩余，连"残差指纹"也不泄露——任何人（含运营方）零钥匙都推断不出隐藏的底牌。

牌堆做手脚当场作废：开牌时一旦发现同一张牌出现两次（合法 52 张牌绝不可能），即判定牌堆被篡改，自动作废该手、退还筹码——做手脚的牌堆根本无法被打出来。

断线规则简化到极简：可恢复掉线 → 无损自动恢复；真正离开 → 本手作废、全额退还、整桌结束建议换桌——没有罚款、没有"操作员代踢"。

auto-reconnect + 消息重放：WS 断开 500ms→10s 指数退避自动重连，重连后按 sinceSeq 重放，状态不丢。

事件全部严格 schema 校验：下注 / 弃牌 / 设置 / 牌堆 / 密钥进状态机前结构校验，畸形 / 越界 / 非整数下注被拒，关闭异常输入造成的状态污染和拒绝服务面。

verifier 覆盖全部事件类型：离线 transcript 验证器不再静默跳过任何类型；摊牌阶段重复明文检查、按签名重建 finalHash。

source fingerprint 覆盖完整信任边界：指纹不再只覆盖发牌核心，还包含认证 / 传输 / 启动 / 身份相关文件。

官方证据资源

透明度报告

公开证据状态

机器可读证据状态

独立验证指南

安全白皮书

已加固内容与已知差距（诚实披露）

最新源码发布清单

AI 可读 JSON 摘要

开源代码仓库（GitHub）

Snyk 安全扫描报告

How the evidence is produced

Status generation

npm run audit:status generates public/audit/status.json and src/generated/auditStatus.ts.

Pre-build refresh

npm run build refreshes release metadata and audit status via prebuild.

Dependency scan

The output of npm audit --omit=dev --json is written into the public status.

Fairness verification

Source release, IPFS CID, SHA256, fingerprint, and the transcript verifier together form a verifiable loop.

Related material

Machine-readable audit status

Transparency report

Independent verification guide

Security whitepaper

Latest source release manifest

AI-readable JSON summary

Open-source repository (GitHub)

Snyk security report

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

开源代码Source code

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

独立验证 · Verification

独立验证指南

三件事你都能自己验，不用相信我们：① 线上跑的游戏，就是这份公开源码（重新编译比对）；② 每手牌结束自动跑 4 灯公平校验；③ 任何一手都能下载牌局记录、在本机重放复验。

Verification

Independent verification guide

Three things you can verify yourself, no trust required: ① the live game is built from this public source (rebuild & compare); ② every hand auto-runs a four-light fairness audit; ③ any hand can be downloaded and replayed locally.

发布事实Release facts

Official domain

https://fairpoker.app

Game client CID

Read from canonical release JSON

Source package CID

Read from canonical release JSON

Source package URL

Read from canonical release JSON

Source fingerprint

Read from canonical release JSON

Archive SHA256

Read from canonical release JSON

官方客户端开源了——但怎么证明「线上 IPFS 上跑的」就是这份源码？The client is open source — but how do you prove the code running on IPFS is this exact source?

先说破一个最常见的误会：上面「发布事实」里有两个不同的 CID，它们本来就不一样、也永远不该相等——别拿这两个互相比。

牌局客户端 CID（Game client CID）＝编译好、能直接玩的成品（好比烤好的蛋糕）。

核心源码包 CID（Source package CID）＝给人阅读、审查的源代码（好比面粉和鸡蛋）。

面粉的编号和蛋糕的编号永远不会一样，这很正常。证明「线上＝源码」靠的是各自对上两次：

比对 ①：你下载的源码包算出的 CID ＝公布的 Source package CID → 说明你读的源码没被掉包。

比对 ②：你用这份源码在固定 Docker 环境里重新编译出的 CID ＝公布的 Game client CID → 说明线上跑的游戏正是这份源码编出来的。

两个都对上＝你能读的（源码）就是线上真在跑的（游戏）。官方没法「给你看一份干净代码、却偷偷跑一份作弊代码」——任何人重编都会当场对不上、立刻穿帮。

1读取官方发布参数

curl -L -o release.json https://fairpoker.app/source/release.json

# 看：gameClientCid、currentSourceRelease.ipfsCid、archiveSha256，

# 以及 reproducibleGameClientBuild.buildEnv（含 SOURCE_DATE_EPOCH）

2下载源码包并校验（比对 ①）

SOURCE_ARCHIVE_URL=$(node -e "console.log(require('./release.json').archiveUrl)")

curl -L -o fair-poker-source.tar.gz "$SOURCE_ARCHIVE_URL"

# (a) SHA256 应等于 release.json 的 archiveSha256

shasum -a 256 fair-poker-source.tar.gz

# (b) 源码包 CID 应等于 release.json 的 currentSourceRelease.ipfsCid ← 比对 ①

ipfs add -rQ --cid-version=1 --raw-leaves --only-hash fair-poker-source.tar.gz

3在固定 Docker 环境里重新编译

tar -xzf fair-poker-source.tar.gz # → fair-poker-source/

cd fair-poker-source

# 用 release.json 的 reproducibleGameClientBuild.buildEnv 里的值：

export SOURCE_DATE_EPOCH=... # buildEnv.SOURCE_DATE_EPOCH

export REACT_APP_SOURCE_ARCHIVE_IPFS_CID=...

export REACT_APP_SOURCE_ARCHIVE_SHA256=...

export REACT_APP_SOURCE_ARCHIVE_URL=...

bash scripts/reproducible-game-build.sh ../fair-poker-source.tar.gz

4比对结果（比对 ②）

脚本最后会打印一个 Game client CID。它应当等于上面「发布事实」里的 Game client CID，也等于你实际进入游戏时浏览器加载的那个 CID。

每个比对结果说明什么

比对 ① 对上

你正在读的源码＝官方公布的源码，没被掉包。

比对 ② 对上

线上正在跑的游戏＝这份源码编出来的，没换成别的。

① + ② 都对上

眼见（源码）即所得（线上游戏）。官方没有藏一手的空间。

不想编译？两个更轻量的快速自查：① 用 ipfs.io、dweb.link 等不同网关打开同一个 Game client CID，应得到同一份文件（内容寻址，改一个字 CID 就变）；② 牌桌「安全牌局」面板会在运行时自动比对你加载的客户端，显示「已锁定 / 不符 / 未固定」。

诚实边界：这套复现证明的是「玩家浏览器里跑的客户端」。后端中转服务器（worker）不在复现范围内——但你不需要信任它：上面公开的客户端源码已经证明 worker 只是一个「哑巴中转」，只看得到密文，既不能发牌、不能踢人、也不能改结果。完整说明见 REPRODUCIBLE_BUILD.md。

First, the most common misconception: the «Release facts» above show two different CIDs, and they are different by design and never equal — do not compare these two to each other.

Game client CID = the compiled, ready-to-play build (the baked cake).

Source package CID = the readable source code you audit (the flour and eggs).

A bag of flour and a cake never share a label — that's normal. Proving «live = source» relies on matching each one to itself, twice:

Check ①: the CID of the source package you download = the published Source package CID → the source you read was not swapped.

Check ②: the CID you rebuild from that source in a pinned Docker toolchain = the published Game client CID → the live game is compiled from exactly this source.

Both matches = what you can read (source) is what actually runs (game). The operator cannot show clean code while secretly running cheating code — any independent rebuild would fail to match and expose it instantly.

1Read the official release inputs

curl -L -o release.json https://fairpoker.app/source/release.json

# see: gameClientCid, currentSourceRelease.ipfsCid, archiveSha256,

# and reproducibleGameClientBuild.buildEnv (incl. SOURCE_DATE_EPOCH)

2Download the source package and verify (Check ①)

SOURCE_ARCHIVE_URL=$(node -e "console.log(require('./release.json').archiveUrl)")

curl -L -o fair-poker-source.tar.gz "$SOURCE_ARCHIVE_URL"

# (a) SHA256 must equal release.json archiveSha256

shasum -a 256 fair-poker-source.tar.gz

# (b) source package CID must equal release.json currentSourceRelease.ipfsCid ← Check ①

ipfs add -rQ --cid-version=1 --raw-leaves --only-hash fair-poker-source.tar.gz

3Rebuild in the pinned Docker toolchain

tar -xzf fair-poker-source.tar.gz # → fair-poker-source/

cd fair-poker-source

# use the values from release.json reproducibleGameClientBuild.buildEnv:

export SOURCE_DATE_EPOCH=... # buildEnv.SOURCE_DATE_EPOCH

export REACT_APP_SOURCE_ARCHIVE_IPFS_CID=...

export REACT_APP_SOURCE_ARCHIVE_SHA256=...

export REACT_APP_SOURCE_ARCHIVE_URL=...

bash scripts/reproducible-game-build.sh ../fair-poker-source.tar.gz

4Compare the result (Check ②)

The script prints a final Game client CID. It must equal the Game client CID in «Release facts» above — and the CID your browser actually loads when you enter the game.

What each comparison proves

Check ① matches

the source you're reading is the official source, not swapped.

Check ② matches

the live game is built from this exact source, nothing else.

① + ② both match

what you see (source) is what runs (game). No room for hidden code.

Don't want to compile? Two lighter quick checks: ① open the same Game client CID through different gateways (ipfs.io, dweb.link) — you should get identical files (content-addressed: change one byte and the CID changes); ② the table's «Secure Table» panel compares your loaded client at runtime and shows locked / mismatch / not pinned.

Honest boundary: this reproduction proves the client running in the player's browser. The backend relay server (worker) is out of scope — but you don't need to trust it: the public client source above already proves the worker is a dumb relay that only sees ciphertext and cannot deal cards, remove players, or change results. Full guide: REPRODUCIBLE_BUILD.md.

每手自带 4 灯公平校验（自动，无需操作）

每局结束的瞬间，浏览器自动跑 4 项校验并在桌面亮一个覆盖层：① 牌堆完整（52 张唯一、无重复）·② 全员参与洗牌（每位玩家都完成 shuffle + lock）·③ 记录指纹一致（canonicalHandHash 可与其他玩家比对）·④ 签名齐全。通过盖"已验证"印，异常红灯并提示下载证据。无需任何命令行；只在看到红灯或想自己再确认时再走下面的复验流程。

下载并在本机重放一局牌

在牌桌左上角打开「安全牌局」面板。

点「下载」，保存本局 transcript JSON。

在核心源码目录安装依赖，运行 verifier。

npm ci

npm run verify:transcript -- /path/to/transcript.json

输出通过，即代表本局的 hash-chain、事件顺序、签名格式、下注、奖池与结果都能在你本机重放复验。篡改 transcript 中任意关键字段，verifier 会报错或给出警告。

Every hand auto-runs a four-light fairness audit (no action needed)

The moment a hand ends, the browser automatically runs four checks and shows an overlay on the table: ① deck integrity (52 unique, no duplicates) · ② all players shuffled and locked · ③ matching record fingerprint (canonicalHandHash, exportable for cross-player comparison) · ④ signatures complete. A pass stamps "verified"; a warn lights red and offers the evidence for download. No command line required; only follow the steps below when you see a red light or want to confirm a hand yourself.

Download and replay a hand on your own machine

Open the Secure Table panel in the upper-left table tools.

Click Download to save the hand transcript JSON.

In the core source directory, install dependencies and run the verifier.

npm ci

npm run verify:transcript -- /path/to/transcript.json

A passing result means the hand's hash-chain, event order, signature format, bets, pot, and outcome can all be replayed on your own machine. Tampering with any important transcript field makes the verifier fail or warn.

为什么官方踢不了人Why the operator can't remove a player

这是「轮流加密」扑克：开局时，牌桌上每个人都用自己的私钥，对整副牌轮流加了一层锁。要翻开任何一张牌，必须每个人都用各自的钥匙解开自己那层——少一个人，那张牌就永远解不开。

因此「谁在座、这手牌能不能继续」完全由各玩家浏览器里的密钥决定，不由服务器决定：

服务器（worker）只是一个「哑巴中转」：它只转发各方已签名的消息，自己既没有任何人的私钥，也无权改动牌局状态。你在上面第 1 步校验过的公开源码里就能确认这一点。

服务器断开某个连接，最多只能触发对方「自动重连」；它无法占据座位、无法替谁解牌、也无法把谁判负——这些都需要对应玩家的私钥，而私钥只存在各自的浏览器里。

所以当有人彻底离开、缺了他那把钥匙时，这手牌在数学上就无法继续——只能整桌作废、各自重开。这不是官方踢人，而是密码学的硬限制，对官方和玩家一视同仁。

一句话：官方就算想踢人或顶替你，技术上也做不到——它手里没有你的钥匙。上面第 1 步证明了「线上代码 = 这份公开源码」，你可以亲自读这份源码，确认服务器确实只是中转。

This is “take-turns encryption” poker: at the start of a hand, every player locks the whole deck with their own private key, one layer each. To reveal any card, every player must peel off their own layer with their own key — if even one player is missing, that card can never be opened.

So “who is seated, and whether the hand can continue” is decided entirely by the keys in each player's browser, not by the server:

The server (worker) is only a dumb relay: it forwards each side's signed messages and holds nobody's private key and no authority to change game state. You can confirm this in the public source you verified in Step 1.

If the server drops a connection, the most it can do is trigger that player's auto-reconnect. It cannot seize a seat, decrypt cards for anyone, or declare anyone the loser — all of that needs the relevant player's private key, which lives only in their browser.

That's why, when someone leaves for good and their key is gone, the hand mathematically cannot continue — the table is voided and everyone restarts. This is not the operator kicking anyone; it's a hard cryptographic limit that applies equally to the operator and the players.

In short: even if the operator wanted to kick or impersonate you, it technically cannot — it does not hold your key. Step 1 above proves “the live code = this public source,” so you can read that source yourself and confirm the server is only a relay.

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

开源代码Source code

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

安全白皮书 · Whitepaper

安全白皮书：安全与攻击模型

这一页说明本研究如何把"运营方控牌、偷看底牌、篡改牌局、事后改记录"放进可验证的证据边界：发牌在玩家浏览器的协议中形成，中继只转发消息，事件进入签名 hash-chain transcript，并可由本地 verifier 重放。

Whitepaper

Security whitepaper: security and attack model

This page explains how Fair Poker places operator card-control, hole-card peeking, tampering, and after-the-fact rewriting inside a verifiable evidence boundary: dealing is formed in the player browser protocol, the relay only forwards messages, events enter a signed hash-chain transcript, and any of it can be replayed by the local verifier.

发布事实Release facts

Official domain

https://fairpoker.app

Game client CID

Read from canonical release JSON

Source package CID

Read from canonical release JSON

Source fingerprint

Read from canonical release JSON

权威发布身份：请用牌局客户端 CID、源码包 CID、源码指纹和压缩包 SHA256 对照 source/release.json 与 ai.json。若缓存页面、镜像或 AI/搜索摘要显示另一组组合，应视为过期副本。

官方控牌边界：在已公布的 Game client CID 与可本地复验的 transcript 下，官方/中继无法在保持 verifier 通过的前提下伪造或篡改签名事件、指定某玩家拿到特定牌、偷看未公开底牌或事后改赢家。私有发牌消息端到端加密发给收牌方，中继只见密文、拿不到逐卡解密钥。这是"对照可验证产物"的主张，不是"相信隐藏服务器或外部徽章"。

Authoritative release identity: compare the Game client CID, source package CID, source fingerprint, and archive SHA256 against source/release.json and ai.json. If a cached page, mirror, or AI/search snippet shows a different combination, treat it as a stale copy.

Operator-control boundary: under the published Game client CID and a transcript that verifies locally, the operator/relay cannot forge or alter signed events, choose a target player's card, read unrevealed hole cards, or rewrite winners while keeping the verifier passing. Private dealing messages are end-to-end encrypted to the recipient, so the relay sees only ciphertext and cannot read per-card decryption keys or any hidden hole card. This is an artifact-verification claim, not a hidden-server or external-badge trust claim.

核心结论：伪装浏览器、改 User-Agent、改语言/时区/IP 等，最多影响脱敏的安全提示；它不能让攻击者直接看到别人的底牌。底牌需要对应玩家浏览器中的逐牌解密钥，解密钥只在发给该玩家或公开摊牌时出现。

运行时权力边界：Cloudflare Worker 只为签名消息排序、转发，并报告谁在线；它不计算座位、回合、轮到谁、赢家或筹码——这些局内逻辑已从中继移除（可在源码 buildRoomState 里查到只剩在线状态）。每个浏览器用同一套确定性 reducer，从签名事件日志算出全部牌桌状态；两端读同一份日志必然算出一致结果，刷新/重连后从日志重新算出完全相同的状态。没有任何协议路径把任何玩家踢出牌局、没收筹码、强行下一局、改写赢家或偷看未公开底牌。中继断 socket 只会触发玩家端自动重连，不能改变牌局状态或夺座位/筹码——并且这种事件可归因、可记录。

攻击面与防护边界

攻击手段

系统防护

验证结果

官方/中继试图把玩家踢出牌局或没收筹码

协议层不存在"操作员踢人"事件类型，也不存在中心化裁判。下注、弃牌、坐离都必须来自玩家本人的签名行动；无法继续才走全员共识作废+全额退还。中继切断 WebSocket 只触发玩家端指数退避自动重连，不改变状态。

中继没有任何协议路径单方移除玩家、没收筹码或改写赢家；这类异常切断可被归因记录。

刷新、网络抖动或强制跳转想把你"挤出"牌桌

浏览器为唯一权威：座位/底池/轮到谁/赢家全部由你的浏览器用同一套确定性 reducer 从签名事件日志算出，不依赖中继的房间状态。重连后按 sinceSeq 重放未读消息把日志补齐，浏览器再从日志重新算出与其他人完全一致的状态——轮到你时回归直接续上 turn，不会被"坐离"。

刷新、瞬时断网或网络切换不会把你瞬移到观战席；座位由你的浏览器从签名日志算出，中继对你在场与否的判断永远不能反过来把你拉下桌。

试图偷看别人底牌

每张牌需要多方逐步解密。私有发牌的逐卡解密钥用收牌方公钥端到端密封（RSA-OAEP），并绑定 sender / recipient / round / cardOffset，重定向到其它人或卡位的密文会被拒收。逐卡解密钥仅在当前这一手牌进行期间暂存于本机，牌局一结束即删除，不长期保留。

中继全程只看到密文，拿不到逐卡解密钥与未公开底牌；其他玩家只会收到发给自己的私有消息，密钥重发到错位置会被绑定校验拒掉。

篡改下注、弃牌、发牌、出场顺序或结果

每个事件由玩家签名，并绑定 tableId 与 sessionNonce；接收端校验签名、sender、payload hash、桌号与会话序号；transcript 用 hash-chain 记录顺序与内容。事件结构通过严格 schema 校验（牌堆须 52 张合法密文、下注须非负安全整数、密钥长度受限），畸形/越界事件直接拒收。

改事件、删事件、换顺序、改赢家、跨桌重放或会话内重放，都会破坏签名、桌号绑定、hash-chain replay 或 schema 校验。

中继服务器偷牌、控牌或决定牌序

使用 Cloudflare Worker 作为轻量 WebSocket 边缘中继，没有传统发牌服务器或自建 VPS 后端；中继只转发签名消息，不充当发牌方，不持有玩家签名私钥或账号密钥库。私有发牌端到端密封；牌序由所有玩家共同 shuffle + lock。

中继不能伪造或篡改签名事件，也不能像中心化 RNG 服务器一样单方决定牌序；私有发牌端到端加密，中继看不到逐卡解密钥与未公开底牌。

中继 token 落入访问日志、代理或 CDN

中继鉴权 token 改走 WebSocket 子协议（Sec-WebSocket-Protocol），不再放在 URL 查询串中；服务端按 Chrome 149+ 规范 echo 回包。

token 不进入 URL 访问日志、代理日志或 CDN 缓存键，无法被外部审计/日志归集者收集。

账号密码或本地密钥被盗

账号密钥库用密码派生密钥本地 AES-GCM 加密；登录改发客户端 PBKDF2 派生的 authSecret，服务端只存其哈希、永远不接触明文密码，无法即时解开密钥库冒充玩家。

账号安全与发牌公平分层处理；身份恢复材料不参与牌序生成或赢家计算；服务端持库者也不能即时解开你的密钥库。

玩家串通、共享屏幕或主动报牌

系统可显示脱敏的伙牌安全信号与同网络/同设备线索。

这类线下行为不改变"服务器不发牌、transcript 可复验"的证据链——但密码学也无法消灭线下串通（如实披露）。

替换前端代码或假冒官网

正式牌局客户端以 IPFS CID 固定；公开源码包有 SHA256 与 source fingerprint；浏览器在运行时拿 ai.json 中的权威 CID 与当前页面 CID 比对，安全面板亮"已锁定 / 不符 / 未从固定入口运行"。source fingerprint 覆盖认证、传输、启动、身份等完整信任边界文件，不仅是发牌核心。

替换前端、伪造镜像或非固定入口进入都会在安全面板触发不匹配状态；任何篡改可对照 SHA256 与 fingerprint 重新核验。

红队实测 · Round 1

第一轮模拟攻击日志

发布白帽悬赏前，我们先以攻击者视角对研究原型做了一轮红队测试，覆盖 10 类攻击。对每一类，我们都先尝试真正打穿、再如实记录结果：能打穿的，写明怎么打穿、怎么修、是否已闭环；打不穿的，也照实写"已防护"。下面是这一轮的完整日志。

10模拟攻击类别

5曾可利用 · 已全部修复闭环

4实测未被打穿

1行业固有 · 仅检测

编号

模拟攻击

我们怎么测的

结论与现状

R1·01

仅凭公开参数推断隐藏牌（二次剩余残差泄露）

用线上真用的加密库与真实密钥跑完整发牌，以"只有公开参数、零解密钥"的攻击者视角推断每张暗牌。

已修复闭环一度可把每张暗牌缩到约 13 种；现牌面改用二次剩余编码，残差指纹归零，PoC 复验泄露＝0 bit。

R1·02

弱加密参数被算力破解

评估发牌加密的密钥位数与可行攻击成本。

已修复闭环原参数偏弱；现模数提升至 2048 位（1024 位质数），离散对数不可行，并设 2048 位上限。

R1·03

运营方中间人偷底牌

模拟恶意中继抢先注入伪造公钥，试图截获私发的逐卡钥匙。

实测未打穿每张牌含玩家本地、永不出网的"自钥匙"层，缺它无法还原任何未摊牌底牌。

R1·04

恶意发牌者用"叠牌/重复牌"做假牌堆

让首位洗牌者用非法牌堆（如重复牌）开局，跑完整流程看是否被接受。

已修复闭环一度可用假牌堆开局；现开牌时一旦发现同一张牌出现两次即判篡改、自动作废退还。

R1·05

伪造或篡改他人的签名动作

注入未签名／签名无效的伪造事件，冒充他人下注、弃牌。

实测未打穿实时强制验签，未签或验签失败一律丢弃；攻击者造不出他人私钥的签名。

R1·06

非法下注（越筹码／抢回合／负数注）

直接向牌局引擎灌入越界与非法金额的下注动作。

实测未打穿引擎校验非负整数、不超过自身筹码、不到回合即拒绝。

R1·07

中继自当裁判，篡改回合或座次

检查局内判定是否依赖中继下发的房间状态。

实测未打穿座位、回合、轮到谁、赢家、底池均由各玩家浏览器用同一套 reducer 从签名事件本地算出；中继已降为哑中继，房间状态只剩"谁在线"提示，不参与任何局内判定。

R1·08

单方面作废、躲掉一手要输的牌

模拟全程在线的玩家谎称"打不下去"以触发作废退款。

已修复闭环一度可借此赖账；现仅真断线／已暂停才作废退款，在线"赖账"被当作弃牌、照常输掉。

R1·09

玩家串通、多开、线下报牌

同一人用多账号同桌互通信息。

行业固有 · 仅检测所有线上扑克都无法用密码学根除线下串通；我们提供启发式合谋风险信号，并如实披露这一边界。

R1·10

超大参数让全场卡死（拒绝服务）

伪造一个把加密位数设到极大值的开局事件。

已修复闭环一度可让全场客户端卡死；现参数设 2048 位上限，超大请求被夹住。

为什么连"被打穿过"也照实写？因为真实的红队一定有打穿项——我们更愿意展示"发现 → 修复 → 闭环"的完整能力，而不是声称从无破绽。上面 5 项"已修复闭环"都附带可复现的攻击脚本与全套测试验证（498 项测试全绿），并已随本次发布上线。

红队实测 · Round 2

第二轮模拟攻击日志

第二轮我们把范围扩大、强度加深，钻进协议层、中继层和密码学退化这些更深的地方。好消息：原型大体扛住了——只在"玩家能不能踢玩家"上发现一个真漏洞并已修复闭环；其余深层向量经测试未被打穿。我们照例把打不穿的也逐条列出，并诚实标注一个待随状态重构加固的设计项。

7深层攻击向量

1发现并修复闭环

5实测未被打穿

1已披露 · 随状态重构加固

编号

模拟攻击

我们怎么测的

结论与现状

R2·01

玩家踢玩家（占用他人 peerId 把人顶下线）

用受害者的 peerId（即其广播签名公钥的哈希，同房间人人可算）发起连接，触发中继"重复会话"踢人。

已修复闭环中继现拒绝跨账号抢占同一 peerId——只有同一账号能替换自己的会话，别人无法借此把你顶下线。

R2·02

边池 / all-in 分配错误、凭空造币

构造多人 all-in 的多层边池 + 平局拆分，逐场景核对筹码守恒与归属。

实测未打穿分配正确且筹码严格守恒，未发现多付 / 少付 / 造币。

R2·03

用退化 / 错误解密钥操纵或偷牌

让参与者用退化加密指数，或在揭示时故意发错误解密钥。

实测未打穿最多让该牌解不开而触发作废，无法把牌翻成指定值，也偷看不到。

R2·04

跨手 / 跨轮重放旧事件污染新局

把上一手的发牌 / 解密事件重放进新一手。

实测未打穿事件按轮号作用域，并绑定签名 / 桌号 / 会话随机数，跨轮重放无效。

R2·05

重连重放偷别人底牌

伪造 sinceSeq / peerId 重连，试图拉到发给别人的私有事件。

实测未打穿中继按收件人过滤私有事件，且私有事件本就端到端密封——拉到也解不开。

R2·06

中继分叉（给不同人发不同事件）致状态分裂

模拟中继向不同玩家投递不同的事件子集。

实测未打穿各浏览器独立重算、分歧可由共识检测；属已知的"连线控制"边界，不会造成可传播的盗取。

R2·07

局中改设置 / 开局缺"房主"权威

任意玩家 emit updateSettings / newRound 操纵盲注位或参与顺序。

已披露 · 待加固当前无房主权限校验；不影响发牌公平与筹码守恒，列为状态重构的路线图项。

第二轮小结：越往深处钻，越能看出底子——这一轮 7 个更刁钻的向量里，只有 1 个真打穿（且已修复闭环），其余要么被现有设计挡住、要么属于已公开承认的连线边界。我们继续坚持"打穿的照实写、打不穿的也照实写"。

红队实测 · Round 3

第三轮模拟攻击日志

第三轮我们改用"真编译记分员 + 真加密库"的直连注入：不改客户端，只用浏览器控制台一行命令，专攻"动钱"的记分员授权层和发牌密码学。这一轮没有粉饰——我们确实打穿了 4 个真洞（任一玩家一行命令就能逃账 / 销毁筹码 / 偷整池 / 偷看全桌底牌），并已逐个修复、各配可复现的 PoC 测试闭环。另有 2 项属"按预期保留"的设计内行为（中继排序边界、友谊桌一人多座），照例如实披露。

6深层攻击向量

4真打穿 · 已修复闭环

2设计内 · 已披露

0未修复的真洞

编号

模拟攻击

我们怎么测的

结论与现状

R3·01

装死 / 伪造"散场"信号逃掉必输局并退款

在记分员上注入一条裸 hand/result，试图把进行中的牌局当作废、把已下注的筹码退回。

已修复闭环记分员不再认裸 hand/result 当作废——退款只认"在座玩家全员签名同意"或客观掉线凭据（cannotContinue）。逃账被堵，附 PoC 测试。

R3·02

局中按"重开"销毁锅里筹码 / 塞重复的自己

牌局进行中注入 newRound（重置 / 覆盖局号 / 名单塞两个自己），试图让锅里的筹码凭空蒸发或一人占两座。

已修复闭环记分员现做：同局号幂等不覆盖、未结算不许开新局、座位名单去重并校验≥2 人。筹码不再被销毁，重复座位被剔除，附 PoC 测试。

R3·03

喊"对面超时了"折叠任意对手、偷整池

注入 autoFold 把对手的牌掀掉直接赢池：既试"指向并非当前行动的对手"，也试"先把回合让给对手、紧接着秒判他超时"。

已修复闭环中继给每条消息盖"服务器收件时间戳"（可信时钟），记分员只在 ① target 确是当前该行动的人、且 ② 时间戳显示真的过了超时秒数时才判弃牌——"任意时刻折叠任意对手"与"0 秒抢判超时"两种偷法都被堵死；真实超时自动弃牌、牌局继续的体验不变。附 PoC（抢跑被拒 / 真超时正常）。

R3·04

首家塞弱 / 合成 / 光滑模数，零钥匙偷看全桌底牌

让第一个洗牌的人广播一个一捅就开的加密模数（如 {p:15,q:21}、大合数、或 p−1 全是小因子的"光滑"素数），仅凭密文反推底牌。

已修复闭环收到模数即强校验：每个素数≥1024 位、Miller–Rabin 素性、且 p−1 含可验证的大素因子（抗 Pohlig–Hellman）；生成端同步改为产此结构的素数。弱 / 合数 / 光滑模数一律拒收，附 PoC 测试。

R3·05

中继靠重排消息先后顺序改输赢

模拟中继对同一批签名事件用不同投递顺序，观察能否改变筹码归属。

设计内 · 已披露各浏览器独立重算、分歧可由共识检测，属已公开的"连线控制"边界；本轮按预期保留，不计为待修真洞。

R3·06

一人戴多个面具坐同一桌

同一账号用多个身份在同桌占多座。

设计内 · 已披露play-money 友谊桌按预期允许，靠对账 / 告警约束；不影响发牌公平与筹码守恒，本轮按预期保留。

第三轮小结：这一轮我们不挑软柿子——直攻"动钱"的记分员与发牌密码学，结果确实揪出 4 个真洞（逃账 / 销毁筹码 / 偷池 / 偷牌），并已逐个修复、各配可复现 PoC 闭环；另 2 项是已公开承认的设计内边界。打穿的照实写、修好的给证据，是我们一以贯之的原则。

红队实测 · Round 4

第四轮模拟攻击日志

第四轮我们做了两件事：①把前三轮 23 个项目在"改了大量代码之后"全部重测一遍（确认旧洞没被新改动改活）；②换更狠的视角钻得更深。复审阶段如实标出 2 个真打穿并各附修法；随后我们把能根治的当场修掉：R4·01（中继时间戳）已修复闭环（自动弃牌改为自我授权、彻底不再信中继时钟，598 项测试全绿并复跑了攻击 PoC）；R4·08（全下掉线赖账）经深入评估属去中心化扑克在"无可信服务器、无零知识证明"下的固有取舍——简单的"托管钥匙/没收筹码"都会顾此失彼（见该行说明），故如实披露、列入零知识可验证发牌的根治路线，当前保留对官方最安全的"退款"处理。随后的全面复查又揪出 2 个真问题并已当场修复：R4·11（红桃A 因编码成"1"而在加密牌堆里露馅）、R4·12（玩家自助复验工具与新编码不同步、认错牌），均已修好并复跑验证。

12深度 + 回归向量

4真打穿（3 已修复闭环 · 1 待根治）

7实测未被打穿

1设计内 · 已披露

编号

模拟攻击

我们怎么测的

结论与现状

R4·01

官方中继伪造"超时时钟"强折对手、吞争议池

用真记分员对同一条弃牌指令对比：诚实的服务器收件时间 vs 中继自己填的时间。

已修复闭环原先堵"喊超时偷牌"靠的是中继盖的时间戳，而该时间戳不进签名、不进牌局指纹，恶意中继与某座位合谋即可伪造它强折一个在场对手。已修复：自动弃牌改为"自我授权"——只有玩家本人客户端（自折）或目标确已掉线才会被弃牌，记分员不再用中继时间戳判定超时。中继即便伪造时间戳也折不动一个在场对手（没有他的签名私钥）。真超时仍由本人客户端自折、掉线者可被折以免卡桌，功能不变；598 项测试全绿并复跑了本攻击的 PoC（伪造时间戳已无效）。

R4·02

打到一半喊"作废"逃掉必输局并退款（E-1 回归）

注入裸"散场"信号、孤张作废票、以及在线状态下喊"打不下去"。

实测未打穿退款只认"在座玩家全员签名同意"或客观掉线凭据；在线赖账一律当作弃牌、照常输掉。

R4·03

按"重开"销毁锅里筹码 / 塞重复的自己（E-2 回归）

局中重开、座位名单塞两个自己、覆盖已有局号。

实测未打穿同局号幂等不覆盖、未结算不许开新局、座位去重并校验≥2 人，筹码不被销毁。

R4·04

首家塞弱 / 合数 / 光滑加密模数，零钥匙偷看全桌

用真校验器收 {15,21}、大合数、p−1 全是小因子的"光滑"素数、以及相等模数。

实测未打穿全部拒收——其中一个 1024 位以上的真素数也仅因结构偏弱被拒；诚实生成的模数正常通过、不误伤。

R4·05

海量乱来的指令想凭空生 / 灭筹码

8000 条随机 + 畸形 + 对抗日志（负注、天价、小数、垃圾身份、越界局号、重复名单）灌进真记分员。

实测未打穿筹码守恒铁桶：零铸币、零销毁、零负数、零崩溃。

R4·06

拦截 / 重定向别人的底牌解密钥匙

拦截密封钥匙，并把它改当成别的牌位 / 局 / 发件人来开。

实测未打穿钥匙端到端锁定收件人，并绑定牌位 / 局 / 发件人；换人、换牌位、换局全都开不了，密文被篡改即拒。

R4·07

顶人下线 / 塞系统幽灵占座 / 打乱顺序改输赢

跨账号抢占他人身份、让"系统中继"混进玩家名单、同一套事件用多种投递顺序。

实测未打穿（连线边界已披露）跨账号抢身份被拒、系统幽灵进不了牌桌；打乱投递顺序确会改变"中途归属"，但筹码仍严格守恒、各端可凭记录指纹对账发现分歧——属早已公开承认的连线控制边界。

R4·08

全下后掉线，赖掉必输局、退回本金

真记分员：两人全下后，快输的一方离线并扣住自己的公共牌钥匙。

已披露 · 待零知识根治全下后只剩翻公共牌。快输一方掉线且不发解牌钥匙 → 对手翻不出板 → 系统判"打不下去" → 整把作废退款。不是偷钱（双方都退回本金），但把"大概率输"变成"100% 退款"，反复用即占诚实对手便宜。在线赖账仍被堵，只剩"真掉线"这条。深入评估后，简单修法都顾此失彼：①"全下即托管全部公共牌钥匙"——诚实客户端本就这么做（所以真断线能照常分胜负），但挡不住故意改造客户端、就是不发钥匙的人；②"掉线就没收判负"能去掉赖账，却给了官方新作弊面——掌控连线的官方可在钥匙广播前掐断受害者连接逼其判负，反而踩"官方只控连线"的红线。真正的根治是零知识可验证发牌（公共牌可凭公开承诺独立翻出、无需任何人事后配合），已列入路线图。当前保留对官方最安全的"退款"处理，并可在账号层对反复掉线赖账做检测告警。

R4·09

伪造 / 篡改他人签名动作、跨桌重放

真签名后篡改下注金额、冒名、跨桌搬运、改会话随机数。

实测未打穿验签覆盖整条信封，改任一处即失效；造不出他人私钥的签名；跨桌 / 跨会话重放被绑定校验拒掉。

R4·10

撬开别人的保险箱 / 账号

真加密：用错密码、别人的密码、以及服务端所存的登录凭据去开保险箱。

实测未打穿保险箱用密码本地加密，与服务端登录凭据域分离；错密码、他人密码、服务端凭据都开不了，数据库查询全参数化、无注入。（另有登录限速、会话轮换、常量时间比较三项纵深加固待补——不让任何人作弊，仅为防穷举 / 长效会话。）

R4·11

零钥匙在加密牌堆里认出某张特定牌（红桃A 不动点）

用真发牌编码 + 真模数加密整副牌，逐张看公开密文里有没有"一眼能认出"的。

已修复闭环原编码把红桃A 记成数字"1"，而"1"的任何加密都还是"1"（不动点），导致它在公开加密牌堆里密文恒为"1"、零钥匙就能认出该牌及其位置（其余 51 张安全）。已修复：发牌编码改为 (序号+1)²（值域 4–2809），仍是完全平方（保持原有的零残差泄露性质），但避开了 0/1 不动点——真加密牌堆里再无"一眼可认"的密文。附 PoC（红桃A 不再露馅）+ 全量测试绿。

R4·12

玩家"自助复验"工具认错牌

把客户端真实编码喂给独立复验脚本的认牌逻辑，逐张核对。

已修复闭环独立复验脚本的"认牌本子"还停在旧编号，与客户端的平方编码不同步——52 张只认对 1 张、其余解错或报错（验签 / 牌堆完整 / 记录指纹等不依赖认牌的检查不受影响）。已修复：两份复验脚本改为"先开方还原序号再解牌"，与新编码对齐；现 52 张全部正确解出。"自己复验"链恢复可靠。

第四轮小结：这一轮把前三轮 23 项全部重测，确认大量改动后旧洞没有复活；地基（验签 / 底牌端到端密封 / 赢家由真解出的牌算 / 账号 / 筹码守恒）依旧扎实，7 个深层向量实测未被打穿。我们也诚实揪出 2 个真洞：官方层的 R4·01（中继时间戳超出"只控连线"）已修复闭环——自动弃牌改为自我授权、彻底不再信中继时钟；玩家层的 R4·08（全下掉线赖账）是去中心化扑克的固有取舍，简单修法会顾此失彼（见该行），故如实披露、留待零知识可验证发牌根治，当前保留对官方最安全的退款处理。打穿的照实写、能根治的修掉给证据、暂不能两全的如实说明，是我们一以贯之的原则。

全面复查 · Full re-audit

前三轮 23 项逐条复跑 + 新增 8 向量

不止重测结论——我们把前三轮 23 个攻击在当前代码上逐条用真代码重新打了一遍（覆盖验签、发牌加密、记分员动钱、中继、账号全栈），并新增 8 个角度。除前述 R4·01（已修复）、R4·08（已披露）外，全部实测未被打穿，旧洞无一复活。

31逐条复查项

26实测未被打穿

1已修复闭环

4设计内 · 已披露

编号

模拟攻击

当前代码复跑结论

R1·01

仅凭公开参数推断暗牌（残差泄露）

未打穿真模数勒让德符号：52 张牌指纹一致、泄露 0 比特

R1·02

弱加密位数被破解

未打穿位数下限 1024（2048 位模数），上限封顶

R1·03

运营方中间人偷底牌

未打穿缺对方逐卡钥匙还原不出任何底牌（大随机/非平方均解不出）

R1·04

用重复牌做假牌堆

未打穿真审计：重复密文当场判篡改告警

R1·05

伪造/篡改他人签名动作

未打穿真 ECDSA：篡改/冒名/跨桌重放全拒

R1·06

非法下注（越筹码/抢回合/负数）

未打穿校验非负安全整数、不超自身筹码

R1·07

中继自当裁判改回合/座次

未打穿座位/回合/赢家全由浏览器从签名日志算

R1·08

单方作废躲掉必输牌

未打穿退款只认全员签名同意或客观掉线凭据

R1·09

玩家串通/多开/线下报牌

行业固有 · 仅检测密码学无法根除线下串通，提供合谋信号

R1·10

超大参数让全场卡死

未打穿位数夹在 1024–2048，超大被夹住

R2·01

玩家踢玩家（占用他人身份）

未打穿中继拒绝跨账号抢占同一身份（返回 409）

R2·02

边池/all-in 分配错误、凭空造币

未打穿短栈封顶正确、严格守恒、平局平分（真分配函数）

R2·03

用退化/错误解密钥操纵或偷牌

未打穿错钥匙翻不成指定值、还原不出，只会得无效牌→作废

R2·04

跨手/跨轮重放旧事件污染新局

未打穿事件按局号作用域，陈旧事件碰不到现局

R2·05

重连重放偷别人底牌

未打穿私有事件按收件人过滤且端到端密封

R2·06

中继分叉致状态分裂

设计内 · 已披露各端独立重算、分歧可由共识检测

R2·07

局中改设置/缺房主权威

未打穿改设置对记分员无任何动钱权

R3·01

装死/伪造散场逃账退款

未打穿裸散场信号不退款（同 R1·08）

R3·02

局中重开销毁筹码/塞重复的自己

未打穿同局号幂等、去重、未结算不许开新局

R3·03

喊"对面超时"折叠对手偷整池

已修复闭环本轮改自我授权（见 R4·01），彻底不再信中继时钟

R3·04

塞弱/光滑模数零钥匙偷看全桌

未打穿弱/合数/光滑/相等模数强校验全拒（见 R4·04）

R3·05

中继靠重排消息改输赢

设计内 · 已披露重排会改中途归属但筹码严格守恒、可对账

R3·06

一人戴多面具坐同桌

设计内 · 已披露友谊桌按预期允许，靠对账/告警

平局平分（含奇数筹码）

未打穿平分守恒、单数筹码完整归账

事件格式模糊（畸形牌堆/超大整数/原型污染）

未打穿真校验器畸形全拒、合法不误伤、原型污染进不去

记录链式指纹篡改（增/删/改/换序）

未打穿真复验器对改/删/换序/插入重复全部识破

记录指纹确定性/原型污染

未打穿字段顺序无关同指纹、NaN/无穷被拒、无污染

反复补码刷分

未打穿补码记入买入，净盈亏为负不可刷正，守恒

坐离/回桌操纵回合或逃盲

未打穿坐离扣不回已下盲注、被判弃，守恒

非在座玩家投作废票/喊停

未打穿记分员校验在座名单，外人投票被忽略不退款

认领他人底牌（改牌位/收件人）

未打穿钥匙绑定收件人/牌位/局/发件人，重定向全拒（见 R4·06）

每一手都自带 4 灯公平校验

每局结束后，浏览器自动跑 4 项校验并以可视化覆盖层告知结果：① 牌堆完整（52 张唯一、无重复）·② 全员参与洗牌（每位玩家都完成 shuffle + lock）·③ 记录指纹一致（可与其他玩家比对 canonicalHandHash）·④ 签名齐全。通过盖"已验证"印，异常红灯并提示下载证据。这是被动证据之外的主动告警层——可疑事件不需要你自己去 grep transcript。

用户建议

只从 fairpoker.app 或官网公布的 IPFS CID 进入牌桌。

重要牌局优先注册账号、使用强密码，并避免在装有可疑扩展的浏览器里玩。

留意每手结束的 4 灯公平校验覆盖层；任何红灯都可在牌桌安全面板下载证据。

下载 transcript 后，可按独立验证指南在本地亲手复验。

Key conclusion: spoofing User-Agent, browser language, timezone, IP, or account/device identity can affect sanitized safety signals, but it does not grant access to other players' private cards. Hole cards require per-card decryption keys held by the relevant player's browser, released only to that player or during public reveal.

Operator power boundary: the Cloudflare Worker only orders and forwards signed messages and reports who is online; it computes no seats, rounds, turn order, winners, or chips — that game logic was removed from the relay (its buildRoomState now returns presence only). Every browser folds the signed event log into the full table state with the same deterministic reducer, so two browsers reading the same log necessarily agree, and a refresh/reconnect re-derives the identical state. There is no protocol path for the relay to kick a player out of a hand, seize chips, force the next deal, rewrite winners, or peek at unrevealed hole cards. The relay dropping a socket only triggers client-side auto-reconnect — it cannot change game state or take a seat or chips, and any such drop is attributable and recorded.

Attack surface and defense boundary

Attack

Defense

Verification result

Operator / relay tries to remove a player or seize chips

The protocol has no "operator kick" event type and no centralized referee. Bets, folds, sit-outs must come from the player's own signed action; only when continuation is impossible does a unanimous-void path refund the hand in full. The relay closing a WebSocket only triggers exponential-backoff auto-reconnect on the client and changes no state.

The relay has no protocol path to unilaterally remove players, seize chips, or rewrite winners; abnormal drops are attributable.

Refresh, network jitter, or forced redirect tries to push you off the table

Browser is the sole authority: seats, pot, turn order, and winner are all computed by your browser with the same deterministic reducer over the signed event log — never from relay-pushed room state. After reconnect, sinceSeq replays missed messages to complete the log, then the browser re-derives state identical to everyone else's; returning while it's your turn resumes that turn instead of sitting you out.

Refresh, brief network drops, or network switches cannot teleport you to the spectator rail; your seat is computed by your browser from the signed log, so the relay's opinion on your presence never overrides it.

Trying to see another player's cards

Cards are revealed through multi-step per-card decryption. Each private decrypt key is end-to-end sealed to the recipient's public key (RSA-OAEP) and bound to sender / recipient / round / cardOffset, so ciphertext redirected to a different recipient or card position is rejected. Per-card decrypt keys are kept on your device only for the duration of the current hand and are erased when it ends; never retained long-term.

The relay only ever sees ciphertext — never per-card keys or unrevealed hole cards. Other players only receive messages addressed to them; keys replayed at a wrong position are rejected by binding checks.

Tampering with actions, deals, ordering, or results

Each event is signed and bound to a tableId and sessionNonce; receivers verify signature, sender, payload hash, table id, and session sequence. The transcript hash-chain preserves order and content. Strict schema validation rejects malformed input (the deck must be 52 valid ciphertexts, bets must be non-negative safe integers, key lengths are bounded).

Edits, deletions, reordering, winner changes, cross-table replay, or in-session replay all break signature, table binding, hash-chain replay, or schema checks.

Relay server tries to peek at, control, or pick the card order

Fair Poker uses a Cloudflare Worker as a lightweight WebSocket edge relay — not a traditional dealing server or self-hosted VPS backend. It only forwards signed messages, never deals cards, and holds no signing keys or vault. Private dealing is end-to-end sealed; the deck is jointly shuffled and locked by every player.

The relay cannot forge or alter signed events nor act like a centralized RNG dealer; it sees neither per-card keys nor unrevealed hole cards.

Relay auth token leaking into access logs, proxies, or CDNs

The relay auth token now travels in the WebSocket subprotocol (Sec-WebSocket-Protocol), not the URL query string; the server echoes it verbatim to satisfy the Chrome 149+ handshake.

The token never enters URL access logs, proxy logs, or CDN cache keys; it is not collectible by external auditors or log aggregators.

Account password or local key theft

The vault is encrypted locally with a password-derived key via AES-GCM. Login sends a client-side PBKDF2-derived authSecret; the server stores only its hash, never touches the plaintext password, and cannot open the vault on demand to impersonate you.

Account security is layered separately from deck generation and winner computation; recovery material does not feed card order or results, and a server that holds the database still cannot open your vault.

Collusion, screen sharing, or telling cards

The system can surface sanitized collusion signals and same-network / same-device hints.

This out-of-band behavior does not change the server-not-dealer, replayable-transcript evidence chain — but cryptography also cannot eliminate off-table collusion (disclosed plainly).

Fake frontend or code replacement

The table client is pinned by IPFS CID; the source archive SHA256 and source fingerprint can be compared against the official release identity. At runtime the browser fetches the authoritative CID from ai.json and compares it with the running CID, and the security panel shows locked / mismatch / not pinned. The source fingerprint covers auth, transport, bootstrap, and identity files — the full trust boundary, not just the dealing core.

Replaced frontends, fake mirrors, or non-pinned entry points raise a mismatch in the security panel; any tampering can be re-checked against published SHA256 and fingerprint.

Red-team · Round 1

Round 1 — simulated-attack log

Before opening a white-hat bounty, we ran our own red-team pass against the research prototype across 10 classes of attack. For each one we genuinely tried to break it first, then recorded the result honestly: where an attack worked, we describe how it worked, how we fixed it, and whether it is closed; where it didn't, we simply mark it defended. The full log is below.

10attack classes simulated

5were exploitable · all fixed & closed

4held under testing

1industry-inherent · detection only

Simulated attack

How we tested it

Result & status

R1·01

Inferring hidden cards from public parameters only (quadratic-residue leak)

Ran a full deal with the exact crypto library and real key sizes used in production, as an attacker holding only public parameters and zero decryption keys.

fixed & closedOnce narrowed every hidden card to ~13 of 52; cards are now encoded as quadratic residues so the residue fingerprint leaks nothing — PoC re-check shows 0 bits leaked.

R1·02

Cracking weak encryption parameters

Assessed the dealing key size and the cost of a feasible attack.

fixed & closedThe old parameters were too small; the modulus is now 2048-bit (1024-bit primes), making discrete-log infeasible, with a 2048-bit ceiling.

R1·03

Operator man-in-the-middle to steal hole cards

Simulated a malicious relay injecting a forged public key first to intercept privately-sealed per-card keys.

held under testingEvery card carries a player-local "self key" that never leaves the device; without it no unrevealed hole card can be reconstructed.

R1·04

Malicious dealer stacking a rigged / duplicate deck

Had the first shuffler start from an illegal deck (e.g. duplicate cards) and ran the full flow to see if it was accepted.

fixed & closedOnce accepted; now if the same card is dealt twice the deck is flagged as tampered and the hand is voided and refunded on the spot.

R1·05

Forging or altering another player's signed actions

Injected unsigned / invalid-signature forged events impersonating others' bets and folds.

held under testingSignatures are enforced live; unsigned or invalid events are dropped, and an attacker cannot produce another player's private-key signature.

R1·06

Illegal bets (over-stack / out-of-turn / negative)

Fed out-of-bounds and illegal bet amounts straight into the game engine.

held under testingThe engine rejects non-integer, negative, over-stack, and out-of-turn actions.

R1·07

Relay acting as referee to alter turn order or seating

Checked whether in-hand decisions depend on relay-pushed room state.

held under testingSeats, turn order, winner, and pot are all computed by each player's browser with the same reducer over the signed events; the relay is now a dumb relay whose room state carries only "who is online" and takes no part in any in-hand decision.

R1·08

Unilaterally voiding a hand to dodge a loss

Simulated a fully-connected player falsely claiming it "cannot continue" to trigger a void-and-refund.

fixed & closedOnce usable to dodge; now only a genuine disconnect / paused hand voids and refunds — a connected player's false claim is treated as a fold and the loss stands.

R1·09

Player collusion, multi-accounting, telling cards

One person using multiple accounts at one table to share information.

inherent · detection onlyNo online poker can eliminate off-table collusion cryptographically; we surface heuristic collusion signals and disclose this boundary honestly.

R1·10

Giant parameters to freeze the whole table (DoS)

Forged a start event setting the encryption bit size to an enormous value.

fixed & closedOnce froze every client; the bit size is now capped at 2048, so oversized requests are clamped.

Why publish the attacks that worked, too? A real red-team always has hits — we'd rather show the full "find → fix → close the loop" capability than claim we were flawless. Each of the five "fixed & closed" items ships with a reproducible attack script and a full test pass (498 tests green), and is already live in this release.

Red-team · Round 2

Round 2 — simulated-attack log

For Round 2 we widened the scope and raised the intensity, digging into the protocol layer, the relay layer, and cryptographic-degeneracy cases. The good news: the prototype mostly held — we found one real vulnerability (a player being able to kick another player) and closed it, while the other deeper vectors held under testing. As always we list the ones that held too, and honestly flag one design item to be hardened with the planned state rework.

7deep attack vectors

1found & fixed / closed

5held under testing

1disclosed · hardening with state rework

Simulated attack

How we tested it

Result & status

R2·01

Player kicking another player (hijacking someone's peerId)

Connected using the victim's peerId (the hash of their signing public key, which is broadcast in every signed event and computable by anyone at the table) to trigger the relay's "duplicate session" eviction.

fixed & closedThe relay now refuses to let one account claim a peerId already held by another account — only the same account can replace its own session, so no one can use this to knock you off the table.

R2·02

Side-pot / all-in mis-allocation or minting chips

Built multi-player all-in side pots plus tie splits and checked chip conservation and ownership case by case.

held under testingAllocation is correct and chips are strictly conserved — no over-pay, under-pay, or minting found.

R2·03

Manipulating or stealing cards with degenerate / wrong decryption keys

Had a participant use a degenerate encryption exponent, or deliberately send a wrong decryption key at reveal.

held under testingAt worst a card fails to decrypt and the hand voids; an attacker cannot flip a card to a chosen value or peek at it.

R2·04

Cross-hand / cross-round replay to corrupt a new hand

Replayed a previous hand's dealing / decryption events into a new hand.

held under testingEvents are scoped by round number and bound to signature / table id / session nonce, so cross-round replay does nothing.

R2·05

Reconnect-replay to steal another player's hole cards

Reconnected with a forged sinceSeq / peerId to try to pull private events addressed to others.

held under testingThe relay filters private events by recipient, and private events are end-to-end sealed anyway — even if pulled they cannot be opened.

R2·06

Relay equivocation (different events to different players) to split state

Simulated the relay delivering different event subsets to different players.

held under testingEach browser recomputes independently and divergence is detectable via consensus; this falls within the known "connectivity control" boundary and yields no propagating theft.

R2·07

Changing settings mid-game / no "host" authority at round start

Any player emitting updateSettings / newRound to manipulate blind positions or seating order.

disclosed · to hardenThere is currently no host-authority check; it does not affect dealing fairness or chip conservation, and is on the state-rework roadmap.

Round 2 takeaway: the deeper you dig, the more the foundation shows — of seven trickier vectors this round, only one actually broke through (and it is fixed and closed), while the rest were either blocked by existing design or fall within an openly-acknowledged connectivity boundary. We keep the same rule: publish the ones that broke and the ones that held.

Red-team · Round 3

Round 3 — simulated-attack log

Round 3 switched to direct console injection against the real compiled scorekeeper and the real crypto library — no client changes, just one console line — targeting the money-moving authorization layer and the dealing cryptography. We did break through 4 real holes (any player, one line, no client patch, could dodge a loss / destroy chips / steal a whole pot / see the whole table), and fixed each with a reproducible PoC. Two more items are by-design behavior (relay ordering boundary, one-person-multi-seat on friendly tables), disclosed as usual.

6deep attack vectors

4truly broke · fixed & closed

2by design · disclosed

0unfixed real holes

Simulated attack

How we tested it

Result & status

R3·01

Playing dead / forging a "table closed" signal to dodge a losing hand and get refunded

Injected a bare hand/result into the scorekeeper to void a live hand and claw back committed chips.

fixed & closedThe scorekeeper no longer treats a bare hand/result as a void — refunds require the unanimous signed consent of seated players, or objective disconnect evidence (cannotContinue). PoC included.

R3·02

Destroying pot chips via "restart" / seating a duplicate of yourself mid-hand

Injected newRound mid-hand (reset / overwrite round number / seat two copies of myself).

fixed & closedSame round number is idempotent, no new hand before settlement, the seat list is deduped and requires ≥2 players. Chips can no longer be destroyed; PoC included.

R3·03

Shout "your opponent timed out" to fold any opponent and steal the pot

Injected autoFold against a non-turn opponent, and the "pass the turn then instantly time them out" steal.

fixed & closedThe relay stamps a trusted server receive-timestamp; the scorekeeper folds only when the target is the actual turn owner AND the timestamp shows the timeout truly elapsed. Both steals are blocked; real timeouts still work. PoC included.

R3·04

First shuffler ships a weak / synthetic / smooth modulus to read the whole table with zero keys

Had the first shuffler broadcast a trivially-openable modulus (e.g. {p:15,q:21}, a large composite, or a "smooth" prime).

fixed & closedOn receipt every prime is checked: ≥1024-bit, Miller–Rabin primality, and p−1 carries a verifiable large prime factor (anti-Pohlig–Hellman); the generator now produces such primes. Weak / composite / smooth moduli are rejected; PoC included.

R3·05

Relay reorders messages to change winners

Simulated the relay delivering the same signed events in different orders to change chip ownership.

by design · disclosedEach browser recomputes independently and divergence is detectable by consensus — the openly-acknowledged connectivity boundary; kept by design this round.

R3·06

One person wears several masks at one table

One account occupying multiple seats at the same table.

by design · disclosedPlay-money friendly tables allow it by design, constrained by reconciliation / alerts; it does not affect dealing fairness or chip conservation.

Round 3 takeaway: we went straight at the money-moving scorekeeper and the dealing cryptography, and it surfaced 4 real holes (dodge / destroy / steal-pot / peek), each now fixed with a reproducible PoC; the other 2 are openly-acknowledged by-design boundaries.

Red-team · Round 4

Round 4 — simulated-attack log

Round 4 did two things: (1) re-ran all 23 items from Rounds 1–3 after a large amount of code had changed, to confirm no old hole had come back to life; and (2) dug deeper with a harsher attacker view. The audit pass recorded 2 real break-throughs with a fix each; we then closed what could be closed: R4·01 (relay timestamp) is fixed & closed — auto-fold is now self-authorized and no longer trusts the relay clock at all (598 tests green, attack PoC re-run). R4·08 (all-in disconnect dodge), on deeper analysis, is an inherent trade-off of decentralized poker without a trusted server or zero-knowledge proofs — the obvious quick fixes each fail (see that row) — so it is disclosed honestly and put on the roadmap for a zero-knowledge verifiable deal, while the current, operator-safest "refund" behavior is kept. The subsequent full re-audit surfaced 2 more real issues and fixed them on the spot: R4·11 (the Heart-Ace leaking because it encoded to "1") and R4·12 (the self-verification tool being out of sync with the encoding and mis-decoding cards) — both fixed and re-verified.

12deep + regression vectors

4truly broke (3 fixed · 1 to root-fix)

7held under testing

1by design · disclosed

Simulated attack

How we tested it

Result & status

R4·01

The operator/relay forges a "timeout clock" to force-fold an opponent and take the disputed pot

Ran the real scorekeeper on one forged auto-fold with an honest server receive-timestamp vs. a relay-chosen one.

fixed & closedThe earlier "claim a timeout" defense trusted the relay's timestamp, which is not signed and not in the hand fingerprint, so a relay colluding with a seat could forge it to fold an on-turn opponent. Fixed: an auto-fold is now self-authorized — a player is folded only by THEIR OWN client (a self-fold) or when they are genuinely unreachable; the scorekeeper no longer uses the relay timestamp to judge a timeout. A relay forging the timestamp can no longer fold a present opponent (it lacks that player's signing key). Real timeouts still self-fold and a disconnected player can still be folded so the table never freezes; 598 tests green with the attack PoC re-run (the forged timestamp is now inert).

R4·02

Void mid-hand to dodge a loss and get refunded (E-1 regression)

Injected a bare "table closed" signal, a lone void vote, and a connected "cannot continue".

held under testingRefunds require unanimous signed consent of seated players or objective disconnect evidence; a connected dodge is treated as a fold and the loss stands.

R4·03

Destroy pot chips via "restart" / seat a duplicate of yourself (E-2 regression)

Restart mid-hand, seat two copies of myself, overwrite an existing round number.

held under testingSame round number is idempotent, no new hand before settlement, seats deduped and ≥2 enforced — chips are not destroyed.

R4·04

First shuffler ships a weak / composite / smooth modulus to peek at the whole table with zero keys

Fed the real validator {15,21}, a large composite, a "smooth" prime (p−1 all small factors), and equal primes.

held under testingAll rejected — including a genuine 1024-bit+ prime rejected purely for a weak structure; an honestly-generated modulus passes, so play is unaffected.

R4·05

A flood of garbage actions tries to mint / destroy chips

8000 random + malformed + adversarial logs (negative bets, huge bets, fractions, junk identities, out-of-range rounds, duplicate rosters) into the real scorekeeper.

held under testingChip conservation is airtight: zero minting, zero destruction, zero negatives, zero crashes.

R4·06

Intercept / redirect another player's hole-card decryption key

Intercepted the sealed key and tried to open it as a different card position / round / sender.

held under testingKeys are end-to-end sealed to the recipient and bound to card position / round / sender; redirecting to a different person, position, or round all fail, and a tampered envelope is rejected.

R4·07

Kick a player / seat a system phantom / reorder messages to change winners

Cross-account claim of someone's identity, the "system relay" sneaking into the roster, and one event set in several delivery orders.

held (disclosed connectivity boundary)Cross-account identity claims are refused and the system phantom cannot be seated; reordering delivery does change a mid-stream result, but chips stay strictly conserved and divergence is detectable via the record fingerprint — the openly-acknowledged connectivity boundary.

R4·08

Disconnect after going all-in to dodge a losing hand and reclaim your stake

Real scorekeeper: after both shove all-in, the side about to lose goes offline and withholds its board keys.

disclosed · root-fix via ZKAfter an all-in only the board reveal remains. A losing player who disconnects and withholds its decryption keys leaves the board unrevealable → the table is voided and refunded. It is not theft (both get their stake back), but it converts a likely loss into a guaranteed refund — repeatedly used, an edge over honest opponents. The connected dodge is still blocked; only genuine disconnect remains. On deeper analysis the obvious fixes each backfire: (1) "escrow all board keys at all-in" — an honest client already does this (so genuine disconnects resolve normally), but it cannot stop a tampered client that simply refuses to publish its keys; (2) "forfeit a disconnected player" removes the dodge but hands the operator a new attack surface — the connectivity-controlling operator could cut a victim's link before its keys broadcast to force a loss, breaching the "connectivity only" boundary. The real fix is a zero-knowledge verifiable deal (the board is recoverable from public commitments with no later cooperation), which is on the roadmap. The current operator-safest "refund" behavior is kept, with account-level detection of repeated disconnect-dodging.

R4·09

Forge / alter another player's signed actions, replay across tables

After a real signature, tampered the bet amount, impersonated, moved across tables, changed the session nonce.

held under testingThe signature covers the whole envelope, so any edit invalidates it; another player's private-key signature cannot be produced; cross-table / cross-session replay is rejected by the bindings.

R4·10

Open someone else's vault / account

Real crypto: open the vault with a wrong password, another account's password, and the login credential the server stores.

held under testingThe vault is encrypted locally with the password and domain-separated from the server login credential; a wrong password, another's password, and the server-stored credential all fail, and DB queries are fully parameterized (no injection). (Three depth-hardening items remain — login rate-limiting, session rotation, constant-time comparison — none of which let anyone cheat.)

R4·11

Identifying one specific card in the encrypted deck with zero keys (Heart-Ace fixed point)

Encrypted the whole deck with the real encoding + a real modulus and scanned the public ciphertexts for any that are trivially identifiable.

fixed & closedThe old encoding mapped the Heart-Ace to the number 1, and 1 is a multiplicative fixed point (1^e = 1 under every key), so its ciphertext was always "1" — identifiable in the public deck with zero keys, along with its position (the other 51 cards were safe). Fixed: the card encoding is now (index+1)^2 (values 4–2809), still a perfect square (preserving the zero residue-leak property) but off the 0/1 fixed points — no ciphertext is trivially identifiable anymore. Ships with a PoC (Heart-Ace no longer leaks) and a green test pass.

R4·12

The "verify-it-yourself" tool mis-decodes cards

Fed the client's real card encoding to the standalone verifier's decode logic, card by card.

fixed & closedThe standalone verifier's card decode still expected the old 1..52 numbering and was out of sync with the squared encoding — it decoded only 1 of 52 cards correctly, mis-decoding or throwing on the rest (signature / deck-integrity / record-fingerprint checks that don't decode cards were unaffected). Fixed: both verifier scripts now take the square root to recover the index before decoding, matching the new encoding; all 52 cards now decode correctly, restoring the self-verification chain.

Round 4 takeaway: re-running all 23 earlier items confirmed no old hole came back after heavy code changes, and the foundation (signatures / sealed hole cards / winners from truly-decrypted cards / accounts / chip conservation) still holds — 7 deep vectors held. We also honestly surfaced 2 real holes: the operator-layer R4·01 (relay timestamp beyond "connectivity only") is fixed & closed — auto-fold is now self-authorized and never trusts the relay clock; the player-layer R4·08 (all-in disconnect dodge) is an inherent trade-off where quick fixes backfire (see that row), so it is disclosed and left for a zero-knowledge verifiable deal, with the operator-safest refund kept for now. Publish the ones that broke and the ones that held, fix what can be rooted out, and plainly explain what can't be had both ways — as always.

Full re-audit

All 23 earlier attacks re-run + 8 new vectors

Not just re-checking conclusions — we re-ran all 23 attacks from Rounds 1–3 against the current code, each one with real code (across signatures, dealing crypto, the money-moving scorekeeper, the relay, and accounts), and added 8 new angles. Apart from R4·01 (fixed) and R4·08 (disclosed) above, every one held under testing and no old hole came back.

31items re-audited

26held under testing

1fixed & closed

4by design · disclosed

Simulated attack

Re-run result on current code

R1·01

Inferring hidden cards from public params (residue leak)

heldLegendre over a real modulus: all 52 share one fingerprint, 0 bits

R1·02

Cracking weak key sizes

heldFloor 1024-bit primes (2048-bit modulus), capped

R1·03

Operator man-in-the-middle to steal hole cards

heldNo per-card key → no hole card (random/non-square all fail)

R1·04

Rigged deck with duplicate cards

heldReal audit flags duplicate ciphertext on the spot

R1·05

Forging/altering another's signed actions

heldReal ECDSA: tamper/impersonate/cross-table replay all rejected

R1·06

Illegal bets (over-stack / out-of-turn / negative)

heldNon-negative safe integer, not over own stack

R1·07

Relay acting as referee for turn/seat order

heldSeats/turns/winner derived by the browser from the signed log

R1·08

Unilateral void to dodge a loss

heldRefund needs unanimous signed consent or objective disconnect

R1·09

Collusion / multi-accounting / telling cards

inherent · detection onlyCrypto can't kill off-table collusion; we surface signals

R1·10

Giant parameters to freeze the table

heldBit size clamped to [1024, 2048]

R2·01

Player kicking another (hijacking an id)

heldRelay refuses a cross-account claim of an id (409)

R2·02

Side-pot / all-in mis-allocation or minting

heldShort stack capped, strictly conserved, ties split (real allocator)

R2·03

Degenerate / wrong decryption keys

heldWrong key can't flip to a chosen value; yields an invalid card → void

R2·04

Cross-hand / cross-round replay

heldEvents scoped by round; stale events can't touch the live hand

R2·05

Reconnect-replay to steal hole cards

heldPrivate events filtered by recipient and end-to-end sealed

R2·06

Relay equivocation splits state

by design · disclosedEach browser recomputes; divergence is consensus-detectable

R2·07

Changing settings mid-game / no host authority

heldupdateSettings moves no chips in the scorekeeper

R3·01

Playing dead / forged "closed" to dodge + refund

heldA bare closed signal does not refund (same as R1·08)

R3·02

Restart to destroy chips / seat a duplicate self

heldSame round idempotent, deduped, no new hand before settlement

R3·03

"Opponent timed out" to fold them and steal

fixed & closedNow self-authorized (see R4·01); never trusts the relay clock

R3·04

Weak/smooth modulus to peek with zero keys

heldWeak/composite/smooth/equal moduli all rejected (see R4·04)

R3·05

Relay reorders messages to change winners

by design · disclosedReorder can shift mid-stream but chips stay conserved & auditable

R3·06

One person, many masks at one table

by design · disclosedPlay-money tables allow it; reconciliation/alerts

Tie / split pot (incl. odd chip)

heldSplit conserves; the odd chip is fully accounted

Event schema fuzz (malformed deck / huge ints / __proto__)

heldMalformed rejected, valid accepted, no prototype pollution

Transcript hash-chain tamper (add/del/edit/reorder)

heldReal verifier catches edit/delete/reorder/duplicate-insert

Record-fingerprint determinism / pollution

heldKey-order independent, NaN/Infinity rejected, no pollution

Rebuy farming

heldRebuy counts as buy-in; net P&L stays negative, conserved

sitOut/return to manipulate turns or dodge blinds

heldA committed blind can't be reclaimed; folded, conserved

Void vote / cannotContinue from a non-seated player

heldScorekeeper checks the seat list; outsiders ignored, no refund

Claiming another player's hole card (offset/recipient)

heldKeys bound to recipient/position/round/sender; redirects rejected (see R4·06)

A four-light fairness audit on every hand

At the end of every hand the browser automatically runs four checks and reports them in an overlay: ① deck integrity (52 unique, no duplicates) · ② all players shuffled and locked · ③ matching record fingerprint (downloadable canonicalHandHash for cross-player comparison) · ④ signatures complete. A pass stamps "verified"; a warn lights red and offers the evidence for download. This is an active alert layer on top of passive evidence — you don't have to grep the transcript yourself to notice an anomaly.

Recommendations

Only enter tables from fairpoker.app or an IPFS CID published by the official site.

For important games, prefer a registered account with a strong password, and avoid playing in a browser with suspicious extensions.

Watch for the four-light fairness audit overlay at the end of each hand; any red light can be exported as evidence from the table's security panel.

After downloading a transcript, verify it yourself locally with the verification guide.

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

开源代码Source code

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

透明度 · Transparency

已加固内容，

与尚未做到的差距

我们只说能证明的。已经做到的，自信地讲清楚；还没做到的，如实标成路线图——而不是用绝对化的话术盖过去。这一页就是那份清单。

权威可验证证据始终以 Game client CID、源码包 SHA256、source fingerprint、签名 hash-chain transcript 与本地 verifier 为准。

已实现的加固已上线

以下能力已在代码中实现并通过单元测试；标 ✓ 者已在真实浏览器双人对局验证。

能力

说明

官方零裁判 · 零踢人 ✓

协议层没有"操作员踢人"事件类型，也没有中心化裁判。中继已降为哑中继：只排序、转发、报告谁在线，不计算座位 / 回合 / 赢家 / 筹码。下注 / 弃牌 / 坐离均需玩家本人签名行动；无法继续时走全员共识作废+全额退还。中继切断 WebSocket 只触发客户端指数退避自动重连，不能改变牌局状态或夺座位、筹码。

超时弃牌改"自我授权" ✓

想牌超时只会被你自己的客户端判弃牌（按本机时钟），或在你确已掉线时由他人替你弃牌以免卡桌；记分员不再用中继盖的时间戳判断超时。这样即便中继与某个座位合谋，也无法伪造一个"假超时"把正轮到、还没超时的对手强制盖牌、吞掉争议池——动钱的弃牌只认本人签名或客观掉线，碰不到在场对手。

浏览器即权威 · 刷新不掉桌 ✓

座位 / 底池 / 轮到谁 / 赢家 / 战绩全部由你的浏览器用同一套确定性 reducer 从签名事件日志算出，不依赖中继的房间状态——两个浏览器读同一份日志必然算出一致结果。重连后按 sinceSeq 重放未读消息把日志补齐，再从日志重新算出完全相同的状态；轮到你时回归直接续上 turn，不再被错误归类为"观战中 / 请重新坐下"，下注也不会两边对不上。战绩本地留存，刷新不丢。

每手 4 灯公平校验 ✓

每局结束自动跑 4 项校验（牌堆完整 · 全员参与洗牌 · 记录指纹一致 · 签名齐全）并以覆盖层显示结果，通过盖"已验证"印，异常红灯并提示下载证据——主动告警层，可疑事件不需要玩家自己查 transcript。

断线规则极简 · 自愈或整桌作废 ✓

固定两条规则：可恢复掉线 → 无损自动恢复；密钥不可达 → 本手作废、全额退还、整桌结束建议换桌。没有"罚款 / 没收 / 操作员代踢"开关。建桌页与入场页都展示规则面板。

WS 自动重连+消息重放 ✓

WebSocket 断开 500ms→10s 指数退避自动重连（含抖动），重连按 sinceSeq 拉取未读消息恢复状态，不丢局、不丢 turn。

私有发牌端到端加密 ✓

私有 card/decrypt 的逐卡解密钥用收牌方公钥端到端密封（RSA-OAEP），并绑定 sender / recipient / round / cardOffset，重定向到其它人或卡位的密文会被拒收。中继只见密文。

解密钥只在本手期间暂存 ✓

逐卡解密钥仅在当前这一手牌进行期间暂存于本机（以便断线/刷新/关闭后重连恢复这一手），牌局一结束（分出胜负或作废）即删除，不长期保留。

认证不泄露密码 ✓

登录改为客户端 PBKDF2 派生 authSecret 发往服务端，密钥库密钥本地派生、永不出本机。服务端不再接触明文密码，无法即时解开密钥库冒充玩家。

签名绑桌号防跨桌重放 ✓

每个签名事件绑定 tableId，接收端保守拒收不属于本桌的事件。

默认拒收未签名事件 ✓

GameRoom 默认 rejectUnsignedEvents = true，正式入口显式开启；未签名 wire 事件直接拒收，离线验证器拒掉未签名 Fair Poker v0 transcript 条目。

运行时事件校验 ✓

所有桌面事件（下注 / 弃牌 / 开局 / 设置）与发牌事件（牌堆 / 密钥）在进入状态机前做严格结构校验，畸形或越界输入被拒，杜绝异常输入导致的状态污染或崩溃。

下注金额校验 ✓

下注必须为非负安全整数，堵住 NaN 等异常值污染底池。

牌堆 / 密钥结构校验 ✓

牌堆须为 52 个合法整数密文，逐卡密钥与公钥须合法且长度受限，防止超大数解析造成的拒绝服务。

验证器事件覆盖 ✓

离线 transcript 验证器现已识别并校验全部桌面事件类型，不再静默跳过。

会话域分离与重放检测 ✓

每个签名会话绑定随机 sessionNonce；离线验证器据此检测同一会话内的序号重放与乱序。

密钥强度下限 ✓

mental-poker SRA 位数下限提升至 1024（2048 位模数，离散对数不可行），并设 2048 位上限——弱参数自动上调、超大参数被夹住，同时消除"极小位数崩溃"与"超大位数卡死"两种拒绝服务；牌面还编码成二次剩余并避开 0/1 不动点（否则编码落在"1"的那张牌密文会恒为"1"、被零钥匙一眼认出），连残差指纹也不泄露任何隐藏牌。

每手统一记录哈希 ✓

用公开事件签名计算"接收者无关"的 canonicalHandHash，离线验证器暴露且与线上一致——任意两名玩家可比对各自记录、发现篡改或缺漏。

客户端 CID 校验显示 ✓

安全面板对比"运行中的 CID 与权威发布 CID"，显示已锁定 / 不符 / 未从固定入口运行。

中继 token 移出 URL ✓

中继认证 token 改走 WebSocket 子协议而非 URL 查询串，避免进入代理 / CDN / 访问日志。

指纹覆盖全信任边界 ✓

source fingerprint 现覆盖认证 / 传输 / 启动 / 身份等全部信任边界文件，不再只是发牌核心。

客户端可复现构建 ✓

公开的源码包是完整可构建的客户端源码；在版本锁定的 Docker 工具链里 npm ci 重新编译，得到的 IPFS CID 与线上 Game client CID 字节级一致——证明"你读到的公开源码"就是"线上真正在跑的程序"，官方无法给你看一份干净代码、却偷偷在跑另一套。复现步骤见独立验证指南。

已知差距与路线图路线图

以下为尚未实现的已知差距。它们多属协议级或研究级工程，需在受控环境充分测试后才能上线，因此我们如实披露，而非声称已解决。对每一项，我们也写明它实际影响什么、可能的风险是什么、以及现有系统已经把多少风险兜住。

先记住一条：每手牌都自检。每手牌结束，你的浏览器会自动跑一遍公平验证器（牌堆完整 · 全员洗牌 · 记录指纹一致 · 签名齐全），并在摊牌时解出真实牌做重复明文检查。只要这手牌亮的是绿灯，无论下面这些研究级证明有没有上线，这一手都已被实测验证为合法——下面的差距改变的是"数学证明的强度"，而不是"这手牌到底有没有被做手脚"。

差距

可能的风险 · 当前兜底 · 计划

可验证洗牌证明

实质作弊每手必被抓出

可能影响：理论上有人想做"假牌堆"或操纵发牌顺序。

当前兜底：三道关一起封死这条路——① 每个玩家都必须各自参与洗牌并加锁，没有任何单方（包括官方）能决定或得知牌序；② 定稿牌堆必须是 52 张互不相同的密文，做假牌堆会当场红灯；③ 每手摊牌时验证器解出真实牌再查有无重复明文、能否正确解密。只要这手牌 4 灯通过且无重复明文，这副牌就是被全员合法洗过的 52 张真牌。缺的只是"在不亮牌前用零知识数学证明合法置换"，即把现在的"事后每手必抓"升级为"事前数学上不可能"。

计划：引入可验证洗牌证明并纳入验证器。

全下掉线的退款边界

不偷钱 · 仅"真掉线"可触发

可能影响：全下之后只剩翻公共牌时，一名快要输的玩家可以直接掉线、并扣住自己的解牌钥匙，使这手牌翻不出板而被判作废、双方退还本金——把"大概率会输"变成"退款"。

当前兜底：这不是偷钱（双方都退回本金、筹码不增不减）；"在线状态下喊作废"的赖账已被完全封死（当作弃牌、照常输掉），只剩"真掉线"这一条。我们刻意保留"退款"而非"掉线就判负"，因为后者会给掌控连线的官方一个新的作弊面（可在你钥匙广播前掐断连接逼你判负）——退款才是对玩家最安全的选择，并可在账号层对反复全下掉线做检测告警。

计划：引入零知识 / 可中途退出的发牌——让公共牌可凭公开承诺由在场各方独立翻出、无需逃跑者事后配合，从根上消除这条赖账（届时真掉线也照常分出胜负）。

登录抗离线爆破（部分）

强密码下已兜住 · 不影响牌局

可能影响：只影响账号登录，且仅在"服务端被攻破、有人拿到密码库后慢慢离线猜测弱密码"时才有意义。不影响任何牌局、筹码或底牌。

当前兜底：登录只发客户端 PBKDF2 派生的 authSecret，服务端从不接触明文密码、密钥库密钥永不出本机，无法即时解开钥匙库冒充你；高轮次 PBKDF2 也大幅拖慢猜测。强密码基本完全免疫，残留风险只针对弱密码 + 已被攻破并持库的服务端。

计划：迁移到完整 OPAQUE / SRP，连弱密码的离线猜测也一并堵死。

签名跨手强绑定（部分）

跨桌重放已封死

可能影响：把一条合法签名事件"重放"到别的桌、别的版本或过期后再用。

当前兜底：每条签名事件绑定 tableId 并在线上强制拒收不属于本桌的事件——跨桌重放已完全封死；sessionNonce 会话域分离 + 序号检测还能发现同一会话内的重放与乱序。尚未强绑定的是 handId / buildCid / expiry，残留的只是"同桌跨手"这类更窄的边角场景。

计划：补全剩余域字段并在受控测试后线上强制。

桌面控制事件授权

够不到筹码与发牌

可能影响：只影响"谁能按开新局、改设置这类桌面控制按钮"。不影响下注、弃牌、筹码与发牌——那些必须玩家本人签名，任何人都偷不走你的筹码、也改不了你的牌。

当前兜底：按零裁判设计，协议层本就没有"操作员 / 房主"特权；真正涉及钱与牌的行动全部需本人签名 + 浏览器为权威 + 无法继续时全员共识作废全额退还。所以这项缺失最多造成"控制按钮的权限边界不够明确"，够不到筹码或牌面。

进展：已定义房主角色（开第一手的人即房主），并让离线验证器把"非房主擅自改设置 / 重开报名"在可复验记录里标注出来、可归因到具体签名者（CI 测试覆盖）。下一步是把这条授权在收发端也强制（现仅在验证侧标注，不在现场拦截，以免误伤刚刚重构过的开局/重开流程）。

验证器与实时逻辑统一

只会误报 · 不会漏判

可能影响：离线验证器与实时状态机暂未合并为同一套纯函数，理论上存在"某个合法事件顺序被离线验证器误判"的边角情况。

当前兜底：关键在于这种偏差只会让验证器把一手合法牌误报为可疑（宁可错杀），永远不会放过一次真正的作弊。也就是说它影响的是"会不会偶尔虚惊一场"，而不是"会不会漏掉坏人"。

进展：现场端已统一为单一确定性 reducer——座位 / 底池 / 轮到谁 / 赢家全部由它从签名事件日志算出，中继不再参与。并已加一致性测试（CI 强制）：把同一份签名记录同时喂给"可下载的离线验证器"和现场 reducer，断言两者算出的筹码结果逐分一致——弃牌结束与摊牌（含边池/比牌赢家）两条路径均已覆盖，二者永远不会悄悄分叉。剩余仅一项：把离线验证器与现场逻辑合并成同一份编译产物（需引入打包工具、并进可复现源码包，留待可验证一次发布时稳做）。

有限开源边界（非玩法页面）

不影响公平性本身

可能影响：这不是安全漏洞，而是公开范围的取舍——可玩客户端（界面 + 公平内核 + 入口 + 静态资源）的完整可构建源码已经公开、并可字节级复现；仍未公开的只是首页、营销文案、AI 摘要页与后端运维这类不参与发牌、也不进入 Game client CID 的非玩法部分。影响的只是"能否一键重建整个站点的每个角落"，不影响任何一手牌的公平性。

当前兜底：所有与公平性相关的核心文件都已开源；你可以在固定 Docker 环境里用公开源码重编出与线上一致的客户端 CID（见独立验证指南），并对照逐文件哈希、信任边界清单与运行中 CID 校验，核对你正在运行的就是公开审计过的那份代码。

计划：在不被整体抄袭的前提下持续扩大可复现构建范围，并引入外部签名发布日志与第三方复现见证。

诚实结论：Fair Poker 比传统黑箱发牌更可审计（WebCrypto 随机、事件签名、hash-chain transcript、公开 CID、端到端加密底牌、本地复验），并且每手牌都会自动自检、实质作弊会被当场抓出。但我们仍未达到"官方与玩家在数学上都无法作弊"的强可证明公平标准——需要强调的是，上述差距大多是把"每手都能被抓出"升级为"数学上不可能"的更高标准，而非当前存在可被利用的作弊通道。我们选择公开披露，而不是用绝对化措辞掩盖。

Transparency

What's hardened,

and what isn't yet

We only claim what we can prove. What's done, we state plainly; what isn't, we mark honestly as roadmap — instead of papering over it with absolute language. This page is that list.

Authoritative verifiable evidence is always the Game client CID, source archive SHA256, source fingerprint, signed hash-chain transcripts, and the local verifier.

Hardening shipped live

The following is implemented in code and covered by unit tests; items marked ✓ are also verified in a real two-browser game.

Capability

What it does

Operator zero referee · zero kick power ✓

The protocol has no "operator kick" event type and no centralized referee. The relay is now a dumb relay: it only orders, forwards, and reports who is online — it computes no seats / rounds / winners / chips. Bets / folds / sit-outs require the player's own signed action; only when continuation is impossible does a unanimous-void path refund the hand in full. The relay closing a WebSocket only triggers exponential-backoff client reconnect — it cannot change game state or seize a seat or chips.

Thinking-timeout fold is self-authorized ✓

A thinking-timeout only folds you via your own client (on its local clock), or — when you are genuinely unreachable — by others so the table never freezes; the scorekeeper no longer uses the relay's timestamp to judge a timeout. So even a relay colluding with a seat cannot forge a "fake timeout" to fold an on-turn opponent who has not actually timed out and take the disputed pot — a money-moving fold requires the player's own signature or a genuine disconnect, and can never touch a present opponent.

Browser-authoritative · refresh-proof seat ✓

Seats / pot / turn order / winner / history are all computed by your browser with the same deterministic reducer over the signed event log, never from relay room state — two browsers reading the same log necessarily agree. After reconnect, sinceSeq replays missed messages to complete the log, then the browser re-derives the identical state; returning while it's your turn resumes that turn instead of being misclassified as "spectator / please sit back down", and bets no longer disagree across clients. History is kept locally and survives a refresh.

Four-light fairness audit per hand ✓

At the end of every hand, the browser automatically runs four checks (deck integrity · all players shuffled and locked · matching record fingerprint · signatures complete) and shows the result in an overlay. A pass stamps "verified"; a warn lights red and offers the evidence for download — an active alert on top of passive evidence.

Disconnect rule simplified · recover or void ✓

Two fixed rules: a recoverable disconnect auto-recovers losslessly; if a needed decrypt key is unavailable the hand voids, every bet is refunded in full, and the table ends so players start a fresh room. No "penalty / forfeit / operator kick" knobs. The rules panel is shown on host setup and the joiner waiting view.

WebSocket auto-reconnect + replay ✓

The WebSocket reconnects with capped exponential backoff (500 ms → 10 s, jittered) and replays missed messages by sinceSeq, so a blip never loses the hand or the turn.

End-to-end sealed dealing ✓

Per-card decryption keys in private card/decrypt messages are end-to-end sealed to the recipient's public key (RSA-OAEP), bound to sender / recipient / round / cardOffset; ciphertext redirected to a different recipient or card position is rejected. The relay sees only ciphertext.

Decrypt keys kept only for the live hand ✓

Per-card decrypt keys are kept on your device only for the duration of the hand currently in play (so a disconnect, refresh, or reopen can recover that hand), and are erased when the hand ends (settled or voided); never retained long-term.

Auth never exposes the password ✓

Login sends a client-side PBKDF2-derived authSecret; the vault key is derived locally and never leaves your browser. The server never touches the plaintext password and cannot open your vault to impersonate you.

Signatures bound to table id ✓

Every signed event is bound to its tableId; receivers conservatively reject events that don't belong to the table, blocking cross-table replay.

Reject unsigned events by default ✓

GameRoom defaults rejectUnsignedEvents = true, the official setup path enables it explicitly, unsigned wire events are dropped, and the offline verifier rejects unsigned Fair Poker v0 transcript entries.

Runtime event validation ✓

All table events (bet / fold / start / settings) and dealing events (deck / keys) are strictly structurally validated before reaching the state machine. Malformed or out-of-range input is rejected.

Bet amount validation ✓

Bets must be non-negative safe integers, closing off NaN and similar values that could poison the pot.

Deck / key structural checks ✓

The deck must be 52 valid integer ciphertexts; per-card keys and public keys must be valid and length-bounded, preventing huge-number parsing denial of service.

Verifier event coverage ✓

The offline transcript verifier now recognises and checks every table event type, no longer silently skipping any.

Session domain separation ✓

Each signing session is bound to a random sessionNonce; the offline verifier uses it to detect sequence replay and reordering within a session.

Key strength floor ✓

The mental-poker SRA bit floor was raised to 1024 (a 2048-bit modulus, discrete-log infeasible) with a 2048-bit ceiling — weak parameters are clamped up and oversized ones are capped, removing both the tiny-bits crash and the huge-bits hang denial of service; cards are also encoded as quadratic residues shifted off the 0/1 fixed points (otherwise the card landing on "1" would always cipher to "1" and be identifiable with zero keys), so no residue bit leaks about any hidden card.

Per-hand consensus hash ✓

A receiver-independent canonicalHandHash is computed from public event signatures and exposed by the offline verifier, identical to live — any two players can compare their records and detect tampering or omission.

Client CID verification display ✓

The security panel compares the running CID against the authoritative release CID and shows locked / mismatch / not-pinned.

Relay token out of the URL ✓

The relay auth token now travels in a WebSocket subprotocol instead of the URL query string, keeping it out of proxies, CDNs, and access logs.

Fingerprint covers the trust boundary ✓

The source fingerprint now covers auth / transport / bootstrap / identity files — the full trust boundary, not just the dealing core.

Reproducible client build ✓

The published source package is the complete buildable client source; recompiling it with npm ci inside a version-pinned Docker toolchain yields an IPFS CID that is byte-for-byte identical to the live Game client CID — proving the public source you read is exactly the code running live, so the operator cannot show clean code while running something else. Steps: verification guide.

Known gaps on the roadmap roadmap

These are known gaps that are not yet implemented. Most are protocol-level or research-level work that must be thoroughly tested in a controlled environment before shipping, so we disclose them rather than claim they are solved. For each one we also spell out what it actually affects, what the possible risk is, and how much of that risk the existing system already contains.

First, one thing: every hand self-checks. At the end of each hand your browser automatically runs the fairness verifier (deck integrity · everyone shuffled · matching record fingerprint · signatures complete) and, at showdown, decrypts the real cards to check for duplicate plaintext. As long as that hand shows green, it has been actively verified as legitimate — whether or not these research-level proofs have shipped. The gaps below change the strength of the mathematical proof, not whether that hand was actually tampered with.

Gap

Possible risk · what contains it today · plan

Verifiable shuffle proof

Real cheating caught every hand

What it affects: in theory, someone trying to "stack the deck" or rig the deal order.

Contained today: three gates already close this off — ① every player must each shuffle and lock, so no single party (including the operator) can set or learn the order; ② the finalized deck must be 52 distinct ciphertexts, so a stacked deck lights red on the spot; ③ at every showdown the verifier decrypts the real cards and checks for duplicate plaintext and correct decryption. If a hand passes its four lights with no duplicate plaintext, that deck was a genuine 52-card deck shuffled by everyone. What's missing is only a zero-knowledge proof of a valid permutation without revealing — i.e. upgrading today's "caught every hand, after the fact" to "mathematically impossible, before the fact".

Plan: add a verifiable shuffle proof and fold it into the verifier.

All-in disconnect refund boundary

no theft · only a genuine disconnect

Could affect: after an all-in, when only the board reveal remains, a player who is about to lose can disconnect and withhold their decryption keys so the board can't be revealed — the hand voids and both stakes are refunded, turning a likely loss into a refund.

Current cover: this is not theft (both stakes returned, no chips minted or destroyed); the connected "claim a void" dodge is fully blocked (treated as a fold, the loss stands), leaving only a genuine disconnect. We deliberately keep "refund" rather than "disconnect = forfeit", because forfeiting would hand the connectivity-controlling operator a new attack surface (cut your link before your keys broadcast to force a loss) — refund is the player-safest choice, with account-level detection of repeated all-in disconnects.

Plan: a zero-knowledge / abort-resistant deal — the board is recoverable from public commitments by the present players with no cooperation from the leaver, removing this dodge at the root (a genuine disconnect then still resolves normally).

Offline-guess-resistant login (partial)

Contained for strong passwords · no game impact

What it affects: account login only, and only in the case where the server is breached and someone slowly offline-guesses weak passwords from the stolen database. It does not affect any hand, chips, or hole cards.

Contained today: login only sends a client-side PBKDF2-derived authSecret; the server never touches the plaintext password, the vault key never leaves your device, and it cannot instantly open your vault to impersonate you. High-iteration PBKDF2 also greatly slows guessing. A strong password is essentially immune; the residual risk is only weak passwords plus an already-breached, database-holding server.

Plan: migrate to full OPAQUE / SRP to also close off offline guessing of weak passwords.

Cross-hand signature binding (partial)

Cross-table replay already closed

What it affects: replaying a legitimate signed event into a different table, a different build, or after it has expired.

Contained today: every signed event is bound to its tableId and live-rejected if it doesn't belong to the table — cross-table replay is fully closed; sessionNonce domain separation plus sequence checks also catch replay and reordering within a session. Not yet strongly bound are handId / buildCid / expiry, so the residual is only narrow edge cases like "same-table, across hands".

Plan: add the remaining domain fields and enforce them live after controlled testing.

Table-control authorization

Cannot reach chips or dealing

What it affects: only "who may press table-control buttons like start-new-hand or change-settings". It does not affect bets, folds, chips, or dealing — those require the player's own signature, so no one can take your chips or change your cards.

Contained today: by the zero-referee design the protocol has no "operator / table owner" privilege to begin with; everything involving money and cards requires your own signature, browser-authoritative state, and a unanimous void with full refund when play can't continue. So this gap can at most leave "the permission boundary on control buttons under-specified" — it cannot reach chips or card faces.

Progress: the host role is now defined (the signer of the first hand is the host), and the offline verifier flags a non-host changing settings or reopening registration in the replayable record, attributable to the specific signer (covered by CI tests). Next is to also enforce it on senders/receivers (today it is flagged at verify time, not blocked live, to avoid disturbing the just-reworked start/restart flow).

Unify verifier and live logic

Can only false-alarm · never miss

What it affects: the offline verifier and the live state machine aren't yet one shared pure function, leaving a theoretical edge case where a legal event order could be misjudged offline.

Contained today: crucially, such a divergence can only make the verifier flag a legitimate hand as suspicious (fail-safe) — it can never let a real cheat through. So it affects "might we occasionally raise a false alarm", not "might we miss a bad actor".

Progress: the live side is now a single deterministic reducer — seats / pot / turn / winner are all derived by it from the signed event log, with the relay no longer involved. A CI-enforced parity test now feeds the same signed record to both the downloadable offline verifier and the live reducer and asserts their chip outcomes are identical to the chip — both the fold-out and the showdown (side-pot / best-hand winner) paths are covered, so the two can never silently diverge. Only one item remains: merging the offline verifier and live logic into one compiled artifact (needs adding a bundler and baking it into the reproducible source package — left for a release we can verify).

Limited-open-source boundary (non-gameplay pages)

Does not affect fairness itself

What it affects: this is not a security hole but a disclosure choice — the complete buildable source of the playable client (UI + fairness core + entry points + static assets) is public and byte-for-byte reproducible; what is still withheld is only non-gameplay parts — the homepage, marketing copy, AI summary pages, and backend operations — which do not deal cards and are not inputs to the Game client CID. It affects only "can you one-click rebuild every corner of the whole site", not the fairness of any single hand.

Contained today: all fairness-critical core files are open; you can recompile the public source in a pinned Docker environment to a client CID identical to the live one (see the verification guide), and cross-check per-file hashes, a trust-boundary manifest, and a live CID check to confirm that what you're running is the same code that was publicly audited.

Plan: keep widening the reproducibly-buildable scope without exposing the project to wholesale copying, and add an external signed publish log plus third-party reproduction witnesses.

Honest bottom line: Fair Poker is far more auditable than black-box dealing (WebCrypto randomness, event signatures, hash-chain transcripts, public CIDs, end-to-end encrypted hole cards, local replay), and every hand self-checks so real cheating is caught on the spot. But it still does not yet meet a strong, fully provable "neither operator nor players can cheat" standard — and to be clear, most of the gaps above are about upgrading "caught every hand" to "mathematically impossible", not an exploitable cheating path that exists today. We disclose them rather than hide them behind absolute claims.

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

开源代码Source code

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

负责任游戏 · Responsible playResponsible play

负责任游戏与"非赌博"声明Responsible play & no-gambling notice

Fair Poker 的演示是一个仅使用虚拟测试筹码的扑克研究原型，供协议研究测试与技能切磋之用。它不是真钱赌博，不涉及任何真实金钱的投注或奖金。即便如此，我们仍希望参与测试的你健康、适度地对待游戏。

The Fair Poker demo is a poker research prototype that uses virtual test chips only, for protocol testing and skill practice. It is not real-money gambling and involves no real-money wagering or prizes. Even so, we want testers to approach it healthily and in moderation.

最后更新：2026 年 6 月 27 日Last updated: 27 June 2026

非赌博：游戏内筹码没有现金价值，不能购买、提现或兑换为任何有价物。赢得或失去筹码不会带来真实的金钱得失。

Not gambling: in-game chips have no cash value and cannot be purchased, cashed out, or exchanged for anything of value. Winning or losing chips brings no real financial gain or loss.

年龄政策

本服务面向成年人。你必须年满 18 周岁方可使用。即使是娱乐筹码，我们也以扑克为题材，不向未成年人提供。详见服务条款。

健康游戏建议

把它当作娱乐，而不是收入来源或情绪出口。

给自己设定游戏时间，定时休息，避免长时间连续游戏。

情绪低落、疲惫或饮酒后，不是适合长时间游戏的状态。

不要让游戏影响睡眠、工作、学习或人际关系。

记住胜负只是娱乐筹码——不必"翻本"，随时可以停下。

你的自控工具

你可以随时关闭页面、退出牌局；

你可以随时删除账号、清除本地数据，停止使用本服务；

如需要，可使用浏览器或设备自带的使用时长／网站限制工具。

如果赌博成为困扰

Fair Poker 本身不涉及真钱。但如果你或你身边的人正受到真实金钱赌博问题的困扰，请认真对待并寻求帮助。许多国家／地区设有免费、保密的求助热线与组织，例如国际上的 BeGambleAware、Gamblers Anonymous；请优先查询你所在地的官方求助资源。

地区可用性

不同司法辖区对扑克题材软件（即便是娱乐筹码）有不同规定。你需自行确认在你所在地使用本服务合法；若当地禁止，请停止使用。

联系

有任何疑问或需要协助，请联系开源代码Source code

[email protected]。

Age policy

The service is intended for adults. You must be at least 18 years old to use it. Even with play-money chips, it is poker-themed and not offered to minors. See the Terms of Service.

Healthy-play guidance

Treat it as entertainment, not a source of income or an emotional outlet.

Set yourself a time limit, take regular breaks, and avoid long unbroken sessions.

Feeling low, tired, or after drinking is not a good state for long play.

Do not let the game affect your sleep, work, studies, or relationships.

Remember wins and losses are only play chips — there is nothing to "win back", and you can stop anytime.

Your self-control tools

you can close the page or leave a table at any time;

you can delete your account and clear local data to stop using the service at any time;

if helpful, use your browser's or device's built-in screen-time / site-limit tools.

If gambling becomes a concern

Fair Poker itself involves no real money. But if you or someone close to you is affected by real-money gambling problems, please take it seriously and seek help. Many countries offer free, confidential helplines and organisations, such as BeGambleAware and Gamblers Anonymous internationally; please look up the official help resources for your own region first.

Regional availability

Jurisdictions treat poker-themed software differently, even with play-money. You are responsible for confirming that using the service is lawful where you are; if it is prohibited locally, please stop using it.

Contact

For questions or help, contact [email protected].

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

法律 · TermsLegal · Terms

服务条款Terms of Service

Fair Poker 是一个非营利、仅使用虚拟测试筹码的德州扑克公平性开源研究项目。本条款是你与项目维护者之间具有约束力的协议；条款中"本服务"指 fairpoker.app 网站、公开研究资料下载，以及向公众开放的研究演示牌桌。访问或使用本服务，即表示你已阅读、理解并同意本条款。

Fair Poker is a non-profit open-source research project on Texas Hold'em fairness that uses virtual test chips only. These Terms are a binding agreement between you and the project maintainers; in these Terms, "the service" means the fairpoker.app website, downloads of public research material, and the public research demo table. By accessing or using the service, you confirm that you have read, understood, and agree to these Terms.

最后更新：2026 年 7 月 3 日Last updated: 3 July 2026

一句话要点：Fair Poker 是非营利开源研究项目，不以营利为目的对公众提供游戏服务；演示牌桌向公众开放，仅供协议研究测试与体验。演示只用没有现金价值的虚拟测试筹码，不是真钱赌博，筹码不可购买、不可提现、不可兑换任何有价物。想研究请下载源码自行搭建。

In one line: Fair Poker is a non-profit open-source research project and provides no commercial gaming service; the demo table is open to the public for protocol research testing only. The demo uses virtual test chips with no cash value. It is not real-money gambling; chips cannot be purchased, cashed out, or exchanged for anything of value. To study the protocol, download the source and run your own instance.

目录Contents

接受条款Acceptance

资格与年龄Eligibility & age

项目与演示说明The project & demo

非真钱赌博No real-money gambling

账号Accounts

可接受使用Acceptable use

知识产权与许可IP & licence

第三方服务Third-party services

免责声明Disclaimers

责任限制Limitation of liability

赔偿Indemnification

终止Termination

条款变更Changes

适用法律与争议Governing law & disputes

联系Contact

1. 接受条款

访问或使用 Fair Poker（"本服务"），即表示你同意受本条款及我们在本页链接的隐私政策、Cookie 与本地存储说明和负责任游戏说明约束。如你不同意，请勿使用本服务。

2. 资格与年龄

你必须达到所在司法辖区可订立有约束力合同的法定年龄；无论如何，你必须年满 18 周岁方可使用本服务。

即便 Fair Poker 仅使用娱乐筹码、并非赌博，我们仍以扑克为题材，因此面向成年人提供。若你未满 18 周岁，请勿创建账号或参与牌局。

你需自行确认在你所在地访问与使用本服务合法。若当地法律禁止本类娱乐性扑克软件，你应停止使用。

3. 项目与演示说明

Fair Poker 是研究性质的开源项目，其演示是一个可验证公平性的德州扑克研究原型：发牌、洗牌、加密与开牌在参与者浏览器之间以点对点协议形成，维护者仅提供把参与者连接到同一张演示牌桌的轻量中继，不充当发牌方、不持有中心牌库。每一手牌生成可下载、可用本地 verifier 复验的 hash-chain transcript。

演示不构成服务承诺。演示牌桌向公众开放，仅用于协议研究测试与体验，不构成任何持续可用性或服务质量的承诺。我们可随时新增、修改、下线功能或收回演示访问权限，且无需事先通知。

公众的正确使用方式是自行搭建。核心源码公开发布，任何人都可以下载源码、在自己的设备上编译并运行自己的实例来研究协议（许可范围见第 7 条）。

自建实例责任自负。你基于公开源码搭建、部署或运营的任何实例，均由你独立控制并独立承担全部法律与合规责任；该实例与本项目维护者无关，维护者对其不提供任何担保，也不承担任何责任。在部分司法辖区运营扑克类软件可能需要许可或存在限制，你必须自行确保合法合规。

4. 非真钱赌博

本服务内的筹码为娱乐筹码，没有任何现金或货币价值，不能购买、出售、提现、转让或兑换为现金、加密货币或任何有价物。游戏内不设任何充值入口、付费下注机制或奖励兑换机制。

本服务不提供任何形式的真钱投注、博彩或赌博，也不发放奖金。

严禁将本服务用作真钱赌博的记分工具，或以任何桌下、场外方式就牌局结果结算现实金钱、加密货币或任何有价物。此类私下约定完全与运营方无关，是本条款明令禁止的行为，其一切后果由行为人自行承担。

我们并不默许此类行为。我们在游戏内提供玩家举报入口，并对疑似真钱赌博、串通与"送筹码"（故意向特定对手输光筹码）等行为进行审查。一经合理认定，我们将永久封禁相关账号，并保留留存证据、追究责任、以及在法律要求时配合执法机关的权利。

你理解扑克是一种结合技巧与运气的游戏；本服务仅供娱乐与技能切磋之用。

5. 账号

部分功能可在不注册的情况下使用；如你创建账号，你需对账号下发生的活动负责，并对你的密码保密。

账号密钥库以你的密码在本地派生密钥加密；登录时客户端只发送派生的 authSecret，服务端仅保存其哈希、不接触你的明文密码。请妥善保管密码——我们无法替你找回明文密码。

禁止冒用他人身份、共享账号用于滥用行为，或以自动化手段批量注册。

严禁买卖、出租或转让账号，也严禁买卖或转让娱乐筹码。娱乐筹码不具现实价值，任何试图将账号或筹码变现的行为均违反本条款，可导致相关账号被永久封禁。

6. 可接受使用

使用本服务时，你同意不进行以下行为：

作弊，或试图绕过、破解、干扰公平性机制、签名校验、transcript 或 verifier；

与他人串通、共享屏幕或场外报牌以获取不正当优势；

使用机器人、脚本或自动化程序代替真人游戏，或对中继/服务发起拒绝服务、爬取或过量请求；

对客户端进行超出公开许可范围的逆向工程、反编译，或上传恶意代码；

骚扰、辱骂、威胁其他玩家，或发布违法、仇恨、欺诈、侵权内容；

将本服务用于洗钱、欺诈、非法赌博或任何违法目的；

仿冒官网、伪造牌局邀请链接，或以误导方式分发非官方客户端。

我们保留在合理判断你违反本条款时，限制、暂停或终止你访问的权利。

7. 知识产权与许可

Fair Poker 的名称、标志、界面与内容受知识产权法保护。核心牌局客户端与核心源码以可验证发布的形式公开，并按其随附的许可证授权；该许可证条款优先于本节的一般性表述。

除随附开源许可证明确授予的权利外，未经授权，你不得复制、镜像、改名运营或分发本服务或其衍生品。我们已留存源码包、SHA256、CID 与发布证据用于维权。

本服务"按现状"提供其公开代码用于审计与复验，不因此放弃任何商标或品牌权利。

8. 第三方服务

本服务使用第三方基础设施，包括用作轻量中继的 Cloudflare、以及用于分发客户端的 IPFS 公共网关。这些第三方有各自的条款与隐私政策，其可用性与行为不在我们控制范围内。私有发牌消息端到端加密，中继只见密文。

9. 免责声明

在适用法律允许的最大范围内，本服务"按现状"与"按可用性"提供，不附带任何明示或默示担保，包括适销性、特定用途适用性、不侵权及不中断或无错误运行的担保。我们不保证服务持续可用、不被中断、绝对安全或没有缺陷。可验证公平性是指你可对照公开产物自行复验，而非对任何隐藏服务器的信任承诺。

10. 责任限制

在适用法律允许的最大范围内，运营方及其关联方对任何间接、附带、特殊、后果性或惩罚性损害，或数据、商誉、利润损失概不负责；因娱乐筹码不具现金价值，你对其"损失"不构成可主张的金钱损害。某些司法辖区不允许排除特定担保或限制责任，则相关限制在法律不允许的范围内不适用，且不影响消费者依强制性法律享有的权利。

11. 赔偿

因你违反本条款、滥用本服务或侵犯他人权利而引起的任何第三方主张、损失或费用（含合理律师费），你同意向运营方及其关联方作出赔偿并使其免受损害。

12. 终止

你可随时停止使用并删除账号。若你违反本条款或为保护服务与其他用户，我们可在合理情况下暂停或终止你的访问。终止后，依其性质应继续有效的条款（如知识产权、免责、责任限制、争议解决）继续有效。

13. 条款变更

我们可能不时更新本条款。重大变更将通过更新本页"最后更新"日期并在适当情况下提供显著提示的方式公布。变更生效后继续使用本服务，即表示你接受更新后的条款。

14. 适用法律与争议

在不与你居住地强制性消费者保护法相抵触的前提下，本条款受运营方主要营业地所适用的法律管辖。若你作为消费者，你所在国家／地区的强制性法律赋予你的权利不受影响。双方应首先尝试通过开源代码Source code

[email protected] 友好协商解决争议。

15. 联系

关于本条款的任何问题，请联系 [email protected]。

1. Acceptance

By accessing or using Fair Poker (the "service"), you agree to be bound by these Terms and by our Privacy Policy, Cookie & Local Storage Policy, and Responsible Play notice, all linked here. If you do not agree, do not use the service.

2. Eligibility & age

You must be of the legal age to form a binding contract in your jurisdiction, and in any case you must be at least 18 years old to use the service.

Although Fair Poker uses play-money chips only and is not gambling, it is poker-themed and therefore intended for adults. If you are under 18, do not create an account or join a table.

You are responsible for confirming that accessing and using the service is lawful where you are. If poker-themed entertainment software of this kind is prohibited in your location, you must stop using it.

3. The project and its demo

Fair Poker is an open-source research project. Its demo is a verifiably fair Texas Hold'em research prototype: dealing, shuffling, encryption, and reveal are formed peer-to-peer between participant browsers. The maintainers only provide a lightweight relay that connects participants to the same demo table and do not act as the dealer or hold a central deck. Every hand produces a downloadable, hash-chain transcript that you can replay with a local verifier.

The demo is not a service commitment. The demo table is open to the public for protocol research testing only and implies no promise of continued availability or quality of service. We may add, change, or discontinue features, or withdraw demo access, at any time without prior notice.

The intended public use is self-hosting. The core source code is published; anyone may download it, build it, and run their own instance to study the protocol (see Section 7 for the licence scope).

Self-hosted instances are your own responsibility. Any instance you build, deploy, or operate from the public source is controlled solely by you, and you bear all legal and compliance responsibility for it. Such instances are unrelated to the project maintainers, who give no warranty and accept no liability for them. Operating poker-related software may require licences or be restricted in some jurisdictions; you must ensure your own compliance.

4. No real-money gambling

Chips in the service are play-money with no cash or monetary value. They cannot be bought, sold, cashed out, transferred, or exchanged for cash, cryptocurrency, or anything of value. The game contains no top-up entry, paid wagering mechanism, or reward-redemption mechanism.

The service offers no real-money betting, wagering, or gambling of any kind, and pays no prizes.

It is strictly prohibited to use the service as a scoreboard for real-money gambling, or to settle real money, cryptocurrency, or anything of value for hand outcomes through any off-table or off-platform arrangement. Such private arrangements are entirely unrelated to the operator, are expressly prohibited by these Terms, and their consequences are borne solely by the persons involved.

We do not tolerate such conduct. We provide an in-game reporting entry and review suspected real-money gambling, collusion, and "chip dumping" (deliberately losing chips to a specific opponent). Where reasonably established, we will permanently ban the accounts involved and reserve the right to preserve evidence, pursue liability, and cooperate with law enforcement where required by law.

You understand poker combines skill and chance; the service is for entertainment and skill practice only.

5. Accounts

Some features work without registration. If you create an account, you are responsible for activity under it and for keeping your password confidential.

The account vault is encrypted locally with a key derived from your password. At login the client sends only a derived authSecret, and the server stores only its hash and never touches your plaintext password. Keep your password safe — we cannot recover a plaintext password for you.

Do not impersonate others, share accounts for abusive purposes, or mass-register by automated means.

Buying, selling, renting, or transferring accounts is strictly prohibited, as is buying, selling, or transferring play-money chips. Play chips have no real-world value; any attempt to monetise an account or chips breaches these Terms and may result in a permanent ban of the accounts involved.

6. Acceptable use

When using the service, you agree not to:

cheat, or attempt to bypass, break, or interfere with fairness mechanisms, signature checks, the transcript, or the verifier;

collude, share screens, or relay cards out-of-band to gain an unfair advantage;

use bots, scripts, or automation in place of human play, or launch denial-of-service, scraping, or excessive requests against the relay or service;

reverse engineer or decompile the client beyond what the public licence permits, or upload malicious code;

harass, abuse, or threaten other players, or post unlawful, hateful, fraudulent, or infringing content;

use the service for money laundering, fraud, illegal gambling, or any unlawful purpose;

impersonate the official site, forge table invitation links, or distribute unofficial clients in a misleading way.

We may restrict, suspend, or terminate your access where we reasonably believe you have breached these Terms.

7. Intellectual property & licence

The Fair Poker name, marks, interface, and content are protected by intellectual-property law. The core table client and core source are published as a verifiable release and licensed under the licence that accompanies them; those licence terms prevail over the general statements in this section.

Except for rights expressly granted by the accompanying licence, you may not copy, mirror, rebrand-operate, or distribute the service or derivatives without authorisation. We retain the source archive, SHA256, CID, and release evidence to enforce these rights.

Publishing the code "as is" for audit and verification does not waive any trademark or brand rights.

8. Third-party services

The service uses third-party infrastructure, including Cloudflare as a lightweight relay and public IPFS gateways to distribute the client. These third parties have their own terms and privacy policies, and their availability and behaviour are outside our control. Private dealing messages are end-to-end encrypted, so the relay sees only ciphertext.

9. Disclaimers

To the maximum extent permitted by law, the service is provided "as is" and "as available" without warranties of any kind, express or implied, including merchantability, fitness for a particular purpose, non-infringement, and uninterrupted or error-free operation. We do not guarantee that the service will be continuously available, uninterrupted, perfectly secure, or free of defects. Verifiable fairness means you can re-check public artifacts yourself; it is not a promise to trust any hidden server.

10. Limitation of liability

To the maximum extent permitted by law, the operator and its affiliates are not liable for any indirect, incidental, special, consequential, or punitive damages, or loss of data, goodwill, or profits. Because play chips have no cash value, their "loss" is not a recoverable monetary damage. Some jurisdictions do not allow certain exclusions or limitations, in which case those limitations do not apply to the extent prohibited, and your mandatory consumer rights are unaffected.

11. Indemnification

You agree to indemnify and hold harmless the operator and its affiliates from third-party claims, losses, or costs (including reasonable legal fees) arising from your breach of these Terms, misuse of the service, or violation of others' rights.

12. Termination

You may stop using the service and delete your account at any time. We may suspend or terminate your access where you breach these Terms or to protect the service and other users. Provisions that by their nature should survive (such as intellectual property, disclaimers, limitation of liability, and dispute resolution) survive termination.

13. Changes

We may update these Terms from time to time. Material changes will be announced by updating the "Last updated" date on this page and, where appropriate, by a prominent notice. Continuing to use the service after changes take effect means you accept the updated Terms.

14. Governing law & disputes

Without overriding the mandatory consumer-protection laws of your place of residence, these Terms are governed by the law applicable at the operator's principal place of business. If you are a consumer, the mandatory rights granted to you by the law of your country or region are unaffected. The parties will first try to resolve disputes amicably via [email protected].

15. Contact

For any questions about these Terms, contact [email protected].

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

路线图Roadmap

隐私Privacy

条款Terms

负责任游戏Responsible play

[email protected]

仅娱乐筹码 · 非真钱赌博Play chips only · no real-money gambling

♠Fair Poker

首页Home

透明度报告Transparency

独立验证Verification

安全白皮书Security Whitepaper博客Blog

中文

法律 · PrivacyLegal · Privacy

隐私政策Privacy Policy

本政策说明 Fair Poker 收集哪些数据、如何使用与共享，以及你依据 GDPR、CCPA/CPRA 等法律享有的权利。Fair Poker 的设计本身就尽量少收集数据：发牌与牌局证据主要留在你的浏览器，官方只做轻量中继。

This policy explains what data Fair Poker collects, how it is used and shared, and the rights you have under laws such as the GDPR and CCPA/CPRA. Fair Poker is designed to collect as little as possible: dealing and hand evidence stay mainly in your browser, and the operator runs only a lightweight relay.

最后更新：2026 年 6 月 27 日Last updated: 27 June 2026

数据最小化要点：我们不出售你的个人数据，不投放广告，不接入第三方行为追踪。账号只需用户名与本地派生的认证凭据；服务端从不接触你的明文密码；每手牌的底牌解密钥只留在你当前标签页。

Data-minimization summary: we do not sell your personal data, run no ads, and use no third-party behavioural tracking. Accounts need only a username and a locally-derived credential; the server never touches your plaintext password; per-hand hole-card keys stay in your current browser tab.

目录Contents

我们是谁Who we are

我们收集的数据Data we collect

如何使用How we use it

法律依据Legal bases

共享与披露Sharing

数据保留Retention

安全Security

你的权利Your rights

国际传输International transfers

儿童Children

Cookie 与本地存储Cookies & storage

政策变更Changes

联系Contact

1. 我们是谁

本服务由 Fair Poker 运营方（"我们"）提供。就适用数据保护法而言，我们是处理本政策所述个人数据的数据控制者。隐私相关事宜联系：开源代码Source code

[email protected]。

2. 我们收集的数据

类别

内容

存放位置

账号数据

你选择的用户名，以及由你的密码在本地派生的认证凭据（authSecret）的哈希。我们不存储明文密码。

账号哈希存于服务端；账号密钥库加密后存于你的浏览器。

本地游戏数据

语言偏好、会话标识、牌局 transcript 证据、逐卡解密钥等。

留在你浏览器的 localStorage / sessionStorage，默认不上传。

连接与技术数据

建立 WebSocket 连接所必需的网络信息（如 IP 地址）、连接时间、基本日志。私有发牌消息端到端加密，中继只见密文。

由中继（Cloudflare）短暂处理，用于连通与防滥用。

你主动提供的数据

当你通过邮件联系我们时提供的内容。

邮箱通信记录。

我们不收集：广告或跨站追踪标识、第三方行为分析、与游戏无关的设备指纹用于画像。界面中显示的脱敏安全/伙牌信号在本地计算，用于提示，不用于广告。

3. 如何使用

提供并维护牌桌连接、账号登录与基本功能；

保障安全：防止作弊、串通、滥用与拒绝服务，维护服务完整性；

排障与改进服务质量；

遵守法律义务、回应合法请求。

4. 法律依据（GDPR）

对欧洲经济区／英国用户，我们处理个人数据的依据包括：合同的履行（为你提供你请求的服务）、合法利益（保障安全、防滥用、维持服务）、同意（在适用且我们征求时）、以及法律义务。你可随时就基于同意的处理撤回同意。

5. 共享与披露

服务提供商：我们使用 Cloudflare 提供中继与边缘基础设施，作为受合同约束的数据处理者按我们的指示处理连接数据。客户端通过公共 IPFS 网关分发。

法律要求：在法律要求或为保护权利、安全与防欺诈所必需时，我们可能披露信息。

业务转移：如发生合并、收购或资产转让，相关数据可能随之转移，并继续受本政策约束。

我们不会出售你的个人数据，也不为第三方的跨站定向广告而"分享"你的个人信息（CCPA/CPRA 含义下）。

6. 数据保留

账号哈希在你的账号存在期间保留；删除账号后，服务端账号数据将在合理期限内删除或匿名化，除非法律要求保留。连接日志仅短期保留用于安全与排障。留在你浏览器中的本地数据由你掌控，可随时在浏览器中清除（见 Cookie 与本地存储说明）。

7. 安全

我们采用与风险相称的技术与组织措施：账号密钥库本地加密、传输层 TLS、服务端只存认证凭据哈希、私有发牌端到端加密。但没有任何系统可保证绝对安全；请使用强密码并避免在装有可疑扩展的浏览器中游戏。

8. 你的权利

视你所在地法律，你可能享有以下权利：

知情与访问我们持有的与你相关的个人数据；

更正不准确的数据；

删除（"被遗忘权"）；

限制或反对某些处理；

数据可携；

对基于同意的处理撤回同意；

（CCPA/CPRA）知悉、删除、更正，并对"出售/分享"选择退出——我们本就不出售或分享；不因你行使权利而歧视你；

向你所在地的数据保护监管机构投诉。

行使权利请邮件 [email protected]；我们将在适用法律规定的期限内回应，并可能为核实身份请求必要信息。

9. 国际传输

我们的服务提供商（如 Cloudflare）通过全球边缘网络运行，你的连接数据可能在你所在国家／地区以外被处理。在适用法律要求时，此类传输会采取适当保障措施（如标准合同条款）。

10. 儿童

本服务面向成年人，不面向 18 周岁以下人士，我们不会有意收集儿童的个人数据。若你认为未成年人向我们提供了数据，请联系我们删除。

11. Cookie 与本地存储

我们仅使用为提供服务所必需的本地存储，不使用广告或第三方追踪 Cookie。详见 Cookie 与本地存储说明。

12. 政策变更

我们可能更新本政策。重大变更将通过更新"最后更新"日期并在适当情况下显著提示的方式公布。

13. 联系

隐私相关请求或问题，请联系 [email protected]。

1. Who we are

The service is provided by the operator of Fair Poker ("we"). For applicable data-protection law, we are the data controller for the personal data described in this policy. For privacy matters, contact [email protected].

2. Data we collect

Fair Poker — 全站 AI / 爬虫合订本

Table of contents

Machine-readable endpoints

Fair Poker 首页

透明度报告 / Transparency Report

公开证据状态 / Public Evidence Status

独立验证指南 / Independent Verification Guide

安全白皮书 / Security Whitepaper

已加固内容与已知差距 / Hardening Status

负责任游戏 / Responsible Play

使用条款 / Terms of Service

隐私政策 / Privacy Policy

Cookie 与本地存储 / Cookies & Local Storage

llms.txt (machine-readable overview)