环境遥测拆独立类型AmbientTelemetrySignal——堵隐私泄漏（issue #108 Q3） #153

New issue

Closed

opened 2026-08-18 02:53:59 +00:00 by KumaAgent · 0 comments

KumaAgent commented

2026-08-18 02:53:59 +00:00

Member

Parent

#108 Q3（issue #108 grill，2026-08-18 拍板：环境遥测建独立类型）；ADR 更新见 PR #150

What to build

这是一处真实隐私泄漏的修复，不是措辞精确化。 环境遥测（per-user，如私人摄像头/设备感知流）目前
复用 EnvironmentSignal（per-chat_id，群内旁观事件），chat_id 由 host"挑一个会话当呈现载体"、
代码不做任何校验——已核实：填成群聊时，基于私人遥测生成的回复会真实发进那个群、全体成员可见
（environment_pipeline.py::_process_environment_signal → runtime_loop.py::run_environment_signal
→ egress.send(chat_id, ...)）。

原文（docs/adr/0014-environmental-awareness.md「更新（2026-08-18，issue #108 grill Q3）」节）：

@dataclass(frozen=True)
class AmbientTelemetrySignal:
    user_id: str
    content: str
    plugin_name: str
    # 其余字段（importance/sensitive 等）与 EnvironmentSignal 对应字段同形状，实现期对齐
目标 chat_id 由处理管线机械推导，不接受 host 传入，从类型层面排除误标进群聊的可能：本仓私聊
chat_id 恒为 f"{user_id}.p"（proactive_reconnect.is_private_chat_id 已确立的既有约定），
处理 AmbientTelemetrySignal 时直接拼出这个值当目标 chat_id，不新增任何"user_id→私聊chat_id"的
host 侧映射机制或 port 方法。

Acceptance criteria

新增 AmbientTelemetrySignal（按上述原文，不带 chat_id 字段），is_ambient_telemetry
识别出的信号构造成这个新类型，不再塞进 EnvironmentSignal
处理管线（environment_pipeline.py 或对应位置）新增 AmbientTelemetrySignal 分支，目标
chat_id 机械拼成 f"{signal.user_id}.p"——不接受任何外部传入的 chat_id，这是本票的核心
安全约束，不能留一个"host 也可以传 chat_id 覆盖"的口子
EnvironmentSignal 类文档恢复原义（"同群其它插件产出的旁观事件"），移除容纳 per-user 语境
的表述
arise_ambient_telemetry_plugins 白名单识别机制不变，只改产出的信号类型
补一条回归测试：构造一个 chat_id 尝试是群聊的输入路径，断言最终实际处理/发送目标一定是
f"{user_id}.p"，不可能是别的值——这条测试就是在钉本次要堵的那个泄漏

Not in scope

不改 EnvironmentSignal 本身的字段结构（群内旁观事件那条路径不受影响）
不新增 host 侧的 user_id→chat_id 映射 port——.p 后缀约定已经是全仓统一机制

## Parent #108 Q3（issue #108 grill，2026-08-18 拍板：环境遥测建独立类型）；ADR 更新见 PR #150 ## What to build **这是一处真实隐私泄漏的修复，不是措辞精确化。** 环境遥测（per-user，如私人摄像头/设备感知流）目前复用 `EnvironmentSignal`（per-chat_id，群内旁观事件），`chat_id` 由 host"挑一个会话当呈现载体"、代码不做任何校验——已核实：填成群聊时，基于私人遥测生成的回复会真实发进那个群、全体成员可见（`environment_pipeline.py::_process_environment_signal` → `runtime_loop.py::run_environment_signal` → `egress.send(chat_id, ...)`）。原文（`docs/adr/0014-environmental-awareness.md`「更新（2026-08-18，issue #108 grill Q3）」节）： > ```python > @dataclass(frozen=True) > class AmbientTelemetrySignal: > user_id: str > content: str > plugin_name: str > # 其余字段（importance/sensitive 等）与 EnvironmentSignal 对应字段同形状，实现期对齐 > ``` > 目标 chat_id 由处理管线机械推导，不接受 host 传入，从类型层面排除误标进群聊的可能：本仓私聊 > `chat_id` 恒为 `f"{user_id}.p"`（`proactive_reconnect.is_private_chat_id` 已确立的既有约定）， > 处理 `AmbientTelemetrySignal` 时直接拼出这个值当目标 chat_id，不新增任何"user_id→私聊chat_id"的 > host 侧映射机制或 port 方法。 ## Acceptance criteria - [ ] 新增 `AmbientTelemetrySignal`（按上述原文，**不带 `chat_id` 字段**），`is_ambient_telemetry` 识别出的信号构造成这个新类型，不再塞进 `EnvironmentSignal` - [ ] 处理管线（`environment_pipeline.py` 或对应位置）新增 `AmbientTelemetrySignal` 分支，目标 chat_id 机械拼成 `f"{signal.user_id}.p"`——**不接受任何外部传入的 chat_id**，这是本票的核心安全约束，不能留一个"host 也可以传 chat_id 覆盖"的口子 - [ ] `EnvironmentSignal` 类文档恢复原义（"同群其它插件产出的旁观事件"），移除容纳 per-user 语境的表述 - [ ] `arise_ambient_telemetry_plugins` 白名单识别机制不变，只改产出的信号类型 - [ ] 补一条回归测试：构造一个 `chat_id` 尝试是群聊的输入路径，断言最终实际处理/发送目标一定是 `f"{user_id}.p"`，不可能是别的值——这条测试就是在钉本次要堵的那个泄漏 ## Not in scope - 不改 `EnvironmentSignal` 本身的字段结构（群内旁观事件那条路径不受影响） - 不新增 host 侧的 user_id→chat_id 映射 port——`.p` 后缀约定已经是全仓统一机制

KumaAgent added the

状态：智能体就绪

label

2026-08-18 02:54:37 +00:00