The RTEST experiment was a Python runtime that worked entirely client-side, in the browser, via WebAssembly (Pyodide) — no backend server involved at all. The idea was simple and, at the time, felt like a neat sandboxing exercise: gate the runtime behind a locally supplied key, and let the browser do all the work of deciding whether that key unlocks anything meaningful. An interesting idea that evolved into a more elaborate architecture than I expected.
I built the whole thing from scratch, without immediately realizing that the shape of what I'd made — an encrypted payload plus a key, decrypted and run entirely on the client, with the hosting side never seeing the plaintext — is also the standard architecture behind loader and dropper malware. That's not a coincidence of naming; it's a coincidence of goals. Anything that wants to hide its payload from static analysis or content moderation ends up with the same design, because "nobody but the key-holder can see what this does before it runs" is exactly the property such a mechanism needs. I arrived at the same shape honestly, from a sandboxing angle, and only later recognized the overlap. Whoever has the key unlocks the door — but only whoever made the key knows what's actually inside, and the moment you type the right key, you're trusting it blindly.
The actual flaw isn't who's running the code — it's that a "decrypt, then execute" pipeline with no validation step in between can't tell the difference between a wrong key producing garbage and a right key producing something malicious. Successful decryption isn't the same thing as trustworthy content, and treating it as the only gate for execution means the architecture has no way to ask "should this actually run?" at all.
That's the real lesson this project left me with. A security-conscious version of the same idea wouldn't execute decrypted output at all — it would treat it strictly as untrusted data, and if code execution is genuinely required, it would authenticate the payload (a signature check, not just "did decryption succeed") before anything runs. The live mechanism isn't part of this redesign — the value here isn't the mechanism itself, it's being able to point at exactly where the design goes wrong and why.
