Live data from Hacker News

Mozilla fixes Firefox zero-day actively exploited in attacks

bleepingcomputer.com

51–60 of 151 posts

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

#51

Earlier quoted context omitted.

Why managed when it could be in Rust and have both performance and safety? The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?

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)...

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

#52

We need a browser written in managed lang Even if it means some perf drop, modern hardware will get it back in X years, but safety will be significantly improved

From the fine article: > Throughout 2024, so far, Mozilla had to fix zero-day vulnerabilities on Firefox only once. > On March 22, the internet company released security updates to address CVE-2024-29943 and CVE-2024-29944, both critical-severity issues Vulnerabilities will be found in everything. Firefox is a fully internationalised application and it is FOSS. The team responsible for Firefox is doing a good job.

>Vulnerabilities will be found in everything.

Different ratios, different consequences, etc.

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

#53

Earlier quoted context omitted.

Why managed when it could be in Rust and have both performance and safety? The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?

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

> 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, decryption, don't forget add-ons people love add-ons, also add-on security and isolation, web edit and debug tools, network analysis tools, etc.

You know, little things.

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

#54
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 pretty relevant considering the continued mismanagement of Mozilla.

Nobody would care about Mozilla in 2024 without Firefox, but Firefox development seemingly takes a back seat to a variety of other pet projects that Mozilla’s management tries (and keeps failing, over and over) to chase.

For example, they’ve been trying a pivot to become a community-focused privacy company the last couple of years, yet are fine with implementing ad topics.

AFAIK didn’t Safari advocate against it over privacy concerns? If so, what is Mozilla doing?

Or their partnering with a shady company for removing data from data brokers.

Before the privacy pivot, there was the “we want to make browsing better” pivot with their acquisition of Pocket that went nowhere.

From the outside Mozilla looks like a low-scoring charity grift you’d find on CharityNavigator with how far they deviate from the missions they claim to support.

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

#55
post #6

Would Rust and it's memory safety stuff have prevented this?

It's not as easy as everyone might think. You could take a look at this thread titled 'My big problem with Rust is too much "unsafe" code' [1].

[1] https://news.ycombinator.com/item?id=41792477

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

#56
> The vulnerability impacts the latest Firefox (standard release) and the extended support releases (ESR).

Does that mean it impacts Firefox 131.0.+, Firefox ESR 115.16.+ and Firefox ESR 128.3.+?

I.e. Firefox 130.0.+ or Firefox ESR 114.+.+ are fine? It's not clear to me when the vulnerability was introduced...

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

#57
post #46
post #35

Regain your ability to sleep at night: https://www.qubes-os.org/

Does virtualization have that big a security benefit over containers? It's certainly a lot more expensive.

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

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

#58

Earlier quoted context omitted.

Why managed when it could be in Rust and have both performance and safety? The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?

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

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.

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

#60
post #57
post #46

Earlier quoted context omitted.

Does virtualization have that big a security benefit over containers? It's certainly a lot more expensive.

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

Yes, but it's a compromise, because I'm not happy spinning up tons of kernels and trying to share access to devices that do not want to be shared, either.

You're right that the trusted codebase is huge, but I sincerely do not know how big a problem this is in practice, hence the question.

Post reply on HN