Mozilla fixes Firefox zero-day actively exploited in attacks (opens in new tab)

I block CSS animations:

https://news.ycombinator.com/item?id=33223080

I'd be interested to know if it's sufficient to avoid this recent vulnerability. Either way, it confirms my opinion that UI animations are an anti-feature.

Firefox doesn't seem to support css animation-timeline, I think this refers to the JS AnimationTimeline API? In that case "dom.animations-api.timelines.enabled" flag should control it.

The vulnerability did require JavaScript to trigger.

I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.

The snap store also complains regularly that it can't updte the snap store because the snap store is running. It is just terrible software overall.

Neither am I, but seems that snap refreshes can be inhibited programmatically if they may cause some damage when proceeded in the background. So it is technically correct that no snap refreshes can be performed at this point, but the message doesn't clearly state that some refreshes have been inhibited (possibly because there would be tons of them if they are exhaustively listed?).

It doesn't update actively running application containers.

You don't actually need to stop it before running “snap refresh” though, it'll just be out of date as long as it is kept open. Once the application stops running, next time it is run the updated image will be used.

[caveat: I'm not a snap user myself currently, so my information may be inaccurate, take with a pinch of your favourite condiment]

The difference being that no one in their right mind is thinking of rewriting a browser in Java to also make it faster, while that's exactly what Servo/Stylo etc are all about.

And don't forget Ada.

Brainfuck too!

CVE affected range is always far too wide. It obviously can't affect anything before ~75 or so because firefox didn't have the timeline api before then. It's annoying that they don't distinguish an unknown lower bound.

Android code was recently imported into mozilla-central which is quite considerable in size.

But the CEO got it’s pay raise, so we are safe.

https://techrights.org/o/2022/02/17/mozilla-salaries/

https://www.reddit.com/r/browsers/comments/yy986k/can_someon...

https://news.ycombinator.com/item?id=38849580

Im aware of Rust, but there is C#/Java too, with way bigger ecosystem, community and lower entry level.

At the end of the day web browser is just bunch of parsers and compilers working together, and some video/audio

>Vulnerabilities will be found in everything.

Different ratios, different consequences, etc.

Im aware of Rust, but there is C#/Java too, with way bigger ecosystem, community and lower entry level

Swift didn't save apple from rce's in blastdoor.

That's not completely accurate. The plan is to use Swift for "security critical" areas like decoding data. It's unlikely core components like the layout/CSS engine will be converted to Swift.

I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure).

Not sure why you think that WASM is less secure than JS though. Even if the WASM heap has internal corruption there's no way for this to do damage outside the WASM sandbox that wouldn't be possible in JS.

They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so.

Probably the biggest thing is to have a lot of ram, because if you're really using the virtualization it's a bit ram inefficient.

Many things I expected to be hard or annoying just turn out to be non-issues. Qubes has lots of good automation to make it pretty seamless to use multiple VMs.

I was already a fedora user, so I just copied my old home into a new app vm and was instantly productive. Then over time I weaned myself off the monolithic legacy vm into partitioned VMs.

It depends on how you use it. The more you leverage its strengths (by splitting out AppVMs), the larger the overhead in memory and CPU.

I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.

If you anything with a GPU anywhere, you can essentially forget it. Or at least this was the case a few years ago when I briefly toyed with using qubes seriously.

Containers share the same kernel as the host. If you're happy sharing millions of lines of monolithic C between trust domains ...

Containers aren't a security measure, so you'd be comparing a stick of wood to a car in this case.

128 is the current ESR: https://whattrainisitnow.com/calendar/