Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For most users I could not agree less.


Make software secure-by-default, make it difficult to override defaults by accident, easy to override on purpose. This is the thought process that seems to be behind, for example, CyanogenMod's recent decision to disable root access by default.

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.


>must include the vendor as a threat

Or anyone who gets access to the vendor's database.


The problem is that, in most cases, the user is unable to judge quality. The difference here is software anyone with knowledge can audit and software only the vendor can.

If the vendor is in control, you aren't secure.


And the user has to trust that these 'knowledgeable people' are indeed knowledgeable. The exact same thing they have to do with a vendor.

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.


The difference is that, once you have chosen who to trust, you are not forced to trust them forever; you can change who you trust whenever you want and for whatever reason you may have.

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.


I don't trust anybody. That applies to both open- and closed-source apps.

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.


If we are talking about open-source versus proprietary software you shouldn't offer Gmail as an option to Exchange, since both are proprietary. In fact, I believe your perception of security is wrong - if someone wanted to steal your e-mails from your Exchange server, all they have to do is to compromise a sysadmin inside your organization (or your co-lo provider). When you need to get someone's email from Gmail, you'll have to compromise a sysadmin within Google with access to the information you want. Even pinpointing one is, most likely, hard.


I did point out that the Gmail comparison is an aside. An aside because as you point out, neither is open source. Gmail in comparison to Exchange does, however, demonstrate the benefits of controlling the environment.

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.


> And the user has to trust that these 'knowledgeable people' are indeed knowledgeable

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.


The advantage of Open-Source is that the source code will (or at least should/could) be audited by a variety of people from different organizations or private individuals who will have differing motivations and therefor it is much more difficult to get away with something that may be advantageous to one group but not to all the others.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: