טביעת אצבע

המשמעות של טביעת אצבע היא לנסות לזהות משתמש כשהוא חוזר לאתר שלכם, או לזהות את אותו משתמש באתרים שונים. יש הבדלים רבים בין ההגדרה שלכם לבין מאפיינים של מישהו אחר. לדוגמה, יכול להיות שאתם משתמשים בסוג אחר של מכשיר ובדפדפן אחר, אם יש לכם גודל מסך שונה ושמות גופנים שונים מותקנים. אם התקנתי את הגופן Dejavu Sans ולא תראו אותו, אתרים אחרים יוכלו להבדיל ביניכם לבין משתמשים אחרים על ידי בדיקת הגופן הזה. כך פועלת טביעת אצבע; יוצרים אוסף של נקודות נתונים, וכל אחת מהן מספקת דרכים נוספות להבדיל בין משתמשים.

הגדרה רשמית יותר עשויה להיראות כך: טביעת אצבע היא הפעולה של שימוש במאפיינים ברורים ולא מובנים לטווח ארוך של הגדרת המשתמש, בניסיון להבחין בינו לבין משתמשים רבים ככל האפשר.

למה יצירה של טביעת אצבע דיגיטלית (fingerprinting) פוגעת בפרטיות המשתמשים

יש כמה מקרים קיצוניים שבהם חשוב לשמור על טביעת אצבע של המשתמש: למשל, זיהוי הונאות. עם זאת, אפשר גם להשתמש ביצירה של טביעת אצבע דיגיטלית (fingerprinting) כדי לעקוב אחרי משתמשים באתרים שונים. לרוב, המעקב מתבצע בלי שהמשתמשים הסכימו לכך, ובמקרים מסוימים גם שמבוסס על הסכמה לא חוקית שלא מספקת ליידע את המשתמש בצורה מספקת. אחרי שעושים זאת, המשתמשים האלה בדרך כלל ירגישו שהיא מטרידה במידה מסוימת והם ירגישו נבגדים.

המשמעות של טביעת אצבע היא למצוא דרכים ליצור הבחנה ברורה בין המשתמש למשתמש אחר. אפשר להשתמש בטביעת אצבע כדי לזהות שמדובר באותו משתמש באותו אתר, או כדי לזהות את אותו משתמש בשני פרופילים שונים של דפדפן בו-זמנית. כלומר, אפשר להשתמש ביצירה של טביעת אצבע דיגיטלית (fingerprinting) כדי לעקוב אחר משתמשים באתרים שונים. אפשר לבדוק במידה מסוימת את שיטות המעקב הדטרמיניסטיות והגלויות, כמו אחסון קובץ cookie עם מזהה ייחודי וספציפי למשתמש, ולבדוק את אלה המשתמשים (והוסבר במודול הקודם חלק מהגישות האלה). אבל קשה יותר להימנע מיצירה של טביעת אצבע דיגיטלית (fingerprinting) באופן מדויק כי היא "נסתרת". היא מסתמכת על מאפיינים בלתי משתנים, וסביר להניח שהיא מתרחשת באופן בלתי נראה. לכן התכונה הזו נקראת "טביעת אצבע". קשה במיוחד לשנות את טביעת האצבע, בין אם זו טביעת האצבע הדיגיטלית שלכם או טביעות האצבעות שבקצה האצבעות.

ספקי דפדפנים יודעים שמשתמשים לא אוהבים שעוקבים אחריהם, והם מטמיעים כל הזמן תכונות כדי להגביל יצירה של טביעת אצבע דיגיטלית (fingerprinting) (חלק מהן ראינו במודול הקודם). כאן נסביר איך התכונות האלה עשויות להשפיע על הדרישות של העסק שלכם, ואיך להמשיך לעשות את מה שאתם רוצים לעשות תוך שמירה על הפרטיות. נסביר יותר איך ההגנה של הדפדפן מול יצירה של טביעת אצבע דיגיטלית (fingerprinting) תשפיע על הפעולות שתבצעו ועל האופן שבו היא תמנע מכם ליצור טביעת אצבע דיגיטלית.

