Browserhistorik som bevis: Chrome, Edge, Safari og Firefox

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Browserhistorikken viser, hvilke adresser der er indlæst, hvornår og hvordan brugeren kom dertil. Alle de store browsere gemmer historik, downloads og søgninger i SQLite-databaser i brugerens profil, og databaserne kan sikres og analyseres med stor præcision. Bevisværdien afhænger dog af, at tidsformater, synkronisering mellem enheder og automatisk oprydning håndteres korrekt.

Browseren er ofte vejen ud af en virksomhed: upload til en privat cloudtjeneste, webmail, deling via chattjenester eller adgang til en konkurrents systemer. Derfor er den en fast del af undersøgelsen, når en medarbejder mistænkes for at have taget data med.

Hvor ligger data?

Chrome (Windows) · Placering (standardprofil): %LOCALAPPDATA%\Google\Chrome\User Data\Default · Hoveddatabase: History
Edge (Windows) · Placering (standardprofil): %LOCALAPPDATA%\Microsoft\Edge\User Data\Default · Hoveddatabase: History
Firefox (Windows) · Placering (standardprofil): %APPDATA%\Mozilla\Firefox\Profiles og en mappe pr. profil · Hoveddatabase: places.sqlite
Safari (macOS) · Placering (standardprofil): ~/Library/Safari · Hoveddatabase: History.db

Ekstra profiler i Chrome og Edge ligger i mapper som Profile 1 og Profile 2, og hver Windows-bruger har sin egen profilmappe. Alle profiler og alle brugere på maskinen skal med i sikringen, ellers kan den relevante aktivitet ligge i en mappe, der aldrig blev kopieret. På macOS ligger Chrome, Edge og Firefox tilsvarende under ~/Library/Application Support. På Linux ligger Chrome som standard under ~/.config/google-chrome og Firefox under ~/.mozilla/firefox, men stierne kan flyttes med indstillinger og miljøvariabler og skal derfor kontrolleres.

Chrome og Edge (Chromium)

Edge bygger på samme motor som Chrome, og databaserne er næsten ens. I History findes blandt andet disse tabeller:

urls: adresser, sidetitler, antal besøg og seneste besøg.
visits: de enkelte besøg med henvisning til forrige besøg og en overgangstype, der skelner mellem indtastet adresse, klikket link, bogmærke og omdirigering.
downloads og downloads_url_chains: downloadede filer, gemt sti, størrelse, start- og sluttidspunkt, kilde-URL og eventuelle omdirigeringer.
keyword_search_terms: søgeord indtastet i adresselinjen.

Overgangstypen er værdifuld, fordi den kan skelne mellem en side, brugeren aktivt har tastet sig frem til, og en side, der er hentet automatisk som følge af en omdirigering eller en reklame. Andre nyttige filer i profilen er Cookies, Web Data (autofyld), Shortcuts, Top Sites, Favicons og Login Data. Den sidste indeholder gemte logins, hvor adgangskoderne er krypteret med operativsystemets nøglebeskyttelse. I en civil sag er det oftest nok at dokumentere, at der findes et gemt login til en bestemt tjeneste og under hvilket brugernavn. Selve adgangskoden er sjældent relevant.

Tidsstempler i Chromium er mikrosekunder siden 1. januar 1601 UTC, samme epoke som Windows FILETIME, men i en anden enhed.

Chrome fjerner som udgangspunkt historik efter en periode. Googles hjælpeside angiver på tidspunktet for gennemgangen (oktober 2026), at historikken viser besøg fra de seneste 90 dage. Ældre aktivitet kan dog stadig findes andre steder, fx i downloads-tabellen, cookies, favicons eller systemets egne artefakter.

Firefox

places.sqlite indeholder:

moz_places: adresser, titler og en tæller for besøg.
moz_historyvisits: de enkelte besøg med tidspunkt, besøgstype og henvisning til forrige besøg.
moz_annos: annotationer, som blandt andet bruges til oplysninger om downloads.

Andre relevante filer er formhistory.sqlite (formularindtastninger), cookies.sqlite og sessionstore-filen, der beskriver åbne faner og vinduer. Sessionsfilen er komprimeret med en Mozilla-variant af LZ4 og kræver et værktøj, der kan pakke den ud. Tidsstempler i Firefox er mikrosekunder siden 1. januar 1970 UTC.

Safari

History.db indeholder blandt andet history_items (adresser) og history_visits (besøg). Downloads beskrives i Downloads.plist. Tidsstempler i Safari er sekunder med decimaler siden 1. januar 2001 UTC, også kaldet Apples Core Data-tid.

Adgang til Safaris data på en kørende Mac kræver, at analyseværktøjet har fuld diskadgang i macOS’ privatlivsindstillinger. Den tilladelse skal gives af en administrator og dokumenteres som en del af metoden. Det grundlæggende om sikring af Mac er beskrevet i Bevissikring af Mac.

