Readit Newshttps://hacks.mozilla.org/2022/11/improving-firefox-stabilit...
Seems like a worthwhile change, though I'm not sure when I'll get around to it.
[1] https://github.com/WebKit/WebKit/pull/41945 [2] https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...
He and the other previous contributors are free to find new employers to continue such an arrangement, if any are willing to make that investment. Alternatively they could cobble together funding from a variety of smaller vendors. I think the author is happy to move on to other projects, after spending a long time in this problem space.
I don’t think that “don’t let one megacorp hire a team of contributors for your FOSS project” is the lesson here. I’d say it’s a lesson in working upstream - the contributions made during their Facebook / Meta investment are available for the community to build upon. They could’ve just as easily been made in a closed source fork inside Facebook, without violating the terms of the license.
Also Mozilla were unable to switch from their fork to the upstream version, and didn’t easily benefit from the Facebook / Meta investment as a result.
The Windows port is moving from Cairo to Skia soon as well, matching the GTK port (though I think the focus is enabling the CPU renderer to start).
Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of funding the hardware.
There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users). It'd definitely be more work than Linux, but it's not as bad as you'd think.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...
For reference, Chromimum (and therefore Chrome) is a monster of a project and has at this point probably over 10 million lines of code and has taken +20 years to develop with thousands of developers involved.
I can only conclude that:
a) the modern WEB is so complicated that this is the minimum required level of complexity to run and render modern WEB safely
b) chromium is extravagantly over engineered and the actual amount of complexity and code needed to run and render modern WEB is actually much less
c) Ladybird is actually not targeting the same features but some "suitable" subset of features.
Or maybe the answer really is C thus making this a toy/hobby project?
One could of course then hope that the answer is b) but somehow I don't feel like it is.
Web Platform Tests (1) make it significantly easier to test your compliance with W3C standards. You don't have to reverse engineer what other engines are doing all the time.
The standards documents themselves have improved over time, and are relatively comprehensive at this point. Again, you don't have to reverse engineer what other engines are doing, the spec is relatively comprehensive.
Ladybird has chosen to not add a JIT compiler for JS and Wasm, reducing complexity on the JS engine. They're already reached (or exceeded) other JS engines on the ECMAScript Test Suite Test262 (2).
There's a big differential between the level of investment in Chromium and the other engines - in part because Chrome / Chromium are often doing R&D to build out new specifications, which is more work than implementing a completed specification. There's also a large amount of work that goes into security for all three major engines - which (for now) is less of a concern for Ladybird.
I'm confident that the Ladybird team will hit their goal of Summer 2026 for a first Alpha version on Linux and macOS. They'll cut a release with whatever they have at that point - it's already able to render a large swathe of the modern web, and continues to improve month-on-month.
(1) https://web-platform-tests.org/ (2) https://test262.fyi/
The thing that works in your favor is that Ladybird is very niche at this point, so unless some well-resourced adversary hates you specifically, it's unlikely that you'd be targeted.
https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
What are you trying to do? Are you embarrassed that you arrived at an end goal via a suboptimal sequence of steps, and are trying to present it in a way that conceals that fact? Is the auditor at the door? What's the end goal here?
Both of these features aren't very useful when they point at a "wip" or similar commit message.
By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.
As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possible to reference a random segment of memory (say, via an unchecked array index exploit) and then do whatever you want with it (exploit other bugs in the original C++ app). The only benefit is that access to the OS is isolated, but all the other exploits are still possible (and impossible in JVM/.NET).
Am I missing something?
We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit.
Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it.
If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-g...
Orion adding Windows support (getting WebKit running on Windows again) would be pretty good too.
Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...