A guide to reviewing an open-source browser tool's on-device claims through code, package licenses, network boundaries, and tests.
Verify licensing and behavior separately
An open-source license defines conditions for inspecting and using code; it does not prove safety or privacy. Review the repository license, then production dependency licenses and versions. A lockfile makes builds repeatable and source history makes changes traceable.
Inspect shipped packages rather than trusting a badge. Runtime CDN scripts, closed remote APIs, or undisclosed telemetry narrow any on-device claim.
- Read LICENSE and the package manifest.
- Map production dependencies to the lockfile.
- Search for dynamic scripts and network endpoints.
Observe the browser boundary
Run a representative input with the Network panel open. Separate normal document, script, and image loading from requests triggered by the tool. Verify that input never enters a URL, request body, error report, or analytics event.
A restrictive CSP can reduce unexpected connections but cannot repair bad application logic. Inspect Service Worker caches and localStorage/IndexedDB too: not sent to a server does not mean never stored on-device.
Complete the evidence chain
Type checks, lint, and unit tests support structural confidence; browser tests validate interactions, mobile overflow, keyboard access, and metadata. A clean heuristic scan or matching hash is never final security approval.
Strong projects disclose limitations, provide correction channels, and keep consequential actions user-controlled. Report a finding with version, path, reproducible steps, and expected behavior—never real secrets or personal data.
- Tie test results to a version.
- Compare policy claims with actual storage.
- Report vulnerabilities responsibly through SECURITY.md.
Content is checked against visible ByteQuant product behavior and the listed primary sources where available. It is general information, not legal or security advice.