Should a poll framework be closed sourced

Question

I was having a chat with a coworker who is working on a polling app and framework. He was asking technical questions and I suggested he open source the application to get more quality opinions from developers who are interested in this problem and are willing to give it heavy though.

He has a different point of view which I think is still valid so I want to open this question for discussion here. He says he believes something like a polling framework should not be open sourced because it will reduce its security and validity as people reveal loopholes through which they can cheat. Can't say I completely disagree. I see a somewhat valid point there, but I always believed that solutions by a group of people are almost always better than a solution thought by a single person asking a small number of coworkers, no matter how smart that person is. Again I'm willing to accept that maybe some types of applications are different.

Does anyone have an argument in his favor? I'd really like to present your responses to him.

Answer 1

You're talking about polls on websites, I'm assuming? The "which is your favourite language, C#, Java or COBOL?" type polls? If so, that's an interesting one.

Normally I would agree with Simon's answer that if opening the source reveals loopholes, it was never secure to begin with.

However, for this sort of app.. the chances are that no, it wasn't secure to begin with, and can't easily be made so. Problem is, I'm betting that you have a requirement for people to be able to just come to the website and vote in the poll, no registration required. And you also have the incompatible requirement that people should only be able to vote once.

So whatever you do.. there's a loophole. Checking IP addresses? Visitor who wants to cheat knows to use a proxy. Cookies? Visitor who wants to cheat knows to clear his cookies. Opening the source makes it trivial to see how to cheat.

But having said that.. it's trivial anyway. Doesn't take very long to try the alternatives and see which one allows multiple votes. It's just not possible to make this sort of anonymous poll secure, so you might as well open source it and at least get eyeballs spotting bugs!

Answer 2

In fact, being open source helps you to be more secure.

I personally believe that when a program began as closed source and is then first made open source, it often starts less secure for any users (through exposure of vulnerabilities), and over time (say a few years) it has the potential to be much more secure than a closed program. If the program began as open source software, the public scrutiny is more likely to improve its security before it's ready for use by significant numbers of users, but there are several caveats to this statement (it's not an ironclad rule). Just making a program open source doesn't suddenly make a program secure, and just because a program is open source does not guarantee security:

• First, people have to actually review the code. This is one of the key points of debate - will people really review code in an open source project? All sorts of factors can reduce the amount of review: being a niche or rarely-used product (where there are few potential reviewers), having few developers, and use of a rarely-used computer language. Clearly, a program that has a single developer and no other contributors of any kind doesn't have this kind of review. On the other hand, a program that has a primary author and many other people who occasionally examine the code and contribute suggests that there are others reviewing the code (at least to create contributions). In general, if there are more reviewers, there's generally a higher likelihood that someone will identify a flaw - this is the basis of the "many eyeballs" theory. Note that, for example, the OpenBSD project continuously examines programs for security flaws, so the components in its innermost parts have certainly undergone a lengthy review. Since OSS/FS discussions are often held publicly, this level of review is something that potential users can judge for themselves.
   
  One factor that can particularly reduce review likelihood is not actually being open source. Some vendors like to posture their "disclosed source" (also called "source available") programs as being open source, but since the program owner has extensive exclusive rights, others will have far less incentive to work "for free" for the owner on the code. Even open source licenses which have unusually asymmetric rights (such as the MPL) have this problem. After all, people are less likely to voluntarily participate if someone else will have rights to their results that they don't have (as Bruce Perens says, "who wants to be someone else's unpaid employee?"). In particular, since the reviewers with the most incentive tend to be people trying to modify the program, this disincentive to participate reduces the number of "eyeballs". Elias Levy made this mistake in his article about open source security; his examples of software that had been broken into (e.g., TIS's Gauntlet) were not, at the time, open source.

• Second, at least some of the people developing and reviewing the code must know how to write secure programs. Hopefully the existence of this book will help. Clearly, it doesn't matter if there are "many eyeballs" if none of the eyeballs know what to look for. Note that it's not necessary for everyone to know how to write secure programs, as long as those who do know how are examining the code changes.

• Third, once found, these problems need to be fixed quickly and their fixes distributed. Open source systems tend to fix the problems quickly, but the distribution is not always smooth. For example, the OpenBSD developers do an excellent job of reviewing code for security flaws - but they don't always report the identified problems back to the original developer. Thus, it's quite possible for there to be a fixed version in one system, but for the flaw to remain in another. I believe this problem is lessening over time, since no one "downstream" likes to repeatedly fix the same problem. Of course, ensuring that security patches are actually installed on end-user systems is a problem for both open source and closed source software.

Another advantage of open source is that, if you find a problem, you can fix it immediately. This really doesn't have any counterpart in closed source.

In short, the effect on security of open source software is still a major debate in the security community, though a large number of prominent experts believe that it has great potential to be more secure.

Look at Linux...

Answer 3

The argument that open source "will reduce its security and validity as people reveal loopholes" is completely invalid. A secure product shouldn't have loopholes so when it is made open source there should be no loopholes to reveal.

If your product has loopholes that would be revealed by making it open source that isn't security, that's just hiding your lack of security behind your compiler. You might get away with it for a while, but eventually someone is going to reverse engineer your code and find one of those loopholes (that you may not even have known about)

I would trust an open source security product far more than I would trust a closed source one.

The security expert Bruce Schneier sums it up nicely:

If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world's best safecrackers can study the locking mechanism -and you still can't open the safe and read the letter - that's security.

Bruce Schneier - Applied Cryptography

Answer 4

Have a read through Will Open Sourcing Stack Overflow Destroy Our Business Model? - while Stack Overflow isn't the same as your poll framework it should give you more insight into many other people's views.

Couple of thoughts that occured to me that I don't know the answer to myself...

1. Just because someone submits code to the project, it might not be good enough/accepted/used. Open-source doesn't automatically make the code better.
2. Similarly, I don't know what the average take-up is for developers helping out with the code. There may not be hordes of developers contributing to the source? (although you only need 1 or 2 to make a substantial difference).
3. I guess there is also nothing stopping you from open-sourcing the framework, but you run a customised version for your business that has other features/security built in.
4. Can your business remain anonymous/not advertise that it is behind the framework? And where the framework is installed/live - disguise that it is a particular framework? (Consider wordpress and how one of the security recommendations is to hide the meta tag that says "Wordpress version 2.3").
5. You also need to talk to your boss/legal department because your employment contract might say something to the effect that the intellectual property of anything that you create at work is owned by your employer, and open-sourcing some code that originated in the company could land you in hot water.