> Why should an application developer implement a sandbox?
Because they are the ones who understand the necessary capabilities of their program and the ones who have access to the source code...
> That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail.
Actually it's a far better sandbox when built into the program. And it doesn't leave users relying on installing arcane operating systems or becoming technically savvy.
> It is also untrustworthy and insecure, since after all you don't trust the application.
No, trusting the application is implicit since it's installed by the user. The sandbox exists to protect against a compromised application.
I think this is the wrong attitude. No one is better suited to implement a sandbox than the developer of the application. The fact that most developers are not trained to do so is just a reflection of our field's terrible progress re: education devs on secure app dev.
Leaving this to the user leaves the vast majority of users unsafe. This is an unacceptable state.
Your argument seems to be that because there are multiple ways to exploit people that closing any of those methods is not useful. I shouldn't have to explain why this is not a meaningful argument.
What I will say is that in many cases an attacker is far more capable of MITM than they are of posting forum comments, or otherwise convincing you to click a link. A phishing campaign is noisy - you are often alerting many parties that you're malicious. MITM within a network is much stealthier and you don't have to rely on users clicking on anything.
Really, they're just completely different attacks and the existence of one has no bearing on the other. TLS on every page would close off real attacks and, if it forced attackers to use noisy methods like phishing, that's a huge win.
The "premature optimization is the root of all evil" thing is totally blown out of proportion. I think what they're saying is don't use that quote as a reason to write garbage slow code.
An attacker needs the ability to compute on your local machine. Javascript is the way to do that in a browser.
With just CSS this should be impossible/ very unlikely. I guess it is probably technically possible, but I do not expect to see exploits using just CSS.
I work for a company with a massive rust codebase. Rust is very much about building production code.
What is 'good production code' ?
* Few errors
* Readable, well documented
* Testable, has tests, has testing tools like quickcheck, fuzzing, etc
* Meets performance constraints
Rust hits those better than any language I've used. The downside is, oh gosh, you'll have to actually learn a programming language that isn't just another variation of the ones you learned in school.
Yep, it's disabled by default. It is a great indicator of the forward thinking work they do, though. And from a corp perspective we can push out policies to enable site isolation for high risk websites (SSO).
"The only interesting thing" is a bit disparaging haha that's kind of a big deal. It means that third party iframes, as one example, run in a separate process. It breaks the case where I am evil.com, and you are okta.com, and there is a way for me to leak data within a process (or exploit the process), I can read okta.com's data.
With site isolation is this made considerably more difficult.
My point with site isolation was more their continued effort to push interesting, compelling security improvements. Currently, from a corp perspective, enabling site isolation for internal high security websites (SSO pages etc) is possible with GPO and a big win imo.
Please don't take it the wrong way, I think Firefox is awesome too :)
Vulnerability counting is never a metric for security when comparing counts across products.
It's very helpful for counting within a product.
One simple example - A and B are browsers. A has a bounty program that they invest millions into, B does not.
A gets 100 vulnerability reports a month, B gets 5.
Is B safer?
No.
However, let's say we just look at A. It gets 100 a month, and then a new feature is added - suddenly it's 200 a month, and the vulns tend to be in the new codebase. That's interesting information for A - it has nothing to do with B.
What I will say is that Edge and Firefox are doing an excellent job - I'm really impressed. Chrome is still the safest browser today, in my opinion.
Site isolation, which was released recently, is a really great example of how far ahead they are - site isolation is at least 3, maybe 4 years in the making. That's serious work.
They have had an excellent bounty program. They have project 0 doing advanced offensive research, much of which has been relevant to browsers.
They fuzz a ton and have managed to solicit others to do the same (not that other browsers don't/ haven't).
Their sandbox is incredible and constantly evolving. They basically invented seccomp v2 just to improve their sandboxing stature on linux. They implemented 'forceaslr' before EMET was even a thing to help prevent info leaks from third party libs.
Their new kernel32.dll unloading mitigation is awesome, and as far as I know the first instance of such a thing.
I could really go on and on, I'm sure - they have taken incredible proactive measures and they're just getting better at it.
We can see similar growth in Edge, which has had a sandbox for years. Firefox has more recently gotten a sandbox and the move to rust is encouraging.
But... yeah, in my opinion, Chrome takes the cake.
Because they are the ones who understand the necessary capabilities of their program and the ones who have access to the source code...
> That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail.
Actually it's a far better sandbox when built into the program. And it doesn't leave users relying on installing arcane operating systems or becoming technically savvy.
> It is also untrustworthy and insecure, since after all you don't trust the application.
No, trusting the application is implicit since it's installed by the user. The sandbox exists to protect against a compromised application.