Why Security Through Obscurity Always Fails

Security through obscurity

The oldest security strategy is: if no one knows how the system works, they cannot attack it. Keep the algorithm secret. Keep the audit trail private. Trust the institution because you cannot see inside it.

This strategy fails for a predictable reason: eventually, someone finds out. A disgruntled employee leaks the algorithm. A breach exposes the database. A whistleblower publishes the internal audit. At that point, every user who relied on obscurity for their security is exposed simultaneously.

More fundamentally, obscurity is not security for the user — it is security against the user. A system you cannot inspect is a system you cannot verify. You are trusting the institution's claim about its own behaviour. History provides no shortage of examples of what institutions do when their behaviour cannot be verified.

Security through verifiable history

This platform takes the opposite approach: the security model is public. The algorithm for computing IA scores is documented. The transaction history for every LTU is visible. The rules for dispute resolution are embedded in the contract you sign before anything happens.

When the model is public, attacks must contend with a community that can see them happening. A bad actor who tries to game their IA score by creating fake contracts creates a visible pattern. A disputed transaction has a full audit trail. A panel that votes dishonestly leaves a record that affects future IA calculations.

The decentralised database

The current implementation stores the immutable record on a server — which means it has a single point of failure. This is acknowledged openly. The design target is a distributed database using a model similar to BitTorrent:

• The data is split across many nodes
• Each node holds a fragment
• If nodes disappear, the data can be reconstructed from remaining fragments
• No single node can corrupt the record unilaterally

This is not the same as Bitcoin's proof-of-work model, which is wasteful, centralising, and immutable in the wrong direction. The target model uses cryptographic hashing to verify fragment integrity without requiring every node to hold a full copy or perform expensive computation.

Why immutability is the wrong goal

A truly immutable ledger sounds secure. In practice, it means:

• Fraudulent transactions cannot be corrected
• Stolen assets cannot be returned
• Errors cannot be fixed

This is the wet dream of criminals, not the architecture of a trustworthy system. The correct model is append-only with dispute resolution: transactions are recorded permanently, but their status can be updated by a verified dispute process. The history of the correction is also recorded. Nothing is deleted. Everything is auditable.