'Ontwikkelaars niet verantwoordelijk voor veiligheidsbugs'

Linux-kernelontwikkelaar Alan Cox heeft tegenover een commissie van het Hogerhuis in het Verenigd Koninkrijk verklaard dat softwareontwikkelaars niet verantwoordelijk gehouden kunnen worden voor bugs in hun code.

'Het is de ethische verantwoordelijkheid van programmeurs om hun code zo veilig mogelijk te maken', aldus Cox. Daar voegde hij echter meteen aan toe dat het een algemeen geaccepteerd feit is dat niemand op dit moment in staat is het perfecte besturingssysteem te ontwikkelen. Hij is overigens wel van mening dat dat probleem ooit opgelost zal worden. Toch zouden softwareontwikkelaars niet verantwoordelijk gehouden mogen worden voor fouten in hun programmatuur, volgens Cox vanwege de invloed die dat zou hebben op de softwaremarkt en de ontwikkeling van third-party programma's. Cox vertelde de leden van het House of Lords dat de interactie tussen het besturingssysteem en third-party software dermate complex is, dat niet gegarandeerd kan worden dat het altijd goed gaat. Als ontwikkelaars verantwoordelijk gehouden worden voor fouten in hun closed-source besturingssysteem, zou de logische reactie volgens Cox dan ook zijn dat ze third-party applicaties verbieden op hun systeem. Dat zou op zijn beurt echter in strijd zijn met de wetten die een vrije marktwerking moeten garanderen.

In het geval van opensourcetoepassingen is het bovendien niet altijd eenvoudig mogelijk om een verantwoordelijke voor een bepaalde bug aan te wijzen, zodat er eigenlijk geen realistische manier is om verantwoordelijkheid af te dwingen. Als commerciële bedrijven gebruik gaan maken van opensourceprogramma's en daarbij ook de bugs in de code overnemen, wordt de zaak bovendien nog complexer. Jerry Fishenden van Microsoft voegde eraan toe dat de verantwoordelijkheid voor veiligheidslekken te allen tijde bij de misbruikers van dat lek hoort te liggen. 'Mensen houden de ramenfabrikant ook niet verantwoordelijk voor inbraken in hun huis', aldus Fishenden. Opensourceontwikkelaar Adam Laurie sloot af met de mededeling dat er een balans gevonden moet worden tussen bruikbaarheid en veiligheid.

Reacties (84)

[Rembert]

Het lijkt wel of er ineens op tweakers vooral gebruikers zitten en nauwelijks programmeurs.

Alan Cox heeft m.i. volkomen gelijk.

Een paar voorbeelden. Een klant van mij heeft, toen ze nog klant van een ander waren, een forum laten bouwen. Ze hebben daarna mij in de arm genomen voor het beheer van hun site, inclusief het forum - een draak van een pakket. Ik ben er ook niet verder in gaan spitten (wie zou dat betalen?) tot het moment dat ineens SQL-injecties de kop op staken: een bug in het forum! De vorige partij geeft terecht 'geen thuis'. En ik doe er alleen wat aan als mijn uren worden betaald.

In de tijd dat het forum werd gebouwd, had nog niemand gehoord van SQL-injectie. Nu begrijpt (bijna?) iedereen hier op tweakers wat het is en wordt er defensief geprogrammeerd. Is dat nu een verwijtbare bug in het forum? Ik denk van niet en de bouwende partij kan niet verantwoordelijk worden gehouden voor deze bug - TENZIJ de klant een onderhoudscontract had afgesloten met de bouwers, hetgeen niet het geval was.

Dan het fenomeen IE7. Een klant van me bouwt websites en ze hebben een paar honderd grote websites draaien in Nederland. Nu blijkt dat hun stylesheets, met alle IE6 hacks enz. niet meer werken met IE7. Wiens probleem is dat? Een klein aantal klanten heeft een onderhoudskontrakt - bij hen worden de problemen direkt opgelost. De anderen niet: zij moeten nieuwe afspraken maken met mijn klant voor het aanpassen van de site.

Mijn code programmeer ik "as-is" en ik geef het aan de klant vrij onder de BSD-licensie. Ik garandeer nooit dat mijn code bugvrij is of vrij is van veiligheidsbugs. Dat is stomweg niet te doen.

Zouden ontwikeklaars wel verantwoordelijk gehouden gaan worden voor veiligheidsbugs, dan is het inderdaad mogelijk dat (closed source) besturingssystemen inderdaad geen 3rd party applicaties meer toe gaan staan op hun systeem. Of de besturingssystemen gaan astronomisch veel geld kosten: deels op gaand aan verregaand onderzoek naar die veiligheidsbugs en deels opgaand als een soort van verzekeringspremie.

Enige oplossing die ik zie is hetgeen ik al eerder noemde: je koopt/verkrijgt software "as-is" en je kunt een onderhoudscontract afnemen.
Bij open-source projecten heb je daarnaast de mogelijkheid om, in geval van geconstateerde bugs, de bug zelf op te (laten) lossen - waarna je de fix natuurlijk wel teruggeeft aan de open-source community.

[kimborntobewild]

