Live data from Hacker News

Ladybird browser spreads its wings

lwn.net

121–130 of 319 posts

Re: Ladybird browser spreads its wings

#121
post #35

I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.

On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with. Perhaps it's a similar situation for Ladybird. >Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code executio…

40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.)

As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons.

So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that

Re: Ladybird browser spreads its wings

#122

From the linked site: > In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites. Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?

As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own…

> As I understand it: Spectre/Meltdown allow reading from the address space of the same process only.

Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.

Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):

https://meltdownattack.com/

> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.

Re: Ladybird browser spreads its wings

#123

> Ladybird now targets Linux and macOS. The SerenityOS target is dropped. What does this mean, that Ladybird will no longer run on Serenity OS? And that is up to the Serenity peeps to make it run should they wish to do so?

Yeah and I believe the reason given is because Ladybird wanted to use third party code and SerenityOS has a no third party code policy which made targeting Serenity kind of hard.

Re: Ladybird browser spreads its wings

#124
post #74
post #35

I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.

I'll take an alternative browser engine, even if it's written in C++. > I'm curious Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the…

It’s curiosity because I’m involved in software security for the company I work for and I’m a software developer that primarily works with managed languages. I unfortunately lack the technical expertise to make an assessment on interpreters and virtual machines. I am, however, aware that many of the CVEs that I review involve reading/writing memory outside the intended bounds. Many of these while processing user generated content.

I appreciate that the author birthed the project as a way to direct his energies towards more productive means. I don’t think it’s relevant to the question though.

Re: Ladybird browser spreads its wings

#125
post #108

Earlier quoted context omitted.

I doubt it. Your prediction might be more appropriate for a project that's in its first week of development, not having been developed for several years and already overcome many difficult hurdles. And if they switch to chromium, there is literally nothing interesting about this project. The fact that it's a novel engine is their only differentiating feature.

The age of the project or the development status of the project does not matter, what matters is the user base. If you build anything that accumulates users, business interests will be aroused at some point. Business people don't give a shit about the technology itself unless of course the technology itself really is a USP and can be converted into €$. But most people (end users) don't care much about the underlying…

It may be hard for you to believe but there are projects not run by "business people".

Re: Ladybird browser spreads its wings

#126
post #35

I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.

Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?

Re: Ladybird browser spreads its wings

#127
post #29

I’m irrationally excited for this project. The idea of a community built browser is incredibly appealing considering the current landscape where all browsers are either Chrome, Chrome in a trench coat, or Firefox

I don't understand what is wrong with Firefox. It is open-source, highly configurable and reasonably secure (if you have the time to configure). Yes, it has shortcomings, but what doesn't.

Around Firefox 4 it became a shitshow of questionable UI redesign every version. And performances where not up to Chrome.

Also Chromium is open-source, and Firefox is mainly funded by Google so it not like Firefox has a real proposition value or independence.

Re: Ladybird browser spreads its wings

#128
post #6

I hear so much about Ladybird on HN, that I’m equally excited and cynical. What is the value proposition? Is it to be another general purpose browser, so there’s more competition with Chrome / WebKit? Or to be a niche browser, that could be an alternative to Electron? How close is it to achieving that?

Ladybird is an experimental engineering project; consider it "basic engineering" (a la basic research). Thinking in terms of "value proposition" is very limiting. Its goal is to develop an independent web stack (not a "hobby project" at all); its intent, one of several really, is to peek into and implement the internals of the modern web stack.

By doing so openly and incrementally without attachments to deadlines or an employer with specific priorities, the dev can take the time to identify inefficiencies, pain points, subtleties across the stack etc. which are then recorded in the development of the browser.

Thus, the project is not aimed to "achieve" something at some point in time; its "value proposition", if you must use this annoying term, is the development process itself.

Re: Ladybird browser spreads its wings

#129
post #32

One commenter who worked on Firefox made a nice blog post in response, about what it takes to make a web browser: https://robert.ocallahan.org/2024/06/browser-engine.html

For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis. I’d wildly guesstimate for 70% of use cases you wouldn’t even need 50% of stuff with some slight modifications. The web is just so bloated. Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas

[flagged]

Re: Ladybird browser spreads its wings

#130
post #85
post #74

Earlier quoted context omitted.

I'll take an alternative browser engine, even if it's written in C++. > I'm curious Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the…

>> I'm curious > Is it really curiosity though? I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language). It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used. It's so sad.

That’s a pretty cynical view. It’s more like asking why a car manufacturer is developing a car without modern safety mechanisms despite knowing those mechanisms save lives.

If this is a work of art whose code is to be admired and only viewed as a creative work, fine I’m sorry I asked the question and that it was criticism of one’s vision.

However, if this is something that is intended to be “driven” by other users in the future I think it’s a perfectly acceptable question to ask why more modern safety mechanisms are not being employed. Maybe there is a rationale I’m unaware of or a reason why those mechanisms are not employed.

Post reply on HN