TL;DR Executive

L’attribution d’usage à partir d’artefacts navigateur est possible mais probabiliste. Les artefacts les plus robustes proviennent de la corrélation multi-sources (historique SQLite, cookies, cache, téléchargements, sessions, profil utilisateur OS, journaux système), et non d’un seul champ (ex. URL visitée). Les navigateurs modernes (Chrome/Edge Chromium, Firefox) conservent de nombreux indices, même après nettoyage partiel, mais la persistance varie selon mode de navigation, synchronisation cloud et politiques de confidentialité [1][2][3][8][10]. Conclusion opérationnelle: en contexte civil/pénal, il faut présenter l’attribution comme un niveau de confiance argumenté (fort/moyen/faible), documenter les hypothèses alternatives (partage de poste, synchronisation multi-device, profil compromis), et valider les résultats avec au moins un second outil/méthode conformément aux bonnes pratiques forensiques [11][12].

—

1) Problématique

Comment attribuer l’usage web à une personne donnée (et non seulement à une machine) à partir des traces Chrome/Edge/Firefox, en minimisant les faux positifs et les contestations probatoires?

2) Méthodologie

2.1 Périmètre de recherche

  • Sujet: attribution d’usage via artefacts navigateur desktop (Chrome, Edge, Firefox), avec focus Windows.
  • Fenêtre de veille: sources techniques et académiques accessibles publiquement.

2.2 Volume et sélection des sources

  • URL évaluées: 15
  • URL retenues/analyées en profondeur: 12
  • URL exclues: 3 (contenu trop marketing, redondant ou insuffisamment vérifiable)

2.3 Critères d’inclusion

  1. Sources primaires normatives/éditeur (NIST, RFC, docs Chromium/Mozilla/Microsoft) [6][7][8][9][10][11][12].
  2. Littérature académique récente sur la récupération d’artefacts multi-modes [1][2][3].
  3. Outils forensiques reconnus, utilisés comme sources secondaires techniques (avec prudence sur biais commerciaux) [4][5].

2.4 Limites méthodologiques

  • Plusieurs articles académiques complets sont partiellement accessibles (abstract/introduction).
  • Les structures exactes de bases SQLite évoluent par version navigateur.
  • L’attribution personne↔machine dépend d’éléments hors navigateur (contexte RH/accès/poste partagé).

—

3) Cadre conceptuel d’attribution

L’attribution d’usage repose sur trois niveaux:

  1. Présence technique: l’artefact existe (ex. entrée de visite, cookie, cache).
  2. Lien session/profil: l’artefact est rattaché à un profil navigateur/local state spécifique [6][7][8].
  3. Lien personne: le profil est rattaché à un individu (compte OS, créneau horaire, habitudes, facteurs contextuels).

Un seul niveau ne suffit pas. En pratique, la valeur probante provient de la convergence de plusieurs artefacts et métadonnées temporelles [1][3][11].

—

4) Artefacts clés par navigateur

4.1 Chrome / Edge (Chromium)

  • Les données utilisateur (historique, cookies, favoris, etc.) résident dans le *user data directory* et ses profils (Default, Profile X) [6].
  • Les traces forensiques typiques incluent: URL, téléchargements, cookies, local storage, extensions, préférences [4].
  • Edge étant Chromium, la logique d’artefacts est proche, avec impact potentiel de la synchronisation entreprise/cloud [10].

Impact attribution:

  • Forte valeur pour établir une activité sur un profil donné.
  • Risque de confusion si profils multiples, usage partagé, ou sync active sur plusieurs appareils [10].

4.2 Firefox

  • Le profil Firefox contient historique, paramètres et autres données; emplacement documenté par Mozilla [7].
  • places.sqlite reste central pour historique et signaux de navigation; d’autres artefacts complètent (cache, sessions, etc.) [5][7].

Impact attribution:

  • Bonne reconstruction de parcours web si base intacte.
  • Nécessité de conversion temporelle correcte et vérification timezone/horloge système [5].

—

5) Points critiques pour l’attribution d’usage

5.1 Le mode privé n’efface pas tout risque probatoire

Les navigateurs annoncent la non-conservation locale de certains éléments en mode privé, mais cela ne signifie pas anonymat complet (réseau, OS, mémoire, téléchargements conservés localement, etc.) [8]. Les études récentes montrent que des artefacts restent parfois récupérables selon scénarios et outils [1][2][3].

5.2 L’horodatage n’est pas une vérité absolue

Les artefacts navigateur dépendent de conventions temporelles (UTC, epoch, microsecondes) et d’une chaîne de conversion fiable. Une mauvaise normalisation temporelle peut créer des corrélations erronées [5][9].