'3rd' party zegt helemaal niet zoveel. Er worden toch dezelfde ontwikkeltools gebruikt? Ik ken een bedrijf, die kreeg een 'Windows-logo' aangeboden omdat 't zo'n mooi programma was. Echt niet omdat 't veilig genoeg in elkaar steekt.

Als je naar bijv. Windows kijkt, kost dat al reeds astronomisch veel vergeleken met hun onkosten! Ik meende dat ze meer dan 400% winst maakten op Windows. Waarom nemen ze geen genoegen met 100% winst en voor die overige 300% winst een veiliger OS maken??

[timonb]

die winstmarge wordt in principe voor twee doeleinden bedoelt:

1. Ontwikkeling van een niet OS dat gebouwd is op de toekomst
2. Ontwikkeling aan het huidige OS in de vorm van patches en bugs.

Hoe denk je dat het in de kleding industrie is geregeld? Denk je werkelijk dat een broek van 100 euro 50 euro kost om te maken? Een broek kost om te maken max. 10 euro. De rest zit puur in de designkosten voor het volgende seizoen.

[Verwijderd]

Dan het fenomeen IE7. Een klant van me bouwt websites en ze hebben een paar honderd grote websites draaien in Nederland. Nu blijkt dat hun stylesheets, met alle IE6 hacks enz. niet meer werken met IE7. Wiens probleem is dat?

Zoiets is wel degelijk de verantwoordelijkheid van de programmeur. Je weet dat als je met specifieke IE6 hacks aan de slag gaat, je dan in alle waarschijnlijkheid in de problemen komt bij een nieuwe versie. Je hebt dan de problemen al bij voorbaat ingebakken.

Je moet dat soort situaties proberen te vermijden. Als dat problemen oplevert, dan moet je dat met de klant bespreken.


De klant kan natuurlijk kiezen voor zo'n oplossing, maar dan heeft hij ook welbewust die verantwoordelijkheid hiervoor overgenomen, en weet hij dat IE7 mogelijk een fikse onderhoudsbeurt zal vergen.

[Megamind]

Als je een auto koopt dan wordt toch ook de fabrikant verantwoordelijk gesteld als tijdens de eerste 30 km een wiel eraf vliegt.

Waarom zullen software makers niet verantwoordelijk zijn voor mankementen in hun produkt?

[xillius]

@megamind
Dat is een verkeerde vergelijking.
Dit artikel gaat erover dat er veiligheids lekken zijn welke pas gevaarlijk zijn als andere personen er verkeerd mee omgaan.

Om op jou voorbeeld door te gaan:
Op een auto is het mogelijk om een wiel los te draaien. Als iemand anders dit doet en jij inderdaad na 30km je wiel kwijt raakt is dit niet de verantwoordelijkheid van de fabrikant.

Zo wel dan zal een fabrikant wielen maken welke hij alleen kan wisselen. Met alle gevolgen van dien

[kidde]

Echter, als je een kerncentrale of wolkenkrabber bouwt, houd je toch meer rekening met 'terroristen' dan dat Microsoft rekening met hackers houdt. Als kerncentrales en wolkenkrabbers zo brak ontworpen zouden zijn als software, met het idee van 'we patchen het later wel', zouden de makers ervan er niet mee weg komen.
Kortom, niet iedereen komt z'n 'morele' verplichting even goed na, maar voor bepaalde bedrijven wordt het kennelijk geaccepteerd.

[mjtdevries]

Zij airbags of SIPS die niet blijken te werken, zijn ook pas gevaarlijk als andere personen er verkeerd mee omgaan. (een ander persoon die tegen de zijkant van mijn auto rijdt)

Reken maar dat de autofabrikant er dan op aangesproken zal worden dat zijn beveiligingsmaatregelen niet werkten.

Dat is toch een aardig goede vergelijking met een veiligheidslek in software niet waar?

[maxxware]

Dat geldt alleen als kan worden bewezen dat de fabrikant willens en wetens een ondeugdelijke constructie in/aan de auto heeft laten zetten.

[Verwijderd]

Dat geldt alleen als kan worden bewezen dat de fabrikant willens en wetens een ondeugdelijke constructie in/aan de auto heeft laten zetten.

Het hoeft niet willens en wetens door de fabrikant te worden veroorzaakt. Er moet een deugedelijk product geleverd worden.

En zo zouden we ook met software om moeten gaan.

[Kix@$$]

Niet helemaal. Als je auto niet goed is ga je terug voor garantie en wordt hij gerepareerd.

Als de software niet goed is wordt er een update gemaakt en ist ook gerepareerd.

Je hebt dus gewoon recht op "garantie" via updates.

[mjtdevries]

Als er een wiel afvliegt en jij daardoor een crash krijgt en zwaargewond in het ziekenhuis terecht komt, dan moet er wel even wat meer betaald worden dan alleen een reparatie van de auto.

Daarom ook dat autofabrikanten modellen terugroepen als er een fout in blijkt te zitten en niet afwachten tot je zelf terugkomt.

Dat stuk extra verantwoordelijkheid proberen de software ontwikkelaars te ontwijken.

