Google résout un problème de confidentialité de longue date qui, pendant des années, a permis aux sites Web de déterminer l’historique de navigation des utilisateurs via les liens précédemment visités.
Le problème vient du fait que les sites permettent de styliser les liens comme »: visité », c’est-à-dire de les afficher sous une autre couleur au lieu du bleu par défaut si un utilisateur avait déjà cliqué dessus.
Le système affiche ce changement de couleur quel que soit le site sur lequel ils se trouvaient lorsqu’ils ont cliqué sur le lien, ce qui permet à d’autres sites d’utiliser potentiellement des scripts créatifs qui divulguent l’historique de navigation de l’utilisateur.
Le problème n’est pas seulement un problème théorique de confidentialité pour les utilisateurs, mais introduit également une série de responsabilités réelles en matière de sécurité qui permettent le suivi, le profilage et l’hameçonnage.
Les chercheurs ont démontré plusieurs classes d’attaques dans le passé liées à cette lacune en matière de confidentialité, notamment le timing, le pixel, l’interaction de l’utilisateur et les attaques au niveau du processus.
La prochaine version de Google Chrome, la version numéro 136, résoudra enfin le problème des 20 ans en implémentant un partitionnement à trois touches des liens « visités ».
Au lieu de stocker globalement les visites de liens, Chrome partitionne désormais chaque lien visité à l’aide de trois clés, à savoir l’URL du lien (cible du lien), le site de niveau supérieur (domaine de la barre d’adresse) et l’origine du cadre (origine du cadre où le lien est rendu).
Cela garantit qu’un lien n’apparaîtra que comme :visité sur le même site et dans la même origine de cadre où l’utilisateur a précédemment cliqué dessus, éliminant ainsi les fuites d’historique intersites.
Pour préserver la convivialité, Google a ajouté une exception « auto-liens », de sorte que les liens visités d’un site seront toujours marqués comme visités sur ce site même si l’utilisateur a cliqué dessus à partir d’un autre site.
Un site Web sait déjà quelles pages l’utilisateur a visitées, donc cette exception n’introduit pas de fuite d’historique indésirable.
Google dit que la dépréciation complète du sélecteur: visited éliminerait les indices UX précieux, ce qui a donc été exclu des objectifs de la proposition. Une autre solution rejetée consistait à utiliser un modèle basé sur les autorisations, car il serait facile de contourner ou même d’abuser des sites Web manipulateurs.
Comment activer
La nouvelle isolation: visited a été introduite en tant que fonctionnalité expérimentale sur Chrome version 132 et devrait être activée par défaut sur Chrome 136 (à venir).
De Chrome 132 à 135 (plus récent), les utilisateurs peuvent activer la fonctionnalité en entrant chrome: / / flags / #partition-visited-link-database-with-self-links dans la barre d’adresse et en définissant l’option sur « activé ».’
La fonctionnalité n’est pas encore stable, elle pourrait donc ne pas fonctionner comme prévu dans toutes les situations.
Sur les autres principaux navigateurs, le risque de styles visités reste partiellement non traité.
Firefox limite les styles auxquels ils sont appliqués: visités et empêche JavaScript de les lire, mais il n’y a pas de partitionnement pour les isoler des vecteurs d’attaque sophistiqués.
Safari applique également des restrictions et utilise des protections de confidentialité agressives comme la Prévention intelligente du suivi, atténuant quelque peu les fuites, mais il n’y a pas de partitionnement pour bloquer toutes les attaques.