4 ms·
Yeah it's more just defense in depth. The browser is already going to have a super optimized and battle-hardened TLS engine, so might as well use that IMHO. T
by qbasic_forever 6y ago
Yeah it's more just defense in depth. The browser is already going to have a super optimized and battle-hardened TLS engine, so might as well use that IMHO. Today we can reasonably assume process IPC is secure... but who knows what exploits will surface tomorrow.
It also opens up an interesting possibility where the tab process isn't on the same machine. That could be handy for power users, or even for interesting things like browser testing apps on different, remote devices.
- monocasa 6y agoI'm all about defense in depth, but for speculative security stuff like that I like to see a well thought out threat model where you actually protected against anything. Otherwise you have unbounded amounts of work (both developer human/cognitive and compute time) dedicated to security that isn't actually helping your users in a meaningful way. The issue with not trusting that the kernel can protect IPC like it's supposed to is that so many ways to get root are ultimately protected by that same IPC protection scheme. If you don't trust the kernel, in the general case you've already lost with any scheme like TLS that ultimately relies on the kernel provided primitives to do stuff like hide the secrets in the first place. You're also opening a new can of worms around boot strapping local certificate distribution to make TLS meaningful that bring you right back to the original problems.
- qbasic_forever 6y agoYep that's a great point, and really the security of TLS isn't so much algorithms and bits over the wire but all of the certs, processes, machinations etc. around generating and trusting them. There definitely would be a lot of headaches around building that chain of trust with dozens and hundreds of tab processes.