>> if it isn’t there, it’s probably for a good reason. > which isn’t really true anymore. For most websites, the majority — not just the plurality, but the majority — of visitors arrive by following a link inside an email or an app
I don't think the statement is factually backed up. At least I hate native apps.
> Even so, my custom query string is, in my calculation, an expression of digital etiquette: rather than dump a load of anonymous traffic on your doorstep, I reveal who’s linking, so a website or online shop operator can trace it back and get in touch, if wanted or needed
Anonymity considered harmful these days?
> a wave of new subscriptions and weren’t sure if they were legitimate; a brief email correspondence assured them that yes,
It's not legitimate unless it's signed (and if anybody gives a shit to verify it).
> Note that a handful of sites do choke on unexpected query strings, including YouTube (!),
This is a good habit IMHO.
Anyway, I'm thankful to the original post because it was a good reminder to re-review my browser settings.
Honestly I don't understand why the EU focused on the stupid cookie law instead of referers which are clearly privacy-violating.
If you use Firefox I recommend you make sure `network.http.referer.XOriginPolicy` set to 1.
Publishing something online means I want it to be seen.
Relying or enforcing Referer or query string basically contradicts the intent. Wanting to know where your users come from could be legit but then you basically distort the "public web" aspect to a "public trap" where you try to sneak on visitors.
Not my vibe
Even in that case, you might want to block unexpected values as early as possible in your stack. For example, if you have a legitimate use for a certain set of `utm_source` values, but someone sends you bobby tables, you probably shouldn't log it blindly.
Ditto for the Referer header -- there's a lot of spam, and some of those strings might even be dangerous. You can't trust any of them anymore.
I highly doubt this is true, unless your definition of "app" includes "web browser".
When I said, “if it isn’t there, it’s probably for a good reason”, I was fully aware of native apps, and decided to gloss over them, because I doubt (on no evidence) they’re so significant for me, and things like email and feed readers may well be web apps anyway. And because I’ve tended to fine nuance in the past, and am trying being concise instead.
While thinking about it—is it possible for a browser to know which app sent it the link, e.g. androidapp://com.example.app? Because that’d probably be a perfectly reasonable referrer, if a browser wanted to send it.
> Note that a handful of sites do choke on unexpected query strings, including YouTube (!)
I want to learn more about this.
Neither the ePrivacy directive (commonly called the "cookie law") nor the later GDPR focus on cookies. They are "technology neutral", applying to e.g. URL parameters and HTTP headers too, but just widely misunderstood and badly enforced.
Well, it might be better than no referrer, but if the app is a mail app or feed reader or something, it doesn't really mean much more than "Safari" or "Chrome".
And yeah I'm also thankful also to see that firefox setting.
May 10, 2026
Chris Morgan is tired of people tacking query strings onto his URLs — e.g. www.robinsloan.com/lab/?like=this&and=this—so he’s configured his website to reject those requests outright, rather than suffer in silence.
Naturally, anybody is free to set up their server in any way they like … however, Chris writes this:
If I wanted to know [where a visitor came from] I’d look at the Referer header; and if it isn’t there, it’s probably for a good reason.
which isn’t really true anymore. For most websites, the majority — not just the plurality, but the majority — of visitors arrive by following a link inside an email or an app (e.g. Instagram, Messages on iOS, the Substack app), neither of which set a Referer header; so, all of those visitors are lumped into a vast slab called Direct or Unknown.
This broken mechanism provides the impetus for the custom query string I append to all outgoing links, utm_source=Robin_Sloan_sent_me: understanding that many/most clicks on links I share will come from my email newsletter, I want the source to be legible, particularly in contexts such as, e.g., Shopify.
This isn’t an argument that Chris Morgan should do anything different — opinionated operator decisions make the internet go round — but rather an opportunity for clarification about the current state of play.
I don’t collect or review analytics of any kind on my websites, so I’m not a consumer of this kind of referral info. Even so, my custom query string is, in my calculation, an expression of digital etiquette: rather than dump a load of anonymous traffic on your doorstep, I reveal who’s linking, so a website or online shop operator can trace it back and get in touch, if wanted or needed. (Memorably, this was useful when the Abrams Planetarium received a wave of new subscriptions and weren’t sure if they were legitimate; a brief email correspondence assured them that yes, these people were real … they were nerdy … they wanted the Sky Calendar!)
Note that a handful of sites do choke on unexpected query strings, including YouTube (!), so I maintain a list of exceptions, to which chrismorgan.info is now added.