From the article: "Proprietary security software is an oxymoron -- if the user is not fundamentally in control of the software, the user has no security."
I could not agree more.
I could not agree more.
If you give everyone 100% control over every interface - this will drive the world crazy. How much control do you have on your house lock - do you take it apart everyday? How much control do you have on temperature regulation in your fridge, except for temperature dial?
People in computing must realize that a computer is just another interface for a user. For a programmer, I agree with you. But if I made cupcakes for a living, I'd want control over my oven, not my computer. As a programmer though, I trust that my oven company did their job and eat food out of it everyday.
No, but I can hire any locksmith of my choosing to look at it.
The point isn't that end-users are in control of it, but that end-users can hire experts to adjust it if needed. Giving a manufacturer complete aftermarket control of their product is entirely different.
The difference comes when you want to customize its behavior--in the open source version, you could five until the code yourself or, more likely, hire somebody to look into it for you. Similarly, if you were very worried about security, you could run an independent audit of the code yourself. Neither of these options exists for a proprietary product.
Basically, you're arguing against a straw man. Nobody is suggesting giving the user more options in the interface. Rather, the suggestion is to give the user access to the source code in case they want something modified.
The "fundamental control" in question is about who gets to see and use the source code, not about what the average user can do from a GUI.
What does that have to do with whether the unmodified one must means user has no security?
All you said can mean you can be more sure that open source code is secure. But it does in no way proof that "proprietary security software mean no security at all (EDIT: better be 'proprietary security software mean user has no security')".
Similarly, if you were very worried about security, you could run an independent audit of the code yourself. Neither of these options exists for a proprietary product.
I actually have taken apart the locking mechanism once to repair it. It got stuck, the door wouldn't open, so I fixed it. I didn't take out the barrel or dig too deep in, but I didn't need to. If I hadn't been technically competent to do that, I would have been able to hire someone else to do it for me.
What FSF is debating is "fundamental" and full control of inner workings of the software, which is what I find a bit narrow.
To me, the essence of that quote is that any sane security model must include the vendor as a threat, but when I do not have control over my own hardware and software, I have little to no ability to respond to that threat. Moreover, without access to source code, I have little to no ability to audit my own security. Fundamentally, I do not believe in the idea that security can reasonably exist without auditability.
Or anyone who gets access to the vendor's database.
If the vendor is in control, you aren't secure.
Open-source and closed-source software really isn't all that much different for users. All the differences require you to become a professional in the field, or a subset of the field before they mean anything.
Can you say "I would like to keep using Exchange, but I do not trust Microsoft, so I will switch to another vendor"?
PS: this has to do both with open source and open formats as well.
Security is one concern of many. The overriding one being business value. Using Exchange as an example, it would be difficult for me to come up with something that matches its value. I don't, however, trust it. As an aside, I trust Gmail even less, because at least Exchange runs in an environment I control.
And therein lies the solution. Defence in depth. It's a process, and should not rely on any single product. Open- or closed-source.
I might choose to protect myself against external, internal and vendor attacks (unintentional as well as malicious) by installing a network firewall, a proxy service, and an application firewall. I might then deploy access controls that authenticate users and authorise their access based on certain criteria. I'd devise a patch strategy. I'd implement an audit policy. I'd do a whole heap of stuff.
Frankly, the argument for either open- or closed source is getting tired. Any threat can be mitigated. It's success depends entirely on the value of the asset being protected, and the amount of money you're prepared to spend protecting that asset.
Apologies, I wasn't very clear.
That said, compromising a sysadmin account in Exchange does not yield email content. Assuming service accounts have been correctly configured (ref. security policy). However, a Gmail sysadmin can have (and has, in the past) access to users' email content.
If I wanted acess to anyone's email account I'd opt for a social engineering attack on that user directly. Given history that's the easiest vector.
If you think advocating defense in depth as a strategy betrays a lack of understanding of security then, well, damn.
Actually, the user doesn't have to trust anyone: the user can ask more than one party to audit the code. In fact, with open source, there are, usually, many different parties already auditing the code.
http://technet.microsoft.com/en-us/library/dd441041.aspx
Unless you consider the 'user' to be the employee sitting at the desk which is a topic for another discussion, unless the FSF is claiming that website blocking by an employer is user abuse.
Edit: There's speculation that the gambling classification was triggered by a pattern matching algorithm because of accepting bitcoin which mostly gambling sites tend to do. Maybe that's why only the donation page got blocked.
Still, you have to trust Microsoft the software will run as expected. With proprietary software, you have no option but to trust the provider. It doesn't matter how much they claim the software is secure, you will never know.