Live data from Hacker News

Mozilla fixes Firefox zero-day actively exploited in attacks

bleepingcomputer.com

91–100 of 151 posts

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#91
post #45

Earlier quoted context omitted.

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

What's that got to do with anything? The CEO situation is awful, but this is just flame bait on your part.

It’s all have to do with resource management here.

It’s obvious that laying off people that were working hard at making more robust the flagship product of the non-profit wasn’t going to result in a an increase of security in this product. Could the whole lay-off have been prevented? That would require some number analysis here, and insights I lake.

Could at least some termination have been avoided? Freezing the income of the CEO until some agreed metrics improve, and use the amount thus spare to save some employ salary was certainly an option here, wasn’t it?

Claiming "think of my family, look how much more some other people earn elsewhere" while almost simultaneously (at organization level at least) putting so many people in a jobless position, that’s a rather bold cognitive dissonance to throw at the world to my mind.

If pointing out "odd financial priorities" of a non-profit is flame bait, one might wonder how humanity is supposed to mend all organizational dysfunctions it can ever fall into.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#92
post #44

Earlier quoted context omitted.

From your experience, what are the system requirements needed to use that as comfortably as your daily driver?

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…

> a world where a random click from HN or reddit can't quietly compromise your entire computer

Doesn't Flatpak also solve this?

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#93
post #53

Earlier quoted context omitted.

> At the end of the day web browser is just bunch of parsers and compilers working together At the end of the day, OS is just a bunch of command lines being piped together. /sarcasm Sure, you are just missing: rendering, layout, security, network traffic for sockets, low-level control over hardware, writing a decent enough VM, image processing, video playback, music playback, compression, decompression, self-update,…

Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT? Same with crypto, sockets, compression, etc? Video and audio I mentioned. Extensions are tricky, right, but more from privacy standpoint cuz after all you can just expose too much

Browsers are using new http features much earlier than they're available in the system libraries. Browsers supported http2 and 3 before they were standardised enough to include in systems. .net http client still can't even tell you about http2 early hints as far as I understand it.

It's going to be the same for crypto and compression. Systems don't ship with brotli for example. The battle tested implementations come to the browsers first in many cases - or at least they're battle tested at the point anyone starts including them in .net or Java.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#95
post #78

Earlier quoted context omitted.

The problem with writing a browser in C# or Java is that neither of them can provide anywhere close to the level of thread safety that Rust does.

both java and c# has thread safety primitives that are also pretty easy to use. E.g., the java concurrency package.

The cool thing about rust is that it forces you to use thread safety primitives. It's called fearless concurrency

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#96
post #51

Earlier quoted context omitted.

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

Servo exists, in Rust. I don't know of any browser engine in C#/Java? Also, modern browsers as a whole outsize entire OSes (sans browser)...

> I don't know of any browser engine in C#/Java?

A famous one is HotJava. According to Wikipedia, it was also the first web browser to support Java applets.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#97
post #25

Earlier quoted context omitted.

They already are partly in JS so there's a smooth path. (Wasm isn't safe but could be a building block too)

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

> 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

Was it this one? https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

Or perhaps this one? https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#98

Earlier quoted context omitted.

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]

Interesting. On Arch, Firefox just refuses to keep working after I've updated and requests me to restart it.

That is Firefox standalone behavior when it detects its files have been changed and differ from the ones loaded by the current instance. In theory, what snap is doing avoid changing files from a program while it is running.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#99

Earlier quoted context omitted.

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]

Interesting. On Arch, Firefox just refuses to keep working after I've updated and requests me to restart it.

Well, it was more broken in more interesting ways before they implemented the forced restart

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#100

Earlier quoted context omitted.

Interesting. On Arch, Firefox just refuses to keep working after I've updated and requests me to restart it.

Well, it was more broken in more interesting ways before they implemented the forced restart

Yeah, I remember. That was fun. haha
Post reply on HN