בפועל, רוב המפתחים ורוב העסקים לא צריכים טביעת אצבע של משתמשים. אם האפליקציה מחייבת כניסה של משתמשים, המשתמשים יזהו את עצמם, בהסכמתם ובאופן חד-צדדי – הם יוכלו לבטל את הסכמתם בכל שלב. זוהי שיטה שעוזרת להגן על הפרטיות כדי להבין אילו משתמשים מחוברים. יכול להיות שלא חייבים למשתמשים להיכנס לחשבון באפליקציה, דבר שמגן עוד יותר על פרטיות המשתמשים (ואז אתם אוספים רק את הנתונים שאתם צריכים).

מה מותר לעשות

להעריך אם יש לצדדים השלישיים טביעת אצבע דיגיטלית. כחלק מהמודול של הצדדים השלישיים, יכול להיות שכבר יש לכם רשימה של שירותי צד שלישי שאתם כוללים ובקשות האינטרנט שהם שולחים. ייתכן שתהיה אפשרות לבדוק את הבקשות האלה כדי לראות אילו נתונים מועברים בחזרה ליוצר, אם יש כאלה. אבל זה בדרך כלל קשה. טביעת אצבע היא מטבעה תהליך סודי שכולל בקשת נתונים שאינם כפופים לאישור המשתמשים.

כדאי גם לקרוא את מדיניות הפרטיות של שירותי הצד השלישי ושל יחסי התלות של הצד השלישי כדי לחפש סימנים לשימוש בטביעת אצבע דיגיטלית (fingerprinting) בשימוש. לפעמים היא נקראת 'התאמה הסתברותית', או כחלק מחבילה של טכניקות התאמה הסתברותיות, בניגוד ל'התאמה דטרמיניסטית'.

איך פועלת יצירה של טביעת אצבע דיגיטלית (fingerprinting)

לעיתים קרובות, השילוב האישי של כל המאפיינים האלה הוא ייחודי לכם, או לפחות לקבוצה קטנה של אנשים דומים. אפשר להשתמש בו כדי לעקוב אחריכם.

בנוסף: יצירה פסיבית ופעילה של טביעת אצבע דיגיטלית

יש כאן הבחנה שימושית בין שיטות פסיביות ופעילות של טביעת אצבע דיגיטלית (fingerprinting). שיטה פסיבית ליצירה של טביעת אצבע דיגיטלית (fingerprinting) היא כזו שמשתמשת במידע שניתן לאתר כברירת מחדל. שיטה פעילה ליצירה של טביעת אצבע דיגיטלית (fingerprinting) היא זו שחוקרת את הדפדפן באופן מפורש כדי לקבל מידע נוסף. ההבחנה הזו חשובה היא שדפדפנים יכולים לנסות לזהות וליירט טכניקות פעילות, או לצמצם אותן. אפשר להגביל ממשקי API או להציב שער מאחורי תיבת דו-שיח עם בקשה לאישור המשתמש (ולכן כדי להתריע למשתמש שהוא בשימוש, או לאפשר למשתמש לדחות אותם כברירת מחדל). טכניקה פסיבית היא שיטה שמשתמשת בנתונים שכבר סופקו לאתר, לעיתים קרובות מפני שהמידע הזה נמסר לכל האתרים בעבר, בימים שהיוו בתחילת הדרך. מחרוזת הסוכן המשתמש היא דוגמה לכך, ונרחיב על כך בהמשך. הוא נחשב למועיל כשהוא מספק הרבה מידע על הדפדפן, הגרסה ומערכת ההפעלה של המשתמש, כדי שאתר יכול לבחור להציג דברים שונים על סמך מידע זה. עם זאת, הפעולה הזו גם מגדילה את כמות המידע המבדיל בין משתמשים ועוזרת לזהות משתמש אחר. כתוצאה מכך מידע כזה הולך ופוחת יותר ויותר, או לפחות קפוא כך שלא ניתן להבחין בו יותר. אם מה שאתם עושים מסתמך על המידע הזה – לדוגמה, אם אתם משתמשים בהסתעפויות קוד שונות בהתאם לסוכן המשתמש – הקוד עלול להשתבש כי הדפדפנים מקפיאים יותר ויותר או עוצרים את המידע הזה. ההגנה הטובה ביותר היא בדיקה ( ראו מאוחר יותר).

מלבד זאת: מדידת טביעת אצבע

