יצירה של טביעת אצבע דיגיטלית פירושה ניסיון לזהות משתמש כשהוא חוזר לאתר שלכם, או זיהוי של אותו משתמש באתרים שונים. יש הרבה מאפיינים שעשויים להיות שונים בין ההגדרות שלכם לבין המאפיינים של מישהו אחר. לדוגמה, ייתכן שאתם משתמשים במכשיר מסוג אחר ובדפדפן אחר, יש להם גודל מסך שונה ומותקנות בהם גופנים שונים. אם יש לי גופן "Dejavu Sans" ולא מותקנת אצלך, כל אתר יכול להבחין ביניכם לבין חיפוש גופן זה. כך יצירה של טביעת אצבע דיגיטלית (fingerprinting), נוצר אוסף של נקודות הנתונים האלה, וכל אחת מהן מספקת דרכים נוספות להבחנה בין משתמשים.
הגדרה רשמית יותר עשויה להיראות כך: יצירה של טביעת אצבע דיגיטלית היא הפעולה של שימוש ברור ולא ברור בטווח הארוך. המאפיינים של הגדרת המשתמש כדי לנסות להבדיל אותו ממשתמשים רבים אחרים ככל האפשר.
למה יצירה של טביעת אצבע דיגיטלית פוגעת בפרטיות המשתמשים
יש כמה מקרי קצה שבהם חשובה למשתמשים יצירה של טביעת אצבע דיגיטלית (fingerprinting) – למשל, זיהוי הונאות. אבל יצירה של טביעת אצבע דיגיטלית יכולה גם משמש למעקב אחרי משתמשים באתרים שונים, והמעקב מתבצע בדרך כלל בלי שהמשתמשים הסכימו לכך, או במקרים מסוימים, על סמך מצב של הסכמה לא חוקית שלא מספק למשתמש מידע בהתאם. אחרי זה, המשתמשים האלה יראו את זה במידה מסוימת תחושת תחושת אי נעימות רגשית, ופחות תחושת אי נעימות.
יצירה של טביעת אצבע דיגיטלית פירושה מציאת דרכים להבחין באופן מוסתר בין משתמשים. אפשר להשתמש בטביעת אצבע כדי לזהות זה עדיין אותו משתמש באותו אתר, או שהוא מזהה את אותו משתמש בשני פרופילים שונים בדפדפן בו-זמנית. כלומר, ניתן להשתמש בטביעת אצבע כדי לעקוב אחר משתמשים באתרים שונים. השיטות הדטרמיניסטיות והגלויות למעקב, כמו אחסון קובץ cookie עם מזהה ייחודי וספציפי למשתמש, ניתנים במידה מסוימת לבדיקה על ידי המשתמשים (ובמודול הקודם הוסבר חלק מהגישות האלה). אבל קשה יותר להימנע מיצירה של טביעת אצבע דיגיטלית (fingerprinting) כי הוא מוסתר; היא מסתמכים על מאפיינים שלא משתנים, ובדרך כלל קורה באופן בלתי נראה. לכן קוראים לזה יצירה של טביעת אצבע דיגיטלית (fingerprinting). קשה לכל היותר לשנות את טביעת האצבע, את טביעת האצבע הדיגיטלית או את טביעות האצבע באצבעות.
ספקי דפדפנים יודעים שהם לא אוהבים שעוקבים אחריהם, והם מיישמים באופן קבוע תכונות להגבלה של יצירה של טביעת אצבע דיגיטלית (fingerprinting) (חלק מהן ראינו במודול הקודם). כאן נסביר איך התכונות האלה עשויות להשפיע על העסק שלך הדרישות ואיך לבצע את הפעולות הרצויות תוך הגנה על הפרטיות. זה מידע נוסף על הגנת הדפדפן יצירה של טביעת אצבע דיגיטלית מול תשפיע על הפעולות שתעשו ואיך, ולא על האופן שבו היא תמנע מכם ליצור טביעת אצבע דיגיטלית (fingerprinting).
בפועל, לרוב המפתחים ולרוב העסקים אין צורך בטביעת אצבע על המשתמשים. אם המשתמשים נדרשים להיכנס לחשבון באפליקציה, המשתמשים מזהים את עצמם, בהסכמתם ובצורה שהם יכולים לבטל את ההסכמה שלהם באופן חד-צדדי בכל שלב. זוהי שיטה להגנה על הפרטיות שמאפשרת להבין אילו משתמשים מחוברים לחשבון. יכול להיות שהאפליקציה לא לדרוש מהמשתמשים להיכנס לחשבון, באופן שמגן עוד יותר על המשתמשים פרטיות (ולאחר מכן אתם אוספים רק את הנתונים הדרושים לכם).
מה מותר לעשות
רצוי לבדוק את הצדדים השלישיים בנוגע ליצירה של טביעת אצבע דיגיטלית (fingerprinting). כחלק מהמודול צדדים שלישיים, ייתכן שכבר יש לו רשימה של שירותי צד שלישי שאתה כולל ושל בקשות האינטרנט שהם שולחים. ייתכן כדי לבדוק את הבקשות האלה ולראות אילו נתונים מועברים חזרה אל היוצר, אם בכלל. עם זאת, לפעמים קשה לעשות זאת; יצירה של טביעת אצבע דיגיטלית היא תהליך סמוי שכרוך בבקשת נתונים שאינם כפופים לאישור המשתמש.
מומלץ גם לקרוא את מדיניות הפרטיות של שירותי צד שלישי ויחסי התלות שבהם אתם משתמשים כדי לאתר סימנים ליצירה של טביעת אצבע דיגיטלית (fingerprinting) בשימוש. המונח הזה נקרא לפעמים "התאמה הסתברותית", או כחלק מחבילה של טכניקות התאמה הסתברותיות, בניגוד ל"התאמה דטרמיניסטית".
איך פועלת יצירה של טביעת אצבע דיגיטלית
לעיתים קרובות השילוב האישי של כל המאפיינים האלה הוא ייחודי לכם, או בכתובת לפחות לקבוצה קטנה של אנשים דומים. כך אפשר לעקוב אחריכם בחשאי.
לצד: יצירה של טביעת אצבע דיגיטלית פסיבית ופעילה
יש כאן הבחנה שימושית בין שיטות פסיבית לפעילות טביעת אצבע דיגיטלית (fingerprinting). יצירה של טביעת אצבע פסיבית היא משתמשת במידע שניתן לאתר כברירת מחדל. שיטה פעילה של טביעת אצבע דיגיטלית היא שבודקת את הדפדפן במפורש לקבלת מידע נוסף. הסיבה שההבחנה הזו חשובה היא שדפדפנים יכול לנסות לזהות וליירט טכניקות פעילות, או לצמצם אותן. אפשר להגביל ממשקי API או לפתוח אותם מאחורי תיבת דו-שיח לבקש את רשות המשתמש (ולכן גם להציג התראה למשתמש על כך שמשתמשים בו, או לאפשר למשתמש לדחות אותו כברירת מחדל). שיטה פסיבית היא שיטה המשתמשת בנתונים שכבר סופקו לאתר, לעתים קרובות כי בעבר, בתחילת הדרך של כביש מהיר עם מידע, המידע הזה נמסר לכל האתרים. מחרוזת User-agent היא דוגמה לכך, ונבחן את הנושא לעומק. הוא נחשב שימושי למתן מידע על הדפדפן, הגרסה ומערכת ההפעלה של המשתמש, כדי שהאתר יוכל לבחור להציג אפשרויות אחרות על סמך זה. עם זאת, הפעולה הזו גם מגדילה את כמות המידע הייחודי שזמין, שעוזר לזהות משתמש אחד מול משתמש אחר; ולכן מידע כזה לא יהיה זמין יותר, או לפחות קפוא כך שכבר לא ניתן להבחין. אם הפעולה לביצוע מסתמך על המידע הזה, לדוגמה, קוד מסתעף בהתאם לסוכן המשתמש – הקוד הזה עלול להשתבש ככל שדפדפנים קופאים או מפסיקים לקבל את המידע הזה יותר ויותר. בדיקה היא ההגנה הטובה ביותר כאן ( ראו בהמשך).
מלבד: מדידה של טביעת אצבע דיגיטלית
המדד הטכני לכמות המידע שמספקת כל אחת מנקודות הנתונים האלה נקרא אנטרופיה והוא נמדד בביטים. תכונה שבה יש ערכים אפשריים רבים ושונים (כמו רשימת הגופנים המותקנים) יכולה לתרום הרבה ביטים לסכום הכולל, כאשר משהו שאין לו יכולת מובחנת (כמו מערכת ההפעלה שבה אתה משתמש) עלול רק להוסיף כמה מהם. אלמנך HTTP מתאר כיצד קיימת יצירה של טביעת אצבע דיגיטלית (fingerprinting) ספריות הופכות את התהליך הזה לאוטומטי, של שילוב התגובות מממשקי API שונים רבים ל"גיבוב", שעשוי לזהות קבוצה קטנה של משתמשים, אולי אפילו רק משתמש אחד. מוד נאלפס מכסה את הנושא הזה בפירוט בסרטון הזה ב-YouTube, אבל בקצרה, דמיינו שהייתם רואים רשימה של החברים שלך עם המוזיקה האהובה עליהם, האוכל האהוב עליהם והשפות שהם מדברים... אבל עם השמות שלהם הוסר. סביר להניח שכל רשימה של אדם אחד תזהה אותו באופן ייחודי בקרב החברים שלכם, או לפחות מצומצמת את הרשימה כך שיופיעו רק מעט אנשים. כך מתבצעת יצירה של טביעת אצבע דיגיטלית (fingerprinting): רשימת הדברים האהובים עליכם הופכת ל'גיבוב'. ב- את הגיבוב הזה, יהיה קל יותר לזהות משתמש כאותו אדם בשני אתרים שונים שאינם מחוברים, ולכן מעקב: כדי לעקוף את הרצון של המשתמש בפרטיות.
מה דפדפנים עושים נגד יצירה של טביעת אצבע דיגיטלית (fingerprinting)?
חשוב לציין שספקי דפדפנים מודעים לדרכים רבות ושונות לניהול אתר (או לצד שלישי כלשהו באתר) כדי לחשב טביעת אצבע ייחודית למשתמש או לקטעי מידע שונים שתורמים לייחודיות של טביעת האצבע הזו. חלק מהדרכים האלה מפורשות ומתכוון, כמו מחרוזת סוכן המשתמש של הדפדפן, שלרוב מזהה את הדפדפן, מערכת ההפעלה והגרסה שבהם נעשה שימוש (ולכן כך קל להבדיל בינך לבין המשתמש, אם אני משתמש בדפדפנים שונים). יש דרכים שלא נוצרות בכוונה כך שניתן יהיה להשתמש בהן בטביעת אצבע, אבל בסופו של דבר הן כאלו בכל מקרה, כמו רשימת הגופנים, או התקני וידאו ואודיו שזמינים לדפדפן. (הדפדפן לא חייב להשתמש את המכשירים האלה, פשוט צריך לקבל רשימה שלהם לפי שם). ויש כאלה שפועלים כתורמים ליצירת טביעות אצבע לאחר ההפצה, למשל רינדור פיקסלים מדויק של חיטוי גופנים ברכיב בד קנבס. יש עוד הרבה דרכים אחרות, וכל דרך שבה הדפדפן שלך שונה משלי מוסיפה אנטרופיה ולכן היא עשויה לתרום דרך להבחין ביניכם לבינך, ולזהות אדם מסוים באופן ייחודי ככל האפשר בכל האתרים. לכתובת https://amiunique.org יש רשימה ארוכה (אבל בהחלט לא מקיפה) של טביעות אצבע אפשריות שאפשר לתרום והרשימה ממשיכה לגדול כל הזמן (מכיוון שיש אינטרס כספי רב באפשרות לבצע טביעת אצבע דיגיטלית של משתמשים, גם אם המשתמשים לא רוצים את זה, או שאולי לא ציפיתם לזה).
אין תמיכה בממשקי API חזקים מסוימים
התגובה של ספקי הדפדפן לכל הגישות האלה לחישוב טביעת האצבע של משתמש היא למצוא דרכים לצמצם כמות האנטרופיה הזמינה מממשקי ה-API האלה. האפשרות המגבילה ביותר היא לא להטמיע אותן מלכתחילה. הדבר נעשה על ידי כמה דפדפנים מובילים עבור מגוון ממשקי API לחומרה ולמכשירים (כגון גישת NFC ו-Bluetooth דרך באפליקציות אינטרנט בצד הלקוח), כאשר הן מתייחסות ליצירה של טביעת אצבע דיגיטלית (fingerprinting) ולשמירה על הפרטיות כסיבות לכך. זאת, כמובן שהם יכולים להשפיע על האפליקציות והשירותים שלכם: אי אפשר להשתמש כלל בממשק API בדפדפן שאינו מיישם אותו, והדבר עלול להגביל או לחתוך לחלוטין גישות חומרה מסוימות מהשיקולים.
שער ההרשאות של המשתמש
גישה שנייה של ספקי דפדפנים היא למנוע גישה ל-API או לנתונים ללא הרשאה מפורשת כלשהי מהמשתמש. גישה זו נוקטת גם מטעמי אבטחה בדרך כלל — אסור שהאתר יצלם תמונות עם מצלמת האינטרנט שלך. ללא רשותכם! אבל כאן, לפרטיות ולאבטחה יכולים להיות תחומי עניין דומים. זיהוי המיקום של מישהו הוא בפני עצמה, כמובן, יש הפרה של הפרטיות, אבל היא גם תורמת לייחודיות של טביעת האצבע. נדרשת הרשאה לראות את המיקום הגיאוגרפי לא מפחית את האנטרופיה הנוספת שמיקום מוסיף לייחודיות של אותה טביעת אצבע, אלא למעשה היא מבטלת שימוש במיקום גיאוגרפי ליצירה של טביעת אצבע דיגיטלית (fingerprinting) כי התהליך הזה כבר לא נראה בלתי נראה. כל המטרה של יצירה של טביעת אצבע דיגיטלית (fingerprinting) היא לאפשר הבחנה בסודיות בין המשתמשים. אם אתם מוכנים שהמשתמש יידע אתם מנסים לזהות אותם, אז לא צריך שיטות ליצירה של טביעת אצבע דיגיטלית (fingerprinting): בקשו מהמשתמש ליצור חשבון ולהתחבר איתו.
הוספת בלתי חזויות
גישה שלישית שננקטת במקרים מסוימים היא עבור ספקי דפדפנים כדי "fuzz" את התגובות מממשקי API כדי שיהיו פחות מפורטים
ולכן יהיו פחות מזהים. הוא תואר כחלק ממנגנון התגובות האקראיות במודול הנתונים כמשהו
שאפשר לעשות בזמן איסוף נתונים ממשתמשים, כדי להימנע מאיסוף לא מכוון של נתונים שמאפשרים זיהוי. ספקי דפדפנים
יכולה לנקוט גישה זו לגבי נתוני API הזמינים גם לאפליקציות אינטרנט ולצדדים שלישיים. דוגמה לכך היא
ממשקי API לתזמון מדויקים מאוד שמשמשים למדידת ביצועי דפים
החל מ-window.performance.now()
. הדפדפן יודע את הערכים האלה
אבל הערכים המוחזרים מצטמצמים בצורה מכוונת על ידי עיגול למרחק של 20 המיקרו-שנייה הקרובה ביותר.
כדי להימנע משימוש בהם ליצירה של טביעת אצבע דיגיטלית (fingerprinting), וגם לצורך אבטחה, על מנת למנוע תזמון של התקפות. המטרה כאן היא
כדי להבטיח שממשקי ה-API ימשיכו להיות שימושיים, אבל כדי שהתשובות יהיו פחות מזהות: במהותן, לספק "חסינות עדר". על ידי יצירת
שהמכשיר שלך דומה יותר למכשיר של כל אחד אחר במקום שהוא ייחודי לך. 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. כך אפשר לבדוק אם צדדים שלישיים שכלולים בשירות שלך משתמשים בנתונים שניתן טביעת אצבע, או אם השירות שלך תלוי שם. לאחר מכן תוכלו לבדוק אם האפקט המכוון מקשה על ביצוע הפעולה הרצויה. אולי כדאי ליצור תיקונים בהתאם כדי להשיג את הנתונים האלה ממקור אחר, לעשות בלעדיו או להשתמש בנתונים פחות מפורטים.
- כמו שהסברנו קודם במודול של צדדים שלישיים, חשוב גם לבדוק את הנתונים של צדדים שלישיים
יחסיים כדי לבדוק אם הם משתמשים בשיטות של טביעת אצבע דיגיטלית. קשה לזהות טביעת אצבע פסיבית
זו אינה אפשרית אם צד שלישי עושה זאת בשרת שלו), אבל מצב יצירה של טביעת אצבע דיגיטלית עשוי לסמן טכניקות מסוימות של יצירה של טביעת אצבע דיגיטלית (fingerprinting),
וחיפוש שימושים ב-navigator.userAgent או יצירה לא צפויה של אובייקטים של
<canvas>
עשויה גם לגלות גישות מסוימות שצריך לבחון אותם לעומק. כדאי גם לחפש שימושים במונח "התאמה הסתברותית" בשיווק חומר טכני שמתאר צד שלישי, מצב כזה יכול לפעמים להעיד על שימוש בשיטות של טביעת אצבע דיגיטלית (fingerprinting).
כלי בדיקה חוצי-דפדפנים
קשה לבצע אוטומציה של הקוד שלכם למטרות פרטיות, והדברים שצריך לחפש באופן ידני מתוארים קודם. לדוגמה, מה קורה כשדוחים את ההרשאה של האתר לממשקי API שאליו הוא מנסה לגשת, ואיך היא מוצגת למשתמש? בדיקה אוטומטית לא יכולה לקבוע אם האתר פועל במטרה לעזור למשתמש לסמוך עליו, או להיפך, כדי לעודד את המשתמש לתת בו אמון. או לחשוב שמשהו מוסתר.
עם זאת, לאחר שהאתר נבדק, הבדיקה של ממשקי ה-API מוודאת ששום דבר לא פגום בגרסאות חדשות יותר של דפדפנים (או "בטא" בקרוב ו-preview יכולות להיות אוטומטיות, וברובו הן חלק מחבילת הבדיקות הקיימת. משהו כדי לקחת בחשבון את כלי הבדיקה האוטומטיים, כשעובדים עם כיסוי של פלטפורמות 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, דפדפן שהושק באותו זמן שבו האסטרונאוטים הראשונים עלה על תחנת החלל הבינלאומית לפני יותר משני עשורים. מחרוזת User-agent היא מקור עשיר של אנטרופיה ליצירה של טביעת אצבע דיגיטלית (fingerprinting), כמובן, וכדי לצמצם את האפשרות של טביעת אצבע דיגיטלית, יצרני הדפדפנים כבר הקפאו את כותרת סוכן המשתמש או פועלים בעשייה הזו. זו דוגמה נוספת לשינוי הנתונים ש-API מספק בלי בהכרח הסרה מלאה של ה-API. שליחת כותרת ריקה של סוכן משתמש תגרום להשבתה של אינספור אתרים שמניחים שהיא קיימת. באופן כללי, מה שדפדפנים עושים הוא מסיר חלק מהפרטים ממנו, ולאחר מכן להשאיר אותו ללא שינוי בעיקר. (אפשר לראות את התהליך הזה ב Safari, Chrome, ו-Firefox). ההגנה הזו מפני המשמעות של טביעת אצבע מפורטת היא למעשה שאי אפשר יותר להסתמך על כך שכותרת הסוכן המשתמש תהיה מדויקת יותר, לכן חשוב למצוא מקורות נתונים חלופיים.
לשם הבהרה, הנתונים בסוכן המשתמש לא נעלמים לגמרי, אבל הם זמינים ברמת פירוט נמוכה יותר, או שלפעמים לא מדויקים, כי ייתכן שידווח מספר ישן יותר שלא משתנה. לדוגמה, אותיות רישיות ב-Firefox, Safari ו-Chrome מספר הגרסה המדווחת של macOS הוא 10 (מידע נוסף זמין במאמר עדכון לגבי צמצום מחרוזת סוכן המשתמש. דיון נוסף). הפרטים המדויקים על האופן שבו Chrome מתכנן לצמצם את הנתונים במחרוזת הסוכן המשתמש זמינים במאמר הפחתה בסוכן המשתמש אבל, בקיצור, ניתן לצפות שמספר גרסת הדפדפן המדווחת יכיל רק גרסה ראשית (כך שמספר הגרסה) תיראה כמו 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, אבל כל השאר קפוא. לכן, גרסה 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-casessummarses חלק מהטענות והסיבות לשינוי, ולרואן מירווד יש מצגת באסטרטגיות מסוימות של הפסקת השימוש בסוכן המשתמש כדי להבדיל ביניהן, בהקשר של הצעת הרמזים של לקוחות UA כפי שמוסבר בהמשך.
מטושטש
Fuzzing הוא מונח משיטות האבטחה, שבו ממשקי API מופעלים עם ערכים לא צפויים בתקווה שהם מטפלים בהם
ערכים לא צפויים ולחשוף בעיית אבטחה. מפתחי אתרים צריכים להכיר את הנושא של כתיבת סקריפטים באתרים שונים (XSS).
שכרוך בהוספת סקריפט זדוני לדף, לעתים קרובות מכיוון שהדף אינו מסמן כראוי את ה-HTML שהוחדר (לכן יש לבצע שאילתת חיפוש)
שכולל את הטקסט <script>
). מפתחי קצה עורפי יהיו מודעים להחדרת SQL,
כאשר שאילתות מסדי נתונים שלא מאמתות כראוי את קלט המשתמש חושפות בעיות אבטחה (כפי שממחיש בעיקר ב-xkcd
Little Woby Tables). Fuzzing, או fuzz Testing, מתאים יותר לשימוש.
שמשמש לניסיונות אוטומטיים לספק ל-API מגוון רחב של קלטים לא חוקיים או לא צפויים, ולבדיקת התוצאות לאיתור דליפות אבטחה,
תאונות או טיפול לא תקין אחר. כל הדוגמאות האלה הן למתן מידע לא מדויק במכוון. כאן עושים את זה
מראש על ידי דפדפנים (על ידי שגיאה בסוכן המשתמש באופן מכוון), כדי לעודד מפתחים להפסיק להסתמך על הנתונים האלה.
מה מותר לעשות
- צריך לבדוק אם ה-codebase מסתמך על מחרוזת סוכן המשתמש (חיפוש של
navigator.userAgent
צפוי למצוא את רוב המופעים בקוד בצד הלקוח, וסביר להניח שהקוד העורפי יחפש אתUser-Agent
ככותרת), כולל של יחסי התלות. - אם מצאת שימושים בקוד שלך, עליך לבדוק מה הקוד מחפש ולמצוא דרך אחרת ליצור את ההבחנה הזו (או למצוא תלות חלופית, או לעבוד עם ה-upstream של התלות על ידי דיווח על בעיות או בדיקה אם יש עדכונים). לפעמים נדרשת הבחנה בין דפדפנים כדי לעקוף באגים, אבל סוכן המשתמש יהפוך יותר ויותר לא הדרך לעשות זאת לאחר הקפאת הדפדפן.
- יכול להיות שאתם בטוחים. אם אתם משתמשים רק בערכי הליבה של המותג, הגרסה הראשית והפלטפורמה, סביר להניח שהם עדיין זמין ולהיות נכונים במחרוזת ה-user-agent.
- MDN מתאר דרכים טובות להימנע מהסתמכות על מחרוזת סוכן המשתמש ("browser sniffing"), העיקרי הוא זיהוי תכונות.
- אם אתם מסתמכים בצורה מסוימת על מחרוזת ה-user-agent (גם אם אתם משתמשים בערכי הליבה היחידים שנשארים שימושיים), מומלץ להשתמש לבדוק עם סוכני משתמש קרובים שיהיו בגרסאות חדשות של הדפדפן. אפשר לבצע בדיקה בדפדפנים הבאים את הגרסאות עצמן באמצעות גרסאות בטא או גרסאות build של טכנולוגיה, אבל אפשר גם להגדיר מחרוזת סוכן משתמש מותאמת אישית בדיקה. אפשר לשנות את מחרוזת סוכן המשתמש ב-Chrome, Edge, Firefox, וגם Safari, במהלך פיתוח מקומי, כדי לבדוק איך הקוד מתמודד עם ערכים שונים של סוכן משתמש שתוכלו לקבל מהמשתמשים.
רמזים ללקוחות
אחת ההצעות העיקריות לספק את המידע הזה היא רמזים ללקוחות של סוכן משתמש.
למרות שהדבר אינו נתמך בכל הדפדפנים. דפדפנים שנתמכים יעבירו שלוש כותרות: 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
}