DEV Community: szp2005

Reconciling 8 IP-reputation feeds into one verdict: averaging is the wrong default

szp2005 — Fri, 19 Jun 2026 08:42:18 +0000

Wire more than one IP-reputation source into a risk check and sooner or later they disagree. One feed says the IP is a residential ISP address. Another calls it a datacenter VPN. A blocklist says it relayed spam last week. A geolocation provider says it's clean and unremarkable.

The naive move is to normalize everything to 0–100 and average it. I did that first. It produces a number that's wrong in specific, reproducible ways, and on top of that a number nobody can act on. The moment a verdict matters, someone asks "why is this 0.62?" and the average has no answer.

The version I landed on after the averaging one kept embarrassing me reads as a decision log. Every rule below is there because some real IP broke the version before it.

Why averaging fails: three concrete failure modes

1. Low-precision sources dominate the consensus. Some feeds label entire datacenter /16 blocks as "proxy" or "VPN" wholesale. They're cheap and high-recall, so they're noisy. Average them in and a plain Hetzner or Linode box that two of these feeds tagged as "proxy" gets dragged up into mid-risk territory, even when every higher-precision source says it's just hosting. You've shipped a scorer that cries wolf on half of AWS.

2. A single low-confidence report flips a binary feed. Abuse-report databases are community-fed. If your rule is flagged = (totalReports > 0), one retaliatory or mistaken report marks an address as a known abuser. I watched 8.8.8.8, Google Public DNS, come back as "abuser" because somebody somewhere reported it once. Averaging doesn't save you. It buries the bad signal under the good ones for most IPs and then surfaces it on the unlucky ones.

3. Averaging dilutes the one source that matters most. A live spam-relay listing, or membership in a Tor exit-node list, sits close to ground truth. Seven geolocation feeds saying "nothing unusual" should not be allowed to wash that out. Risk signals aren't symmetric, and an average pretends they are.

The model: visible per-source verdicts, asymmetric floors

Two ideas did most of the work.

The first: don't collapse to one opaque number. Keep every source's verdict and show it as its own line item. Which feed, what it claimed, what signal category it falls under (datacenter, residential proxy, Tor exit, active abuser, spam-list hit). Then whoever consumes the score decides whether a given flag matters for their case. A Tor-exit listing is disqualifying for a signup flow and irrelevant for a geo-IP cache.

The second: keep a weighted baseline, but let signal type set a hard floor. The aggregate starts as a precision-weighted average, and then certain confirmed signals impose a minimum the average can't pull below.

Tor exit node (confirmed)      → floor 90
Dedicated proxy/VPN (consensus)→ floor 65
Confirmed abuser               → floor 55
Datacenter / hosting           → floor 35

A floor says: if this signal is present, the score can't drop below X no matter how many geo feeds call the address clean. Swapping type-driven floors in for the pure average is the one change that got the output to line up with what an analyst would actually conclude.

The rules that keep the floors honest

A floor is only as trustworthy as the boolean that trips it. Each of these earned its place by killing a specific false positive.

Proxy/VPN needs consensus from dedicated sources. The low-precision general feed never gets to establish a proxy verdict on its own. On datacenter ranges I require ≥2 dedicated (purpose-built proxy/VPN) sources to agree. On residential ranges ≥1 is enough, since a residential proxy is rarer and so means more when a specialized feed flags it. Hetzner and Linode fall back to "hosting 35" instead of a phantom "proxy 65," and a real consumer-ISP proxy still trips.
Tighten the noisy binary feed. An abuse listing now requires score ≥ 25 AND reports ≥ 3 (or ≥2 distinct reporters), and the address can't be on the provider's own allowlist. 8.8.8.8 stops being an abuser.
Whitelist known infrastructure ASNs. Google, Cloudflare, and the like suppress the abuser and hosting floors. A CDN edge node isn't a threat, and you don't want your scorer picking fights with the backbone of the internet.
Treat ASN reputation as standalone evidence. A small set of autonomous systems are VPN/proxy-only businesses: M247, Mullvad, Proton, a handful of others. For these, membership alone settles it, with no cross-source consensus needed, because the network operator's identity is the signal. This recovers the case where one feed alone recognizes a niche VPN that the consensus rule above would otherwise suppress.
Add a hard, independent signal: DNSBL over DoH. I query a handful of DNS blocklists, reversing the octets against each zone and going over DNS-over-HTTPS so it runs from an edge runtime. A hit there is close to ground truth and leans on nobody's opaque vendor score.
Short-circuit reserved and CGNAT ranges before scoring. CGNAT (100.64.0.0/10), TEST-NET, benchmark, multicast, and the IPv6 equivalents get an explicit "reserved, here's the category" response rather than going through the pipeline to be mislabeled. It also keeps thousands of carrier-NAT users behind one exit from being scored as a shared proxy.

