Stemsysteem waterschapsverkiezingen blijkt vatbaar voor misbruik

Nadat de politiek vanwege problemen met de veiligheid al besloot te stoppen met het elektronisch stemmen bij de Tweede Kamerverkiezingen, zijn nu ook de plannen voor internetstemmen bij de waterschapsverkiezingen in de ijskast gezet.

In een maandag aan de Tweede Kamer gezonden brief schrijft Tineke Huizinga, staatssecretaris van Verkeer en Waterstaat, dat uit onderzoek is gebleken dat het Ries-stemsysteem vatbaar is voor manipulatie. "Met wat ik nu weet, is het mijn stellige overtuiging dat ik een negatief besluit zal moeten nemen", aldus Huizinga, die hiermee de plannen in de ijskast zet.

Volgens het Eindhoven Institute for Protection of Systems and Information, dat samen met de Radboud Universiteit Nijmegen de veiligheid van het systeem onder de loep heeft genomen, is het systeem onder meer vatbaar voor sql-injectie en xss-aanvallen. In het rapport stellen de onderzoekers bovendien dat het systeem met name vatbaar is voor misbruik door insiders.

Hoewel de staatssecretaris haar definitieve oordeel uiterlijk eind augustus zal geven, betekent deze tussentijdse interventie dat er bij de komende waterschapsverkiezingen in november naar alle waarschijnlijkheid niet via internet gestemd zal kunnen worden. De overheid en de Unie van Waterschappen hoopten met deze mogelijkheid de opkomst voor deze verkiezingen te verhogen.

Ries is ontwikkeld door het hoogheemraadschap van Rijnland en werd eerder al in die regio gebruikt bij verkiezingen. Dit jaar had het systeem zijn landelijke debuut bij de 26 waterschappen moeten maken. Hoewel de broncode als closed source is ontwikkeld, is deze sinds deze week open source. De politiek had daar op aangedrongen vanwege de transparantie en de controleerbaarheid.

Reacties (44)

Connection oCon=null;
Statement oStmt=null;
ResultSet oRs=null;
StringBuffer sbBuffer;


if (_bDEBUG)
System.out.println("BasicHttpLoginModule: Commit");

if (_bSuccess)
{
if (_bDEBUG)
System.out.println("succes");
if (_oSubject.isReadOnly()) {
throw new LoginException("Subject is read-only");
}

try
{
// get connection
oCon =_oDS.getConnection();
oStmt = oCon.createStatement ();

// freeze opr table
sbBuffer =new StringBuffer();
sbBuffer.append("select * from role where operator_id='");
sbBuffer.append(_sUserName);
sbBuffer.append("'");
oRs=oStmt.executeQuery(sbBuffer.toString());

while(oRs.next())
{
assignPrincipal(new RIESRolePrincipal(oRs.getString("role")));
}
oRs.close();
oRs=null;
assignPrincipal(new RIESUserPrincipal(_sUserName));
assignPrincipal(new RIESRolePrincipal("AuthenticatedUser"));
return true;
}
catch (Exception e)
{
throw new LoginException(e.getMessage());
}
finally
{
try{oRs.close();}catch(Exception ee1){/* do nothing*/}
try{oStmt.close();}catch(Exception ee1){/* do nothing*/}
try{oCon.close();}catch(Exception ee2){/* do nothing*/}
}
}

Dit is een stukje code uit BasicHTTPLoginModule.java... Lelijke variabele namen, geen logging framework, onafgehandelde exceptions en zelf SQL statements in de code in elkaar klussen en executen. Nice. Niet echt reclame voor die jongens (m/v) van Magic Choice. Een goede audit had geen slecht idee geweest.

Edit: Nee er zijn wel diverse audits uitgevoerd... Maar als je bv een van de conclusies van de Radbout Universiteit ziet, vraag je je gelijk weer af hoeveel zin zo'n audt heeft:

De gekozen opzet met statische HTML-pagina's die via Javascript-functies
bepalen welke formulieren er precies naar de server worden opgestuurd,
maakt het voor kwaadwillenden lastiger om te begrijpen wat er nu precies
wanneer gebeurt. Bij voldoende tijd is het echter niet moeilijk om met
elementaire kennis van HTML en Javascript te achterhalen wat er gebeurt.

Daarnaast hebben ze ook nog een DDOS aanval gesimuleerd.... met 17 pc's. Zucht.

[Reactie gewijzigd door sys64738 op 1 juli 2008 11:31]

