Tweede Kamer hoeft broncode van Debat Direct-app niet openbaar te maken

De Rechtbank Overijssel heeft een beroep om de broncode van de Debat Direct-app van de Tweede Kamer openbaar te maken, ongegrond verklaard. De Tweede Kamer wil de broncode niet openbaar hebben uit veiligheidsoverwegingen.

De broncode van de Debat Direct-app is niet feitelijk al openbaar en de Tweede Kamer valt niet onder de Wet openbaarheid van bestuur, waardoor de broncode ook niet openbaar gemaakt hoeft te worden. Dat vonnist de Rechtbank Overijssel. Debat Direct is een gratis app waarmee vergaderingen van de Tweede Kamer te volgen zijn. "Bij het omzetten van de ene vorm naar de andere vorm, van broncode naar app, gaat er veel waarde verloren, wat reeds impliceert dat de informatie die de app bevat en die de broncode bevat niet een-op-een overeenkomen", stelt de rechtbank. Aan de beoordeling of de broncode geldt als informatie neergelegd in documenten wordt niet toegekomen.

Jos van den Oever, technology advisor bij Stichting NLnet en deskundige op het gebied van vrije software en open standaarden, verzocht de voorzitter van de Tweede Kamer begin 2018 om de broncode van de Debat Direct-app aan hem te verstrekken. Die app is alleen beschikbaar voor iOS, Android en Windows. Van den Oever gebruikt Linux en wilde de app zelf aanpassen, zodat die op dat besturingssysteem kan draaien.

De Tweede Kamer heeft auteursrecht op de broncode van de app en zou dus tot publicatie kunnen overgaan, maar weigerde dit. Als reden noemde de Tweede Kamer dat de broncode niet openbaar is en er ook geen verplichting is deze open te stellen. Daarnaast beriep de Tweede Kamer zich op mogelijke veiligheidsrisico's. Openbaarmaking zou tot 'manipulatie van het informatiekanaal kunnen leiden'. Daarbij beargumenteerde de Tweede Kamer dat de app zoals gebruikers die draaien, en de backend op de systemen van de Tweede Kamer, twee delen van een geheel zijn.

Hier stelde de eiser tegenover dat de communicatie tussen de servers van de Tweede Kamer en clients ook zonder broncode te analyseren is. "Ik vind het onveilig om de broncode niet openbaar te maken. Het gaat hier om software die wordt uitgevoerd op mijn telefoon, niet op de servers van de Tweede Kamer", schreeft Van den Oever vorig jaar op iBestuur.

Van den Oever erkende dat Wet openbaarheid van bestuur niet van toepassing is op de Tweede Kamer en beriep zich daarom op de Wet hergebruik overheidsinformatie. De Who is bedoeld om burgers de herbruikbare vorm van publieke informatie te geven. Zowel de app als de daaraan ten grondslag liggende broncode is volgens hem aan te merken als informatie die is neergelegd in documenten als bedoeld in de Who. De rechtbank ging hier niet in mee. Van den Oever beraadt zich nog op een gang naar de Raad van State. De Tweede Kamer gaf volgens hem tijdens het proces wel aan dat nieuwe projecten misschien openbaar gemaakt worden. "Daar heb ik nog niets van gezien", aldus Van den Oever.

Hij kreeg tijdens zijn initiatief bijval van de Free Software Foundation Europe, die onder andere campagne voert voor openbaarmaking van publiek gefinancierde software als vrije software, onder de noemer Public Money, Public Code. Nico Rikken van de FSFE wees er eerder tegenover Tweakers al op dat de Wet hergebruik overheidsinformatie de Nederlandse implementatie van de Europese Public Sector Information-richtlijn betreft. "In die richtlijn staat expliciet dat het niet de bedoeling is dat software eronder valt. Deze uitzondering is echter niet overgenomen in de Nederlandse Who en dus lijkt het mogelijk om de broncode van de Debat Direct-app op te vragen", stelde hij toen.

Reacties (116)

De volledige uitspraak is hier te lezen: https://uitspraken.rechts...id=ECLI:NL:RBOVE:2020:848

Een correctie op dit stuk: in het stuk staat dat de rechter er niet in meegaat de broncode informatie neergelegd in documenten is. Daar doet de rechter geen uitspraak over. (Een Franse rechter had dit al vastgesteld). De rechter zegt dat broncode niet de herbruikbare vorm van software is. Dit is, vanuit het perspectief van een softwareontwikkelaar, een zeer opmerkelijke uitspraak.

Bron: ik was de klagende partij in deze zaak.

Ik was een van de mensen die aan Debat Direct ook had gewerkt, en bij de presentatie aanwezig was.
Wat houdt je tegen om met de API waarmee gesproken wordt (en die gewoon uitgelezen kan worden), je eigen app te ontwikkelen ?
Als de API openbaar is, en gewoon gebruikt mag worden (geen idee waar je dat sowieso kan vinden deze info), kun je net zo goed je eigen app ervoor schrijven... Of was dat weer teveel werk enzo ? De software is niet gepubliceerd onder een open source licentie, maar goed, wat een gezeur. Gebruik dan gewoon een wrapper om de Android app of WINE gebruiken om hem daarop te gebruiken... pffft.

[Edit] Om sarcastische opmerkingen te voorkomen, ik weet zelf niet of de API publiekelijk is of niet, maar je zou wellicht dit kunnen navragen aan de beheerder van die API. Volgens mij is er vast wel iets over te vinden, maar het is al weer wat jaartjes geleden dat ik eraan gewerkt had.

[Reactie gewijzigd door Power2All op 3 maart 2020 08:10]

Wat houdt je tegen om met de API waarmee gesproken wordt (en die gewoon uitgelezen kan worden), je eigen app te ontwikkelen ?

De API is niet publiek. Ik zou de API moeten reverse-engineeren.

De app bestaat al. De app aanpassen is een bescheiden inspanning. Een volledig nieuwe app schrijven is veel werk. Ongetwijfeld heeft jouw werkgever daarvoor betaald gekregen. Het doel van de Wet hergebruik overheidsinformatie (die is aangenomen door de Tweede Kamer) is om dat werk, dat met overheidsgeld is gedaan, zo nuttig mogelijk te maken voor de maatschappij en het dus ter beschikking te stellen voor hergebruik.

De API is niet publiek. Ik zou de API moeten reverse-engineeren.

Mag je zo'n API zomaar gebruiken? Volgens mij kun je daar geen rechten aan ontlenen. Men mag daar beperkingen over opstellen.

Verder is Android/Java naar ik heb begrepen niet moeilijk te reversen.

Hangt er vanaf. Als de APIs gewoon publiek staan en er geen contract getekend moet worden voor toegang weet ik niet welke rechten men denkt te hebben (behalve het recht alles steeds anders te maken). Overigens in de in de USA een zaak gaande tussen Google en Oracle of een API patenteerbaar is. Als die doorgang vind dan wordt het wel redelijk eng.

Normaliter is het zo dat wanneer er geen licentie (of terms & agreements etc) beschikbaar is waarin staat dat je het vrij mag gebruiken je het niet hoort te doen. Je zult dan toestemming moeten vragen van de rechthebbende. Als het gaat om een bedrijf of instantie is het vaak zo dat de software niet expliciet openbaar wordt gezet. Een stuk software reverse engineeren om zelf stukken te (her)gebruiken is in sommige gevallen zelfs straftbaar.

Een simpele vraag die je jezelf kunt (lees: zou moeten) stellen is: Is het voor mij duidelijk dat ik deze API(s) mag gebruiken?
a. Ja. Top. Doen!
b. Nee. Oef, niet doen
c. Twijfel. Oef, niet doen

Ik spreek hier over APIs. Ik vraag me af als je een onbeveiligde REST service neerzet die RebootServer heet en ik roep hem iedere 5 minuten aan via een Wget je iets doet wat strafbaar is. Alhoewel de wet zegt dat als je "door een technische ingreep," iets doet je al strafbaar bent ben ik idd. bang dat je bij de recht bakzeil haalt tenzij deze snapt dat wat je doet geen technische ingreep is maar gewoon gebruik maken van slecht ontworpen APIs.

Het ontwerpen & de beveiliging ervan ligt in dat geval bij de ontwikkelende partij(en). Er zal altijd een stukje common sense bij komen kijken. Wanneer je je uiterste best doet om een service plat te leggen zul je je in de rechtzaal ook moeten kunnen verwoorden. Maar als ik jouw voorbeeld letterlijk neem klinkt het alsof de ontwikkelende partij verantwoordelijk is.

android !=/!~= java !!!

dat grote delen van de android code gebaseerd is op de java syntax (sytax is door mensen te lezen interpretatie van een programmeertaal), maakt nog niet dat ook de bytecode lijkt op die van java. sterker nog die verschilt bijna evenveel als die van bijv een c++ app. Dalvik en ART enz gebruiken een heel eigen bytecode generator met hun eigen routines en optimalisaties. één van de belangrijkste redenen van de conflichten tussen sun (later oracle) en google was nu juist dat google die optimalisatie welden en dat men daar niet in wilde meegaan.

Er zijn wel tools om Android-apps te decompilen. Hier komt natuurlijk nooit de originele bron uit terug, maar wel meer dan genoeg om e.e.a. aan te passen, opnieuw te compilen, en deze class te injecten in de bestaande app. Dit wordt veel gedaan voor game hacks op Android, maar zo werkten bijv. ook WhatsApp+ en een aantal van de alternatieve Snapchat-clients.

Uiteindelijk zal het vele malen makkelijker zijn om de API te gebruiken in een eigen wrapper, maar in principe is het mogelijk om de app zelf aan te passen, tenzij de code geobfuscate is.

> wat een gezeur

Dat hangt er maar helemaal van af wie er voor de ontwikkeling van die app betaalt heeft. Is dat de belastingbetaler dan zou de broncode gewoon onder een O.S. licentie moeten worden vrijgegeven.

Kijk, dit vind ik nou een geweldig standpunt. Ik weet niet hoe het nu wettelijk zit, maar ik vind dat wij als belastingbetaler volledige inzage moeten hebben in alles waar ons geld aan besteed wordt. Dat wil niet zeggen dat wij allemaal individueel rechten hebben over deze resultaten, maar wij zouden dus wel toegang moeten hebben tot de broncode van deze software en bijv. de website van de belastingdienst IMO. Als developer zet ik veel vraagtekens bij de manier waarop sommige dingen werken, ik zou graag willen zien of het er allemaal aan de binnenkant net zo slecht uit ziet als aan de buitenkant.

Hoef je niet veel voor te doen.... gewoon solliciteren en dat proces met succes afronden. En als je vermoedens bewaarheid worden kun je dan meteen meehelpen om dat te fixen en wordt je er nog door de overheid voor betaald ook.

https://werken.belastingd...essionals/ict?q=Developer

Owww! Wat is probleem? Doe mij even het linkje van die API documentatie! Ik klim gelijk in de IDE!

De rechter zegt dat broncode niet de herbruikbare vorm van software is

Bij dit soort interpretaties van uitspraken verwacht ik toch wel enige context. En die lijkt te gaan om beroep op de Wob en hoe de betekenis van de term hergebruik binnen de Wob hier niet van toepassing zou zijn. Omdat de Tweede Kamer niet onder de verplichtingen vanuit Wob valt en dus ook niet onder het hergebruik. Dus niet dat broncode in het algemeen niet de herbruikbare vorm van software is.

De Who is van toepassing op informatie die via Wob verkregen kan worden, maar ook op informatie die al openbaar is. De app is al openbaar en de Who is van toepassing op de app. De app wordt gepubliceerd in een vorm die niet herbruikbaar is. Onze redenering is dat broncode de herbruikbare vorm van de app is. In de uitspraak staat dat, omdat broncode meer informatie bevat, namelijk variablenamen en commentaar, de broncode niet de herbruikbare vorm van de software is.

Als de overheid een grafiek publiceert, kun je de onderliggende data opvragen. Als een kaart wordt gepubliceerd kun je de onderliggende coordinaten opvragen. Als software wordt gepubliceerd kun je de broncode opvragen. Of die vraag gehonoreerd wordt, hangt af van de interpretatie van wat de herbruikbare vorm is.

https://wetten.overheid.nl/BWBR0036795/2016-10-01

Maar dat lijkt mij wat anders dan een conclusie dat de rechter stelt dat broncode niet de herbruikbare vorm van software is.

Dat maakt de bevinding over het een-op-een principe niet minder opvallend:

Bij het omzetten van de ene vorm naar de andere vorm, van broncode naar app, gaat er veel waarde verloren, wat reeds impliceert dat de informatie die de app bevat en die de broncode bevat niet een-op-een overeenkomen.

De term informatie lijkt me hierbij belangrijk. Er kunnen veel gegevens verloren gaan maar dat wil nog niet zeggen dat de informatie dus een-op-een verloren gaat. Neem compressie als voorbeeld. De gegevens zijn na verwerking een-op-een niet meer hetzelfde in representatie maar de informatie is wel degelijk uit terug te halen.

wat mij verbaasd in deze is toch wel dat de juristen aan julie kant deze kans niet hebben voorzien.

bij deze inzet zou ik niet alleen om broncode maar subsidiair ook om api-toegang hebben verzocht.

je kunt namelijk zeggen dat broncode meer is dat de herbruikbare vorm van software, maar je kunt ook zeggen dat een volledige beschrijving van de werking van die software minder is dan dat geheel. maar desondanks een redelijk compromis kan vormen.

