Re:Proving the Turing Completeness of Fonts
by mLuby on Monday March 11, 2019 @07:40PM
(#19363994)
>But even in HarfBuzz and CoreText, there are hard limits on the recursion depth. HarfBuzz sets its limit to 6. Therefore, the above example will only work on strings of length 7 or fewer. HarfBuzz is open source, though, so I simply used a custom build of HarfBuzz which bumps up this limit to 4 billion. This let me recurse to my heart’s content. A limit of 6 is probably a good thing; I don’t think users generally expect their text engines to be running arbitrary computation during layout.
Re:Proving the Turing Completeness of Fonts
by pcwalton on Monday March 11, 2019 @07:09PM
(#19363780)
GSUB handling is done by a library called a text shaper. Examples of libraries that do shaping include the cross-platform HarfBuzz, Windows DirectWrite, and macOS Core Graphics/Core Text.
Re:Proving the Turing Completeness of Fonts
by benj111 on Tuesday March 12, 2019 @03:03AM
(#19365980)
Thanks
So from what I understand these would be called from the UI libraries eg GTK in Linux land. I would assume window managers also, to deal with title bars.
I would further take from this that we shouldn't expect full Unicode support in virtual terminals (not emulators) in the future.....
Re:Proving the Turing Completeness of Fonts
by XaspR8d on Monday March 11, 2019 @06:03PM
(#19363313)
It's not arbitrary code execution, just a toy observation about the specification. Additionally, 1) as noted, none of the font rendering libraries used were capable of recursion without the author's modifications, 2) in a web context, Javascript is unable to access information about actual glyphs rendered or other "font-internal" calculations.
If anything, exposing glyph data to the web API would be a bigger problem for fingerprinting, and probably expose some sort of user browsing history snooping flaw...
Re:Proving the Turing Completeness of Fonts
by yorwba on Monday March 11, 2019 @07:02PM
(#19363727)
> Javascript is unable to access information about actual glyphs rendered or other "font-internal" calculations.
Just render the text to a canvas and read out the pixel data to see the glyphs, a.k.a. canvas fingerprinting. I'm not sure whether getting clever with the font would reveal any information you can't get more easily, though.
Re:Proving the Turing Completeness of Fonts
by kccqzy on Wednesday March 13, 2019 @10:57PM
(#19386170)
I think this is extremely interesting. Not to dismiss the author's work, but merely performing addition is far from Turing complete. Addition is primitive recursive, a much smaller class of functions than say, generally recursive. Although in this case I have no reason to doubt that GSUB isn't Turing complete, because recursive symbol substitution is powerful enough.
Truly, Zalgo waits just beyond the wall.
Could someone explain at what level this is happening. What classes of software/libraries are affected?
So from what I understand these would be called from the UI libraries eg GTK in Linux land. I would assume window managers also, to deal with title bars.
I would further take from this that we shouldn't expect full Unicode support in virtual terminals (not emulators) in the future.....
If anything, exposing glyph data to the web API would be a bigger problem for fingerprinting, and probably expose some sort of user browsing history snooping flaw...
Just render the text to a canvas and read out the pixel data to see the glyphs, a.k.a. canvas fingerprinting. I'm not sure whether getting clever with the font would reveal any information you can't get more easily, though.
https://www.toothycat.net/~hologram/Turing/HowItWorks.html
This can be generalized as: Pattern Matching = if statement.
I don't know nor can I prove that that's true under all circumstances, however...
But, an interesting article.