Ik ben het niet helemaal eens met je commentaar

Lelijke variabele namen

Subjectief. Ze gebruiken Hongaarse notatie, big deal. Misschien vind jij dat lelijk, er zijn ook een hele zooi mensen die het handig vinden. Geen argument om code op af te rekenen iig.

geen logging framework

Discutabel.

onafgehandelde exceptions

In dat finally block? Duh, dat is opruim-code. Je bent op dat moment al helemaal niet meer geïnteresseerd in exceptions, je wilt de objecten sluiten en opruimen waarbij het niet boeit of dat fout gaat of niet. Wat moet je nou doen als het wel fout gaat? Nog maar een exception gooien terwijl er mogelijk al een exception gegooid is (het is immers de finally, die ook wordt aangeroepen na de 'throw new LoginException')?

Het enige echte punt wat je noemt is het zelf bouwen van SQL statements in de business layer (dus zonder DAL te gebruiken) waarbij de input ook nog eens niet geescaped wordt. Als je in dit geval een user aanmaakt met de naam "0 OR 1" krijg je mooi alle rechten. Dat is echt prutswerk van de bovenste plank.

[Reactie gewijzigd door .oisyn op 1 juli 2008 11:47]

Toch moet je je wel afvragen of dit door serieuze programmeurs is gemaakt.

B.v. de meeste programmeurs gebruiken Log4j (of soortgelijke frameworks) om logging toe te passen. Geen System.out.

Verder is het een kleine moeite om preparedStatements te gebruiken en zou (als het project wat groter is) zelfs een framework als Hibernate gebruikt (kunnen) worden.
Hier lijkt men niet van een 'de facto' java framework gebruik gemaakt te hebben.

Ongewild leg je hier wel de vinger op een nadeel van dit soort open sourcing. Het is 1 ding om de kwaliteit van de software in het openbaar te laten controleren, maar het is wat anders om de ontwerpkeuzes aan de orde te stellen. Fouten en gevaren elimeren: prima. Maar zolang het project door een bepaalde partij geleid/uitgevoerd wordt heeft die partij de vrijheid om het zo op te bouwen als ze zelf willen.

Het wordt nu openbaar gemaakt omwille van de controle van de veiligheid. Ik vind het dan eigenlijk wat onterecht om opmerkingen over andere zaken te gaan maken.

Als je mening is dat je het zelf beter zou doen, dan zou ik me volgende keer ook aanmelden voor de aanbesteding van een dergelijk project.

Als je mening is dat je het zelf beter zou doen, dan zou ik me volgende keer ook aanmelden voor de aanbesteding van een dergelijk project.

Ik heb niet de kennis of ervaring die nodig is om een dergelijk project succesvol af te kunnen ronden. Het verschil is, ik weet het van mezelf. Het bedrijf dat het project blijkbaar wel heeft toegewezen gekregen niet.

Ik kan eerlijk zeggen dat ik er van overtuigd ben dat ik het tenminste 'minder waardeloos' zou hebben gedaan. Het zou nog steeds niet voldoen aan de veiligheidseisen die je van dergelijke software zou verwachten, maar sql-injection en xss... kom op zeg

Subjectief. Ze gebruiken Hongaarse notatie, big deal. Misschien vind jij dat lelijk, er zijn ook een hele zooi mensen die het handig vinden. Geen argument om code op af te rekenen iig.

Ik vraag me af hoe subjectief dit is: er is genoeg onderzoek gedaan/literatuur beschikbaar dat aangeeft dat het voor de gem persoon/programmeur moeilijker te volgen is. Gezien we niet meer in 1980 leven mag je verwachten dat meer dan een persoon naar de code kijkt. Met dit als perspectief is gemiddelde persoon/programmeur is dus belangrijker dan wat de individu vindt. Zelf als zou het een klein project geweest zijn waar maar een persoon aan hoeft te werken gaat het nog steeds niet op: goede software blijft immers langer bij een bedrijf dan een werknemer. Waarop dus als nog meer mensen naar de code zullen kijken en dus wat de gem programmeur vind uitmaakt.

Wat betreft het finally block: excepties gooien vanuit een finally block leid er mogelijk toe dat andere excepties magisch verdwijnen. Mja het is in ieder geval gecomment, of er iets gelogged moet worden hebben de guru's niet eens consensus over.

Wat betreft het niet gebruiken van een logging framework (java.util.logging / SLF4J / etc) en gaan voor System.out is toch wel een beetje wazig, volgens mij raad bijna elk beginners boek het wel af. Een van de simpele redenen hiervoor is dat je niet op System.out kan filteren natuurlijk je kan gaan greppen op een standaard out maar dan heb je meer informatie nodig dan wat er nu geprint word en om die informatie mee te sturen is het meer werk om met System.out te werken dan gewoon een logger te gebruiken. etc.
Mischien dat .oisyn kan toelichten waarom die stelling discutabel is. Of misschien vond je het discutabel dat er geen logging framework gebruikt werd, dan heb ik het verkeerd geïnterpreteerd sorry.

[Reactie gewijzigd door Mr_Light op 1 juli 2008 18:24]

Je kunt wel 100 valide argumenten aanhalen waarom Hongaarse notatie geen meerwaarde biedt of waarom een logging framework handiger is dan logging via System.out, maar daarbij ga je compleet voorbij aan het feit dat zonder die dingen de code nog altijd geen prutswerk hoeft te zijn, en dát is wat hier gesteld werd. Je zal ongetwijfeld ook wel wetenschappelijk kunnen aantonen dat een accolade-openen op dezelfde regel leesbaarder is dan op een nieuwe regel, maar dat maakt code die dat niet doet ineens kutcode .

Over dat logging, je weet niet wat er nu voor systeem achter zit die de standaard output processed en wellicht filtered. Granted, ik heb ook niet het idee dat dat het geval is, maar feit blijft wel dat dat kan en dat dat ook hier een mogelijkheid is. Dat is dan een designkeuze die zij gemaakt hebben waar ze wellicht gewoon hun redenen voor hadden. Daarom vind ik het discutabel.

Ze gebruiken Hongaarse notatie, big deal. Misschien vind jij dat lelijk, er zijn ook een hele zooi mensen die het handig vinden.

Hongaarse notatie bied geen enkel voordeel in een statisch getypeerde programmeertaal. Een beetje IDE kan je zo vertellen wat elke variabele is.

Daarbij komt dat het in dit geval nogal sullig is uitgevoerd. Je hebt een object geörienteerde taal en je prefixt alle objecten met een 'o', nuttig hoor.

geen logging framework - Discutabel

Hoewel je natuurlijk ook software kan ontwikkelen zonder logging zegt het wel iets over de professionaliteit waarmee het ontwikkelteam tegen de opdracht aankijkt. Het is een f*cking stem-programma. Ik kon me 10 minuten geleden niet voorstellen dat iemand een dergelijke applicatie zou ontwikkelen zonder logging.

Niet dat ik dit soort fouten goed wil praten (verre van dat zelfs), maar in de praktijk wordt nog al eens de snelste weg gekozen en het kost dan weer te veel tijd om uit te zoeken hoe een PreparedStatement werkt...

Als het echter gaat om een systeem dat op het internet moet werken en bedoeld is om stemmingen te verwerken dan is het wel héél erg dom om aan dit soort basic zaken geen aandacht te besteden.

Als ik de naamgeving bekijk dan lijkt het er ook op dat er geen Data Abstraction Layer gebruikt is, da's natuurlijk ook niet zo slim - wat als ik naar een ander database back-end wil overstappen?

* Little Penguin weet wel hoe dit komt, het moet goedkoop (denkt het ontwikkelende bedrijf) en dus wordt er minder aandacht aan kwaliteit besteed .

Het is maar het idee dat een stuk software bouwen zonder vantevoren over structuur, verantwoordelijkheden, DAL's, etc na te denken goedkoper is. De opstap is wat hoger, maar als je structuur eenmaal staat is de applicatie veel makkelijker/sneller/goedkoper te bouwen.

Het bloed komt met uit de ogen als ik dit soort broncode zie. Welk serieus bedrijf schrijft dit soort bagger nou nog anno 2008? Geen (logging-)framework, geen goede exception-handling, geen DAL (O/R-mapper anyone?), en zo kan ik wel doorgaan.

Nou, als je _sUserName een beetje weet te manipuleren, kun je er zeker voor zorgen dat jouw partij wint. Lekker is dat zeg, Nederland wordt met de dag democratischer.

Het is echt gewoon weer het zoveelste mislukte ICT project van de overheid. Misschien zou een aparte minister voor ICT (die ook werkelijk wat van ICT af weet) niet zo'n slecht idee zijn.

Als ik dit allemaal lees heb ik de volgende opmerkingen/overwegingen.

Zolang het de verantwoordelijkheid van de overheid blijft voor het ontwikkelen van een geautomatiseerd stemsysteem zal, omdat de overheid intern geen mogelijk heeft, dit altijd uitbesteed worden. En dan gaan zaken meespelen als niet in de keuken laten kijken, (design) keuzes om economische of andere obscure redenen, geen inspraak door derden enz. Het wordt dus op deze manier per definitie nooit wat.

Het zou n.m.m. een (technische/juridische) uitdaging moeten zijn van de goegemeente en m.n. de leden van tweakers en de sympathisanten van 'wijvertrouwenstemcomputersniet' om met een oplossing te komen. B.v in eerste instantie voor stemmen in stembureaus en daarna op internetstemmen.

Ik begrijp dat er allerlei eisen gesteld moeten worden over traceerbaarheid/vertrouwelijkheid e.d. We moeten echter ook de voeten op de vloer houden. Als we b.v. de hedendaagse eisen over veiligheid 100 jaar geleden zouden hebben toegepast dan hadden we nu geen gas in huis (bij lekkage kun je dood gaan of de boel kan ontploffen) of elektriciteit in huis (ook daar kun je dood door gaan). Om nog maar niet te spreken over het verkeer. Dus 100% vertrouwelijkheid e.d. moet wel worden nagestreefd (over tijd) maar moet niet een strikte eis aan het begin van een evolutie zijn.

Op de vraag of het wel zo nodig snel (zelfde avond de uitslag) moet zou ik willen zeggen dat het bij deze tijd hoort. We zijn door allerlei zaken aan snelheid gewend (snel over de wereld reizen, snel een antwoord op een e-mailtje). Dit wil niet zeggen dat het snel moet maar is wel leuk (kun je de discussie over dit onderwerp voorstellen als iedere volgende slag pas over een week gedaan kan worden omdat de publicaties in een weekblad verschijnen!).

Uiteraard speelt ook de vraag of het economisch wel nodig/wenselijk is. Dit is denk ik moeilijk op voorhand te beantwoorden. Als de overheid het moet uitvoeren dan wordt het al gauw duur (uitbesteden en bedrijven willen uiteraard winst maken en iedere designwijziging om b.v. door vernieuwd inzicht leidt tot hogere kosten) maar als het door de gemeenschap wordt ontworpen dan vallen die kosten in ieder geval mee (Linux is ook gratis). Als dan ook nog 'off the shelf' apparatuur wordt gebruikt vallen die kosten ook nog wel mee. Hierbij zou je in retrospect eens de vraag 15 jaar geleden hebben moeten stellen of we allemaal wel een GSM zouden gaan gebruiken...

Dus personen (m/v) critici maar ook de inventieve geesten op zowel wettelijk als technisch gebied ga iets bedenken dat maatschappelijk geaccepteerd kan worden en begin een site met www.wijvertrouwenstemcomputerswel.nl.

Butch

Is het niet mogelijk om in combinatie met DigID te stemmen? Volgens mij is DigID tot op heden vrij veilig gebleken. SSL-verbinding en een supersimpele statische pagina met alleen checkboxes waarbij je een persoon kunt aanvinken. Vervolgens versturen en opslaan de keuze. Dus geen ingewikkelde pagina met flash/css/xml/javascript zooi om dat soort problemen/veiligheidslekken aan de gebruikerskant te minimaliseren. Het moet toch wel mogelijk zijn op een of andere manier? Ik wil dat internetstemmen namelijk wel de toekomst wordt.

Los daarvan, het is toch wel mogelijk om in samenwerking met de "hackers" en de onderzoekers te werken aan een goed beveiligd systeem? Nu ze weten wat voor zwakheden het systeem kent, zou je zeggen dat ze dat moeten gaan dichten. Vervolgens gaan er weer wat experts hacken en kijken of er nog steeds lekken in zitten. Zit dat er niet in en is er geen kritiek te vinden verder, dan is het systeem toch gewoon bruikbaar? Tuurlijk kan er altijd nog weer een lek gevonden worden, maar dat betekent dat we wel alles op internet kunnen afschaffen omdat in elke software/site wel een lek te vinden is, als je maar lang genoeg probeert/zoekt.

[Reactie gewijzigd door Tjeerd op 1 juli 2008 10:38]

De eventuele veiligheid van DigiD lost problemen in het stemsysteem niet op, het enige dat dan beter beveiligd wordt is het authenticatiedeel.