[Verwijderd]

@mjtdevries: dit is Nederland, we doen hier niet aan emotionele schade. De materiële schade (ziekenhuiskosten, revalidatiekosten, et cetera) worden verder alleen vergoed als inderdaad bewezen kan worden dat de fabrikant had kunnen weten dat zoiets zou kunnen gebeuren. Met andere woorden: als hij de veiligheidsvoorschriften van de overheid aan zijn laars gelapt heeft. En dat wordt best moeilijk, aangezien de auto dan schijnbaar níet voldoet aan de eisen, maar wél goedgekeurd is voor de Nederlandse wegen. Dan is het dus schijnbaar een "verborgen gebrek" en wordt het nog moeilijker te bewijzen dat de fabrikant hiervoor verantwoordelijk gehouden kan worden.

Overigens ben ik het niet met mijnheer Cox eens. Het perfect veilige OS zal NOOIT komen. Om de doodsimpele reden dat er teveel mensen rondlopen die slechts _denken_ heel goed te weten wat veilig is en hoe alles werkt. En gek genoeg zijn dat dezelfde mensen die er van gruwelen als hun OS/hardware voor ze bepaalt wat veilig is...

[Verwijderd]

Sorry, post is twee keer geplaatst !?!

[Gerco]

Simpel, als dat zou gebeuren, dan verbied MS om niet-MS applicaties te draaien, want ze kunnen niet garanderen dat andere applicaties geen fouten in Windows zullen blootleggen. (Geld ook voor Apple trouwens)

Op deze manier ontwikkelaars verantwoordelijk maken zou ervoor zorgen dat de complete softwarewereld instort. Applicaties zullen vele malen meer gaan kosten om te maken dan ze nu al doen en niemand durft meer iets te releasen omdat ze bang zijn voor een aanklacht (misschien jaren later pas).

[kimborntobewild]

Alsof ze wél kunnen garanderen dat hun eigen producten veilig zijn! De security-fixes die ik moet installeren zijn toch echt 9 op de 10 keer van MS zelf.
Er moet gewoon een oplossing worden gezocht voor 'buffer overflow' fouten, dan ben je al een heel end. Het is eerder onwil dan onkunde volgens mij, dat dat nog niet opgelost is.
Als MS ook niet steeds zijn eigen standaarden na zou streven, zou dat ook al heel wat problemen schelen. Bijv. ActiveX, da's toch echt een ramp wat security betreft.

[whoami]

Als MS standaarden van anderen zou gebruiken (zoals bij Java)

Hoe bedoel je dat ?

[Neko Koneko]

Bovendien zou het ook werk schelen. Als MS standaarden van anderen zou gebruiken (zoals bij Java) dan zouden ze daar al niet meer verantwoordelijk voor zijn, en hoeven ze ook geen tijd meer aan de ontwikkeling ervan besteden.

Eigenlijk zou het fijn zijn als ze Windows kaal zouden strippen zodat je, als je bijvoorbeeld geen Windows Media player wilt, ook niet vatbaar bent voor Media Player bugs.

[CH4OS]

Simpel, als dat zou gebeuren, dan verbied MS om niet-MS applicaties te draaien, want ze kunnen niet garanderen dat andere applicaties geen fouten in Windows zullen blootleggen. (Geld ook voor Apple trouwens)

MS kan anders ook nooit garanderen dat hun eigen software bugvrij is, dat kan niemand namelijk, ook Microsoft niet. Zo kan MS dus ook niet voorkomen dat MS-applicaties geen fouten en / of lekken blootleggen.

[SPee]

Tot op zekere hoogte kun je wel die zekerheid geven.
Dat is wanneer je alleen via 1 vooraf bepaalde manier kunt werken.

Bv. bij demo's van nieuwe applicaties zal deze veelal worden getoond met de juiste handelingen zodat hij geen fouten zal tonen. Omdat het een demo is zal hij het op die manier wél doen, maar als je maar 1 ding anders doet, gaat het al fout.

Dat zal men dan ook in de software gaan toepassen. 1 bepaalde manier wordt op alle mogelijke manieren getest en is op dat punt bugvrij. Alle andere manieren worden door de software niet mogelijk gemaakt en heb je dus een bugvrij systeem.
Je kunt er maar op 1 manier mee werken, maar hij is wel bugvrij.

Zoals je ziet komt dat de innovatie niet ten goede. Daarom is het goed dat ze de overheid duidelijk maken dat sommige dingen afdwingen met regels niet gedaan moet worden.

[Belenar]

Een beetje kromme vergelijking.

Vaak is de schade die wordt toegebracht aan een besturingssysteem het resultaat van een aanval van buitenaf. Dit kan lukken door een bug of beveiligingsgat dat de fabrikant over het hoofd heeft gezien.

Als iemand erin slaagt om bij een nieuwe auto de velgen van een auto te stelen, in te breken in de wagen of de wagen helemaal te stelen is dan ook de fabrikant verantwoordelijk?

[tes_shavon]

deze vergelijking gaat niet op:

Het gaat om security-issues en niet om performance-issues. Een fabrikant van software mag wat mij betreft aansprakelijk worden gesteld als ik zijn software op mijn pc installeer op het door hem geadviseerde OS-platform en mijn hele machine crasht. Ofwel, ik voldoe aan al zijn voorwaarden en TOCH werkt het niet (ik koop een nieuwe auto en TOCH breekt het wiel af)... Aan de andere kant: als die bij heel veel mensen gebeurd, denk ik niet dat de softwarefabrikant een lang leven beschoren is.

En volgens mij kun je een autofabrikant niet aansprakelijk stellen als er in je auto wordt ingebroken. Ook al staan door een fabrikagefout altijd al je ramen open.

Edit: volgens mij zijn er meer mensen die het niet de juiste vergelijking vinden, WOEHOW, een triple-post

[Limaad]

bij de auto heb je garantie gekocht...
linux is gratis? en geeft vrij duidelijk dus geen garantie.....
zo simpel is het...

[Verwijderd]

linux geeft dezelfde garantie; als je linux installatie "defect" raakt mag je zo een nieuwe downloaden

[Brupje]

als iets gratis is en het sloopt je systeem kun je de maker nog steeds wel aansprakelijk stellen. Alleen bij open-source had je kunnen weten dat het fout gaat, je hebt immers de source

[Niemand_Anders]

Windows is niet gratis, en welke garanties heb je daar dan? Microsoft is nog nooit bij mij aan de deur geweest om mijn windows installatie te repareren.

Als je auto-updates als repararie ziet, bied linux dezelfde garantie. Voor zover ik weet brengen alle distributies veiligheids updates uit welke allemaal indien gewenst automatisch geinstalleerd kunnen worden.


Ongeacht open- of closed source, er zijn altijd een of meerdere personen verantwoordelijk voor een onderdeel van de code. Zodra een veiligheidslek wordt gemeld en daar wordt niets mee gedaan en er komt ook geen feedback van de verantwoordelijke(n), dan kan wat mij betreft die partij wel degelijk daarvoor verantwoordelijk worden gehouden.

[tes_shavon]

je installatie gaat niet stuk... je configuratie begeeft het!

[McChouffe]

Een software-ontwikkelaar is voor mij in die zin verantwoordelijk dat hij/zij gevonden fouten zo snel mogelijk moet dichten.
Dat fouten uitgebuit worden is mijns inziens niet de verantwoordelijkheid van de ontwikkelaar, tenzij die fouten consequent genegeerd werden.
Als een autofabrikant lucht krijgt van een ernstig mankement, zal hij ook alle modellen terugroepen en herstellen.

[CH4OS]

Als je een auto koopt dan wordt toch ook de fabrikant verantwoordelijk gesteld als tijdens de eerste 30 km een wiel eraf vliegt.

Als het bij 1 auto gebeurd, is het gewoon de bestuurder die waarschijnlijk zijn auto niet goed gebruikt heeft.
Gebeurd zoiets echter te vaak, dan pas zou je kunnen zeggen dat het een fabricage fout is, dan pas is de fabrikant verantwoordelijk.

Zou wat zijn, als je gelijk de autofabrikant verantwoordelijk houdt, omdat eenmalig bij een auto tijdens de eerste 30km een wiel er af vliegt.

Zo is dat dus ook in de 'Programmeerwereld' en ik denk dat dat hier ook bedoeld word...

[paterke1984]

Als je een auto koopt en een randdebiel die niet uitkijkt ramt jouw auto, heb je ook geen garantie van de fabrikant dat je auto is beschadigd. En als iemand de ruit van je auto inslaat (of subtieler je auto open maakt) en je persoonlijke bezittingen of autoradio jat, heb je ook gewoon pech.

Dus als een stel randdebielen virussen loopt te schrijven om jouw computer/software te beschadigen of je persoonlijke bestanden te bekijken, kun je daar de maker van de software ook niet verantwoordelijk voor houden. Deze doet zijn best om ervoor te zorgen dat niemand makkelijk erbij komt, maar er kan niet worden verwacht van hem dat hij kwaadwillenden helemaal kan weren.

[Floor]

Hoewel ik het gedeeltelijk met je eens ben denk ik dat de financiele schade minder zwaar zal tellen dan de eventuele lichamelijke schade wat dus bij het verliezen van een wiel zou kunnen zijn.
Hypothese voor de filosofen: stel je zou het geld dat je verloren hebt door slecht funtionerende software gebruikt hebben om hongerende mensen te helpen die nu overleden zijn omdat er geen geld beschikbaar was..

Er moet inderdaad een balans worden gevonden tussen:
- wat verwacht je van de software (zoals bijv een OS) en wat doet deze (het blijkt alleen een calculator te zijn), daar kan een ontwikkelaar wel aangehouden worden.
- aan de andere kant, je hebt goed werkende software maar deze wordt (ge/mis)bruikt op een manier waarvoor deze niet ontworpen is, dan wordt het een heel ander verhaal.
Jouw verhaal met je auto zou het erop neer komen dat je van je auto mag verwachten dat deze zijn wiel niet in de eerste 30 km verliest. Behalve wanneer je de auto dwars achter een trein sleept....

