I built a free Chrome extension after seeing someone accidentally open an adult site while screen sharing

No — and I'll be straight about why: it's pre-launch. Store listing done, sixteen builds deep, zero installs that aren't mine. So anything I told you about which layer users keep it for would be me guessing in a confident voice.

There's a second reason worth naming, because it's a cost I chose on purpose. There's no telemetry in it. So even at a thousand installs I won't have a funnel showing me which layer earned the keep. I'll be learning that from conversations and uninstall replies, which is slower and noisier than a dashboard. That's the price of the privacy claim and I'd rather pay it than quietly ship a beacon.

You're also right that the layers read like four products, and that's a positioning failure on my end — what you read is architecture docs, not a pitch. My actual bet is that only one of them is a product. Blocking a known-bad domain is a worse uBlock. A confirm-before-you-navigate dialog is a browser feature nobody asked for. But "flip one switch before you present, and your keys, tokens and personal tabs stop being visible on the call" is something nothing else does — and it's the layer that would be hollow without the other three sitting under it.

So the number I care about isn't which layer rates highest. It's whether someone flips the switch a second time. One flip is curiosity. Two means it became part of getting on a call, and the rest of the architecture is just what makes the switch trustworthy enough to keep flipping. If it turns out people only ever use the blocklist and never touch the toggle, then I've built a mediocre content blocker and should say so out loud.

You're right about the boundary, and that's the axis the whole thing is built on. Known-bad domains go through declarativeNetRequest, so the request never leaves the browser — there's no frame to be embarrassed by. Heuristic matches get caught at onBeforeNavigate and the destination is replaced before anything paints. Link clicks are intercepted in the capture phase, ahead of the page's own handlers. Redaction runs at document_start rather than on load, for the same reason.

Where I'd push back is "hold unknown navigation." Unknown isn't the same as unsafe, and essentially the entire web is unknown to a local table. Gating every unfamiliar hostname during a share is the fastest possible route to an uninstall. So it's tiered instead: known-bad blocked pre-request, heuristic match gets the confirmation, unknown gets nothing louder than redaction. The interstitial detail I am taking from you is the redirect chain — webNavigation hands me the hops, and "you clicked X, this ends at Y" is far more persuasive than a category label.

On metrics you've put your finger on a real tension: the only honest way to count accepted, cancelled and false-positive is locally, visible to the user, never phoning home. So counters live in chrome.storage and the history page lists every block, warning and allow. False positives come back through a report button, not a beacon.

Verifiability: five permissions, zero host_permissions, one plain sentence each in the README. Classification is a pure offline function — no network call exists in that path. And 215 real sites plus 77 adversarial look-alikes (essex.gov.uk, sex-education.org, bet.com) are in the test suite precisely because a false positive is the failure that kills this category of extension.