המדד הטכני של כמות המידע שכל אחת מהנקודות האלה מספק נקרא אנטרופיה, והוא נמדד בביטים. תכונה שבה יש ערכים אפשריים רבים (כמו רשימת הגופנים המותקנים) יכולה לתרום הרבה ביטים לסך הכול, כך שמשהו שאין לו עוצמה רבה מאוד (כמו מערכת ההפעלה שבה אתם משתמשים) יכול להוסיף רק כמה מהן. באלמנך של HTTP מתואר איך ספריות קיימות ליצירה של טביעת אצבע דיגיטלית (fingerprinting) הופכות לאוטומטיות את התהליך הזה של שילוב התגובות מממשקי API רבים שונים ליצירת 'גיבוב' שיכול לזהות רק קבוצה קטנה של משתמשים, אולי אפילו רק אחת. מוד נלפס מסביר על כך בפירוט בסרטון הזה ב-YouTube, אבל בקצרה, דמיינו שאתם רואים רשימה של חברים עם המוזיקה שהם אוהבים, המאכלים האהובים עליהם והשפות שהם דוברים... אבל כשהשמות שלהם הוסרו. סביר להניח שרשימה של משתמשים אחת תזהה אותו באופן ייחודי מבין החברים שלכם, או לפחות תצמצם את הרשימה למספר קטן של אנשים. כך עובדת יצירה של טביעת אצבע דיגיטלית (fingerprinting). רשימת הדברים האהובים עליך הופכת ל "גיבוב". בעזרת הגיבוב הזה, קל יותר לזהות משתמש כאותו אדם בשני אתרים שונים שאינם מחוברים, וזה המטרה של המעקב: לעקוף את השאיפה של המשתמש לפרטיות.

מה דפדפנים עושים נגד יצירה של טביעת אצבע דיגיטלית (fingerprinting)?

חשוב לציין שספקי דפדפנים מודעים להרבה דרכים שונות שבאמצעותן אתר (או צד שלישי שכלול באתר) יוכל לחשב את טביעת האצבע הייחודית של המשתמש, או את הפרטים השונים שתורמים לייחודיות של אותה טביעת אצבע. חלק מהדרכים האלה מפורשות ומכוונות, כמו מחרוזת סוכן המשתמש של הדפדפן, שלרוב מזהה את הדפדפן, מערכת ההפעלה והגרסה שבה נעשה שימוש (וכך היא עוזרת להבחין ביניכם, אם אנחנו משתמשים בדפדפנים שונים). חלק מהדרכים לא נוצרות בכוונה כך שניתן יהיה טביעת אצבע, אבל בסופו של דבר כן, כמו רשימת הגופנים או התקני וידאו ואודיו שזמינים לדפדפן. (הדפדפן לא חייב להשתמש במכשירים האלה, אלא רק לקבל רשימה שלהם לפי שם). כמו כן, בחלקם הוכחו כתורמים לטביעת אצבע זמן רב לאחר שחרורם, למשל רינדור פיקסלים מדויק של החלקת קצוות לגופנים באלמנט בהדפסה על קנבס. יש אפשרויות רבות נוספות, וכל אחת מהדרכים שבהן הדפדפן שלך שונה מזו שלי מוסיפה אנטרופיה וכך היא עשויה לתרום לדרך לזיהוי ההבדל ביניכם לבין אדם מסוים בצורה ייחודית ככל האפשר באתרים שונים. ב-https://amiunique.org יש רשימה ארוכה (אבל לא מקיפה) של תכונות פוטנציאליות התומכות טביעות אצבע והרשימה הולכת וגדלה כל הזמן (ואולי אפילו יש יותר עניין במשתמשים, אפילו שהגישה של טביעת אצבע חזקה).

אין תמיכה בממשקי API מסוימים מתקדמים

התגובה של ספקי הדפדפנים לכל הגישות האלה לחישוב טביעת האצבע של המשתמש היא למצוא דרכים לצמצם את כמות האנטרופיה שזמינה מממשקי ה-API האלה. האפשרות המגבילה ביותר היא לא ליישם אותן מלכתחילה. חלק מהדפדפנים הגדולים עשו זאת במגוון ממשקי API לחומרה ולמכשירים (כמו גישה ל-NFC ול-Bluetooth מאפליקציות אינטרנט בצד הלקוח). הסיבה לכך היא שלא הוטמעו טביעות אצבע ובעיות פרטיות. התנהלות כזו יכולה, כמובן, להשפיע על האפליקציות והשירותים שלכם: אסור להשתמש ב-API בכלל בדפדפן שלא מטמיע אותו, וזה עלול להגביל או לקטוע לחלוטין גישות חומרה מסוימות.