[Verwijderd]

Die ontwikkelaars zijn wel erg gemakkelijk met hun handen in onschuld te wassen.

Natuurlijk bestaat het bug-vrije programma niet. Maar dat wil niet zeggen dat we alles maar moeten accepteren. Er is ook nog zo iets als verwijtbaar falen. Iedereen kent stapels voorbeelden van bugs die simpelweg niet zouden mogen voorkomen.

Het is hoofdzakelijk een mentaliteits kwestie. Je moet o.a. defensief programmeren. En dat is iets wat nauwelijks gebeurt. En dat komt waarschijnlijk omdat het ook absoluut niet wordt bijgebracht bij het leren programmeren. Error handling komt pas in hoofdstuk 20 in behandeling... Het zou in hoofdstuk 1 al moeten beginnen. (Ik ben één keer een boek tegengekomen dat dat ook deed! Ging over programmeren in REXX, waarbij goede error afhandeling ook wel een noodzaak is, omdat alles wat oninterpreteerbaar is, als commando naar de environment wordt gestuurd.... )

Die ontwikkelaars moeten eerst maar eens de hand in eigen boezem steken. Er moet nog zeer veel veranderen in hun manier van werken.

[SuperDre]

Het probleem vaak is dat veel klanten de ontwikkelaars zitten te pushen om maar een release te krijgen, en je kunt gewoon niet alles goed testen omdat je gewoonweg niet alles kunt verwachten hoe een gebruiker er mee om gaat..
Kijk als een fout bv optreedt op elke PC bij het opstarten van het programma, tja dat is echt gewoon fout omdat dat simpel te testen was, maar als het van de 2000 klanten maar bij 1 klant voor komt dan is zo'n bug toch al een heel stuk moeilijker te vinden geweest, of een fout wordt dus veroorzaakt door de configuratie van de gebruiker..
Ga er maar vanuit dat mensen die met Vista gaan werken dadelijk ineens rare dingen krijgen met bestaande programma's die in '?:\program files\' staan en ook daar hun data in wegschrijven... Is het dan ook een fout van de ontwikkelaar omdat bv MS iets gewijzigd heeft waardoor jouw programma ineens niet meer werkt, maarja het is een oud programma dus je kan/gaat daar geen nieuwe compile meer voor maken..

[Verwijderd]

Ik ben van mening dat jij wel erg gemakkelijk eenzijdig wijst naar 'de mentaliteit van de ontwikkelaar'. Helaas zijn er aanzienlijk meer factoren die invloed hebben op het al dan niet bug-vrij zijn van programma's. Ik noem hier enkele, vaak voorkomende hiervan (gebaseerd op mijn persoonlijke ervaringen als SD, en nofi uiteraard):

- ontwerpproblematiek
Het maken van goede ontwerpen is een creatief proces. Dus per definitie nondeterministisch, en daardoor niet goed te plannen. Met name bij grotere projecten speelt dit vaak een nogal belangrijke rol, een kleine fout in het ontwerp kan dan verstrekkende gevolgen hebben voor de opleverdatum;

- programmeurs van onvoldoende niveau
Ik heb een aantal keren samen moeten werken met programmeurs die helaas (soms bij lange na) niet het vereiste niveau hadden. Het kost dan steeds weer enorm veel tijd om de productie daarvan te checken en te verbeteren. Dit levert dus programmatuur met enorm veel fouten, en/of (soms opvallend grote) tijdsoverschrijdingen op. Ik ben van mening dat dit voor 100% management probleem is, als de bewuste persoon niet vervangen wordt;

- teveel programmeurs op een project
Ik heb meerdere malen meegemaakt dat er door management onnodig (!) programmeurs aan een project werden toegevoegd, omdat die op dat moment in de leegloop zaten... De kosten van inwerken, extra communicatie (afstemming) en dergelijke, blijken iha. dan zo sterk te stijgen, dat de winst doordat er meer produktie gedraaid zou kunnen worden, daar niet tegenop weegt. Netto is er dan tenminste sprake van geldverlies. Sowiezo heeft ieder project een optimum, waarbij het toevoegen van 1 programmeur leidt tot een produktievermindering, vanwege de toename van overhead. Ik ben trouwens opvallend veel managers tegengekomen, die dit concept niet lijken te kunnen begrijpen, maar van mening zijn dat een deadline voorkomen kan worden door er maar een batterij programmeurs tegenaan te gooien;

- klant wil eindeloos de specs wijzigen, hetgeen door verkoop/management geaccordeerd wordt
Hier valt uiteraard never tegenop te ontwikkelen;

- klant stelt onredelijke deadline, die door verkoop/management geaccepteerd wordt
Dit is een standaard aanleiding tot de oplevering van buggy programmatuur, waarbij de programmeur zijn uiterste best doet, maar gewoon onvoldoende tijd tot zijn (m/v) beschiking krijgt;

- onvolledige randvoorwaarden (infrastructuur)
Ik heb het als SD maar weinig meegemaakt dat de randvoorwaarden die de software-ontwikkelaars nodig hebben om hun werk naar behoren te kunnen doen, voldoende aanwezig waren. Talloos zijn de uren die ik verloren heb zien gaan door het niet goed functioneren of zelfs uitvallen van systemen, gebrekkige informatie-infrastructuur, subtiele werkwijzigingen ten gevolge van vervanging van management, en calamiteiten;

- problemen met 3th-party tools & libs
Ik heb het heel regelmatig meegemaakt dat externe libraries (soms heel subtiele) bugs bevatten. Uiteraard is hierdoor te verliezen tijd (vind-tijd en de wachttijd op een patch) zeer moeilijk inplanbaar, en meestal gebeurt dat ook niet. Terwijl ik hieraan een aantal keren ontiegelijk veel tijd verloren heb zien gaan. En voor de vele compiler bugs die ik ben tegengekomen geldt iets vergelijkbaars, aan je compiler ga je überhaupt pas als laatste twijfelen, dus kun je daar enorm veel tijd aan verliezen;

- niet-optimaal functioneren van mensen
Niet iedereen werkt op elk moment op de toppen van zijn kunnen, per slot van rekening zijn we mensen en geen machines. Dat betekent bijvoorbeeld: één niet ingecalculeerde griepgolf, en je haalt de (iha. niet door de programmeur bepaalde!) deadline niet meer...
Dan is er nog het probleem van mensen binnen een team die elkaar niet mogen, waardoor al ruziënd de feitelijke produktiviteit van die mensen richting nul kan dalen. En is er ook nog zoiets als produktievermindering ten gevolge van overmatige stress.

Dus: defensief programmeren is op zich heel goed, maar het is maar een betrekkelijk klein deel van het totale plaatje.

[BartS12]

Toch opvallend dat er door zo weinig mensen het volgende verschil wordt gemaakt:

- "gewone producten" zoals auto's, magnetrons of videorecorders moeten het goed doen, als ze normaal gebruikt worden. Dat wil zeggen, zonder kwade intentie van de gebruiker, of van buitenaf.

- Van software / OS-en wordt verwacht dat ze het goed doen, ook als ze 'kwaadaardig' gebruikt worden!Lees : hackers, virussen, buffer overflows, etc. Daar moeten ze kennelijk maar tegen kunnen, die boze buitenwereld.

Waarom dit verschil? Omdat er de perceptie is dat het misschien wel zou moeten kunnen , een 100% veilig operating system maken? Terwijl iedereen wel snapt dat het volstrekt onmogelijk is om een auto te maken die bestand is tegen elke vorm van externe sabotage?

[CyberArt]

Volgens mij is dat helemaal niet waar. Bij auto's wordt wel degelijk rekening gehouden met inbraak (hackers), of tegenwoordig met camera's voor het inparkeren, etc. Ook bij magnetrons en andere keukenapparatuur wordt wel degelijk gezorgt dat het deurtje bijvoorbeeld niet open kan als ie aanstaat.

[TromboneFreakus]

Helemaal juist. En bovendien: een magnetron of auto is een gesloten systeem, een pc juist naar haar aard open (welke hard- of software je gebruik is helemaal aan jezelf). Dat maakt het aantal mogelijke combinaties oneindig groot.

[Top-Rob]

De reden dat dat verschil gemaakt wordt, is omdat niet iedereen over de hele wereld zomaar in mijn tuin kan komen en gebruik maken van het slechte slot op mijn achterdeur (ik noem maar wat). Maar op softwaregebied is dit anders: bij een lek in Windows kan IEDEREEN ter wereld ineens de controle over mijn computer overnemen, vooral als de exploit bekend is. Op mijn deur kan ik een beter slot zetten maar v.w.b. van Windows ben ik afhankelijk van Microsoft. Vandaar dat dit bij software dus wat gevoeliger ligt.

Bovendien verwacht ik dat als ik een goed slot koop dat ie ook niet met het kleinste gemak te kraken is: oftewel moet er natuurlijk onderscheid gemaakt worden tussen constructiefouten in Windows (de dief tikt zachtjes op het raam en het raam flikkert ineens eruit) of kwaadwillig gebruik (de dief smijt een molotovcocktail tegen het raam en deze verbrijzelt).

P.S.: Windows slechts als voorbeeld gebruikt, het gaat hier natuurlijk evengoed om andere software.

[chime]

Je zegt het al eigenlijk zelf:

Voor een huis te beveiligen koop je sloten.
Om windows te beveiligen koop je een firewall.

Veel virussen of andere exploits vereisen vaak nog een handeling van de gebruiker: openen van een attachment van een mail. Als het dan fout loopt is het de schuld van de software.
Als er 1 of andere onguur type aan je deur aanbelt, je doet open en wordt overvallen ... ga je dan de aannemer van je huis aanklagen?

Wel dient een ontwikkelaar zijn software zo veilig mogelijk te maken, maar de gebruiker heeft een even grote verantwoordelijkheid om na te denken voordat deze iets doet. (Firewall/virusscanner kopen voordat je op internet gaat, is dit attachment te vertrouwen of niet?)
Komt erbij dat de software ongelooflijk hard evolueert, iets wat een paar jaar geleden nog veilig was is dat nu niet meer (encryptie-technieken zoals WEP bijvoorbeeld)
Maar ja, er zijn natuurlijk ook genoeg auto's die professionele inbrekers in een paar minuten open krijgen zonder bruut geweld te moeten gebruiker

PS. het huis en de autos worden slechts als voorbeeld gebruikt, het gaat hier evengoed over andere producten (kijk maar naar de Amerikaanse toestanden van katten in de microgolf tot kinderen in de wasmachine)

[Verwijderd]

Sloten zijn ze wel veilig.... ze berusten allemaal op het zelfde principe(als ze met een mechanische sleutel werken) ...
En zij dus HEEL simpel te openen DMV "Bump Lock Picking"
als je meer wilt weten kijk eens hier --> http://www.toool.nl/bumping.pdf

zou je daarom de fabrikant van de slot kunnen aanklagen omdat je je inbraak niet vergoed krijgt omdat er geen sporen van schade zijn...

John

[Verwijderd]

Een softwareontwikkelaar die verklaart dat softwareontwikkelaars niet verantwoordelijk zijn. Verrassend....

[SuperDre]

Dat vindt ik helemaal niet zo verrassend (ook niet sarcastisch bedoeld).. Want een gewone gebruiker heeft geen idee met wat voor problemen een softwareontwikkelaar rekening mee te houden heeft of tegen aan loopt. Die ziet bv alleen maar dat het programma op zijn PC niet werkt, maar bij alle ander 99.999 klanten van de ontwikkelaar werkt het wel..

[Verwijderd]

Nou... deze klant ziet dat er nog verschrikkelijk veel programma's 'administrator rights' nodig hebben om te draaien, terwijl daar geen enkele reden voor is. Dat veel programma's hun settings en userdata op verkeerde of zelfs ongeoorloofde plekken wegschrijven. Dat er zelfs nu nog programma's zijn die er maar blind vanuit gaan dat alles op c:\ geinstalleerd staat.

Allemaal volkomen onacceptabel gedrag van software, hetgeen absoluut niet goed te praten valt.

[Verwijderd]

Omdat er een verschil is tussen nalatigheid, en overmacht.

Als je vergeet de bouten op je wiel vast te draaien spreek je over nalatigheid. Als deze bouten afbreken spreek je over overmacht.

Software is tegenwoordig zo complex, met zoveel afhankelijkheden dat het niet meer gaat om nalatigheid.

[kimborntobewild]

Als die bouten afbreken kan dat evengoed nalatigheid zijn (bijv. als men veel te zwak metaal heeft gebruikt).

Software is tegenwoordig zo complex, met zoveel afhankelijkheden dat het niet meer gaat om nalatigheid.

Het creeëren (c.q. niet tegengaan) van overdreven veel afhankelijkheden zou je wel als nalatigheden kunnen zien.

[SuperDre]

Onzin, want anders ben je weer terug bij het oude dos, waar iedereen zelf telkens het wiel opnieuw uitvindt.
Juist het gebruik van afhankelijkheid (zoals die hier genoemd wordt) is de reden waarom software tegenwoordig zo snel klaar is..
Dan komen er natuurlijk ook nog de fouten van de compilers erbij (ofwel fouten die niet in jouw code zitten, maar in de compiler)..

[Verwijderd]

Dat komt omdat met features wil. En beveiling achteraf komt.

Ik ben juist van mening dat je _gesloten_ software moet dwingen financieel en juridisch aangesprakelijk te zijn.

Er zijn namelijk wel degelijk methodes om veiligheid te garanderen:

1. Managed programmeertalen. Bufferoverflows, pointers, etc. De meeste exploits misbruiken gaten die ontstaan door het gebruik van een 'te lage' programmeertaal. Het gebruik van een taal als C voor iets anders dan een driver of interpreter is in mijn ogen per defintie een vorm van nalatigheid. (dat maakt het moeilijker stabiliteit en security te garanderen)

2. Sandboxing: de meest brute-force aanpak die real-time performance kost maar veel garanties oplevert.

3. Theorem provers gebruiken om bepaalde voor de veiligheid relevante eigenschappen ge-automatiseerd te bewijzen. Vergelijk het met een wiskundige formule. Je kan het proberen te bewijzen door allerlei mogelijke test-data, maar het bewijs zal dan nooit sluitend zijn. Je kan het ook bewijzen dmv reducties en inductie.

4. Declaratieve programmeertalen gebruiken: Maak het jezelf makkelijk, gebruik een programmeertaal waar alle bewijsbare eigenschappen afgeleid kunenn worden direct aan de source-code. Dan kan je dus letterlijk een vraag stellen over de werking van je code en een antwoord krijgen. Bijvoorbeeld: "Is het er een permutatie van characters zodanig dat de html-renderer crasht."

Waarom de industrie geen van deze vier zaken serieus toepast? Omdat ze niet financieel worden afgerekent op hun stabiliteit en security.

