The Passcode Test: How We Design Every Feature

The Question

Every feature we build must answer one question: “A suspicious partner unlocks your phone and opens sTELgano. What do they see?”

The answer must always be the same: a blank entry screen with two fields. Nothing else.

This is the Passcode Test. It is the single most important design constraint in the entire application. Every feature, every interaction, every pixel on the screen is evaluated against this question before it ships.

Why This Matters

In our threat model, the attacker has physical access to your unlocked device. They can open any app, read any notification, scroll through any history. This is not a hypothetical scenario — it is the most common real-world privacy threat for many people.

Traditional encrypted messengers fail this test completely. Encryption protects the wire, but it does nothing to protect the screen. If someone is standing behind you — or has your phone in their hand — all the end-to-end encryption in the world is meaningless.

How Other Apps Fail

Signal shows a contact list. WhatsApp shows recent chats. Telegram shows a message list. Even with disappearing messages enabled, even with app locks in place — the existence of conversations is visible.

The mere presence of a chat thread tells an attacker that you are communicating with someone. The contact name, the timestamp, the unread count — all of this is metadata that survives encryption. These apps protect the content but betray the context.

How sTELgano Passes

sTELgano shows nothing. No contact list. No chat history. No recent conversations. No notification badges. No “last seen” status.

When someone opens the app, they see exactly two empty fields: a number and a PIN. Without knowing both the correct steg number and the correct PIN, there is no way to determine whether the app has ever been used, who you have spoken to, or what was said.

Even the name is deliberate. “sTELgano” is intentionally meaningless to anyone who isn’t looking for it. If a suspicious partner sees it in your browser history or on your home screen, it reads like any forgettable utility app — not a messaging tool. A name like “SecretChat” or “HiddenMessages” would fail the Passcode Test before the app even opens. The brand itself is steganographic.

The app looks identical whether you have an active channel or have never used it before. That is the point.

Design Decisions That Follow

No Push Notifications

Nothing to see on the lock screen. No badges, no banners, no sounds. The absence of notifications is a privacy feature.

Browser-Only, No Install

sTELgano is a web page, not an installable app. Nothing appears in the launcher or home screen — it lives only in the browser, for the one tab you opened.

SessionStorage Only

Closed tab means gone. No localStorage, no cookies persisting session data. Closing the browser tab erases everything.

Panic Route

Navigate to /x for instant clearing. No confirmation dialog, no animation. Immediate session destruction.

The Blank Screen Is the Feature

The most important UX decision we made was what NOT to show.

Most apps compete on features: more buttons, more screens, more things to do. sTELgano competes on absence. The fewer elements on the screen, the less an attacker can learn. The blank entry screen is not a limitation of the design — it is the design.

Every feature request is evaluated against the Passcode Test. If it adds visible state, it fails. If it reveals that a conversation exists, it fails. If it gives an attacker any information at all, it fails. The blank screen is the feature.