What gets published, and what does not

The thing worth wanting from a company is accountability: the ability to check whether it did what it said, without needing its cooperation to find out.

Disclosure is one route to accountability, and it is often assumed to be the only one. It is not. Accountability needs three things — commitments specific enough to be broken, a record of failures reported by the company itself, and behaviour observable over enough time to form a pattern. None of those requires publishing how a system is built.

This distinction matters because the two get conflated constantly. A company that publishes an architecture diagram and a vague values statement looks more open than one that publishes falsifiable refusals and no diagram. The second is far more accountable. The diagram cannot be broken; the refusals can.

Publishing certain operational detail does not inform the people it is supposed to protect. It informs the people working against them.

A worked example. Suppose a platform publishes the threshold at which a new account is flagged for review: more than twenty messages in the first hour. That number is now public. Every spam operation reads it once and rewrites its scripts to send nineteen. The threshold has not just been revealed — it has been permanently neutralised, and the only parties who changed behaviour are the abusive ones. Ordinary users never knew the number existed and are now measurably less protected.

The same reasoning applies to ranking weights, which become a manipulation guide; to infrastructure topology, which becomes a target list; and to unpatched vulnerabilities, which become an exploit window. In each case, the disclosure transfers capability to an attacker and gives the ordinary reader nothing they can act on.

There is a well-known rule in cryptography, Kerckhoffs's principle: a system should remain secure even if everything about its design is public, with only the key kept secret. It is correct, and Nicholic follows it. Cryptographic design that depends on nobody knowing how it works is broken design, and any encryption used here should be safe to describe openly.

That principle is routinely stretched into something it does not say. It is a claim about cryptographic algorithms, where the security rests entirely on a secret key and the design can be published without loss. It is not a claim about operational defence, where there is no key — where the "secret" is a threshold, a heuristic, or a signal, and publishing it removes the protection outright rather than relocating it.

Anti-abuse work has no equivalent of a key. That is the whole difference, and eliding it is how "security through obscurity is bad" gets used to argue for publishing a fraud-detection playbook.

Everything above is also exactly what a company would say if it wanted a principled-sounding reason to hide things.

Security through obscurity is a genuine anti-pattern. "Operational security" is a genuinely popular excuse for concealing incompetence, and the argument on this page could be lifted verbatim by a company using it in bad faith. Anyone reading this sceptically is reading it correctly.

What distinguishes the two is not the argument, which is available to anyone. It is whether the boundary is fixed in advance and whether the company reports its own failures. A posture drawn before there is anything to hide, published with the specific signs that would expose it as a cover story, is harder to abuse than one improvised when a difficult question arrives.

If something sits in Tier 3 that you think belongs in Tier 1 or 2, that is a reasonable argument to make, and the contact address is on the contact page. The tiers are a position, not a natural fact, and the case for moving something is worth hearing.