שער הרשאות המשתמש

הגישה השנייה שננקטת על ידי ספקי דפדפנים היא למנוע גישה ל-API או לנתונים ללא אישור מפורש כלשהו מהמשתמשים. לעיתים קרובות נוקטת גישה זו גם מטעמי אבטחה - אסור לאתרים לצלם תמונות במצלמת האינטרנט ללא רשותך! אבל כאן, לפרטיות ולאבטחה יכולים להיות אינטרסים דומים. זיהוי מיקום של מישהו הוא כמובן הפרה של הפרטיות בפני עצמו, אבל יש גם תורמת לייחודיות של טביעת האצבע. דרישת הרשאה להצגת מיקום גיאוגרפי לא מקטינה את האנטרופיה הנוספת שמוסיפה מיקום לייחודיות של טביעת האצבע, אבל היא מבטלת את השימוש במיקום הגיאוגרפי ליצירה של טביעת אצבע דיגיטלית (fingerprinting), כי היא כבר לא מתבצעת באופן בלתי נראה. המטרה של טביעת אצבע היא ליצור הבחנה חשאית בין המשתמשים. אם אתם מוכנים שהמשתמש יידע שאתם מנסים לזהות אותו, אין צורך בשיטות ליצירה של טביעת אצבע דיגיטלית: בקשו מהמשתמש ליצור חשבון ולהתחבר באמצעותו.

הוספה של נתונים בלתי צפויים

במקרים מסוימים, גישה שלישית היא לאפשר לספקי דפדפנים "לטשטש" את התגובות מממשקי ה-API כדי שיהיו פחות מפורטות ופחות מזדהות. כפי שתואר כחלק ממנגנון התגובה האקראית במודול הנתונים, אתם יכולים לבצע איסוף של נתונים ממשתמשים כדי להימנע מאיסוף לא מכוון של נתונים שמאפשרים זיהוי. ספקי דפדפנים יכולים לנקוט גישה זו לגבי נתוני API שזמינים גם לאפליקציות אינטרנט ולצדדים שלישיים. דוגמה לכך היא ממשקי ה-API לתזמון מדויקים מאוד שמשמשים למדידת ביצועים של דפים מ-window.performance.now(). הדפדפן יודע את הערכים האלה ברמת דיוק של מיקרו-שנייה, אבל הדיוק של הערכים שמוחזרים מופחת באופן מכוון על ידי עיגול לגבול הקרוב ביותר של 20 מיקרו-שניות כדי למנוע שימוש בהם ביצירה של טביעת אצבע דיגיטלית (וגם לאבטחה כדי למנוע התקפות תזמון). המטרה כאן היא לוודא שממשקי ה-API יישארו שימושיים, אבל שהתגובות יהיו פחות מזדהות: באופן עקרוני, לספק "חסינות עדר" כך שהמכשיר ייראה יותר כמו המכשיר של כולם ולא יהיה ייחודי לכם. מהסיבה הזו, Safari מציג גרסה פשוטה יותר של הגדרות המערכת.

אכיפה של תקציב בנושא פרטיות

תקציב הפרטיות הוא הצעה שטוענת לדפדפנים להעריך את המידע שנחשף לפי כל פלטפורמה ליצירה של טביעת אצבע דיגיטלית. עוד לא הוטמע בדפדפן. המטרה היא לאפשר ממשקי API חזקים תוך שמירה על פרטיות המשתמשים. מידע נוסף על ההצעה לתקציב בנושא פרטיות

משתמשים בסביבת בדיקה רחבה

