121–130 of 377 posts
Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
I gave Firefox an honest go, but some web apps just don't work 100% in it. Chrome does not have this issue. Most of us drive cars filled with fuel from evil oil companies, why do we all drive cars?
Chrome does have reasonable alternatives.
Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
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.
Earlier quoted context omitted.
A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another la…
It doesn't even have to be memory safe, just less memory accident prone. D for example would have been an interesting choice (and I think it was usable back then).
D has some interesting bits, but it did a lot of head-scratching stuff too. It seemed really confused about what target it was going after, like some middle ground between C#/Java & C/C++ that really doesn't seem to exist.
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…
Earlier quoted context omitted.
A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another la…
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.
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.
Earlier quoted context omitted.
A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another la…
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.
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.
Half of it is vulnerability vs exploit in eli5 style, and then the rest is just mentioning FileReader in passing.
Earlier quoted context omitted.
No codebase will ever be fully free of security bugs, but having 7 million lines of code definitely doesn't help.
The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many millions of dollars, and we don't know what it is. Can we reasonably expect that price to be lower with language X? For many reasons, I would argue 'yes'.
If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either.
But safety is rarely the exclusive factor in play, now is it? Things like memory usage efficiency & performance also play large roles here.
Earlier quoted context omitted.
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…
The number of people required was a function of the "this complex" qualifier. I can write a safe C++ app on my own. I can't write Chrome on my own.
But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".
This is a blog post that seems to just be reporting on this tweet: https://twitter.com/justinschuh/status/1103087046661267456 which in turn is referencing this new release from this past Friday: https://chromereleases.googleblog.com/2019/03/stable-channel... which seems to have been motivated by "CVE-2019-5786: Use-after-free in FileReader. Reported by Clement Lecigne of Google's Threat Analysis Group on 2019-02-27".…
From the code referenced, it seems like this might be the commit that fixes this issue: https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0...