CrispGuard 的遮挡是本地处理的吗？截图或录屏时，扩展本身会泄露内容吗？

CrispGuard 的遮挡在浏览器本地完成，不依赖远程服务器，也不会把页面内容发送出去。但它工作在页面层，不是操作系统安全层——系统截图或录屏工具如果绕过了浏览器渲染，遮挡不保证出现在捕获结果里。它不是安全产品，不加密屏幕，不替代防窥膜或系统级截图防护。

如果你想知道 CrispGuard 具体能遮什么，产品页列了三种遮挡形态。这一页讨论的范围更窄：遮挡发生在哪一层，以及这个位置能保护什么、不能保护什么。

CrispGuard 的数据路径——什么留在浏览器里，什么不离开

遮挡逻辑运行在扩展的内容脚本里，也就是你正打开的那个页面内部。文本匹配、图片替换、区域绘制都发生在页面本地渲染阶段，这条路径上没有任何一步需要先把页面传到服务器。

CrispGuard 是一个 Chrome 扩展，真正干活的部分是内容脚本——浏览器注入到你正在浏览的页面里的代码。它读取页面里已经存在的文本和图片，和你自己配置的关键字表做比对，然后改写浏览器即将绘制的内容：命中的关键字变成一条遮挡条、一个纯色块或一个 emoji；命中的图片被替换成占位块；框选的区域被一层覆盖层盖住。页面本身照常可用，链接能点、表单能填、滚动不受影响。

上面每一步都是对「已经下载到本地的那份文档」做的本地操作。比对用的是扩展里存的那份关键字表，不是服务器上的模型。这条路径上没有哪一步需要把页面送出去才能完成遮挡。

这句话只覆盖遮挡路径，值得把它的边界说清楚：「本地遮挡」和「零网络请求」是两个不同的说法。后者更强，也可被检验，这一页不会把前者升级成后者。根据商店页的功能描述，CrispGuard 的遮挡判定与绘制都发生在你的设备上。至于扩展在网络上去访问什么——授权校验、以及其它任何请求——由它的隐私政策定义，那才是你下判断之前该读的文档。CrispGuard 的设计目标是尽可能减少数据离开浏览器，具体网络行为以扩展的隐私政策为准，而不是以一篇介绍页为准。

值得对照的是把更强说法公开写出来的产品。ContextBlur 的隐私政策明确写了 100% 本地处理、零网络请求，自动模糊只在用户点击「Run auto-blur now」时运行，并且只存 CSS 选择器、不存页面内容。不论你还从里面读出什么，它说明了一件有用的事：在这个品类里，「本地处理」是一个厂商可以公开声明、并且可以被追问的说法，不是 CrispGuard 独有的说辞，也不该凭任何一家厂商（包括这一家）的自述就采信。

这里还有一条边界要单独说：遮挡改变的是页面显示出来的内容。它不加密页面，不把页面从浏览器自身的进程里藏起来，也拦不住任何能接触你已解锁电脑的人打开开发者工具直接读 DOM。CrispGuard 是共用空间里的隐私便利工具，不是安全产品，也不应该被描述成安全产品。

截图和录屏时，遮挡会发生什么——能覆盖什么，不能覆盖什么

这完全取决于捕获路径。工具如果读取的是浏览器渲染出来的页面，遮挡通常就在图里；如果读取的是操作系统的帧缓冲，或者用摄像头拍屏幕，扩展没法把遮挡放进那张图。

机制决定结果。浏览器扩展活在页面的渲染管线里：它改的是 DOM 和挂在 DOM 上的样式，然后由浏览器把结果画出来。截图和录屏工具分两类：一类向浏览器索取「当前显示的内容」，读到的就是扩展已经改过的那份渲染结果；另一类直接读操作系统的帧缓冲，也就是整块屏幕合成后的图像，压根不去问页面。

移动平台演示了第二类在平台配合时能做到什么。Android 的 FLAG_SECURE 在平台安全层拦下截图，操作系统直接拒绝捕获。Chrome 扩展没有对应的一层——没有任何 API 能让扩展要求 Windows、macOS 或采集设备「拒绝这一帧」。

CrispGuard 的遮挡是页面层的可见性控制，不是截图阻断。如果你需要硬件级截图阻止，应该使用操作系统或平台提供的安全显示机制，而不是浏览器扩展。

由此有两条实用推论。第一，凡是你没实测过的捕获方式，先假定遮挡不在结果里，而不是假定它在。第二，这个测试很便宜：拿你实际会用的那个工具，对一个你实际遮过的页面截一次，看结果。

网锁的 PIN 是怎么存的——一个可验证的信任信号

网锁的 PIN 只以加盐哈希的形式保存，不存明文。即使有人读取扩展的本地存储，拿到的也不是一个能直接填进解锁框的值。打开设置仍是正常界面，只有解锁时才询问 PIN。

