tl;dr: It is a fall-back font of which every glyph is zero width. It can be, for example, used as a substitute font while the actual web font loads; the text width of zero indicates that the web font is yet to be loaded.
You're not using an actual image, just an image object. Set the src attribute of the image object to the URL of the webfont and the browser will call the onerror callback when it finishes loading.
Just because a font has "loaded" does not mean it's ready to be used. This very problem makes it hard to load @font-face fonts on demand in <canvas> apps as there is a certain amount of time you must wait for the font to actually load that is not exposed or accounted for in any browser APIs. Even if you include a font in @font-face with a data: URI, you cannot immediately start using it.
Saw the title and thought it was an early April fools. Got ready to comment how knowing adobe even an app showing just a blank screen would be full of tons of security vulnerabilities and need biweekly updates.
That was my first thought to but skimmed it and sounded like there might be some uses for it. Then reached the link at the bottom "this font was built using only AFDKO tools" and immediately thought that AFD stood for "April Fools Day", I had been fooled, and clicking the liked would just be a page explaining the joke. I couldn't figure out what the KO could stand for though so I clicked and turned out the abbreviation was just for "Adobe Font Development Kit for OpenType".
I'm interested in the technique suggested for font loading. As an exercise I just created a font containing a single character at zero width. The resulting file size is considerably smaller than Blank (1440 bytes, versus 80k) which makes it nicer to inline, but should be able to serve the same purpose for font loading:
Create a span containing the character, with the font family referring to the font being loaded and the empty font (inlined in the css) and when the width is non-zero the font is loaded.
and periodically check that the width of a line of nonsense text for both classes is not the same. Blank has the obvious benefit that it will be obvious when 0 != something else, but you can do it if you have some reasonable expectation that some other common font will exist with different metrics than your fancy font.
interesting to see the process behind the font, though.
As you say, if you know that the font you're loading has different metrics this approach will work, but if you have to make that sort of assumption it's not a generalised approach.
If you know that one font has zero width dimensions and one does not, then it greatly simplifies matters.
There's an interesting issue with invisible fonts that hasn't been pointed out in the comments thus far.
In a job interview last year, I was asked to name some ways to hide an element on a page. I think I came up with seven or eight ways and listed upsides and downsides of each.
Besides obvious ones like opacity, visibility, display: none, z-index, moving the elements off-screen, setting font-size to 0, etc., one idea I came up with on the spot was to design a font with blank characters in case the div was simply text. The text would be visible to search engines but not to users.
(Since I was interviewing at a large search company, I also raised the point that they might want to start analyzing custom fonts to make sure they're not simply empty characters, if they're not already.)
lol DDoS by Hackers News is a common curse for small websites. But "Error establishing a database connection" for only 16 points on Hackers News is a shame for Adobe.