O3.14.4Unverified interface origin设计研究
用户很少主动核验界面来源，需要系统主动阻断伪造
别名: 来源核验缺失 · security indicators · passive verification
概念解释
安全 UI 研究几十年的稳定结论：用户默认不核验界面的来源——不看证书、不查签名、不辨像素，他们靠「看起来对不对」与「剧情通不通」决定是否输入。因此防伪装的有效防线不在教育用户去核验，而在系统把核验自动化、把伪造直接阻断。
机制
核验来源是有成本的动作（注意力、知识、时间），收益却是「避免一个可能不发生的损失」——防御成本即时确定，攻击概率与损失不确定，这是安全经济学里最典型的失衡。用户把有限注意力留给主任务，核验被系统性省略；这不是疏忽，是任何理性人在同样处境下都会做的取舍。有效对策的共同点是把「用户得记得核验」这个前提移除：自动填充按域拒绝，假框收不到密码；系统弹窗强制署名，来源不可隐藏；敏感操作绑定硬件确认，伪造界面触发不了安全芯片。每条都把安全属性从用户行为搬到系统能力。
怎么研究
证据链很长：早期的网站可信度实验记录到多数被试不看地址栏与证书标识；钓鱼实验中即使受过训的被试也主要依赖内容线索而非来源线索；移动端研究统计用户对权限弹窗来源的忽略率。典型范式是在真实任务里植入伪造界面，统计发生主动核验行为的比例。方法论注意点：「用户不核验」不等于「用户不可教育」——教育能抬高检出率，但抬高后的水平仍远低于自动化防线，把教育当主防线是对证据的误读。
边界
主动阻断有代价：按域拒绝会误伤合法的非常规界面（自定义登录页、嵌入式 webview）；强制署名暴露所有来源，包括用户不想透露使用情况的；硬件确认对没有安全芯片的老设备不可用。阻断强度要按场景分级——浏览器的「不安全」提示是弱阻断，支付场景拒绝自绘输入是强阻断，两档不可混用也不可跳过分级直接上最强档，否则误伤会把用户推向关闭防护。
怎么落地
- 对每个敏感输入点回答「来源验证由谁完成」，答案不能是「用户会看」，必须是某个系统机制：域匹配 autofill、来源署名、硬件确认，三选一起步。
- 保留「一行可见」的来源信息（如状态栏常驻标识）给想核验的人，但不把安全押在它被看到上。
- 验证：可用性测试里统计主动核验行为的发生率——预期接近零；若防线设计依赖它发生，设计不成立，回到机制层重做。