Good questions -- yes other Chromium-based browsers would likely be affected by this bug. Many of these do a commendable job of following security updates in Chromium (like Brave), but others tend to fall quite far behind (like Samsung's SBrowser).
Chrome desktop was affected as well, both on Linux and Windows. Chrome bundles its own version of libwebp, so even if your Linux distribution hasn't patched yet, as long as Chrome is up-to-date you should be OK (in terms of browser attacks at least).
There's lots of wonderfully obscure image file formats that are supported by the major browsers and operating systems. For example you can load a KTX2 file (Khronos Texture Container) on MacOS, or a DNG file (Adobe Digital Negative) on Android. Lots of interesting and highly exposed attack surface for attackers to explore.
Chrome on MacOS was affected as well, yeah. Note that we don't know if attackers exploited the bug on platforms other than iOS, but its certainly possible that they did (I'd argue even probable).
1. Everything that supports WebP is affected. Not just Chrome and Electron, but all browsers, desktop and mobile, and non-browser software too. All kinds of image viewers, graphics programs, email clients, even your file manager that shows thumbnails.
The bug is in the codec library, and WebP has implementation monoculture, so everyone uses the same library, and everyone needs to patch.
3. Google tried to make WebP a thing 10 years ago, but it didn't get much traction, since it was Chrome-only for a long time. It never got properly standardized (it is open source tho). It compresses low-quality images better than JPEG, but tends to blur and smear colors in higher-quality images.
Ironically WebP became widely supported at the same time when it became technically obsoleted by AVIF and JPEG XL.
Desktop Linux is on the relatively safer side, just because so much of the open source ecosystem still uses dynamic linking so it just needs your distro to package a new version of libwebp.
All the proprietary software with their own bundled versions of electron or vendored libraries, etc. on the other hand...
> so it just needs your distro to package a new version of libwebp.
That and every snap/flatpack/etc. package, every container image you are using and possibly pip packages that can come with and compile all kinds of dependencies and haven't been maintained for ten years...
The security benefit a well maintained Linux distro provides has been eroding for years now.
However, you can choose to largely avoid these. Yes, people are pushing the other way, but you can not use snap and flatpack of you use a distro with large repos. You can use Python virtualenvs with --system-site packages and put just pure python packages in your requirements.txt. You can run things in containers for security without using images.
I think there are two problems:
1. people running single/small numbers of servers copying practices that are used by people running fleets of containers who can have someone promptly updating everything has needed.
2. As always, convenience. The easiest and best supported way to pip install things is without --system-site-packages.
I have always felt we were going the wrong way with this. I thought I was the only one!
What do you mean? Dolphin displays thumbnails perfectly fine, and I love how easy it is to change the thumbnail size (ctrl-mousewheel or the slider at the bottom).
I don't think I've ever seen that in the past several years of using Dolphin. The context here being webp, I checked the many webp files I have, and Dolphin thumbnails all of them without any issue.
Yeah, but once you fix the library the system should be safe. Well, except for all of the snaps and docker containers and whatnot. Those will need to be updated as well.
I ignore them without problem, I do most of my web reading on my iPad that does not support webp and most sites display images without issues. Usually the ones that only offer images in webp are low quality sites and it’s usually a good sign I should just bounce.
You've almost certainly downloaded WebP images, but you didn't realize it because many websites serve multiple formats at the same URL. This is often done with a HTTP reverse proxy that automatically converts between formats so if you have a modern (last decade) browser, you'll get a WebP even if the download's file extension seems to be ".png". All modern image editors support WebP so you'll never notice the difference
On The Guardian for example it looks like I'm getting WebP for the photo collections and AVIF for the story images, both from .jpg URLs (in Firefox hit Ctl-I to see image info). Their photo galleries have been WebP for years. Firefox is clever enough to correct the suffix if you try to save it.
>All modern image editors support WebP so you'll never notice the difference
This support has always been overstated. Photoshop still doesn’t support it, you encounter other weirdness like Apple Preview.app can view them but not edit them.
Preview.app is the exception to the rule, but it still has acceptable UX. After you finish drawing the first brush stroke on a WebP file, it will ask you to reopen the edited file as a tiff before you continue editing. No loss of data or functionality
> 3. Why haven't I heard of WebP before? Am I living under a rock, or is this a mobile-first technology?
It's been supported in desktop chrome for a long while. There's dozens of JPEG replacements that have come and gone, and WebP is primarily notable for having Google's clout behind it. When Google bought Duck/On2 they got a lot of video compression technology, some of which went into WebP.
Oh, it's definitely something that makes/made sense for them to do; just pointing out that not knowing one of many JPEG replacements doesn't mean you live under a rock.
s/JPEG/PNG/ and my comment still works. In any event it's clearly designed for both, since the lossy and lossless modes are relatively independent of each other.
Every browser is affected, Firefox issued security update as well.
WebP is gaining popularity as replacement for JPEG, I'm surprised you haven't stumbled it on yet, cause more and more images I download from the web turn out to be WebP.
Many CDNs use it automatically. They detect you're on a modern browser and transparently compress sub-optimal images like PNGs without loss of quality.
I did find that `ffmpeg -i file.png -lossless 1 test.webp` could produce a full-res chroma image, recognized as WebP by file and opening successfully in Chrome and Firefox. I was under the impression this was not possible, but I suppose it is (today, not sure in the past).
Why do I see WebP as an image format used to sneakily degrade PNG files? I've seen gaming wikis and CDNs serve PNG URLs as lossy WebP, ruining pixel art and degrading color detail in 2D art. And Discord CDN's "file.webp?size=1024&quality=lossless" serves icons/emotes with chroma subsampling (and ffprobe doesn't say the file is lossless, unlike test.webp above).
Dunno about ffmpeg, but the official library supported lossless encoding a decade ago
> Why do I see WebP as an image format used to sneakily degrade PNG files?
Why does Twitter reencode PNG to JPEG even when this results in larger file sizes and terrible quality for 2D art and technical drawings? All the services you've listed are free and they all cater to the lowest common denominator. They'll never use lossless WebP by default for the same reason they won't use PNG. Lossless media is virtually unheard-of outside our bubbles. If you're lucky there will be a "download original" button
1. Are other Chrome-based browsers (e.g. Brave) affected by this?
2. Is desktop Chrome affected, or is this purely a mobile thing?
3. Why haven't I heard of WebP before? Am I living under a rock, or is this a mobile-first technology?