Sollte ein Umfrage -Rahmen geschlossen werden

Question

Ich unterhielt mich mit einem Kollegen, der an einer Umfrages -App und einem Framework arbeitet. Er stellte technische Fragen und ich schlug vor, er habe die Bewerbung offen, um mehr hochwertige Meinungen von Entwicklern zu erhalten, die sich für dieses Problem interessieren und bereit sind, sie jedoch stark zu geben.

Er hat eine andere Sichtweise, die meiner Meinung nach immer noch gültig ist, also möchte ich diese Frage hier zur Diskussion öffnen. Er sagt, er glaubt, dass so etwas wie ein Wahlrahmen sollte nicht Seien Sie offen, da es seine Sicherheit und Gültigkeit verringert, wenn Menschen Lücken aufdecken, durch die sie betrügen können. Ich kann nicht sagen, dass ich völlig anderer Meinung bin. Ich sehe dort einen etwas gültigen Punkt, aber ich glaubte immer, dass Lösungen einer Gruppe von Menschen fast immer besser sind als eine Lösung, die von einer einzelnen Person gedacht hat, die eine kleine Anzahl von Mitarbeitern fragt, egal wie klug diese Person ist. Wieder bin ich bereit zu akzeptieren, dass vielleicht einige Arten von Anwendungen unterschiedlich sind.

Hat jemand ein Streit zu seinen Gunsten? Ich möchte ihm wirklich Ihre Antworten präsentieren.

Answer 1

Sie sprechen über Umfragen auf Websites, nehme ich an? Das "Welches ist deine Lieblingssprache, C#, Java oder Cobol?" Umfragen eingeben? Wenn ja, ist das interessant.

Normalerweise würde ich Simons Antwort zustimmen, dass es nie sicher war, wenn das Öffnen der Quelle Lücken enthüllt.

Jedoch, für diese Art von App .. die Chancen sind, dass nein, es war nicht Zu Beginn sicher und kann nicht leicht gemacht werden. Das Problem ist, ich wette, dass Sie die Anforderung haben, dass Personen einfach zur Website kommen und in der Umfrage abstimmen können, ohne Registrierung erforderlich zu sein. Und du Auch haben die inkompatible Anforderung, dass Menschen nur einmal abstimmen können.

Also was auch immer du tust ... es gibt eine Lücke. IP -Adressen überprüfen? Besucher, der betrügen möchte, weiß, dass er einen Stellvertreter benutzt. Kekse? Besucher, der betrügen will, weiß, dass er seine Kekse räumen will. Das Öffnen der Quelle macht es trivial zu sehen, wie man betrügt.

Aber das ist aber trotzdem trivial. Es dauert nicht lange, bis die Alternativen ausprobiert werden und welche mehrere Stimmen zulässt. Es ist einfach nicht möglich, diese Art von anonymer Umfrage zu sichern, also können Sie es genauso gut eröffnen und zumindest Augäpfel erkennen, die Fehler erkennen!

Answer 2

In der Tat, Open Source zu sein, hilft Ihnen, sicherer zu sein.

Ich persönlich glaube, dass ein Programm als geschlossene Quelle begann und zuerst Open Source hergestellt wird, es für Benutzer (durch Exposition von Schwachstellen) und im Laufe der Zeit (z. B. ein paar Jahre) häufig weniger sicher beginnt, hat das Potenzial, viel zu sein Sicherer als ein geschlossenes Programm. Wenn das Programm als Open -Source -Software begann, verbessert die öffentliche Prüfung eher seine Sicherheit, bevor es für eine erhebliche Anzahl von Benutzern bereit ist, aber es gibt mehrere Einschränkungen für diese Aussage (es ist keine Eisenclad -Regel). Wenn Sie nur ein Programm Open Source erstellen, macht ein Programm nicht plötzlich sicher, und nur weil ein Programm Open Source ist, garantiert sie keine Sicherheit:

