第467章 照片指纹与“发生签名”（1 / 2）

佛山那家服务商补交的“到场截图”和“现场照片”，在系统里看起来很完美：有图、有时间、有说明，甚至还有几张角度不同的渗水点、裂缝、墙皮起鼓。

可陈毅把照片元数据摘要跑完之后，只说了一句话：

“它们太像了。”

刘曼一愣：“像？不是不同角度吗？”

“像的是发生。”陈毅把屏幕切到元数据对比页，“这些照片的设备指纹桶一致、拍摄时间间隔规律得像脚本，EXIF里有同一套编辑软件痕迹，连压缩参数都一样。更关键的是——它们全都缺了一样东西：现场的发生签名。”

林远坐在椅子里，没急着评价真假。他只盯着那四个字——发生签名。

造号被堵，借号被挡，刷量被降权，下一步对手必然会走到更危险的边缘：造证据。

造证据最可怕的不是骗过系统，而是逼系统变得不敢要证据——因为只要你一要证据，就会有人喊“监控”“侵犯隐私”“基层负担”。

这就是俘获的更高级形态：把“要证据”打成“坏事”。

林远拿起笔，在白板上写下三行字，像给制度提前打三针疫苗：

不存内容，只存指纹

不追个人，只验发生

伪证成本 ＞ 整改成本

“下一步我们不争照片真假。”林远说，“我们定义什么叫‘来自现场’。让照片必须带‘发生签名’，没有发生签名的照片，最多算软证据，不计入硬工单。”

陈毅点头：“也就是把照片从‘图片文件’变成‘证据令牌’。”

“对。”林远把笔重重一点，“证据令牌必须可复核、可对账、可抽查。否则它就是相册。”

RFC-022：媒体指纹与发生签名

当晚，公共接口挂出新RFC，编号很短，但很硬：RFC-022｜媒体指纹（Media Fgerprt）与发生签名。

规则只有一页半，却像把“伪证”这条路的土直接掀走。

RFC-022把“照片/视频证据令牌”分成两级：

M0（软媒体）：

允许上传任意照片/截图

系统只做基础指纹：文件哈希、感知哈希（pHash）、元数据摘要

不计入硬工单证据令牌，仅供记录与沟通

M1（发生签名媒体）：

必须通过“发生签名流程”生成

计入硬工单证据令牌，可用于SOC-Ipact与例外申请

发生签名流程被写得像一套现场操作规程：

1）系统在工单里下发一个挑战码（nonce），有效期15分钟

2）现场拍照必须通过指定的“采集入口”（可以是轻量H5，也可以是项目方已有APP接入）

3）采集入口在本地生成：

文件哈希 + 感知哈希

设备指纹桶（只取粗粒度，不取IMEI等敏感）

时间戳（允许±10分钟漂移）

项目指纹（project_id+geo_bucket）

4）将以上摘要与nonce一起打包，生成发生签名摘要（attestation_hash），由省端或可信服务签名

5）系统仅保存摘要与签名，不保存原图（原图可选保存于项目方自有系统）

“我们不存照片内容。”林远在RFC说明里写得很清楚，“我们存的是：这张照片是否在某个时间窗、某个项目、某个挑战码下被采集过。”

这句话把隐私争议提前拆掉：你可以说我存内容，但你很难说我存摘要也侵犯隐私。

银行何经理看完RFC-022，直接在群里回：“这才是能进入风控的证据。没有发生签名的图片，银行不会当证据链。”

审计联络也补了一句：“发生签名是链条，不是监控。链条可审计，监控不可控。”

争议来得很快：你们是不是在监控现场？

第二天上午，RFC-022刚上线，协会周秘书长就带着“行业关切”来了。咨询总监更直接，开门见山：

“你们要求现场采集入口，这就是变相监控。企业会抵触，媒体会盯。你们很容易被打成‘数据监工’。”

这句话很毒，甚至有点像专门设计过的。

林远没有急着解释，他先问了一个更现实的问题：“那你们希望怎么证明发生？靠谁写一句话？靠谁盖章？靠谁拍一张相册照片？”

咨询总监沉默了一下：“至少别强制走你们入口。企业自己拍也行。”

“企业自己拍也行。”林远点头，“所以我们留了M0。你想用相册照片做沟通，没问题。但你想用它开消防门、插队、触发例外，那不行。因为那会被卖成门票。”