Gosub Browser Progress, pt50
These last weeks were primarily on code and comment cleanup. Since the engine keeps on growing (especially with the three big merges lately), we need to make sure that things are not only working properly, but also that we keep understanding the codebase. A browser is a large project consisting of many technically detailed components, ranging from GPU textures to seccomp to tokenizing and byte streaming, and everything in between. Being able to grasp the whole thing is not a given, and it becomes less so the larger the project gets. So a deep dive into the codebase once in a while is good practice, especially into the parts we haven't touched for a long time (like the html5 parser).
Besides this, I've done a lot of work on setting up a proof-of-concept for the multi-process setup of the engine. Here we tried to tie all the parts together (separate render processes, IPC and shared memory, a separate fork-server, decoders, and much more), in such a way that we get on par security-wise with the other four engines (chromium, firefox, ladybird and servo).
Yes, much was planned and generated by LLMs, and no, it's not a vibe coded process. Pretty much each line was inspected, reviewed and documented in a separate guide, to make sure that A) whatever it needs to do, it actually does, and B) we understand the implications.
For instance, we sometimes need to pass a (socket) file descriptor to another process so it can communicate with the main broker process. There are various ways to do that, most of them insecure. The way we do it is fork/exec, with a pre-exec step that clears CLOEXEC on the file descriptor we need. Not only do we test and verify this, we also dive into the reasoning behind it. Why not an on-disk socket? Its path sits in the filesystem for anyone with access to reach. Why not an abstract local socket? No permission bits at all, so any process in the same network namespace can connect. Why not SCM_RIGHTS? Because you need a channel before you can send a channel over it, which is exactly the gap we are bootstrapping here.
The reasoning for working this way is simple: we do not need (or want) to invent the same wheel over again. There are many proven technologies we can use that other browser engines use as well (and not only browser engines, other pieces of software too). From there we can figure out where we can make things more strict (and why other engines cannot), or where we can relieve the security tension a bit without any compromises.
In the end, it's not about who writes the code, it's about us understanding it. And I think we can.