After watching part of the video, I believe the world would benefit from a weekly television program where you could tune in each week to watch something weird, brilliant and funny. This would be a great episode #1 for that television show.
Watching his videos is often very calming for me at the same time. Visually striking beauty in simple things, calm narration and pleasing music. I also recommend his Lazy channel.
This is honestly one of my favorite channels. It is one of those things where if one asks "why" the only answer that can be given is "because."
Just look at the 4 most recent videos. Maybe start with "Harder Drive: Hard drives we didn't want or need" where he tries to make hard drives out of things that shouldn't be hard drives. This includes: by pinging the entire internet, tetris, and Covid-19 tests. But in truth the absurdity is a deep dive into the nature of how data can be stored and encoded. I think it should encourage people to pursue knowledge for the sake of knowledge and how there are frequently deep insights into seemingly dumb questions, as long as you dig deep enough.
We do these things not because they are hard, but because they are harder drives!
On his website he has an acadamic paper about red i removal. Not red eye removal. Red i. As in he superimposes a big red Comic Sans letter `i` over an image and then tries different techniques to remove it again...
Very much inspired this earlier HackerNews post which put Tetris into a font, today we put an LLM and an inference engine into a font so you can chat with your font, or write stuff with your font without having to write stuff with your font.
This is cool, as far as a practical issue though (aside from the 280gb TTF file!) is that it makes it incompatible with all other fonts; if you copy and paste your "improved" text then it will no longer say what you thought it did. It just alters the presentation, not the content. I guess you would have to ocr to get the content as you see it.
I was wondering why this was never used for an simpler autocorrect, but i guess that's why.
Also perhaps someone more educated on LLMs could tell me; this wouldn't always be consistent right? Like "once upon a time _____" wouldn't always output the same thing, yes? If so even copying and pasting in your own system using the correct font could change the content.
> if you copy and paste your "improved" text then it will no longer say what you thought it did
It's not a bug, it's a feature - a DRM. Your content can now be consumed, but cannot be copied or modified - all without external tools, as long as you embed that TTF somehow.
Which kind of reminds me of a PDF invoices I got from my electricity provider. It looked and printed perfectly fine, but used weird codepoint mapping which resulted in complete garbage when trying to copy any text from it. Fun times, especially when pasting account number to a banking app.
This is while pretty much all software that extracts structured data from PDFs throws away the text and just OCRs the page. Too many tricks with layouts and fonts.
I'm always surprised how "generate PDF from Word" turns one word into 10 different print points, all with just a single letter.
Or even straight lines in a table. The straight lines from a table boundary get hacked into pieces. You'd think one line would be the ideal presentation for a line, but who are you to judge PDF?
Apple provides OCR through VisionKit ImageAnalyzer API – https://developer.apple.com/documentation/visionkit/imageana... – albeit that is only officially supported to call from Swift (although apparently you can expose it to Objective C if your write a "proxy Swift framework"–a custom Swift framework that wraps the original and adds @objc everywhere–I assume such a proxy framework could be autogenerated using reflection, but I'm not sure if anyone has written a tool that actually does that). There is also the older VNRecognizeTextRequest API which is supported by Objective C, but its OCR quality is inferior.
A very similar thing is also just built in to the screenshot tool, at least in Windows 11, easier for me to use since it's the same keybind as always to take a screenshot, then it's just a tool in it.
While cool, technically… From a security perspective today I learned that TrueType fonts have arbitrary code execution as a ‘feature’ which seems mostly horrific.
(Sadly) this is nothing new. Years ago I wrangled a (modified) bug in the font rendering of Firefox [1, 2016] into an exploit (for a research paper). Short version: the Graphite2 font rendering engine in FF had/has? a stack machine that can be used to execute simple programs during font rendering. It sounded insane to me back then, but I dug into it a bit. Turns out while rendering Roman based scripts is relatively straightforward [2], there are scripts that need heavy use of ligatures etc. to reproduce correctly [3]. Using a basic scripting (heh) engine for that does make some sense.
Whether this is good or bad, I have no opinion on. It is "just" another layer of complexity and attack surface at this point. We have programmable shaders, rowhammer, speculative execution bugs, data timing side channels, kernel level BPF scripting, prompt injection and much more. Throwing WASM based font rendering into the mix is just balancing more on top of the pile. After some years in the IT security area, I think there are so many easier ways to compromise systems than these arcane approaches. Grab the data you need from a public AWS bucket or social engineer your access, far easier and cheaper.
For what it's worth, I think embedded WASM is a better idea than rolling your own eco systems for scripting capabilities.
If you think that's bad, until very recently, Windows used to parse ttf directly in the kernel, meaning that a target could look at a webpage, or read an email, and be executing arbitrary code in ring0.
Last I checked there were about 4-10 TTF bugs discovered and actively exploited per year. I think I heard those stats in 2018 or so. This has been a well known and very commonly exploited attack vector for at least 20 years.
I'm pretty sure it can't. There's nothing in a WAV file that's meant to be executed. A quick google turns up a DirectX vulnerability from 2007 (a validation error that's not inherent to the WAV format per se), and a recent case of WAV files being used to conceal malicious payloads (but coupled with a loader).
Having said that, the "arbitrary code" found in TrueType is not really arbitrary either - it's not supposed to be able to do anything except change the appearance of the font. From a security standpoint, there's no theoretical difference between a WAV and a TTF font - neither can hurt your machine if the loader is bug-free. Practically speaking though, a font renderer that needs to implement a sort of virtual machine is more complex, and therefore more likely to have exploitable bugs, than a WAV renderer that simply needs to swap a few bytes around and shove them at a DAC.
No, TTF is fully turning complete. Maybe I should have specified that in the original post. WAV is just "vibrate speaker this way" over and over again.
I realize this, but the fact that the format is "Turing complete" doesn't actually have any direct bearing on whether it's exploitable. Because the input to a TTF engine is not actually x86 machine code, it's misleading to frame it as "arbitrary code in ring0". It's not arbitrary - it can't do anything unless the TTF engine has bugs. And any format loader can have exploitable bugs, not just Turing complete ones.
Security wise, Turing completeness doesn't matter[note]. All that really matters is that the implementation of the format is complex. H264 is not Turing complete, but it is complex, and thus a frequent source of vulnerabilities. Conversely you could probably put a toy Brainfuck interpreter in ring0 and, with moderate care, be confident that no malicious Brainfuck code can take over your system.
[note] It matters a little bit if you consider it a "security" problem that you lose any guarantees of how long a file might take to load. A malicious file could infinite loop, and thus deny service. But then again, this isn't restricted to Turing complete formats - a zip bomb can also deny service this way.
It's technically not arbitrary. There is a stack, of sorts, but IIRC it has a depth of six or so, by default. You can do cool stuff with font shaping, but you can't easily execute arbitrary code.
Certain design tools type sites like Canva or Pitch allow you to upload fonts and obviously control the content. They are frequently used by phishers to make official looking phishing pages on a trusted source, leading to a cat and mouse game where the companies try to catch phishing like indicators in the content and flag them up for human review or block immediately.
In that case being able to show arbitrary other text would definitely be a hindrance because the scanning software typically looks at the data stored in the database. However I think you don't need a Turing machine to exploit this — you could have a single ligature in a well crafted font produce a full paragraph of text.
Perhaps there's an alternative vector where someone's premade font on a site that doesn't allow font uploading can be exploited to make arbitrary calculations given certain character strings. Maybe bitcoin mining, if you could find a way to phone home with the result
If you can trick someone into installing the font, you can now control what they read. Unfortunately a lot of hacks involve the user doing something dumb and avoidable.
If this font format is successful, then given enough time, it will become legacy. People won't be as vigilant about it, and they won't understand the internals as well. This is why TIFF-based exploits became so common 20-30 years after TIFF's heyday.
> Not really, no more so than a random webpage running js/WASM in a sandbox.
... except that it can happen in non-browser contexts.
Even for browsers, it took 20+ years to arrive at a combination of ugly hacks and standard practices where developers who make no mistakes in following a million arcane rules can mostly avoid the massive day-one security problems caused by JavaScript (and its interaction with other misfeatures like cookies and various cross-site nonsense). During all of which time the "Web platform" types were beavering away giving it more access to more things.
The Worldwide Web technology stack is a pile of ill-thought-out disasters (or, for early, core architectural decisions, not-thought-out-at-all disasters), all vaguely contained with horrendous hackery. This adds to the pile.
> The only output from the WASM is to draw to screen.
Which can be used to deceive the user in all kinds of well-understood ways.
> There is no chance of a RCE, or data exfiltration.
Assuming there are no bugs in the giant mass of code that a font can now exercise.
I used to write software security standards for a living. Finding out that you could embed WASM in fonts would have created maybe two weeks of work for me, figuring out the implications and deciding what, if anything, could be done about them. Based on, I don't know, a hundred similar cases, I believe I probably would have found some practical issues. I might or might not have been able to come up with any protections that the people writing code downstream of me could (a) understand and (b) feasibly implement.
Assuming I'd found any requirements-worthy response, it probably would have meant much, much more work than that for the people who at least theoretically had to implement it, and for the people who had to check their compliance. At one company.
So somebody can make their kerning pretty in some obscure corner case.
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 ...
I’m open to your idea, but can you explain in technical terms why a wasm sandbox is invulnerable to the possibility of escape vulnerabilities when other flavors of sandboxes have not been?
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
Has there already been a proposal to add scripting functionality to Unicode itself? Seems to me we're not very far from that anymore...
Considering the actual complexity of rendering e.g. Urdu in decent, native-looking way you presumably do want some Turing-complete capabilities at least in some cases, cf "One handwritten Urdu newspaper, The Musalman, is still published daily in Chennai.[232] InPage, a widely used desktop publishing tool for Urdu, has over 20,000 ligatures in its Nastaʿliq computer fonts." (https://en.wikipedia.org/wiki/Urdu#Writing_system)
Edit—the OP uses this exact use case, Urdu typesetting, to justify WASM in Harfbuzz (video around 6:00); seems like Urdu has really become the posterchild for typographic complexity these days
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
In that case could you ship a live demo of this that's a web page with the font embedded in the page as a web font, such that Chrome and Firefox users can try it out without installing anything else?
> Usage: Just download llama.ttf (60 MB download, since it's based on the 15M parameter TinyStories-based model demoed above) and use it like you would any other font.
>build Harfbuzz with -Dwasm=enabled and build wasm-micro-runtime, then add the resulting shared libraries, libharfbuzz.so.0.60811.0 and libiwasm.so to the LD_PRELOAD environment variable before running a Harfbuzz-based application such as gedit or GIMP
It'd be lovely if someone embedded the font in a website form to save us all the trouble of demoing it
It would not be of much use as no browser enables this experimental feature. So unless you somehow build a wasm build of Harfbuzz with the feature enabled and embed it on there nothing will happen.
According to demo, this feature has no opt-in, so if Android/iOS/any Linux distro ships with "better fonts feature for LibreOffice" it will be enabled in every text editor/browser/electron app, up to systemd blue screen of death.
Are there _any_ generally available consumer applications (document viewers, printers, obscure browsers, ...) that use a TTF font renderer with the WASM feature enabled?
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
Oh, this can't be used for nefarious purposes. What could POSSIBLY go wrong?!
WASM sandboxing is pretty good! Together with the presumably very limited API with which this can communicate with the outside world, I wouldn't be too concerned.
To me, it's a great reminder that the line between well-sandboxed turing-complete execution environments and messy implementations of decoders for "purely declarative" data formats can be quite blurry.
Said differently, I'd probably trust Harfbuzz/WASM more than the average obscure codec implementation in ffmpeg.
Fuzzing is good, robust sandboxing is better, I'd argue. There's just a much smaller surface area to cover for the latter.
> Is there scientific proof of above claim such as "WASM sandboxing is pretty good!" ?
I'm not aware of quantitative studies, but just from a design perspective, the surface that a WASM runtime presents seems intrinsically easier to defend than that of, say, the full Unix userspace that ffmpeg instances usually run in.
Anecdotally, many high-profile iOS and Android vulnerabilities originated in some more or less obscure codec implementation.
TrueType fonts have had a Turing complete virtual machine (almost?) since the beginning. It is used for "hinting" to allow partially colored pixels at low resolutions to remain legible. It's basically a program that decides whether to color a pixel or not to allow fine tuning of low resolution rasterization.
This isn't used as much today with modern large resolutions where we can get decent image quality from just rasterizing the font outline with anti aliasing.
This example, however, is using wasm embedded to ttf fonts which is not the same as ttf hinting byte code.
> TrueType fonts have had a Turing complete virtual machine (almost?) since the beginning. It is used for "hinting" to allow partially colored pixels at low resolutions to remain legible. It's basically a program that decides whether to color a pixel or not to allow fine tuning of low resolution rasterization.
That sounds like an awful idea, too. I think a font file should describe the fonts form, but it should not describe how it is gonna be rendered. That should be up to the render engine of the device that is going to display the font (printer driver, monitor driver...). But I guess this idea is from a time when people were still using bitmap fonts.
You need to remember that when TrueType fonts were introduced, a typical display resolution was 640x480 to 800x600 on a 13-15" display.
If you rasterize the Bezier curve outline of a ttf font at that resolution, you will have very crooked characters without anti aliasing and very blurry with AA.
At the same time the same font files needed to look good on print paper with a very different DPI setting.
It's a compromise between bitmap and outline fonts. Not ideal but it delivered good results on display and on paper at the time.
The hinting engine is not (?) used that much any more with large resolutions where we can comfortably just rasterize the outline with some AA and have good results.
Apparently the font can only embed WASM, which is sandboxed so it can't do anything except turning a buffer of codepoints into glyphs and positioning them.
Of course, back in the 1990s Java and Flash were supposed to be sandboxed. So who knows?
Yes, that's the general consensus in the comments. It doesn't even sound safe to me and I'm not a full security pro. But OP did it as a PoC/for fun. It's okay to have fun still.
I believe your point was "it's ok for OP to have fun with this project even if it's unsafe", but no one's saying that OP shouldn't have done this, since it's not what they've done that's unsafe. But if that wasn't your point, then OK, yeah.
Can someone explain why HarfBuzz isn't a potentially serious security vulnerability? Couldn't someone create a .ttf file that looks like one of the standard .ttf files but includes similar capability to this llama.ttf to execute arbitrary code?
PostScript is Turing complete and your PDF reader is a PostScript interpreter. So, yeah, potentially any PDF is instructions to a general-purpose computer.
Older versions of PDF files and readers don't know or care about what happened later. PDFs also did shady shit like being able to embed JavaScript actions and other files. They also became Turing complete when they adopted Type 4 functions in PDF 1.3 that still aren't deprecated in 2.0.
LaTeX subsumed most of the human authoring uses of PS where it was used in academia.
PostScript files are dynamic code. You can create polygons dynamically with commands. And, of course, font FX's, styles, elipses...
Also, there's a ZMachine interpreter (text adventure player) written in PostScript which can play Zork and some libre games such as Calypso with just GhostScript, the PostScript interpreter most software use to render PostScript files.
The author categorizes this as "pointless" but some things I can think of is being able to create automated workflows within an app that didn't previously allow it or had limited scope and then creating app interoperability with other app's using the same method.
This is really cool, but I'm left with a lot of questions. Why does the font always generate the same string to replace the exclamation points as he moves from gedit to gimp? Shouldn't the LLM be creating a new "inference"?
As an aside, I originally thought this was going to generate a new font "style" that matched the text. So for example, "once upon a time" would look like a storybook style font or if you wrote something computer science-related, it would look like a tech manual font. I wonder if that's possible.
So, another poster cleared up my first question. It's probably because the seed is the same. I think it would have been a better demo if it hadn't been, though.
You got it, same seed in practice, but also just temperature = 0 for the demo actually. A few things I considered adding for the fun of it were 1) a way to specify a seed in the input text, 2) a way to using a symbol to say "I didn't like that token, try to generate another one", so you could do, say, "!" to generate tokens, "?" to replace the last generated token. So you would end up typing things like
"Once upon a time!!!!!!!!!!!!!!!!!!!!!!!!!!!!!SEED42!!!!!??!!!??!"
and 3) actually just allow you to override the suggestions by typing what letters on your own, to be used in future inferences. At that point it'd be a fairly generic auto-complete kind of thing.
Using the input characters to affect the token selection would increase the ‘magic’ a little.
As it is, if you go back into a string of !!!!!!!!!! That has been turned into ‘upon a time’, and try to delete the ‘a’, you’ll just be deleting an ! And the string will turn into ‘once upon a tim’.
If you could just keyboard mash to pass entropy to the token sampler, deleting a specific character would alter the generation from that point onwards.
I fail to understand how an LLM could produce two different responses from the same seed. Same seed implies all random numbers generated will be the same. So where is the source of nondeterminism?
Barring subtle incompatibilities in underlying implementations on different environments, it does, assuming all other generation settings (temperature, etc.) are held constant.
Wow, this is incredible. OP you (I?) should train a few models with different personalities/tasks and pair them with the 5 GitHub Monaspace fonts accordingly, allowing people in multifont programs to easily get different kinds of help in different situations. Lots of little ideas sparked by this… in general, I think this a good reminder that we are vastly underestimating fonts in discussions of UI (and, it appears, UX in full!)
It seems like it'd be possible to, instead of typing multiple exclamation points, have one trigger-character (eg. ). And then replace that character visually with an entire paragraph of text, assuming there aren't limits to the width of a character in fonts. I suppose the cursor and text wrapping would go wonky, though.
You could also use this to make animated fonts. An excuse to hook up a diffusion model next?
I may be doing this wrong but...the font provided just install as OpenSans and does not provide any functionality at least in mousepad or LibreOffice Writer. I am talking about the 90mb one
Yeah, sorry, that could have been clearer, I added a few more instructions. Basically, chances are that even if you've got Harfbuzz running, you're still running a version with no Wasm runtime. If so, chances are you can get away with building it with Wasm support, then add the built library to LD_PRELOAD before running the editor.
That was useful. I have indeed compiled and installed wasm-micro and now meson build it successfully. Tho "meson compile -C build" returns an error about not finding "hb-wasm-api-list.hh". Do you have any experience of that?
EDIT: Nevermind. Using the exact commits you linked give another error (undefined reference to wasm_externref_ref2obj). I give up
Since it only alters the presentation of the text, not the text/data itself, maybe using a type of image-to-text tool like this could work: https://www.imagetotext.info/
The critical part is knowing that TTF fonts can include a virtual machine.. then he pops an llm into that and replaces instances of !!!!!! with whatever the llm outputs.
Not exactly. Harfbuzz, the font shaping library, has an optional feature to use WASM for shaping. Normal font hinting is much more restricted, precisely because Turing-complete fonts are a horrible idea.
reply