Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.
When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.
Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.
OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)
> everyone now has an incentive to refactor it into something nice.
My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.
Do you honestly think Google would be likely to collaborate on that?
Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.
> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?
Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
See: the Linux kernel.
The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!
> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
No, the organization that didn't like the change would fork the project. This already happened with WebKit!
> See: the Linux kernel.
Linux gets forked over and over and over again, every time some organization wants to ship a device running it.
Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)
It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)
It gives the incentive to create a black market.
Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.
What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?
Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.
Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.
For the old IE, Firefox happened (and other as well).
My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?
IE did not force anyone doing anything, even if it had a de facto monopoly, therefore Firefox was created, because people chose to.
In this scenario I'm discussing it would not be allowed to create a Firefox, because everyone was forced to use Chrome, hence a black market is created.
I would not, however, wish it to be the only thing available.
The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening.
The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.
The FUD is strong...
As far as making money off of their own software written in Rust, that advantage is actually stronger if they convince everyone else Rust is stupid and not worth their time.
If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument?
> rationalize it with some technical bullshit.
If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}.
Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)
They don't have to be free of security vulnerabilities either, but it would be very nice. What's your point?
I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.
A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
No, because:
1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.
2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.
3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.
> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?