Hacker News new | past | comments | ask | show | jobs | submit login

I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue.

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

I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm not interested in making a judgment call on their initial choice - I totally get the decision, regardless.




> 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 scream "you cannot use this language safely!!!", now does it?

I would certainly argue for something like Rust instead if starting from scratch, though, but just because A is better than B doesn't make B unusable trash, either.


Well, that's not really a fair interpretation of my argument, I'd say.

My argument is:

* We have a production, widely used codebase

* This codebase is in C++

* This codebase has probably the most significant efforts to secure it of anything of its size, or at least it's in the top 5

* This codebase suffered enouguh critical vulnerabilities for users to be attacked in the wild

So let's be clear - Chrome suffers from thousands of memory safety vulnerabilities, but not many make it to ITW exploits. This case is special because users actually suffered because of it. It isn't fair to say they've had "one security issue", certainly, just one that's had major user impact.

I'm not judging C++ or the choice to use it. I am saying that this is an example of a very hardened system not being able to compensate for memory unsafety.


> not being able to compensate for memory unsafety.

This is a bit of a simplistic view tbh. They have managed to drive up costs for 0 days on the black market. They have introduced auto-updating browsers to get security patches to users quickly. They have managed to reduce the number of security exploits. This is a big feat and major progress.

They have compensated for memory unsafety quite effectively. Maybe not perfectly, but well enough.

Yes, memory safe languages are wonderful. I myself am a rustacean and LOVE to RIIR. But their efforts weren't in vain.

Should they start thinking about adopting a memory safe language like Rust or Wuffs? Definitely.


> This is a bit of a simplistic view tbh.

It's a very literal one.

I think I've been very open about what an accomplishment they've made, and how proud they should be to have kept Chrome users safe for all of these years.

It is exactly because their efforts to secure Chrome are so impressive that I think this event is interesting.

None of what I've said is about Rust or even a suggestion that they shouldn't keep doing what their doing. One ITW exploit in a lifetime of a product is a great track record.

It is merely interesting to observe when herculean efforts fall down.


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


Not by a long shot either. The current stable version of Chrome (72) came with 58 security fixes, including a dozen UAFs, albeit several of those are in third party dependencies.

https://chromereleases.googleblog.com/2019/01/stable-channel...


There was even another UAF just a few months ago. https://chromereleases.googleblog.com/2018/11/stable-channel...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: