WhatsApp 正在有限范围内测试 Scam Alert：当非联系人发来消息时，设备端机器学习模型会判断其中是否存在潜在诈骗风险。真正值得关注的不只是分类模型，而是围绕模型建立的隐私架构：消息内容留在设备上，性能评估和模型交付则结合机密计算、Oblivious HTTP、差分隐私与模型透明度机制。
棳手的问题不是推理，而是评估
把模型放到手机上运行，可以避免将原始消息发送到服务器，但这只解决了推理阶段的隐私问题。团队仍然需要回答一系列运营问题：
- 新模型是否减少了漏报？
- 某个版本是否产生过多误报？
- 不同语言或地区的效果是否失衡？
- 模型是否被正确、完整地交付到目标设备？
如果直接上传消息、模型分数和用户身份，设备端推理带来的隐私优势就会被遥测系统抵消。因此，这套架构需要严格区分三类数据：原始消息、设备产生的风险判断，以及经过隐私处理的聚合指标。
原始消息应停留在设备上。风险判断可以直接用于本地界面，例如提示用户核实对方身份。只有用于评估模型的最小统计量，才有理由进入后端分析流程。
四层机制分别解决什么问题
设备端机器学习负责在消息所在的位置完成特征提取和推理。服务器不需要为了分类而读取消息正文，这也意味着模型必须适应移动设备的算力、内存和耗电约束。
Oblivious HTTP（OHTTP）用于降低请求身份与请求内容被同一服务关联的风险。典型设计会让中继看到客户端连接信息但看不到加密负载，让处理端看到负载却难以直接识别原始客户端。它不是匿名系统的万能替代品，时间、流量大小和重复请求仍可能形成侧信道。
机密计算保护数据使用中的阶段。遥测数据进入受保护的执行环境后再完成解密和聚合，可以缩小云平台、运维人员或其他基础设施组件接触明文数据的范围。实际安全性仍取决于远程证明、密钥管理、可信计算基和漏洞响应。
差分隐私限制聚合结果泄露单个用户信息的程度。它通常通过噪声、采样和隐私预算实现，因此会牺牲一部分统计精度。样本量太小、维度切分过细或反复查询，都可能削弱保护效果。
模型透明度则面向交付链：客户端需要能够识别模型版本，并验证收到的模型是否符合发布记录。它有助于发现未经授权的替换，但不能自动证明模型没有偏差或安全缺陷。
可以这样实践：只上传经过扰动的结果
下面是一个可直接运行的概念验证。它在本地检查非联系人消息，只返回风险等级；随后使用随机响应生成一个经过差分隐私处理的遥测位。这个示例不实现 WhatsApp 的真实模型、OHTTP 或机密计算，只演示“内容留在本地、后端接收最小统计量”的数据边界。
将代码保存为 local_scam_demo.py，然后运行 python local_scam_demo.py：
import json
import random
import re
SUSPICIOUS_PATTERNS = [
r"verification code",
r"gift card",
r"urgent payment",
r"send.*password",
]
def classify_on_device(message: str, is_contact: bool) -> dict:
if is_contact:
return {"checked": False, "risk": "not_applicable"}
matches = sum(
bool(re.search(pattern, message, flags=re.IGNORECASE))
for pattern in SUSPICIOUS_PATTERNS
)
risk = "high" if matches >= 2 else "medium" if matches == 1 else "low"
return {"checked": True, "risk": risk}
def randomized_response(value: bool, epsilon: float = 1.0) -> bool:
# 二元随机响应：epsilon 越小，隐私越强，但统计噪声越大。
truthful_probability = pow(2.718281828, epsilon) / (
1 + pow(2.718281828, epsilon)
)
if random.random() < truthful_probability:
return value
return not value
message = "Urgent payment needed. Buy a gift card and send the code."
result = classify_on_device(message, is_contact=False)
telemetry = {
"model_version": "demo-1",
"high_risk_noisy": randomized_response(result["risk"] == "high"),
}
print("Local UI result:", result)
print("Upload payload:", json.dumps(telemetry))
assert message not in json.dumps(telemetry)
这里的关键词规则只是为了让示例无需第三方依赖即可运行，不能作为生产级诈骗检测器。生产实现可以替换为量化模型，但应保留同样的数据边界：推理函数接触正文，遥测函数只接触离散结果和必要的模型版本。
如果要继续扩展，可以把遥测请求发送到 OHTTP 网关，并让后端只发布达到最小样本阈值的聚合数据。不过，不能只是在 HTTP 请求中删除用户 ID 就宣称实现了 OHTTP；标准协议涉及负载封装、密钥配置、中继与网关的职责隔离。
落地时需要检查的边界
这类设计的价值在于把诈骗检测与内容集中收集拆开，但“设备端”并不天然等于“隐私安全”。采用类似方案时，应逐项确认：
- 日志、崩溃报告和调试工具是否意外记录消息或模型输入。
- 遥测字段是否足以通过组合重新识别用户。
- 差分隐私预算是否覆盖多轮查询，而不只是单次报表。
- 小语种、方言和新型诈骗话术是否存在明显漏报。
- 警告界面是否允许用户继续操作，并避免把模型判断描述成确定事实。
- 模型包是否签名、版本化，并能通过透明记录或等效机制接受核验。
- 机密计算环境是否验证远程证明，同时准备密钥轮换与漏洞处置流程。
有限测试是合理的起点。诈骗检测会直接影响用户对陌生消息的判断，误报可能阻断正常沟通，漏报则可能造成实际损失。工程上的目标不应是承诺“模型永远正确”，而是让内容暴露面、统计误差、模型偏差和交付风险都能被明确测量和约束。