Netnography · Hacker News · 2021–2026
Clicked through
I went looking for people who weigh a risk and proceed anyway. I found
people meeting a warning that has no answer they can give.
A design-research study by Himanshu Kalra.
76 coded items, drawn from a corpus of 372 Hacker News threads. The corpus, the
sampling log and every screening decision are
in the repository.
14
items, across 10 separate threads, about a warning that
cannot be satisfied — the largest and most widely spread code
6
items where someone weighs a risk and proceeds — the thing
this study went looking for, one per thread, nowhere discussed at length
3,158 → 76
items retrieved, then read, then coded. Every drop in
between is recorded with a reason
The warning that cannot be obeyed
A browser tells you a certificate cannot be trusted. You are connecting
to a printer on your own network. There is no compliant answer to give, because the
public-CA path the warning assumes does not exist for a device on a LAN address.
The warning has one meaning available — someone may be attacking you — and the
situation has another, and nothing in the interface can hold both. This is the largest
code in the corpus and the most widely spread across threads, and it is not a story
about judgement. It is a story about a dialog with no correct button.
When someone proceeds here they are not discounting a risk they understand. They are
resolving a mismatch between what the warning can express and what is actually
happening. That distinction matters, because the behaviour gets recorded as user
error either way.
Three things follow, and practitioners describe all three themselves: the
organisation forbids the compliant path until the insecure one becomes policy; the
goal quietly becomes the silence of the indicator rather than the security it
indicated; and everyone involved can see the habituation coming and says so.
What people actually said
Five patterns, in the order the argument runs. Every quote below appears verbatim in
the published corpus, and a script in the repository checks that — not that the id
resolves, but that the quoted words are really in the item they are attributed to.
The compliant path exists, and the organisation forbids it 4 items · 2 threads
Where a compliant option does exist, the obstacle described is almost never
technical. It is a queue.
Unfortunately, enterprises are intensely risk averse. I worked at a place where we
could only generate proper certs by manually submitting a ticket to IT and waiting
probably days to get it back, giving us zero hope of applying meaningful
automation. Getting certs from a proper CA was absolutely forbidden, despite our
lobbying, so in a lot of cases self-signed certs were the only option if we wanted
to automate.
A117 · on Hacker News
Where I work it’s months, and fights, and maybe even several meetings. And that’s
only if you fill out the correct form the exact right way. Any slight deviation and
your ticket is closed weeks after you opened it with the field you got wrong.
A118 · on Hacker News
The prohibition on proper certificates is what put
self-signed certificates into production. A risk-averse process produced a less
secure outcome than no process would have. Both items sit in one thread, so read it
as an illustration rather than a distribution.
The goal becomes the silence of the indicator 3 items · 2 threads
The clearest item in the corpus, and the one that most deserves reading twice.
I have one supplier that uses letsencrypt to generate a wildcard certificate, then
distributes it as part of a software update to thousands of machines in hundreds of
companies across the world. The exact same certificate and key. But it gets rid of
the red X in a browser so tick
A127 · on Hacker News
A private key shipped to thousands of machines is worse than
the self-signed certificate it replaced — the same poster says so in the next
sentence. What it buys is a browser that stops complaining. The indicator became the
target, and nothing downstream is capable of noticing, because from the browser's
point of view nothing is wrong.
Everyone can see the habituation coming 5 items · 4 threads
The corpus does not need an outside analyst to point out that unsatisfiable warnings
train people to dismiss warnings. Practitioners say it unprompted, as an argument
against a design.
Second, it reduces your security because your users will inevitably learn to ignore
certificate errors. Thirdly, you'll never stop the certificate errors.
A122 · on Hacker News
the auto-generated self-signed RDP server certificates are only valid for 6 months
for some reason, so users eventually learn to just ignore these warnings.
A52 · on Hacker News
“Six months for some reason” is the whole mechanism in five
words. A default nobody chose deliberately sets how often an unavoidable warning
fires, and the frequency decides what the warning comes to mean.
There'll be a sign that says "Peanut free zone" and everyone will read it and
respect it. Then there'll be a sign that says "Please be sure to pick your kid up
by x o'clock." And everyone will read it and respect it and silently stop looking at
it cause they know.
A902, on a daycare rather than a network · on Hacker News
The control that teaches the opposite lesson 13 items · 4 threads
The second-largest code is about security controls training the behaviour they
punish. Phishing training dominates it, and the complaint is consistently mechanical
rather than attitudinal.
My university routinely sends notifications about required annual phishing training
that violate almost every point in the training about how to avoid getting phished.
Its been happening for years. Urgency. Appeals to authority. Grammatical errors.
Mystery click-me links that go outside the domain to training service providers that
we do not use in any other context.
A925 · on Hacker News
Corporations outsource almost every single tool used by their employees and train
them to cough up their corporate credentials no matter what url the browser
identifies. In essence, they phish their employees 100 times a day.
A922 · on Hacker News
This is the sharpest design claim in the study. The advice —
check the domain — is not wrong. It is inapplicable, because the organisation
has already made its legitimate traffic indistinguishable from the attack. The
training asks people to apply a test their employer has arranged to fail.
And the measurement sits on the same footing as the advice:
A couple of times, I got emails that seemed suspicious, but I figured I would click
the link to investigate further. I was on high alert and would not have entered
login credentials or opened an executable or anything like that, I just wanted to
check it out and see. Of course, it was a phishing audit and I failed.
A834 · on Hacker News
Someone who investigated a suspicious email carefully and
disclosed nothing is recorded as a failure. Whatever that metric counts, it is not
the thing the programme exists to prevent. The end state is reported as an outcome
rather than a prediction:
The phishing training in my workplace is so odious, and the consequences for
failing a test are high enough, that it's led to everyone just ignoring all
unexpected communications. Better to ignore it all than to risk making a mistake.
A550 · on Hacker News
What is almost absent 6 items · 6 threads
Worth stating because the study went looking for it. The framing this work started
from — competent people weighing a risk and choosing to proceed — is present, but it
is small and thin: six items, one per thread, no sustained discussion anywhere.
There are two readings and this corpus cannot separate them. Either the deliberate
risk calculus is rarer than the security literature's framing assumes, or it is
simply not the kind of thing people write posts about, while unsatisfiable warnings
and absurd training are. The second is more likely — an unremarkable decision
generates no text — and no count here is evidence for the first.
What the corpus does support is narrower, and more useful: when these practitioners
explain proceeding past a security warning, they overwhelmingly explain it as a
property of the situation they were placed in rather than as a judgement they made.
The evidence
All
76 coded items, in full. Filter by code, search the text, and follow any item back to
the thread it came from. This is the part that makes the rest checkable rather than
merely claimed.
What this cannot support
- No frequencies. Nothing here supports “X% of engineers do Y”. A corpus
assembled by phrase search from a self-selected forum has no denominator. The counts
on this page are counts of items in this corpus and nothing more.
- Thirty threads, not 372. The corpus spans 372 threads, but the 76 coded
items come from 30 of them. Several codes rest on a
single conversation, which is why the chart above shows thread spread next to every
item count.
- Posters are not users. The overwhelming majority of people who read these
threads never post, and nothing here represents them.
- Self-selection, twice over. People write about a warning when the episode
was unusual or annoying, on a forum that rewards a good story. Routine, uneventful
compliance generates no text and is invisible here by construction.
- Retrospective accounts are accounts. Someone explaining why they proceeded
is reconstructing a decision, often long after it. That is legitimate data about how
the decision is justified. It is not evidence of what went through their head.
- First-pass coding was LLM-proposed, then reviewed by the author. No
inter-rater statistic is reported, because none would mean anything. It would be
absurd to write about people taking a defensible-looking shortcut and then quietly
take one.
- One community. Hacker News is English-speaking, technical, US-weighted and
unusually confident of its own competence. Every finding is a finding about that
population.
- A recency sample wearing a date range. Search returns newest-first, so a
date floor plus a thread limit yields the most recent matching threads rather than a
spread. The sampling log reports this per query, with the gaps named.
What went wrong
Three approaches failed before this one worked, and they are kept in the repository
rather than tidied away.
A large corpus can be empty. The first harvest returned 1,786 items and was
mostly noise: search matches whole threads, so a product announcement that used the
phrase “security warning” once arrived with ninety replies about pricing attached.
Tightening the query did not fix it — the second returned 1,791 with the same
problem.
A keyword screen is precise about words and blind to meaning. The third attempt
kept only items containing a query phrase. It cut 2,350 items to 103 — and kept a link
post titled “Preventing Alert Fatigue” with no body text at all, and a Kubernetes
certificate-pinning argument, while missing every account phrased in words the list had
not anticipated. That corpus is committed as corpus-lexical-screen/ so the
failure is inspectable rather than asserted.
The phenomenon is semantic and the retrieval is lexical. No amount of query tuning
closes that gap; something has to read the items. Hence a read-through with a recorded
decision for every one.
And the question itself changed. It began as “why do people click through
security warnings”, the corpus could support about ten items on that, and it was
reframed — before coding, so the codes were not fitted to a conclusion. The original
framing survives as a result of its own, in What is almost absent above.
The other half
the-human-element
examined 10,042 public security incidents and found a large share running through
interfaces, defaults and warnings that set people up to fail. It cannot say why anyone
proceeded, because incident records store outcomes.
These 76 items are an answer in practitioners' own words, pointing at the same place
from the other side. Neither study establishes a frequency. Together they do something
more modest and harder to dismiss: a pattern found in incident records, described
independently and unprompted by the people who work inside it.