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

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

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

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

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

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

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

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

מה מותר לעשות

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

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

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

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

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

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

הערה: מדידת היכולת לזהות טביעות אצבע

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

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

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

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

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

השער של הרשאות המשתמשים

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

הוספת בלתי חזויות

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

אכיפת מכסת פרטיות

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

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

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

מה מותר לעשות

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

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

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

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

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

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

לשם הבהרה, הנתונים בסוכן המשתמש לא נעלמים לגמרי, אבל הם זמינים ברמת פירוט נמוכה יותר, או שלפעמים לא מדויקים, כי ייתכן שידווח מספר ישן יותר שלא משתנה. לדוגמה, בדפדפני Firefox,‏ Safari ו-Chrome, מספר הגרסה של macOS שמדווח מוגבל לעשר (מידע נוסף זמין במאמר עדכון לגבי הפחתת המחרוזת של סוכן המשתמש). הפרטים המדויקים לגבי האופן שבו Chrome מתכנן לצמצם את הנתונים במחרוזת של סוכן המשתמש זמינים במאמר הפחתת מידע ב-User-Agent, אבל בקצרה, אפשר לצפות שמספר גרסת הדפדפן שידווח יכלול רק גרסה ראשית (כך שמספר הגרסה ייראה כמו 123.0.0.0, גם אם גרסת הדפדפן היא 123.10.45.108), וגרסת מערכת ההפעלה לא תכלול פרטים ותוקפא לאחת מתוך מספר קטן של אפשרויות שלא משתנות. כך גרסת Chrome הדמיונית 123.45.67.89 שפועלת על "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, אבל כל השאר קפוא. למשל, דפדפן 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) זמין, ודפדפן Safari ל-iOS עדיין מספק את מספר הגרסה של iOS. עם זאת, רוב המידע המשני שהיה זמין בעבר הוקפא. חשוב לציין שמדובר גם ב-Safari את מספר הגרסה, שאינו בהכרח זמין.

השינויים בסוכן המשתמש שדווחו עוררו דיון סוער. https://github.com/WICG/ua-client-hints#use-cases summarises

בדיקת fuzz

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

מה מותר לעשות

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

רמזים על הלקוח (Client Hints)

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

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