انگشت نگاری

انگشت نگاری به معنای تلاش برای شناسایی کاربر هنگام بازگشت به وب سایت شما یا شناسایی همان کاربر در وب سایت های مختلف است. بسیاری از ویژگی ها ممکن است بین راه اندازی شما و شخص دیگری متفاوت باشد. به عنوان مثال، ممکن است از نوع دیگری از دستگاه و مرورگر دیگری استفاده کنید، اندازه صفحه نمایش متفاوتی داشته باشید و فونت های مختلفی نصب شده باشد. اگر من فونت "Dejavu Sans" را نصب کرده باشم و شما نصب نکنید، هر وب سایتی می تواند با بررسی آن فونت تفاوت بین من و شما را تشخیص دهد. انگشت نگاری به این صورت است. شما مجموعه ای از این نقاط داده را ایجاد می کنید و هر کدام راه های بیشتری برای تمایز بین کاربران ارائه می دهند.

یک تعریف رسمی‌تر ممکن است به این صورت باشد: اثرانگشت عمل استفاده از ویژگی‌های بادوام واضح و غیر آشکار تنظیمات کاربر برای تلاش برای متمایز کردن آن‌ها از هر چه بیشتر کاربران دیگر است.

چرا اثر انگشت مانع حفظ حریم خصوصی کاربران می شود؟

برخی از موارد حاشیه ای وجود دارد که در آن انگشت نگاری از یک کاربر مهم است: برای مثال، تشخیص تقلب. اما از انگشت نگاری می توان برای ردیابی کاربران در سراسر سایت ها نیز استفاده کرد و این ردیابی اغلب بدون رضایت کاربران انجام می شود، یا در برخی موارد بر اساس رضایت نامعتبر است که به طور کافی به کاربر اطلاع نمی دهد. وقتی این کار انجام می شود، آن کاربران اغلب این موضوع را تا حدودی آزاردهنده می یابند و احساس می کنند که به آنها خیانت شده است.

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

فروشندگان مرورگرها می دانند که کاربران دوست ندارند ردیابی شوند و به طور مداوم ویژگی هایی را برای محدود کردن اثر انگشت (که برخی از آنها را در ماژول قبلی دیدیم) پیاده سازی می کنند. در اینجا، ما به بررسی این موضوع می پردازیم که چگونه این ویژگی ها ممکن است بر نیازهای کسب و کار شما تأثیر بگذارد و چگونه همچنان کاری را که می خواهید انجام دهید به روشی برای حفظ حریم خصوصی انجام دهید. این بیشتر به این موضوع می‌پردازد که چگونه محافظت مرورگر در برابر اثرانگشت بر کارهایی که انجام می‌دهید و چگونه تأثیر می‌گذارد، نه اینکه چگونه مانع از انجام اثر انگشت شما می‌شود.

در عمل، اکثر توسعه دهندگان و اکثر کسب و کارها نیازی به اثر انگشت کاربران ندارند. اگر برنامه شما از کاربران می‌خواهد که وارد سیستم شوند، کاربران شما با رضایت آن‌ها و به گونه‌ای که می‌توانند در هر زمانی که بخواهند به‌طور یک‌جانبه از آن انصراف دهند، خود را به شما معرفی می‌کنند. این یک روش محافظت از حریم خصوصی برای درک اینکه کدام کاربران به سیستم وارد شده‌اند است. ممکن است برنامه شما اصلاً نیازی به ورود کاربران به سیستم نداشته باشد، که حتی از حریم خصوصی کاربران شما محافظت می‌کند (و سپس فقط داده‌های مورد نیاز خود را جمع‌آوری می‌کنید).

انجام دهید

اشخاص ثالث خود را برای اثر انگشت ارزیابی کنید. به عنوان بخشی از ماژول اشخاص ثالث ، ممکن است از قبل فهرستی از خدمات شخص ثالثی که شامل می‌شوید و درخواست‌های وب که آنها ارائه می‌کنند، داشته باشید. ممکن است بتوان این درخواست‌ها را بررسی کرد تا ببینیم کدام داده‌ها در صورت وجود به منبع اصلی بازگردانده می‌شوند. با این حال، این اغلب دشوار است. اثر انگشت طبیعتاً یک فرآیند مخفی است که شامل درخواست داده هایی است که مشمول تأیید کاربر نیستند.