כל אלה ישפיעו על האופן שבו אתם יוצרים אפליקציות ושירותים. באופן ספציפי, יש בתחום הזה מגוון רחב של תגובות וגישות בפלטפורמות ובדפדפנים שונים. המשמעות היא שבדיקת העבודה שלכם בכמה סביבות שונות היא קריטית. זה כמובן חשוב, אבל סביר להניח שעיבוד HTML או CSS יהיו קבועים במנוע עיבוד נתון, ללא קשר לדפדפן או לפלטפורמה שבהם המנוע נמצא (ולכן יכול להיות מפתה לבדוק רק בדפדפן אחד מבוסס-Blink, לדוגמה). זה לא בדיוק המצב כשמדובר בשימוש ב-API, כי דפדפנים שחולקים מנוע רינדור עשויים להשתנות באופן משמעותי מבחינת האופן שבו הם מקשיחים את ה-API מפני יצירה של טביעת אצבע דיגיטלית (fingerprinting).

מה מותר לעשות

• תוכלו לעיין בניתוח הנתונים ובקהל שלכם כדי להנחות את קבוצת הדפדפנים שכדאי לתת להם עדיפות במהלך הבדיקה.
• קבוצה טובה של דפדפנים לבדיקה היא Firefox, Chrome, Edge, Safari במחשב, אינטרנט Chrome ו-Samsung ב-Android ו-Safari ב-iOS. כך ניתן לבצע בדיקה בכל שלושת מנועי העיבוד העיקריים (Gecko ב-Firefox, מזלגות שונים של Blink ב-Chrome, Edge ו-Samsung Internet ו-Webkit ב-Safari), ובפלטפורמות לנייד ולמחשב.
• אם האתר שלכם משמש גם במכשירים פחות נפוצים, כמו טאבלטים, שעונים חכמים או קונסולות משחקים, כדאי לבדוק גם שם. פלטפורמות חומרה מסוימות עלולות להיות בעיכוב אחרי עדכוני הדפדפן בנייד ובמחשב, כלומר ייתכן שממשקי API מסוימים לא יהיו מוטמעים או לא זמינים בדפדפנים בפלטפורמות האלה.
• בודקים בדפדפן אחד או יותר שמצהירים על פרטיות המשתמשים כמניע. כדאי לכלול את גרסאות טרום-ההשקה והבדיקה העתידיות של הדפדפנים הנפוצים ביותר שלכם, שבהם אפשר ואם הם זמינים: גרסת טרום-ההשקה (Preview) של הטכנולוגיה של Safari, גרסת Canary של Chrome וערוץ הבטא של Firefox. כך יש סיכוי טוב יותר לזהות תקלות ב-API ושינויים שמשפיעים על האתרים שלכם, לפני שהשינויים ישפיעו על המשתמשים. חשוב גם לקחת בחשבון את הסביבות של המשתמשים, תוך התייחסות לכל ניתוח הנתונים הקיים. אם בבסיס המשתמשים שלכם יש הרבה טלפונים ישנים של Android, חשוב לכלול אותם בבדיקות. לרוב האנשים אין את החומרה המהירה ואת הגרסאות העדכניות שיש לצוות הפיתוח.
• בדוק גם באמצעות פרופיל נקי וגם במצב גלישה פרטית/פרטית; סביר להניח שכבר הענקת את ההרשאות הנדרשות בפרופיל האישי שלך. צריך לבדוק מה קורה אם לא מעניקים הרשאה לאתר בנוגע לשאלה כלשהי.
• צריך לבדוק באופן מפורש את הדפים במצב הגנה באמצעות טביעת אצבע דיגיטלית (fingerprinting) של Firefox. פעולה זו תציג תיבות דו-שיח של ההרשאות אם נעשה ניסיון ליצור טביעת אצבע בדף, או שהיא תחזיר נתונים מעורפלים בחלק מממשקי ה-API. כך תוכלו לוודא אם צדדים שלישיים שכלולים בשירות שלכם משתמשים בנתונים שניתנים לטביעת אצבע, או אם השירות שלכם תלוי בכך. לאחר מכן אפשר לבדוק אם הטשטוש המכוון מקשה על ביצוע הפעולות הדרושות. כדאי לבצע תיקונים בהתאם כדי לקבל את הנתונים ממקור אחר, למנוע את הכללתם או להשתמש בנתונים פחות מפורטים.
• כפי שצוין קודם במודול של הצדדים השלישיים, חשוב גם לבדוק את התלות של גורמי צד שלישי כדי לראות אם הם משתמשים בשיטות ליצירה של טביעת אצבע דיגיטלית. קשה לזהות יצירה של טביעת אצבע פסיבית (ובלתי אפשרי אם צד שלישי מבצע אותה בשרת שלו), אבל יכול להיות שמצב יצירה של טביעת אצבע דיגיטלית (fingerprinting) מסמן שיטות מסוימות ליצירה של טביעת אצבע דיגיטלית. גם חיפוש שימושים ב-navigator.userAgent או יצירה לא צפויה של אובייקטים של <canvas> עשוי לחשוף גישות מסוימות שדורשות בדיקה נוספת. כדאי גם לחפש שימוש במונח "התאמה הסתברותית" בחומרי שיווק או בחומרים טכניים שמתארים צד שלישי. לפעמים זה יכול להצביע על שימוש בטכניקות של יצירה של טביעת אצבע דיגיטלית (fingerprinting).