网锁是 PRO 功能：给某个站点上锁之后，要解锁得先输入 PIN。扩展存下来的是这个 PIN 的加盐哈希——把 PIN 和一个随机值一起送进单向函数——而不是 PIN 本身。所以读到扩展本地存储的人，拿不到可直接使用的口令。盐也有意义：两台机器即使碰巧设了同一个 PIN，存下来的值也不一样，存储内容不会泄露「这两个 PIN 相同」这件事。

这个选择值得掂量，因为它可以被检查。把 PIN 明文存起来的产品，暴露的是它对「存储」这件事的思考方式；存哈希的产品，说明它假设过这份存储早晚会被人读到。两个选择本身都不能让一个产品变得可信，但对一个装在你每个页面上的工具，你会想看到后者。

哈希做不到的事同样要说清楚。它保护的是存储下来的值，不是「已解锁」这个状态：站点已经解锁、有人站在你身后，他读到的是页面，不是哈希。短数字 PIN 在尝试次数足够多时也可被猜中，而哈希本身不说明允许试几次。哈希只回答一个问题——「有人读到这个文件能拿到什么」——这个问题它答得很好，其它问题它不管。

如果你在评估「要不要信任一个屏幕隐私扩展」，应该检查什么

五件事能定下大半：隐私政策有没有明说页面内容不外传、遮挡究竟在哪一层完成、申请了哪些与遮挡无关的权限、自动识别是不是等你触发、以及产品认不认自己的边界。

这些都不需要技术背景，只需要读一份政策和一张权限表——在把一个能读你所有页面的工具装进来之前，这点工作量是合理的。

1. 隐私政策里有没有逐字写明「不传输页面内容、截图、浏览历史」？点名这三类的政策是一个可被证伪的承诺；只说「我们尊重你的隐私」的不是，而无法证伪的话事后也无从检验。
2. 遮挡是在内容脚本/页面层完成的，还是必须先把内容发到服务器？这决定了「本地」是架构属性还是文案里的一个词——只有前者能扛住断网。
3. 扩展有没有申请与遮挡无关的敏感权限（剪贴板、请求拦截、远超功能需要的站点访问）？每一项权限都是一种能力，它是否存在与当前版本是否使用无关，所以权限表说的是「可能发生什么」，不只是「现在发生了什么」。
4. 自动识别功能是不是只在你明确触发时才运行？默认扫描每个页面的功能，和等你点一下才动的一样，隐私姿态并不相同，哪怕屏幕上看到的结果一样。
5. 产品有没有承认自己的边界（比如「不是安全产品」「拦不住系统级截图」），还是声称能阻断截图？写清边界的厂商通常想过边界在哪；声称什么都能拦的，要么搞错了，要么在卖别的东西。

这不是一张打分表，这一页也不会替 CrispGuard 把它填完。凡是无法从公开文档确认的项，就当作未确认，去读隐私政策。这是这个问题诚实的答法，也是唯一一个在下一个版本发布之后依然成立的答法。

常见问题

CrispGuard 会把我的页面内容发到服务器吗？

遮挡路径不需要这么做。匹配在内容脚本里完成，比对的是存在扩展里的关键字表，替换直接画在页面里，这条路径上没有哪一步要上传页面。扩展是否还有其它网络请求（例如授权校验）由隐私政策定义，那份文档才是该查的地方。

我用系统截图工具截图，遮挡还在吗？

不保证。系统截图读的是操作系统的帧缓冲，而扩展只改浏览器渲染出来的内容，所以遮挡在不在结果里取决于捕获路径，而不是取决于遮挡有没有打开。如果捕获走的是浏览器渲染结果，遮挡通常会被包含进去。

录屏软件录到的画面会有遮挡吗？

取决于录屏软件的捕获模式。读取渲染页面或浏览器合成结果的工具通常会带上覆盖层；在操作系统层面直接抓屏的工具可以完全绕过它。CrispGuard 里没有任何设置能改变这一点，因为限制在捕获路径上，不在扩展里。

网锁的 PIN 如果忘了，扩展会泄露明文吗？

不会——扩展只存 PIN 的加盐哈希，所以读取本地存储看不到 PIN 本身。这保护的是存下来的东西，不是别人能看到的东西：如果站点已经解锁、有人正看着你的屏幕，PIN 与此无关。

屏幕隐私扩展能替代防窥膜吗？

不能。防窥膜收窄的是物理屏幕的可视角度，旁边的人根本读不到；扩展改的只是浏览器里的像素。防窥膜还盖住屏幕上的一切——别的应用、通知、视频通话——这是浏览器扩展够不到的范围。这也是本文那条边界声明的意思：页面层的可见性控制不是截图阻断。

如果我真的需要防止截图，应该用什么？

用平台机制，而不是浏览器扩展。Android 的 FLAG_SECURE、受 DRM 保护的播放通路、以及禁用了捕获的受管设备策略，都工作在操作系统或平台层——截图真正经过的就是那一层。多数共用空间场景里，防窥膜加上把屏幕转开就是务实的答案。

← 全部文章