Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Ladybird browser project

ladybird.dev

Post reply on HN
Print view View original

211–220 of 293 posts

Re: The Ladybird browser project

#211

Post by jorvi »

gkbrk wrote: post #132
jorvi wrote: post #102

Earlier quoted context omitted.

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

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.

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.

Re: The Ladybird browser project

#212

Post by jorvi »

mouse_ wrote: post #175
jorvi wrote: post #102

Earlier quoted context omitted.

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

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

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.

Re: The Ladybird browser project

#213

Post by jwells89 »

JimDabell wrote: post #182
legacynl wrote: post #152

Earlier quoted context omitted.

> European Union is coming after apple.... seems short sighted I think you have a fundamental misunderstanding of the goals of the EU in this matter. The objective is not to keep both companies on even keel, but it is merely about enforcing existing anti-monopoly laws. If this results in Google gaining a de-facto browser monopoly then those same laws can be used to break up that monopoly when we get to it. What would…

> What would be the alternative in your opinion? Force Apple to allow alternative rendering engines, but only the ones with People already mistake Blink-only APIs like Web USB, Web Bluetooth, Web MIDI, etc. for web standards. The market is already dangerously close to where it was 20 years ago, where a vast number of web developers treat the most popular rendering engine as if it’s synonymous with the web. Handing mo…

Another thing the EU could do which would help is to prohibit cross-promotion of browsers, as Google has quite aggressively done since Chrome’s inception and Microsoft is returning to doing with Edge.

That means no more “download Chrome” prompts on Google search and YouTube, no pestering people to install Chrome when tapping links in Google iOS apps, no bundling of Chrome in installers of unrelated software (very common on Windows), etc.

Some sort of rule against favoring one’s own browser in web apps (as has happened with GSuite and YouTube on multiple occasions) would also be nice but unfortunately strikes me as unlikely.

Re: The Ladybird browser project

#214

Post by jwells89 »

scblock wrote: post #194
grey_earthling wrote: post #117

Earlier quoted context omitted.

> if it works in Chrome, all web developers will adopt it This is why we, tech nerds who understand the problem, must resist monopolies: object to using such APIs. Chrome wouldn't be in quite this position if, instead of embracing the monopolist, more techies had warned their non-techy friends and family away from it, like they did with IE.

"Tech nerds" built web sites that only worked in IE back then and "tech nerds" are building websites now that only work in Chrome. Didn't have a clue back then, and don't have a clue now. Forget warning "non-techy" people and clean your own house first.

Ethics go out the window so long as the flow of shiny new features remains unimpeded. The only reason devs turned against IE is because Microsoft got complacent and essentially abandoned it, letting Gecko and WebKit steal the spotlight… a move that Google is smart enough to know to not repeat.

Re: The Ladybird browser project

#215

Post by SkiFire13 »

jll29 wrote: post #68
stephen_g wrote: post #19

It's really quite incredible that one guy basically started a project to create a whole operating system from scratch for fun and to give himself something interesting to do, and then accidentally created one of the most viable new browser engines in a decade or two... I've been watching the development videos for a year or two, and the speed that this has progressed in such a short time is unbelievable. Now they hav…

He is a world expert on Web rendering, and an extremely capable C++ developer. One of their success recipes is to code up the various specifications directly, which is - today - the best way to go about this. They are also heavily test-driven. He did not even use the C++ standard library, when he says "from scratch" it includes his own string class, for better or worse, which is fine since it's "just for fun", "to le…

> then Jakt, their own novel programming language, because neither C++ nor Rust is what makes him perfectly happy.

TBH Jakt defaults to reference counting, which makes it compete more with Swift and Go rather than C/C++/Rust.

Re: The Ladybird browser project

#216

Post by Misdicorl »

jorvi wrote: post #210
trashburger wrote: post #139

Earlier quoted context omitted.

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.

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.

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?!

Re: The Ladybird browser project

#217

Post by SkiFire13 »

Cthulhu_ wrote: post #148
TheCoreh wrote: post #94

Earlier quoted context omitted.

When you open sites on other "new" browser engines you typically get a really butchered visual result, with layouts completely broken, elements missing, wrong colors, etc. For example, Servo didn't support floats until recently, and IIRC even simple sites like Hacker News look "wrong". Ladybird's approach has been to start with a somewhat naive implementation of features, then choose popular websites and apps and jus…

I can't relate / do not recognise these claims of incorrect rendering; is there a resource out there that shows images of how it's supposed to be vs what it looks like? I thought this was a problem of the past, IE compatibility with web standards kind of thing.

> I thought this was a problem of the past, IE compatibility with web standards kind of thing.

For the mainstream browser engines, yes, but if you're starting a browser from scratch the amount of stuff you have to implement is massive and cannot be implemented in the span of even a couple of years.

Re: The Ladybird browser project

#218

Post by TheCoreh »

ptx wrote: post #190

Are there any plans to rewrite the browser implementation in the Jakt language once that gets a bit more stable? Memory safety would be a unique advantage over other browsers (aside from Servo).

I am also looking forward to that, but I think the Serenity philosophy is to not make any long term plans and commitments.

If the language becomes mature enough, and there are people interested enough in doing that porting, it will likely happen.

I think their C++ code is also constrained enough due to the use of their custom standard library that it would be possible to write a transpiler from C++ to Jakt.

Re: The Ladybird browser project

#219

Post by TheCoreh »

hosteur wrote: post #185

I am fascinated by this project. What are the chances that this could become a real world usable replacement for chrome or Firefox witching the next couple of years?

My gut feeling with how far they've come in so little time says it's definitely in the double digit percentage points.

Re: The Ladybird browser project

#220

Post by matheusmoreira »

pygy_ wrote: post #101
sph wrote: post #70

Earlier quoted context omitted.

It is not any easier, because we still have a monopoly running the show, only it's not called Microsoft anymore. If anyone threatens Google position, they can literally throw money at the problem, invent some overcomplicated standard, implement it in Blink, and have the competition chase them. It doesn't need to go through W3C either, if it works in Chrome, all web developers will adopt it and any smaller engine will…

This is where Apple'grip on the iOS browser engine choice paradoxically comes in clutch. It is conceptually despicable, especially for devs, but it prevents Google from completely running the show. Now the European Union is coming after Apple without trying to rein in Google's influence... This seems short-sighted.

> without trying to rein in Google's influence

That's the problem. They should go after Google too. Honestly all of these megacorporations should be broken up.

Post reply on HN