מהו צמצום של סוכן משתמש?

הפחתת המידע של סוכן המשתמש (UA) מפחיתה את כמות המידע המזהה שמשותף במחרוזת של סוכן המשתמש, שעשוי לשמש ליצירת טביעת אצבע פסיבית. עכשיו, אחרי שהשינויים האלה הושקו לכלל המשתמשים, לכל בקשות המשאבים יש כותרת User-Agent מוקטנת. כתוצאה מכך, ערכים שמוחזרים מממשקי Navigator מסוימים מצטמצמים, כולל: navigator.userAgent,‏ navigator.appVersion ו-navigator.platform.

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

רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש (UA-CH)

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

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

למה צריך את UA המופחת ואת UA-CH?

בעבר, מחרוזת סוכן המשתמש הייתה משדרת מחרוזת גדולה של נתונים על הדפדפן, מערכת ההפעלה והגרסה של המשתמש בכל בקשת HTTP. הבעיה הזו נבעה משתי סיבות:

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

הגרסאות המוקטנות של UA ו-UA-CH משפרות את פרטיות המשתמשים על ידי שיתוף רק מידע בסיסי כברירת מחדל.

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

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

איך פועלים UA ו-UA-CH המוקטנים?

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

משתמש פותח את הדפדפן ומקליד example.com בסרגל הכתובות:

  1. הדפדפן שולח בקשה לטעינה של דף האינטרנט.

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

זיהוי מכשירים מסוג טאבלט באמצעות UA-CH API

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

עם זאת, המידע שסופק על ידי הדפדפן גם למחרוזת 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

או בממשק JavaScript המקביל:

  • דפוס הטלפון: 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 כדי לקרוא את דגם המכשיר, את גרסת הפלטפורמה או את גרסת הדפדפן המלאה, תצטרכו להטמיע את UA-CH API.

אחרי העדכון ל-UA-CH API, כדאי לבדוק שאתם מקבלים את הנתונים הצפויים מה-User-Agent. יש שלוש דרכים לבצע בדיקה, והן הולכות ונעשות מורכבות יותר.

זמינות מותאמת של קיצור סוכן המשתמש פירושה ששרשור ה-UA המקוצר לגמרי נשלח לכל מכשירי Chrome. התכונה הזו הופחתה בגרסה משנית של Chrome שפורסמה ברבעון השני של שנת 2022.

בדיקה מקומית של מחרוזות בהתאמה אישית

אם רוצים לבדוק את האתר באמצעות מחרוזות User-Agent בהתאמה אישית כדי לדמות מכשירי שונים, מריצים את Chrome עם הדגל --user-agent="Custom string here" בשורת הפקודה. מידע נוסף על התרעות לגבי שורת פקודה

לחלופין, אפשר להשתמש באמולטור המכשיר בכלי הפיתוח ל-Chrome.

טרנספורמציה של המחרוזת בקוד של האתר

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

תמיכה ב-Client Hints וב-hints קריטיים

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

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

אופטימיזציה של טיפים קריטיים

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

תרשים רצף של רמזים על הלקוח (Client Hints) עם רמזים קריטיים.
כשהשרת מבקש רמז קריטי, הלקוח ינסה שוב לשלוח את הבקשה הראשונה לדף האינטרנט עם הרמז הקריטי. בדוגמה הזו, הבקשה להצעה ל-Sec-CH-UA-Model נשלחת פעמיים: פעם אחת כ'הצעה ללקוח' עם Accept-CH ופעם נוספת כ'הצעה קריטית' עם Critical-CH.

כדי לבצע אופטימיזציה של רמזים קריטיים (כותרת Critical-CH), צריך ליירט את לחיצת היד הזו ולספק מודל ל-Client Hints. השלבים האלה עשויים להיות מורכבים ודורשים ידע מתקדם.

הפריימים של ACCEPT_CH HTTP/2 ו-HTTP/3, בשילוב עם התוסף TLS ALPS, הם אופטימיזציה ברמת החיבור שמאפשרת להעביר את ההעדפות של הלקוח לגבי הנחיות לשרת בזמן לבקשת ה-HTTP הראשונה. כדי להשתמש בהן נדרשת הגדרה מורכבת, ומומלץ להשתמש בהן רק למידע קריטי באמת.

‏BoringSSL (הסתעפות של OpenSSL) עוזר לכם לעבוד עם התכונות הניסיוניות של Google ב-Chromium. בשלב זה, ALPS מוטמע רק ב-BoringSSL.

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

שאלות נפוצות

למשך כמה זמן יישלחו רמזים שצוינו באמצעות הכותרת Accept-CH?

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

האם UA-CH פועל עם HTTP/2 ו-HTTP/3?

UA-CH פועל עם חיבורי HTTP/2 וגם עם חיבורי HTTP/3.

האם תת-דומיינים (ו-CNAME) דורשים דף ברמה העליונה Permissions-Policy כדי לגשת ל-UA-CH עם ערך אנטרופי גבוה?

כותרות UA-CH עם ערכי אנטרופיה גבוהים בבקשות מוגבלות בבקשות ממקורות שונים, ללא קשר לאופן שבו המקור מוגדר בצד ה-DNS. צריך לטפל בהענקת הגישה דרך Permissions-Policy לכל משאב משנה חוצה-מקורות, או לקבל אותה דרך JavaScript שפועל בהקשר חוצה-מקורות.

איך הפחתת סוכני משתמשים משפיעה על זיהוי בוטים?

השינוי של Chrome במחרוזת User-Agent שלו לא משפיע ישירות על המחרוזת User-Agent שבוט בוחר לשלוח.

בוטים יכולים לבחור לעדכן את המחרוזות שלהם כך שישקפו את המידע המופחת ש-Chrome שולח, אבל זו בחירה שלהם לגמרי. Chrome עדיין שולח את אותו פורמט של User-Agent, ורובוטים שמוסיפים מזהה משלהם בסוף המחרוזת של User-Agent ב-Chrome יכולים להמשיך לעשות זאת.

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

יצירת מעורבות ושיתוף משוב

למידע נוסף