منطقهٔ زمانی، زبان و IP: سایت چطور می‌فهمد وانمود می‌کنید

کسی روی گرهٔ خروجی ژاپن، با منطقهٔ زمانی سیستم روی شانگهای و مرورگر به زبان چینی ساده‌شده. وب‌سایت به تحلیل هوشمندانه‌ای نیاز ندارد؛ این سه واقعیت را کنار هم بگذارید، داستان خودش را تعریف می‌کند. این لزوماً باعث مسدود شدن شما نمی‌شود، اما وارد یک امتیاز می‌شود. این مقاله می‌گوید دقیقاً چه چیزهایی مقایسه می‌شود و با کدام ناسازگاری‌ها می‌توان کنار آمد.

استنباط منطقهٔ زمانی از IP

سرور به محض داشتن IP شما آن را در یک پایگاه دادهٔ GeoIP (MaxMind، IPinfo و مانند آن‌ها) جستجو می‌کند و کشور، استان، شهر و به‌عنوان جایزه، نام منطقهٔ زمانی مثل Asia/Tokyo را می‌گیرد. در سطح کشور این نسبتاً قابل اتکاست؛ در سطح شهر بسیار کمتر، چون پایگاه‌های داده معمولاً کل بلوک‌های نشانی مراکز داده را با محل ثبت‌شدهٔ اپراتور برچسب می‌زنند.

سرور با داشتن منطقهٔ زمانی IP می‌تواند محاسبه کند «همین حالا آنجا باید ساعت چند باشد». این گام بعداً مهم می‌شود.

منطقهٔ زمانی‌ای که مرورگر گزارش می‌دهد

JavaScript صفحه دو منبع دارد:

• Intl.DateTimeFormat().resolvedOptions().timeZone نام منطقهٔ IANA را برمی‌گرداند، مثلاً Asia/Shanghai.
• new Date().getTimezoneOffset() اختلاف زمان محلی با UTC را به دقیقه برمی‌گرداند؛ زمان پکن -480 می‌دهد.

در یک مرورگر عادی این دو، دو بیان از یک تنظیم سیستمی‌اند و همیشه با هم سازگارند. رابطهٔ آن‌ها با منطقهٔ زمانی IP موضوع دیگری است: IP در توکیو (UTC+9)، JavaScript می‌گوید شانگهای (UTC+8)، یک ساعت اختلاف.

ساعت تابستانی دام ساده‌ای است. America/Los_Angeles در زمستان اختلاف 480 و در تابستان 420 دارد. سایت‌ها با تاریخ امروز مقایسه می‌کنند، پس ابزاری که منطقه را بدون در نظر گرفتن DST عوض می‌کند، در ماه‌های خاصی لو می‌رود.

خودِ ساعت

فراتر از منطقه، می‌توان زمان را مقایسه کرد. سرور لحظهٔ فعلی در منطقهٔ زمانی IP را می‌داند؛ صفحه new Date() را برمی‌گرداند؛ تفریق کنید. چند ثانیه اختلاف یعنی ساعت سیستم همگام است. ده دقیقه و بیشتر یعنی یا ساعت هرگز همگام نمی‌شود (در ماشین‌های مجازی قدیمی رایج است) یا منطقه و ساعت جداگانه تغییر داده شده‌اند. امتیاز اصالت ما برای اختلاف بیش از سه دقیقه کسر کوچکی در نظر می‌گیرد. کوچک، چون ساعت افراد عادی هم جابه‌جا می‌شود.

زبان: سه جا، سه پاسخ

زبان از سه جا نشت می‌کند، و این سه در یک لایه نیستند:

1. هدر درخواست Accept-Language. با هر درخواست ارسال می‌شود، مستقیماً برای سرور قابل مشاهده است، و شکلی مثل zh-CN,zh;q=0.9,en;q=0.8 دارد.
2. navigator.language و navigator.languages. چیزی که اسکریپت صفحه می‌خواند؛ معمولاً همان تنظیم هدر.
3. locale پیش‌فرض Intl، مثلاً new Intl.NumberFormat().resolvedOptions().locale. بازتاب منطقهٔ سیستم یا مرورگر است و هنگام قالب‌بندی اعداد و تاریخ‌ها استفاده می‌شود.

در یک مرورگر واقعی این سه بسیار سازگارند: نه بایت‌به‌بایت یکسان، اما از یک منشأ. زبان اصلی Accept-Language که با navigator.language فرق داشته باشد یکی از کسرهای سنگین‌تر در این سایت است، چون تقریباً فقط وقتی اتفاق می‌افتد که کسی یکی از آن‌ها را دستی ویرایش کرده باشد.

دو مثال

