OC
投诉警员后遭上百次Flock查询,车牌数据库的边界落在谁能查
科技 · 2026-09-07 · 数字权利与安全 · 阅读 17

投诉警员后遭上百次Flock查询,车牌数据库的边界落在谁能查

据 Reason 的报道,美国威斯康星州 Sussex 居民、海军退伍军人 Napoleon Jones 在拍摄一次交通执法并投诉警员之后,成为一系列 Flock 车牌数据库查询的对象。当地媒体 TMJ4 的原始调查结合记录和证词,报道了超过 100 次相关搜索。

作者:韩启明|OC 政策与安全编辑

据 Reason 的报道,美国威斯康星州 Sussex 居民、海军退伍军人 Napoleon Jones 在拍摄一次交通执法并投诉警员之后,成为一系列 Flock 车牌数据库查询的对象。当地媒体 TMJ4 的原始调查结合记录和证词,报道了超过 100 次相关搜索。

一句话结论:这宗仍在诉讼中的个案说明,车牌识别系统的监督不能只数摄像头;谁能发起查询、以什么案件为依据,以及被投诉者能否反查投诉人,同样决定权力边界。

一张晚了数周的照片,把查询暴露出来

按媒体梳理,最初冲突发生于 2025 年 5 月 4 日。Jones 录下执法过程后,在私人停车场被 Waukesha County 警员 Brandon Shayhorn 拦下,对方提出临时号牌不可读的问题。Jones 随后被拘留,约五小时后获释,没有收到罚单或刑事指控。

报道援引的内部材料对最初拦停合法性提出否定意见。但这是部门记录的内容,不能据此替法院宣布整宗民事案件已经裁决。Jones 的联邦诉讼仍包含需要通过程序认定的指控。

后来的投诉回复中出现了一张 Jones 白色 BMW 的照片。律师发现,照片时间比最初事件晚了约 25 天,拍摄地点也不在原停车场。顺着这张照片,后续记录揭示了多名部门人员发起的搜索。

超过 100 次是查询记录的数量,不是已经确认的 100 次实地跟踪,更不是 100 个不同摄像头同时锁定同一个人。数据库可以被重复查询,一次查询也可能返回不同数量的结果。把这几个单位混用,会夸大系统实际发生的行为。

警方人员的解释与原告指控必须同时呈现

TMJ4 报道,相关警员在证词中称,搜索与内部投诉调查有关,并提到来自上级的指示;原告则主张,这是针对其行使权利的报复。媒体还报道,部门政策要求 Flock 数据用于正当执法目的。TMJ4 调查与证词摘要。

“用于内部调查”解释了行为人提出的理由,并不自动证明每次搜索都有充分必要性;“遭到报复”则是原告主张,也不能省略证明过程。尤其值得核查的是:为什么被投诉警员参与了对投诉人车辆的查询,以及查询时间范围与调查问题之间是否相称。

当地部门以案件正在诉讼为由拒绝媒体采访,Flock 在该报道刊出时尚未回应采访请求。这些回应状态不构成承认指控。

查询者、案件依据与独立审核构成审计责任链

数据留存是一种能力,回溯查询是另一种能力

摄像头记录公共道路上的车辆,与后来按车辆特征搜索历史记录,是两个不同阶段。后一阶段把分散的观察变成可以围绕特定对象组织的资料,因此授权不能只发生在采购摄像头时。

这是从该案引出的系统设计问题,并不是对 Flock 所有客户的使用方式作统一认定。即使系统已经保存查询日志,也还需要有人检查异常。只有记录,没有复核,往往只能在纠纷出现后帮助重建过程,不能及时限制不当使用。

更有效的审计应能回答:查询属于哪个案件,理由是否具体,时间与地域范围是否必要,谁获得结果,结果是否被继续传播。对涉及员工本人、熟人或投诉人的查询,还应有利益冲突处理机制。

把理由做成一个随便填写的文本框,并不会自然获得这些保障。系统需要让理由与实际案件、权限和复核责任建立联系,否则“有审计功能”很容易只剩一个采购清单上的勾。

普通人往往不知道自己需要提出什么问题

Jones 案件中,一张进入回复材料的照片使后续查询得以被追查。对于其他被检索者,如果查询结果从未进入公开程序,他们可能连申请哪一类记录都不知道。

这使透明度不能完全依赖个人偶然发现异常。采购机构应说明查询规则、违规调查渠道和可公开的审计统计,同时保护真实案件中的敏感信息。透明与调查保密需要具体划分,而不应被当作只能二选一。

最终法律责任应由法院依据证据认定。技术报道能够提前指出的,是一个明确的治理缺口:采集范围控制得再好,也需要防止合法数据库被不当查询。输入端和使用端必须各自有人负责。

关键事实

  • 地点与对象:Wisconsin 的 Sussex、Waukesha County;Napoleon Jones。
  • 数量口径:媒体依据记录报道超过 100 次搜索,不等于同等次数实地跟踪。
  • 程序状态:原告提出报复等指控,案件未在所引报道中形成终局认定。
  • 争议核心:投诉调查的目的、查询必要性与参与者利益冲突。

OC 判断

评价监控技术不能只问“数据是否合法采集”。当历史记录可以轻易围绕一个人重新组织,查询本身就需要清晰授权和独立监督。审计日志是证据基础,不能被当作已经完成监督。

为什么重要

  • 对公共机构:采购条款应覆盖查询权限、利益冲突和异常复核。
  • 对开发者:日志要能连接案件依据,而不只是记录按钮被谁点击。
  • 对公众:数据库用途和申诉入口,关系到技术能力是否被适当约束。

参考来源

相关阅读

基于标题、摘要和正文内容自动匹配。

更多科技

评论

围绕这篇文章补充信息、提出问题或分享观察。

0
暂无评论。

发表评论

继续看看 OC 用户围绕这个话题说了什么、做了什么。

相关帖子

更多

奉劝大家不要移民了

<p>对于大多数人而言,移民就是悲剧。实在看不下去了,大家不要往火坑里面跳。 国内发展那么快,你出国去慢车道,消费又高,又存不下钱,又要拼命适应当地环境,何苦? 老老实实在大城市找工作,根据收入买房子上车就好。</p> <p>补充:大城市觉得房价太高太辛苦,就好好学好英语,美国远程回老家省会城市,拿同比一线的收入,三线城市的开销,岂不美哉?</p> <p>转文章: <a href="https://mp.weixin.qq.com/s?__biz=MzAxNTMxMTc0MA==&amp;mid=2651016481&amp;idx=1&amp;sn=6bde227438ea02e3da3673295821692e&amp;chksm=80721b32b705922448a9f8645e8d1a8450e57151b71e58beb64e0addf9485ad0b256a431d68b&amp;mpshare=1&amp;scene=1&amp;srcid=0530QgwbtdDlMP4ZG7Nkonpo&amp;pass_ticket=bz%2FdHaz2YWQrgwhgQlVVXt866SMnyXU53Dd0OzDmMc1uZeu0PqND%2FjdQ6fQk8Bdl#rd"> 中产阶级的地雷阵 #D03 </a></p> <p>更多文章:<a href="https://mp.weixin.qq.com/s?__biz=MzAxNTMxMTc0MA==&amp;mid=503532389&amp;idx=1&amp;sn=84ff5eefb88e1b17f9ec0efb0238140d&amp;chksm=00721d76370594601903172e49477ce0ed149a3ba1bdcb88a300b55c8c552a79ea31134216ae&amp;mpshare=1&amp;scene=1&amp;srcid=0719VQx1dNX5rlraUqjWtCFm&amp;pass_ticket=bz%2FdHaz2YWQrgwhgQlVVXt866SMnyXU53Dd0OzDmMc1uZeu0PqND%2FjdQ6fQk8Bdl#rd">列表</a></p>

halida 198 9

做 AI 语音产品时,授权、撤回和审计日志应该怎么落地?

<p>最近看到越来越多关于声音授权的讨论。对开发者来说,真正麻烦的往往不是“模型能不能模仿”,而是授权如何进入系统、生成结果如何追溯,以及授权撤回后该怎么办。</p> <p>我们在做 FlowSpeech 时也碰到过类似问题。我的体会是,不要把“用户勾选过同意”当成一个布尔字段,而应该把它做成一组可以审计的业务对象。</p> <h2>1. 把声音资产和授权分开</h2> <p>声音文件只描述技术属性,例如哈希、上传者、存储位置和创建时间。授权记录则至少要包含授权主体、用途范围、地域、有效期、来源证据和当前状态。这样同一份声音用于个人试听、商业广告、公开播客时,可以绑定不同的授权,而不是共用一个模糊的 consent=true。</p> <h2>2. 每次生成都保存授权快照</h2> <p>生成任务不要只引用当前授权 ID。授权内容以后可能变更,如果任务只查最新状态,历史结果就无法解释。更稳妥的做法是在任务创建时保存授权版本、文本哈希、声音版本、模型版本和操作者。生成出的音频再记录 artifact_id,并反向关联任务。</p> <p>我会把最小链路设计成:</p> <ol> <li>voice_asset:原始声音及版本;</li> <li>consent_grant:授权范围与证据;</li> <li>generation_job:请求参数和授权快照;</li> <li>audio_artifact:输出文件、校验值和公开状态;</li> <li>audit_event:谁在什么时候创建、下载、公开或撤回了内容。</li> </ol> <h2>3. 撤回不是简单删除一行</h2> <p>授权撤回后,系统至少要阻止新任务,并把相关公开音频进入下架队列。已经交付给客户的文件是否能删除,要按照合同和产品能力区分,不能在界面上承诺技术上做不到的“全球删除”。更现实的状态机是 active、suspended、revoked、expired,并明确每个状态允许哪些动作。</p> <h2>4. 对外展示也要可验证</h2> <p>除了后台日志,公开音频最好带上来源标记或可查询的生成记录。水印不是万能方案,但“可识别的音频 + 可验证的元数据 + 清晰的举报入口”组合起来,比一句“AI 生成”更有用。</p> <p>我们现在做的 <a href="https://flowspeech.io/zh">FlowSpeech</a> 主要解决上下文感知、情绪和停顿控制。越往产品化走,越觉得声音效果只是前半程,权限边界和可追溯性才决定这类工具能不能长期使用。</p> <p>大家在实际项目里会把授权证据放在业务数据库、对象存储,还是单独的审计系统?如果授权撤回,你们通常怎么处理已经生成并交付的音频?</p>

FlowSpeech 0 1

测试OurCoders能否发布照片

<p>今天小区的彩虹🌈<img src="https://share.icloud.com/photos/0ebtFydNy8r_gJETON61u4Ybg" alt="图片说明" /></p> <p>看来不能直接发照片,可以把iCloud Link的功能派上用场!</p>

梁建溢 15 45

你为什么不移民?

<p>我是一定要移了,在这里连正常呼吸都不行了。以前正常呼吸指的是言论自由,现在是生物学意义的正常呼吸问题了。</p> <p>你为什么不移民?</p>

tinyfool 741 48