De stemsoftware zelf is dan niet beveiligd, ook is het maken van statische pagina's geen optie want iedere 4(?) jaar heb je waterschapsverkiezingen en dan zou je dus iedere 4 jaar alle pagina's opnieuw moeten genereren...

Als je met statische pagina's bedoelt pagina's zonder JavaScript, dan ben ik het helemaal met je eens - JavaScript zou voor een stemsysteem helemaal niet nodig moeten zijn idd...

Waarom is het maken van statische pagina's dan geen optie? Zoveel werk is dat niet om 1 set goed geteste statische pagina's per verkiezing te maken. Je zou kunnen argumenteren dat een statische pagina, als die eenmaal goed is gecontroleerd, een betrouwbaarder optie is dan een dynamisch gegenereerde pagina.

DigID zorgt inderdaad niet voor een goed werkend en controleerbaar stemsysteem. Maar het zorgt wel voor een goede, relatief veilige controle van de identiteit van de persoon en dat is alvast 1 aspect dat van belang is -- dat iedereen 1x kan stemmen en zich niet kan voordoen als een ander. Dus binnen de door DigID gecontroleerde omgeving moet je dan een stemsysteem implementeren.

Het maakt helemaal niet uit of het statische pagina's zijn, of (deels) dynamisch.
Daar zit ook het probleem niet.

DigiD mag dan wel een relatief veilige controle leveren, maar feit is dat dit geen veilig systeem is. Je zou vrij makkelijk onder de naam van iemand anders kunnen inloggen en kunnen stemmen. De oorspronkelijke 'eigenaar' van de logincode kan dus niet meer stemmen. (kijk maar wat b.v. de belastingdienst vorig jaar opperde).

Verder moet de stem alsnog in een database worden bewaard.
Met code zoals 'sys64738' heeft laten zien, zal dit nooit veilig kunnen!

Volgens mij is DigID behoorlijk veilig. Natuurlijk hangt deze veiligheid wel samen met hoe zorgvuldig de gebruikers omgaan met hun inloggegevens. Als iemand ergens inbreekt en inloggegevens vindt, kan die zich uitgeven als de andere persoon. Maar dat geldt m.i. voor ELK systeem waarbij je niet persoonlijk ter plekke bent. Dit is dus geen zwakte van het DigID systeem, tenzij jij op de hoogte bent van onveiligheden die ik niet ken natuurlijk.

Kun je wat specifieker uitleggen waarom DigID een relatief veilige controle levert, maar tegelijk geen veilig systeem is?

DigiD veilig? Vorig jaar was het aanbevolen door de belastingdienst dat als je geen DigiD had je wel die van je buurman kon gebruiken. Komt de verschrikkelijke implementatie bij waarbij je zelf een gebruikersnaam moet kiezen. Als je dus een wachtwoord kwijt raakt kun je vrolijk een nieuwe naam kiezen waardoor ik al 3 digid's heb rond lopen. DigiD heeft wat mij betreft niets met identiteitscontrole te maken.

Ik zou het nog iets breder willen trekken. Waarom zouden de waterschappen hiervoor hun eigen systeem moeten laten ontwikkelen (al dan niet met DigID) ? Kan de landelijke overheid niet gewoon één keer een (zij het waarschijnlijk duur) systeem laten maken waar vervolgens zij zelf én de lagere overheden gebruik van kunnen maken?

Als je 1 keer de infrastructuur hebt om een formulier op een beveiligde, aan het individu gekoppelde manier aan de gebruiker voor te leggen en het resultaat daarvan veilig en controleerbaar op te slaan, dan kun je dat toch vervolgens voor allerlei toepassingen gebruiken lijkt me.

Mijn idee...
Inderdaad. Het is van de zotte dat iedere lagere overheid zijn eigen systemen moet ontwikkelen. Zo heeft bijvoorbeeld iedere gemeente tig verschillende oplossingen voor een en hetzelfde probleem. Gevolg hiervan is dat er onnodig veel belastinggeld in ICT projecten wordt gestopt, terwijl dit juist een van de zaken zou moeten zijn die centraal gecoordineerd moeten en kunnen worden.

Het is te zot dat iedere overheid een autonome zeggenschap heeft over dit soort relevante zaken.

