Personuppgifter & integritet

Personuppgiften du redan lämnat ut

Öppna ett av dina repon på GitHub och gå till din allra första commit. Där står ditt namn, och en mejladress. De finns i varje commit du gjort sedan kursens början, för Git stämplar varje commit med vem som skrev den, och du har valt Public varje gång du publicerat.

Det visste du. I Kom igång fick du veta att namnet och adressen följer med varje commit, och i Molnet & portföljen fick du välja mellan din riktiga adress och en dold. Poängen med att titta nu är en annan: jämför den första commiten med den senaste. Står det samma sak? Och om du ändrade dig någonstans på vägen, vad hände med de commits som redan var gjorda?

De står kvar precis som de var. Det går inte att ändra i efterhand, för en publicerad historik är just historik.

Ett namn och en mejladress är personuppgifter Personuppgift Varje uppgift som direkt eller indirekt kan kopplas till en identifierbar levande person: namn, e-postadress, IP-adress, användarnamn med mera. Se: Personuppgifter & integritet , data som kan kopplas till en identifierbar person. Det kluriga med dem är inte att de är svåra att förstå. Det är att de är lätta att lämna ifrån sig och nästan omöjliga att ta tillbaka, och det gäller även när man som du blivit varnad i förväg. Hittills har det handlat om dina egna uppgifter, där du själv får bära konsekvensen av ditt val. I samma stund ditt program lagrar något om någon annan är det deras uppgifter, och deras konsekvens.

Vad är en personuppgift?

En personuppgift är varje uppgift som direkt eller indirekt kan kopplas till en levande person. Ett namn är det uppenbara fallet, men listan är längre: e-postadress, telefonnummer, IP-adress, ett användarnamn, en highscore-lista med initialer. Också data som var för sig verkar anonym kan bli en personuppgift när den kombineras med annat.

Din mejladress i commit-historiken är alltså en personuppgift du redan hanterar, om än om dig själv. Så fort ett program du bygger sparar ett namn, ett alias eller en mejl om någon annan, hanterar du deras. Det gör inte dina program olagliga, men det gör dig till någon som förvaltar andras data, och det kommer med ansvar.

Dataminimering

Det starkaste integritetsskyddet är inte kryptering eller hashning. Det är att aldrig samla in datan från början. Data du inte har kan inte läcka, inte missbrukas och inte begäras ut.

Ställ dig frågan för varje uppgift ditt program sparar: behöver det verkligen den här? Behöver ett spel spelarens riktiga namn, eller räcker ett valfritt alias? Behöver en highscore ett fullständigt namn, eller räcker tre bokstäver? Varje uppgift du väljer bort är en uppgift du aldrig behöver skydda.

GDPR och rättigheter

I EU regleras personuppgifter av GDPR GDPR EU:s dataskyddsförordning. Ger personer rätt att se, rätta och radera sina personuppgifter, och ålägger den som samlar in dem ett ansvar. Se: Personuppgifter & integritet . På den nivå du behöver här handlar det om en enkel princip: den vars data det är bestämmer över den. En person har rätt att få se vilka uppgifter du lagrar, att få felaktiga uppgifter rättade, och att få sina uppgifter raderade.

Du har ett levande exempel att titta på: den här kursens egen webbplats. Läs avsnittet Dataskydd på Om-sidan. Den berättar vad som samlas in (din e-post och ditt GitHub-namn för inloggningen, dina svar för att spara framsteg), varför, var det lagras, och att du kan radera ditt konto själv från din dashboard. Det är dataminimering och rättigheter i praktiken. Läs den som ett exempel, kopiera den inte.

Hemligheter i ett publikt repo

Sedan Molnet & portföljen väljer du Public när du publicerar. Det är bra för din portfölj, men det betyder också att allt du committar är synligt för vem som helst. Tre saker hör därför aldrig hemma i ett repo: personuppgifter, lösenord skrivna rakt in i koden, och API-nycklar.

Lösenordet förtjänar ett eget stycke, för här går en gräns som inte är förhandlingsbar. Ett system ska aldrig lagra ett lösenord i klartext. Inte i koden, inte i en fil, inte i en databas. Skälet är enkelt: i samma stund som lösenordet finns nedskrivet någonstans är den platsen en måltavla, och en enda läcka avslöjar allas lösenord på en gång. Det har hänt om och om igen, miljontals lösenord i klartext på vift. Du kan själv kolla om din e-post varit med i en känd läcka på Have I Been Pwned.

Vad gör riktiga system i stället? De lagrar inte lösenordet utan ett oåterkalleligt avtryck av det. Vid inloggning räknas avtrycket fram på nytt från det du skrev, och de två avtrycken jämförs. Systemet vet alltså aldrig vad ditt lösenord är, bara om det du just skrev ger samma avtryck som förra gången. Läcker databasen får angriparen en hög avtryck, inte en hög lösenord. Tekniken bakom får du prova i utmaningen i Låsskärmen.

Farligast av de tre är ofta API-nycklar. En API-nyckel API-nyckel Ett hemligt lösenord som ger ett program tillgång till en tjänst, till exempel en molntjänst eller ett API. Hör aldrig hemma i ett publikt repo, en läckt nyckel kan missbrukas av vem som helst. Se: Personuppgifter & integritet är ett lösenord som ger ditt program tillgång till en betald tjänst, till exempel en molntjänst eller ett AI-API. Lägger du en sådan i ett publikt repo hittar automatiska bottar den ofta inom minuter, de skannar GitHub dygnet runt just efter nycklar. En läckt molnnyckel kan ge någon annan en räkning på tusentals kronor i ditt namn innan du ens hunnit reagera. Det är inte ett teoretiskt hot, det händer nybörjare varje dag.

Verktyget som håller sådant utanför repot är .gitignore, en fil som talar om för Git vilka filer den aldrig ska spåra eller ladda upp:

# .gitignore, det här committas aldrig
.env
sparfil.txt

En fil som heter .env är där riktiga projekt lägger sina nycklar och hemligheter, och med den raden laddas den aldrig upp. Ett lösenord eller en nyckel ska aldrig stå hårdkodat i koden, det hör hemma i en fil som .gitignore håller utanför repot.

Det för oss tillbaka till frågan som öppnade hela kursen i Verkstaden byggs: vem lämnar antaganden utanför, och vem exponeras? Amazon-systemet, krocktestdockan, ansiktsigenkänningen, allt kom ur beslut om vems data och vems verklighet som räknades. Nu är det du som fattar de besluten i din egen kod.

Prova

Det här steget är att titta, inte att bygga. Bygget kommer i uppgiften.

1. Öppna din commit-historik på GitHub och jämför den första commiten med den senaste. Vilket namn och vilken adress står i var och en? Vad säger det om vad ett beslut om personuppgifter kostar att ångra?
2. Läs avsnittet Dataskydd på Om-sidan. Vilken data samlar kursens webbplats in om dig, hur länge sparas den, och hur raderar du den?
3. Titta på hur det ser ut utanför kursen. Just Delete Me betygsätter hur svårt det är att radera sitt konto hos olika tjänster, från enkelt till omöjligt. ToS;DR sammanfattar vad användarvillkoren du klickade ja till faktiskt säger. Slå upp två tjänster du själv använder. Vad hittade du som du inte visste, och skulle du ha klickat ja om det stått i klartext?