That worked great for OpenSSL didn't it? ;)
The "advantage" of proprietary code here was that Microsoft got to downplay them (surprise surprise, no scary logo made by Microsoft for them!), and that's how proprietary code owners deal with security issues in general - they try to hide that they exist to keep the illusion that the software is (more) secure.
Here's the first:
https://news.ycombinator.com/item?id=9445436
These are egregiously bad arguments you're making, involving people who you don't know but that, from my experience reading so many of your comments, I believe are operating many levels above your own comfort level with actual software security.
The trouble is, like me, you comment on HN all the time, and so, like me, you get a huge name recognition boost for these comments you make. People reasonably believe that you know what you're talking about when you "explain" to them how Apple and Microsoft handle vulnerabilities. But you don't, and so these misleading comments prey on their lack of information.
Maybe I painted with a too wide brush the "proprietary software teams pretending the vulnerabilities don't exist", but the "security through obscurity" expression didn't just come out of nowhere. Many proprietary software companies do try to hide or downplay their security holes when they happen - you can't seriously tell me you you're contesting that?
You'll notice that the recent TLS bulletins were the only ones to credit an internal finder. There's a reason for that, and it's not because MS people aren't finding vulns in their own software.
My issue is that the comment that roots this thread is, as you discreetly agree, totally uninformed, yet written in a tone suggesting direct knowledge of how vulnerabilities are handled at big software companies.
If you want to discuss the subtleties of internal vs. external reporters, patch timelines, prioritization, pre-disclosure, and things like that, I'm up for it, but not until there's clarity about what --- let's call it: --- "the HN community" --- does and does not know about this stuff.
I am fine with random commenters on HN talking about vuln disclosure without ever having reported a vulnerability or triaged a report. I don't think our having spent so much time with those things makes us special. I am less fine with people pretending to know things that they don't, or, to be as charitable as I can, writing comments that carelessly create that impression.
Microsoft has had 2 Heartbleed-level vulnerabilities in its Windows code so far, that were not just 2-3 years old but 10+ years old, leaving systems vulnerable to them for much longer. The "advantage" of proprietary code here was that Microsoft got to downplay them (surprise surprise, no scary logo made by Microsoft for them!), and that's how proprietary code owners deal with security issues in general - they try to hide that they exist to keep the illusion that the software is (more) secure.
Related to the other claim, I'm fairly certain that the NSA does get pre-disclosure of MS vulns via MAPP, but it's pretty obvious that this is a side effect of disclosure complexities and not a quid pro quo deal. China also gets the same pre-disclosure, or did, until they got caught leaking it. But they probably still do, one way or another.
I'm actually laughing out loud at the Apple Pay in the USG thing.
If you want to roll the discussion up to the original claim on this thread:
* Yes, closed-source vendors, Google included, do not as a rule announce severe flaws they find (or contract to find) in their own code. On the other hand, when we're talking about Google, Microsoft, and Apple: they are actually finding sophisticated flaws in their own product, which is something very few open source projects can credibly claim.
* Open source projects are not as a rule particularly awesome about handling disclosures either. See, for instance, AFNetworking.
* Nobody made logos for HTTP.sys (that I know of). On the other hand, HTTP.sys was a bigger deal in the industry than POODLE or pretty much any other vuln with a name besides Heartbleed, which, because it implicated a library used by lots of products, was particularly prevalent among Internet SAAS sites, and was easier to quietly exploit than an RCE, was a legitimately more important flaw. The idea that Microsoft gets a free pass for vulns is something you can only believe if your only contact with them is HN.
* There's no evidence Microsoft hid those vulnerabilities. They were there for 10+ years because nobody found them. In Microsoft's case, you can't reasonably claim that's because they weren't looking. Minesweeper gets more pentesting effort at Microsoft than most open source crypto projects.
I strongly prefer open source software to closed-source software, but I'm not unrealistic about how open source security works. See security tire fires such as: OpenSSL, Rails, PHP, Cryptocat, BIND --- each distinctive not just for having vulns but for the manner in which they've historically handled them.
I've noticed tptacek over the past few years that your comments have shifted from great general security advice to more defending "the security profession". Please consider this shift and whether it is helpful.
In my experience, the worst security offenders are either small businesses or big businesses whose core competency is not in tech. My friend managed to download 50,000 passwords from GreatestJournal.com because they left their MySQL server exposed to the Internet, with no password, and the open-source LiveJournal code stored passwords in plain text in the DB. He reported the vulnerability to them, and their response was to put a password on the MySQL server (and take it off the Internet a few days later), write a blog post saying "You may want to change your passwords if you reuse your GJ.com password on other sites", and then take down that blog post a couple days later.
By contrast, when I worked at Google, a security bug was a drop-everything P0 bug. I recall grabbing dinner at In'n'Out at 11:00 PM because a potential data leak was discovered at 6:00 and the culture is such that when a potential security bug is discovered, you drop what you're doing, assess the impact, fix it, and don't do anything else until you've done that. And I didn't work on a security team, just an infrastructure one responsible for google.com.
This has nothing to do with Microsoft. It is about a false assertion (i.e. OSS peer review leading to less bugs) made so fleetingly that the authors clearly expected it to be accepted by readers as a proven fact. It isn't proven. And I gave just one of countless examples why OSS peer review has proven itself to not necessarily work as one might naively expect it to.
Looks like it was indeed committed to OpenSSL about 2 1/2 years prior.