I don't think this is so self-evidently awful. There are a number of big open-source projects in this sort of position, like git, TeX, linux, GHC.
What is special about browsers that we need multiple competing implementations of the standard?
> What is special about browsers
Nothing. We need multiple implementations of all software that is relied upon for anything remotely important. It still amazes me that so many businesses critically depend on something that is only available from one source. Without a second source[2], the business lives or dies at the whim of the company they depend on.
[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....
HTML is supposed to be an actual standard for interchange of hypertext.
Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.
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?
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.)
The FUD is strong...
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?
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.
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.
I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.
Mercurial has a more sane way of referring to commits and traversing the history. They now also have different kinds of branching models. You can even maintain multiple checkouts of a repo using a single clone which is great and saves me from having to checkout branches when I want to work on another feature. (Imagine checking out 3.5 mn files each time you wanted to change branches).
In, my opinion, Mercurial scales better but suffers from the unintuitive names and lack of enough people talking about it.
Then you live in a very small bubble.
What could happen with Chrome if they were the only ones on the market, I wonder.
- Play Store website threw you out if you were using Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=1131601
- Gmail delivered an inferior mobile version to Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=668275
- Actually, Google fucks with Firefox on Android all the time https://bugzilla.mozilla.org/show_bug.cgi?id=668288
- Inbox is still Chrome only
- Youtube refused to serve webm to Firefox for a while | https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
Is that enough for now?
Google is no better than old Microsoft/IE team often. But hey, since you get a shiny browser that implements non standard things, it's okay, right?
Even with the NaCL thing I was able to find and implementation [1] of it that was under a open source license when I was trying to find a NaCl spec. NaCl existed because webassembly didn't, Google wanted other browsers to implement it.
Bugs happens, Technologies don't get adopted; Google is made of people and mistakes happen. Your disingenuous crying of anti-competitive wolf dilutes real claims of anti-competition.
[1] - https://chromium.googlesource.com/native_client/src/native_c...
The problem with this is that Google solicited feedback on Pepper on the plugin-futures mailing list early on. The other browser vendors correctly pointed out that Pepper was unnecessary. Google completely ignored the feedback and did it anyway. Years later, it is obvious that the unanimous consensus of the other browser vendors was right. PNaCl is dead, and Web Assembly uses the Web APIs instead of Pepper, which is precisely what everyone else had advocated early on.
The lack of adoption of PNaCl is Google's problem. As is obvious with Web Assembly, nobody has any problem with adding a portable low-level IR to the browser. The biggest problem was the insistence on Pepper. If they had listened to feedback, maybe we would have had Web Assembly much sooner.
Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.
I hate microsoft but I still don't give them flak for not releasing Linux versions of office and excel. They are allowed to not do that. Where it steps into anti-competitive is when they start breaking other's people things or maliciously manipulating standards. Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
It sure is when combined with Google releasing NaCl-based software, such as Google Earth.
> Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Not with Dart, which followed a very similar trajectory (see my other comments). Not with -webkit prefixes. Etc. etc.
> Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
I was unaware even of the existence of a web based version of Earth. The last time I used Google earth was as a desktop client. That was back when I worked in the Air Force Weather Wing almost a year ago. Have they done away with the desktop client?
Starting over with whether or not this is anticompetitive; who are they repressing by giving away free software that runs on other free software? Does this software need to be used?
This all seems to hinge around this part of what you are saying:
> When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
The option to lose users here is huge. How is this different than microsoft making excel and only supporting it on windows? I choose not to use excel at least in part because it doesn't run on any platform I care to use. I feel I should clarify here, I don't condone this obnoxious behavior from microsoft or Google. I think it is wrong from the stance that all software should inter-operate smoothly and be open source, but it doesn't seem illegal or even unethical.
The answer for a users to both Earth and excel seems to be to use some other competing software. For mapping software something like openstreetmap or even some other Google software like Google maps (or even a pay for solution). For spreadsheets I use libreoffice.
Even if this is anti-competitive it seems so minor that it dilutes the meaning of the term. Lumping this in with things like the Dr DOS fiasco just doesn't seem right. For reference in the Dr DOS times there was a DOS competitor to microsoft's DOS. Dr DOS was a relatively bug free DOS and it worked fine with windows until the 3.0 release (I think). Until this specific version/patch started intermittently causing windows to not run if Dr DOS was detected even though it was advertised as working. The end result was Dr DOS being run out of business because it looked like a bug in Dr DOS and sometime ms even claimed such. The Dr DOS team was very overtly fucked by ms.
Nothing about most of the things brought up in this thread seems overt. No money is being paid for web browsers or this mapping software. Having users takes significant effort to monetize. It seems detached from web standards in any direct way (I agree it indirectly relates to webassembly, but not in a way that seems legally relevant). Most of it seems like engineers being engineers and fixing their own little slice of the world and hoping everyone works with their stuff because they don't want to change. Shortsighted and imperfect just like most humans.
Thank you for taking the time to explain (and listen) to me in a rational and level headed way. I won't be checking my messages here again until I start another build or boring process tomorrow. Have an upvote.
http://i.imgur.com/FDM5DQ9.png
k
You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
>when they start breaking other's people things
They are! They actually are! These bugs I listed aren't "bad engineering". They're "When UserAgent is detected send shitty version". In what world is that not deliberately breaking people's things? Users access Inbox on Firefox, see that their friends on chrome that sent him the link can actually access it, they're not going to blame Google, they're going to say that Firefox is a piece of crap and dump it.
> maliciously manipulating standards.
chrome.* javascript APIs
Bluetooth API
FileSystem API
-webkit CSS prefixes
not manipulating standards, just implementing half assed things on their side of things and leaving the blame on other browser manufacturers when they don't implement them.
>They didn't force it on anyone else.
"Company with 50% of desktop browser share and 80% of mobile browser share only unilaterally did something non standard and screwed everyone over. But that's not forcing everyone's hand I swear, they're only the biggest players on the market."
k
You know, when pcwalton keeps proving you wrong over and over again, you might want to rethink your opinions. It's not as if he knew what he's talking about or anything, right? :>
If you must pick an example of them breaking stuff, please pick one that they didn't already apologize and fix.
> http://i.imgur.com/FDM5DQ9.png
My mistake on confusing google earth with google maps, that is an important point that issue. It does suck that doesn't work on firefox, but no one is forcing any one to do anything. Its not like you paid for any of this, or there is some law that says companies have to give stuff away for free.
> You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
I am not reversing my stance or saying anything self contradictory. I am attempting to define nuanced boundaries around some who would rather bludgeon things into a simple categories whether or not it fits. So far all I hear are complaints about company giving away huge amounts of value for free, but isn't doing it the way you (or I) want.
I never said Google was paragon of anything and I admitted they could do better (I really do wish they would do better), the only line I am taking is that their behavior is not "anti-competitive", which is not a high bar. Which has not been disproved or this case even rationally approached. I am open to having my mind changed, but I would need well thought out discourse and evidence to change it.
If you respond again so thoughtlessly or with such poor grammar I will not be responding again.
...Okay then ? ¯\_(ツ)_/¯
It's not as if we were having a meaningful discussion anyways, each of us camping on his positions.
You... Clearly just want me to agree with you without applying any critical thought of my own. You implicitly my experience, personal and professional, while presuming your stance to be the only valid one on a subjective topic. That is not how you have a constructive conversation, goodbye.