בדיקה בסיוע Chrome

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

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

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

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

הצענו שני מצבים שונים:

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

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

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

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

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

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

תווית % מהתנועה היציבה
control_1.1 0.25
control_1.2 0.25
control_1.3 0.25
control_1.4 0.25
label_only_1 1.5
label_only_2 1.5
label_only_3 1.5
label_only_4 1.5
label_only_5 1.5

קבוצות דפדפנים במצב א' label_only_ זמינות מאז נובמבר 2023. קבוצות במצב א' control_1_* זמינות החל מ-4 בינואר 2024. אנחנו נמשיך לשלוח את כל התוויות של מצב א' ומצב ב' עד שנוציא משימוש את קובצי ה-cookie של צד שלישי בתחילת 2025.

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

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

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

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

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

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

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

תווית % מהתנועה היציבה
treatment_1.1 0.25
treatment_1.2 0.25
treatment_1.3 0.25
control_2 0.25

בנוסף, Chrome הגביל את השימוש בקובצי cookie ב-20% מלקוחות Chrome Canary, Dev ו-בטא.

תווית % מהתנועה במצב טרום-יציב
prestable_treatment_1 10%
prestable_control_2 10%

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

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

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

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

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

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

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

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

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

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

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

לגשת ל-cookieDeprecationLabel JavaScript API

אפשר לגשת לערך 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, ומאמתים אותו לפני השימוש.

הדגמה (דמו) ובדיקה

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

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

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

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

chrome://flags/#tpc-phase-out-facilitated-testing

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

כדי לבדוק רק תוויות של קבוצות ניסויים, צריך לבחור באפשרות Enabled Force Control 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 פרטיים, צריך לבחור באפשרות Force Control 2. הפעולה הזו תשלח את התווית של קבוצת הניסוי "fake_control_2", תעדכן את דף ההגדרות של קובצי ה-cookie, תחסום קובצי cookie של צד שלישי וגם תשבית את ממשקי ה-API החדשים של מודעות פרטיות.

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

משוב

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

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