4 comments

  • KevinChasse12 hours ago
    Nice work. One thing I've noticed with locally checking extensions against threat lists is that the verification process itself can become a target. Stateless, deterministic verification — where hashes or IDs are derived on-device and never stored centrally — reduces risk of supply chain or server-side compromise. It’s a subtle design point, but it can prevent a malicious actor from using the verification system itself to exfiltrate data.
    • toborrm912 hours ago
      Great point. The current setup is exactly what you&#x27;re describing, a fully local verification with no phone-home behavior.<p>The CLI&#x2F;GUI tools I&#x27;m building read your locally installed extensions, extract their IDs, and check them against the CSV (which you can clone&#x2F;download). No data leaves your machine during the scan.<p>The only &quot;central&quot; piece is the GitHub-hosted CSV itself, which is just a static file anyone can audit, fork, or host themselves. No API calls, no telemetry, no server lookups.<p>You&#x27;re right that this design prevents the verification tool from becoming an attack vector. Even if my repo got compromised, worst case is a bad CSV, your local scan process stays isolated.<p>I&#x27;m also looking at surfacing critical permissions for locally installed extensions,things like &quot;access to all websites,&quot; &quot;read clipboard,&quot; etc. That way users can make informed decisions about what to keep based on what&#x27;s actually authorized, even if an extension isn&#x27;t in the malicious database yet.<p>Appreciate the security-minded feedback.
  • julius10 hours ago
    Super cool. Brave support by any chance? Using Linux, it found my Chrome, but thats not my primary browser.
  • wasmainiac8 hours ago
    Super cool, I hope this gets the attention it deserves!
  • politelemon10 hours ago
    Could Firefox extensions be included?