I also can't agree that it isn't related. If I tell you I'm wearing a green shirt, how can you know for sure if you or someone you trust hasn't verified it? You can't. It's the same with MSFT. But in the case of MSFT, it has been proven that they wear a lot of Hypercolor[1] stuff.
Is it good that MSFT is doing stuff to make things more secure? Sure. Do we still have to take it on faith that they are doing everything they can to protect their users? Yup.
I work in a small programming company and we do internal and external audits while maintaining compliancy with federal and state regulators as well as groups like ISO.
Sure, our work is closed source, but that doesn't automatically mean it hasn't been externally verified for a number of different things by a number of different organizations...
Yes, but we have to take your word for it.
Sure, it looks like its not leaking air. It has not dropped down to earth yet, and all the videos posted on their website looks to show it being fine. However, if I ever went there and depended on its security, I would demand more.
Whereas if the source is open, and you are a subject matter expert (yes, that's a big if), you can review the source yourself. You can decide for yourself whether the software has an NSA backdoor, an innocent flaw or whatever.
Yes, a lot of people, myself included, don't have the technical background to do this. But with open source we could, if we had the knowledge (which can be learned), without relying on potentially compromised authorities.
With closed source we simply can't. We have to trust the auditors and the government, which have been shown to be unreliable.
How many open source projects have most people audited for their own sense of satisfaction about its security promises?
Debian SSL bug lasted 2 years. Open source means little for security.
The argument I'm making is not that Windows is secure (because it isn't), but that Open Source isn't necessarily secure just because it's open source.
Open source is however possible to independent verify if it is secure. Closed source is not possible to verify as secure and must be taken solely on the word of the company who made it.
How many examples can you come up with? Was this specific bug being actively exploited when it was discovered?
A bug caused by prettying the code, which was secure from upstream, which is in an important, widely used, supposedly secure bit of code isn't a good enough example?
> Was this specific bug being actively exploited when it was discovered?
Many Linuxes used to ship with lots of services running. That lead to many rooted boxes being used to deliver spam. Open Source fixed the problem, but only after many millions of emails had been delivered.
Someone somewhere probably has a nice chart of all the Red Hat boxes in SKorea in the late 1990s early 2000s.
Again, this isn't to suggest that MS or Apple are more secure. For years anyone putting an MS server onto the Internet ran the risk of very quick exploitation.
It's a good example. Can you come up with more? Because, you know, it's just one instance of a problem. It says nothing on how pervasive it is.
> For years anyone putting an MS server onto the Internet ran the risk of very quick exploitation.
IIRC, there was a time when the average time between install and first invasion was in the 40 seconds range.
I am not a fan of FSF's tone here, they could be more diplomatic -- but saying "we appreciate your effort, but you fail" would have been more insulting. I think there are many places for closed source software, but core privacy software is not one of those places.
The encryption core (the critical pieces that either input or output plain text -- the places where the attack is more likely to succeed as opposed to the core of the algorithms), as well and the general platform should have the source code available (even if at a fee). That's not quite the FSF vision, but perhaps the powerful vision is needed (one can think of FSF's goals as a captivating utopian story that leads to more incremental improvements).