Ze patchen misschien die zaken die goedaardige hackers ontdekken. Maar dat betekent niet dat er niet al jaren gaten zijn die door bepaalde 'slechte' figuren ontdekt zijn en misbruikt worden. Je kan wel op elke wond een pleister blijven plakken, maar als het kalf verdronken is, dan .. je snapt hem. Je moet van te voren bepaalde garanties kunnen geven over de werking van je code.

De wetenschappelijke wereld heeft de tools al ontwikkeld. Het enige wat nodig is, is dat de commercie gedwongen wordt het te gebruiken. Het zal even pijn doen, en je moet ze een periode van aanpassing gunnen (3 jaar voor desktop-applicaties, 5 jaar voor OS en drivers, etc.). Maar dwing ze verantwoordelijkheid te nemen.

Biedt ze wel 1 alternatief: het opensourcen (dat wil zeggen: niet perse het gratis maken van sourcecode, maar het beschikbaarstellen van source-code aan betalende klanten) als enige juridische alternatief. Op deze manier kunnen de patches en security door 3rd party bedrijven geregeld worden. Dan kan een bedrijf een verzekering tegen hacken nemen, en dan investeert bijvoorbeeld het verzekeringsbedrijf dat de garanties geeft in een risico-analyse van de code.

Alhoewel ik denk dat een bedrijf als Microsoft liever zelf de verantwoordelijkheid neemt, dan dat ze de code moeten openbaren. Het zou ook goed zijn voor de linux commercie. Novell en Red Hat zouden dan dus aansprakelijk gesteld kunnen worden voor geleden schade. Dat zou voor bedrijven een goeie reden kunnen zijn om toch een liscentie te nemen.

[Paul C]

'Mensen houden de ramenfabrikant ook niet verantwoordelijk voor inbraken in hun huis', aldus Fishenden.

Wie vind nog meer de keuze van 'ramenfabrikant' als voorbeeld door een microsoft medewerker een goeie keus

[kimborntobewild]

Geen goeie keus; een raam kan je nog dicht doen. 'T valt op als ie stuk is. Met een OS is dat geheel niet 't geval. Een huis zit ook -tig keer simpeler in elkaar dan een OS.
@XIU:
I know. Bruggetje maken noemen ze dit .

[XIU]

Ik denk dat hij het had over het "Windows" feit

[Bloodshot]

Zie ik het nou te simpel als ik stel dat de programmeurs niet verantwoordelijk zijn voor bugs in hun code, maar het bedrijf wel? (Quality assurance enzo)

Overigens ben ik wel van mening dat misbruikers verantwoordelijk zijn voor de schade die ontstaat door gebruik te maken van bugs.

[elmuerte]

Zelfs formeel geteste programmas kunnen fouten bevatten (zoals een foutieve aanname). Aangezien het verschrikkelijk duur is om programmas formeel te testen word het voor de normale gebruiks software nooit gedaan. Niemand is bereid dat bedrag er voor neer te leggen, en verder duurt het heel lang. Er is een reden waarom instellingen zoals NASA of Thales oude procesoren gebruiken (lees: i386, microSPARC II, etc). Ze hebben jaren gespendeerd om deze procesoren in kaart te brengen zodat ze precies weten hoe het reageerd onder veel omstandigheden. Hier kunnen ze vervolgens rekening mee houden in hus software.

[tjerkw]

Dit is het grootste probleem in de informatica: men probeert dit op te lossen na de zogenaamde Software Crisis: Software werd te laat opgeleverd, kostte teveel geld, en er zaten fouten in.

Bij ons bij de Universiteit Twente Informatica wordt onderzoek gedaan naar model-checking. Men is namelijk opzoek naar software waarvan men naderhand kan verrifieren dat het correct is ( dit kan in de bouwkunde bijvoorbeeld wel).

Er is al veel vooruitgang geboekt , maar het is allemaal nog een beetje omslachtig.

Cox heeft gelijk dat software uitermate complex kan zijn, vooral bij concurrent & distributed systems. Ooit al eens gehad dat je computer niet reageerde? Op helemaal niks? Dan heb je te maken met een DeadLock. Met model checking kunnen deadlocks voorkomen worden, maar zo ver zijn we dus nog niet.

Het ligt dus inderdaad nog niet in het menselijke om perfecte software te schrijven.

[SuperDre]

Dit is gewoonweg onmogelijk om een model te vinden die alle software kan testen.. Dus zo'n onderzoek is gewoonweg weggegooid geld.. Je kunt er dus hooguit bepaalde software mee testen..

Deadlocks voorkomen? hoe wil je dat checken als het dus een combinatie is van jouw software met een specifieke driver.. Niet....

[tjerkw]

Ik zeg niet dat men een model probeert te vinden om alle software te checken. Ik heb het over een manier van software ontwikkelen waarme je software kan checken op correctheid: zodat het deadlock vrij is en bug vrij. (afgezien van semantisch fouten).

Deadlocks voorkomen kan tegenwoordig al heel goed door concurrente modellen op te zetten en deze te testen op toestanden die geen uitgaande transities meer hebben.
Ik heb het niet over de huidige software, dus die specifieke driver waar je hebt over hebt gaat buiten mijn verhaal om.

En nee het is zeker geen weggegooid geld.