כלי בדיקה לדפדפנים שונים

קשה לבצע אוטומציה של בדיקת הקוד שלכם למטרות פרטיות, והדברים שיש לבדוק בעת ביצוע בדיקה ידנית מתוארים למעלה. מה קורה כשדוחים הרשאה לאתר עבור ממשקי API שאליהם הוא מנסה לגשת, לדוגמה, ואיך ההרשאה הזו מוצגת למשתמש? בדיקה אוטומטית לא יכולה לקבוע אם האתר פועל כדי לעזור למשתמש לסמוך עליו, או להפך, כדי לעודד את המשתמש לסמוך עליו או לחשוב שמשהו מוסתר.

עם זאת, אחרי שהאתר נבדק, הבדיקה של ממשקי API כדי לוודא ששום דבר לא התקלקל בגרסאות חדשות יותר של הדפדפן (או בגרסאות הבאות של 'בטא' ו'תצוגה מקדימה') יכול להיות אוטומטי, וברובו צריך להיות חלק מחבילת הבדיקות הקיימת. כשמשתמשים בכלי הבדיקה האוטומטיים, כשעובדים עם כיסוי פלטפורמות של API, רוב הדפדפנים מאפשרים רמה מסוימת של שליטה על ממשקי ה-API והתכונות הזמינים. Chrome עושה זאת באמצעות מתגי שורת הפקודה, וכך גם Firefox, וגישה אליהם בהגדרה של כלי הבדיקה תאפשר לך להריץ בדיקות מסוימות כאשר ממשקי API מושבתים או מופעלים. (לדוגמה, ראו את הפלאגין Browser-launch של Cypress ואת הפרמטרlaunch.args של puppeteer כדי לראות איך מוסיפים דגלים לדפדפן בזמן ההפעלה).

הסתמכו על מחרוזת סוכן המשתמש רק עבור מידע גס

אם ניקח דוגמה נוספת, דפדפנים שלחו מאז תחילת האינטרנט תיאור של עצמם עם כל בקשה בכותרת ה-User-Agent של HTTP. במשך כמעט זמן רב, אנשים קוראים למפתחי אינטרנט לא להשתמש בתוכן של כותרת סוכן המשתמש על מנת להציג תוכן שונה בדפדפנים שונים, ולמשך כל הזמן הזה מפתחי אינטרנט עשו זאת בכל זאת, עם מידה מסוימת של הצדקה בחלק מהמקרים (אבל לא בכולם). מכיוון שדפדפנים לא רוצים שאתרים יזהו חוויה לא אופטימלית, כתוצאה מכך כל דפדפן יעמיד פנים שהוא כל דפדפן אחר, והמחרוזת של סוכן המשתמש תיראה בערך כך:

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, דפדפן שהושק כשיצאו האסטרונאוטים הראשונים לתחנת החלל הבינלאומית לפני יותר משני עשורים. מחרוזת הסוכן המשתמש היא מקור עשיר של אנטרופיה ליצירה של טביעת אצבע דיגיטלית (fingerprinting), כמובן, וכדי לצמצם את האפשרות לטביעת אצבע דיגיטלית (fingerprinting), יצרני הדפדפנים כבר הקפיאו את כותרת הסוכן המשתמש או שהם עשו זאת. זו דוגמה נוספת לשינוי הנתונים שה-API מספק בלי להסיר בהכרח את ה-API. שליחת כותרת ריקה של סוכן משתמש תגרום להשבתת אתרים רבים שמניחים שהוא קיים. באופן כללי, הדפדפנים עושים הסרה של חלק מהפרטים, ומשאירים את רובם ללא שינוי בעתיד. (אפשר לראות את זה ב-Safari, ב-Chrome וב-Firefox). המשמעות של ההגנה הזו מפני יצירה של טביעת אצבע דיגיטלית מפורטת היא שכבר אי אפשר להסתמך יותר על הדיוק של כותרת הסוכן המשתמש. במקרה כזה, חשוב למצוא מקורות נתונים חלופיים.

