Åpen kildekode-utvikler forsvarer korona-appens lukkede kildekode

- Jeg hadde tatt det samme vanskelige valget, skriver Rafael Winterhalter, som selv er en viktig bidragsyter av åpen kildekode.

Utvikler Rafael Winterhalter forteller at han er selv pådriver for åpen kildekode, men at vi bør gjøre unntak for den nye appen fra FHI. 📸: Privat
Utvikler Rafael Winterhalter forteller at han er selv pådriver for åpen kildekode, men at vi bør gjøre unntak for den nye appen fra FHI. 📸: Privat Vis mer

De siste dagene har det blitt ført mange debatter om FHIs planlagt applikasjon for smittesporing, og beslutningen om å holde kildekoden hemmelig og lagre data på en sentral server.

Flere har i denne sammenhengen fremstilt appen som urovekkende og stilt spørsmål om den burde installeres.

Men kritikerne overser sentrale problemstillinger som åpen kildekode og desentralisert datalagring medfører.

Jeg er selv softwareutvikler, tilhenger av åpen kildekode og aktiv bidragsyter til miljøet.

Jeg mener at vi utviklere burde publisere mer kode, spesielt når den er finansiert av Statens penger. Å holde kildekode stengt skulle ikke være normalen, men være forbeholdt unntakstilfeller.

Og for den mobile smittesporingsappen til FHI, synes jeg et slikt unntak gjelder.

Spesielle omstendigheter

Det er to fordeler med å dele kildekoden til en applikasjon:

  1. Brukere kan kontrollere om applikasjonen skjuler funksjoner. Om FHIs applikasjon sporet mer enn lokasjons- og kontaktdata, hadde åpen kildekode avslørt dette umiddelbart.

  2. Kildekoden blir tilgjengelig for brukere som ønsker å evaluere kvalitet og vil bidra med forbedringer.

Jeg antar at det er et minoritet som tror Folkehelseinstituttet lyver om funksjonsomfanget. Kravet om å åpne kildekoden er i stedet drevet av at man ønsker at alle skal kunne kvalitetssikre applikasjonen. Slik vil man øke kvalitet og dermed tillit.

«Det hadde vært uansvarlig å stole på at frivillige kan tilby tilstrekkelig fritid på kort varsel.»

Samtidig blir FHIs mobile applikasjon utviklet under særpregede omstendigheter.

Kvalitetsøkningen man forbinder med åpen kildekode er en langsiktig effekt. Det tar tid å bli kjent med en kodebase og det gjelder spesielt om man bare får muligheten til å jobbe med den på fritiden - tid som mange uansett mangler i disse dager med stengte skoler og barnehager.

Appen må derfor granskes av profesjonelle aktører, og det er en prosess som ikke behøver åpen kildekode. Det hadde i alle fall vært uansvarlig å stole på at frivillige kan tilby tilstrekkelig fritid på kort varsel, uten at det settes økonomiske incentiver.

Ikke gratis å åpne koden

Profesjonelle "crackere" kunne imidlertid hatt en fordel av åpen kildekode på kort sikt. Mens uavhengige ildsjeler gransker kilder i sin fritid, jobber rutinerte "crackere" gjerne fulltid for å finne feil så fort som mulig etter lansering.

Problemet blir forsterket av muligheten til å utnytte en svakhet umiddelbart, mens det tar tid før en feil er rapportert, utbedret og publisert som ny versjon.

Det er heller ikke gratis å åpne kildekoden. Det koster tid å vurdere henvendelser, og det er typisk arbeid som må gjøres av utviklere som er godt kjent med en applikasjon. På kort sikt kan det derfor være mer effektivt om disse jobber direkte med koden.

Et softwareprosjekt i en tidlig fase er ofte nødt til å prioritere hvilke svakheter som skal utbedres. En individuell programmeringsfeil trenger nemlig ikke å være et problem, det krever typisk et samspill av flere svakheter for å gi en angriper uønsket tilgang.

Risiko desentralisert, også

I tillegg hevdes det at lagring av kontaktdata kan bli til ulempe for den enkelte, om datainnsamlingen brukes urelatert til koronasituasjonen. Dette er uten tvil en reell risiko.

Samtidig ignoreres ofte risikoen desentralisert datalagring medfører.

Når mobiltelefoner utveksler informasjon direkte kan en angriper tilpasse sin egen appinstallasjon og bli en del av datautvekslingskjeden. Programmeringsfeil i en distribuert applikasjon kan derfor raskt få store konsekvenser, og siden distribuert datalagring er mer komplisert å lage, hadde det kortsiktige valget nok også økt sannsynligheten for en slik feil.

«Jeg hadde i hvert fall tatt det samme vanskelige valget under gitt tidsramme.»

Samtidig er det ingen mulighet til å utbedre feilen umiddelbart, siden feilen krever en oppdatering av alle brukerne ved distribuert datalagring.

Security by obscurity

I denne sammenhengen er det altså feil å likestille åpen kildekode med økt sikkerhet, og dermed grunn for tillit.

Og det er feil å påstå at en mer ambisiøs arkitektur med desentralisert datalagring alltid hadde blitt tryggere.

Beslutningene innebærer en vurdering av kort- mot langsiktig applikasjonssikkerhet, og i beste fall skal FHIs mobile app kun brukes i noen få måneder.

Derfor kan security by obscurity være et fornuftig, midlertidig tiltak når appen for smittesporing behøver lansering på så kort varsel.

Samtidig håper jeg at kildekoden publiseres på sikt, for å bevise at forskuddet i tillit var fortjent.

Jeg hadde i hvert fall tatt det samme vanskelige valget under gitt tidsramme, til tross for min daglige innsats for åpen kildekode.

💡 PS: For ordens skyld opplyser Winterhalter at en kollega i Scienta rådgir FHI i forbindelse med utviklingen av korona-appen. Men Winterhalter er overhodet ikke involvert i dette arbeidet, og uttaler seg som en åpen kildekode-bidragsyter, ikke Scienta-ansatt.