• Zunächst müssen die Leute den Code tatsächlich überprüfen. Dies ist eine der wichtigsten Punkte der Debatte - werden die Leute den Code in einem Open -Source -Projekt wirklich überprüfen? Alle möglichen Faktoren können die Überprüfung verringern: Ein Nische oder ein selten verwendetes Produkt (wo es nur wenige potenzielle Gutachter gibt), nur wenige Entwickler und Verwendung einer selten verwendeten Computersprache. Ein Programm mit einem einzigen Entwickler und keinen anderen Mitwirkenden jeglicher Art hat diese Art von Überprüfung nicht. Auf der anderen Seite schlägt ein Programm mit einem primären Autor und vielen anderen Personen, die gelegentlich den Code untersuchen und dazu beitragen, darauf hin, dass andere den Code überprüfen (zumindest zum Erstellen von Beiträgen). Wenn es mehr Rezensenten gibt, besteht im Allgemeinen eine höhere Wahrscheinlichkeit, dass jemand einen Fehler identifiziert - dies ist die Grundlage für die "viele Augäpfel" -Theorie. Beachten Sie, dass das OpenBSD -Projekt beispielsweise Programme für Sicherheitsfehler kontinuierlich untersucht, sodass die Komponenten in den innersten Teilen sicherlich eine lange Überprüfung durchlaufen haben. Da OSS/FS -Diskussionen häufig öffentlich abgehalten werden, können potenzielle Benutzer für sich selbst beurteilen.
   
  Ein Faktor, der die Überprüfungswahrscheinlichkeit insbesondere verringern kann, ist nicht Open Source. Einige Anbieter mögen ihre "offengelegten Quelle" (auch als "Quelle verfügbar") als Open Source -Programme, da der Programmbesitzer jedoch umfangreiche exklusive Rechte hat, andere haben weitaus weniger Anreize, "kostenlos" für den Eigentümer auf zu arbeiten der Code. Sogar Open Source -Lizenzen mit ungewöhnlich asymmetrischen Rechten (wie der MPL) haben dieses Problem. Schließlich ist es weniger wahrscheinlich, dass die Menschen freiwillig teilnehmen, wenn jemand anderes Rechte an ihren Ergebnissen hat, die sie nicht haben (wie Bruce Perens sagt: "Wer will der unbezahlte Mitarbeiter eines anderen sein?"). Da die Rezensenten mit den meisten Anreiz in der Regel Menschen sind, die versuchen, das Programm zu ändern, reduziert dieser Anreiz zur Teilnahme die Anzahl der "Augäpfel". Elias Levy machte diesen Fehler in seinem Artikel über Open Source Security; Seine Beispiele für Software, die in (z. B. Tis 'Gauntlet) unterteilt worden waren, waren damals nicht Open Source.

• Zweitens müssen zumindest einige der Personen, die den Code entwickeln und überprüfen, wissen, wie sie sichere Programme schreiben. Hoffentlich hilft die Existenz dieses Buches. Es ist klar, dass es egal ist, ob es "viele Augäpfel" gibt, wenn keiner der Augäpfel weiß, wonach sie suchen müssen. Beachten Sie, dass nicht jeder wissen muss, wie man sichere Programme schreibt, solange diejenigen, die wissen, wie die Codesänderungen untersucht werden.

• Drittens müssen diese Probleme schnell behoben werden und deren Korrekturen verteilt werden. Open Source -Systeme neigen dazu, die Probleme schnell zu beheben, aber die Verteilung ist nicht immer reibungslos. Zum Beispiel leisten die OpenBSD -Entwickler hervorragende Arbeit, um den Code für Sicherheitsfehler zu überprüfen - aber sie melden die identifizierten Probleme nicht immer dem ursprünglichen Entwickler. Daher ist es durchaus möglich, dass es eine feste Version in einem System gibt, aber der Fehler in einem anderen bleibt. Ich glaube, dieses Problem verringert sich im Laufe der Zeit, da niemand "stromabwärts" immer wieder das gleiche Problem behebt. Es ist natürlich ein Problem für Open Source- und Closed Source-Software, sicherzustellen, dass Sicherheitspatches tatsächlich auf End-User Systems installiert sind.

Ein weiterer Vorteil von Open Source ist, dass Sie es sofort beheben können, wenn Sie ein Problem finden. Dies hat wirklich kein Gegenstück in geschlossener Quelle.

Kurz gesagt, die Auswirkung auf die Sicherheit der Open -Source -Software ist nach wie vor eine große Debatte in der Sicherheitsgemeinschaft, obwohl eine große Anzahl prominenter Experten der Ansicht ist, dass es ein großes Potenzial hat, sicherer zu sein.

Schau dir Linux an ...

Answer 3

Das Argument, dass Open Source "ihre Sicherheit und Gültigkeit verringern wird, wenn Menschen Lücken offenbaren", ist völlig ungültig. Ein sicheres Produkt sollte keine Lücken haben. Wenn es Open -Source -Open -Source ist, sollte es keine Lücken enthüllen.

Wenn Ihr Produkt Lücken enthält, die sich durch die Herstellung von Open Source enthüllt, ist dies nur Ihre mangelnde Sicherheit hinter Ihrem Compiler versteckt. Sie könnten eine Weile damit davonkommen, aber irgendwann wird jemand Ihren Code umkehren und eine dieser Lücken finden (von dem Sie möglicherweise nicht einmal gewusst haben)

Ich würde einem Open -Source -Sicherheitsprodukt weit mehr vertrauen, als ich einer geschlossenen Quelle vertrauen würde.

Der Sicherheitsexperte Bruce Schneier fasst es gut zusammen:

Wenn ich einen Brief nehme, ihn in einen Safe sperre, den Safe irgendwo in New York verstecken und Ihnen sagen, Sie sollen den Brief lesen, das ist keine Sicherheit. Das ist Dunkelheit. Auf der anderen Seite, wenn ich einen Brief nehme und ihn in einen Safe sperle und Ihnen dann den Safe zusammen mit den Entwurfsspezifikationen der sicheren und hundert identischen Safes mit ihren Kombinationen gebe, damit Sie und die besten Safekracker der Welt das studieren können Verriegelungsmechanismus - und Sie können den Safe immer noch nicht öffnen und den Brief lesen - das ist Sicherheit.

Bruce Schneier - Angewandte Kryptographie

Answer 4

Durchlesen Wird Open Sourcing Stack Overflow unser Geschäftsmodell zerstören? - Während der Stack -Überlauf nicht der gleiche wie Ihr Umfrage -Framework ist, sollte es Ihnen mehr Einblick in die Ansichten vieler anderer Menschen geben.

Ein paar Gedanken, die mir vorkommen, dass ich die Antwort an mich selbst nicht kenne ...

1. Nur weil jemand dem Projekt Code einreicht, ist es möglicherweise nicht gut genug/akzeptiert/verwendet. Open-Source macht den Code nicht automatisch besser.
2. In ähnlicher Weise weiß ich nicht, was die durchschnittliche Aufnahme für Entwickler ist, die mit dem Code helfen. Es gibt möglicherweise keine Horden von Entwicklern, die zur Quelle beitragen? (Obwohl Sie nur 1 oder 2 benötigen, um einen wesentlichen Unterschied zu machen).
3. Ich denke, es gibt auch nichts, was Sie davon abhält, das Framework zu open-Sourcing, aber Sie führen eine individuelle Version für Ihr Unternehmen aus, die andere Funktionen/Sicherheit integriert.
4. Kann Ihr Unternehmen anonym bleiben/nicht werben, dass es hinter dem Rahmen steht? Und wo das Framework installiert ist/live - verkleidet, dass es sich um ein bestimmtes Framework handelt? (Betrachten Sie WordPress und wie eine der Sicherheitsempfehlungen darin besteht, das Meta -Tag mit der Aufschrift "WordPress Version 2.3" zu verbergen).
5. Sie müssen auch mit Ihrem Chef/Ihrer Rechtsabteilung sprechen, da Ihr Arbeitsvertrag möglicherweise etwas ausdrückt, was das geistige Eigentum von allem, was Sie bei der Arbeit erstellen landen Sie in heißem Wasser.