小团队匿名反馈协议

目的

本机制的目标：降低团队成员提出真实反馈的成本，使问题能够尽早暴露并得到改进，同时避免匿名机制被用于骚扰、攻击或无意义的信息轰炸。

本机制遵循两个基本原则：

• 个体理性：提出善意反馈的预期激励应高于其时间、心理压力和潜在风险。

• 激励相容：成员通过提供真实、具体、有信息量的反馈，对团队整体发展有长期益处。

---

防滥用机制

每条反馈原则上不超过 1000 字。每名团队成员每天最多提交 5 条反馈。

明显的广告、辱骂、机器生成轰炸、与团队无关内容，以及完全重复且没有新增信息的提交，可以被 AI 检测和过滤。

---

匿名配额机制

目标

匿名配额机制用于同时实现以下目标：

1. 成员资格（Eligibility）

   只有合法团队成员能够获得匿名反馈凭证。

2. 固定配额（Fixed Quota）

   每个成员每天固定获得 5 个匿名反馈 token。

3. 不可伪造（Unforgeability）

   未经系统签发，用户无法自行生成合法 token。

4. 不可关联（Unlinkability）

   在密码协议正确实现的前提下，mentor / issuer 无法仅根据 token 本身，将后续使用的某个 token 与最初领取该 token 的具体成员建立密码学关联。

   该性质不等同于完整的网络匿名性。IP、连接时间、TLS 信息及反馈内容等侧信道仍可能泄露身份，需要由后续网络匿名机制单独处理。

5. 一次性使用（One-time Spend）

   每个 token 最多成功提交一次反馈。

6. 最小化元数据（Metadata Minimization）

   匿名反馈接口不依赖登录身份、员工账号等身份信息，并尽量避免收集与反馈处理无关的客户端元数据。

---

基本思想

系统采用 Blind Signature（盲签名）、支持 Public Metadata Binding 的匿名 token 协议，或具有等价安全性质的匿名凭证机制。

基本思想是：

mentor 可以确认“今天已经为某个合法团队成员签发了固定数量的反馈凭证”，但不知道具体签发了哪些 token。

成员之后使用 token 提交反馈时，系统可以验证：

“这个 token 确实由系统针对指定用途和指定 epoch 合法签发，并且尚未被使用。”

但无法仅通过 token 知道：

“这个 token 当初是签发给 Alice、Bob 还是其他成员的。”

系统因此将两个问题分离：

Identity / Issuance:
这个人是否是成员？
今天是否已经领取固定额度？

              ↓ unlinkable

Feedback / Redemption:
这个匿名 token 是否合法？
是否尚未使用？

---

客户端每日固定时间领取固定额度 Token

所有团队成员固定获得：

5 tokens / member / day

无论成员当天最终提交：

0 条
1 条
...
5 条

反馈，每天都按照预设规则签发 5 个 token。

token 的签发不应由：

“我现在想发送一条反馈”

这一行为触发。

客户端应将 token issuance 作为例行自动任务，与用户当下是否具有反馈意图解耦。

成员可以预先选择一个长期使用的自动签发规则，例如：

默认规则：
每天上班后约 30 分钟

或：

每天 09:30 左右

客户端可以加入一个较小的本地随机抖动，例如：

随机窗口：±20 分钟

随机执行时间由客户端本地决定。

需要明确：

issuer 仍然可以观察到签发请求实际发生的时间。

例如 issuer 可能知道：

Alice
09:37
完成今日 token issuance

自动签发机制的目标不是让 issuer 无法得知签发时间，而是让：

token issuance

与：

feedback intent

在行为上解耦。

由于成员无论当天是否准备反馈都会例行领取固定数量 token，签发事件本身不应表示：

“Alice 现在准备提交反馈。”

这种机制可以降低 timing correlation 的信息价值，但不能单独消除 timing side channel。

网络层和时序层的进一步保护由后文“网络匿名性”部分处理。

---

Epoch

系统定义固定 token 有效周期：

epoch = 1 day

例如：

scope = anonymous-feedback
epoch = 2026-09-21
quota = 5

当天签发的 token 原则上只允许用于对应 epoch：

2026-09-21

不能在：

2026-09-22

继续使用。

因此：

scope
epoch

不能只是 redemption 时由客户端自行声明的普通字段，而必须与 token 进行密码学绑定。

---

本地生成匿名 Token