5.3 Effets de la synchronisation cloud

Avec Edge/Chrome/Firefox, la synchronisation inter-appareils peut propager historique/onglets/données de session, brouillant l’origine exacte d’une action si l’enquêteur n’isole pas les terminaux et comptes [10].

5.4 Effets SQLite (WAL/SHM) sur récupération

La présence de fichiers -wal et -shm peut contenir des écritures récentes non encore checkpointées; les ignorer réduit la complétude, les interpréter sans méthode augmente le risque d’erreur [9].

5.5 Biais outil

Les outils commerciaux/open-source accélèrent l’analyse mais imposent leur logique de parsing. Sans validation croisée, il existe un risque d’artefacts manqués ou mal interprétés [4][11][12].

—

6) Modèle de décision probatoire (pratique)

Niveau de confiance fort

  • Concordance multi-artefacts (historique + cookie/session + téléchargement + cache + horodatages cohérents)
  • Rattachement stable à un compte OS/profil utilisateur
  • Absence d’hypothèse alternative crédible

Niveau de confiance moyen

  • Traces cohérentes mais incomplètes (ex. historique seul + peu de contexte système)
  • Sync multi-device possible mais non tranchée

Niveau de confiance faible

  • Artefacts isolés, timeline instable, poste partagé, ou altération potentielle non exclue

—

7) Procédure recommandée (tribunal-ready)

  1. Acquisition forensique incluant profils navigateur + fichiers auxiliaires (WAL/SHM/cache) avec hash et chaîne de possession [11].
  2. Normalisation temporelle explicite (UTC/local, dérive horloge).
  3. Corrélation avec événements OS et contexte compte utilisateur.
  4. Validation croisée (au moins 2 méthodes/outils + requêtes SQL manuelles ciblées).
  5. Rapport d’incertitude: ce qui est établi vs probable vs non démontrable [11][12].

—

8) Discussion critique

  • La littérature récente confirme une récupération significative d’artefacts en modes normal/privé/portable, mais l’écart entre *recoverable* et *attributable to a person* demeure central [1][2][3].
  • Les docs éditeurs (Chromium/Mozilla/Microsoft) améliorent la localisation et l’interprétation technique, mais ne suffisent pas à la qualification juridique de l’auteur [6][7][10].
  • Les standards de pratique (NIST/CFTT) imposent rigueur méthodologique: reproductibilité, validation outil, et neutralité dans l’interprétation [11][12].

—

9) Conclusion

L’analyse forensique des artefacts navigateur permet une reconstruction fiable d’usage web au niveau du profil et de l’appareil. L’attribution à une personne exige toutefois un raisonnement de convergence et une expression explicite des incertitudes. En pratique, la meilleure stratégie est un modèle de preuve gradué (fort/moyen/faible), adossé à des sources primaires, une validation technique croisée et une documentation complète de la chaîne de possession.

—

Références

  1. **Advancing Web Browser Forensics: Critical Evaluation of Emerging Tools and Techniques** — arXiv (2024), URL — https://arxiv.org/html/2410.12605v1
  2. **Advancing Web Browser Forensics: Critical Evaluation of Emerging Tools and Techniques** — SN Computer Science / Springer (2025), URL — https://link.springer.com/article/10.1007/s42979-025-03921-6
  3. **Forensic analysis of web browsers lifecycle: A case study** — ScienceDirect / Forensic Science International: Digital Investigation (2024), URL — https://www.sciencedirect.com/science/article/abs/pii/S2214212624001418
  4. **Hindsight (Chromium browser forensics tool)** — Obsidian Forensics (GitHub), URL — https://github.com/obsidianforensics/hindsight
  5. **Mozilla Firefox (forensic artifact notes)** — Forensics Wiki, URL — https://forensics.wiki/mozilla_firefox/
  6. **Chromium User Data Directory** — Chromium Docs, URL — https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md
  7. **Profiles – Where Firefox stores user data** — Mozilla Support, URL — https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data
  8. **Private Browsing – Use Firefox without saving history** — Mozilla Support, URL — https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history
  9. **Write-Ahead Logging (WAL)** — SQLite Documentation, URL — https://www.sqlite.org/wal.html
  10. **Configure Microsoft Edge enterprise sync** — Microsoft Learn, URL — https://learn.microsoft.com/en-us/deployedge/microsoft-edge-enterprise-sync
  11. **NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response** — NIST, URL — https://csrc.nist.gov/pubs/sp/800/86/final
  12. **Computer Forensics Tool Testing Program (CFTT)** — NIST, URL — https://www.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt

Articles qui pourraient vous intéresser