IP در ژاپن، منطقهٔ زمانی Asia/Shanghai، زبان zh-CN. نمونهٔ کلاسیک «کاربر چینی از طریق گرهٔ ژاپنی». دو سیگنال از سه سیگنال می‌گویند چین، یکی می‌گوید ژاپن. بیشتر سایت‌ها برای این جلوی شما را نمی‌گیرند: این ترکیب بیش از حد رایج است، و صادقانه است. شما چیزی جعل نکرده‌اید؛ ترافیکتان فقط مسیر دورتری رفته است. ثبت می‌شود، شاید پیشنهادها یا امتیاز ریسک را کمی جابه‌جا کند، و همین.

IP در آمریکا، منطقهٔ زمانی America/Los_Angeles، زبان zh-CN، فهرست فونت‌ها پر از فونت‌های چینی. برای یک چینی‌زبان ساکن لس‌آنجلس این کاملاً عادی است. اما برای یک مدل ریسک هم‌پوشانی زیادی با «کاربر داخلی که منطقهٔ زمانی‌اش را عوض کرده» دارد، پس ممکن است بیشتر از حالت اول تأیید اضافی بخواهد. طنز ماجرا: هرچه بیشتر تلاش کنید منطقهٔ زمانی با IP بخواند، بیشتر شبیه لباس مبدل می‌شود، مگر اینکه زبان، فونت‌ها و چیدمان صفحه‌کلید هم با آن حرکت کنند.

اشتباهاتی که مرورگرهای ضدشناسایی مدام تکرار می‌کنند

«مرورگرهای اثر انگشت» یا مرورگرهای ضدشناسایی این وعده را می‌فروشند که هر پروفایل شبیه یک آدم واقعی متفاوت به نظر برسد. آن‌ها در جاهای قابل پیش‌بینی می‌لغزند:

• منطقهٔ زمانی JavaScript عوض می‌شود اما Accept-Language نه، یا برعکس.
• timeZone در Intl بازنویسی می‌شود اما getTimezoneOffset() همچنان مقدار قدیمی را برمی‌گرداند، پس دو API با هم در تناقض‌اند.
• منطقه عوض می‌شود اما زمان سیستم نه، پس اختلاف ساعت محاسبه‌شده نسبت به منطقهٔ IP دقیقاً مضربی از یک ساعت کامل است.
• فهرست زبان غیرطبیعی است: en-US, zh-CN بدون zh ساده، یا یک مورد در Accept-Language و پنج مورد در navigator.languages.
• فقط مقادیر قابل مشاهده در مرورگر تغییر می‌کند؛ لایهٔ HTTP، از جمله Client Hints، دست‌نخورده می‌ماند.

وجه مشترک این‌ها تغییر ناقص است. سیستم‌های ریسک به آن به‌شدت حساس‌اند، چون در میان کاربران واقعی تقریباً هرگز رخ نمی‌دهد.

توصیه برای کاربران ابزارهای عبور از فیلترینگ

دنبال لباس مبدل کامل نباشید؛ آن مشکل صنعت دیگری است. چیزی که باید بدانید ساده‌تر است: منطقهٔ زمانی‌ای که با IP نمی‌خواند پیامد طبیعی استفاده از پروکسی است، سایت‌ها آن را مدام می‌بینند، و امتیاز اصالت ما فقط کسر سبکی برایش در نظر می‌گیرد. چیزی که سخت جریمه می‌شود جعل آشکار است: user agent که با موتور نمی‌خواند، navigator.webdriver روی true، دو رسم canvas که با هم فرق دارند. مرورگر را به حال خودش بگذارید و انرژی را به‌جای ور رفتن با منطقهٔ زمانی، صرف انتخاب یک ابزار خوب کنید.

برای دیدن سه مقدار منطقهٔ زمانی و سه مقدار زبان خودتان، بررسی منطقهٔ زمانی را اجرا کنید.

پرسش‌های متداول

اگر منطقهٔ زمانی سیستم را با گرهٔ خروجی هماهنگ کنم امن‌تر می‌شوم؟ معمولاً نه. مگر اینکه زبان، ساعت سیستم، فونت‌ها و Client Hints هم با هم حرکت کنند، فقط یک ناسازگاری را با ناسازگاری دیگری عوض کرده‌اید، و ناسازگاری جدید بیشتر شبیه لباس مبدل است.

منطقهٔ زمانی IP می‌گوید گوانگژو اما من در شنژن هستم. مهم است؟ نه. دقت شهری GeoIP در هر حال محدود است، و سایت‌ها منطقهٔ زمانی را مقایسه می‌کنند، نه شهر را. هر دو Asia/Shanghai هستند.

انگلیسی کردن زبان مرورگر اثری دارد؟ تا وقتی هدر و JavaScript با هم سازگار باشند، کسری در کار نیست. بسیاری از توسعه‌دهندگان در چین محیط کاملاً انگلیسی دارند. تنها اثرش این است که سایت به‌طور پیش‌فرض کدام زبان را به شما نشان می‌دهد.