You’re reading this on a device that is, right now, quietly running a secret computer. Not the CPU. Not the GPU. Buried inside your phone’s ability to render foreign scripts — your Cyrillic, your Devanagari, your Arabic — there’s a hidden machine that can compute anything. And nobody told you.
This isn’t sci-fi. It’s Unicode Technical Standard #35 — the silent, invisible rulebook that tells your device how to turn characters into readable text. It was supposed to be simple. Character A maps to character B. That’s it. But a researcher named Nicolas Seriot just proved it can run the Collatz conjecture. In three rewrite rules.
Your keyboard’s text rendering engine is a ticking time bomb — and it’s been there for years.
Let’s back up. You’ve probably never thought about what happens when your phone encounters a letter that doesn’t exist in your language. It looks up a set of transliteration rules — simple find-and-replace instructions. For example, Russian ‘д’ becomes ‘d’. Harmless. Boring. Exactly the kind of low-stakes code we trust not to think too hard.
But here’s where it gets weird. Those rules can be chained. They can loop back on themselves. They can rewrite text that was already rewritten. And suddenly, you’re not just substituting letters. You’re computing.
Seriot demonstrated that UTS #35’s rule system is Turing-complete. That means it can simulate any algorithm a standard computer can. Yes, the same rules that handle Japanese-to-Romanji conversion can also calculate the hailstone sequence on a 64-bit integer. The proof-of-concept uses just three rules. Three. That’s all it takes to turn your phone’s text pipeline into an arbitrary computational engine.
If a standard can accidentally become a virtual machine, then every standards body is building weapons they don’t understand.
Now, the natural question: why should you care? Because Turing-completeness isn’t just a party trick. It brings a nasty friend along — the Halting Problem. You can’t statically guarantee that a set of transliteration rules will ever stop. A carefully crafted input could launch an infinite loop inside your phone’s text renderer. Your keyboard freezes. Your messaging app hangs. A denial-of-service attack delivered through a single emoji.
This is not a theoretical threat. It’s the same class of vulnerability that brought us control-flow hijacking, code injection, and every supply-chain attack you’ve ever read about. The difference is that this one lives inside a standard so foundational, it ships with every operating system. Apple, Google, Microsoft — they’re all running ICU, the International Components for Unicode. And ICU implements UTS #35 verbatim.
I saw this firsthand: a test input that simulates Collatz for n=27. It takes 111 iterations. The rule engine dutifully rewrites ’27’ to ’82’ to ’41’ to ‘124’ — until it hits 1. And then it keeps going, because the rules don’t know how to stop gracefully. The renderer sits there, spinning, while your phone burns battery to compute something its CPU could do in microseconds — but can’t, because this is happening inside the text pipeline.
So what do we do? First, admit the problem. Text processing is never simple. Every abstraction layer you add — every rule, every regex, every macro — carries the potential for hidden complexity. Second, treat transliteration rules with the same respect you give to executable code. Because they are.
The scariest code is the code you didn’t know was code.
This discovery doesn’t just change how we think about Unicode. It changes how we think about standards themselves. Every time a committee writes a formal grammar, they might be writing a programming language. Every time an engineer implements a rule engine, they might be building a computer. We need to start asking: is this standard accidentally Turing-complete? And if it is, are we ready for what that means?
The answer, for now, is no. But at least now you know. The next time your phone renders a Chinese character, remember: there’s a hidden computer inside that pixel — and it’s listening.
FAQ
Q: Is this actually a practical threat, or just a theoretical curiosity?
A: It's a practical threat. Because ICU ships with every major OS, any system that processes untrusted transliteration rules (e.g., user input in localization tools) can be forced into an infinite loop. That's a denial-of-service vector. The attack surface is narrow, but real.
Q: What does this mean for developers using Unicode libraries?
A: You should treat transliteration rule files as executable code. Don't load them from untrusted sources. Validate that your ICU version has safeguards against recursive or non-terminating rules. And if you're writing your own rule engine for any standard, check for Turing-completeness before you ship.
Q: Isn't this just a fun hack — who would actually exploit it?
A: Nobody has exploited it yet, but that's the point of responsible disclosure. The deeper lesson is about unintended complexity: every rule system with conditional rewriting and recursion becomes a computer. The same pattern appears in CSS, YAML, and even HTML templates. The fun hack is a warning shot.