一个上线仅三天的开源项目,做了一件听起来很朴素的事。Chrome扩展ocr-it让用户在网页或PDF阅读器里画一次截图区域,之后每按一次热键就截屏、跑一遍内置Tesseract引擎识别文字、追加进一份文档;开启自动模式,它能自己翻页、自己截图、自己识别,直到整本书读完,最后导出成文本文件——喂给Claude或ChatGPT去问答、去总结。它的卖点是零网络请求、纯离线OCR,安装时甚至不主动申请任何网站权限。
这款项目真正值得说道的,不是OCR效果多好,而是它在两件事上呈现出的反差。它的权限设计比多数同类扩展要克制;可它一边在文档里明明白白写着"把几百页不能选中的书变成文本喂给大模型",一边对由此牵出的版权问题只字不提,连自己承诺的用户反馈渠道都是断的。
权限抠得比同行细,但也就到这一步
MV3扩展常见的做法是在manifest里直接声明大范围host_permissions,安装那一刻就把整个互联网的访问权限要走,这也是过去几年隐私争议的主要来源之一。ocr-it的做法不太一样:它只申请activeTab、scripting、storage等七项具体权限,把最敏感的<all_urls>放进了可选权限里,安装时不请求,只有用户开启跨页自动运行或者操作跨域iframe时,弹窗才会问一次。截图OCR成功后,原始全尺寸图片也会被丢弃,只留文字和缩略图。
自动运行本身也带着几道止损线:连续两页文字相同就判定到了结尾,单次运行默认封顶三百页,标签页关闭或Chrome重启会立即停止。这些细节说明开发者确实花了心思把"失控"的可能性压到最低。
但"一键拿下整本书"的顺滑叙事在最常见的场景里会打折扣。Chrome内置PDF阅读器是个插件,扩展没法往里注入点击,自动翻页在这里彻底失效,用户得自己按翻页键;本地file:///路径的PDF还得额外去扩展详情页手动打开"允许访问文件网址"的开关。真正能全自动跑完的,只是嵌在网页里、且能被脚本操控翻页的那类阅读器。
说明书没写的两件事
README里明确定位:把"不能选中"的书变成文本文件,这是绕开出版方或阅读器设置的技术性复制保护。全篇没有一句提醒版权归属、合理使用边界,MIT许可证只覆盖扩展自身的代码,和用户OCR出来的内容毫无关系。
更矛盾的是它自己的隐私文件。PRIVACY.md告诉用户,如果对隐私处理有疑虑,去开一个GitHub issue反馈。但仓库检查时,Issue创建功能被限制,已有的issue和PR数量都是零,三次可见提交全部标注在同一天完成。唯一承诺的公开监督渠道,在项目诞生的那一刻就没打开过。
它自称对清晰渲染的文本能做到九成以上的识别置信度,这个数字目前只是开发者自述,没有任何第三方跑分或独立测试可以印证,零网络请求的隐私承诺也是同理。
权限做得细致,治理却是空白,这个组合才是它真正的产品风险
- 风险.版权由用户独自承担,出版方一旦追究,开发者几乎没有留下任何免责说明。
谁会用,谁该盯
对研究者和学生来说,这是一个真实的效率增量:面对扫描书、加密PDF、不让选字的阅读器,能免费、离线、不上传图片地跑一遍OCR,省下的是逐页手打或截图发云端API的成本。代价是版权风险自己扛,隐私和准确率的承诺也没人能替他们验证。
对出版方而言,这类工具打开了一条新的绕道:技术性复制保护被离线OCR加大模型的组合直接架空,而且发生在Chrome官方商店审核范围之外——目前这个扩展只能靠"开发者模式加载"安装,还没有提交上架申请。真要申请上架,README里"把整本书变成文本"这句宣传语,很可能正是审核会重点盯的那一句。
- 结论.权限设计的克制掩盖不了治理层面的空白,这才是它真正的产品风险。
接下来值得盯的,是这个项目会不会补上版权提示、修好issue入口,以及有没有人愿意做一次独立测试,核实它自称的隐私和准确率承诺。在那之前,它更像一个方便的开发者工具,离经得起公众审视的产品还差一步。