Strefa czasowa przeglądarki a lokalizacja IP: porównanie sygnału ryzyka
Strefa przeglądarki i strefa wywnioskowana z IP mierzą różne rzeczy. Porównaj, co każda z nich może udowodnić, zanim niezgodność stanie się wyrokiem VPN w twoim modelu ryzyka.
Przeglądarka zgłasza Europe/London, podczas gdy baza IP umieszcza żądanie w America/New_York. To niezgodność dwóch obserwacji i warto ją zapisać. Nie jest to dowód, że odwiedzający używa VPN, a traktowanie tego jako dowodu jest miejscem, w którym większość implementacji się myli. Poniższe porównanie utrzymuje obie wartości i ich tryby awarii osobno.
Dwie obserwacje o różnych właścicielach
Wartość przeglądarki to ustawienie: strefa wybrana przez system operacyjny lub użytkownika do formatowania dat. Wartość bazy to szacunek przypisany do sieci IP, wytwarzany przez dostawcę, który mapuje bloki adresów na miejsca. Żadna z nich nie jest uwierzytelnionym stwierdzeniem o tym, gdzie stoi odwiedzający, i żadna nie wie, jaką ścieżką sieciową poszło żądanie.
Ponieważ właściciele się różnią, obie wartości mogą się rozjechać z powodów, które nie mają nic wspólnego z narzędziami prywatności. Podróżny zachowujący strefę domową, firmowy laptop przypięty do czasu centrali, łącze satelitarne z regionalnym wyjściem albo nieaktualny wiersz bazy – wszystko to daje niezgodność.
Jak każda wartość faktycznie powstaje
Przeglądarka może odczytać swoją rozstrzygniętą strefę za pomocą new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone
, co zwraca identyfikator IANA wyprowadzony z ustawień formatera. Nie prosi o zgodę na lokalizację i nie korzysta z GPS. Na serwerze ustal adres klienta na podstawie zaufanej konfiguracji proxy, a następnie sprawdź go u zatwierdzonego dostawcy. Nagłówek przekazywania podany przez odwiedzającego nie jest automatycznie tym adresem.vpnDetectedPrzechowuj obie obserwacje jako osobne pola wraz z czasem obserwacji i wynikiem wyszukiwania. Nazwanie pola pochodnego
vpnDetected
| , gdy obliczenie jest tylko porównaniem stref, wpisuje wniosek w pomiar i utrudnia późniejszy przegląd. | Co dowodzi zgodność, a co niezgodność |
|---|---|
| Obserwacja | Co pozostawia nierozstrzygnięte |
| Różne zgłoszone strefy | Podróż, zachowane ustawienie, brama firmowa, proxy lub błąd bazy mogą to wszystkie wytworzyć. |
| Ta sama zgłoszona strefa | Wyjście VPN może znajdować się w strefie użytkownika, więc zgodność nie dowodzi bezpośredniego połączenia. |
Brak jednej wartości lub jest nieprawidłowa
Porównanie jest niedostępne, co nie jest ani zgodnością, ani niezgodnością.
Asymetria jest ważniejsza, niż sugeruje tabela. Niezgodność ma wiele niewinnych wyjaśnień, a zgodność ma co najmniej jedno winne, więc żaden kierunek nie uzasadnia kategorycznej reguły. Własne noty o dokładności dostawcy opisują ograniczoną precyzję i brakujące dane oraz wskazują, że usługa anonimizująca może ujawnić lokalizację swojego serwera, a nie użytkownika.
Dlatego sygnał należy do oceny ryzyka z zapisanym powodem i jawnym stanem nieznanym, a nie do wartości logicznej sterującej dostępem.
Przesunięcia UTC nie są skrótem
Porównywanie przesunięć zamiast identyfikatorów stref nie naprawia wnioskowania. Dwie różne strefy mogą dzielić przesunięcie przez część roku, a ta sama strefa może zmienić przesunięcie na granicy czasu letniego. Jeśli funkcja naprawdę potrzebuje przesunięcia do planowania, oblicz je dla konkretnej chwili, zamiast przechowywać jedną liczbę i używać jej ponownie jako dowodu tożsamości.
Porównywanie ciągów ma własną pułapkę: dwa zapisy tej samej strefy albo dawny alias różnią się jako tekst, choć opisują to samo ustawienie. Sprawdzaj identyfikatory i porównuj przez obsługę stref czasowych platformy, zamiast dopasowywać surowe ciągi.
Blokować czy punktować: wybierz reakcję świadomie