Memory safety is a critical property for web browsers: all Chrome exploits caught in the wild (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. However, there is a catch: V8 vulnerabilities are rarely “classic” memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which in turn allow for the construction of unusually powerful and reliable exploits. Furthermore, these bugs are unlikely to be mitigated by memory safe languages or upcoming hardware-assisted security features such as MTE or CFI in isolation. We propose addressing this problem with a lightweight, in-process sandbox, called V8 Sandbox. The sandbox limits the impact of typical V8 vulnerabilities by restricting the code executed by V8 to a subset of the process’ virtual address space (“the sandbox”), thereby isolating it from the rest of the process. This works purely in software by effectively converting regular full pointers either into offsets from the base of the sandbox or into indices into out-of-sandbox pointer tables. In principle, these mechanisms are very similar to the userland/kernel separation used by modern operating systems (e.g. the unix file descriptor table).