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

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

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

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

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

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

למה אנחנו צריכים לצמצם את השימוש ב-UA וב-UA-CH?

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

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

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

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

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

איך פועל הצמצום של UA ו-UA-CH?

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

משתמש פותח את הדפדפן ומזין את 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

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

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

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

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

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

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

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

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

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

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

תמיכה ברמזים ללקוח וברמזים קריטיים

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

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

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

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

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

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

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 עם אנטרופיה גבוהה בבקשות CORS, ללא קשר לאופן שבו המקור מוגדר בצד ה-DNS. צריך לטפל בהענקת הגישה באמצעות Permissions-Policy לכל משאב משני חוצה-מקורות, או לקבל אותה באמצעות JavaScript שמופעל בהקשר חוצה-מקורות.

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

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

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

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

השתתפות ושיתוף משוב

למידע נוסף