Contacter l'assistance

Nous répondons par e-mail, en général sous deux jours.

Pour prévenir les abus, Google reCAPTCHA vérifie cet envoi ; des données sont transmises à Google. Le script n'est chargé qu'à l'ouverture de ce formulaire.

← Tous les articles

Pourquoi la liste d'exclusion n'est pas hachée

Quand on construit son site, on l'ouvre vingt fois par jour. Sur un compteur à quarante visiteurs par mois, la moitié des statistiques, c'est vous. D'où un réglage : ne pas compter les visites depuis ma propre adresse.

Partout ailleurs dans ce service, les adresses sont hachées avec un sel secret et une date, et l'adresse elle-même n'atteint jamais le stockage. À cet unique endroit, elle est conservée telle que vous l'avez saisie, en clair. C'est une décision délibérée et elle mérite d'être dite plutôt que laissée à découvrir.

La version essayée en premier

La première mise en œuvre stockait une somme de contrôle de l'adresse, en cohérence avec tout le reste. Elle marchait, elle stockait moins, et elle était presque inutile : la plupart des connexions domestiques reçoivent une nouvelle adresse chaque jour. L'exclusion était juste au moment où vous la posiez et sans valeur le lendemain matin.

Ce qui survit à un changement quotidien, c'est une plage — typiquement le /24 ou le /16 du fournisseur, qui reste identique pendant que la dernière partie tourne. Et une plage ne se compare pas comme une somme de contrôle. Le hachage détruit l'ordre exprès, et « cette adresse est-elle dans cette plage » est une question d'ordre. Il n'y a pas de contournement astucieux ; les deux exigences pointent en sens opposés.

La plage est donc stockée telle que saisie, normalisée, à côté de ses deux bornes de seize octets chacune, et un unique BETWEEN tranche. IPv4 est écrite sous sa forme IPv6 pour que les deux familles aient la même largeur et qu'une seule comparaison couvre les deux.

Pourquoi ce compromis est acceptable ici

Ce qui est stocké, c'est le propre réseau de l'exploitant, saisi par lui, réaffiché à lui et supprimable par lui à tout moment. Ce n'est pas l'adresse d'un visiteur. La politique de confidentialité le dit dans les mêmes termes, car l'alternative — décrire le service comme hachant tout et excepter cela en silence — serait ce genre d'affirmation vraie dans les grandes lignes qui vaut moins que pas d'affirmation du tout.

La limite est de dix entrées par compteur : assez pour la maison, le bureau et le mobile, assez peu pour que la liste ne devienne pas un entrepôt d'adresses.

Le second type, pour ce qui bouge

Une partie du trafic a une identité stable et une adresse instable : votre propre surveillance de disponibilité, le récupérateur d'aperçus d'une messagerie, un service de vérification. Aucune plage ne les attrape.

Pour eux, l'exclusion compare un fragment de l'identification du navigateur. Saisir uptimerobot attrape la chaîne complète qu'il envoie. Le minimum est de quatre caractères, car un fragment de deux lettres figurerait dans presque toutes les identifications et couperait le compteur entièrement.

Le point général

Une conception de confidentialité est un ensemble de compromis, et les parties intéressantes sont celles où une règle a dû plier. Les règles qui ne plient jamais signifient généralement que personne ne les a encore confrontées à une exigence réelle.

Ce qu'il faut éviter, c'est d'en plier une en silence. Un champ haché qui ne l'est pas vraiment, décrit dans la documentation comme s'il l'était, est pire qu'un champ en clair décrit clairement — il dépense une confiance qu'il n'a pas gagnée, et finira par être trouvé par quelqu'un qui ne s'attendait pas à devoir vérifier.

Publicité