בדיקה בסיוע Chrome

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

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

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

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

הצענו שני מצבים נפרדים:

• מצב א': החל מנובמבר 2023, ארגונים שבודקים את ממשקי ה-API של PS R&M יכולים להביע הסכמה לקבלת תוויות עקביות בקבוצת משנה של Chrome דפדפנים כדי לאפשר בדיקה מתואמת בין בודקים שונים.
• מצב ב': החל מ-4 בינואר 2024, קובצי Cookie של צד שלישי הושבתו ברחבי העולם בחלק מדפדפני Chrome.

כשמשביתים קובצי Cookie של צד שלישי במצב ב', הם נשארים מושבתים במהלך כל שלבי ההוצאה משימוש של קובצי Cookie של צד שלישי.

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

ניתן לגשת לתוויות באמצעות הערך הזמני Sec-Cookie-Deprecation הזמין מכותרת HTTP או מ-API של JavaScript. פרטים על ההטמעה זמינים במאמר תוויות גישה שמשתמשות בערך של Sec-Cookie-Deprecation .

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

מצב א': קבוצות דפדפנים מסומנות בתווית

ארגונים שייקחו חלק בבדיקה יוכלו להביע הסכמה לקבלת קבוצה קבועה של תוויות לקבוצת משנה של דפדפני Chrome, כדי לאפשר להם לבצע ניסויים מתואמים בטכנולוגיות פרסום שונות באותה קבוצה של דפדפנים. לדוגמה, אם דפדפן מסוים נכלל בקבוצת הניסוי label_only_3 (כפי שמוצג בטבלה הבאה), כל ספקי טכנולוגיות הפרסום המשתתפים יוכלו לראות את אותה תווית label_only_3 ולתאם בהתאם: להשתמש בממשקי ה-API של PS R&M, אבל להימנע משימוש בקובצי Cookie של צד שלישי. אנחנו מצפים מהמשתמשים בדף לוודא שהתוויות מועברות למשתמשים אחרים, כדי לאפשר ניסויים עקביים לאורך כל תהליך בחירת המודעות והמדידה.

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

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

המטרה היא ליצור קבוצות שמייצגות את התנועה הרגילה ב-Chrome. כלומר, קובצי ה-cookie של הצד השלישי וממשקי ה-API של PS R&M אמורים להיות זמינים, אבל חלק מהמשתמשים עשויים להשתמש בהגדרות או בתוספים כדי לשנות או להשבית תכונות.

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

אנחנו מתכננים לכלול 8.5% מהדפדפנים של Chrome Stable במצב א', וההצעה הראשונית שלנו מחלקת את האוכלוסייה הזו ל-9 קבוצות. קבוצות המשנה הקטנות יותר נועדו לאפשר לטכנאי הפרסום לשלב תוויות כדי ליצור ניסויים משלהם בגדלים שונים. הקבוצות לא חופפות.

חשוב לזכור שהתוויות control_1.* מיועדות לשימוש כ'קבוצת בקרה 1', כפי שמתואר בהנחיות של CMA לבדיקות בתעשייה. לכן, המשתתפים בבדיקה לא צריכים להשתמש ב-Topics API או להפעיל מכרזים של קהלים מוגנים עבור התנועה הזו. מאחר שהתוויות לא משפיעות על התנהגות הדפדפן, המשתתפים לא צריכים להעביר נושאים שנצפו או להפעיל מכרזים של קהל מוגן כשהם מזהים את תוויות הקבוצה control_1.*.

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

קבוצות הדפדפנים במצב א' label_only_ זמינות מאז נובמבר 2023. מצב א' control_1_* קבוצות זמין החל מ-4 בינואר 2024.

מצב ב': השבתה של 1% מקובצי ה-Cookie של צד שלישי

Chrome השבית קובצי Cookie של צד שלישי בכ-1% מהאפליקציות היציבות של Chrome מ-4 בינואר 2024 (וגם בגרסת פיתוח, Canary ובטא) במהלך הרבעון הרביעי של 2023). ארגונים שבודקים את ממשקי ה-API של PS R&M לא צריכים להצטרף למצב זה, מכיוון שהוא מוחל באופן אחיד על כל הדפדפן אוכלוסייתו. יכול להיות שחלק מתכונות האתר יושפעו אם עדיין לא הוחל פתרון חלופי באתר, כמו CHIPS או קבוצות של אתרים קשורים.

