6 ms·

Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pre

Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.

staticassertion 8y ago
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.
- kllrnohj 8y ago
  > 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.
  - staticassertion 8y ago
    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.
    - est31 8y ago
      > 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.
      - staticassertion 8y ago
        > 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.
  - tedunangst 8y ago
    This is not the first chrome security issue in over a decade.
    - tomjakubowski 8y ago
      There was even another UAF just a few months ago. https://chromereleases.googleblog.com/2018/11/stable-channel-update-for-desktop_19.html?m=1 https://chromereleases.googleblog.com/2018/11/stable-channel...
    - magila 8y ago
      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-update-for-desktop.html https://chromereleases.googleblog.com/2019/01/stable-channel...
naikrovek 8y ago
That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust.
- steveklabnik 8y ago
  > Rust has unsafe all over the place This does not match my experience nor numbers I’ve seen. What leads you to say this? (Also, other than LLVM, Rust is written in Rust. And when cranelift lands, you could remove that too.)
  - deleted 8y ago
    [deleted]
- kllrnohj 8y ago
  > Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.
  - pjmlp 8y ago
    Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.
    - deleted 8y ago
      [deleted]
    - 8y ago
OpenBSD-supreme 8y ago
Ada/SPARK would be an even better choice than rust.
kerng 8y ago
C++ is a write only language. Too many complex features that are used in ways that only the author of the code understands at the time of writing - or thinks of understanding at the time of writing even.
pjmlp 8y ago
I wonder what are the huge downsides of Modula-2, Ada, Delphi, ....

staticassertion 8y ago

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.

kllrnohj 8y ago
> 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.
- staticassertion 8y ago
  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.
  - est31 8y ago
    > 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.
    - staticassertion 8y ago
      > 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.
- tedunangst 8y ago
  This is not the first chrome security issue in over a decade.
  - tomjakubowski 8y ago
    There was even another UAF just a few months ago. https://chromereleases.googleblog.com/2018/11/stable-channel-update-for-desktop_19.html?m=1 https://chromereleases.googleblog.com/2018/11/stable-channel...
  - magila 8y ago
    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-update-for-desktop.html https://chromereleases.googleblog.com/2019/01/stable-channel...

naikrovek 8y ago

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust.

steveklabnik 8y ago
> Rust has unsafe all over the place This does not match my experience nor numbers I’ve seen. What leads you to say this? (Also, other than LLVM, Rust is written in Rust. And when cranelift lands, you could remove that too.)
- deleted 8y ago
  [deleted]
kllrnohj 8y ago
> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.
- pjmlp 8y ago
  Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.
  - deleted 8y ago
    [deleted]
  - 8y ago

OpenBSD-supreme 8y ago

Ada/SPARK would be an even better choice than rust.

kerng 8y ago

C++ is a write only language. Too many complex features that are used in ways that only the author of the code understands at the time of writing - or thinks of understanding at the time of writing even.

pjmlp 8y ago

I wonder what are the huge downsides of Modula-2, Ada, Delphi, ....