Met de openbaarmaking van die api kun je zoals power2all al aangaf op zijn minst een compatible client bouwen. met afdoende documentatie en de nodige reverse-engenering (of decompiling) moet dat zeker mogelijk zijn.

het verhaal dat de api niet openbaar zou zijn is natuurlijk onzin, want iedere client praat er al tegen en de informatie die via die weg wordt aangeboden is ook van een aard dat daar zo min mogelijk restricties op liggen.

Link naar het vonnis toegevoegd (had er natuurlijk meteen in moeten staan) en citaat uit de uitspraak toegevoegd.

Bedankt, alle lof voor je inspanning!

Jammer dat het in 2020 nog nodig is te vragen (public money/public code) om source code, laat staan dat het nodig is ervoor naar de rechter te stappen

Zoals ik het lees wordt de broncode niet openbaar gemaakt omdat de tweede kamer niet onder de WOB valt. Daarnaast stelt de rechtbank ook dat de broncode van de app niet hetzelfde is als de app. Dit roept bij mij vragen op!

Met verweerder is de rechtbank van oordeel dat de vrij te downloaden app niet hetzelfde is als de broncode die daaraan ten grondslag ligt.

Dit zegt dus specifiek dat de vrij te verkrijgen app niet dezelfde applicatie is als de broncode, oftewel heb je een broncode in machine-readable formaat, en een apart stuk sourcecode die niet openbaar gemaakt kan worden. De rechtbank is volgens mij in dit opzicht dus verkeerd ingelicht. Als eiser had je vervolgens hier op moeten reageren door te stellen dat de machine-readable formaat een afgeleide is van de broncode, en de broncode zo gemanipuleerd kan worden dat het machine-readable formaat specifiek aangepast kan worden voor een bepaald toestel. Door mee te gaan in het feit dat de vrij te downloaden app gelijk is aan de broncode, heb je gesteld dat de machine-readable code gelijk is aan de broncode (ze verschillen in vorm).

Voor de mensen die, net als ik, niet zo in de Tweede Kamer debatten zitten:

https://www.tweedekamer.nl/debat-direct

De vergaderingen in de Tweede Kamer zijn gemakkelijk te volgen met de gratis app Debat Direct.

Tip voor de nieuwsredactie; geef even kort aan wat het product/dienst betreft die je in een artikel bespreekt. Ik had nog nooit van Debat Direct gehoord, uit het artikel wordt het ook niet duidelijk.

Tip voor de nieuwsredactie; geef even kort aan wat het product/dienst betreft die je in een artikel bespreekt. Ik had nog nooit van Debat Direct gehoord, uit het artikel wordt het ook niet duidelijk.

Tip voor jou: zet feedback in het feedback forum en verwittig de auteur, zoals @Olaf voor een correcte afhandeling.

edit:
Om niet alleen te zeiken maar ook initiatief te nemen tot verbetering, heb ik een topic voor je gestart.

[Reactie gewijzigd door 84hannes op 2 maart 2020 19:30]

"Daarnaast beriep de Tweede Kamer zich op mogelijke veiligheidsrisico's. Openbaarmaking zou tot 'manipulatie van het informatiekanaal kunnen leiden'." - dat is toch gewoon toegeven dat er veiligheidstechnisch gaten in zitten?

Nouja, hoe meer mensen toegang hebben tot de app of de code, hoe groter de kans dat er beveiligingsproblemen worden gevonden. Als deze niet gevonden worden kunnen ze ook niet misbruikt worden.

Als deze niet gevonden worden kunnen ze ook niet misbruikt worden.

Als ze niet gevonden kunnen worden, inderdaad. Echter kan je een android apk ook gewoon unzippen, dus wie beveiligingsgaten zoekt kan ze nog gerust vinden (en wie echt wilt kent waarschijnlijk nog wel wat meer methodes). In de browser kan je ook gewoon geminimaliseerde code inkijken. Enigste nadeel bij een apk of geminimaliseerde code vergeleken met de broncode zijn de geobfusceerde variabelen, die het moeilijker maken voor degene die uit de broncode wilt leren of eens kijken hoe iets werkt. Een aanvaller gaat daar geen probleem mee hebben vermoed ik.

Verder blijft gelden dat security through obscurity geen echte security is. Kijk maar naar SSH, Signal, Matrix, encryptie, ... : daar heb je echte security en kan je de broncode dus gewoon publiek maken. Enkel met de sleutel kan je geencrypteerde data lezen.

Edit: ik zeg niet dat het onveilig is omdat ze de broncode niet willen vrijgeven, enkel dat als het veilig is, security geen probleem vormt voor het vrij te geven.

[Reactie gewijzigd door bertware op 2 maart 2020 17:20]

Als ze niet gevonden kunnen worden, inderdaad. Echter kan je een android apk ook gewoon unzippen, dus wie beveiligingsgaten zoekt kan ze nog gerust vinden (en wie echt wilt kent waarschijnlijk nog wel wat meer methodes).

Echter is het nu wel zo, dat je eerst de code moet terughalen middels reverse engineering, wat niet per se de daadwerkelijke code hoeft op te leveren. Ook voor de Android app geldt dit. Het is niet dat de sourcecode leesbaar verpakt zit in de .apk die in de Play Store staat.

Verder blijft gelden dat security through obscurity geen echte security is.

Doordat de code niet gedeeld wordt, betekend niet automatisch dat de app (on)veilig is. Nu zit dat in het ongewis, maar beiden zouden dus goed kunnen. Van security through obscurity is dan ook niet echt sprake; verder dan een 'zou kunnen dat het onveilig is' komt het nu niet.

Men beroept zich WEL op de veiligheids issues. Dus blijkbaar is met niet zeker van de zaak dat de site veilig is tegen manipulatie van data.
Mogelijk moet de 2e kamer een audit laten doen op de software?

WC Eend moet WC Eend gaan adviseren?

(Hoewel de Tweede Kamer iets anders dan degene die eigenaar is van deze 'Debat Direct' app, komt er uiteindelijk wel politiek achter te zitten dat een mening moet gaan vormen)

[Reactie gewijzigd door CH4OS op 2 maart 2020 18:56]

Echter is het nu wel zo, dat je eerst de code moet terughalen middels reverse engineering, wat niet per se de daadwerkelijke code hoeft op te leveren. Ook voor de Android app geldt dit. Het is niet dat de sourcecode leesbaar verpakt zit in de .apk die in de Play Store staat.

Enige wat ze hoeven doen is de apk ver genoeg te reverse-engineeren om uit te vinden waar HTTPS verbindingen opgebouwd worden en daar haak je in met wat extra logica om de plaintext request en respons te loggen.

Vervolgens recompilen en draaien en kijken wat er over de verbinding gaat. Daar vanaf kun je een paar onderbouwde aannames maken over hoe de communicatie-protocollen van de app werken en kun je bijv. authenticatie-sleutels onderscheppen.

Blijken die bijv. constant te zijn en is het dus een simpele account/wachtwoord combinatie dan kun je al los en proberen op het netwerk in te breken en data te gaan plunderen.

Je hoeft echt niet de volledige werking van de interne app voor de volle 100% te gaan doorgronden.

Het ging in het verzoek juist om de broncode van de app, niet de data dat verstuurd wordt over en weer. De data die over de lijn gaat is niet het interessantste.

Enigste nadeel bij een apk of geminimaliseerde code vergeleken met de broncode zijn de geobfusceerde variabelen, die het moeilijker maken voor degene die uit de broncode wilt leren of eens kijken hoe iets werkt. Een aanvaller gaat daar geen probleem mee hebben vermoed ik.

Ik heb source code gezien waarbij de namen van variabelen en comments de code niet beter te begrijpen maakten. Maar dat waren uitzonderingen. Zelfs de meest beroerde code is over het algemeen beter te begrijpen met variabelnamen en comments. Dat een aanvaller daar geen enkel probleem mee heeft lijkt me dus sterk, het zal hem zeker vertragen.

Onderschat de kracht van refactoring en decompiling niet. Je hoeft vaak niet de hele software onder de loep te nemen. Dit is een Java applicatie. Stel je ziet ergens de API call: Runtime.getRuntime().exec() gebruikt worden (en dat staat ook in de decompiled versie zo: dit zijn systeem APIs en die moeten 1-op-1 in de gecompileerde versie staan). Dan ga je vanaf daar terug tracen naar de UI om te zien of je er iets in kunt proppen wat de bouwer niet verwachte. Dat kan bijna geautomatiseerd.

Maar dat is dus een typisch argument van 'security through obscurity' en dat is al jaren afgewezen als een goede beveiligingsmaatregel.

Aan de ene kant maak heb je gelijk dat je het met openbaring van de bron makkelijker is om zwakheden te vinden, aan de andere kan iedereen ze dan vinden en melden. Mensen die zwakheden zoeken zullen ze toch wel vinden en als het niet kan door broncode door te spitten dan proberen ze het wel door verzoeken te onderscheppen en analyseren.

Daarnaast valt er ook veel voor te zeggen dat het Tweede Kamer word gefinancieerd met publieksgeld en dus standaard beschikbaar zou moeten zijn voor de bevolking, tenzij het van gevoelige aard is en dat is hier (wat mij betreft) maar de vraag. Alle informatie die de app beschikbaar maakt moet/is al ergens anders openbaar gepubliceerd.

Ligt eraan, ik vind dat argument “security by obscurity is no security” altijd een dubbelzijdig zwaard en niet zo zwart/wit. Obscurity kan bijdragen aan het minder makkelijk maken van een aanval, waardoor het als extra laag niet perse kwaad kan. Je moet er niet vanuitgaan dat het werkt en als enige maatregel is ‘t waardeloos, maar het heeft zeker zo z’n usecases.

Wat ik lees is dat men risico's ziet. En een risico kan veel diverser zijn dan alleen beveiliging. Hoewel er een beveiligingsvoorbeeld is gegeven zijn er waarschijnlijk nog tal van andere risico's te bedenken die niet perse onder afgewezen vallen. De eerste vraag is dus welke risico's men allemaal kan zien. Want dan valt er ook te discussiëren onder welke omstandigheden die risico's wel of niet van toepassing zijn. Simpel stellen dat through obscurity is afgewezen lijkt me hier waarschijnlijk niet werken als argument.

Je kan het ook andersom zien: hoe meer mensen toegang hebben tot de code, hoe groter de kans dat er beveiligingsproblemen worden gevonden, aangekaart en verbeterd.

Dat is het hele idee van open source software.

Dat werkt goed wanneer de software heel diffuus gebruikt wordt. Niet wanneer het voor een specifieke organisatie of doel is.

Grofweg om 3 redenen;
Als je veel gebruikers wereldwijd hebt zijn dat allemaal kleine aanvalsdoelen, i.p.v. 1 bullseye. Dus het gevaar (per doel) is kleiner.
Daarnaast heb je veel meer contributors en dus veel grotere kans dat bugs worden gevonden en daarna gefikst.
Ten slotte heb je zowel (bijvoorbeeld) Russen en Amerikanen die het zowel willen gebruiken als willen kraken, wat het van beide kanten in balans houdt. Als er een tool is die maar door 1 kant wordt gebruikt (en dus door de andere kant wordt gekraakt) is open source juist een risico.

Kijk we zouden best de app en API kunnen reverse engineeren, dat is niet zo gek moeilijk, maar kost gewoon wat tijd. Als Rusland of de VS deze app zouden willen 'hacken', op wat voor een manier dan ook, hebben deze echt wel de mogelijkheden, geld, en tijd om dit gewoon rustig te reverse engineeren. De enige groep die je het hier moeilijker maakt is de burger, en ik denk dat dat geheel onterecht is.

Niet zo gek moeilijk misschien, maar toch wel aanzienlijk moeilijker dan als je de api/source bekend maakt. Als dat bij jou niet zo is dan is je code denk ik niet zo strak.

Het is zeker mogelijk, maar als het meer moeite kost voor dezelfde uitkomst is het wel minder interessant.

hoe meer mensen toegang hebben tot de code

Toegang hebben tot de code verandert niks aan de kans op het vinden van bugs, daar verandert pas wat aan als er daadwerkelijk naar de code gekeken wordt, door mensen met kennis.

Je kan het ook andersom zien: hoe meer mensen toegang hebben tot de code, hoe groter de kans dat er beveiligingsproblemen worden gevonden, aangekaart en verbeterd.

Dat is het hele idee van open source software.

De andere minder zonnige kant is dat er ook types tussen zitten die het willen gebruiken voor minder goede doeleinde en het als chantagemiddel gaan gebruiken.

Open source heeft altijd 2 kanten.

Security by obscurity bestaat deels omdat men niet te overtuigen is dat de nadelen minder zwaar wegen dan de voordelen. Dus wat is je inbreng als iemand stelt dat de voordelen niet opwegen tegen de nadelen? En het antwoord dat men het simpelweg fout heeft of dat men dat zelf maar moet bewijzen is alvast geen passend antwoord omdat die antwoorden het probleem niet weg nemen maar hooguit verleggen. Hoe neem je hun zorgen weg zonder alleen maar te wijzen naar de voordelen?

ik weet niet precies hoe het zit maar als het closed is, dan is de toegang ook bekend wie er toegang heeft. Bij open source kan je er dus een uurtje ofzo toegang tot hebben (een hack) en hele databases van gebruikers en wachtwoorden binnen halen en niemand weet wie dat even was.

Closed source kan ook ge-reverse-engineerd (wat een woord) worden.
Dan kunnen de databases als nog leeg geplukt worden.

