کاهش User-Agent چیست؟

کاهش User-Agent (UA) اطلاعات شناسایی به اشتراک گذاشته شده در رشته User-Agent را که ممکن است برای اثر انگشت غیرفعال استفاده شود، به حداقل می‌رساند. اکنون که این تغییرات برای دسترسی عمومی اعمال شده‌اند، تمام درخواست‌های منابع دارای هدر User-Agent کاهش یافته هستند. در نتیجه، مقادیر بازگشتی از رابط‌های خاص Navigator ، از جمله: navigator.userAgent ، navigator.appVersion و navigator.platform ، کاهش می‌یابند.

توسعه‌دهندگان وب باید کد سایت خود را برای استفاده از رشته User-Agent بررسی کنند. اگر سایت شما برای خواندن مدل دستگاه، نسخه پلتفرم یا نسخه کامل مرورگر به تجزیه رشته User-Agent متکی است، باید API مربوط به User-Agent Client Hints را پیاده‌سازی کنید .

نکات مربوط به کلاینت عامل کاربر (UA-CH)

نکات مربوط به کلاینت User-Agent امکان دسترسی به مجموعه کامل داده‌های User-Agent را فراهم می‌کند، اما تنها زمانی که سرورها به طور فعال نیاز صریح به بخش‌های خاصی از داده‌ها را اعلام کنند.

با حذف داده‌های کاربر که به صورت غیرفعال در معرض دید قرار می‌گیرند، می‌توانیم میزان اطلاعاتی را که عمداً توسط هدرهای درخواست، APIهای جاوا اسکریپت و سایر مکانیسم‌ها در معرض دید قرار می‌گیرند، بهتر اندازه‌گیری و کاهش دهیم.

چرا به کاهش UA و UA-CH نیاز داریم؟

از نظر تاریخی، رشته‌ی User-Agent با هر درخواست HTTP، رشته‌ی بزرگی از داده‌ها در مورد مرورگر کاربر، سیستم عامل و نسخه را منتشر می‌کرد. این امر به دو دلیل مشکل‌ساز بود:

• جزئیات دقیق و فراوان می‌تواند منجر به شناسایی کاربر شود.
• دسترسی پیش‌فرض به این اطلاعات می‌تواند منجر به ردیابی مخفیانه شود.

کاهش UA و UA-CH با به اشتراک گذاشتن تنها اطلاعات اولیه به صورت پیش‌فرض، حریم خصوصی کاربر را بهبود می‌بخشد.

User-Agent کاهش‌یافته شامل برند مرورگر و نسخه قابل توجهی از آن، جایی که درخواست از آنجا آمده (دسکتاپ یا موبایل) و پلتفرم است. برای دسترسی به داده‌های بیشتر، User-Agent Client Hints به شما امکان می‌دهد اطلاعات خاصی در مورد دستگاه یا شرایط کاربر درخواست کنید.

علاوه بر این، با گذشت زمان، رشته User-Agent طولانی‌تر و پیچیده‌تر شد، که منجر به تجزیه رشته مستعد خطا شد. UA-CH داده‌های ساختاریافته و قابل اعتمادی را ارائه می‌دهد که تفسیر آنها آسان‌تر است. کد موجودی که رشته UA را تجزیه می‌کند نباید خراب شود (اگرچه داده‌های کمتری را برمی‌گرداند) و اگر سایت شما به اطلاعات خاص مشتری نیاز دارد ، باید به UA-CH مهاجرت کنید.

UA و UA-CH کاهش‌یافته چگونه کار می‌کنند؟

در اینجا مثالی مختصر از نحوه‌ی عملکرد رشته‌ی کاهش‌یافته‌ی User-Agent و UA-CH آورده شده است. برای مثالی عمیق‌تر، بهبود حریم خصوصی کاربر و تجربه‌ی توسعه‌دهنده با User-Agent Client Hints را مرور کنید.

کاربر مرورگر را باز می‌کند و example.com در نوار آدرس وارد می‌کند:

1. مرورگر درخواستی برای بارگذاری صفحه وب ارسال می‌کند.

   1. مرورگر شامل هدر User-Agent با رشته User-Agent خلاصه شده است. برای مثال: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

   2. مرورگر همین اطلاعات را در هدرهای پیش‌فرض User-Agent Client Hint قرار می‌دهد. برای مثال:

      Sec-CH-UA: "Chrome"; v="98"
      Sec-CH-UA-Mobile: ?1
      Sec-CH-UA-Platform: "Android"
      

2. سرور می‌تواند از مرورگر بخواهد که نکات اضافی مربوط به کلاینت، مانند مدل دستگاه، را با هدر پاسخ Accept-CH ارسال کند. برای مثال: Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

3. مرورگر، سیاست‌ها و پیکربندی‌های کاربر را اعمال می‌کند تا مشخص کند چه داده‌هایی مجاز به بازگشت به سرور در هدرهای درخواست بعدی هستند. برای مثال:

   Sec-CH-UA: "Chrome"; v="93"
   Sec-CH-UA-Mobile: ?1
   Sec-CH-UA-Platform: "Android"
   Sec-CH-UA-Model: "Pixel 2"
   

