Nettleserens tidssone mot IP-plassering: et risikosignal sammenlignet
Nettleserens sone og sonen utledet fra IP måler ulike ting. Sammenlign hva hver av dem kan bevise før et avvik blir en VPN-dom i risikomodellen din.
En nettleser rapporterer Europe/London mens en IP-database plasserer forespørselen i America/New_York. Det er en uenighet mellom to observasjoner, og den er verdt å registrere. Det er ikke bevis for at besøkeren bruker VPN, og å behandle det som bevis er der de fleste implementasjoner går galt. Sammenligningen nedenfor holder de to verdiene og feilmodusene deres atskilt.
To observasjoner med ulike eiere
Nettleserverdien er en innstilling: sonen operativsystemet eller brukeren valgte for å formatere datoer. Databaseverdien er et anslag knyttet til et IP-nettverk, produsert av en leverandør som kartlegger adresseblokker til steder. Ingen av dem er en autentisert uttalelse om hvor besøkeren står, og ingen av dem vet hvilken nettverksvei forespørselen tok.
Fordi eierne er forskjellige, kan de to verdiene avvike av grunner som ikke har noe med personvernverktøy å gjøre. En reisende som beholder hjemsonen, en bedriftsbærbar låst til hovedkontorets tid, en satellittlenke med regional utgang, eller en utdatert databaserad gir alle et avvik.
Hvordan hver verdi faktisk produseres
En nettleser kan lese den oppløste sonen sin med new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone
, som returnerer en IANA-identifikator utledet fra formateringsinnstillingene. Den ber ikke om posisjonstillatelse og konsulterer ikke GPS. På serveren, løs opp klientadressen fra din klarerte proxy-konfigurasjon, og slå den deretter opp hos en godkjent leverandør. En videresendingsheader som besøkeren oppgir er ikke automatisk den adressen.vpnDetectedLagre de to observasjonene som separate felt sammen med observasjonstiden og resultatet av oppslaget. Å kalle det utledede feltet
vpnDetected
| når beregningen bare er en sonesammenligning, baker en konklusjon inn i en måling og gjør senere gjennomgang vanskeligere. | Hva samsvar og avvik beviser hver for seg |
|---|---|
| Observasjon | Hva den lar stå uavklart |
| Ulike rapporterte soner | Reise, en beholdt innstilling, en bedriftsgateway, en proxy eller en databasefeil kan alle produsere det. |
| Den samme rapporterte sonen | En VPN-utgang kan ligge i brukerens sone, så samsvar etablerer ikke en direkte forbindelse. |
Én verdi mangler eller er ugyldig
Sammenligningen er utilgjengelig, noe som verken er samsvar eller avvik.
Asymmetrien betyr mer enn tabellen antyder. Et avvik har mange uskyldige forklaringer, mens et samsvar har minst én skyldig, så ingen av retningene støtter en kategorisk regel. Leverandørens egne nøyaktighetsnotater beskriver begrenset presisjon og manglende data, og de påpeker at en anonymiseringstjeneste kan avsløre serverplasseringen sin i stedet for brukerens.
Det er derfor signalet hører hjemme i en risikoscore med en registrert grunn og en eksplisitt ukjent tilstand, ikke i en boolsk verdi som styrer tilgang.
UTC-forskyvninger er ingen snarvei
Å sammenligne forskyvninger i stedet for soneidentifikatorer reparerer ikke slutningen. To ulike soner kan dele en forskyvning deler av året, og samme sone kan endre forskyvning ved en sommertidsgrense. Hvis en funksjon faktisk trenger en forskyvning for planlegging, beregn den for det konkrete øyeblikket i stedet for å lagre ett tall og gjenbruke det som identitetsbevis.
Strengsammenligning har sin egen felle: to stavemåter av samme sone, eller et eldre alias, vil avvike som tekst mens de beskriver samme innstilling. Valider identifikatorene og sammenlign gjennom plattformens tidssonehåndtering i stedet for å matche rå strenger.
Blokkere eller score: velg responsen bevisst