每天进入新的 epoch 后，客户端使用密码学安全随机数生成器，在本地生成 5 个随机 nonce。

例如：

r1 = CSPRNG(256 bits)
r2 = CSPRNG(256 bits)
r3 = CSPRNG(256 bits)
r4 = CSPRNG(256 bits)
r5 = CSPRNG(256 bits)

这些 nonce 不应包含：

member identity
employee ID
device ID
IP address
account ID

每个 token 在逻辑上包含：

Token {
    private:
        nonce: random_256_bit_value

    public_context:
        scope: "anonymous-feedback"
        epoch: "2026-09-21"
}

其中：

nonce

作为客户端私有输入，对 issuer 隐藏。

而：

scope
epoch

作为所有成员共享的 Public Context，由客户端和 issuer 共同确认。

---

Scope / Epoch 的密码学绑定

系统必须确保：

nonce
+
scope
+
epoch

共同决定一个 token 的有效性。

不能采用以下不安全的逻辑：

Sign(nonce)

然后 redemption 时由客户端另外声称：

scope = anonymous-feedback
epoch = 2026-09-21

否则签名本身实际上没有证明该 nonce 属于：

anonymous-feedback / 2026-09-21

用户理论上可能尝试将 token 搬运到其他日期或其他用途。

因此实际实现必须使用以下任一具有等价安全性质的机制：

Partially Blind Signature

或：

支持 Public Metadata Binding 的 Privacy Pass 类协议

或：

不同 scope / epoch 使用密码学隔离的 issuer configuration / key

核心要求只有一个：

verifier 必须能够从密码学上确认某个 token 是为指定 scope + epoch 签发，而不能依赖客户端提交时对这两个字段的单方面声明。

以下 Blind / BlindSign API 为抽象伪代码，用来表达这一安全要求，并非要求自行设计密码算法。

---

Blind Signature / Public Context Binding

定义当天所有成员共同的 public context：

public_context = {
    scope: "anonymous-feedback",
    epoch: "2026-09-21"
}

Alice 本地拥有：

r1
r2
r3
r4
r5

客户端执行：

B1 = Blind(r1, public_context)
B2 = Blind(r2, public_context)
B3 = Blind(r3, public_context)
B4 = Blind(r4, public_context)
B5 = Blind(r5, public_context)

然后向 issuer 发送：

authenticated member:
    Alice

public context:
    scope = anonymous-feedback
    epoch = 2026-09-21

blinded private inputs:
    B1
    B2
    B3
    B4
    B5

issuer 可以确认：

Alice 是合法团队成员

Alice 今天尚未完成每日签发

本次签发数量 = 5

scope = anonymous-feedback

epoch = today

但 issuer 看不到：

r1
r2
r3
r4
r5

issuer 执行：

S1' = BlindSign(B1, public_context)
S2' = BlindSign(B2, public_context)
S3' = BlindSign(B3, public_context)
S4' = BlindSign(B4, public_context)
S5' = BlindSign(B5, public_context)

客户端收到以后，在本地执行：

