I shipped a Chrome extension, then found a permission bug and a hidden analytics call in the same week

The problem I was scratching Every time I was debugging a web app, the same friction kept happening: I'd see a request in Chrome DevTools' Network tab, and to actually test a variation of it — a different header, a different body, a different query param — I had to copy it out to Postman or Insomnia, paste it in, re-add auth headers, and lose all the DevTools context in the process. Small friction, but it happened a dozen times a day. So I built Network Sniper, a Chrome extension that puts an editable, resend-capable request panel directly inside DevTools. Capture a request, edit it in place, hit resend, and see a diff between the old and new response — no context switch. It's local-first by design: no telemetry, no cloud sync, sensitive headers masked by default. That promise turned out to be more important than I expected, for reasons I'll get to. Launch day: smaller than I hoped, which taught me something I posted a Show HN. It didn't hit the front page — under 10 upvotes, a handful of comments. In the first few hours I got about 15 installs, then growth flattened out almost completely. If you're benchmarking your own launch: don't assume a Show HN that doesn't take off means the product is bad. It might just mean the post didn't catch the algorithm's attention that hour. I posted on a Wednesday; in hindsight I'd try a different day and spend more time on the title. The bigger lesson came from what happened after launch, not the launch numbers themselves. Surprise #1: I accidentally asked for way too much permission To support resending requests to any API the user is debugging (which by definition could be any origin — that's the whole point of the tool), my first shipped version declared: "host_permissions": ["*://*/*"] This works, technically. It also means Chrome shows every installer a scary warning: "Read and change all your data on all websites." For a tool whose entire pitch is "trustworthy, local-first, minimal," that's a bad first impression — and it's exactly the kind of thing a careful reviewer (or a future acquirer, if you're building to eventually sell a side project) will flag immediately. The fix was to stop asking for broad access up front, and instead request permission for a specific origin only when the user actually tries to resend a request to it: "optional_host_permissions": ["*://*/*"] // only requested at the moment of use, scoped to the exact origin const granted = await chrome.permissions.request({ origins: [targetOriginPattern], }); Approved origins get cached for the session so the user isn't re-prompted every time. The install-time warning disappeared completely. Lesson: if your extension needs broad capability, that doesn't mean it needs broad permission — request narrowly, and only when the user's action actually requires it. Surprise #2: the "zero telemetry" tool had a Google Analytics property This one stung more. A few days after launch, I was checking install numbers and ended up looking at a Google Analytics real-time dashboard that was, unmistakably, tied to my extension's own ID — active users, country breakdown, the works. For a project whose README and public launch comment both said "zero telemetry, nothing leaves the browser," that's not a small inconsistency. I did a full audit: grep'd the entire codebase and build output for any analytics SDK, tracking domain, or beacon call. Found nothing in the runtime code. Loaded the actual packaged extension in a real Chrome profile, pointed it at a live API, and watched the network traffic for a sustained window. Zero requests to any analytics domain — every outbound request went exactly where the user told it to go. The likely explanation: Chrome Web Store's own Developer Dashboard lets you optionally link a Google Analytics property to track your store listing page views — a completely separate thing from the extension's runtime behavior. It's easy to conflate "traffic to my listing" with "telemetry from my extension," and I did, for a few uncomfortable hours. I still added a regression test that scans the entire source tree and build output for analytics domains and SDK signatures, plus a comment at the top of the manifest and entry files saying, bluntly, don't add tracking here. Not because I found a violation, but because "I was pretty sure it was fine" isn't the bar I want for a tool whose whole pitch is trust. Where it stands now Network Sniper is live, permission-minimal, and — as far as a real, instrumented live-browser test can show — genuinely telemetry-free. Growth is slow and mostly self-inflicted right now (a quiet Show HN, a Reddit post caught by a spam filter I'm still waiting on mods to review), which is its own lesson: shipping the product is maybe 30% of the work, and I underestimated the rest. If you debug APIs and have felt the Postman-copy-paste friction, I'd genuinely appreciate you trying it and telling me what's missing: Network Sniper - Chrome Web Store DevTools network inspector, editor, and resend client with environment variables and local-first storage. chromewebstore.google.com It's free, Manifest V3, and — now provably — doesn't phone home.