Internet is juist een methode om stemmen simpel en toegankelijk te maken, en het mensen niet al te veel moeite te laten zijn om naar de stemcomputers te gaan. Er zullen vast mensen zijn die het niet doen, omdat ze gewoonweg geen zin hebben om na hun werk 's avonds nog even naar de stembus te lopen, en in de wachtrij te staan om een stem uit te brengen: dan denken ze "laat maar", vooral bij verkiezingen voor de waterschappen. Dit is jammer, want de democratie is er juist op gebouwd dat iedereen zijn stem uitbrengt, en er zo een "democratisch" bestuur komt: en dus niet alleen de politiek actieve mensen laten stemmen

Systemen kunnen altijd gemanipuleerd worden, en er zijn altijd wel weer manieren om omheen te komen. Neem bijvoorbeeld de stemkasten die momenteel gebruikt worden bij 'normale' verkiezingen: deze stemcomputers zijn ook gestopt/afgeschafd, omdat ze onveilig zouden zijn.
En dan gaat het om kleine foutjes, dingen die te verbeteren zijn. Ok, ze mogen weer gebruikt worden zodra de nieuwe versie "gemaakt is", die wel veilig zou moeten zijn, maar: er zal toch wel weer een succesvolle hack zijn.

Internet zal ook problemen kunnen hebben, maar ze kunnen het best veilig maken: mits ze goed hun best doen, en geen foutjes als SQL-injectie maken.. want dat is toch wel een "vreemd" zielig foutje. OpenSource lijkt me een prima taktiek, omdat hierbij gezorgd wordt dat veel mensen die het interessant vinden, even kijken hoe dit gemaakt wordt: dit om ideeën op te doen voor je eigen programmeren, en gewoon om te kijken of het wel klopt: het is natuurlijk leuk om te kijken of ze daar fouten gemaakt hebben. Foutcontrole wordt zo goed gedaan, en dit is dan ook "democratisch" voor het hele volk beschikbaar.

Tegen het voordeel van internet in, is het feit dat er niet gecontroleerd kan worden of er vals gespeeld is: bij papieren stemmen of stemmachines is iedereen vrij, en sowieso niet gecontroleerd. Via internet kan er iemand (die jou 'bedreigt') meekijken, of jou beïnvloeden bij je stem. Dit valt niet te controleren.. dat zal nooit kunnen.

Stemcomputers zijn onder andere afgeschafd omdat ze niet goed genoeg "anoniem" zijn, er schijnt elektromagnetische straling vanaf te komen: iets wat bijna valt te verwaarlozen, maar wat wel gebruikt kan worden om te zien wie/wat stemt. Daarnaast zijn ze makkelijk 'te manipuleren' voor de kast open te breken bijvoorbeeld.
Hier een organisatie tegen stemcomputers
Ik denk persoonlijk dat -voor politieke mensen die bij de stemmingen zijn- het ook gemakkelijk is om vals te spelen bij niet-elektronische stemmingen.. dus dan is er ook sprake van mogelijke misbruik. Ze kunnen bijvoorbeeld systematisch wat meer stemmen geven aan de aanwezige partijen (die de stemmen tellen), of gewoon zelf wat stemmen erbij tellen o.d.

Voor de mensen die niet weten wat SQL injectie is. Een beginnersfoutje, doorgaans.
Info over een: xss attack

[Reactie gewijzigd door vmsw op 1 juli 2008 10:16]

Iemand die "geen zin meer heeft om 's avonds nog even naar de stembus te lopen" heeft zich vast ook niet goed verdiept in de beleidsplannen, denk ik dan. Je mag best verwachten dat mensen een klein beetje moeite doen voor de democratie.

En het is inderdaad makkelijk om te frauderen bij een papieren stembureau, er zijn in principe maar 3 mensen altijd aanwezig. Maar er zijn ongeveer tienduizend stembureau's in Nederland, dus het is vrijwel onmogelijk om met dergelijke fraude zetels te winnen. Daarentegen kan een programmeur bij Nedap landelijk een partij een paar procent meer geven. Over stemmen via internet heb ik het al helemaal niet.

Helaas zijn stemcomputers om hele andere redenen afgeschaft (straling e.d.) dus als die "problemen" zijn opgelost zullen de actiegroepen weer door moeten gaan.

Sowiezo is stemmen via het Internet per definitie niet wenselijk, afgezien van technische onmogelijkheid om het goed te implementeren, is er nog een simpele kwestie waar je niet om heen kan.

In een democratie gaat het er juist om dat de stemming geheim is, niemand kan bewijzen wat hij of een ander heeft gestemd, daardoor kunnen mensen niet gedwongen of omgekocht worden om de 'juiste' stem uit te brengen.