Make the verdict auditable, not just displayable

If I had to press one point on anyone building this, it's this: emit the breakdown as structured data, not just the final number. Every lookup returns each source's contribution, the weighted average before floors, which floors fired and why, and the final value. You get debuggability out of it. When a verdict looks wrong, the breakdown tells you at a glance whether it was a bad weight, a floor that shouldn't have fired, or thin data. You also let the user overrule you: the person reading the score can tell whether it rests on one thin signal or a five-way consensus, and judge for their own case. A black-box number forces all-or-nothing, trust it blind or throw it out.

What I still haven't solved well

A few open problems, since anyone who's done this for real will have opinions.

CGNAT and mobile carriers are the worst of them. Shared-exit NAT and a residential proxy pool throw off the same surface signal: many users, one IP. Short-circuiting the reserved CGNAT block helps, but carriers also use public ranges that look identical to a proxy from the outside. I flag uncertainty rather than guess, and I still don't have a clean discriminator.

Then there's absence of evidence versus evidence of absence. For smaller regional ISPs the databases run thin. "No source flagged it" reads as "clean" when it often just means "nobody has data." Right now I surface coverage, the count of how many sources had any opinion at all, next to the verdict. I'm not convinced that's enough.

Last, the residential-versus-datacenter split. When two classifiers disagree on the same IP I show both labels and leave it unresolved. Whether a confidence-weighted merge beats preserving the raw disagreement, I genuinely don't know.

If you've run reputation scoring at scale, I'd value your take on the /24 neighbor signal (contamination ratio weighted by flag recency?) and on the residential/datacenter conflict above.

The scorer described here runs behind ipok.io, a free, no-login IP reputation checker that shows the per-source breakdown instead of a single number. The CLI is MIT on GitHub. Happy to go deeper on any of the data-source quirks in the comments.

Making "files never leave your browser" verifiable with DevTools and CSP

szp2005 — Mon, 15 Jun 2026 03:23:04 +0000

"Files never leave your browser" is becoming standard copy for PDF tools, image editors, and document converters. But a trust claim and a verifiable fact are different things. Here's how to turn "zero upload" into something any user can audit in about two minutes, and how to enforce it at the browser level so it isn't just a promise.

Step 1: Read the Network panel

Open DevTools → Network, enable "Disable cache", reload. While processing a file, filter by "Fetch/XHR" and "Doc". A genuinely client-side tool should show only HTML/CSS/JS/WASM asset loads — no POST requests, no GETs carrying file content in query parameters.

The non-obvious trap: third-party analytics, Google Fonts, and CDNs all show up as outbound requests. If you claim zero uploads, those count too. The honest move is to self-host fonts and scripts and drop analytics entirely, so the request list is genuinely short enough to eyeball.

The Network panel is the human-readable check. The next part is what actually makes it hold.

Step 2: Enforce egress with CSP `connect-src`

This is the piece people get backwards, so it's worth stating precisely.

CSP's connect-src is an egress allowlist the browser enforces before the request is sent. A fetch/XHR to an origin that isn't on the list is blocked by the browser and never leaves the machine. You'll see it fail in the console as a CSP violation, with no entry in the Network tab going out to that origin.

This includes no-cors requests. no-cors is sometimes assumed to be an escape hatch, but it isn't one for this purpose. All no-cors does is let you issue a cross-origin request while making the response opaque (you can't read the body). It does not bypass connect-src: if the target origin isn't in your connect-src allowlist, the no-cors request is blocked exactly the same way — it never goes out. So you can't smuggle a file out to a third party with no-cors under a tight CSP.

That's what makes CSP the actual proof, not just documentation. Tighten connect-src to 'self' (or an explicit list of the few endpoints you genuinely need), and any code path that tries to ship data to another origin — yours, a third party's, an injected script's — is stopped by the browser. A realistic policy:

connect-src 'self';
font-src 'self';
script-src 'self' 'wasm-unsafe-eval';
img-src 'self' data:;

Note 'wasm-unsafe-eval' rather than the broader 'unsafe-eval' — modern browsers support the narrower directive for instantiating WASM, so there's no reason to grant full eval.

With that in place, the Network panel check from Step 1 stops being "trust me, the list is short" and becomes "the browser will refuse to send anything I didn't whitelist, and here's the empty list to confirm it."

Step 3 (optional): Content-Length as a sanity check

If you want a quick gut-check rather than reasoning about the allowlist, clear the Network panel before triggering processing, then sum the Size column afterward. If the total is nowhere near the original file size, no file content went out. This also catches chunked-transfer or WebSocket approaches that a naive "look for a POST" scan might miss. It's a weaker check than the CSP guarantee, but it's fast and visual.

A Service Worker doesn't replace CSP

