[jorvi]

> they are making their own image decoders as an example -- inclding SVG

Considering the vast amount of exploits that continually comes out of media decoders everywhere, this basically guarantees I will never ever use this browser.

[trashburger]

Have you looked at how it's implemented? The image decoder is completely separate from the main browser and is in a sandboxed process (with restricted syscall and filesystem access). If the image decoder is exploited, there's nothing the attacker can do.

[ptx]

Where can I find more details on how this sandboxing works?

Edit: Seems like it's using OpenBSD's pledge API? https://www.youtube.com/watch?v=bpRw6KQnY0k&t=8107s

[jorvi]

Look at how many of the past big exploit chains on iPhones, Chromium etc involved media decoding at some point in that chain.

It’s like crypto, you have to be very deliberate with your choices, and it’s generally ill-advised to roll your own.

[Misdicorl]

That advice has context. Do not roll your own if the feature is not your core product offering. So don't roll crypto if you're not selling crypto. If it is your core offering (and media decoding is absolutely a core offering of a web browser), you should choose carefully whether to get it off the shelf or roll your own.

Otherwise how would new/better stuff ever get built?!

[jorvi]

If Apple and Google can’t even find all the vulnerabilities in their libs, how on earth would a scrappy team of a few devs, especially since media decode isn’t the sole thing they’re focused on?

> Otherwise how would new/better stuff ever get built?!

The problem here is that people are salivating to use this as their daily driver. When WireGuard was still in development, everyone got told in very strong terms to not use it in any setting that required actual security.

Browsing the web at large is sort-of hostile by default.

Ladybird is a great project, and I hope it keeps developing, but any user that thinks their media decode libraries will be bulletproof libs free of vulnerabilities are nuts.

[tremon]

If Apple and Google can’t even find all the vulnerabilities in their libs, how on earth would a scrappy team of a few devs

Perhaps a few devs have nowhere near the required escape velocity to create vulnerabilities before they can be fixed, nor the pressure of PMs to ship substandard code?

[Misdicorl]

> but any user that thinks their media decode libraries will be bulletproof libs free of vulnerabilities are nuts.

Sure. And its a high bar to challenge the same or better vulnerability profile that the established players have. But a "small scrappy team" which is capable of doing everything this team has done certainly garners a lot of confidence that the bar is possible.

[Neikius]

Apple and google are big corpos and those are legendary for their inability to make anything properly. It has been a while since they were small and could move fast... So no, I would not take them as a standard.

[gkbrk]

That's fine, I'm sure they weren't targeting only you when they developed it. So it will still have utility for the developers of the project and other users.

[jorvi]

Let’s be dismissive of bad security practices I’m sure it’ll work out fine.

There would be absolutely nothing sacrificed by using open source, well-tested libs for image decode.

[DexesTTP]

I don't think that's a healthy mindset to have.

Just because something is widely used doesn't mean it's more secure (example: libwebp). The security issues tend to happen mostly when creating optimizations that bypass the "obviously secure" way to do things, but rely on an internal state that gets broken by another optimization down the line. This is way less frequent in "smaller" projects, just because they didn't need to go through that round of optimizations yet.

For this question specifically, tho, I think Ladybird is extremely interesting in terms of creating a security-focuses C++ project. Between the constant fuzzing that each part of Ladybird already goes under (courtesy of the OSS-Fuzz initiative), the first-class citizenship of process separation for the different features of the browser, the modern C++ used in Ladybird (that prevents a lot of the issues cropping up in commonly used media decoding libraries), the overall focus on accuracy over performance in library implementations, and the compiler-level sanitatization utils (UBSAN, ASAN) that are enabled-by-default, I think it's less likely that an critical security-impacting bug would exists in Ladybird's .ico support than in Webkit's for example.

[mouse_]

If something is bad, we should be trying to rewrite it. Will you not touch WireGuard because OpenVPN is full of holes?

[jorvi]

If massive companies like Google and Apple can’t even find all the vulnerabilities, how are you expecting a scrappy team to?

Don’t get me wrong, how far they’ve gotten is very laudable and as a educational exercise it is really cool, but it starts being a pretty massive risk if users start using this as a daily driver.

[cantours]

Google and Apple are just a bunch of scrappy teams trying to work together on insanely massive and bloated code bases. Numbers of bugs scale with lines of code.

Small scrappy team writing simple and consice code from scratch is likely to produce fewer bugs than enterprisey monstrosities.