201–210 of 319 posts
Earlier quoted context omitted.
Yep, stuff like this makes me question many things. I mean in a sane world this should be enough to sue them into oblivion. But the general bar in that regard is so low, that apparently even open source companies can do it as default.
Why don’t you think it’s a sane enough world to “sue them into oblivion”?
Earlier quoted context omitted.
Note that despite that study, Windows and XBox teams are quite found of their C and C++, and even their own .NET has more success on the Azure side, than replacing all those COM/WinRT C++ workloads, and extension points. It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.
> Note that despite that study, Windows and XBox teams are quite found of their C and C++... And we all know how secure the average user's Windows computer is. And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux. And the uptime. Let's not forget the uptime with patch…
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
Those that have glass ceilings should not throw rocks.
Earlier quoted context omitted.
> The problem with targeting a subset is there's a ratchet effect with web APIs What about starting a new web then only for the supported subset? Based on my current browsing experience, this may be a plus in the long run.
The problem is convining anyone to write a website in this. You will have like 3 sites that use only the subset. The closest example is AMP, but you must be Google to force people to use it.
I hope both Ladybird and Servo succeed in creating a new browser engine. Though I do have a slight preference for Servo as it's using Rust. Not that Rust is magical, but given how much attack surface there is in a browser, it seems picking C++ is a bit odd in 2024.
Personally if I were to attempt a project at this scale, I'd do so using a language I'm proficient in. There might be other reasons, but Rust & C++ really are different beasts.
Earlier quoted context omitted.
This is so wildly wrong it hurts. As soon as that one important website (to your user) breaks, they will switch browsers. Just deciding that you don't want to implement >50% of web specs "for simplicity" and expecting that to be a winning strategy is very HN.
To me it’s not wrong at all, why won’t a simpler browser with a “modern mode” rendering succeds? There is no need for that browser to support the space jam website, who really cares? Imo thinking that people need quirks mode because they need to visit old website it’s very HN.
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
> 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
IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).
I really don't want to drop the all too common negative comment - in particular since I already use an alternative web browser - but the initial investment required just for an MVP seems mind-boggling to me.
I think a basic HTML browser that can automatically delegate all it cannot handle to other apps - PDF viewing to a PDF viewer, video playback to a video player, and JS-requiring things to a big browser - would be interesting (if it already exists, please let me know).
Earlier quoted context omitted.
The problem with targeting a subset is there's a ratchet effect with web APIs, once support reaches critical mass in the major browsers sites will start unconditionally relying on those features and there's no going back from there, any new browser has to also support those features or be considered broken. I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too…
> The problem with targeting a subset is there's a ratchet effect with web APIs What about starting a new web then only for the supported subset? Based on my current browsing experience, this may be a plus in the long run.
It's even deliberately designed to not be easily extensible, as to avoid the temptation of adding features.
Earlier quoted context omitted.
The problem with targeting a subset is there's a ratchet effect with web APIs, once support reaches critical mass in the major browsers sites will start unconditionally relying on those features and there's no going back from there, any new browser has to also support those features or be considered broken. I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too…
> The problem with targeting a subset is there's a ratchet effect with web APIs What about starting a new web then only for the supported subset? Based on my current browsing experience, this may be a plus in the long run.
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…
Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.
Andreas Kling is a great role model in the world of development I feel. The decision to step away from the Serenity OS makes a lot of sense. There are plenty of them, nice projects to do, but they'll never have an immediate impact if any at all. But the browser space, Ladybird is viable as a daily driver for people. I'm still today astounded the work that has been produced just on this. > Somewhat ironically, it was…
(Sarcastically saying something is interesting is something I find distasteful.)
Anyway the irony is that the project chose to use a discussion platform which uses lots of modern web cruft and would be a big challenge for a new browser, when they could have chosen a (maybe less capable) simpler platform like IRC or some simple web forum which would more likely have run on Ladybird.