Towards native security defenses for the web ecosystem
security.googleblog.com
security.googleblog.com
On the one hand, this looks way too complicated, and I predict web devs are going to be confused and getting this stuff subtly wrong for the next decade or more. CORS was bad enough, but this looks worse.
On the other hand, processors are completely broken and I genuinely don't see a better alternative.
I wish this was my experience with security teams. The teams I've worked with through the years are generally disconnected from any product teams and support a wide-ranging enterprise. So they simply don't have the resources or specific technical or product knowledge to do it. It would be awesome to have a security person on the team directly mitigate issues, understanding the product, and making everyone else more security knowledgeable. I've just never seen it happen though. But I digress.
I agree. These new sets of headers look useful and simple to get going, and even would be useful to deploy today. So it seems worth checking out!
Meanwhile not having programming languages is a disaster as I explained in my parent comment but did your brain process the added value that such a change would bring to the world?
"One just needs to fully sandbox the VM" this is easier said than done. I explained in another post why Apparmor/Selinux are not nearly as effective as the Chrome sandbox. As for V8, sure, you could port over many mitigations it has to graalVM and get it running in a similar sandbox. Feel free, I'd certainly support you doing so.
Sure, my brain processes the benefit of other languages just fine. I'm excited to see wasm come to the browser.
I'm excited to see wasm come to the browser. Yeh but it doesn't have native binding with the browser APIs nor does it have multilanguage interoperability, hence the added values of graalvm over wasm.
A) It's not a good idea. The Chrome sandbox is arguably a lot stronger than Apparmor/ Seccomp. A native program in Apparmor or SELinux can still make virtually arbitrary system calls, whereas an attacker who has compromised a Javascript renderer can not. Further, The attacker would have to own the renderer first, whereas you're talking about just giving native execution rights. Further than that, you can just Apparmor/seccomp chrome? So just go do that? I've done it myself.
B) The attacks described in the post have nothing to do with code execution on your system. They're talking about attacks like XSS, which would exist in any language that provides the ability to manipulate the DOM with strings - so, any of the ones that would be useful.
In a container sandbox platform, you could still define the permissions that must be granted for a site. Like, this program wants to access your camera, should you let it? Or, it wants to access a directory. That isn't much different than a browser today.