همچنین ارزش آن را دارد که خط‌مشی‌های حفظ حریم خصوصی سرویس‌ها و وابستگی‌های شخص ثالث خود را بخوانید تا نشانه‌هایی از اثر انگشت در حال استفاده را جستجو کنید. گاهی اوقات به عنوان "تطابق احتمالی" یا به عنوان بخشی از مجموعه ای از تکنیک های تطبیق احتمالی، در مقابل "تطابق قطعی" نامیده می شود.

نحوه کار انگشت نگاری

غالباً ترکیب شخصی شما از همه این ویژگی ها منحصر به شما یا حداقل برای گروه کوچکی از افراد مشابه است. این می تواند برای ردیابی مخفیانه شما استفاده شود.

به غیر از: اثر انگشت غیرفعال و فعال

در اینجا یک تمایز مفید بین تکنیک های انگشت نگاری غیرفعال و فعال وجود دارد. تکنیک انگشت نگاری غیرفعال تکنیکی است که از اطلاعاتی استفاده می کند که به طور پیش فرض به وب سایت داده می شود. یک تکنیک انگشت نگاری فعال، تکنیکی است که به صراحت مرورگر را برای اطلاعات بیشتر مورد بازجویی قرار می دهد. دلیل اهمیت این تمایز این است که مرورگرها می توانند برای شناسایی و رهگیری یا کاهش تکنیک های فعال تلاش کنند. APIها را می‌توان محدود کرد یا در پشت گفتگوهایی قرار داد که از کاربر اجازه می‌خواهد (و بنابراین به کاربر هشدار می‌دهد که از آنها استفاده می‌شود یا به کاربر اجازه می‌دهد به طور پیش‌فرض آنها را رد کند). تکنیک غیرفعال تکنیکی است که از داده هایی استفاده می کند که قبلاً به وب سایت داده شده است، اغلب به این دلیل که از نظر تاریخی، در روزهای نوپای بزرگراه اطلاعاتی، این اطلاعات به همه سایت ها داده می شد. رشته user-agent نمونه ای از این مورد است و در ادامه با جزئیات بیشتری به این موضوع خواهیم پرداخت. برای ارائه اطلاعات بسیار زیادی در مورد مرورگر، نسخه و سیستم عامل کاربر مفید تلقی می شد تا وب سایت بتواند موارد مختلفی را بر اساس آن ارائه دهد. با این حال، این مقدار اطلاعات متمایز در دسترس را نیز افزایش می دهد، اطلاعاتی که به شناسایی یک کاربر از کاربر دیگر کمک می کند. و بنابراین چنین اطلاعاتی به طور فزاینده ای دیگر در دسترس نیستند، یا حداقل ثابت می شوند تا دیگر متمایز نباشند. اگر کاری که انجام می‌دهید متکی به این اطلاعات باشد - برای مثال، اگر بسته به عامل کاربر، شاخه‌های کد متفاوتی می‌گیرید، ممکن است این کد با مسدود شدن یا توقف فزاینده اطلاعات توسط مرورگرها شکسته شود. در اینجا تست بهترین دفاع است (بعد ببینید).

به علاوه: اندازه گیری قابلیت اثرانگشت

معیار فنی برای میزان اطلاعاتی که هر یک از این نقاط داده ارائه می دهد، آنتروپی نامیده می شود و در بیت اندازه گیری می شود. یک ویژگی که در آن مقادیر زیادی ممکن است (مانند لیست فونت‌های نصب شده) وجود داشته باشد، می‌تواند بیت‌های زیادی را به کل کمک کند، به موجب آن چیزی که قدرت تمایز زیادی ندارد (مانند سیستم عاملی که استفاده می‌کنید) ممکن است فقط تعداد کمی را اضافه کند. . HTTP Almanac توضیح می‌دهد که چگونه کتابخانه‌های اثرانگشت موجود، این فرآیند ترکیب پاسخ‌های بسیاری از APIهای مختلف را به یک «هش» خودکار می‌کنند، که ممکن است تنها گروه کوچکی از کاربران، شاید حتی یک نفر را شناسایی کند. Maud Nalpas این موضوع را با جزئیات در این ویدیوی یوتیوب پوشش می دهد، اما، به طور خلاصه، تصور کنید که لیستی از دوستان خود را با موسیقی مورد علاقه، غذای مورد علاقه و زبان هایی که صحبت می کنند، مشاهده می کنید اما نام آنها حذف شده است. بسیار محتمل است که لیست هر فرد به طور منحصر به فرد آنها را در بین دوستان شما شناسایی کند، یا حداقل لیست را به تعداد معدودی محدود کند. انگشت نگاری به این صورت است. لیست چیزهایی که دوست دارید تبدیل به "هش" می شود. با آن هش، شناسایی یک کاربر به عنوان یک فرد در دو سایت مختلف غیر مرتبط آسان تر می شود، که هدف ردیابی است: دور زدن تمایل کاربر برای حفظ حریم خصوصی.