Je mag hopen dat er betere software wouwers bezeig geweest dan an een database als open access op het internet aan te bieden. Dat is het recept voor problemen.

"Open source = veel ogen = veiliger" is een onzin uitspraak die niet klopt in de praktijk (ook al is het een erg mooi idee). Dat wordt elk jaar weer bewezen. Val niet in dit gat en gebruikt dit a.u.b. niet als argument om software open source te maken. Dit is een brak argument wat niks toevoegt.

Leef je onder een steen?

QEMU - VENOM https://access.redhat.com/articles/1444903
OpenSSL - Heartbleed https://www.us-cert.gov/ncas/alerts/TA14-098A [en](http://www.pcmag.com/article2/0,2817,2457614,00.asp) nog [meer](http://ccsinjection.lepidum.co.jp/) vulnerabilities.
Bash - Shellshock https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-6271
Linux Kernel - https://threatpost.com/cr...system-compromise/149325/ https://www.theregister.c...ch_against_12yearold_bug/

*Jaren* lang, soms zelfs *decaden* lang, onder het mom "Het is veilig want veel ogen kijken mee". Leef maar lekker verder onder die steen. Dit is allemaal algemeen bekend.

Hoeveel "jaren oude serieuze security issues" moet ik hier nog plaatsen voor je? 100? 1000? Noem maar, we komen er wel.

Dit zijn overigens niet kleine open source projecten met 1 developer, maar mega projecten die door miljarden apparaten en gebruikers gebruikt worden (!) en ook commercieel ondersteund worden door verschillende partijen.

In plaats van mij een bewijs laten leveren van iets wat algemeen bekend is, plaats jij maar eens bewijs dat open source veiliger is dan alternatieven.

Die -1's komen dus voornamelijk omdat mensen de waarheid niet in kunnen zien? Of door iets anders? Verder prima hoor. Ik leef in ieder geval niet onder het valse gevoel dat open source perse veiliger is.

Zeggen dat open source veiliger is krijgt dan weer wel + moderaties.. rara. Zowel mijn reactie als die andere reactie (beide zonder onderbouwingen, mijne is nu wel onderbouwd) zijn of samen on topic (+) of samen niet on topic (-). Als je met iets niet eens bent is de -1 daar niet voor.

tl;dr: Het is gewoon een feit dat de uitspraak "open source = veiliger dan alternatieven" niet klopt. Alle software heeft security issues, en alle software kan serieuze security issues bevatten. Hou op met "O.S. = veiliger" leugens te verspreiden.

[Reactie gewijzigd door grasmanek94 op 3 maart 2020 09:40]

Hoe meer mensen toegang hebben tot de code, hoe sneller beveiligingsproblemen gevonden worden en opgelost kunnen worden.

Hoe meer mensen zien wat voor fouten je maakt hoe schadelijker dat voor je reputatie kan zijn. Voor iedere positieve kan valt een negatieve kant te geven. Hoe neem je die negatieve kanten weg als je de ander niet enkel kan overtuigen met de voordelen die je ziet?

Maar ook: hoe sneller ze gevonden kunnen worden door mensen met goede bedoelingen en hoe sneller ze opgelost kunnen worden. Het vinden van beveiligingsproblemen op zich is niet het issue. De tijd die nodig is om het op te lossen is dat wel. En het lijkt mij dat bij gesloten applicaties de kans kleiner is dat mensen met goede bedoelingen er veel onderzoek naar doen.

Het blijft nogal haken in de redenatie dat er voor- en nadelen zijn. Maar als je iemand wil overtuigen en je voordelen worden niet als waardevoller gezien dan de nadelen, hoe ga je dan de nadelen wegnemen?

Diezelfde nadelen spelen ook voor closed source, alleen dan met een iets hogere drempel tot reverse-engineeren, waardoor je dit waarschijnlijk alleen gaat doen als je al specifieke intenties hebt.
Het wegnemen van de nadelen is dus niet relevant, aangezien de nadelen niet uniek zijn voor open source.

Daarnaast is de time to fix langer, als je een fout vindt en aangeeft bij de ontwikkelaar, dan moet die deze nog steeds zelf herstellen. Een oplossingsvoorstel direct in je repository krijgen, die meteen door anderen gereviewed kan worden, is dan potentieel veel sneller.

Onder het mom van "Als je een beerput dicht laat, heb je er ook geen last van."

Nee, volgens mij is hun redenatie iets anders. Zodra jij als gebruiker de content (live stream, stemmingsuitslagen, debat-inhoud, etc.) tot je neemt, moet je er vanuit gaan dat deze informatie klopt. Ze willen dus geen man-in-the-middle toestaan die een app bouwt en onderweg de data manipuleert.

Er zit ook helemaal geen vertrouwelijke informatie in die app, maar de integriteit van die data moet nog wel worden gewaarborgd.

Kortom, ze willen voorkomen dat bijv. iemand een Ubuntu-app lanceert en alle debatten waar de SGP aan meedoet eruit filtert. Of alle stemmen van de PvdA omdraait.

Ter verduidelijking: die man-in-the-middle is dus niet de bad guy tussen server en client, maar de app-bouwer zelf. Tussen client en user dus.

[Reactie gewijzigd door StephanVierkant op 2 maart 2020 17:13]

