Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

171–180 of 230 posts

Re: Memory safety for web fonts

#171

Post by plorkyeran »

hgs3 wrote: post #69
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

Is the FreeType2 test suite public? It looks like the project's tests/ directory only contains a script for downloading a single font [1]. They have a fuzz test repo with what appears to be a corpus of only a few hundred tests [2]. For critical infrastructure, like FreeType, I'd expect hundreds of thousands if not millions of tests, just like SQLite [3]. [1] https://gitlab.freedesktop.org/freetype/freetype/ [2] https…

I don’t know if this applies to freetype’s testing, but when I worked on software that operated on fonts in the past I quickly concluded that piracy was the only practical way to test it. You need a very large corpus of real fonts, which would be both very expensive and not redistributable. This meant that I did not open source my tests.

Re: Memory safety for web fonts

#172

Post by xyst »

sidcool wrote: post #108

This is a wonderful write up. Reminiscent of the old google

G engineering write ups are usually well written with plenty of useful information to carry forward.

It’s G’s _business_ folks (ie, C-level executives) that I have no respect for. Their business model of exploiting users is just awful.

Re: Memory safety for web fonts

#173

Post by maxdamantus »

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully.

Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted).

In case anyone's wondering what properly hinted text looks like, here's a screenshot [2]. This currently relies on setting the environment variable `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, possibly some other configuration through fontconfig, and using a font with good hinting instructions (eg, DejaVu Sans and DejaVu Sans Mono in the screenshot).

My suspicion is that Windows moved away from font hinting after XP because it's very hard to create fonts with good sets of hinting instructions (aiui, OTF effectively only allows something like "autohinting"), so in the modern world of designer fonts it's easier to just have everyone look at blurry text. Some other minor reasons would be that UI scaling in Windows sometimes (or always?) introduces blurring anyway, and viewing raster images on screens of varying resolutions also introduces scaling blur.

[0] Windows still has a way to enable it, but it disables antialiasing at the same time. This is using an option called "Smooth edges of screen fonts" in "Performance Options"). This basically makes it look like XP, which imo is an improvement, but not as good as FreeType which can do hinting and antialiasing at the same time.

[1] https://freetype.org/freetype2/docs/hinting/subpixel-hinting...

[2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

Re: Memory safety for web fonts

#174

Post by grishka »

da_chicken wrote: post #153
grishka wrote: post #127

Earlier quoted context omitted.

> It's not a configuration they sell So what is the "configuration they sell" for the desktop Macs? The Studio Display that costs way too much for what it is, so to no one's surprise, they're not selling all that many of those? Or the Pro Display XDR for which the stand alone costs more than an entry-level Mac Mini? Sure no one will buy a $1600 monitor to use with their $600 Mac Mini. They'll get a much cheaper third…

Apple put all their chips behind Retina/HiDPI displays. To that end, they've got really good HiDPI resolution scaling, they no longer sell displays incapable of Retina features (in laptops or stand-alone), and they have removed features that only serve to support sub-4k displays. To Apple, 4k is the minimum standard. If you want a 2k monitor you can buy one and hook it up, but Apple isn't interested in making it look…

Well, in my particular case, I use an M1 Max MBP with a 2K monitor that I already had when I bought the MacBook.

The problem with 27" 4K monitors is that you can't have integer scaling on them. If you set the scaling factor to 1x, everything will be too small, if you set it to 2x, everything will be huge, and macOS can't properly do fractional scaling because what it actually does is render everything into a 2x framebuffer and downscale that for output.

And besides, only supporting HiDPI displays doesn't mean one can stop striving for pixel perfection. I hate SF Symbols icons because they're sizeless. They're an abhorrent blurry mess on my monitor but they're also not all that sharp on the MacBook screen. If you notice it once, it'll haunt you forever. Sorry. They do look fine-ish on iPhones though because those use OLED displays that lack the notion of a pixel grid anyway.

Re: Memory safety for web fonts

#175

Post by izacus »

interroboink wrote: post #167
izacus wrote: post #154

Earlier quoted context omitted.

How is that related to the tradeoff calculation at hand? Implementing VP9, enabling it, transcoding videos and testing it COST SWE hours, it didn't save them. It also cost resources. In what way did you envision the VP9 issue being related to SWE/resource hour computations here?

I think what they're suggesting is that yes, Google spent some SWE hours to implement it, but they have (or will, over time) saved more than that in equivalent compute (by pushing it onto users). So, from Google's point of view, they saved SWE hours on the company balance sheet, so it's a win. But from the larger point of view of "everyone," this actually made the total cost worse. The cost/benefit analysis from Goog…

I'm don't think that metric applies here - "SWE years" is when you want for determine whether investing in certain optimisation is worth doing.

In case of VP9, there was no such tradeoff - it used more storage, more CPU time and age SWE hours. What it saved was a very clearly quantifiable financial cost of bandwidth and SWE hour tradeoff didn't have much to do with it.

It would be applicable if the debate would be investing engineering time to speed up VP9 encoder for example.

Re: Memory safety for web fonts

#176

Post by TheRealPomax »

TheRealPomax wrote: post #133
Ono-Sendai wrote: post #116

Earlier quoted context omitted.

I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...

I know how to read, and that MR comment sounds 100% reasonable to me. Normally you'd take a comment like that, go "oh, okay let me do some more investigations" and start a dialog instead of going "they rejected my MR on the first pass, they don't know what they're doing and their library is antiquated". Where's the follow-up, or did you just walk away?

Because to be a clear: a reviewer comment is the start of the conversation, if you don't respond then the bad actor is you, not them. Ask them why they don't want to use math.h, ask them if there are dev documents that explain what can and can't be used, and why. If you don't, this failure is on you, not them.

Re: Memory safety for web fonts

#177

Post by jstimpfle »

rs186 wrote: post #100
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

That perspective was never correct to begin with. Along with laughable comments I have seen like "memory safety is easy. Memory related bugs are created by bad programmers". See comments under this video: https://youtu.be/gG4BJ23BFBE We are all humans, and humans make mistakes. The obvious way to avoid mistakes is to formalize "correct code" and get code chekced by machines, and in this context, let the compiler guar…

Only "obvious" if the things you are doing match simple ownership patterns for example. If you want to do performance-oriented things: for example compressing the size of certain data structures, shaving off a few pointers/integers of or even compress them in some way. Or applying various concurrency patterns, or otherwise speed up the code...

... then it's not all obvious anymore. In these situations you'd rather drop down to assembly than go up to sth like Rust.

I'm currently doing my 2nd take on a userspace allocator (fixed-size pages but of different sizes, running 32-bit too) as well probably my 8th take or so on a GUI toolkit. I've experimented with lots of approaches, but it always seems to come back to removing abstractions, because those seem to kill my work output. A big reason is they blow up code size and make code (by and large) less understandable, as well as harder to change because of the sheer size.

Not necessarily saying that approach doesn't lead to more potential security issues. I mostly just turn up warnings, not doing fuzzing etc. But it seems to be a more pragmatic way for me to achieve functioning (and robust-in-practice) software at all.

Re: Memory safety for web fonts

#178

Post by h3half »

declan_roberts wrote: post #8

> Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers I like this way of measuring extra work. Is this standard at Google?

This is also extremely extremely common in engineering services contracts, both for government and private sector contracting. RFPs (or their equivalent) will specifically lay out what level of effort is expected and will often denote effort in terms of FTE

Re: Memory safety for web fonts

#179

Post by nyanpasu64 »

maxdamantus wrote: post #173

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properl…

> In addition, before the integration into Chromium, we ran a wide set of pixel comparisons in Skia, comparing FreeType rendering to Skrifa and Skia rendering to ensure the pixel differences are absolutely minimal, in all required rendering modes (across different antialiasing and hinting modes).

I'm hoping (but not sure) Skrifa will support hinting (though I'm not sure how it interacts with fontconfig). I noticed your screenshot uses full hinting (a subjective choice I currently don't use on my machines), presumably with integer glyph positioning/advance which isn't scale-independent (neither is Windows GDI), though this is quite a nonstandard configuration IMO.

Re: Memory safety for web fonts

#180

Post by bawolff »

AndriyKunitsyn wrote: post #165

So, there's Skia. Skia is a high-level library that converts texts to glyph indices, does high-level text layout, and caches glyphs (and it also makes GPU calls). But the actual parsing of the font file and converting glyphs to bitmaps happens below in FreeType. Skia is made in C++. It's made by Google. There's FreeType. It actually measures and renders glyphs, simultaneously supporting various antialiasing modes, hi…

Format parsing is generally considered some of the most risky type of code to have for memory safety. Skia is probably considered a less risky problem domain.
Post reply on HN