مرورگرها در برابر اثر انگشت چه می کنند؟

نکته مهم این است که فروشندگان مرورگر از روش‌های مختلفی برای یک وب‌سایت (یا شخص ثالث موجود در یک وب‌سایت) برای محاسبه اثر انگشت متمایز برای یک کاربر، یا بیت‌های مختلف اطلاعات برای کمک به منحصربه‌فرد بودن آن اثر انگشت بسیار آگاه هستند. برخی از این راه‌ها صریح و عمدی هستند، مانند رشته کاربر-عامل مرورگر، که اغلب مرورگر، سیستم عامل و نسخه در حال استفاده را مشخص می‌کند (و بنابراین به تمایز شما از من کمک می‌کند، اگر من و شما از مرورگرهای مختلف استفاده می‌کنیم) . برخی از راه‌ها عمداً برای اثرانگشت بودن ایجاد نشده‌اند، اما به هر حال چنین هستند، مانند فهرست فونت‌ها، یا دستگاه‌های ویدیویی و صوتی موجود در مرورگر. (لازم نیست مرورگر از این دستگاه‌ها استفاده کند ، فقط فهرستی از آن‌ها را با نام دریافت کنید.) و برخی از آن‌ها به عنوان کمک‌کننده به اثرانگشت پس از انتشار، مانند رندر دقیق پیکسلی ضداساس فونت‌ها بر روی بوم ثابت شده‌اند. عنصر . موارد بسیار دیگری نیز وجود دارد، و هر روشی که مرورگر شما از طریق مرورگر من متفاوت است، آنتروپی را اضافه می کند و بنابراین به طور بالقوه راهی برای تشخیص تفاوت بین من و شما، و شناسایی یک فرد منحصر به فرد تا حد امکان در بین وب سایت ها کمک می کند. https://amiunique.org فهرستی طولانی (اما قطعا جامع نیست) از ویژگی‌های بالقوه اثرانگشت دارد، و این فهرست دائماً افزایش می‌یابد (چون علاقه پولی زیادی برای امکان اثر انگشت کاربران وجود دارد، حتی اگر کاربران این کار را انجام ندهند. آن را می‌خواهم یا شاید انتظارش را نداشته باش).

از API های قدرتمند خاصی پشتیبانی نمی کند

پاسخ فروشندگان مرورگر به همه این رویکردها برای محاسبه اثر انگشت کاربر، یافتن راه‌هایی برای کاهش میزان آنتروپی موجود از این APIها است. محدودترین گزینه این است که در وهله اول آنها را اجرا نکنید. این کار توسط برخی از مرورگرهای اصلی برای انواع APIهای سخت افزاری و دستگاه (مانند دسترسی NFC و بلوتوث از برنامه های وب سمت سرویس گیرنده) انجام شده است و نگرانی های مربوط به اثر انگشت و حفظ حریم خصوصی به عنوان دلایلی برای اجرا نشدن آنها ذکر شده است. بدیهی است که این می‌تواند بر برنامه‌ها و سرویس‌های شما تأثیر بگذارد: شما به هیچ وجه نمی‌توانید از API در مرورگری که آن را پیاده‌سازی نمی‌کند استفاده کنید، و این می‌تواند برخی از رویکردهای سخت‌افزاری را محدود کرده یا به‌طور کامل از بررسی آن‌ها منصرف کند.

دروازه مجوزهای کاربر

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

اضافه شدن غیرقابل پیش بینی بودن

