Serious Chrome zero-day

Post by scrollaway » Thu, Mar 07, 2019, 5:25 AM UTC

qrbLPHiKpiux wrote: post #92

mda wrote: post #62

Earlier quoted context omitted.

It is fast, responsive, has much better security history and architecture than all others, super convenient if you have multiple computers. I have absolutely no problems with Chrome, I already trusted my information with Google, so I always stay signed in as well, never had any issues.

Caveat: if something’s “free,” you’re the product. Google wants to pull as much metadata from you as possible. I don’t trust anyone who gives me something for free. I therefore limit how I use it.

Post by magila » Thu, Mar 07, 2019, 5:30 AM UTC

tedunangst wrote: post #153

kllrnohj wrote: post #134

Earlier quoted context omitted.

> What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all…

This is not the first chrome security issue in over a decade.

Post by zetafunction » Thu, Mar 07, 2019, 6:05 AM UTC

stcredzero wrote: post #88

staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. Do they distrust their own coders to the same degree they distrust the processes they sandbox? I suspect the answer to this is "no" but I would like to hear from someone who actually codes there. I think the truth is more like this: You can write safe C++, just like you can keep a secret. It's just that the odds that you…

Post by duneroadrunner » Thu, Mar 07, 2019, 6:30 AM UTC

zrm wrote: post #223

staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. And so, as they say, we should all be using Rust. But allow me to explain why I don't yet. Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole…

Post by gsich » Thu, Mar 07, 2019, 6:42 AM UTC

zetafunction wrote: post #234

staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.