Over het algemeen gebruikt de overheid de GPL of AGPL licentie als ze software publiceert. Zie bijvoorbeeld de broncode van de stikstofmodellen van het RIVM (https://github.com/rivm-syso/OPS en https://gitlab.com/AERIUS/) of de broncode van het BRP (https://github.com/MinBZK/OperatieBRP).

Met (A)GPL moet de broncode van de aangepaste app ook gepubliceerd worden. Enige manipulatie wordt zo duidelijk.

Het beste middel om manipulatie te voorkomen is het digitaal ondertekenen van de gepubliceerde informatie.

De overheid is een term. Dat bepaalde overheidsorganisaties software publiceren heeft mede te maken met wetgeving en richtlijnen die voor die organisaties gegeven zijn. Een beroep doen dat andere organisaties zich daarin schikken omdat heel veel organisaties dat (moeten) doen legt deels al het probleem uit waarom er destijds wetgeving en richtlijnen tot stand zijn gekomen. Als je verandering wil is het dan misschien handig om te beseffen op wie je een beroep zou moeten doen om verandering te krijgen en of de personen die je de reacties geven daarin een functie of mandaat hebben om te veranderen.

Kortom, ze willen voorkomen dat bijv. iemand een Ubuntu-app lanceert en alle debatten waar de SGP aan meedoet eruit filtert. Of alle stemmen van de PvdA omdraait.

Hoe wordt dat voorkomen door de source niet te delen? Als ik een beetje moeite doe kan ik alle data op m'n eigen server zetten en mijn "foute" app gebruik laten maken van mijn eigen server.

[Reactie gewijzigd door CAPSLOCK2000 op 2 maart 2020 20:31]

Maar dat doe je dus niet door de app gesloten te houden. Daar kan je andere verificaties voor inbouwen zoals de communicatie met de server digitaal ondertekenen.

Als je de communicatie tussen app en server ondertekent is er inderdaad geen man-in-the-middle mogelijk. Tussen app en server althans.

Mijn voorbeeld gaat er vanuit dat de app-bouwer ter kwade trouw is, dus de informatie correct binnenhaalt maar foutief weergeeft.

Ik denk dat ze met 'manipulatie van het informatiekanaal' bedoelen dat ze willen voorkomen dat iedereen apps gaat bouwen waarvan je niet zeker weet of de content wel juist wordt weergegeven. Stel je voor dat Forum voor Democratie een (neutraal ogende) app zou bouwen waarbij alleen debatten te zien zijn waar ze aan meedoen, zodat het voor de gebruiker lijkt alsof ze aan alle debatten meedoen. En waarbij ze achteraf stemmingsresultaten aanpassen als het even niet lekker in de media kwam.

Tja, name squatting heb je nu ook. Dan geef je die app een slechte review, met comment. Je ziet ook wie de bouwer is. Vervolgens komt dit in de media (als het een populaire app is, bij eentje met 10 downloads is dat onnodig).

Doen we toch gewoon een trollenfarm openen om zo nepnieuws in het leven te helpen? Oh, wacht. Non-argument.

Daarbij komt, als iemand een SGP stream wil opstarten met alleen de SGP sprekers dan moet diegene die vrijheid hebben. Net zoals je ook kranten hebt die voor eigen parochie preken.

Ze willen dus geen man-in-the-middle toestaan die een app bouwt en onderweg de data manipuleert.

Waaruit maak je deze conclusie dat op? Want wat ik lees vooral vage omschrijvingen dat er risico's gezien worden maar nauwelijks inhoudelijke verduidelijking welke risico's dat dan zijn. Als er geen uitleg staat lijkt het me niet dat je makkelijk kan stellen dat een zelf bedachte redenatie dus overeen zou komen.

Is het niet per definite naief te denken dat een applicatie geen gaten van wat voor vorm dan ook heeft?

"Daarnaast beriep de Tweede Kamer zich op mogelijke veiligheidsrisico's. Openbaarmaking zou tot 'manipulatie van het informatiekanaal kunnen leiden'." - dat is toch gewoon toegeven dat er veiligheidstechnisch gaten in zitten?

Het hoeft niet te wijzen op een beveiligingsgat.
De eiser geeft zelf aan dat een belangrijk doel voor het openbaren van de broncode is dat hij dan daarmee zelf een app kan maken voor Linux. De broncode kan door anderen ook gebruikt worden voor een eigen versie van de app voor Android/ iOS/ Windows met een andere interface/ mogelijkheden. Eén van de extra mogelijkheden is dan ook het manipuleren van de getoonde informatie. Het weglaten/ toevoegen van informatie.Dat zou ook een risico kunnen zijn.

“ Daarnaast beriep de Tweede Kamer zich op mogelijke veiligheidsrisico's. Openbaarmaking zou tot 'manipulatie van het informatiekanaal kunnen leiden'.”

Broncode hebben is een luxe, maar geen vereiste voor een aanvaller...

Broncode is wel een vereiste om te kunnen zeggen dat je een app aanbiedt gebaseerd op de originele broncode. Terwijl je de broncode zo hebt aangepast dat je zelf eigen informatie toe kan voegen of officiële informatie weg kan laten. Dan kun je doelgroepen die al in hun eigen bubbel leven en reguliere media wantrouwen een eigen versie van de debatten tonen waarin bepaalde partijen beter/ slechter afgeschilderd worden.

Op zich begrijp ik de weigering. Alleen waarom denkt men vervolgens dan niet mee en biedt aan ook een Linux-versie voor Debian of Red Hat of een van de andere populairdere distros te maken?

Overigens, heeft deze man zoiets überhaupt gevraagd voordat hij naar de broncode vroeg? Of is hij gelijk naar de rechter gestapt?

Zoals het stuk vermeld heb ik eerst de Tweede Kamer een brief gestuurd en gevraagd om de broncode. Daarbij heb ik aangegeven dat ik een Linuxversie van de app wil maken.

Ik lees dat je doel is om zelf een app te bouwen, en niet per sé het auditen van de bestaande code?
Heb je al geprobeerd om de werking zelf na te bouwen (reverse engineering)?

• APK los downloaden via een zoekmachine, een tool als http://www.javadecompilers.com/apk gebruiken?
• je telefoon verbinden met een debugging proxy zoals https://www.telerik.com/fiddler en dan kijken welke calls er gedaan worden?

[Reactie gewijzigd door wind-rider op 2 maart 2020 17:36]

De twee tools die je noemt zijn de voorsprong kwaadwillenden op goedwillenden hebben. Gaten in de serverssoftware zijn te vinden met analyse van verkeer en APK.

En ja, een bare-bones app is met analyse van het verkeer tussen client en server waarschijnlijk wel te maken. Maar veel waarde van de app zit in de mooie UI. Dat is javascript en CSS code. Ik kan die voor eigen gebruik wel nemen, maar natuurlijk nooit delen met anderen. Dat is dan veel moeite voor een beperkt publiek van 1 persoon.

Het veiligheidsargument slaat nergens op, klinkt als leken die iets over software mogen zeggen.

Toch kan ik het niet kwalijk vinden dat dit niet gedeeld wordt. Er is een webpage die dezelfde info beschikbaar maakt en daarmee is vrijwel ieder platform al te bedienen.

En dat de UI niet legaal gebruikt kan worden is ook geen drama. Maakt het allemaal net ff tijdrovender om een met fake news gevulde kloon te maken. Kan in verkiezingstijd toch prettig zijn, een drempel voor scriptkiddie #34 die zijn/haar clubje ff wil 'helpen'. Daarnaast, ook een overheid hoeft zijn huisstijl niet zomaar vrij te geven.

https://www.rijkshuisstijl.nl/

De rijks huisstijl is open naar ;-).

Anyway, zelf ben ik niet van mening om zomaar alle broncode van de overheid openbaar te maken. Zelfs niet met een licentie dat deze commercieel niet gebruikt mag worden.

Er zijn genoeg redenen te bedenken waarom wel en niet de broncode openbaar zouden moeten worden.

de voorsprong kwaadwillenden op goedwillenden hebben

Iedereen kan die tools gebruiken, daar hoef je niet per sé kwaadwillend voor te zijn. Je kunt het ook als white hat gebruiken of inderdaad voor eigen gebruik.

