How writing here is published
The most contested post on this site is the March 2026 piece on fifteen Italian citizenship agencies. It tested every editorial question I care about — how to publish security findings about real services without naming people, how to source things properly, how to handle a correction. This page describes the practice, anchored to that post throughout. Where the practice is more general, it’s named as such.
Version 1.1 · last reviewed 6 May 2026.
1. Why publish at all
Security findings normally surface in conference talks, trade publications, or annual reports written for technical audiences. The people who actually choose services that handle their identity documents move on a different timescale. They read the website, scan reviews, and decide. Someone hiring a citizenship agency to handle their grandparents’ birth certificates isn’t going to read the FBI IC3 report on business-email-compromise losses; they need the relevant facts in one paragraph in front of them.
That gap is the reason for the agencies post. The same gap is the reason future posts will exist. Each carries a cost: a risk to the organisations described, a risk to me, and a risk of being misread by either side. When those risks clearly outweigh the public interest in publication, the draft stays in the editorial folder.
2. Principles, anchored to the agencies post
Each principle below has a generic statement and a specific application. The specific is what makes it real; without it, the principle is decoration.
Public interest is the test, not novelty
The agencies post wasn’t published because the technical findings were interesting (they weren’t — missing DMARC records are trade-press boring). It was published because a non-technical reader hiring one of these services to hold their passport copy needs the data in front of them at the point of decision. That standard kills most posts at the draft stage.
Truth, with a verifiable trail
Every aggregate count in the agencies post (87% no effective DMARC, 13 of 15 no CSP, 12 of 15 loading Google Analytics) is a direct count from the JSON archive of the 23 March 2026 scan. The archive lives in the editorial folder; available on request where relevant. The scanner that produced it is open source, so a reader can rerun it on the same domains and disagree.
Proportionate disclosure
The agencies post named no specific exploit, no payload, no path that an attacker could weaponise against the unpatched targets. The findings are category-level (no DMARC, no CSP) because that’s the level the public-interest reading needs. A technical reader who wants the precise check methodology gets it at /methodology; a journalist gets the aggregate stats; an attacker gets nothing they didn’t already have.
Anonymisation by default; naming with cause
The fifteen domains scanned in March 2026 aren’t named in the post. They’re held privately because the public interest is fully served by the aggregate state of the sector; naming would shift the post from sector reporting to a list of accusations against fifteen specific entities, which is a higher bar. The detailed reasoning lives at the addendum. A future post that names a specific organisation will need to clear the higher bar at section 4 below.
Source verification
Each breach precedent cited in the post is a primary source: the British Airways CSP precedent links to the ICO’s decision, the BEC fraud loss totals link to the FBI IC3 annual report, the session-recording precedent links to the Princeton academic paper. Where a primary source isn’t available, the precedent is dropped from the post rather than substituted with secondary commentary.
Conflicts disclosed in line
None of the fifteen sampled agencies has been a client of any service I run. None of their competitors has either. If that ever changed for a future post, the relationship would be disclosed at the head of that post.
3. The editorial test, in one paragraph
For each post that touches a real organisation, the test is the same: is the finding factually verifiable, is it something a reasonable reader needs at the point of decision, and is the wording proportionate to what was actually observed? When all three are yes, it gets published. When any one is no, it doesn’t.
The agencies post passed that test. Findings are direct counts from a public-internet scan; the audience makes decisions about who holds their passport copies; the wording sticks to configuration facts and avoids implying anything beyond what the scan actually shows. Where interpretation is offered — the closing line about what configuration habits in one area suggest about habits behind the login — it’s flagged as opinion, not reporting.
4. The bar for naming
A future post that names a specific organisation will need all four of these to be true at the same time:
- The finding is verifiable by a reader using the published method against the same target.
- The finding isn’t trivial — the same configuration has been the subject of regulator action against another organisation in a comparable role.
- The organisation has been contacted at least seven calendar days before publication and given a chance to respond, or has previously declined to respond to comparable contact.
- The post identifies the configuration, not a person inside the organisation.
Posts here don’t name individual employees in connection with a finding. The institution is the subject; the individual is not.
5. What doesn’t get published, ever
Independent of the post or the cause:
- Working exploit code or payloads targeted at a named organisation.
- Credentials, session tokens, API keys, or any secret material observed during a scan, even where the scan would have allowed retrieval.
- Personal data of customers, beyond what the organisation has chosen to publish itself.
- Internal documents, source from private repositories, or anything obtained through a route that wouldn’t meet the authorisation rule at /scope#authorisation.
- Information identifying a child, even where a child was incidentally captured by a finding.
- Material that would, in honest belief, prejudice an active investigation I’m on notice about.
6. If something needs correcting
If you represent an organisation referenced in a post and you think a finding is wrong, or if you’re a reader who’s spotted an error, email [email protected] with the URL, the specific claim you’d like considered, and the evidence you’d like me to look at.
I respond within one calendar month, usually faster. Corrections appear on the page itself, with a dated note at the top describing what changed and why. Where the disagreement is about interpretation rather than fact, your wording can be added inline if you’d like.
The window to write in runs from receipt of your message, not from when the post was published — an organisation that finds the post a year later isn’t time-barred. Your statutory rights are unaffected.
7. Errata, versioning
Factual corrections appear on the post itself, with a dated note at the top describing what changed and why. Substantive corrections are never made silently; earlier versions of any page are kept and available on request. The agencies post hasn’t been corrected since publication.
This page is versioned. Substantive changes update the version number and the date at the top. Posts published under earlier versions of this page remain governed by the standards in force at their publication date, except that the right to write in for a correction runs forward indefinitely.