When to Withhold: Why Total Transparency Isn’t Always the Responsible Default

Transparency is a reflex of good research, and rightly so. We want our methods inspectable, our claims falsifiable, our limits stated out loud. A vendor who hides how their numbers are produced has usually earned your suspicion. So the instinct to “just make it all open” feels like the principled choice.

But there is a kind of openness that is not principle at all — it is leakage. When the openness in question is your client’s confidential stimulus sitting in readable form on a stranger’s phone, or the proprietary logic of a test exposed as source on a device you will never see again, “transparent” stops meaning “honest” and starts meaning “undefended.” The responsible default is to separate the two, because conflating them quietly costs the people who trusted you with their material.

It helps to split openness into two things that get bundled together. The first is openness about method and limits: what you measured, how, what the design can and cannot tell you, and where the protections stop. This kind you should maximise. It is what lets a buyer evaluate your work on its merits instead of taking marketing on faith.

The second is exposure of implementation and assets: the test logic, the proprietary algorithms, the confidential stimuli, the raw collected data. This kind is not a virtue to maximise — it is a risk to manage. On hardware you do not control, in browsers anyone can open and read, exposure of implementation is simply a gift to whoever wants to copy your client’s material or reverse your method. The best practice is to be loud about the first and deliberate about the second.

Online testing makes the tension concrete. To run a test you must put a stimulus on a respondent’s screen and read their reactions in real time — both have to be in the clear at the instant they are used. A great deal of the market ships that entire experience as readable client-side code, where the logic is its own source and the data sits in browsable objects. Convenient to build; also, by construction, exposed on the devices you least control.

The responsible alternative is to move the engine, the timing, and the data into a compiled core that is not shipped as readable source and does not leave assets lying around in inspectable form. Stimuli are decrypted only at the moment of display and zeroed immediately after; collected data is sealed as it is recorded; nothing reusable is left on the machine when the session ends. That is opacity chosen deliberately, in exactly the place where exposure would do harm — and it is entirely compatible with being completely transparent about the method itself.

Choosing opacity does not excuse you from honesty — it raises the bar. The practice that separates a defensible position from a marketing claim is this: state the floor. Tell people precisely what is protected, what is not, and why. A security story that hides its own limit is not a security story.

In the display example, the honest floor is screen capture: anything a person can see on their screen, they can photograph, and no web application can reliably prevent operating-system-level recording. Saying so out loud is not weakness — it is what lets a client’s own security team assess your protections on the merits. Opacity of implementation, transparency of limits: that pairing is the whole discipline.

Before you expose something “for transparency,” ask one question: does this openness help someone evaluate my work, or does it help someone copy my client’s material or defeat my method? If it is the former, lean open. If it is the latter, lean protected — and document the trade so it can be reviewed rather than assumed.

Total transparency is not the responsible default. Honest transparency about method and limits, paired with deliberate, stated protection of assets and logic, is. The goal is not to hide — it is to make sure the only things in the clear are the things that have to be.