En inderdaad, je kunt de "voorkant" waarschijnlijk niet zomaar kopiëren en vervolgens met anderen delen of verkopen als je daar geen afspraken over hebt met de oorspronkelijke maker. Wat je wel zou kunnen doen is met anderen samenwerken die evt een mooie voorkant kunnen maken nadat de logica uitgeplozen is.

Begrijp me niet verkeerd, ik ben ook voorstander van het openbaar maken van de broncode, echter je doel kun je misschien al bereiken zonder ervoor te hoeven procederen.

Clean room ontwikkeling kan ook. Het wine project heeft dat jaren gedaan.
Een persoon/groep onderzoekt alle code op welke manier dan ook. En stelt aan de hand daarvan functionele en technische beschrijvingen op.
Een andere groep maakt aan de hand van die beschrijvingen een nieuwe applicatie.
Vervolgens kunnen de gebruikers van de applicatie alle anomalieen benoemen die dan ook in de specs kunnen worden opgenomen en verwerkt.

Dit is wel een zijsprong die je nu opeens maakt. Bij je argumentatie heb je het over het recht op transparantie, het belang van een openbaar democratisch proces etc, en nu gaat het om de mooie UI? Wees nou wel een beetje rechtlijnig in de argumentatie (ook al zoom je in op bepaalde aspecten van de kwestie), anders wordt het wel heel lastig om rechtzaak te winnen.

Op zich begrijp ik de weigering.

Ik niet. Public Money, Public Code.

De weigering begrijpen vanuit de gegeven redenering van een rechter bij de bestaande wetgeving lijkt me heel wat anders dan het niet begrijpen omdat je een andere mening hebt. Je kan toch moeilijk verwachten dat de rechter de wet naast zich neer legt en gaat oordelen op basis van niet bestaande wetgeving.

Je kan toch moeilijk verwachten dat de rechter de wet naast zich neer legt en gaat oordelen op basis van niet bestaande wetgeving.

De redenering waarom de rechter denkt dat het er niet onder valt kan je gerust twijfels bij hebben.

Verder is mijn reactie niet op het oordeel van de rechter zelf, maar om de gehele situatie die ervoor zorgt dat de rechter dit oordeel maakt. Als er wetgeving mist dan is het tijd om daar iets aan te doen.

[Reactie gewijzigd door The Zep Man op 3 maart 2020 06:27]

Komt nog bij dat Android een dominante marktpositie heeft, en dat dat niet iets is dat een overheid moet stimuleren. Een overheid zou een initiatief als SailfishOS niet moeten tegenwerken.

Ze ondersteunen ook iOS en Windows. Wat is nu het precies probleem? Dat ze niche systemen niet ondersteunen?

Dat ze dat actief belemmeren. Een overheid hoort daar onpartijdig in te zijn.

In de meeste gevallen krijgt de 'klant' van custom software enkel het gebruiksrecht en niet het volledige eigendom van de broncode. Zo kan de bouwer delen uit de broncode ook gebruiken voor andere klanten.
Volledig eigendom van de broncode is natuurlijk mogelijk, maar tegen een meerprijs.

'Public Code' zal dus betekenen 'More Public Money'. 'More Public Money' voor 'Public Code' betekent 'Less Public Money' voor andere doeleinden.

Na meer dan tien maanden werd mijn verzoek afgewezen (even daargelaten dat de beslistermijn vier weken was.) Vervolgens schreef ik een bezwaarschrift dat leidde tot een hoorzitting in de Tweede Kamer. Resultaat: de afwijzing van mijn verzoek wordt gehandhaafd.

Geschreven 17 oktober 2019. Jos van den Oever is dus al 15 maanden bezig.

[Reactie gewijzigd door Eonfge op 2 maart 2020 17:21]

Er is een web-app beschikbaar (https://debatdirect.tweedekamer.nl/) dus de noodzaak om voor ieder OS/platform een app te bouwen zie ik niet direct. Als de Tweede Kamer slim is bieden ze een publieke API aan dan kan iedereen die dat wil een app voor zijn/haar favoriete OS bouwen.

deze kende ik nog niet bedankt voor het delen van je informatie :)!
ik gebruikte altijd de windows app van debatdirect in de windows store, die werkt heel erg goed.

Ik denk dat tegenwoordig dezelfde app voor Red Hat en Debian zal werken. Maar niet op Sailfish, dus waarom is er niet gewoon één app, namelijk een web app?

[Reactie gewijzigd door 84hannes op 2 maart 2020 19:27]

Er is een "web app" als in een website https://debatdirect.tweedekamer.nl/ of dit hier een PWA van te bouwen is weet ik niet.

Ik neem aan dat deze app mede met publiek geld gefinancierd is toch? Dan lijk mij dat rede genoeg om de broncode ook publiek te maken aangezien iedereen er toch aan heeft meebetaalt. Daarnaast is dit best wel zorgelijk, want ik vraag mij enorm af of broncode van stemcomputers (als deze er ooit komen) dan bijv. wel openbaar wordt. Nu kan iedereen nog enig sinds verifiëren hoe het stemproces in zijn werk gaat, met een stem computer moet dat ook kunnen. Grote gemiste kans naar mijn mening.

[Reactie gewijzigd door n9iels op 2 maart 2020 18:09]

Die vergelijking/redenatie klinkt leuk, maar gaat niet op. Dan zou je namelijk ook als voorbeeld kunnen stellen dat de belastingdienst of AIVD al haar verzamelde informatie ter beschikking tot haar burgers moet stellen, met alle gevolgen van dien. Die worden namelijk ook vanuit de overheid betaald..

Als publiek geld een vereiste zou zijn voor openbaar maken, welke wet is dan volgens jou daar dan op van toepassing? Want als die wetgeving er niet is dan is het slechts een mening en daarmee kan een rechter moeilijk toekennen dat de broncode publiek zou moeten zijn.

Het is ook zeker een mening

Hoe mooi zou het zijn als de overheids ict projecten opensource zouden zijn en dat iedereen kan bijdragen. Maar nee helaas, projecten worden uitbesteed aan degene die het beste weet hoe je een aanbesteding wint. Daarna begint de ellende.

In dit geval maakt het niet uit wie de realisatie doet. De tweede kamer is eigenaar van de broncode en kan er dus over beslissen. En dat eigenaarsschap kan, waar mogelijk, gewoon meegenomen worden in de tenders.

In de VS doen ze dit wel vziw.

Open source als in OSI open source hoeft geen eens; vrijgave van broncode zou al voldoende moeten zijn.

Aan de andere kant; als ik een brokje eigen code bij de belastingdienst naar binnen kan drukken om mijn BSN totaal over het hoofd te zien... Bugje, bedankt!

Zoiets zal er ook binnen een paar minuten weer uitzijn als het uberhaupt al toegelaten wordt.

Nee, maar als het opensource is zijn er genoeg IT'ers die dit er weer uitvissen, krijgt de persoon die te weinig betaald heeft een boete vanwege niet betalen en misschien zelfs een aanklacht voor belastingfraude.

