3 ms·

Unfortunately for everyone that cares about security, using Firefox (or Safari or old IE) is a colossal mistake since it's orders of magnitude easier to exploi

Unfortunately for everyone that cares about security, using Firefox (or Safari or old IE) is a colossal mistake since it's orders of magnitude easier to exploit (with almost no serious anti-exploitation mitigations) than Chrome. Spidermonkey in particular (Firefox's Javascript engine) is laughably bad when it comes to vulnerabilities. This is also the reason why the Servo browser that some folks think will be a lot more secure (due to Rust) is mostly smoke & mirrors. They're planning to keep using Spidermonkey there too!

om2 10y ago
Firefox is much less secure than other modern browsers. And Chrome is indeed very secure. But I think it's incorrect to say that it's "orders of magnitude" more secure than Safari. This hasn't been true since Safari introduced multiprocess and sandboxing. Safari and Edge are closer to Chrome in security level than they are to Firefox. That's why pwn2own doesn't even include Firefox in the competition any more but does include Safari and Edge.
- armitron 10y ago
  Agreed on Safari/Edge but note that I didn't use the words "very secure" to describe Chrome in isolation. How can something that gets publicly exploited year after year by _teenagers_ (1)(2) be called "very secure" ? The grim reality is that we never had a browser than can be called even remotely secure. Major factors for that are the implementation languages (C++ and C) and the vast attack surface. It's disheartening to see this trend continue. (1) http://www.tomsguide.com/us/pwn2own-browsers-2015,news-20680.html http://www.tomsguide.com/us/pwn2own-browsers-2015,news-20680... (2) http://blog.trendmicro.com/pwn2own-day-2-event-wrap/ http://blog.trendmicro.com/pwn2own-day-2-event-wrap/
  - pcwalton 10y ago
    > Major factors for that are the implementation languages (C++ and C) and the vast attack surface. It's disheartening to see this trend continue. You realize that there's only one browser which is starting to adopt alternative implementation languages, and it's not Chrome, right?
  - gcp 10y ago
    How can something that gets publicly exploited year after year by _teenagers_ (1)(2) be called "very secure" ? You're underestimating teenagers.
  - om2 10y ago
    I guess I was grading on a curve when I said "very secure".
pcwalton 10y ago
> Spidermonkey in particular (Firefox's Javascript engine) is laughably bad when it comes to vulnerabilities. This is the first I've heard this claim. Do you have data showing this? JS engines, from my point of view, regularly have all sorts of memory safety issues. No particular JS engine stands out relative to the others. > This is also the reason why the Servo browser that some folks think will be a lot more secure (due to Rust) is mostly smoke & mirrors. They're planning to keep using Spidermonkey there too! Smoke and mirrors? Servo has sandboxing, which is already implemented (and which I maintain). There's a night and day difference between that and an unsandboxed browser. The goal of Servo's architecture is to, first, achieve a best-in-class sandboxing story and then, afterward, to advance the state of the art by reducing attack surface. We aren't going to reduce the memory safety attack surface to zero. But it's very much feasible to reduce it so far down that attackers don't even look at layout/DOM/etc. code for memory safety issues the way they do today when searching for browser holes. The return on investment when looking for memory safety holes in memory-safe languages just isn't there.

om2 10y ago

Firefox is much less secure than other modern browsers. And Chrome is indeed very secure. But I think it's incorrect to say that it's "orders of magnitude" more secure than Safari. This hasn't been true since Safari introduced multiprocess and sandboxing. Safari and Edge are closer to Chrome in security level than they are to Firefox. That's why pwn2own doesn't even include Firefox in the competition any more but does include Safari and Edge.

armitron 10y ago
Agreed on Safari/Edge but note that I didn't use the words "very secure" to describe Chrome in isolation. How can something that gets publicly exploited year after year by _teenagers_ (1)(2) be called "very secure" ? The grim reality is that we never had a browser than can be called even remotely secure. Major factors for that are the implementation languages (C++ and C) and the vast attack surface. It's disheartening to see this trend continue. (1) http://www.tomsguide.com/us/pwn2own-browsers-2015,news-20680.html http://www.tomsguide.com/us/pwn2own-browsers-2015,news-20680... (2) http://blog.trendmicro.com/pwn2own-day-2-event-wrap/ http://blog.trendmicro.com/pwn2own-day-2-event-wrap/
- pcwalton 10y ago
  > Major factors for that are the implementation languages (C++ and C) and the vast attack surface. It's disheartening to see this trend continue. You realize that there's only one browser which is starting to adopt alternative implementation languages, and it's not Chrome, right?
- gcp 10y ago
  How can something that gets publicly exploited year after year by _teenagers_ (1)(2) be called "very secure" ? You're underestimating teenagers.
- om2 10y ago
  I guess I was grading on a curve when I said "very secure".

pcwalton 10y ago

> Spidermonkey in particular (Firefox's Javascript engine) is laughably bad when it comes to vulnerabilities. This is the first I've heard this claim. Do you have data showing this? JS engines, from my point of view, regularly have all sorts of memory safety issues. No particular JS engine stands out relative to the others. > This is also the reason why the Servo browser that some folks think will be a lot more secure (due to Rust) is mostly smoke & mirrors. They're planning to keep using Spidermonkey there too! Smoke and mirrors? Servo has sandboxing, which is already implemented (and which I maintain). There's a night and day difference between that and an unsandboxed browser. The goal of Servo's architecture is to, first, achieve a best-in-class sandboxing story and then, afterward, to advance the state of the art by reducing attack surface. We aren't going to reduce the memory safety attack surface to zero. But it's very much feasible to reduce it so far down that attackers don't even look at layout/DOM/etc. code for memory safety issues the way they do today when searching for browser holes. The return on investment when looking for memory safety holes in memory-safe languages just isn't there.