3 ms·
"We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds". You'd rip a new one to Google if there would be
by izacus 18d ago
"We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".
You'd rip a new one to Google if there would be a CVE in a new C++ library in Chrome because of it.
Now that Rust library is available, they will continue adoption, as it should be.
- account42 18d ago> "We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds". It is when that didn't stop them YOLO'ing in webp and then avif support.
- izacus 18d agoIf you have two toilets in your house, are you going to sign up to clean mine too, for free, because I demanded it from you? Thought so.
- F3nd0 17d agoThe stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration). Memory safety as a condition for adoption was brought up only years later, and by Mozilla rather than Google. The JPEG XL devs, who’d offered to work on it if there was interest, got to work as soon as interest was proclaimed. You might say it’s a good thing for Chrome to have held off adoption until then, but that’s completely incidental, not because they cared. Near-zero efforts to be fair and responsible were made.