Un browser dichiara Europe/London mentre un database IP colloca la richiesta in America/New_York. È un disaccordo tra due osservazioni, e vale la pena registrarlo. Non è la prova che il visitatore usi una VPN, e trattarlo come prova è l'errore della maggior parte delle implementazioni. Il confronto qui sotto tiene separati i due valori e le loro modalità di errore.

Due osservazioni con proprietari diversi

Il valore del browser è un'impostazione: il fuso che il sistema operativo o l'utente ha scelto per formattare le date. Il valore del database è una stima associata a una rete IP, prodotta da un fornitore che mappa blocchi di indirizzi su luoghi. Nessuno dei due è un'affermazione autenticata su dove si trovi il visitatore, e nessuno dei due sa quale percorso di rete abbia seguito la richiesta.

Poiché i proprietari differiscono, i due valori possono divergere per ragioni che non hanno nulla a che vedere con gli strumenti per la privacy. Un viaggiatore che mantiene il fuso di casa, un portatile aziendale bloccato sull'ora della sede, un collegamento satellitare con uscita regionale o una riga obsoleta del database producono tutti una discrepanza.

Come viene prodotto davvero ciascun valore

Un browser può leggere il fuso risolto con new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone

, che restituisce un identificatore IANA derivato dalle impostazioni del formattatore. Non richiede un permesso di localizzazione e non consulta il GPS. Sul server, risolvi l'indirizzo del client dalla configurazione del proxy fidato, poi cercalo presso un fornitore approvato. Un'intestazione di inoltro fornita dal visitatore non è automaticamente quell'indirizzo.vpnDetectedMemorizza le due osservazioni come campi separati con l'ora dell'osservazione e l'esito della ricerca. Chiamare il campo derivato

vpnDetected

quando il calcolo è solo un confronto di fusi incorpora una conclusione in una misurazione e rende più difficile la revisione successiva.Cosa provano l'accordo e il disaccordo
OsservazioneCosa lascia irrisolto
Fusi dichiarati diversiUn viaggio, un'impostazione mantenuta, un gateway aziendale, un proxy o un errore del database possono tutti produrlo.
Lo stesso fuso dichiaratoUn'uscita VPN può trovarsi nel fuso dell'utente, quindi l'accordo non stabilisce una connessione diretta.

Un valore mancante o non valido

Il confronto non è disponibile, il che non è né una corrispondenza né una discrepanza.

L'asimmetria conta più di quanto suggerisca la tabella. Una discrepanza ha molte spiegazioni innocenti, mentre una corrispondenza ne ha almeno una colpevole, quindi nessuna delle due direzioni sostiene una regola categorica. Le note di accuratezza del fornitore descrivono precisione limitata e dati mancanti, e sottolineano che un servizio di anonimizzazione può esporre la posizione del proprio server anziché quella dell'utente.

Ecco perché il segnale appartiene a un punteggio di rischio con una motivazione registrata e uno stato sconosciuto esplicito, non a un booleano che governa l'accesso.

Gli scostamenti UTC non sono una scorciatoia

Confrontare gli scostamenti invece degli identificatori di fuso non corregge l'inferenza. Due fusi diversi possono condividere uno scostamento per parte dell'anno, e lo stesso fuso può cambiare scostamento al confine dell'ora legale. Se una funzione ha davvero bisogno di uno scostamento per la pianificazione, calcolalo per l'istante specifico invece di memorizzare un solo numero e riusarlo come prova di identità.

Il confronto tra stringhe ha la sua trappola: due grafie dello stesso fuso, o un alias legacy, differiscono come testo pur descrivendo la stessa impostazione. Convalida gli identificatori e confronta tramite la gestione dei fusi della piattaforma invece di confrontare stringhe grezze.

Bloccare o valutare: scegli la risposta con intenzione

Articoli correlati