Hvordan vi beskytter barnets data
Nettvakten behandler sensitiv informasjon om barn. Vi tar dette ansvaret ekstremt alvorlig. Her forklarer vi hvordan data beskyttes i alle ledd.
Det viktigste først: Rå skjermtekst fra barnets enhet forlater ALDRI telefonen. Nettvakten analyserer teksten lokalt, og kun anonymiserte varsler og krypterte rapporter sendes videre.
Sikkerhet i alle ledd
1. Hva skjer på barnets telefon?
Nettvakten bruker Android sin tilgjengelighetstjeneste til å lese tekst på skjermen. Denne teksten analyseres umiddelbart i telefonens minne:
- Teksten sjekkes mot kjente risikofaktorer (ordlister og mønstermatch)
- Hvis noe flagger, vurderes konteksten automatisk
- Den råe teksten lagres ALDRI og sendes ALDRI noe sted
- Kun resultatet av analysen (kategori, risikonivå, tidspunkt) lagres
Tenk på det slik: Nettvakten fungerer som en vekter som leser et brev, sjekker om det er trygt, og deretter makulerer brevet. Bare beskjeden «dette brevet var trygt» eller «dette brevet var mistenkelig» lagres.
2. Hvordan beskyttes data på telefonen?
- Kryptert database All lagret data på telefonen er kryptert med SQLCipher (AES-256). Selv med fysisk tilgang til telefonen kan ingen lese dataene uten PIN-koden.
- PIN-beskyttelse Appen er låst bak en PIN-kode som hashes med industristandard PBKDF2 (210 000 iterasjoner). Selv om noen får tilgang til den krypterte filen, tar det år å knekke den.
- Automatisk låsing Etter 5 feilede PIN-forsøk låses appen i 5 minutter. Denne telleren kan ikke manipuleres.
- Skjermdump blokkert Sensitive skjermer (PIN, innstillinger, hendelsesdetaljer) er beskyttet mot skjermbilder og skjermopptak.
- Hemmelig lagring Passord, API-nøkler og tokens lagres i Android sitt sikre nøkkelskap (Keystore), som på mange enheter bruker en dedikert sikkerhetsbrikke.
3. Hva sendes til serveren — og hvordan?
Kun to typer data sendes fra telefonen til serveren:
a) Krypterte rapporter
Deteksjonshendelser pakkes i en rapport som krypteres før den forlater telefonen. Krypteringen bruker to lag:
- Et tilfeldig generert engangspassord (AES-256-GCM) låser rapporten
- Engangspassordet krypteres med en RSA-2048-offentlig-nøkkel
- Rapportens innhold lagres på serveren som en kryptert pakke som ikke kan leses uten riktig privat nøkkel
Pågående arbeid (2026-04): Vi er midt i en migrering fra «server-holdt» privat nøkkel til «forelder-holdt» privat nøkkel. Når migreringen er ferdig, vil bare forelderen kunne dekryptere rapportene — Nettvakten vil ikke lenger ha nøkkelen. I overgangsfasen lagrer vi den private nøkkelen sikkert (HSM-beskyttet), brukt kun til at dashboardet skal kunne vise rapport-innhold for forelderen. Detaljer: E2E-migrasjons-planen.
b) Pseudonymisert telemetri (valgfritt)
Hvis du har gitt samtykke til datadeling, sender appen pseudonymiserte deteksjonsdata som hjelper oss å forbedre deteksjonen. Disse dataene sendes via HTTPS og lagres som strukturerte rader på vår server (Cloudflare D1). Vi behandler dem som personopplysninger og er underlagt GDPR for innholdet.
Dataen vi samler inn:
- Deteksjonsresultater Risikokategorier, trigger-ord (sanitert for kjente PII-mønstre), treffstyrke, alvorlighetsnivå
- Kontekst Tidspunkt, app-type, domenenavn, tekstlengde, situasjonssignaler, språk
- AI-vurderinger Resultat, begrunnelse, alvorlighetsvurdering, grooming-fase
- Din tilbakemelding Om du markerte varselet som falsk alarm
- Systeminfo Appens fase og modellversjon
- Pseudonyme identifikatorer Bruker-ID og enhets-ID følger med raden slik at vi kan slette dine telemetri-data ved kontosletting og oppfylle innsynsretten din
Hva som ALDRI samles inn:
- Ingen rå meldingstekst, skjermbilder eller skjerminnhold
- Ingen klartekst-navn, klartekst-brukernavn, passord eller kontaktinfo i telemetrien (e-post, brukernavn og telefonnumre i trigger-ord erstattes av salt-hash før sending)
- IP-adresser logges ikke i deteksjonshendelser; de logges kun ved samtykke-handlinger og innlogging for revisjons- og sikkerhetsspor
Krypterte rapporter (avsnitt a) er en separat datakanal og forblir uleselige for serveren. Dette avsnittet beskriver kun den valgfrie telemetrikanalen.
All kommunikasjon mellom appen og serveren skjer over HTTPS med TLS 1.2 eller nyere og moderne cipher-suites. Det betyr at selv om noen kontrollerer Wi-Fi-nettverket, kan de ikke avlytte eller endre dataene så lenge enhetens tillit til offentlige sertifikatutstedere er intakt.
4. Innlogging og brukerkonto
Nettvakten bruker Vipps Login som primær innloggingsmetode (BankID under panseret), med Google-innlogging (OAuth 2.0) som sekundær. Vi tar ikke imot innlogginspassord — det er en bevisst sikkerhetsbeslutning.
- Ingen innlogginspassord lagret Aktive kontoer har ingen passord-hash i databasen — all identitetsverifikasjon skjer hos Vipps eller Google. Det betyr at en eventuell database-lekkasje ikke gir angripere noe å brute-force for å overta kontoen din. (PIN-koden som låser opp foresatt-appen lagres som PBKDF2-hash hos oss for verifisering, men gir kun app-låsing — ikke konto-tilgang.)
- Vipps som standard Vipps Login bruker BankID for verifisering og gir oss en autoritativ aldersbekreftelse — for foresatte er kontoen 18+-bekreftet uten egen dokumentasjon
- Korte sesjoner Innloggingen bruker JWT access-token (15 min) + refresh-token (30 dager). Refresh-token fornyer access-token i bakgrunnen så lenge du er aktiv
- Sesjons-familie-binding Hver sesjon har en family-ID som binder access og refresh sammen. Ved utlogging revokeres hele familien — tokenet kan ikke gjenbrukes
- Fungerer på alle enheter Foreldre med iPhone kan bruke nettvakten.eu i nettleseren med samme Vipps- eller Google-innlogging
5. Hva skjer på serveren?
- Rapporter forblir kryptert Serveren mottar og lagrer den krypterte rapporten uten mulighet til å lese innholdet
- Rate limiting Alle endepunkter har begrensning på antall forsøk for å forhindre misbruk
- Sikkerhetslogging Alle innlogginger og mistenkelige hendelser logges
- Kort sesjonstid Økten din utløper automatisk og fornyes i bakgrunnen så lenge du er aktiv
6. Sikkerhet i nettportalen (nettvakten.eu)
Nettvakten sin nettside og brukerportal er bygget med flere lag av forsvar mot vanlige nettangrep. Tiltakene beskytter både vanlige brukere og administratorer.
For alle brukere (konto og nettside)
- Beskyttelse mot kodeinjeksjon (XSS) All brukerdata som vises i nettleseren saniteres gjennom HTML-escaping. Selv om en angriper registrerer et ondsinnet brukernavn eller e-postadresse, vil det aldri kunne kjøre som kode i nettleseren din. Dette hindrer datatyveri fra innloggede brukere.
- Content Security Policy (CSP) Nettleseren din instrueres til kun å laste ressurser fra godkjente kilder. Selv om en angriper klarer å injisere innhold, vil nettleseren blokkere forsøk på å laste ondsinnede skript fra ukjente servere.
- Sikker autentisering (JWT) Innloggingstoken verifiseres med kryptografisk signatursjekk (HMAC-SHA256) og utløper automatisk. Token-formatet valideres korrekt med base64url-dekoding for å forhindre at ugyldige token aksepteres.
- Ingen passord-flate hos oss Vi tar ikke imot brukerregistrering med passord — all kontoopprettelse går via Vipps eller Google. Det fjerner hele angrepsflaten for credential stuffing, brute-force og phishing av Nettvakten-passord.
- Hastighetsbegrensning (rate limiting) Chatbot-API-et begrenser antall forespørsler per time for å forhindre automatisert misbruk. Denne begrensningen er obligatorisk og kan ikke omgås selv om tjenesten er feilkonfigurert.
- Sikre lenker Alle eksterne lenker har beskyttelse mot window.opener-angrep, og chatbotens markdown-motor tillater kun lenker med http/https-protokoll for å forhindre javascript-injeksjon.
For administratorer
- Beskyttet admin-tilgang Administrasjonspanelet krever Google OAuth-innlogging. Passord-basert fallback er deaktivert for å forhindre phishing og brute-force mot admin-kontoer.
- Sanitert datavisning Alle brukerdata som vises i admin-dashboardet (e-postadresser, navn, abonnementsdetaljer, affiliate-koder) saniteres for å forhindre at ondsinnede brukere kan angripe administratoren gjennom lagret XSS.
- Ekstern kodeintegritet (SRI) Tredjepartsbiblioteker lastes med Subresource Integrity-hash. Hvis CDN-leverandøren kompromitteres, vil nettleseren nekte å kjøre den endrede koden.
Nettverks- og transportlag
- CORS-kontroll Chatbot-API-et godtar kun forespørsler fra nettvakten.eu og wiki-domenet. Andre nettsteder kan ikke sende forespørsler til API-et på vegne av brukeren.
- Referrer-policy Nettleseren instrueres til kun å dele referrer-informasjon med samme opprinnelse, slik at sensitiv URL-data ikke lekker til tredjeparter.
- Innholdstype-beskyttelse X-Content-Type-Options forhindrer at nettleseren feiltolker filtyper, noe som ellers kan utnyttes til å kjøre ondsinnet innhold.
Utviklermiljø vs. produksjon: Testdata og mock-API er fullstendig adskilt fra produksjonskoden. Ingen intern API-struktur, testnøkler eller mockdata er synlig i koden som deployes til nettvakten.eu.
7. Automatisk sletting (GDPR)
Nettvakten sletter data automatisk i henhold til disse reglene:
- Alle deteksjonshendelser: slettes automatisk etter 90 dager
- Eskalerte hendelser (sendt til politi/barnevern): 180 dager
Lagringstiden vil bli vurdert i dialog med Datatilsynet før produksjonslansering. Du kan også slette all data manuelt fra innstillingene når som helst.
8. Hva vi IKKE gjør
- Vi lagrer ALDRI rå skjermtekst fra barnets telefon
- Vi selger ALDRI data til tredjeparter
- Vi sender ALDRI ukryptert informasjon over nettet
- Etter E2E-migrasjonen (pågående) vil vi ikke lenger ha tilgang til å lese de krypterte rapportene på serveren — privat nøkkel flyttes til forelderens egen enhet
- Vi tar ALDRI imot innlogginspassord — verken i klartekst eller hashet. Innlogging går utelukkende via Vipps eller Google (OAuth). PIN-koden som låser opp foresatt-appen er den eneste hashede koden vi lagrer, og den gir kun app-låsing — ikke konto-tilgang
- Vi bruker ALDRI data til reklame eller profilering
9. Spørsmål?
Har du spørsmål om hvordan vi beskytter barnets data? Ta kontakt: