C’mon. Ability to read the cache is obviously a much much lower threat than the ability to read the browser processes’ memory – the browser doesn’t cache your G

C’mon. Ability to read the cache is obviously a much much lower threat than the ability to read the browser processes’ memory – the browser doesn’t cache your GMail password. Also let’s stop here and admire just how far you’ve shifted the goal posts: we’ve gone from “memory isolation isn’t a security measure it’s actually just for reliability” to “ok sure it’s obviously a security critical measure, but check out this boneheaded RMS rant and also what about the lower threat value data that gets cached, what about that. And do we even need security or can we just go back to the 1980s with our Amigas when everything was cool and advanced persistent threats didn’t exist, man”. Pick a coherent point you’re trying to argue and some kind of intelligible threat model, at least. If we’re concerned about leaking filesystem data, there’s more aggressive sandboxing measures which several OSes employ, but they even more strongly rely on memory isolation, not less. The point, which you seem to have conceded several posts ago, remains: Memory isolation is a security measure, not just or even primarily a reliability issue. Also you don’t seem to understand what you’re trying to talk about, because: > and even read the memory of any of your processes through /proc/$PID/maps This requires root permissions (or for you to have explicitly changed /proc/sys/kernel/yama/ptrace_scope to a non-default value to allow processes to PTRACE_ATTACH to arbitrary non-child processes, which you shouldn’t do on a general purpose internet-facing machine unless you are a clinically insane person) for the obvious reason that this would be incredibly dangerous otherwise. Proving once again my entire point: Memory isolation is a security measure.