Google in 2008: A new approach to browser security: the Chrome Sandbox
Google now: Sandboxing is expensive…Sandboxing doesn’t eliminate vulnerabilities from the code.
I wrote about the death of the sandbox:
securityweek.com/cost-sandboxin
9
60
146
Conversation
This Tweet was deleted by the Tweet author. Learn more
This is the correct explanation—I know firsthand—and I would add to the list of reasons the very different architectures of the systems themselves. So yeah, there's no big strategic change. It's just a case of two different orgs doing their own thing, as is typical at Google.
1
1
7
Do you think that those divergent styles/architectures end up being a net-positive or net-negative for Google?
1
1
Android and Chrome are two very different systems, and what works for one doesn't necessarily work for the other (at least not without ground up redesign). So, I think it's healthy for each to pursue an approach that plays to their own unique strengths and constraints.
1
4
Case in point, Android's zygote design makes processes significantly more expensive than on other systems. Since processes are a core sandboxing primitive, Jeff is right to note that expense and favor alternative security mechanisms. But it's a different story on other systems.
2
1
2
Managed app processes are expensive due to the high level language runtime and libraries.
It isn't because of the zygote spawning model. That makes it cheaper, not more expensive. If you use exec-based spawning, these managed app processes become significantly more expensive.
1
1
Android does have lightweight processes without the high-level language runtime for Java/Kotlin.
Many processes are managed app processes, but there are also many lightweight processes. Apps can use lighter processes. OS doesn't mandate that you only use Java/Kotlin processes.
1
1
Chromium uses an isolatedProcess service for each renderer sandbox and those are managed app processes.
A different approach could have been used. It's entirely possible to spawn lightweight processes sandboxed with a strict seccomp-bpf policy rather than primarily via SELinux.
An API could have been made for spawning non-managed isolatedProcess processes too.
Chromium is almost entirely C++ and has JIT compilation, GC, etc. itself. So yeah, it's wasteful to have a whole separate large, managed language runtime for each process. Not the only option.
2
1
If you're sandboxing code that's written primarily in Java/Kotlin, isolatedProcess isn't wasteful.
Chromium is using it as a sandbox for C++ and Chromium's own managed language runtime. Similarly wouldn't want to have that Chromium runtime in your processes if not being used.
1