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.
It doesn't seem so bad to me. Fetch Metadata will be handled by your framework of choice (Rails, Django, etc) & COOP is a single header that can be deployed by the security team in your app or at the edge. TrustedTypes are the only thing that will really cause developer headache I think.
> ... & COOP is a single header that can be deployed by the security team ...
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!
The opener policy is something that I've wanted for a while. I remember looking for such a header value and only finding the debates about how to implement it.
These changes are positive, but I must say I find it hard to trust anything Google does while the impossible-to-disable and undisclosed advertising ID backdoor to DoubleClick exists in Chrome (alongside the most weak cookie policies in the entire industry). Part of me thinks they're strengthening security while deliberately leaving holes for their advertising arms to exploit.
If they would just use a container sandbox and AppArmor/Seccomp/etc we wouldn't be stuck on this JavaScript monster we've created that still allows companies to spy on every mouse movement and track you around the web by default, but now requires 100s of unvetted JavaScript modules and dependencies for a framework to do the most simple tasks that should be included by default in HTML.
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.
> 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.
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.
If they used such a sandboxing technology, could they bring true support for other programming languages than js?
(webassembly has no seamless support of browser APIs and no seamless js interop)
I strongly think that bringing graalVM polyglotism to browsers is one of the biggest breakthroughs awaiting browsers this century!
It would bring the pleasure and expressiveness of modern programming languages, bring more performance and bring an insanely big advantages, order of magnitude too big for our homo sapiens brains to realize: bring the other programming ecosystems such as the Java one, as such bring hundreds of billions of dollars of existing human resources AKA the best open source libraries in the world, solving any niche problem at will.
Explaining why it was and why it would still be a disaster would bring actual intellectual value to your comment.
The old plugin interface was not at all integrated with browser APIs nor interoperable with js like ts is.
The security issues are nothing undoable, one just need to fully sandbox the VM, V8 has nothing special that couldn't be added to graalVM.
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?
I didn't think it needed to be stated why. It was horrible from a security perspective. The world has completely changed in terms of end user security since Java went from default-run to click-by-default to denied.
"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 explained in another post why Apparmor/Selinux are not nearly as effective as the Chrome sandbox.
Interesting, where can I find such post?
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.
Yes, not only would it allow support for other programming languages but it would be orders of magnitude faster than JavaScript. I agree with pretty much everything you said.
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.