A Service Worker can intercept fetches and is useful for offline caching, but it's not the egress boundary — it's first-party code that can be bypassed or simply not cover a code path, and it does nothing about requests that don't route through it. CSP connect-src is enforced by the browser regardless of your application code. Use a Service Worker for caching if you want; rely on CSP for the "can't exfiltrate" guarantee.

What this looks like in practice

I built a PDF tool this way (moguanpdf.com, my own project — mentioning it only because it's a live example you can poke at). The classic tools (compress, merge, split, OCR, watermark, encrypt/decrypt, etc.) run entirely in-browser via WASM + pdf.js. Open DevTools → Network while processing a file and you'll see only .wasm, .js, and .css loads, no POST, no analytics. The one server-side exception is the AI features (summarize/translate/Q&A), which send extracted text rather than the file, and the UI says so. I'd encourage auditing it the same way you'd audit anyone else's — that's the whole point.

The broader point

If your users handle contracts, medical records, or financial documents, "open DevTools and follow these steps, and here's the CSP that guarantees it" is a stronger statement than any privacy policy. The Network panel shows users an empty list; connect-src 'self' is the reason the list stays empty. A tool that can't survive that audit probably shouldn't be making the claim.

643 articles, 11 Google clicks: my 4-month AI SEO experiment

szp2005 — Wed, 27 May 2026 15:29:12 +0000

I spent 4 months and 643 articles to test AI-generated SEO. Here's what 11 clicks taught me.

TL;DR: I built a 4-site, 643-article AI-content portfolio over 4 months. Google gave me 11 clicks. AdSense rejected one site for "low-value content". Here's the experiment, the numbers, and what I think I got wrong.

The setup

January 2026, I left a salaried job to build a "one-person company." The thesis was simple and very 2025: a single operator + Claude + a content pipeline can produce SEO-friendly articles at a scale that used to require an agency. Pick 4 niches, pick 4 domains, point the pipeline at each, wait for Google traffic, monetize with AdSense + affiliate.

This is the kind of plan that sounds reasonable in a YouTube video and obvious in a Twitter thread.

The 4 sites:

Site	Niche	Articles
`ai.toolrouteai.com`	AI tool reviews and comparisons	172
`gear.toolrouteai.com`	Home office equipment	142
`notes-automate.com` (EN + zh-cn)	Obsidian / PKM workflows	174 + 174
`pkm-insights.com`	Personal knowledge management theory	191

Total: 679 English articles + 174 Chinese translations = 853 published URLs. Across 4 months. That's ~7 articles per day, every day, including weekends. No human writer can sustain that rate. I didn't try — Claude wrote every word.

The stack:

Astro 5 static sites, deployed on Cloudflare Pages (free tier)
Content pipeline: n8n workflows on a Docker host, calling Claude for drafts, Gemini for research, MinIO for asset storage
A custom Telegram dispatcher (19 slash commands) for monitoring, manual triggers, daily briefs
A cross-platform "viral content" scraper hitting Reddit, Hacker News, Substack RSS, YouTube transcripts — designed to source title angles from what was already winning elsewhere
6 Cloudflare Workers running cron jobs for various pipelines

Infra cost: $0/month. The whole thing runs on free tiers, hardware I already owned, and the fact that I write code faster than I write prose.

The result

After 4 months and 643 indexed articles:

Google Search Console clicks: 11
Email subscribers: 0 (the newsletter form sat at the footer of every page)
AdSense status: notes-automate.com rejected for "low-value content"; ai.toolrouteai.com still under review; the other two never submitted
Affiliate revenue: $0
Direct traffic / brand searches: 0

11 clicks. Across 4 months. Across 643 articles. Across 4 domains.

That's a click-through rate that rounds to zero. If I'd just posted one comment per day on Hacker News for 4 months, I would have gotten more traffic.

What actually happened

I want to be precise about this part, because the obvious narrative ("AI content slop doesn't work") is too simple and partly wrong.

The content was not visibly garbage. I read through several articles last week. Most of them are coherent, technically accurate, structured for SEO (H2/H3, intro paragraph, FAQ, related links), and would pass a casual human reader's smell test. They are not Mad-Libs blogspam. They are something more interesting: technically competent, contextually empty.

Google indexed almost everything. Out of 853 URLs, ~580 are indexed. The "已抓取-尚未编入索引" (crawled, not indexed) bucket is real but not dominant. So this is not a "Google never saw my site" problem.

The 11 clicks were spread across long-tail queries with single-digit monthly volume. Things like "obsidian dataview snippets for book trackers." Niche enough that there was little competition. Common enough that Google ranked me on page 1 for the query. But also: small enough that ranking #1 means 1-3 clicks per month, total.

AdSense's "low-value content" rejection is the most informative signal. It didn't say "too thin" or "duplicate." It said "low value." That's a different judgment — the reviewer (or model) decided my articles, despite being long and structured, weren't adding anything a reader couldn't get faster from the next 10 search results.

I'd been telling myself for 4 months that I was building a scalable content business. What I had actually built was a scalable irrelevance machine.

Where I think the mistake was

A few candidates, in order of how much I now believe them:

1. I optimized the production loop, not the distribution loop.

I spent ~80% of my time on the pipeline: making the n8n workflow more reliable, building the dispatcher, adding the Telegram alerts, the cron jobs, the viral scraper, the auto-translation system, the markdown linter, the OG image generator, the AdSense injector, the sitemap builder. All of this is "make production faster."

I spent ~5% of my time on distribution: submitting sitemaps, building 4 random backlinks. There is no version of this experiment that works without distribution.

If I had spent the 4 months differently — say, 80% on distribution and 20% on writing 50 articles by hand — I'm now fairly sure the outcome would have been better. Not great, but better than 11 clicks.

2. SEO doesn't work like it did in 2021.

The old playbook: write 500 articles, build a few backlinks, wait 6 months, get Google traffic. People still teach this. It worked. It does not work now, at this scale, with this content type, for one operator.

Google's quality threshold has moved. Helpful Content Update + the December 2024 spam updates + whatever they're doing internally with their own AI classifiers — the bar is higher than the bar AI-generated articles can clear, even when the articles are coherent.

I should have known this from reading Google's documentation. I read the documentation. I rationalized it as "applies to other people."

3. "Niche selection" became "niche of niches" without me noticing.

gear.toolrouteai.com is about home office gear. Fine niche. But the articles I wrote weren't "best monitor 2026" — they were "best portable monitor for dual-screen laptop setup." That second query has maybe 30 searches per month. Globally. After Google takes its cut for shopping results and YouTube widgets, you're competing for ~5 organic clicks.

I had been told that "long-tail = less competition = good." This is technically true and operationally useless. Less competition for a query with 5 clicks per month is still 5 clicks per month.

4. I confused "publishable" with "valuable."

The pipeline produced articles that were publishable. They cleared the bar of "not embarrassing to have on the internet." That bar is not the bar that gets traffic. The bar that gets traffic is "this is the best result a reader will find for this query today." I was nowhere near that bar.

What I think the experiment actually proved

Not "AI content doesn't work." That's the lazy take and it's not what my data shows.

What it proved, for me:

AI content at scale, deployed by a solo operator with no distribution, does not produce a business in 4 months. (Maybe in 12 months. Probably not.)
The infrastructure is the easy part. I built a sophisticated pipeline. So can you. So can 10,000 other people. None of us are going to make money from the infrastructure.
The bottleneck is distribution, not production. Always was. Will be more so as production gets cheaper.
"Programmatic SEO" is mostly a 2021-era pattern that smart operators are still riding the tail of, but the entrance is closed.

What I'm doing now

I'm not deleting the sites. They cost $0/month to run. The 11 clicks might be 1,000 clicks in 12 months — Google indexing curves are long. I'm just not going to write any more articles for them.

Instead, I extracted the genuinely useful parts of my own workflow into 5 free tools and shipped them as tools.toolrouteai.com:

Prompt Optimizer — turns "write me a blog post about X" into a structured prompt with role, constraints, output format
Comparison Builder — pulls from a JSON index of ~50 AI tools, lets you pick 2-5, exports Markdown or PDF
Obsidian Template Generator — browser-side, generates a .zip of Markdown + Dataview + Templater files
Price Tracker — scheduled scraper of 50+ AI tool pricing pages, exposes RSS + JSON + a UI for change signals
Side Hustle Ideas — give it your skill + weekly hours + budget, returns 3 realistic ideas with first-week action plans

No signup, no API key, no paywall. $0/month to run. They're useful to me; they might be useful to you. If they're not, please tell me what's missing.

And I'm writing this post — which is, finally, distribution.

If you're thinking about doing the same thing

Don't, if your plan is "643 articles, ranking, AdSense." That door is closed.

Do, if your plan is:

5-20 articles, each one targeting something you have a genuine and verifiable edge on
80% distribution (HN, Reddit, niche newsletters, podcast appearances, paid placement on niche sites)
Treat the articles as proof of competence, not as traffic-generation devices
Monetize with consulting, products, or paid newsletters — not display ads

Or do, if your plan is "I want to learn the infrastructure." You'll learn a lot. Just don't expect a business at the end.

I'm a solo maker based in China. I'll respond to every comment in this thread, including the ones telling me I missed something obvious — those are the most useful.

If you want to follow what I do next, my email is on tools.toolrouteai.com. No automated newsletter; I'll write to you when I have something worth saying.

— Alex