رویکرد سومی که در برخی موارد اتخاذ می‌شود این است که فروشندگان مرورگرها پاسخ‌های APIها را «فاصله» می‌کنند تا آن‌ها را کمتر دانه‌بندی کنند و در نتیجه شناسایی کمتری داشته باشند. این به عنوان بخشی از مکانیسم پاسخ تصادفی در ماژول داده توصیف شد، به عنوان کاری که می‌توانید هنگام جمع‌آوری داده‌ها از کاربران انجام دهید تا از جمع‌آوری ناخواسته داده‌هایی که در حال شناسایی هستند، جلوگیری کنید. فروشندگان مرورگر می‌توانند این رویکرد را برای داده‌های API که در دسترس برنامه‌های وب و اشخاص ثالث قرار داده‌اند، اتخاذ کنند. یک مثال از این API های زمان بندی بسیار دقیقی است که برای اندازه گیری عملکرد صفحه از window.performance.now() استفاده می شود. مرورگر این مقادیر را با دقت میکروثانیه می‌داند، اما مقادیر برگشتی عمداً با گرد کردن به نزدیک‌ترین مرز 20 میکروثانیه برای جلوگیری از استفاده از آنها در اثر انگشت (و همچنین برای امنیت برای جلوگیری از حملات زمان‌بندی، به طور عمدی از دقت کاهش می‌یابند). هدف در اینجا این است که اطمینان حاصل شود که APIها مفید باقی می مانند، اما پاسخ ها کمتر قابل شناسایی هستند: در اصل، ایجاد "مصونیت گله" با ساختن دستگاه شما بیشتر شبیه دستگاه دیگران به جای اینکه برای شما خاص باشد. Safari یک نسخه ساده از پیکربندی سیستم را به همین دلیل ارائه می دهد .

اجرای بودجه حفظ حریم خصوصی

بودجه حریم خصوصی پیشنهادی است که به مرورگرها پیشنهاد می کند اطلاعات آشکار شده توسط هر سطح اثر انگشت را تخمین بزنند. هنوز در مرورگرها اجرا نشده است. هدف، اجازه دادن به APIهای قدرتمند با حفظ حریم خصوصی کاربر است. درباره پیشنهاد بودجه حفظ حریم خصوصی بیشتر بیاموزید .

از یک محیط آزمایشی گسترده استفاده کنید

همه این‌ها بر نحوه ساخت اپلیکیشن‌ها و سرویس‌ها تأثیر می‌گذارند. به ویژه، تنوع گسترده ای از پاسخ ها و رویکردها در مرورگرها و پلتفرم ها در این زمینه وجود دارد. این بدان معنی است که آزمایش کار شما در چندین محیط مختلف بسیار مهم است. این البته همیشه مهم است، اما می‌توان فرض کرد که رندر HTML یا CSS برای یک موتور رندر مشخص ثابت است، صرف نظر از اینکه آن موتور در کدام مرورگر یا پلتفرم قرار دارد (و بنابراین آزمایش در آن می‌تواند وسوسه انگیز باشد. برای مثال فقط یک مرورگر مبتنی بر Blink). این دقیقاً برای استفاده از API صادق نیست، زیرا مرورگرهایی که یک موتور رندر مشترک دارند ممکن است در نحوه سخت کردن سطح API خود در برابر اثر انگشت تفاوت چشمگیری داشته باشند.

انجام دهید