Tidsformater samlet

Chrome, Edge · Epoke: 1601-01-01 UTC · Enhed: mikrosekunder
Firefox · Epoke: 1970-01-01 UTC · Enhed: mikrosekunder
Safari · Epoke: 2001-01-01 UTC · Enhed: sekunder med decimaler

Forveksles epoker eller enheder, bliver tidspunkterne forkerte med år eller årtier. En mere lumsk fejl er visning i forkert tidszone, hvor alle tidspunkter rykkes en eller to timer, og fejlen kun opdages, når de sammenholdes med andre kilder. Kontrollér altid omregningen mod en kendt hændelse, fx et besøg, der også fremgår af en mail eller en serverlog. Metoden er beskrevet i Tidslinjeanalyse.

Synkronisering

Når en bruger er logget ind med Google-konto, Microsoft-konto, Firefox-konto eller iCloud, kan historik fra andre enheder blive synkroniseret ind i den lokale database. Det har tre konsekvenser:

Et besøg i databasen er ikke nødvendigvis foretaget på den undersøgte computer. Det kan stamme fra en telefon eller en privat computer. Spor fra privat browsing og fra installerede udvidelser er beskrevet i Privat browsing og inkognito og Browserudvidelser som spor.
Nyere versioner af browserne kan i visse tabeller angive, om et besøg stammer fra en anden enhed. Hvilke felter der findes, afhænger af browser og version og skal kontrolleres i den konkrete database.
Omvendt kan historik, der er slettet lokalt, stadig findes på andre enheder eller i kontoen.

En påstand om, at et besøg er foretaget på netop denne computer, skal derfor understøttes af andre spor: en download til en lokal sti, Prefetch for et program, der blev startet bagefter, LNK-filer eller filsystemets tidsstempler. Se Windows-artefakter.

Privat browsing og sletning

Private vinduer (Inkognito, InPrivate, privat vindue) skriver normalt ikke historik til disken. Spor kan dog findes i DNS-cache, i hukommelsen, i netværkslogs og hos tjenesten selv. Er computeren tændt, kan en hukommelsessikring være relevant, se Hukommelsessikring (RAM).
Slettet historik kan nogle gange gendannes fra ledige sider i SQLite-databasen, fra WAL- eller journalfiler, fra skyggekopier eller fra backup.
Selve sletningen kan efterlade spor, fx et pludseligt hul i en ellers kontinuerlig historik eller en tom database på en computer, der er brugt dagligt. Fundet skal tolkes varsomt, som beskrevet i Anti-forensics.

Sikring

Kopiér databaserne sammen med de tilhørende journal-, wal- og shm-filer. Uden dem kan de seneste data mangle, fordi SQLite skriver nye poster til WAL-filen, før de flyttes til selve databasen.
Åbn aldrig originaldatabasen i et værktøj, der kan skrive til den. Selv en almindelig SQLite-browser kan gennemføre et checkpoint, der flytter data fra WAL-filen og overskriver ledige sider med gendannelige poster.
Luk ikke browseren på en tændt computer uden overvejelse. Åbne faner, sessioner og data i hukommelsen kan være relevante.
Sikr hele profilen, ikke kun historikfilen. Cookies, sessioner og udvidelser kan forklare aktivitet, som historikken alene ikke forklarer.
Beregn hashværdier for de kopierede filer straks, og notér browserversion, profilnavn og operativsystem.

Det bedste udgangspunkt er en forensisk kopi af hele disken, hvor profilen udtrækkes bagefter. Er det ikke muligt, skal en målrettet logisk kopi dokumenteres med metode og værktøj.

Hvad historikken viser, og hvad den ikke viser

Historikken viser, at en adresse er indlæst i en browserprofil på et bestemt tidspunkt. Den viser ikke, at brugeren har læst siden, hvor længe den var åben i forgrunden, eller hvem der sad ved tastaturet. Den viser heller ikke direkte, at en fil er uploadet. Et besøg på en upload-side kombineret med en fil, der blev åbnet umiddelbart før, og tjenestens egne logs kan dog tilsammen give et stærkt billede. Den slags logs fra cloudtjenester behandles i Cloud-forensic.

I rapporten bør hvert fund angives med databasefil, tabel, rå værdi og omregnet tidspunkt med tidszone, så en anden sagkyndig kan efterprøve konklusionen. Forbehold om synkronisering og om, hvem der havde adgang til profilen, hører med.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Discord teknisk: servere, kanaler, lokal cache og dataudtræk · SQLite i forensic: WAL-filer, frie sider og slettede rækker

→ Digital forensics-undersøgelse · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik