It's still horrible, not in a (direct) security but in an interop sense: Now you have to embed an entire WASM engine, including proper sandboxing, just to render the font correctly. That's a huge increase of complexity and attack surface.
Normalizing the complexity doesn't make it go away.
Ideally, I'd like not to execute any kind of arbitrary code when doing something mundane as rendering a font. If that's not possible, then the code could be restricted to someting less than turing complete, e.g. formula evaluation (i.e. lambda calculus) without arbitrary recursion.
The problem is that even sandboxed code is unpredictable in terms of memory and runtime cost and can only be statically analyzed to a limited extent (halting problem and all).
Additionally, once it's there, people will bring in libraries, frameworks and sprawling dependency trees, which will further increase the computing cost and unpredictability of it.
That's why I care so much about WebAssembly (and other sandbox) features that can set a strict limit on the amount of memory and CPU that the executing code can access.
Exactly that! And speaking of quotas, nobody can explain, why Ethereum Virtual Machine-like quotas were not enforced in the standard.
Imagine that you download a .odt/docx/pdf form with embedded font in LibreOffice in 2025. You start to type some text... And font start to saturate FPU ports (i.e. div/sqrt) in specific pattern. Meanwhile some tab in browser measures CPU load or port saturation by doing some simple action, and capture every character you typed.
While neat in a "because we can" kind of sense, it really is maddening: Have we gone "compute-mad" and will end up needing a full-fledged VM to render ever-smaller subsets of UI or content until ... what?
What is the end game here?
It is kind of like a "fractal" attack surface, with increasing surface the "deeper" one looks into it. It is nightmarish from that perspective ...
