Časové pásmo prohlížeče versus IP poloha: srovnání rizikového signálu

Prohlížeč hlásí Europe/London, zatímco IP databáze umisťuje požadavek do America/New_York. To je nesoulad mezi dvěma pozorováními a stojí za zaznamenání. Není to důkaz, že návštěvník používá VPN, a právě zacházení s ním jako s důkazem je místo, kde většina implementací chybuje. Níže uvedené srovnání drží obě hodnoty a jejich způsoby selhání odděleně.

Dvě pozorování s různými vlastníky

Hodnota z prohlížeče je nastavení: pásmo, které zvolil operační systém nebo uživatel pro formátování dat. Hodnota z databáze je odhad připojený k IP síti, který vytváří poskytovatel mapující bloky adres na místa. Ani jedna není ověřené tvrzení o tom, kde návštěvník stojí, a ani jedna neví, kterou síťovou cestou požadavek šel.

Protože se vlastníci liší, mohou se obě hodnoty rozejít z důvodů, které s nástroji pro soukromí nemají nic společného. Cestovatel, který si ponechá domácí pásmo, firemní notebook ukotvený na čas ústředí, satelitní spoj s regionálním výstupem nebo zastaralý řádek v databázi – to vše vytváří nesoulad.

Jak se každá hodnota skutečně vytváří

Prohlížeč může své vyřešené pásmo přečíst pomocí new Intl.DateTimeFormat().resolvedOptions().timeZone, což vrátí identifikátor IANA odvozený z nastavení formátovače. Nežádá o oprávnění k poloze a neobrací se na GPS. Na serveru určete adresu klienta ze své důvěryhodné konfigurace proxy a poté ji vyhledejte u schváleného poskytovatele. Hlavička předávání dodaná návštěvníkem není automaticky touto adresou.

Ukládejte obě pozorování do samostatných polí spolu s časem pozorování a výsledkem vyhledávání. Pojmenování odvozeného pole vpnDetected, když je výpočet jen srovnáním pásem, zapeče závěr do měření a ztěžuje pozdější revizi.

Co dokazuje shoda a co nesoulad

Asymetrie je důležitější, než tabulka naznačuje. Nesoulad má mnoho nevinných vysvětlení, zato shoda má alespoň jedno vinné, takže ani jeden směr nepodporuje kategorické pravidlo. Vlastní poznámky poskytovatele k přesnosti popisují omezenou přesnost a chybějící data a upozorňují, že anonymizační služba může odhalit polohu svého serveru místo uživatele.

Proto signál patří do rizikového skóre se zaznamenaným důvodem a výslovným neznámým stavem, ne do booleovské hodnoty, která řídí přístup.

Posuny UTC nejsou zkratka

Srovnávání posunů místo identifikátorů pásem inferenci neopraví. Dvě různá pásma mohou část roku sdílet posun a totéž pásmo může na hranici letního času posun změnit. Pokud funkce opravdu potřebuje posun pro plánování, spočítejte ho pro konkrétní okamžik, místo abyste uložili jedno číslo a znovu ho používali jako důkaz totožnosti.

Srovnávání řetězců má svou past: dva zápisy téhož pásma nebo starý alias se budou jako text lišit, i když popisují stejné nastavení. Ověřujte identifikátory a porovnávejte přes zpracování časových pásem platformy, místo abyste porovnávali surové řetězce.

Blokovat, nebo skórovat: zvolte reakci vědomě

Pro zobrazení času se návštěvníka zeptejte, které pásmo preferuje, a tím to skončete. Pro rizikový systém aplikace berte nesoulad jako jeden slabý kontextový signál vedle důkazů, které odpovídají skutečnému modelu hrozby, a nechte neúspěšné vyhledávání vytvořit neznámou hodnotu místo tichého zjištění. Blokování jen na základě srovnání mění mezeru v měření v obvinění vůči uživateli.

Pokud rozhodnutí s následky potřebuje silnější záruku, použijte krok ověření nebo autentizace, který je k tomu určený. Heuristika časového pásma takovou záruku poskytnout nemůže a detektor, který počítá chybějící důkazy jako úspěch, může vypadat účinně, zatímco odpovídá na jinou otázku, než jste položili.