# SnowEyes and the browser extension that reads a page for hidden endpoints > SnowEyes, also called Xue Tong, is a Chrome extension that detects and extracts sensitive information and website fingerprints from a page, including JavaScript rendered after load. It suits security testers and developers auditing what a site actually ships to the browser. **SickleSec/SnowEyes** — 一款用于网页敏感信息检测，指纹识别的chrome插件 - Repository: https://github.com/SickleSec/SnowEyes - Stars: 944 · Forks: 54 - Language: JavaScript - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/sicklesec-snoweyes ## What the extension is built to find on a page SnowEyes, whose Chinese name is Xue Tong, is a browser extension for detecting and extracting sensitive information from web pages, with the stated goal of helping users quickly obtain that information and analyse and process it. The project describes itself as a Chrome browser extension, and the feature list names four capabilities. The first is multi-dimensional information detection, covering multiple kinds of sensitive information and website fingerprints, with results classified rather than dumped as raw text. The second is dynamic content scanning, which captures information from pages whose content is rendered by JavaScript in real time. The third is deep scanning, aimed at sites where one JavaScript file nests and loads others, so that a single top level script does not hide the rest. The fourth is Webpack adaptation, which improves how JavaScript is collected from bundled pages. The interface follows the same split, with separate screens for information collection, fingerprint sniffing, website analysis, and configuration with a whitelist. This is a page-level inspection tool. It runs in your browser, against the site you are looking at, and it reports what that page reveals. ## Why the extension scans at all instead of reading the response body The dynamic scanning capability is the design decision that separates this from a simple view-source approach, and it explains the shape of the rest of the tool. A page that renders its content through JavaScript presents two different realities. The HTML you fetch on the first request may be nearly empty of the data you care about, while the browser ends up holding keys, endpoints, tokens and configuration objects that only exist after scripts have run. A tool that only reads the initial response sees the empty version. SnowEyes scans what the page actually ends up holding, which is why the deep scanning feature exists as well. On some sites, a JavaScript file loads further JavaScript files, and those nested scripts carry their own strings. The deep scan follows that nesting so the collected set is not missing the payloads. The Webpack adaptation addresses the same problem from the other direction. Bundled sites pack many modules into one file, and the collection logic was adjusted so that Webpack output does not defeat the scanner. The cost of this is time and page responsiveness, which the documentation addresses directly in its list of cautions. ## Installing from source through the extensions page The project ships a Firefox Add-ons listing, and the source installation path is described as a sequence of manual steps. First you download the open source release v0.2.7.6 from the repository releases page. ```bash https://github.com/SickleSec/SnowEyes/releases ``` Next you extract the downloaded archive. Then you open the extensions page of Chrome or Edge, which the documentation gives as the `chrome://extensions/` or `edge://extensions/` address. ```bash chrome://extensions/ ``` In the top right of that page you enable developer mode, then click the load unpacked option and select the folder you just extracted. The extension then appears in your extension list and is ready to use. There is no build step in these instructions and no package manager route. The repository layout explains why. The top level holds a manifest.json next to background, content, popup and icons directories, with a README.md. That is the shape of an unpacked extension, where JavaScript is loaded directly by the browser rather than compiled. The versions differ between the two channels. The instructions point at v0.2.7.6, while the release history also lists v0.2.7.6-patch from 2025-10-19 and v0.3.0 from 2026-01-13, so the documented download link and the newest tag are not the same artifact. ## Hover, left click, right click and Ctrl click on a result Once a scan has run, the results are interactive, and the interaction model is worth spelling out because it is unusual and mostly discoverable only by trying. Hovering over any result shows the source URL of that piece of information. A left click copies the source URL of the information. A right click copies the content of that result itself. Holding Ctrl while left clicking opens the source link directly in a new browser tab. So the same list serves two purposes. It is a lookup table for the values themselves, and it is a map of where each value came from, with the copy and jump actions built on top of the same hover information. That distinction matters when you are auditing a page with many findings, because the question is often not only what the value is but which script or endpoint produced it. The repository also carries a custom whitelist feature, added in the same release cycle as the source display, which lets you exclude sites or patterns you do not want to keep seeing. ## The three cautions the documentation raises itself The project lists four things to be aware of, and they read like an honest list of where the tool strains. The first is scan lag. On sites containing a large number of JavaScript files, scanning may take a long time and the page may briefly stutter. The update history reinforces this, with entries describing optimisation of the stuttering problem during search in v0.2.7.3 and a fix for stutter on some pages in v0.2.7.2, which tells you the issue was live rather than theoretical. The second is unknown bugs, with the request to report them as issues, and a note that the program is still being refined. The third concerns deep scanning specifically. The documentation advises using it only when a regular scan does not meet your needs, because in some cases it can produce JavaScript false matches. That is a precise warning: the deep mode trades false negatives for false positives. The fourth is about the registration lookup. The documentation advises registering and using your own ID and Key with the the API box service service, because the public interface has a query rate limit. ## Third party lookup services and the cost of the public endpoints The extension calls out to external services rather than doing all of its work locally. Two are named as third party free interfaces, the Miren API and the API box service, and the project acknowledges them as such. This has a direct operational consequence that the documentation calls out. Public endpoints carry a query rate limit, so a user who runs many lookups will hit that ceiling. Registering and using your own ID and Key with the API box service is the documented workaround, and it is also the reason the configuration screen exists. It is worth being clear about what this means for an audit. Some of the collected sensitive information is resolved by calling out to those services, so those calls leave your browser and the data involved travels to a third party. For a page containing internal hostnames, internal identifiers or credentials found in the source, that is a genuine consideration about where the data ends up, and it applies to the finding workflow rather than only to the scan itself. The presence of the whitelist and configuration screens alongside this dependency suggests the authors expected users to control which hosts and lookups the extension performs, which is where you would start if the default behaviour is too broad for your environment. ## Activity since the v0.3.0 release and an unresolved licence The repository is not archived and the last push was on 2026-08-10. Recent releases are v0.3.0 from 2026-01-13, v0.2.7.6-patch from 2025-10-19 and v0.2.7.6 from 2025-10-13, so the version series has moved past the 0.2.7 line that the installation instructions still reference. That gap between the documented download and the newest tag is the practical upgrade note: if you follow the source install steps verbatim you get v0.2.7.6, and the newer artifacts are on the releases page. The extension is also published on Firefox Add-ons, and the update history records the Firefox build being kept in step with the Chrome one at v0.2.7.3, so both channels are maintained from the same source. On licensing, the facts are thin. The licence field on the repository shows no recognised licence identifier, and there is no LICENSE file in the top level entries, which hold only the README, the manifest, the icons and the extension directories. For an extension you install into your own browser that is mostly a non-issue. For a team that intends to modify the source, re-sign it under their own Chrome Web Store developer account or ship it inside a product, the absence of a stated licence is a real open question that has to be answered by asking the maintainers, because the code is public but the terms are not written down. The primary language is JavaScript, and the extension is described as open source in its own installation steps, which is a claim about availability rather than a grant of rights. ## Conclusion Adopt SnowEyes if you audit what a web application exposes to the browser, especially when the interesting endpoints appear only after JavaScript runs or sit inside a Webpack bundle. Skip it if you need continuous coverage across many sites, since the extension works one page at a time and the documentation warns that heavy JavaScript pages can stall during scanning. Before relying on it, load the release v0.2.7.6 from the repository, register your own ID and Key with the API box service because the public endpoints carry a query rate limit, and note that the licence field on the repository is unknown, so treat the redistribution terms as unresolved until you read the source. ## FAQ ### How do I install the SnowEyes extension from source? Download the release archive from the repository releases page, extract it, open chrome://extensions/ or edge://extensions/, enable developer mode, and use the load unpacked option to select the extracted folder. The extension then appears in the extension list. ### Does SnowEyes detect information that is rendered by JavaScript? Yes. Dynamic scanning captures information from pages rendered in real time by JavaScript, and deep scanning follows JavaScript files that load further JavaScript files, with separate handling for pages bundled with Webpack. ### Why does SnowEyes ask me to use my own ID and Key for the API box service? The public interface has a query rate limit, so the documentation advises registering and using your own ID and Key with the API box service. The extension calls third party lookup services including the Miren API and the API box service. ### When should I use the deep scan mode in SnowEyes? Only when a regular scan does not meet your needs. The documentation warns that deep scanning can produce JavaScript false matches in some cases, and that sites with many JavaScript files can make the page stutter while scanning. ## Sources - [Issues](https://github.com/SickleSec/SnowEyes/issues) - [README](https://github.com/SickleSec/SnowEyes/blob/main/README.md) - [Releases](https://github.com/SickleSec/SnowEyes/releases) - [SickleSec/SnowEyes on GitHub](https://github.com/SickleSec/SnowEyes) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sicklesec-snoweyes