• تجزیه و تحلیل و مخاطبان خود را بررسی کنید تا مجموعه مرورگرهایی را که هنگام آزمایش باید در اولویت قرار دهید راهنمایی کنید.
• مجموعه خوبی از مرورگرها برای آزمایش عبارتند از فایرفاکس، کروم، اج، سافاری در دسکتاپ، کروم و اینترنت سامسونگ در اندروید و سافاری در iOS. این تضمین می‌کند که سه موتور رندر اصلی (Gecko در فایرفاکس، فورک‌های مختلف Blink در Chrome، Edge و اینترنت سامسونگ، و Webkit در Safari) و بر روی پلت‌فرم‌های موبایل و دسکتاپ را تست کنید.
• اگر ممکن است سایت شما در دستگاه‌های کمتر رایج مانند تبلت‌ها، ساعت‌های هوشمند یا کنسول‌های بازی نیز استفاده شود، آن‌ها را نیز تست کنید. برخی از پلتفرم‌های سخت‌افزاری ممکن است برای به‌روزرسانی‌های مرورگر از موبایل و دسکتاپ عقب باشند، به این معنی که برخی از APIها ممکن است در مرورگرهای آن پلتفرم‌ها اجرا نشده یا در دسترس نباشند.
• با یک یا چند مرورگر آزمایش کنید که حریم خصوصی کاربر را به عنوان محرک ادعا می کنند. نسخه‌های پیش‌انتشار و آزمایشی متداول‌ترین مرورگرهای خود را در جایی که می‌توانید و اگر در دسترس شما هستند قرار دهید: پیش‌نمایش فناوری Safari، Chrome's Canary ، کانال بتا Firefox. اینها بهترین شانس را برای شناسایی خرابی API و تغییراتی که بر سایت شما تأثیر می گذارد، قبل از اینکه این تغییرات بر کاربران شما تأثیر بگذارد، می دهد. به طور مشابه، محیط های کاربران خود را با اشاره به هر تحلیلی که ارائه کرده اید در نظر داشته باشید. اگر پایگاه کاربری شما دارای تعداد بالایی از تلفن های اندرویدی قدیمی است، حتما آن ها را در تست های خود قرار دهید. اکثر مردم سخت افزار سریع و آخرین نسخه هایی که یک تیم توسعه دارد را ندارند.
• با استفاده از نمایه تمیز و در حالت مرور ناشناس/خصوصی تست کنید. این احتمال وجود دارد که شما قبلاً مجوزهای لازم را در نمایه شخصی خود اعطا کرده باشید. تست کنید اگر برای هر سوالی مجوز سایت را رد کنید چه اتفاقی می افتد.
• صریحاً صفحات خود را در حالت حفاظت از اثر انگشت فایرفاکس آزمایش کنید. اگر صفحه شما در حال تلاش برای انگشت نگاری است، با انجام این کار، دیالوگ های مجوز نشان داده می شود، یا داده های فازی برای برخی از API ها را برمی گرداند. این به شما کمک می‌کند تا تأیید کنید که آیا اشخاص ثالثی که در سرویس شما گنجانده شده‌اند از داده‌های قابل اثرانگشت استفاده می‌کنند یا اینکه سرویس شما به آن بستگی دارد. سپس می‌توانید در نظر بگیرید که آیا مبهم‌سازی عمدی انجام کاری را که نیاز دارید دشوارتر می‌کند یا خیر. برای به دست آوردن آن داده ها از منبع دیگری، بدون آن انجام دهید، یا از داده های دانه بندی کمتری استفاده کنید، اصلاحاتی را بر این اساس در نظر بگیرید.
• همانطور که قبلاً در ماژول شخص ثالث بحث شد، همچنین مهم است که وابستگی های شخص ثالث خود را بررسی کنید تا ببینید آیا آنها از تکنیک های انگشت نگاری استفاده می کنند یا خیر. تشخیص انگشت نگاری غیرفعال دشوار است (و اگر شخص ثالثی این کار را در سرور خود انجام دهد غیرممکن است) اما حالت انگشت نگاری ممکن است برخی از تکنیک های انگشت نگاری را علامت گذاری کند و جستجو برای استفاده از navigator.userAgent یا ایجاد غیرمنتظره اشیاء <canvas> نیز ممکن است برخی از رویکردها را نشان دهد. سزاوار بررسی بیشتر هستند همچنین ارزش جستجوی کاربردهای عبارت "تطابق احتمالی" در بازاریابی یا مطالب فنی برای توصیف شخص ثالث را دارد. این گاهی اوقات می تواند نشان دهنده استفاده از تکنیک های انگشت نگاری باشد.

ابزارهای تست بین مرورگرها

تست کردن کد خود برای اهداف حفظ حریم خصوصی به صورت خودکار دشوار است و مواردی که هنگام آزمایش دستی باید به دنبال آنها باشید قبلا توضیح داده شده است. چه اتفاقی می‌افتد وقتی مجوز سایت را برای هر APIهایی که به عنوان مثال سعی می‌کند به آن دسترسی داشته باشد، رد می‌کنید، و چگونه به کاربر ارائه می‌شود؟ یک تست خودکار نمی‌تواند قضاوت کند که آیا سایت به گونه‌ای عمل می‌کند که به کاربر کمک کند به آن اعتماد کند یا برعکس، کاربر را به بی‌اعتمادی تشویق کند یا فکر کند چیزی در حال پنهان شدن است.

