La société Google des changements à venir dans Chrome visant à renforcer la confidentialité. La première partie des changements concerne le traitement des cookies et le support de l'attribut SameSite. À partir de la version Chrome 76, attendue en juillet, un drapeau «same-site-by-default-cookies», qui, en l'absence de l'attribut SameSite dans l'en-tête Set-Cookie, définira par défaut la valeur «SameSite=Lax», limitant l'envoi de cookies pour les inserts de sites tiers (mais les sites pourront toujours annuler cette restriction en définissant explicitement la valeur SameSite=None lors de la définition des cookies).
Attribut permet de définir les situations dans lesquelles le transfert de cookies est autorisé lors de la réception d'une requête d'un site tiers. Actuellement, le navigateur envoie des cookies pour toute requête vers un site pour lequel des cookies ont été définis, même si le site a été ouvert à partir d'un autre site, et que la requête est effectuée indirectement via le chargement d'une image ou à travers un iframe. Les réseaux publicitaires exploitent cette caractéristique pour suivre les mouvements des utilisateurs entre les sites, tandis que
des attaquants pour organiser (lorsqu'un site contrôlé par l'attaquant est ouvert, une requête est discrètement envoyée à un autre site sur lequel l'utilisateur actuel est authentifié, et le navigateur de l'utilisateur envoie des cookies de session pour cette requête). D'un autre côté, la possibilité d'envoyer des cookies vers des sites tiers est utilisée pour insérer des widgets sur les pages, par exemple, pour l'intégration avec YouTube ou Facebook.
Avec l'attribut SameSite, il est possible de contrôler le comportement lors de l'émission de cookies et de restreindre l'envoi de cookies uniquement en réponse à des requêtes initiées depuis le site à partir duquel ces cookies ont été initialement reçus. SameSite peut prendre trois valeurs : «Strict», «Lax» et «None». En mode «Strict», les cookies ne sont pas envoyés pour tout type de requêtes intersites, y compris tous les liens entrants de sites externes. En mode «Lax», des restrictions moins strictes s'appliquent et l'envoi de cookies est bloqué uniquement pour les sous-requêtes intersites, telles que les requêtes d'images ou le chargement de contenu via un iframe. La différence entre «Strict» et «Lax» réside dans le blocage des cookies lors du passage par un lien.
Parmi les autres changements à venir, une restriction stricte est également prévue, interdisant le traitement des cookies tiers pour les requêtes sans HTTPS (avec l'attribut SameSite=None, les cookies ne pourront être définis qu'en mode Secure). De plus, des travaux seront réalisés pour se protéger contre l'utilisation de l'identification cachée (« browser fingerprinting »), y compris les méthodes de génération d'identifiants basées sur des données indirectes, telles que , la liste des types MIME pris en charge, les paramètres spécifiques dans les en-têtes ( et ), l'analyse des plugins installés , la disponibilité de certaines API Web spécifiques aux cartes graphiques pour le rendu à l'aide de WebGL et Canvas, avec CSS, l'analyse des particularités de l'interaction avec et .
De plus, dans Chrome contre les abus liés à la difficulté de retourner à la page d'origine après avoir visité un autre site. Il s'agit de la pratique de surcharger l'historique de navigation par une série de redirections automatiques ou d'ajouter artificiellement de fausses entrées dans l'historique (via pushState), ce qui empêche l'utilisateur d'utiliser le bouton « Retour » pour revenir à la page d'origine après un passage accidentel ou un redirection forcée vers un site de fraude ou malveillant. Pour se protéger contre de telles manipulations, Chrome ignorera dans le gestionnaire de bouton Retour les entrées associées aux redirections automatiques et aux manipulations de l'historique de navigation, ne laissant que les pages ouvertes par des actions explicites de l'utilisateur.
Source : opennet.ru
