There is no stable sandboxed browser protecting against kernel vulnerabilities on any platform that I know of prior to Chrome. That's the very definition of pioneering. Do you have an example of prior art? There may be sandboxing mechanisms in various kernels, but that's not what browser users care about.

As for the other points:

* "seccomp-nonbpf" is a vastly more limited mechanism than seccomp-bfp, and inappropriate for Chrome use-case. http://en.wikipedia.org/wiki/Seccomp. seccomp-bfp is pioneering in Linux kernel space, even if, ironically, the team might not have wanted to spend their time there. See below.

* Popular consumer distribution of Linux doesn't have SELinux enabled by default. https://wiki.ubuntu.com/SELinux. "SELinux can be enabled in Ubuntu by installing the "selinux" meta-package". In my bubble we everyone uses Ubuntu on desktop, apologies to other distributions vying for the title of "popular consumer Linux distribution".

* Not sure why we are talking about security mechanisms on non-Linux kernels. Chrome is a browser, the team's job is not to innovate in the kernel space. http://www.chromium.org/developers/design-documents/sandbox. "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".

if you give enough details you'll always find a way to work around words. For example if i ship a copy of webkit with my ui on top with a sandbox I'll pioneer that. Or a shell. Or a text editor. Or whatever you want. A blue wheel of 29.0349in on a bike. etc.

I'm not sure why I'm even replying sometimes.

> Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)

You're quite confused. SELinux, AppArmor, SMACK, etc. do not overlap with seccomp-bpf which exists to protect the kernel itself. Chromium has a working sandbox with or without seccomp-bpf based on a chroot, namespaces and IPC protocols. It needs seccomp to mitigate kernel vulnerabilities, which are not at all uncommon.

they actually do the control in a very similar way. its the model of how the control is decided that differs. in other words, they're all blocking syscalls depending on the arguments/syscall name/etc. LSMs and seccomp-bpf alike.

So no, I'm not confused :)

What comex meant is Chrome pioneered the use of seccomp-bpf. And indeed, Chrome is by far the application using seccomp-bpf in the most advanced way.