نکات مهم مشتری

اگر در درخواست اولیه خود به مجموعه‌ای خاص از Client Hints نیاز دارید، می‌توانید از هدر پاسخ Critical-CH استفاده کنید. مقادیر Critical-CH باید زیرمجموعه‌ای از مقادیر درخواستی Accept-CH باشند.

برای مثال، درخواست اولیه ممکن است شامل درخواستی برای Device-Memory و Viewport-Width باشد، که در آن Device-Memory حیاتی تلقی می‌شود.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

اگر مرورگر برای رندر صحیح صفحه وب به یک راهنمای حیاتی ( Critical-CH ) نیاز داشته باشد، سرور می‌تواند این اطلاعات اضافی را با هدر Accept-CH درخواست کند. سپس، مرورگر می‌تواند درخواست جدیدی برای صفحه، شامل راهنمای حیاتی، ارسال کند.

به طور خلاصه، Accept-CH تمام مقادیری را که برای صفحه می‌خواهید درخواست می‌کند، در حالی که Critical-CH فقط زیرمجموعه‌ای از مقادیری را که باید برای بارگذاری صحیح صفحه داشته باشید، درخواست می‌کند. برای اطلاعات بیشتر به مشخصات قابلیت اطمینان Client Hints مراجعه کنید.

تشخیص دستگاه‌های تبلت با API UA-CH

از آنجایی که مرز بین دستگاه‌های موبایل، تبلت و دسکتاپ همچنان کمتر مشخص می‌شود و فرم‌فکتورهای پویا رایج‌تر می‌شوند (صفحه‌های نمایش تاشو، تغییر حالت بین لپ‌تاپ و تبلت)، توصیه می‌شود از طراحی واکنش‌گرا و تشخیص ویژگی برای ارائه یک رابط کاربری مناسب استفاده کنید.

با این حال، اطلاعات ارائه شده توسط مرورگر برای هر دو رشته User-Agent و User-Agent Client Hints از یک منبع می‌آید، بنابراین منطق یکسانی باید کار کند.

برای مثال، اگر این الگو روی رشته UA بررسی شود:

• الگوی تلفن: 'Android' + 'Chrome/[.0-9]* Mobile'
• الگوی تبلت: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

رابط هدرهای پیش‌فرض UA-CH مطابق را می‌توان بررسی کرد:

• الگوی تلفن: Sec-CH-UA-Platform: "Android" ، Sec-CH-UA-Mobile: ?1
• الگوی تبلت: Sec-CH-UA-Platform: "Android" ، Sec-CH-UA-Mobile: ?0

یا رابط معادل جاوا اسکریپت:

• الگوی تلفن: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
• الگوی تبلت: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

برای موارد استفاده خاص سخت‌افزار، نام مدل دستگاه را می‌توان از طریق اشاره‌گر Sec-CH-UA-Model با آنتروپی بالا درخواست کرد.

چگونه می‌توانم از UA کاهش‌یافته استفاده و آن را آزمایش کنم؟

برای شروع، کد سایت خود را برای موارد و کاربردهای رشته User-Agent بررسی کنید . اگر سایت شما برای خواندن مدل دستگاه، نسخه پلتفرم یا نسخه کامل مرورگر به تجزیه رشته User-Agent متکی است، باید API UA-CH را پیاده‌سازی کنید .

پس از به‌روزرسانی به API UA-CH، باید آزمایش کنید تا مطمئن شوید داده‌هایی را که از User-Agent انتظار دارید دریافت می‌کنید. سه روش برای آزمایش وجود دارد که هر کدام پیچیدگی بیشتری دارند.

دسترسی‌پذیری مقیاس‌پذیر برای کاهش User-Agent به معنای کاهش کامل رشته UA در تمام دستگاه‌های Chrome است. این کاهش با انتشار جزئی Chrome در سه‌ماهه دوم سال 2022 آغاز شد.

تست رشته‌های سفارشی به صورت محلی

اگر می‌خواهید سایت خود را با استفاده از رشته‌های سفارشی User-Agent برای شبیه‌سازی دستگاه‌های مختلف آزمایش کنید، کروم را با پرچم خط فرمان --user-agent="Custom string here" اجرا کنید. اطلاعات بیشتر در مورد پرچم‌های خط فرمان را اینجا بیابید.

روش دیگر، استفاده از شبیه‌ساز دستگاه در Chrome DevTools است.

رشته را در کد سایت خود تغییر دهید

اگر رشته‌ی موجودِ user-agent کروم را در کد سمت کلاینت یا سمت سرور خود پردازش می‌کنید، می‌توانید آن رشته را برای آزمایش سازگاری به قالب جدید تبدیل کنید. می‌توانید با بازنویسی و جایگزینی رشته، یا تولید نسخه‌ی جدید و آزمایش در کنار آن، آن را آزمایش کنید.

پشتیبانی از نکات مشتری و نکات مهم