S1 = Unblind(S1')
S2 = Unblind(S2')
S3 = Unblind(S3')
S4 = Unblind(S4')
S5 = Unblind(S5')

最终客户端持有：

(r1, public_context, S1)
(r2, public_context, S2)
(r3, public_context, S3)
(r4, public_context, S4)
(r5, public_context, S5)

其中每一个组合都代表一个合法的一次性匿名反馈凭证。

其含义不是简单的：

issuer signed r3

而是：

issuer issued a valid credential for:

private nonce = r3

under:

scope = anonymous-feedback
epoch = 2026-09-21

同时 issuer 在 issuance 阶段仍然不知道：

r3

的具体值。

---

Issuance DB

身份侧数据库只需要记录：

Member	Epoch	Issued
Alice	Sep 21	5
Bob	Sep 21	5
Carol	Sep 21	5

Issuance DB 可以知道：

Alice、Bob、Carol 今天分别完成了固定 5 个 token 的领取。

但不知道：

Alice 的 nonce 是什么
Alice 的具体 token 是什么
Alice 后来使用了哪个 token
Alice 是否实际发送过反馈
Alice 的反馈内容是什么

---

客户端 Token 本地保存

签发完成后的 token 只存储在成员客户端。

例如：

Local Wallet

2026-09-21

token #1    unused
token #2    unused
token #3    unused
token #4    unused
token #5    unused

客户端无需向 issuer 汇报：

还剩几个 token
使用了哪些 token
准备什么时候使用 token

---

提交反馈

假设 Alice 希望提交一条匿名反馈。

客户端从当天未使用 token 中选择一个，例如：

r3

然后通过匿名反馈通道发送：

feedback:
    "事实1……事实2……
     目前造成的影响……
     可以改进的方向……"

private token input:
    nonce = r3

public context:
    scope = anonymous-feedback
    epoch = 2026-09-21

signature:
    S3

反馈 endpoint 不要求 Alice 登录。

服务器按照所采用的标准协议验证：

Verify(
    public_key,
    private_input = r3,
    public_context = {
        scope = anonymous-feedback,
        epoch = 2026-09-21
    },
    signature = S3
)

该验证必须同时证明：

signature valid

AND

scope cryptographically bound
    == anonymous-feedback

AND

epoch cryptographically bound
    == 2026-09-21

AND

token not spent

满足条件后：

ACCEPT feedback

并将对应 token 标记为已经消费。

这样，一个：

scope = anonymous-feedback
epoch = 2026-09-21

的 token 无法仅通过修改请求字段变成：

scope = another-service
epoch = 2026-09-22

的合法 token。

---

Redemption DB

Redemption DB 只保存防止 double spend 所需要的信息，例如：

Spent Token ID	Epoch
91da...	Sep 21
c52f...	Sep 21
02ab...	Sep 21

第一次使用：

signature valid
token not spent

→ ACCEPT

随后将 token 标记为 spent。

再次使用同一个 token：

signature valid
token already spent

→ REJECT

因此：

每个合法 token 最多成功提交一条反馈。

---

两个数据域的隔离

系统分为两个数据域：

┌─────────────────────────┐
│ Identity / Issuance     │
│                         │
│ knows:                  │
│ - member identity       │
│ - daily quota           │
│ - issuance completed    │
│ - issuance timestamp    │
│                         │
│ does NOT know:          │
│ - actual token nonce    │
│ - feedback content      │
└────────────┬────────────┘
             │
             │ blind issuance
             ▼
        Member Client
             │
             │ later /
             │ independently
             ▼
┌─────────────────────────┐
│ Feedback / Redemption   │
│                         │
│ knows:                  │
│ - anonymous token       │
│ - feedback              │
│ - spent status          │
│                         │
│ does NOT require:       │
│ - member identity       │
└─────────────────────────┘

从 token 协议本身来看，即使 mentor 可以访问两个数据库，也只能分别看到：

Issuance side:

Alice -> 今天领取 5 个 token
Bob   -> 今天领取 5 个 token
Carol -> 今天领取 5 个 token

以及：

Redemption side:

token A -> used
token B -> used
token C -> used

Blind Signature / Privacy Pass 类协议的目标是使系统无法从 token 本身建立：

token A -> Alice

这样的密码学映射。

但是：

这一保证不等于网络层无法通过 IP、时间戳或其他元数据尝试建立关联。

因此网络匿名必须作为独立安全层设计。

---

元数据风险

Blind Signature 主要解决：

token issuance
        ↕
token redemption

之间的密码学关联问题。

它不能自动解决所有网络和行为层面的身份泄露。

仍然需要注意：

IP address
request timestamp
login cookie
User-Agent
browser fingerprint
device identifier
TLS / connection correlation
feedback content itself

因此匿名反馈系统应遵循数据最小化原则。

特别是匿名 Feedback Endpoint 不应要求或者主动携带：

employee ID
account ID
SSO session
实名 login cookie
user-specific API key

仅仅使用：

浏览器隐私模式

并不能隐藏客户端对服务器的 IP 地址，因此不应将其视为网络匿名机制。

用户仍应意识到，反馈正文自身也可能包含能够推断身份的信息。

---

网络匿名性

如果 Feedback Receiver 能直接看到用户真实 IP，则：

Blind Signature

本身不足以提供完整匿名性。

例如：

09:30

Alice
IP = 1.2.3.4
→ Issuer

随后：

14:20

IP = 1.2.3.4
→ Feedback Receiver
→ anonymous feedback

即使 token 本身在密码学上完全不可关联，拥有两侧网络日志的一方仍可能通过 IP 等元数据进行关联。

因此，更强的部署结构应将匿名 token redemption 与用户网络身份进一步分离：

IDENTIFIED CHANNEL

Alice
  ↓
Issuer
  ↓
Blind / Privacy-preserving Token


ANONYMOUS REDEMPTION CHANNEL

Client
  ↓
Independent Relay / Anonymity Layer
  ↓
Feedback Receiver

一种标准化实现思路是 OHTTP（Oblivious HTTP）。

其基本隔离目标是：

Client
   │
   │ encrypted request
   ▼
Independent Relay
   │
   │ knows:
   │ - client network address
   │
   │ does NOT know:
   │ - plaintext feedback
   ▼
OHTTP Gateway / Feedback Receiver
   │
   │ knows:
   │ - plaintext request
   │ - anonymous token
   │
   │ does NOT directly see:
   │ - original client IP
   ▼
Feedback System

为了达到这一网络层隐私目标，relay 与能够读取反馈明文的一侧不能由同一个可联合分析数据的主体控制。

也可以采用具有类似匿名目标的独立 relay 或匿名网络。

需要注意：

网络 relay 可以显著降低 IP / connection metadata 带来的身份关联能力，但并不能消除所有 traffic analysis 或内容侧信道。

例如：

提交时间
请求大小
极小的 anonymity set
正文中特有的事实

仍然可能提供身份线索。

因此应区分两层保证：

Cryptographic Unlinkability
        +
Network-layer Anonymity

Blind Signature / Privacy Pass 类协议主要负责第一层。

Independent Relay / OHTTP / 其他匿名网络主要负责第二层。

两者结合后才能提供更完整的匿名提交机制。

---

Anonymity Set 与内容侧信道

匿名性的实际效果还受到 anonymity set 大小影响。

如果团队有：

20 人

某条反馈理论上可能来自其中很多人。

如果团队只有：

3 人

并且只有一个人知道某件事情，那么即使：

Blind Signature 正确
+
网络 relay 正确
+
没有身份 cookie

mentor 仍然可能根据反馈内容推断反馈者身份。

例如：

“昨天只有我和 mentor
一起参加了客户 A 的会议……”

内容本身已经大幅缩小 anonymity set。

因此本系统的匿名性不能被理解为：

“任何情况下 mentor 都绝对不可能猜到反馈者是谁。”

更准确的目标是：

系统不主动向 mentor 提供将反馈与具体成员对应起来的身份信息，并通过密码学和网络架构降低技术性关联能力。

---

流程概况

完整流程可以概括为：

---------------------------------
          DAILY ISSUANCE
---------------------------------

Member
  │
  │ authenticated
  ▼
Client
  │
  │ 例行自动生成 5 个随机 nonce
  │
  │ r1...r5
  ▼
Blind
  │
  │ private:
  │   nonce
  │
  │ public context:
  │   scope
  │   epoch
  ▼
Issuer
  │
  │ 验证：
  │ member 合法
  │ epoch 正确
  │ scope 正确
  │ 每日固定额度 = 5
  │
  │ Blind Sign
  │ with public context binding
  ▼
Client
  │
  │ Unblind
  ▼
Local Anonymous Token Wallet

(r1, scope, epoch, signature1)
(r2, scope, epoch, signature2)
(r3, scope, epoch, signature3)
(r4, scope, epoch, signature4)
(r5, scope, epoch, signature5)


---------------------------------------
          LATER / INDEPENDENTLY
---------------------------------------

User decides to send feedback
  │
  ▼
Select one unused token
  │
  ▼
Independent Relay / Anonymity Layer
  │
  ▼
Anonymous Feedback Endpoint
  │
  │ feedback
  │ nonce
  │ epoch
  │ scope
  │ signature
  ▼
Verify Signature
+ Cryptographic Context Binding
  │
  ├── invalid → reject
  │
  ▼
Check Epoch / Scope
  │
  ├── invalid → reject
  │
  ▼
Check Spent Set
  │
  ├── already spent → reject
  │
  ▼
Accept Feedback
  │
  ▼
Mark Token Spent

---

推荐反馈格式

反馈者鼓励按照以下结构表达：

事实 / 情境 → 影响 → 建议 → 不确定性

事实 / 情境

发生了什么？尽量描述可以观察或验证的事实。

正确示例：

“过去三次周会平均超过了计划时间约 30 分钟。”

错误示例：

“我们的会议管理很差。”

影响

这件事产生了什么影响？

影响可以是效率、质量、客户体验、团队氛围，也可以是反馈者自己的感受。

建议

你希望发生什么变化？

如果没有明确解决方案，也完全可以只提出问题，发现问题本身具有价值。

不确定性

哪些部分是你确认的事实，哪些部分只是你的判断？

如果样本较少或者存在其他可能解释，可以主动说明。

---

有效反馈

有效反馈不意味着 mentor 必须同意或采纳该建议。

一条反馈符合以下精神即可视为有效：

• 反馈是善意提出的；
• 与团队工作、管理、协作或环境有关；
• 包含具体事实、影响、问题、建议或有价值的问题中的至少一部分；
• 能够给团队提供新的决策信息；
• 不是没有新增信息的纯重复提交；
• 反馈可以是错误的。只要反馈者基于自己实际掌握的信息善意表达，后续事实证明判断有误，也不因此失去有效反馈资格。

---

Mentor 的回应

mentor 承诺阅读反馈。

每条反馈应进入以下状态之一：

• 决定采纳
• 计划尝试
• 未来条件合适时采纳
• 需要更多信息
• 重复问题
• 不属于有效反馈

“决定采纳 / 计划尝试 / 未来条件合适时采纳”都可以计入团队反馈积分。

对于暂不采纳的反馈，mentor 可以说明原因。

每次提交后，系统向反馈者提供随机 Feedback ID 和访问凭证。

反馈者可以在不暴露身份的情况下：

• 查看 mentor 的回应；
• 回答 mentor 的澄清问题；
• 补充事实；
• 继续讨论解决方案。

---

团队反馈积分

每一条“决定采纳 / 计划尝试 / 未来条件合适时采纳”计 1 分，共同累计进入团队积分池。

参考规则：

每累计 5 分，mentor 请全团队进行一次团队聚餐。

---

反馈处理透明度

在不暴露反馈者以及敏感信息的前提下，可以公开一个团队级别的反馈看板，例如：

• 本月收到反馈数量；
• 有效反馈数量；
• 当前团队积分；
• 已解决问题数量；
• 正在尝试的问题；
• 若问题可以公开，最终未采纳的问题及简要原因。

---

反馈者保护

反馈机制中的“匿名”需要区分三个不同维度：

1. 身份匿名（Identity Anonymity）

即：

“谁提交了这条反馈？”

默认情况下，mentor 和 Feedback Receiver 不需要知道反馈者的真实身份。

匿名配额机制主要用于保护这一层。

反馈者可以选择：

[✓] 对 mentor 隐藏我的身份

---

2. 内容保密（Content Confidentiality）

即：

“哪些人可以阅读这条反馈的原始内容？”

身份匿名不意味着反馈内容必须公开。

反馈者可以指定原始反馈的可见范围，例如：

[✓] 原始内容仅 mentor / 指定处理人可见

对于敏感反馈，可以进一步限制处理人员。

如果反馈涉及 mentor 本人或者存在其他直接利益冲突，应允许采用其他指定处理人或利益冲突回避机制。

---

3. 内容公开（Publication）

即：

“这条反馈是否允许以去标识化方式出现在团队反馈看板中？”

反馈者可以单独选择：

[ ] 允许公开原始内容

[✓] 允许公开去标识化后的摘要

[ ] 不允许公开任何反馈内容

因此：

身份匿名
≠
内容保密
≠
允许公开

三者应作为独立权限处理。

例如某位成员完全可以选择：

身份：
匿名

原始内容：
仅 mentor 可见

团队看板：
允许发布去标识化后的问题摘要

也可以选择：

身份：
匿名

原始内容：
仅指定处理人可见

团队看板：
完全不公开

团队反馈看板不得因为公开统计或摘要而重新暴露能够推断反馈者身份的信息。

对于可能涉及利益冲突的反馈，应允许：

• 利益冲突回避；
• 指定其他处理人；
• 事实调查；
• 对原始反馈内容限制访问范围。

---

协议复盘

本协议首先作为试运行机制运行 3 个月。

团队应定期复盘：

• 有效建议比例；
• 成员是否相信匿名机制；
• mentor 是否能够实际完成反馈闭环；
• 积分和聚餐机制是否产生预期效果。

反馈机制的目标是提高真实、有价值信息到达决策者的概率。