Bij stemmen via het Internet kan je je 'kom geld verdienen' stemlokaal oprichten, waarbij je meekijkt met de stemmer en de beloning uitkeert wanneer hij 'goed stemt'.

Rob Gongrijp (je weet wel, oprichter van XS4ALL en van http://wijvertrouwenstemcomputersniet.nl) had het al over "beginnersfouten".

Dat is inderdaad ontzettend slordig, opmerkelijk hoe vaak ik dit soort vreemde zaken nog tegenkom als ik lees over een ICT project. Anyway, het gaat in veel gevallen (ook met de stemcomputers) natuurlijk over theoretisch gevaar. Ja, je zou kunnen zien wie er op wie stemt, maar wie gaat dat in NL nu doen... manipuleren van een stemming kan misschien, maar dan moet dat wel zodanig geraffineerd en tegelijkertijd massaal gedaan worden dat het niet opvalt. Uiteraard moet je daar scherp op zijn, maar ik vind het overtrokken om alles daarom maar af te schaffen, de kans dat dat gebeurt acht ik nog steeds net zo groot als manipulatie met de potlood-wijze. Je zou wellicht beter scherp moeten zijn op vreemde uitslagen van een stembureau en in de tussentijd de boel verbeteren. Zo zonde van het geld anders.

Je vergeet de eerste stap: is het wenselijk om via internet te kunnen stemmen?

Je vergeet de eerste stap: is het wenselijk om via internet te kunnen stemmen?

Een stapje terug nog: is het nodig om via internet te kunnen stemmen?

Even los wat ik van waterschapverkiezingen vind......

De manier waarop mensen moeten stemmen, de manier waarop deze moeten worden en de controle op de telling moet 100% deugen.

Dit kun je zonder ict al niet eens garanderen. En keer op keer blijkt dat zaken gekraakt kunnen worden. Niet alleen stemmachines maar alles wat door de mens is gecodeerd.

En laten we wel zijn, je hoeft echt niet alles naar ict te vertalen. Of alles mogelijk te maken via internet. De absolute noodzaak is er gewoon niet. Enkele jaren geleden stemden we nog gewoon met potloot en de uitslag van de stemming werd ergens aan het begin van de volgende ochtend bekend gemaakt. Dat ging volgens mij prima.

Ik vind het prima om te stemmen met de stemcomputers die het rode potlootje hebben vervangen maar veel verder hoef / moet je denk ik niet eens willen gaan. We weten nu de uitslag al de zelfde avond.

What is next? Tijdens verkiezingen om de tien minuten horen wie er op dat moment voor ligt ? Lijkt mij geen goede zaak want dat beinvloed de manier waarop mensen stemmen. En dan ook nog de grotere veiligheidsrisico's op de koop toe nemen ?

Als het zo nodig moet, laat bedrijven dan maar een systeem maken en dan iedereen uitnodigen om over een periode van 2 jaar ofzo het systeem te kraken. Lukt dat niet, dan is dat bedrijf de gelukkige om hun stem-systeem aan te bieden aan de overheid.

Voor de mensen die het niet kennen, wat is een waterschapverkiezingen ?

Waterschappen zijn een zeer oud, democratisch georganiseerd orgaan die het waterbeheer van een regio doen. Het gaat dan om het onderhoud van sluizen, gemalen, etc., maar ook over bijvoorbeeld grondwaterstanden in polders. Een waterschap werkt als een bestuurslaag met beperkte verantwoordelijkheden. Het bestuur van een waterschap wordt democratisch, dus via verkiezingen, gekozen. Je betaalt als eigenaar van een stuk grond in een waterschap overigens ook belasting aan dat waterschap.

Waarom moet zoiets in hemelnaam democratisch geregeld worden? Dit klinkt als een puur technisch orgaan, dat dus ook bestuurt zou moeten worden door waterbouwkundigen die aangesteld worden op grond van hun kennis en vaardigheden, niet vanwege hun populariteit.

Het beleid van het waterschap heeft wel degelijk een hoop invloed op de lokale situatie. Bijvoorbeeld voor tuinders is de grondwaterstand erg belangrijk. Terwijl voor bedrijven de zuivering van het oppervlaktewater (en mogelijkheden voor lozen op het oppervlaktewater) weer belangrijk zijn. In de beleidsvorming moet vaak worden afgewogen tussen verschillende belangen. Het is dus niet zo gek dat bedrijven en burgers daar op lokaal niveau inspraak in hebben.

[Reactie gewijzigd door mddd op 1 juli 2008 12:42]

Omdat er sprake is van verschillende doelgroepen en belangen. Met het regelen van de waterstanden in rivieren, beken en sloten wordt ook het grondwaterpeil geregeld. En op dat vlak hebben agrariërs, natuurbeheerders, bedrijven en burgers vaak tegenstrijdige belangen, die alleen middels een democratisch gekozen bestuur kunnen worden afgewogen. Waterschappen verzorgen trouwens ook de kwaliteit van het oppervlaktewater dmv zuivering van rioolwater, afgifte van lozingsvergunningen en dergelijke.

Dat is al zo volgens mij sinds de 12e eeuw, het is democratisch geregeld omdat het gaat om de belangen van de ingezetenen en de grondeigenaren (vroegâh alleen de grondeigenaren). Die stemmen dus om inspraak te hebben wat er met water, polder, grondwater ed gebeurt.

Het gaat om de betrokkenheid en het algemeen belang, dan wil je niet dat er een stel technocraten bepalen wat er gebeurt zonder rekening te houden met die belangen.

Het Waterschap is regiogebonden en is in die regio onder meer belast met het onderhoud van wegen en bruggen. Ze worden bekostigd vanuit het rijksbudget en via baten die de inwoners uit het gebied moeten betalen (de zgn waterschapsbelasting). Meer informatie vind je op de website van de Unie van Waterschappen. Bij de verkiezingen voor het waterschap wordt dus feitelijk de waterschapsvertegenwoordiging gekozen.

[Reactie gewijzigd door Wilbert de Vries op 1 juli 2008 10:48]

vatbaar voor SQL injectie? wat een amateurs die ontwikkelaars. Als de broncode meteen open source geweest was, was dit meteen opgevallen....

[Reactie gewijzigd door gassiepaart op 1 juli 2008 09:57]

Open source of geen open source, dingen als SQL injection vulnerabilities zouden uberhaupt niet eens in code mogen zitten. Nogal slordig als je het mij vraagt...zeker als het om dit soort systemen gaat.

[Reactie gewijzigd door SilentThunder op 1 juli 2008 10:02]

Gewoon PHP verbieden, dan ben je van driekwart van het probleem af.

De taal heeft er niets mee te maken. Een incompetente programmeur maakt rotzooi met welke taal dan ook, en iemand die weet wat ie doet kan met elke taal een veilig systeem bouwen.

Het beeld dat PHP 'onveilig' is, komt gewoon voort uit een paar features die vaak gebruikt werden/worden door prutsers en eigenlijk niet hadden mogen bestaan, bv. register_globals of magic_quotes, of het gepruts met PHP en HTML in dezelfde bestanden zodat je hele applicatie een rotzooi wordt en je het overzicht verliest (het niet scheiden van 'view' en 'controller' moet je gewoon niet doen bij software ontwikkeling).

Allemaal dingen die een goede programmeur voorkomt.

[Reactie gewijzigd door Sfynx op 1 juli 2008 19:22]

Ik zal mijn ongenuanceerde uitspraak even toelichten. Jullie hebben helemaal gelijk dat talen als ASP/.NET ook aantrekkelijk zijn voor beginners en slechte programmeurs en dat je in elke taal kan knoeien. Ik bedoelde niet dat de taal zelf persee evil is, al kan je met PHP makkelijk onoverzichtelijk knutselen. Als je een beginnende webprogrammeur vraagt waarin hij schrijft en waarom zal hij 9 van de 10 keer antwoorden 'PHP, omdat het zo hoort'. De kans dat een programmeur die een andere taal kiest zoals TCL of Python of nog iets obscuurders, gewoon zelf nadenkt en weet hoe hij te werk moet gaan is groter en bovendien zitten maatregelen als escaping soms al in de libraries ingebouwd.

Dit vindt ik toch weer het stereotype beeld wat mensen 'vaak' hebben van PHP ,
"Het is in PHP geschreven => onveilig en buggy "

En wil je nu zeggen dat met een andere web-based programmeertaal (*kuch* ASP/.NET)
alle (veiligheids-)problemen uit de wereld zijn zodat iedereen met "Programmeren voor dummies" veilig systeem kan bouwen ?

Bovendien zie ik nergens in het bericht staan dat het in PHP geschreven is.