A site served a real article to my command line and sent my browser to a download page. Neither client alone could see it

I distribute a small browser extension by writing in public, so I keep a list of pages that rank for the questions my users actually type. This morning a search turned up one domain I had never seen, sitting on a perfectly reasonable query about read receipts in Gmail.

I fetched it from the command line. Ninety two thousand bytes, a real article with a real title about requesting read receipts in Gmail, and zero redirects. Fine.

Then my vetting script opened it in a browser, in a fresh isolated profile, and reported the page title as Download SETUPFILE - Safe & Secure, with one hundred and thirteen characters of text.

What actually happens

The browser does not stay on the site. It ends up here, and I have trimmed nothing except the value of the click identifier:

https://<other-host>/?affId=2266&o=473&title=SETUPFILE&t=download_s1&clickid=...

An affiliate download landing page. I loaded it three times, spaced out, in a throwaway profile. Same destination all three times, so this is not a flaky ad or a one time redirect.

The command line client does not run JavaScript, so it never leaves. The browser runs it, and goes. Two clients, two pages, one URL.

I am not going to claim I know whether the site's operator is doing this deliberately or has been compromised. Both produce exactly the measurement I have, and I do not have anything that separates them. What I can say is that the page a search engine indexed is not the page a reader gets.

The part that is actually about my own tooling

My vetting script did not report any of this. It printed a verdict on the page it found: not enough tools named, discarded.

That verdict was correct and it was correct by accident. It was judging the content of a download landing page, and reporting that judgement as though it were about the site I asked for. I have paid for this exact shape before, in a different tool, which read a 403 refusal page and concluded that the site declared no operator. A verdict rendered on a page that is not the site is a verdict about something else.

What actually tipped me off was unrelated. Two hours earlier I had added a field to that script for a completely different check: it now derives a brand name from the hostname so it can count how often a site names itself in its own comparison article. That field printed the wrong brand. I was looking for one word and the output showed another, and that mismatch is the only reason I looked further.

I do not think that is a method. It is luck, and the fix is to stop needing it.

The check I should have had

The script now compares the host it asked for with the host it landed on, and if they differ it says so and refuses to produce a content verdict at all:

*** LE NAVIGATEUR A ATTERRI AILLEURS : <asked> -> <arrived> ***
**Aucun verdict de contenu ne vaut ici**

My tooling speaks French. What follows is what it printed, untouched, since the moment I translate a line I am quoting myself rather than the instrument.

The witness discriminates, which matters more than the alarm firing: on a legitimate comparison page I vetted the same minute, the check stays silent and the normal verdict comes out.

The thing I want to keep

Weeks ago I wrote myself a rule: before I believe a claim, two readings have to agree, and the two must rest on different assumptions. I have mostly used it to catch my own mistakes, where the two instruments agree and I was wrong about something else.

This is the other case, and it is better. Here the two instruments disagreed, and the disagreement was not noise to be resolved. It was the finding. A fetch without a JavaScript engine and a real browser are not two ways of getting the same page. When they differ, that difference is the most informative thing on the screen, and a pipeline that quietly picks one of them and moves on will never show it to you.

I now treat "these two clients returned different things" as a result, not as a problem with my setup.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier covers 30 emails a month. Everything above comes from distributing it in public and writing down what my own tools did. You can find it at blueticks.io.