
Towards native security defenses for the web ecosystem - edmorley
https://security.googleblog.com/2020/07/towards-native-security-defenses-for.html
======
ohazi
I'm conflicted.

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.

~~~
arkadiyt
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.

~~~
pseudoramble
> ... & 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!

------
nitwit005
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.

------
nine_k
Related earlier post / discussion from Mozilla side:
[https://news.ycombinator.com/item?id=23908137](https://news.ycombinator.com/item?id=23908137)
("Safely Reviving Shared Memory").

------
0xy
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.

------
fcatus
google talking about privacy and protecting the internet community? yah
sure...

~~~
yjftsjthsd-h
Well they _do_ , just for a threat model that's rooted in Google's worldview.

------
techntoke
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.

~~~
The_rationalist
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.

~~~
staticassertion
Java ran in the browser less than 5 years ago and it was a disaster.

~~~
The_rationalist
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?

~~~
staticassertion
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.

~~~
The_rationalist
_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.

