Må man gjøre en risikovurdering av hvorvidt JavaScript skal brukes på en nettside eller i en app, for å operere i tråd med GDPR? Det er sikkert flere som stiller seg det spørsmålet etter at det danske Datatilsynet nylig slo fast at ID-tjenesten MitId burde ha risikovurdert bruken av JavaScript på klienten:
– Du må vurdere JavaScript som risiko!
MitId hadde gjort en risikovurdering av tiltak knyttet til at man benyttet JavaScript, men det danske datatilsynet mente det ikke var nok siden de ikke hadde risikovurdert selve språket JavaScript. Også det norske Datatilsynet sa til kode24 at språket må vurderes på lik linje med alle andre verktøy.
Johannes Brodwall er utvikler i Sopra Steria, og bruker JavaScript og TypeScript daglig både som utvikler og som høyskolelærer. Han har levert systemer innenfor samfunnssikkerhet og jobber til daglig med systemer der sikkerhet, personvern og etterrettelighet er viktig.
Brodwall var med på å skrive Datatilsynes sjekkliste for programvareutvikling med innebygget sikkerhet og mener det danske og norske Datatilsynet tar feil når de sier GDPR stiller krav om å vurdere alle individuelle teknologier grundig – i dette tilfellet programmeringsspråket JavaScript.
– Å bruke mye innsats på å vurdere et stabilt og omfattende brukt programmeringsspråk som JavaScript virker tøysete, sier Brodwall.
«Det virker tøysete.»
JavaScript ingen risiko
Brodwall forteller til kode24 at når de skrev veilederen, var spesielt artikkel 32 i personopplysningsloven om sikkerhet i behandlingen viktig. Artikkel 32 krever at man vurderer sikkerhetsrisikoen i databehandlingen og at man gjennomfører "tekniske og organisasjonsmessige tiltak" som står i forhold til risikoen.
– Det er naturlig at en slik vurdering også inneholder en vurdering av risikoen i tekniske komponenter. Det danske Datatilsynet påpeker også et viktig moment: At MitId la til grunn en gammel vurdering ved utvikling av et nytt system, sier Brodwall.
Han er enig med det danske datatilsynet i at det ikke er godt nok å legge til grunn en gammel sikkerhetsvurdering når man utvikler noe nytt.
– Både regelverket og teknologien har endret seg og det er mange eldre systemer som har gamle synder. Artikkel 32 sier at gjennomføringskostnadene for tiltak også er en faktor man kan vurdere. Det kan unnskylde gamle synder, men det kan ikke unnskylde å videreføre svakheter i et nytt system.
Men det betyr ikke at man må risikovurdere hver eneste teknologi som er brukt, som det enkelte programmeringsspråket.
– Utgjør JavaScript noen sikkerhetsrisiko? I mitt syn er svaret klart "nei". Å bruke klient-side språk som JavaScript – eller mobilapper for den saks skyld – krever at man har en god analyse av sikkerhetsarkitekturen i systemet.
– Med JavaScript ligger brukergrensesnittet "utenfor sikkerhetsgrensen" til systemet. Man må anta at brukeren kan se alt som kommer til klienten, og kan erstatte alle kode som ligger i klienten. Men dette er velkjente problemstillinger og burde ikke by på problemer for et kompetent team.
Raser mot Datatilsynet: «Urimelig, overraskende»
"Det er vås!"
Brodwall har noen gode råd til utviklere som nå er usikre på hva de skal gjøre for at ikke løsningene de lager skal bryte med noen av bestemmelsene i GDPR og i personopplysningsloven.
GDPR stiller krav til en behandlingsprotokoll (artikkel 30) og til kommunikasjon til sine brukere (artikkel 12). Artikkel 30 krever at man lister opp hvilken type informasjon man behandler og hvilke organisatoriske og tekniske sikkerhetstiltak som er utført for å sikre disse. Denne protokollen trengs kun å gjøres tilgjengelig for Datatilsynet, ikke publiseres på nettsidene.
– Det er ikke krav om at man gjør eksplisitt vurdering av teknologier. Artikkel 12 krever at man på en klar og lettfattelig måte publiserer informasjon om hvilken informasjon man behandler og hvordan man behandler den. Loven setter ingen krav til å liste ut teknologiene som benyttes.
Den som klaget inn MitId til det danske datatilsynet skrev at "JavaScript er foreldet og usikkert, og at enheter som telefoner og datamaskiner lett kan hackes hvis JavaScript er aktivert". Til det har Brodwall bare én ting å si:
– At JavaScript er "foreldet og usikkert" er vås!
Brodwall sier JavaScript er et språk i kontinuerlig utvikling, og at språket ifølge Tiobe-indeksen har vært på topp 10-listen over de mest brukte språkene i veldig mange år.
– I motsetning til for eksempel C og PHP, som har språk-features som leder uvørne programmerer til å innføre sikkerhetsfeil, så har ikke JavaScript-systemer vært plaget av sikkerhetshull. Min erfaring er at JavaScript, eller egentlig TypeScript, er et av de vakreste språkene for å skrive funksjonell kode i dagligdagse prosjekter.
«At JavaScript er "foreldet og usikkert" er vås!»
Oppfordrer deg til å lese lover
Brodwall mener det er viktig for alle utviklere å holde seg oppdatert på personvern, og at det ikke trenger å være så vanskelig som mange tror.
Han oppfordrer alle til å gå inn på Lovdata og skrive ut artikkel 5 av personopplysningsloven.
– Det er en halvside med tekst som er fornuftig og lettfattelig og gir deg en forståelse av hva som er formålet med loven. Det er en del detaljer, men har du lest en teknisk manual, så klarer du glatt å lese en liten lov.
For de fleste holder det også å lese artikkel 1 – 39, samt artikkel 44, for å forstå om man trenger juridisk hjelp.
– Utviklere trenger ikke være redde for å lese lover. Det fikser du!