בנוסף, אנחנו מתכננים לספק חלק קטן מהתנועה במצב ב'. כולל ממשקי API של PS R&M מושבתים. ממשקי API אחרים כמו 'קבוצות של אתרים קשורים', CHIPS FedCM לא יושבת. אנחנו צופים ששילוב זה יעזור לך כדי לקבוע את רמת הביצועים הבסיסית לדפדפנים ללא קובצי Cookie של צד שלישי וללא ממשקי API של PS R&M.

כחלק ממודל B, אנחנו מספקים גם תוויות לדפדפנים שהושפעו. התוויות יהיו זמינות באותו זמן שבו ממשקי ה-API מושבתים. אנחנו הצעה לחלק את האוכלוסייה לשלוש קבוצות treatment_1.* כאשר קובצי cookie של צד שלישי מושבתים, אבל ממשקי API של PS R&M זמינים, קבוצה control_2 שבה גם קובצי Cookie של צד שלישי וגם ממשקי ה-API של PS R&M מושבת.

כדי לעזור בניפוי באגים בשילובים של Attribution Reporting API ו-Private Aggregation API, וכדי לעזור למשתתפי הבדיקה להבין טוב יותר את ההשפעה של הרעש, דוחות ניפוי הבאגים של ARA ודוחות ניפוי הבאגים של Private Aggregation עדיין יהיו זמינים לדפדפנים במצב B, כל עוד המשתמש לא חסם באופן מפורש קובצי Cookie של צד שלישי. דוחות על ניפוי באגים לא יהיו זמינים ב control_2, כי ממשקי API של PS R&M לא זמינים בפרוסה הזו. דוחות ניפוי באגים עדיין יוצאו משימוש בהדרגה, במקביל להפסקת השימוש בקובצי Cookie של צד שלישי.

