Definition og hvad “datalækage” kan betyde

Datalækage fra mobilapps handler typisk om, at oplysninger ender et sted, de ikke var tiltænkt. Det kan være fordi data bliver sendt til en tredjepart uden et klart, nødvendigt formål, fordi data sendes i en svag eller forkert form, eller fordi data bliver eksponeret lokalt på telefonen (fx via læsbare filer, logning eller fejlkonfigurationer).

Det er nyttigt at skelne mellem to niveauer: (1) datadeling og (2) databrud. Datadeling er ikke automatisk ulovlig eller skadelig, men kan alligevel være uønsket, hvis den ikke matcher brugerens forventning. Databrud betyder, at data håndteres forkert, så uvedkommende får adgang.

Et enkelt trusselsmodel-billede: hvor kan lækagen opstå?

Du kan anskue datalækage gennem tre “hvor”-spørgsmål. Det gør vurderingen mere konkret, især når du læser beskrivelser, tilladelser og privatlivstekster.

  1. På enheden (lokalt):

    • Data kan gemmes i klartekst eller på en måde, der gør den let at hente.
    • Appen kan efterlade oplysninger i logfiler eller midlertidige cache-/filområder.

  2. Under transport (netværk):

    • Data kan sendes med utilstrækkelig beskyttelse.
    • Implementationsfejl kan give utilsigtet eksponering, fx ved at sende mere end nødvendigt.

  3. Hos tredjepart (leverandør/økosystem):

    • Tracking- eller annoncebiblioteker kan indsamle identifikatorer eller adfærdsdata.
    • Backend og analyseleverandører kan modtage data, selv hvis appen lokalt virker “privat”.

Poenget er ikke at gætte enkeltstående skyld, men at finde den del af kæden, hvor du faktisk kan stille relevante spørgsmål. Når du kan placere din bekymring i én af de tre kategorier, bliver det lettere at vælge kontrolpunkter.

De vigtigste dele af mobilapps, der skaber datalækage

Selv uden at have kildekoden kan du ofte identificere risikofaktorer gennem appens opførsel og de oplysninger den giver.

1) Tilladelser og adgangsomfang

Hvis en app anmoder om flere tilladelser end det, den reelt bør bruge, øges risikoen for uønsket dataeksponering. Vurder særligt:

  • Om appens funktion matcher de tilladelser, den kræver.
  • Om den bruger adgang til kontakter, filer, lokal lagring, mikrofon, kamera eller placeringsdata på en måde, der virker begrundet.

2) Dataformat og “minimum nødvendig”

En almindelig årsag til lækager er ikke nødvendigvis manglende sikkerhed, men at data behandles for bredt. Hvis appen indsamler eller sender flere felter end nødvendigt, øges konsekvensen af enhver fejl eller misforståelse.

Tænk på spørgsmålet: hvad er det mindste datagrundlag for at levere funktionen? Jo tættere appens indsamling ligger på det minimale, desto mindre “overflade” har en potentiel lækage.

3) Logning og diagnostik

Apps kan logge hændelser og fejlinformation. Hvis logning indeholder persondata (selv i korte perioder), kan den lokale eksponering stige.

4) Tredjepartsbiblioteker

Mange mobilapps integrerer tredjepartsservices. Det kan være nødvendigt, men betyder også, at data kan blive delt internt i et bredere økosystem. Når du vil forstå risikoen, er det derfor relevant at skelne mellem:

  • Hvad appen selv siger den gør
  • Hvad tredjepartsmoduler typisk kræver for at fungere (fx analyse, måling, personalisering)

5) Privatsprog vs. konkret praksis

Privatlivstekster kan være brede. Kig efter detaljer som datakategorier, formål og om data deles. Brede formuleringer uden konkrete kategorier gør det sværere at vurdere, om der er et match mellem dine forventninger og appens praksis.

Forskelle og grænser: hvad du kan og ikke kan verificere

En central begrænsning er, at du sjældent kan bevise fravær af datalækage alene fra en appbeskrivelse. Du kan derimod ofte vurdere sandsynligheder og “angrebsflader”.

Her er realistiske grænser, du bør have med:

  • Ingen nulrisiko: Selv med gode teknikker kan der opstå fejl, misforståelser eller uventet datadelingsadfærd.
  • Verifikation kræver analyse: Hvis du har behov for stærkere sikkerhedsgarantier, kræver det typisk teknisk gennemgang af appens opførsel (fx hvilke forbindelser der laves, og hvilke data der sendes), ikke kun læsning af marketing- og privatlivstekst.
  • Backend kan ændre adfærd over tid: Dataflows kan blive opdateret, uden at appens brugerflade nødvendigvis ændrer sig.

Hvad kan skille “lokal” fra “netværk” og “tredjepart”?

Hvis du observerer appens opførsel, kan du ofte lave en grov placering af risikoen:

  • Hvis appen kun arbejder lokalt uden synlige delingsfunktioner, er lokal risiko ofte mere relevant.
  • Hvis appen skaber forbindelser hyppigt eller til mange destinationer, øges relevansen af transport- og tredjepartsrisiko.
  • Hvis appen deler funktionalitet med integrerede services, kan leverandørrelateret risiko være vigtig.

Praktisk brug: kontrolpunkter du kan anvende nu

Brug disse kontrolpunkter som en tjekliste, der hjælper dig med at vurdere datalækage uden at falde i absolutte løfter.

  1. Match funktion og tilladelser: Gå til appens tilladelsesliste og vurdér, om hver tilladelse virker nødvendig for det, du bruger.

  2. Læs efter datakategorier og formål (ikke kun ord): Prioritér afsnit der nævner hvilke data, hvorfor, og om data deles. Hvis teksten er for vag, så behandl det som et svaghedstegn.

  3. Vurdér “hvor stor en ændring” data får i kæden: Spørg dig selv, om appen kun bruger data lokalt eller også eksporterer den. Jo længere data rejser, desto flere steder kan noget gå galt.

  4. Vær ekstra opmærksom ved data med høj følsomhed: Placering, kontakter, adgangstokens, identifikatorer og personlige dokumenter er typisk højere konsekvens end fx anonyme præferencer.

  5. Lav en løbende vurdering: Appopdateringer kan ændre dataflows. Hvis du ser ændringer i tilladelser eller funktioner, så revurder kort dine risikospørgsmål.

Hvis dit mål er at undgå datalækage, handler det i praksis om at mindske overfladen: reducer unødige tilladelser, vælg apps med mere gennemsigtige dataprincipper, og behandl “privat”-kommunikation som et udgangspunkt, ikke en garanti.