'Hoewel open source goedkoop lijkt en een soort gelijkheidsideaal en standaardisatie uitdraagt, ligt de broncode op straat en daarmee ook de kwaliteit, robuustheid en beveiliging en dus privacy', brabbelde een niet nader te noemen vertegenwoordiger in de software-industrie onlangs in Computable. Laten we er even van uit gaan dat dit correct geciteerd is en hij deze kletskoek zelf heeft gebakken.
Ik zal u de demagogie toelichten. Een zin die begint met 'Hoewel appels goedkoper lijken dan peren' zal uiteindelijk beweren dat appels duurder of slechter zijn. De vertegenwoordiger probeert hier dus te suggereren dat open source gevaarlijk is voor de privacy. 'Nee, gevaren voor de privacy willen we niet!' hoor ik u al denken. Maar wordt die bewering ook hard gemaakt?
'De broncode ligt op straat en daarmee ook de kwaliteit.' Alles wat op straat ligt is blijkbaar slecht. Maar het lijkt me juist goed als de kwaliteit zichtbaar wordt voor wie dat wil weten. Als je zin hebt in een hamburger wil je toch ook weten waar de beste ingrediënten worden gebruikt, en het schoonste wordt gewerkt? In het geval van open source kunnen we dan zelf kijken of de software wel een beetje onderhoudbaar is, of dat er een prutser aan het programmeren is geweest.
Als de broncode openbaar is, is daarmee dan de beveiliging in gevaar? Het woord code in broncode betekent alleen maar onbegrijpelijk, in tegenstelling tot het woord code in pincode. Als de versleutelingstechniek bekend is, hoeven de sleutels dat nog niet te zijn. Trouwens, in de beveiligingswereld leeft de overtuiging dat openbare beveiligingsmechanismen juist veiliger zijn omdat iedereen dan kan zien dat er niet bewust of onbewust lekken in zijn gemaakt.
En al zou de beveiliging ‘in gevaar zijn' doordat we de broncode kennen, is daarmee dan de privacy in gevaar? Ik denk toch niet dat dat serieus speelt bij de meeste populaire open source software zoals Open Office, Firefox en contentmanagementsystemen.
Kortom, kletskoek!
De argumentatie van de kletskoekenbakker(s) lijkt veel op eentje die die ik in de tachtiger jaren vond bij mijn eerste stagebedrijf. Aldaar had een programmeur iets gebrouwen wat zo obscuur en moeilijk leesbaar was dat alleen hij er nog iets mee kon. Op mijn vraag hoe dat moest worden onderhouden antwoorde hij “als het voor een ander niet leesbaar is, dan is ons intellectueel eigendom beter beschermd”
Security by obscurity: als ik er niets van begrijp, dan moet het wel heel veilig zijn!!
Als de broncode openbaar is worden eventuele lekken vaak sneller gevonden omdat er meer mensen inzicht in hebben. Dergelijke lekken kunnen daarom relatief snel gedicht worden of vaak kan een work-around gebruikt worden om de gevolgen van het lek te beperken tot er een update uit is.
Als de broncode niet inzichtelijk is zal een lek dus veel langer onbekend blijven voor de buitenwereld en kunnen beheerders zich er dus ook niet tegen beschermen.
Totdat er een patch is zullen kwaadwillenden dus vrij spel hebben…
Wat zou veiliger zijn ?
In afgelopen zeg 5 jr heb ik regelmatig artikelen gelezen over open source versus closed source beveiligings issues. In open source zou door iedereen gemakkelijker fouten gevonden kunnen worden en ook worden opgelost en in closed sources zou alleen de leverancier dit kunnen. Nu zien we dat bij open source de code vaak alleen door een beperkte groep gewijzigd wordt en dat zeker niet iedereen deze kan lezen of in staat is deze te veranderen. Bij closed source zijn er behalve de leverancier (die niet gebaad is bij security bugs in zijn software) ook derde partijen die de source code in mogen kijken fouten vinden. Volgens mij is het daarom lood om oud ijzer… Microsoft maakt er al jaren een wedstrijdje van tov linux om zo min mogelijk security patches uit te brengen. Maar in een security patch lossen ze vaak meerdere bugs op… En fouten die niemand kant zijn op dat moment ook niet gevaarlijk… totdat iemand deze vind. Verder zijn er hoe dan ook fouten in code… bij 1 fout per 10000 regels code heb je dus bij een OS met 50 miljoen regels code 5000 fouten. Bij 1 fout per 1000 regels code is dat 50000. Volgens mij hebben we dus nog een lange weg te gaan… die “Security by obscurity” heb je dus hoe dan ook.
Het gaat erom hoe het totaal plaatje eruit ziet en als je meerdere lagen van security hebt is de kans op een inbraak een stuk kleiner.
>> die “Security by obscurity” heb je dus hoe dan ook.
Er is een groep programmeurs met kennis en toegang tot de vrij beschikbare code (open source) en er is een groep programmeurs met kennis en toegang tot de closed source. Welke groep zou groter zijn?
Heb niet de illusie dat programmatuur veilig is omdat er niemand bij de code kan komen, dat is grote onzin. Bij open source heeft helemaal niemand deze i
llusie, de code ligt tenslotte “op straat”.
De snelheid van patchen verschilt per project/leverancier, daar zijn (helaas) geen richtlijnen voor te geven. Ik ken voorbeelden van slechts enkele uren tussen het vinden van een bug en het patchen van deze bug, maar dat is (helaas) niet de norm. En ja, dit betreft open source.
Dit is wel heel kort door de bocht. Een veronderstelde mening weerleggen in een eigen stukje zonder weerwoord?
Dat open source per situatie voor- en nadelen heeft, weet iedereen. Zo ook in bovenstaand stuk. De vertegenwoordiger zet zwart, de schrijver zegt wit. De waarheid is grijs, zwart of wit.
Meest gehoorde probleem om source open te kunnen maken, is de moeilijkheid van het verdienmodel en
(on)mogelijheden met het vastleggen en controleren van (digitale) rechten.
@Robert: Heb je wat meer informatie over “de (on)mogelijkheden met het vastleggen en controleren van rechten” ? Waar doel je hier op en waarom zou dit spelen bij open source?
Het verdienmodel is geen enkel probleem, projecten zoals Apache, Tomcat en PostgreSQL bestaan al vele jaren en velen verdienen daar hun boterham mee. Dit zal niet opgaan voor alle projecten, maar heeft meer met het succes van een product te maken dan met de licentievorm.
Zelf kijken in de code? Dit gaan bedrijven die een stuk software willen gebruiken toch niet doen? Die willen iets kopen en iemand aansprakelijk kunnen stellen als wat ze gekocht hebben niet voldoet aan de (veiligheids)eisen.
Ze “moeten” hoe dan ook vertrouwen op degene die de software uitlevert, en ik kan goed begrijpen dat ze hun vertrouwen liever baseren op een leverancier, dan een onbekende groep programmeurs die nergens aansprakelijk voor zijn.
Open source is een prachtig iets, maar een ongenuanceerde uitspraak proberen te weerleggen met: je kunt zelf in de code kijken dus het is harstikke veilig…tja…
Vandaag weer te horen gekregen: “iedereen gebruikt X dus is het zeker goed”. Dat X 2000 EUR kost en het FOSS programma 0 EUR, en dat X nauwelijks mogelijkheden kent te verbinden i.t.t. het FOSS proogramma wordt nauwelijks gehoord. Het argument dat je met FOSS onafhankelijk van een leverancier bent blijkt in de praktijk een argumant dat te komplex is omdat je dan over een wat langere tijd moet kunnen denken.
Ik ben bang dat de FOSS-luitjes wel intelligent zijn maar geen goede verkopers . . . . . , die kunnen namelijk kletskoek bakken.
@Rin, als het daarom gaat kunnen bedrijven nog altijd hun software betrekken van een bedrijf dat OSS levert. Je betaalt niet per definitie voor de software zelf maar voor de support. Is de support niet goed dan heb je in elk geval een partij om de schuld op af te schuiven.
Blijft het feit, je *kunt* in de software kijken hoe het is opgebouwd. Of je het doet of wil doen staat daar los van. Inderdaad, de meesten zullen snel weer iets anders gaan doen omdat ze de inhoud niet kunnen lezen of begrijpen. Gelukkig zijn er ook mensen die het wel kunnen. Dat zijn de mensen die de software maken en/of onderhouden. En velen daarvan werken ook nog eens in software onderhoud, soms zelfs bij de bedrijven die OSS leveren aan partijen die dat zelf niet kunnen of willen onderhouden.
Het gaat vaak om heel veel centjes en dan wordt alles uit de kast gehaald om het eigenbelang veilig te stellen. Maar het grootste euvel is nog steeds het ’technisch’ management wat vaak geen flauw benul heeft waar ze mee bezig zijn en laten zich van alles aansmeren. De grote commerciele spelers weten dit donders goed en weet ze vaak zat te paaien.