• ב-Attribution Reporting API, מכיוון שקובצי cookie של צד שלישי מושבתים, המקור לדיווח לא יוכל כדי להגדיר את קובץ ה-cookie ar_debug וצריך להסתמך על הגדרת השדות של debug_key (בדוחות שיוך-הצלחה) ובשדות debug_reporting (לדוחות מפורטים כדי להביע הסכמה לקבלת דוחות על ניפוי באגים.
• ב-Private Aggregation API, מקור הדיווח צריך להיות מופעל על ידי קריאה enableDebugMode() כדי לקבוע את ההסכמה לקבלת דוחות על ניפוי באגים. חברות צריכות להמשיך להביא בחשבון את האופן שבו מחויבויות רגולטוריות עשויות לחול על שימוש ב-Attribution Reporting API ו-Private Aggregation API, כולל דוחות ניפוי באגים.

המצב A ממשיך לפעול, והקבוצות האלה נפרדות מהקבוצות של המצב A, כי משתמש יכול להיות במצב A, במצב B או בשום מצב. משתתפי הבדיקה צריכים להשתמש בתנועה control_1.* כקבוצת בקרה שמייצגת את המצב הקיים עם קובצי cookie של צד שלישי.

בנוסף, קובצי Cookie מוגבלים ל-20% מלקוחות Chrome Canary, פיתוח ובטא.

ההשפעה של הכללה באחת מזרועות הניסוי האלה תהיה זהה להשפעה של הכללה בגרסת ה-Stable המקבילה.

בדומה למצב A, אי אפשר להבטיח ש-PS R&M APIs יהיו זמינים, כי המשתמשים יכולים להשבית אותם דרך ההגדרות של פרטיות ואבטחה ב-Chrome. כמו כן, לא בטוח שקובצי cookie של צד שלישי יושבתו לכל חבר בקבוצה control_2, כי המשתמשים יכולים לגשת לממשק המשתמש של הדפדפן כדי לאפשר שימוש בקובצי cookie של צד שלישי באתר.

מעקב אחר ניסויים

חשוב לעקוב אחרי נפח התנועה היחסי של כל טיפול ותווית בקרה. ב-treatment_1.1 צריכה להיות כמות תנועה דומה לזו של treatment_1.2 ו-treatment_1.3.

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

תוויות לפני התקופה

עד ינואר 2024, הרצנו תקופות מקדימות בכמה זרועות ניסוי. המוצרים לפני התקופות מספר הפעמים שבהן ל-Chrome הייתה אפשרות להתאים את הגודל והבחירה באופן מדויק בקבוצות לא מוטות. תקופות הטרום האלה פעלו בכל הזרועות שתזמנתם להתחיל לפעול בינואר: זרועות המצב B וזרועות Control_1.*. אין צורך לפעולות של מפתחים או אתרים כאן – בזרועות טרום-התקופה האלה לא יחוו שינוי בהתנהגות או בזמינות של ה-API, אבל חשוב לדעת שייתכן שתראו הוחזרה תווית preperiod במצבים מסוימים. דפדפנים שמקבלים את התווית preperiod עשויים לעבור לאחת מקבוצות הניסוי, אבל אין ערובה לכך. לכן, מומלץ לא להניח שדפדפנים עם התווית הזו ייכללו בניסוי.

זרוע ניסוי היא קבוצת משנה של האוכלוסייה שנמצאת במחקר. כאן אחת מהקבוצות בעלות התווית.

גישה לתוויות באמצעות ערך ההוצאה משימוש של קובצי Sec-Cookie

למשך זמן הניסוי במצב A ובמצב B, הוספנו ערך Sec-Cookie-Deprecation זמני שאפשר לגשת אליו באמצעות כותרת HTTP להצטרפות ו-API של JavaScript. הערך הזה מספק את התווית לקבוצת הניסוי הרלוונטית של הדפדפן במצב A או במצב B (כפי שהוגדר באחוזים שלמעלה), אם הוא נכלל באחת מהן.

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

גישה לכותרת ה-HTTP Sec-Cookie-Deprecation

כדי לקבל את כותרת הבקשה Sec-Cookie-Deprecation, צריך קודם להגדיר אתר קובץ ה-cookie receive-cookie-deprecation. קובץ ה-cookie הזה חייב להשתמש במאפיין Partitioned, כלומר צריך להביע הסכמה לקבלת הכותרת לכל אתר ברמה העליונה.

לדוגמה, אם 3p-example.site רוצה לקבל את Sec-Cookie-Deprecation בכותרת המשאבים שלו שמוטמעים ב-example.com, אז 3p-example.site חייב את קובץ ה-Cookie הבא בהקשר הזה.

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

מאפייני קובצי ה-cookie Secure,‏ HttpOnly,‏ SameSite ו-Partitioned הם חובה. אפשר להגדיר את המאפיינים Domain,‏ Path,‏ Expires ו-Max-Age בהתאם לצרכים שלכם, אבל Path=/ הוא ערך ברירת מחדל טוב. בדוגמה הזו, הערך של Max-Age=15552000 מוגדר כך שתוקף קובץ ה-cookie יפוג רק אחרי 180 ימים.

מומלץ להתחיל להגדיר את קובץ ה-cookie receive-cookie-deprecation=1 לפני תחילת תקופת הבדיקה של Chrome, כדי לוודא שהדפדפנים בקבוצת הניסוי יכללו את כותרת הבקשה Sec-Cookie-Deprecation ברגע שהיא תהיה זמינה.

לדוגמה, בהנחה שהדפדפן נמצא בקבוצה example_label_1, בקשות שכוללות את קובץ ה-cookie הזה יכללו גם את Sec-Cookie-Deprecation הכותרת.

Sec-Cookie-Deprecation: example_label_1

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

גישה לממשק ה-API של JavaScript עבור cookieDeprecationLabel

אפשר לגשת לערך Sec-Cookie-Deprecation גם באמצעות navigator.cookieDeprecationLabel.getValue() JavaScript API. הפונקציה מחזירה הבטחה שמתקבלת ממנה מחרוזת שמכילה את תווית הקבוצה הרלוונטית. לדוגמה, אם הדפדפן היה בקבוצה example_label_1:

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

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

אפשר לקרוא ל-JavaScript API ללא קשר לנוכחות של קובץ ה-cookie receive-cookie-deprecation. עם זאת, אם קובצי cookie חסומים לחלוטין או באופן ספציפי עבור האתר, ה-API שוב לא יהיה זמין שתחזיר מחרוזת ריקה.

כמו בכל ערך שמסופק על ידי לקוח, חשוב לנקות ולאמת את הערך מהכותרת או מ-JavaScript API לפני השימוש בו.

הדגמה ובדיקה

החל מגרסה 120 של Chrome ואילך, יש סימונים זמינים להפעלת מפתחים מקומיים בדיקה של בקשה וקריאה של התוויות.

הדגל chrome://flags/#tpc-phase-out-facilitated-testing מאפשר להפעיל מבחר של תוויות בדיקה. התוויות האלה מתחילות ב-fake_ כדי להבדיל אותן מהתוויות האמיתיות. הפעלת הדגל לא תגרום להוספת הדפדפן לאף אחת מקבוצות הניסוי.

אפשר לראות את התוויות בפעולה בכתובת goo.gle/cft-demo.

מאחר שההרשמה נאכפת לממשקי ה-API למדידת הרלוונטיות ולמדידה של ארגז החול לפרטיות, יכול להיות שתצטרכו לבטל את האכיפה לצורך בדיקה מקומית באמצעות chrome://flags/#privacy-sandbox-enrollment-overrides ולספק את גרסת המקור לדמו. לחלופין, אם מפעילים את Chrome מסוף, צריך לכלול את הדגל הבא של שורת הפקודה: --args --disable-features=EnforcePrivacySandboxAttestations

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

כדי לבדוק רק תוויות של קבוצות ניסוי, צריך לבחור באפשרות 'בקרת אילוץ 1' מופעלת או "Enabled Force LabelOnly". בעקבות זאת הדפדפן ישלח את 'fake_control_1.1' או 'fake_label_only_1.1' תוויות.

ב-Chrome M120 ואילך אפשר גם להשתמש ברשומות הבאות.

כדי לבדוק את החסימה של קובצי Cookie של צד שלישי, בוחרים באפשרות 'הפעלת טיפול בכפייה'. הזה ישלח את הערך 'fake_treatment_1.1' של קבוצת הניסוי, אבל גם תשנה את דף ההגדרות של קובצי cookie וההגדרות הנוכחיות של קובצי cookie, לחסימת קובצי cookie של צד שלישי.

כדי לבדוק חסימת קובצי cookie של צד שלישי ללא ממשקי API של מודעות פרטיות, בוחרים באפשרות 'אילוץ שימוש' שליטה 2 אינץ'. הפעולה הזו תשלח את התווית של קבוצת הניסוי fake_control_2, תעדכן את דף הגדרות קובצי ה-cookie, תחסום קובצי cookie של צד שלישי ותשבית גם את ממשקי ה-API החדשים של מודעות פרטיות.

שימו לב: יש בעיה שבה הדפדפן יישאר עם דף ההגדרות החדש של קובצי ה-cookie וההגדרה שחוסמת קובצי cookie של צד שלישי, גם אם משביתים את הדגל. אנחנו פועלים לפתרון הבעיה, אבל בינתיים תוכלו לבדוק את ערכי הדגלים האלה בספריית נתונים נפרדת של Chrome. לשם כך, מריצים את Chrome עם הדגל --user-data-dir=<new dir> בשורת הפקודה.

משוב

אנחנו משתמשים בתווית chrome-testing במאגר התמיכה למפתחים ב-GitHub כדי לנהל את השאלות. נשמח לראות את המשוב שלך ואת הדיון לגבי השאלות הראשוניות:

• האם תכננת לבצע בדיקה במצב א', במצב ב' או בשניהם?
• בחירת גדלים של תוויות לבדיקות בעזרת Chrome
• שימוש ברמזים של לקוחות לבדיקה שמתבצעת באמצעות Chrome

אפשר גם פרסום שאלות או דיונים חדשים במאגר באמצעות 'בדיקה שמתבצעת באמצעות Chrome' תבנית.