חשוב להבהיר: הנתונים בסוכן המשתמש לא נמחקים לחלוטין, אבל הם זמינים ברמת פירוט נמוכה יותר. לפעמים הם לא מדויקים, כי המערכת עשויה לדווח על מספר ישן יותר אבל לא משתנה. לדוגמה, ב-Firefox, ב-Safari וב-Chrome יש הגבלה ל-10 על מספר הגרסה של macOS (למידע נוסף, ראו עדכון לגבי הפחתת מחרוזות של סוכן משתמש). הפרטים המדויקים על האופן שבו Chrome מתכנן לצמצם את הנתונים במחרוזת סוכן המשתמש זמינים במאמר הפחתת מידע של סוכן משתמש. עם זאת, בקיצור, מספר הגרסה של הדפדפן המדווח יכלול רק גרסה ראשית (כך שמספר הגרסה ייראה כמו 123.0.0.0, גם אם גרסת הדפדפן היא 123.10.45.108), והגרסה של מערכת ההפעלה לא תשתנה מבלי לשנות את המספר. כך, גרסה 123.45.67.89 של Chrome דמיונית שפועלת ב-"Windows 20" תדווח על מספר הגרסה באופן הבא:

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

המידע העיקרי שדרוש לכם (גרסת הדפדפן) עדיין זמין: Chrome 123 ב-Windows. עם זאת, המידע של חברת הבת (ארכיטקטורת הצ'יפים, איזו גרסת Windows, ואיזו גרסה של Safari היא מחקה, הגרסה המשנית של הדפדפן) לא יהיו זמינים יותר לאחר ההקפאה.

השוו זאת לסוכן משתמש 'נוכחי' של Chrome בפלטפורמה אחרת:

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

וניתן לראות שההבדל היחיד הוא מספר הגרסה של Chrome (104) ומזהה הפלטפורמה.

באופן דומה, מחרוזת סוכן המשתמש של Safari מציגה פלטפורמה ומספר גרסה של Safari, וגם מספקת את גרסת מערכת ההפעלה ב-iOS, אבל כל השאר תקוע. לכן, בגרסה 1234.5.67 של Safari דמיונית שפועלת ב-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; אבל חלק גדול מהמידע הנוסף שהיה זמין בעבר הוקפא מאז. חשוב לציין שפרטים אלה כוללים את מספר הגרסה של Safari, שלא בהכרח זמין.

על השינויים בסוכן המשתמש המדווח יש דיון חריף. https://github.com/WICG/ua-client-hints#use-cases summarises מסכם כמה מהארגומנטים והסיבות לשינוי, ומצגת שקפים של רוואן מרווד, עם הסבר נוסף על שימוש בסוכן משתמש לבידול, מוסבר בהרחבה על כמה מהאסטרטגיות שנוגעות לשימוש בסוכן המשתמש לבידול ב-Client.

התאמה חלקית

Fuzzing הוא מונח מנוהלי אבטחה, שבו ממשקי API נקראים עם ערכים לא צפויים בתקווה שהם יטפלו בערכים הלא צפויים האלה בצורה גרועה וחושפים בעיית אבטחה. מפתחי אתרים צריכים להכיר את הנושא סקריפטים חוצי-אתרים (XSS), שכרוכים בהוספת סקריפט זדוני לדף, לעיתים קרובות כי הדף לא עושה escape נכון של קוד HTML (כך שאתם מבצעים שאילתת חיפוש עם הטקסט <script>). מפתחי קצה עורפי יכירו את החדרת ה-SQL, שבה שאילתות של מסד הנתונים שלא מאמתות בצורה נכונה את קלט המשתמש חושפות בעיות אבטחה (כפי שניתן לראות ב-xkcd בעזרת Little Bobby Tables). השימוש ב-fuzzing, או בדיקת fuzz, מתאים יותר לניסיונות אוטומטיים לספק קלטים לא חוקיים או בלתי צפויים רבים ל-API, וכדי לבדוק את התוצאות לאיתור דליפות אבטחה, קריסות או טיפול לא תקין אחר. כל הדוגמאות האלה הן דוגמאות לפרטים לא מדויקים במכוון. אבל במקרה הזה, הדפדפן מבצע את הפעולה הזו באופן יזום על ידי דפדפנים (באמצעות טעות מכוונת של סוכן המשתמש), כדי לעודד מפתחים להפסיק להסתמך על הנתונים האלה.

מה מותר לעשות

• צריך לבדוק את בסיס הקוד כדי לבדוק אם יש הסתמכות על מחרוזת הסוכן המשתמש (חיפוש של navigator.userAgent צפוי למצוא את רוב האירועים בקוד בצד הלקוח, וסביר להניח שקוד הקצה העורפי יחפש את User-Agent ככותרת), כולל את יחסי התלות.
• אם מצאתם שימושים בקוד שלכם, בדקו מה הקוד בודק ולמצוא דרך אחרת לעשות את ההבדל הזה (או למצוא תלות חלופית, או לעבוד עם התלות במעלה הזרם על ידי דיווח על בעיות או בדיקה אם יש עדכונים). לפעמים יש צורך בהבחנה בין הדפדפן כדי לעקוף באגים, אבל סוכן המשתמש יהפוך יותר ויותר לא הדרך לעשות זאת לאחר הקפיא.
• יכול להיות שתהיו בטוחים. אם אתם משתמשים רק בערכי הליבה של המותג, הגרסה הראשית והפלטפורמה, כמעט בטוח שהם יהיו זמינים ויהיו נכונים במחרוזת סוכן המשתמש.
• ב-MDN מתוארות דרכים טובות להימנע מהסתמכות על מחרוזת הסוכן-משתמש ("דפדפן sniffing"), שעיקרה זיהוי התכונות.
• אם אתם מסתמכים בצורה כלשהי על מחרוזת הסוכן המשתמש (גם אם אתם משתמשים בערכי הליבה היחידים שנשארים שימושיים), כדאי לבדוק את זה עם סוכני משתמש עתידיים שיהיו בגרסאות חדשות לדפדפן. אפשר לבדוק בעצמם את גרסאות הדפדפן הבאות באמצעות גרסאות build של גרסת בטא או של תצוגה מקדימה של הטכנולוגיה, אבל אפשר גם להגדיר מחרוזת מותאמת אישית של סוכן משתמש לצורך הבדיקה. במהלך פיתוח מקומי, ניתן לעקוף את המחרוזת של סוכן המשתמש ב-Chrome , Edge , Firefox ו-Safari, כדי לבדוק איך הקוד מטפל בערכים שונים של סוכן משתמש שאתם עשויים לקבל ממשתמשים.

רמזים ללקוחות

אחת מההצעות העיקריות לספק את המידע הזה היא טיפים ללקוח של סוכן משתמש, אבל האפשרות הזו לא נתמכת בכל הדפדפנים. דפדפנים תומכים יעבירו שלוש כותרות: Sec-CH-UA, עם שם המותג ומספר הגרסה של הדפדפן. Sec-CH-UA-Mobile שמציין אם הבקשה מגיעה ממכשיר נייד, ו-Sec-CH-UA-Platform – שם מערכת ההפעלה. (ניתוח הכותרות האלה פחות קל מכפי שנראה כי הן כותרות מובנות ולא מחרוזות פשוטות, ולכן דפדפנים ששולחים ערכי 'tricky' יטופלו בצורה לא נכונה אם לא ינתחו אותן בצורה נכונה. זאת, כמו קודם, דוגמה ל"בדיקת fuzz" שמתבצעת מראש על ידי הדפדפן. מפתח שמשתמש בנתונים האלה נדרש לטפל בהם בצורה נכונה, כי הנתונים תוכננו כך שניתוח לא תקין או עצלנות עשוי להניב תוצאות לא טובות, כמו הצגת מותגים שלא קיימים או מחרוזות שלא נסגרות כמו שצריך). למרבה המזל, הנתונים האלה זמינים גם על ידי הדפדפן ל-JavaScript ישירות בתור navigator.userAgentData, ובדפדפן תומך אפשר להיראות בערך כמו האובייקט הבא:

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