Fuseau horaire du navigateur contre localisation IP : comparaison d’un signal de risque
Le fuseau du navigateur et le fuseau déduit de l’IP mesurent des choses différentes. Comparez ce que chacun peut prouver avant qu’une divergence ne devienne un verdict VPN dans votre modèle de risque.
Un navigateur annonce Europe/London tandis qu’une base de données IP situe la requête à America/New_York. C’est une divergence entre deux observations, et elle mérite d’être consignée. Ce n’est pas la preuve que le visiteur utilise un VPN, et c’est précisément en la traitant comme une preuve que la plupart des implémentations se trompent. La comparaison ci-dessous garde les deux valeurs, et leurs modes d’échec, séparés.
Deux observations aux propriétaires différents
La valeur du navigateur est un réglage : le fuseau choisi par le système d’exploitation ou l’utilisateur pour formater les dates. La valeur de la base de données est une estimation rattachée à un réseau IP, produite par un fournisseur qui associe des blocs d’adresses à des lieux. Ni l’une ni l’autre n’est une déclaration authentifiée sur l’endroit où se trouve le visiteur, et aucune ne sait quel chemin réseau la requête a emprunté.
Parce que les propriétaires diffèrent, les deux valeurs peuvent diverger pour des raisons sans aucun rapport avec des outils de confidentialité. Un voyageur qui conserve le fuseau de son domicile, un portable d’entreprise calé sur l’heure du siège, une liaison satellite à sortie régionale ou une ligne obsolète dans la base produisent tous une divergence.
Comment chaque valeur est réellement produite
Un navigateur peut lire son fuseau résolu avec new Intl.DateTimeFormat().resolvedOptions().timeZone, qui renvoie un identifiant IANA dérivé des réglages du formateur. Il ne demande pas d’autorisation de localisation et ne consulte pas le GPS. Côté serveur, déterminez l’adresse du client à partir de votre configuration de proxy de confiance, puis consultez-la auprès d’un fournisseur approuvé. Un en-tête de transfert fourni par le visiteur n’est pas automatiquement cette adresse.
Conservez les deux observations dans des champs distincts, avec l’heure de l’observation et le résultat de la recherche. Nommer le champ dérivé vpnDetected alors que le calcul n’est qu’une comparaison de fuseaux inscrit une conclusion dans une mesure et rend la revue ultérieure plus difficile.
Ce que prouvent la concordance et la divergence
| Observation | Ce qu’elle laisse non résolu |
|---|---|
| Fuseaux déclarés différents | Un déplacement, un réglage conservé, une passerelle d’entreprise, un proxy ou une erreur de base de données peuvent tous le produire. |
| Le même fuseau déclaré | Une sortie VPN peut se trouver dans le fuseau de l’utilisateur, donc une concordance n’établit pas une connexion directe. |
| Une valeur manquante ou invalide | La comparaison est indisponible, ce qui n’est ni une concordance ni une divergence. |
L’asymétrie compte plus que le tableau ne le suggère. Une divergence a beaucoup d’explications innocentes, tandis qu’une concordance en a au moins une coupable, donc aucune direction ne soutient une règle catégorique. Les propres notes de précision du fournisseur décrivent une précision limitée et des données manquantes, et signalent qu’un service d’anonymisation peut exposer la localisation de son serveur plutôt que celle de l’utilisateur.
C’est pourquoi le signal appartient à un score de risque avec une raison consignée et un état inconnu explicite, pas à un booléen qui contrôle l’accès.
Les décalages UTC ne sont pas un raccourci
Comparer des décalages au lieu des identifiants de fuseau ne répare pas l’inférence. Deux fuseaux différents peuvent partager un décalage une partie de l’année, et un même fuseau peut changer de décalage à une limite d’heure d’été. Si une fonction a réellement besoin d’un décalage pour planifier, calculez-le pour l’instant précis au lieu de stocker un seul nombre et de le réutiliser comme preuve d’identité.
La comparaison de chaînes a son propre piège : deux graphies d’un même fuseau, ou un ancien alias, différeront comme texte tout en décrivant le même réglage. Validez les identifiants et comparez via la gestion des fuseaux horaires de la plateforme au lieu de faire correspondre des chaînes brutes.
Bloquer ou noter : choisissez la réponse délibérément
Pour afficher l’heure, demandez au visiteur quel fuseau il préfère et arrêtez-vous là. Pour un système de risque applicatif, traitez une divergence comme un signal contextuel faible aux côtés de preuves adaptées au modèle de menace réel, et laissez une recherche échouée produire un inconnu plutôt qu’une détection silencieuse. Bloquer sur la seule comparaison transforme un manque de mesure en accusation vis-à-vis de l’utilisateur.
Si une décision lourde de conséquences exige une assurance plus forte, utilisez une étape de vérification ou d’authentification conçue pour cela. Une heuristique de fuseau horaire ne peut pas fournir cette assurance, et un détecteur qui compte l’absence de preuve comme un succès peut sembler efficace tout en répondant à une autre question que celle que vous avez posée.