سه Client Hint پیش‌فرض به سرور برگردانده می‌شود، از جمله نام مرورگر و نسخه اصلی، یک مقدار بولی که نشان می‌دهد آیا مرورگر روی دستگاه تلفن همراه است یا خیر، و نام سیستم عامل. این موارد پس از handshake پروتکل امنیت لایه انتقال (TLS) ارسال می‌شوند. این موارد از قبل در مرورگر شما موجود و پشتیبانی می‌شوند.

با این حال، ممکن است مواقعی وجود داشته باشد که شما نیاز به بازیابی اطلاعات حیاتی برای رندر شدن سایت خود داشته باشید.

نکات مهم را بهینه کنید

یک TLS handshake اولین قدم برای ایجاد یک اتصال امن بین مرورگر و وب سرور است. بدون هیچ گونه مداخله‌ای، هدر پاسخ Critical-CH به گونه‌ای طراحی شده است که به مرورگر بگوید در صورت ارسال درخواست اول بدون هیچ گونه اشاره‌ی بحرانی، فوراً درخواست را دوباره امتحان کند.

برای بهینه‌سازی نکات حیاتی ( سرآیند Critical-CH )، باید این handshake را رهگیری کرده و مدلی برای نکات کلاینت ارائه دهید. این مراحل ممکن است پیچیده باشند و نیاز به دانش پیشرفته داشته باشند.

فریم‌های ACCEPT_CH HTTP/2 و HTTP/3 ، همراه با افزونه TLS ALPS ، یک بهینه‌سازی در سطح اتصال است تا تنظیمات Client Hint سرور را به موقع برای اولین درخواست HTTP ارائه دهد. این موارد نیاز به پیکربندی پیچیده‌ای دارند و ما توصیه می‌کنیم فقط از این مورد برای اطلاعات واقعاً حیاتی استفاده کنید.

BoringSSL (شاخه‌ای از OpenSSL) به شما کمک می‌کند تا با ویژگی‌های آزمایشی گوگل در Chromium کار کنید. در حال حاضر، ALPS فقط در BoringSSL پیاده‌سازی شده است.

اگر نیاز به استفاده از نکات مهم دارید، به راهنمای ما در مورد قابلیت اطمینان و بهینه‌سازی نکات مهم مراجعه کنید.

سوالات متداول

چه مدت طول می‌کشد تا نکات مشخص شده از طریق سربرگ Accept-CH ارسال شوند؟

نکات مشخص شده از طریق هدر Accept-CH برای مدت زمان جلسه مرورگر یا تا زمانی که مجموعه متفاوتی از نکات مشخص شود، ارسال می‌شوند.

آیا UA-CH با HTTP/2 و HTTP/3 کار می‌کند؟

UA-CH با هر دو اتصال HTTP/2 و HTTP/3 کار می‌کند.

آیا زیردامنه‌ها (و CNAMEها) برای دسترسی به UA-CH با آنتروپی بالا به یک Permissions-Policy صفحه سطح بالا نیاز دارند؟

هدرهای درخواست UA-CH با آنتروپی بالا، صرف نظر از نحوه تعریف آن مبدا در سمت DNS، به درخواست‌های بین مبدایی محدود می‌شوند. واگذاری اختیار باید از طریق Permissions-Policy برای هر زیرمنبع بین مبدایی مدیریت شود یا از طریق جاوا اسکریپتی که در زمینه بین مبدایی اجرا می‌شود، به دست آید.

کاهش User-Agent چگونه بر تشخیص ربات تأثیر می‌گذارد؟

تغییر کروم در رشته‌ی User-Agent خود، مستقیماً بر رشته‌ی User-Agent که یک ربات برای ارسال انتخاب می‌کند، تأثیر نمی‌گذارد.

ربات‌ها ممکن است رشته‌های خود را به‌روزرسانی کنند تا اطلاعات کاهش‌یافته‌ای را که کروم ارسال می‌کند، منعکس کنند، اما این کاملاً انتخاب پیاده‌سازی آنهاست. کروم هنوز همان قالب User-Agent را ارسال می‌کند و ربات‌هایی که شناسه خود را به انتهای رشته User-Agent کروم اضافه می‌کنند، می‌توانند به این کار ادامه دهند.

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

مشارکت کنید و بازخورد خود را به اشتراک بگذارید

• آزمایش Origin : نظرات خود را در مورد آزمایش‌های Origin قبلی به اشتراک بگذارید .
• نسخه آزمایشی : نسخه آزمایشی ما از کاهش کاربر-عامل را امتحان کنید.
• گیت‌هاب : توضیحات UA-CH را بخوانید، سوال بپرسید و بحث را دنبال کنید .

اطلاعات بیشتر

• بهبود حریم خصوصی کاربر و تجربه توسعه‌دهنده : مروری بر توسعه‌دهندگان وب
• مهاجرت از رشته UA به UA-CH : آموزشی برای توسعه‌دهندگان وب
• کاوش در سندباکس حریم خصوصی