||
如果你平时会测试浏览器隐私、排查自动化环境、观察 WebRTC / Canvas / WebGL 泄漏,或者只是想知道“这个浏览器到底暴露了多少指纹面”,那你大概率会听到一个名字:CreepJS。
但这次我想先把最重要的一句话放在最前面:如果你是从 creepjs.org 这个域名知道它的,先别急着跑测试。
先把风险说清:项目作者明确警告,`creepjs.org` 不是官方 live deployment我在 2026 年 6 月 30 日 读取到的官方 GitHub 仓库 README 里,作者写得非常直接:
这不是我自己的猜测,而是上游仓库自己写出来的安全提醒。所以如果你看到 `creepjs.org` 这种域名,正确的第一反应不是“太好了,有个现成官网”,而应该是“先回上游仓库确认它是不是官方”。
那 CreepJS 到底是什么?按上游仓库自己的定位,CreepJS 不是一个“帮你绕过检测”的工具,而是一个 educational / research 方向的浏览器指纹检测项目。作者写得很清楚:它的目标是揭示现代反指纹扩展和浏览器在隐私与一致性上的弱点和泄漏。
换句话说,它更像一个“让你看清浏览器暴露面”的显微镜,而不是一个“教你伪装得更像真人”的外挂。
它关注的核心问题,其实很现代上游仓库里列出的目标很有代表性,核心包括:
这意味着它不是只测一个 `canvas hash` 就结束,而是试图从浏览器行为的一致性出发,判断你当前环境到底暴露了什么,伪装了什么,又在哪些地方“说漏嘴”。
官方 live 页面能看到的检测面,非常完整我实际打开官方 GitHub Pages live deployment 后,页面上能直接看到一长串检测维度,典型包括:
这些名字本身就说明,它在测的是“指纹表面”的全景,而不是某一个点状指标。对开发者来说,这种全面性比单个泄漏测试更有价值,因为真实指纹识别往往靠的是多个信号之间的组合与一致性。
它关心的,不只是普通浏览器,还包括很多“自称更隐私”的环境上游仓库 README 里直接列出了不少重点观察对象,例如:
这就解释了为什么 CreepJS 经常会被浏览器隐私测试、自动化环境 QA、反指纹研究的人提起。它不是一个面向普通上网用户的“趣味检测页”,而是一个更偏研究和诊断的工具。
谁适合用它我觉得比较适合以下几类人:
但它不适合被当成“黑盒分数器”。你不应该只看一个结论,然后忽略它背后到底是哪类信号出了问题。
为什么 `creepjs.org` 这种镜像风险特别大这类风险和普通镜像站不太一样。因为 CreepJS 本身就是一个收集浏览器高熵指纹信号的项目。
换句话说,如果你在一个不可信的域名上运行它,你等于主动把自己最细颗粒度的浏览器环境特征,交给了一个上游作者已经明确提醒你不要信任的站点。
这和访问一个普通内容镜像站完全不是一个风险等级。普通镜像最多是内容不准;而指纹检测镜像的问题是,它天生就更接近一个“收集你设备画像”的入口。
我对这类工具的建议是:用官方部署,或者本地研究代码如果你真的要用 CreepJS,我会建议只走这几个安全入口:
而不是把 `creepjs.org` 这种外部镜像当成默认入口。
顺带说一句:`creepjs.org` 当前页面为什么容易误导人我这次也实际读取了 `creepjs.org` 当前公开页,它把自己包装成一个面向开发者的“privacy-first browser fingerprinting platform”,并且给出了 Checker、IP Risk、Signals、Docs、Playground 这些导航。这正是容易误导用户的地方:它看起来很像一个正规产品站。
但问题在于,上游仓库的安全提醒比这类包装更值得信任。对这类项目,真正的信任锚点不应该是哪个域名做得更像 SaaS 官网,而应该是谁掌握源代码、谁写了 README、谁定义了官方部署。
如果只用一句话总结CreepJS 值得看,但 `creepjs.org` 不值得盲信。
我会把 CreepJS 定义成一个很有研究价值的浏览器指纹检测项目:它能帮你看清浏览器、扩展、自动化环境和反指纹策略到底暴露了什么。但也正因为它测的是高熵指纹,入口域名本身就必须格外谨慎。对这类项目,最重要的不是“有没有漂亮官网”,而是“是不是官方部署”。如果你真要用,请优先走上游仓库明确认可的 GitHub Pages 入口。