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

81–90 of 230 posts

Re: Memory safety for web fonts

#81

Post by shadowgovt »

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.

Google's overall approach to Rust right now is based on a philosophy that sees two categories of bugs:

1. bugs in new code

2. bugs in old code that have survived years of scrutiny

Their conclusion from this is that they're generally greenlighting Rust for new projects but not requiring a rewrite for old projects because they believe rewrites are likely to introduce new category-1 bugs (regardless of the target language). But new code always has category-1 bugs, so if they write it in Rust they cut down on the number of possible category-2 bugs thanks to the static constraints imposed by the type system.

I'm assuming the font module got rewritten into Rust because they planned to rewrite it period (i.e. their analysis suggests the current status quo of how it's built and maintained is generating too many bugs, and Google tends to be very NIH about third-party dependencies so their knee-jerk response would be "solve that by writing our own").

Re: Memory safety for web fonts

#82

Post by GaggiX »

fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

Translation technology has gotten so much better in the meanwhile, I didn't even notice it at first.

Re: Memory safety for web fonts

#83

Post by jorvi »

pradn wrote: post #73
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?

Yes, a SWE-year is a common unit of cost. And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB. This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea. I personally have use…

Note that this can lead to horrid economics for the user.

An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU.

It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.

Re: Memory safety for web fonts

#84

Post by slyzmud »

fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

The worst offender to me is Google Maps. I'm a native Spanish speaker but set my phone to English because I hate app translations. The problem is when I want to read reviews it automatically translates them from Spanish (my native language) to English. It doesn't make any sense!

Re: Memory safety for web fonts

#85

Post by [deleted] »

GoblinSlayer wrote: post #43
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 code looks chaotic, though, it was written for local trusted fonts first. It was a typical google move "let's expose this random thing to internet, we can add security in 2025".

[deleted]

Re: Memory safety for web fonts

#86

Post by spookie »

3form wrote: post #32
fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

Hey, at least it's preferred language. It's much worse when it bases it on the country that I'm in, which I can only reasonably influence with a VPN, and calling that reasonable is a stretch.

It cuts in both ways.

I'm trying to learn the language of the country I now live in. And yet, Google thinks they know better than me, my preference, at the moment.

And this preference is quite circumstantial, mind you.

Re: Memory safety for web fonts

#87

Post by steveklabnik »

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…

Yes, I certainly agree that Java's guarantee is stronger, and that it's harder to exploit Go's issues than non-MSL's issues.

Re: Memory safety for web fonts

#88

Post by x0x0 »

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.

I generally agree, but their manual memory management CVEs were dated 2014 and 2020. That doesn't really feel like a strong substantiation of their case here.

Re: Memory safety for web fonts

#89

Post by woodruffw »

jasonthorsness wrote: post #51
cbdumas wrote: post #30

Earlier quoted context omitted.

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…

I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.

> why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.

It can be, if the composition is itself sound. That's a key part of Rust's value proposition: individually safe abstractions in Rust also compose safely.

The problem in C isn't that you can't write safe C but that the composition of individually safe C components is much harder to make safe.

Re: Memory safety for web fonts

#90

Post by ghusbands »

wkat4242 wrote: post #47
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

To be clear: Windows still does subpixel rendering, and the wizard is still there. The wizard has not actually worked properly for at least a decade at this point, and subpixel rendering is always enabled, unless you use hacks or third-party programs.
Post reply on HN