با این حال، هنگامی که سایت ممیزی شد، آزمایش APIها برای تأیید اینکه هیچ چیز در نسخه‌های مرورگر جدیدتر (یا در نسخه‌های «بتا» و «پیش‌نمایش» آینده) خراب نشده است، می‌تواند خودکار شود و تا حد زیادی باید به عنوان بخشی از آزمایش موجود شما باشد. سوئیت هنگام کار با پوشش سطح API، چیزی که باید در مورد ابزارهای تست خودکار خود در نظر بگیرید، این است که بیشتر مرورگرها سطحی از کنترل بر روی APIها و ویژگی‌های موجود را می‌دهند. کروم این کار را از طریق سوئیچ های خط فرمان انجام می دهد، مانند فایرفاکس ، و دسترسی به این موارد در تنظیمات ابزار تست به شما امکان می دهد آزمایش های خاصی را با API های خاموش یا روشن انجام دهید. (برای مثال، پلاگین راه اندازی مرورگر Cypress و پارامتر launch.args عروسک گردان را برای راه های اضافه کردن پرچم های مرورگر هنگام راه اندازی ببینید.)

برای اطلاعات درشت فقط به رشته user-agent تکیه کنید

با در نظر گرفتن مثالی دیگر، مرورگرها از ابتدای وب با هر درخواستی که در سربرگ HTTP User-Agent توضیحی از خود ارسال کرده اند. تقریباً برای مدت طولانی، مردم به توسعه دهندگان وب توصیه می کردند که از محتویات هدر عامل کاربر برای ارائه محتوای مختلف به مرورگرهای مختلف استفاده نکنند، و در تمام این مدت توسعه دهندگان وب به هر حال این کار را انجام داده اند، با مقداری توجیه در برخی موارد. (اما نه همه) موارد. از آنجایی که مرورگرها نمی‌خواهند توسط وب‌سایت‌ها برای تجربه‌ای کمتر از حد مطلوب انتخاب شوند، این باعث می‌شود که هر مرورگری وانمود کند که هر مرورگر دیگری است و رشته عامل کاربر چیزی شبیه به:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36 .

در میان چیزهای دیگر، این ادعا می‌کند که Mozilla/5.0 مرورگری است که همزمان با ورود اولین فضانوردان به ایستگاه فضایی بین‌المللی بیش از دو دهه پیش منتشر شد. رشته کاربر-عامل منبع غنی آنتروپی برای اثرانگشت است، البته، و برای کاهش این قابلیت اثرانگشت، سازندگان مرورگر یا قبلاً هدر عامل کاربر را مسدود کرده‌اند یا در تلاش برای انجام این کار هستند. این مثال دیگری از تغییر داده‌هایی است که یک API بدون حذف کامل API ارائه می‌کند. ارسال یک سربرگ عامل کاربر خالی، وب‌سایت‌های بی‌شماری را که فرض می‌کنند وجود دارد، خراب می‌کند. بنابراین، به طور کلی، کاری که مرورگرها انجام می دهند این است که برخی از جزئیات را از آن حذف می کنند، و سپس آن را عمدتاً بدون تغییر نگه می دارند. (شما می توانید این اتفاق را در سافاری ، کروم و فایرفاکس مشاهده کنید.) این محافظت در برابر اثر انگشت دقیق اساساً به این معنی است که دیگر نمی توانید به دقیق بودن هدر عامل کاربر تکیه کنید، و اگر این کار را انجام می دهید، پیدا کردن منابع داده جایگزین مهم است. .

