Arcan: A browser for different webs

[Vinícius dos Santos Oliveira]

I always talked about Arcan as the "desktop service" that allows one
to have "widgets as capabilities". The IPC was designed by a seasoned
developer with a clear (but initially undocumented) threat model from
the start.

Under Arcan IPC, one may request a new "segment" which is Arcan
terminology for a new "channel"/actor-address, and pass the new
segment along to a new process. So using standard OS technologies
(e.g. Capsicum under FreeBSD, or seccomp on Linux), it's doable to
start a new sandboxed process that only communicates through a
delegated Arcan segment... and that would draw as a widget inside your
app. Plus the IPC is designed to work nicely with processes
distrusting each other.

Unfortunately the codebase is "too" portable and used to use lots of
OS abstractions that deviate from capabilities (e.g. it used shm_open
in the past because OpenBSD). Now we're in an interesting time because
one of the last anti-features that conflicted with capabilities was
finally removed/made-optional (the use of the syscall kill which takes
a forgeable name for a process):
https://codeberg.org/letoram/arcan/commit/8924bb237c0dfd0fabb765ee9e569b019fe21fb5

A few friends of mine managed to open an Arcan window inside a
completely isolated container to draw a window on the host and it
worked. So that's a milestone. Next one I want to see is a window
running not on a container, but on a Capsicum sandbox (which should be
the final checkbox for capabilities under a traditional/real-world
UNIX system).

Recently the main guy behind Arcan published yet another attempt at
explaining Arcan which some of you might find interesting as it
touches on several points across the history of the development of
www: https://arcan-fe.com/2026/01/26/arcan-explained-a-browser-for-different-webs/