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

131–140 of 230 posts

Re: Memory safety for web fonts

#131

Post by kiicia »

tadfisher wrote: post #94
kiicia wrote: post #46

Earlier quoted context omitted.

For me, being old time user, (ab)using any subpixel layouts for text rendering and antialiasing is counterproductive and (especially with current pixel densities, but also in general) introduces much more issues that it actually ever solved “Whole pixel/grayscale antialiasing” should be enough and then specialized display controller would handle the rest

Agreed, but layouts such as Pentile don't actually have all three subpixel components in a logical pixel, so you'll still get artifacts even with grayscale AA. You can compensate for this by masking those missing components. https://github.com/snowie2000/mactype/issues/932

surprising info, I thought this was supposed to be the part about "display controller taking care of any additional issues", thanks for link with details, will read it with interest

Re: Memory safety for web fonts

#132

Post by kiicia »

kevingadd wrote: post #48
kiicia wrote: post #41

Earlier quoted context omitted.

The real issue is the effort required to rewrite everything without introducing new bugs resulting from a misunderstanding of the original code

New (likely aesthetic only) bugs in font rendering are probably considered preferable to existing security vulnerabilities, I would hope.

it's hard to argue that "occasional accent rendering issue" is better than "occasional zero-click issue", but rewriting code of any actual complexity is hard in practice... and we are talking about only one library here, with thousands libraries and utils to go

Re: Memory safety for web fonts

#133

Post by TheRealPomax »

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

Earlier quoted context omitted.

The best libraries are libraries that have a clearly defined goal, hit that goal, and then don't change until the goalposts get moved. Something that happens only very slowly in font land. Its age is completely irrelevant other than as demonstration that it did what it set out to do, and still performs that job as intended for people who actually work on, and with fonts.

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?

Re: Memory safety for web fonts

#134

Post by truncate »

grishka wrote: post #127
da_chicken wrote: post #106

Earlier quoted context omitted.

That's not really the most charitable reading of GP's comment. I think they very clearly mean that Apple does not sell Macs with non-HiDPI displays anymore . It's not a configuration they sell, so they don't need to support those features anymore in their current offerings. You're right that there's nothing stopping someone from hooking up an HDMI-to-VGA adapter for their 22" Trinitron from 2001, but that doesn't mea…

> 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…

Since you are so sure about how Mac Mini's are used, is it 2k on 24" or 27" that these customers use?

My impressions based on limited anecdotal data I've is that most people with mac mini are using it as their secondary device (everyone has a Macbooks). Everyone is using 27" 4k monitors. 4k monitors are not that far from 2k monitors, and I think most people who are preferring to buy 2k are gamers that want higher refresh rate that their GPU can support at 2k. But gamers are not using Mac's anyway.

Re: Memory safety for web fonts

#135

Post by adgjlsfhk1 »

kortilla wrote: post #95
kevingadd wrote: post #48

Earlier quoted context omitted.

New (likely aesthetic only) bugs in font rendering are probably considered preferable to existing security vulnerabilities, I would hope.

“Aesthetic only” bugs for a project entirely for aesthetics can easily kill the usage of it. Nobody cares about a CVE-free rendering library if it can’t render things correctly.

that really depends. There are thousands of languages in the world in dozens of alphabets and I currently only have a hope of reading text in a latin alphabet. As such, even a rendering library that misrendered 99% of unicode but was CVE free would be a major win for me (and hundreds of millions of people)

Re: Memory safety for web fonts

#136

Post by jpc0 »

cbdumas wrote: post #30
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.

Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's…

> Of course evidence continues to build that no tooling or coding practice eliminates the risk here

Concidering Rust is just tooling and coding practice in front of LLVM IR does this statement not also include Rust? There are in fact formally verified C and C++ programs, does that formal verification also count as tooling and coding practice and therefore not apply?

If either of the above is true why does it matter at all?

I am specifically calling out your blanket statement and want to open uo discussion about it because at present your implied point was it is impossible to write safe code in C/C++ and it is only possible in Rust, however the very point you made would also apply to Rust.

There are also non-safety issues that may affect the integrity of a program. I recently again looked into Rust, haven't given up just yet but to just instantiate a WGPU project the amount of incidental complexity is mind boggling. I haven't explored OpenGL but concidering that the unofficial webgpu guide for rust [1] recommends using an older version of winit because the current version would require significant rewrites due to API changes is not encouraging. Never mind the massive incidental complexity of needing an async runtime for webgpu itself, is this a pattern I am going to see in different parts of Rust. Rust already has enough complexity without injecting coroutines in places where blocking functions are reasonable.

1. https://sotrh.github.io/learn-wgpu/#what-is-wgpu

Re: Memory safety for web fonts

#137

Post by p_ing »

grishka wrote: post #127
da_chicken wrote: post #106

Earlier quoted context omitted.

That's not really the most charitable reading of GP's comment. I think they very clearly mean that Apple does not sell Macs with non-HiDPI displays anymore . It's not a configuration they sell, so they don't need to support those features anymore in their current offerings. You're right that there's nothing stopping someone from hooking up an HDMI-to-VGA adapter for their 22" Trinitron from 2001, but that doesn't mea…

> 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…

They don't sell it as part of the configuration options.

You can separately purchase whatever monitor you wish. There are now plenty of 27" 5K monitors out there. Asus, LG (for now), Viewsonic, Kuycon, others I'm probably forgetting. They're expensive as far as monitors go, but not as expensive as the Studio Display.

Re: Memory safety for web fonts

#138

Post by p_ing »

truncate wrote: post #134
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…

Since you are so sure about how Mac Mini's are used, is it 2k on 24" or 27" that these customers use? My impressions based on limited anecdotal data I've is that most people with mac mini are using it as their secondary device (everyone has a Macbooks). Everyone is using 27" 4k monitors. 4k monitors are not that far from 2k monitors, and I think most people who are preferring to buy 2k are gamers that want higher ref…

24"-ish 4K, 27" is 5K, 32" 6K. Outside of that is not HiDPI and will lead to fuzzy fonts (your eyes may vary). PPI needs to be near 220.

Re: Memory safety for web fonts

#139

Post by ack_complete »

oergiR wrote: post #65
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.

FreeType was written when fonts were local, trusted, resources, and it was written in low-level C to be fast. The TrueType/OpenType format is also made for fast access, e.g. with internal pointers, making validation a pain. So though FreeType is carefully written w.r.t. correctness, it was not meant to deal with malicious input and that robustness is hard to put in afterwards.

TrueType also just has way too much complexity accumulated into it. The character to glyph mapping table alone has nine different encoding formats. I was only writing a TTF file instead of reading it and the complexity was still impressive.

Re: Memory safety for web fonts

#140

Post by vardump »

pcwalton wrote: post #80
steveklabnik wrote: post #33

Earlier quoted context omitted.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

Java only has tearing for double and long, which are POD types and so are irrelevant to memory safety. Go has tearing for pointer-like objects (interfaces, slices), which causes the memory safety problems. Data races on those pointer-like objects are undefined behavior in Go, whereas there isn't something comparable in Java. The reason why Go is considered a memory safe language is actually pretty mundane: it's simpl…

I haven’t seen any aligned double or long tearing for over 20 years on workstation or server CPUs.
Post reply on HN