برای روشن بودن، داده‌های موجود در user-agent به طور کامل از بین نمی‌روند، اما با جزئیات کمتر در دسترس هستند یا گاهی اوقات نادرست هستند زیرا ممکن است یک عدد قدیمی‌تر اما تغییرناپذیر گزارش شود. برای مثال، فایرفاکس، سافاری و کروم همگی تعداد نسخه گزارش‌شده macOS را به ده می‌بندند ( به‌روزرسانی کاهش رشته عامل کاربر را برای بحث بیشتر در اینجا ببینید). جزئیات دقیق نحوه برنامه ریزی Chrome برای کاهش داده ها در رشته عامل کاربر در User-Agent Reduction موجود است، اما به طور خلاصه، می توانید انتظار داشته باشید که شماره نسخه مرورگر گزارش شده فقط شامل یک نسخه اصلی باشد (بنابراین شماره نسخه به نظر می رسد مانند 123.0.0.0، حتی اگر مرورگر نسخه 123.10.45.108 باشد)، و نسخه سیستم عامل بدون جزئیات خواهد بود و به یکی از تعداد کمی از گزینه های بدون تغییر ثابت می شود. بنابراین یک کروم خیالی نسخه 123.45.67.89 که روی یک "ویندوز 20" خیالی اجرا می شود، شماره نسخه خود را به این صورت گزارش می کند:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

اطلاعات اصلی مورد نیاز شما (نسخه مرورگر) هنوز در دسترس است: کروم 123 در ویندوز است. اما اطلاعات فرعی (معماری تراشه، کدام نسخه ویندوز، کدام نسخه از Safari تقلید می کند، نسخه جزئی مرورگر) دیگر پس از فریز در دسترس نخواهد بود.

این را با یک عامل کاربر Chrome "فعالی" در پلتفرم دیگری مقایسه کنید:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36 ،

و مشاهده می شود که تنها چیزی که تفاوت دارد شماره نسخه کروم (104) و شناسه پلتفرم است.

به طور مشابه، رشته عامل کاربر سافاری یک پلتفرم و یک شماره نسخه سافاری را نشان می‌دهد و همچنین یک نسخه سیستم‌عامل را در iOS ارائه می‌دهد، اما همه چیز ثابت است. بنابراین، یک Safari خیالی نسخه 1234.5.67 که روی یک macOS 20 تخیلی اجرا می شود، ممکن است عامل کاربر خود را به صورت زیر ارائه دهد:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15 ،

و در iOS 20 خیالی ممکن است این باشد:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15** .

باز هم، اطلاعات اصلی (این Safari است، در iOS یا macOS است) در دسترس است، و iOS Safari هنوز شماره نسخه iOS را ارائه می‌کند. اما بسیاری از اطلاعات جانبی که در گذشته در دسترس بود از آن زمان منجمد شده است. نکته مهم، این شامل شماره نسخه سافاری است که لزوماً در دسترس نیست.

تغییرات در عامل کاربر گزارش شده به شدت مورد بحث قرار گرفت. https://github.com/WICG/ua-client-hints#use-cases خلاصه برخی از استدلال ها و دلایل این تغییر را خلاصه می کند، و Rowan Merewood دارای یک عرشه اسلاید با برخی استراتژی ها برای مهاجرت به دور از استفاده از user-agent است. برای تمایز، در زمینه پیشنهاد UA Client Hints توضیح داده شده است.

مبهم

Fuzzing اصطلاحی از رویه امنیتی است که در آن APIها با مقادیر غیرمنتظره فراخوانی می شوند، به این امید که آن مقادیر غیرمنتظره را به خوبی مدیریت کنند و یک مشکل امنیتی را فاش کنند. توسعه دهندگان وب باید با اسکریپت بین سایتی (XSS) آشنا باشند، که شامل افزودن اسکریپت مخرب به یک صفحه است، اغلب به این دلیل که صفحه به درستی از HTML تزریق شده فرار نمی کند (بنابراین شما یک پرس و جو با متن <script> در آن انجام می دهید) . توسعه دهندگان Back-end از تزریق SQL آگاه خواهند بود، جایی که پرس و جوهای پایگاه داده که به درستی ورودی کاربر را تأیید نمی کنند، مسائل امنیتی را آشکار می کنند (همانطور که به طور مشخص توسط xkcd با جدول های کوچک بابی نشان داده شده است). Fuzzing یا fuzz test برای تلاش‌های خودکار برای ارائه ورودی‌های نامعتبر یا غیرمنتظره مختلف به یک API و بررسی نتایج برای نشت امنیتی، خرابی یا سایر مدیریت‌های بد، به درستی استفاده می‌شود. همه اینها نمونه هایی از ارائه اطلاعات نادرست عمدی است. با این حال، در اینجا، این کار به طور پیشگیرانه توسط مرورگرها (با نادرست کردن عمدا عامل کاربر) انجام می شود تا توسعه دهندگان را تشویق کند که به آن داده ها اعتماد نکنند.