Zal wel zo lek zijn als een mandje dan want anders zouden ze de broncode wel openbaar maken..

Dat is meestal niet de reden dat iets closed source is.

Het is meer dat "De Tweede Kamer wil de broncode niet openbaar hebben uit veiligheidsoverwegingen" een beetje een zorgelijke opmerking is. Wat is dan precies die veiligheidsoverweging, en waarom leidde die ertoe dat het closed source moet blijven?

Ik zou zeggen dat het alleen andersom kan, dus dat de sourcecode wél openbaar gemaakt moet worden uit veiligheidsoverwegingen.

Dus het zou kunnen dat je gelijk hebt, maar niet in z'n algemeenheid. En ook niet zeker.

Wat is dan precies die veiligheidsoverweging, en waarom leidde die ertoe dat het closed source moet blijven?

Het argument van de 2e kamer is dat de client- en server-zijde van de app één verbonden geheel zijn en dat publicatie tot manipulatie van die communicatie zou kunnen leiden.

Zo'n statement doet bij mij eerlijk gezegd alle alarmbellen afgaan.

Dat stinkt naar een app die sterk verbonden is met de achterliggende netwerk infrastructuur en die bijvoorbeeld zelf een hele berg certicaat-sleutels en interne wegwijzering (lokale hostnames, of harde lokale IP addressen) in zich draagt om middels een aan het internet verbonden proxy het lokale netwerk van de 2e kamer te kunnen bereiken en daar geauthenticeerd te zijn bij allerlei backend-systemen om daar direct data uit op te kunnen vragen.

Heel eng als het echt zoiets mocht blijken te zijn.

Dat is precies waar ik in mijn tweede alinea voor vrees.

Gelukkig is het relatief makkelijk om erachter te komen wat een app allemaal over de lijn slingert.

Dat is precies waar ik in mijn tweede alinea voor vrees.

Gelukkig is het relatief makkelijk om erachter te komen wat een app allemaal over de lijn slingert.

Gevaarlijker is dat, als dit het geval mocht zijn, iemand ook de app kan decompilen - of wellicht al gedecompiled heeft - om zo aan de toegangssleutels te komen.

En als die sleutels lekker naïef alle mogelijke permissies hebben om overal bij te komen -- wat in het kader "Overheid en klungerig-dan-ons-kan-het-niet ICT" eigenlijk geheel in de lijn der verwachting ligt -- dan zijn de rapen pas echt gaar.

Of ze hebben een app laten maken en het niet gehad over publicatie van de broncode. En nu wil je dat wel, dan mag je misschien bijbetalen.
Al is het niet handig om de rechten van de source niet te verkrijgen. Maar dat terzijde.

Het zou een behoorlijke flater zijn om de rechten op de broncode bij een commerciele partij te laten liggen. De meeste opdrachtgevers in mijn ervaring komen met ons overeen dat zij de eigenaar van de code zijn. Stel dat je naar een ander wil, dan zou je de hele shit opnieuw moeten laten bouwen. Dat is geen optie.

Ik denk niet dat dit de reden is. Ik denk eerder dat het compleet openbaar maken van de code nog een brug te ver is voor de overheid. Als je aan een niet-programmeur vraagt of het openbaar maken van code een slim plan is zal bijna iedereen nee antwoorden. Het lijkt namelijk best een obvious security issue, een beetje alsof je de exacte details van de persoonsbeveiligingen van de koning openbaar maakt.

In praktijk kan het juist een positief effect hebben, zowel omdat iedereen de code kan inzien als dat men blijkbaar genoeg vertrouwen heeft om het openbaar te tonen. Maar dat uitleggen aan een niet programmeur is gewoon best wel lastig.

Daar staat tegenover dat de code (hopelijk!) niet door een niet-programmeur geschreven is...

Nou heb ik wel een keer zo'n soort situatie meegemaakt met een extern inelkaargeknutseld tentamen aanmeldsysteem (opa vertelt) op de TU. Bij reverse engineering door het protocol af te luisteren, bleek dat het gruwelijk ondoordacht inelkaar zat. Dat komt bij customsoftware helaas wel vaker voor. Je kunt daar dan wel encryptie bovenop zetten zodat reverse engineering lastiger wordt, maar door de broncode in te zien is het dan opeens wel weer duidelijk.

Het kan dus zijn dat (de leverancier van) de overheid hier iets te verbergen heeft.

Overigens is reverse engineering van het protocol met als doel interoperabiliteit, in zulke gevallen gewoon toegestaan. Dat is hier dus ook de oplossing, zelfs als er geen api's of protocollen zijn vrijgegeven.

[Reactie gewijzigd door mae-t.net op 3 maart 2020 17:56]

Die aanname is natuurlijk wel erg kort door de bocht.

Van de andere kant getuigd het ook niet echt van vertrouwen dat je de veiligheidsrisico's als 1 van de redenen aankaart om je software niet OS te maken.

Als je iets niet wilt voer je in een rechtszaak gewoon alle mogelijke argumenten die enigszins hout snijden.

sorry, maar dat soort argumentatie houd geen enkele steek. Alsof niemand er problemen mee heeft dat goed geschreven code openbaar wordt en er nooit slecht geschreven code als open software wordt gelanceerd. Dat is als tegen de rechter zeggen dat je het niet gedaan hebt om dan veroordeeld te worden omdat schuldigen dat net zouden zeggen.

Volgende stap. Stem computers!

Houdt er rekening mee dat dit soort rechtzaken een precedent neerzetten die nogal eens heel nadelig kan uitpakken: Heeft een guur rechtse/links/religieuze partij daadwerkelijk 100% van alle stemmen gehaald in de landelijke verkiezingen? De computer zegt van wel. En nee, wij gaan jou niet vertellen hoe die computer tot die uitslag komt.

Ongeacht of de broncode van de software van een stemcomputer openbaar zou zijn of niet, blijft het ook heel lastig om als stemmer te controleren of de binary die op de stemcomputer draait daadwerkelijk gecompileerd is uit de openbare broncode.

Dat weet jij en dat weet ik, maar zo te horen weten onze volksvertegenwoordigers dat niet. Ze zijn immers van mening dat gesloten producten beter beveiligd zijn. Gesloten stemcomputers liggen dus wel in de lijn der verwachting.

Ongeacht of de broncode van de software van een stemcomputer openbaar zou zijn of niet, blijft het ook heel lastig om als stemmer te controleren of de binary die op de stemcomputer draait daadwerkelijk gecompileerd is uit de openbare broncode.

Laat staan of de stemcomputer zelf goed beveiligd is. Zal de eerste keer niet zijn als je gewoon stiekem een USB-key in een poort kunt frutten.

Public money, means public code. Zou ik zeggen.