انجام دهید

• پایگاه کد خود را برای هرگونه اتکا به رشته user-agent بررسی کنید (جستجوی navigator.userAgent احتمالاً بیشتر موارد را در کد سمت سرویس گیرنده شما پیدا می کند و کد باطن شما احتمالاً به دنبال User-Agent به عنوان هدر خواهد بود) از جمله وابستگی های شما
• اگر در کد خود کاربردهایی پیدا کردید، بررسی کنید که کد چه چیزی را بررسی می کند، و راه دیگری برای انجام آن تمایز پیدا کنید (یا یک وابستگی جایگزین پیدا کنید، یا با ثبت مشکلات یا بررسی با آنها برای به روز رسانی، با وابستگی بالادستی کار کنید). گاهی اوقات تمایز مرورگر برای رفع اشکالات ضروری است، اما عامل کاربر پس از ثابت شدن به طور فزاینده ای راهی برای انجام این کار نخواهد بود.
• ممکن است در امان باشید. اگر فقط از ارزش‌های اصلی برند، نسخه اصلی و پلتفرم استفاده می‌کنید، تقریباً مطمئناً این مقادیر همچنان در دسترس هستند و در رشته کاربر-عامل صحیح هستند.
• MDN روش‌های خوبی را برای اجتناب از اتکا به رشته عامل کاربر ("خریدن مرورگر") توضیح می‌دهد، که اصلی‌ترین آنها تشخیص ویژگی است.
• اگر به نحوی به رشته کاربر-عامل وابسته هستید (حتی زمانی که از تعداد کمی از مقادیر اصلی استفاده می‌کنید) ایده خوبی است که با عوامل کاربر آتی که در نسخه‌های جدید مرورگر خواهند بود آزمایش کنید. می‌توان با نسخه‌های پیش‌نمایش بتا یا فناوری خود با آن نسخه‌های مرورگر آینده آزمایش کرد، اما همچنین می‌توان یک رشته عامل کاربر سفارشی برای آزمایش تنظیم کرد. هنگام انجام توسعه محلی، می‌توانید رشته عامل کاربر را در Chrome، Edge ، فایرفاکس و سافاری لغو کنید تا بررسی کنید کد شما چگونه با مقادیر مختلف عامل کاربر که ممکن است از کاربران دریافت کنید، سروکار دارد.

نکات مشتری

یکی از پیشنهادات اصلی برای ارائه این اطلاعات ، User-Agent Client Hints است، اگرچه این مورد در همه مرورگرها پشتیبانی نمی‌شود. مرورگرهای پشتیبان سه سرصفحه ارسال می‌کنند: Sec-CH-UA ، که مارک مرورگر و شماره نسخه را می‌دهد. Sec-CH-UA-Mobile ، که نشان می دهد آیا درخواست از یک دستگاه تلفن همراه می آید یا خیر. و Sec-CH-UA-Platform که سیستم عامل را نامگذاری می کند. (تجزیه این سرصفحه ها کمتر از آنچه به نظر می رسد آسان نیست زیرا آنها سرصفحه های ساختار یافته هستند تا رشته های ساده، و این توسط مرورگرهایی اعمال می شود که مقادیر "مشکل" را ارسال می کنند، که اگر به درستی تجزیه نشوند به اشتباه مدیریت می شوند. این، مانند قبل، یک مثال است. "تست فاز" که به طور پیشگیرانه توسط مرورگر انجام می شود، توسعه دهنده ای که از این داده ها استفاده می کند باید به درستی آن ها را مدیریت کند، زیرا داده ها به گونه ای طراحی شده اند که تجزیه نامناسب یا تنبل احتمالاً نتایج بدی را به همراه خواهد داشت، مانند نشان دادن مارک هایی که وجود ندارند. یا رشته هایی که به درستی بسته نمی شوند.) خوشبختانه، این داده ها نیز توسط مرورگر به طور مستقیم به عنوان navigator.userAgentData در دسترس جاوا اسکریپت قرار می گیرند، که در یک مرورگر پشتیبانی کننده ممکن است چیزی شبیه به این شی باشد:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}