דוח משוב – רבעון 4 של 2022

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

כחלק מההתחייבויות שלה ל-CMA, Google הסכימה לפרסם דוחות רבעוניים על תהליך המעורבות של בעלי העניין בהצעות שלה לארגז החול לפרטיות (ראו פיסקאות 12 ו-17(ג)(2) בהתחייבויות). דוחות הסיכום האלה של המשוב על ארגז החול לפרטיות נוצרים על ידי צבירת המשוב ש-Chrome מקבל מהמקורות השונים שמפורטים בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין בכתובת privacysandbox.com, פגישות עם בעלי עניין בתעשייה ופורומים של תקני אינטרנט. אנחנו ב-Chrome מקבלים בברכה את המשוב שאנחנו מקבלים מהסביבה העסקית, ומחפשים דרכים לשלב את הלקחים האלה בהחלטות העיצוב שלנו.

נושאי המשוב מדורגים לפי שכיחות לכל ממשק API. כדי לעשות זאת, אנחנו אוספים את כמות המשוב שקיבל צוות Chrome בנושא מסוים וממיינים אותו בסדר יורד לפי כמות. כדי לזהות את הנושאים הנפוצים של המשוב, בדקנו את נושאי הדיון בפגישות ציבוריות (W3C, ‏ PatCG,‏ IETF), משוב ישיר, GitHub ושאלות נפוצות שהופיעו בצוותים הפנימיים של Google ובטפסים ציבוריים.

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

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

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

CHIPS
קובצי Cookie עם חלוקה עצמאית למחיצות
DSP
פלטפורמה בצד הביקוש
FedCM
Federated Credential Management
FPS
קבוצות מאינטראקציה ישירה (First-Party Sets)
IAB
הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)
IDP
ספק זהויות
IETF
ארגון תקינה בנושאי האינטרנט (IETF)
קניין רוחני (IP)
כתובת פרוטוקול אינטרנט
openRTB
בידינג בזמן אמת
הארכה
גרסת מקור לניסיון
PatCG
קבוצת הקהילה של טכנולוגיית פרסום פרטית
RP
צד נסמך
SSP
פלטפורמה לספקים
TEE
סביבת מחשוב אמינה
UA
מחרוזת של סוכן משתמש
UA-CH
רמזים על הלקוח (Client Hints) לגבי סוכן משתמש
W3C
World Wide Web Consortium
WIPB
עיוורון מכוון של כתובות IP

משוב כללי, ללא API או טכנולוגיה ספציפיים

נושא המשוב סיכום תגובה מ-Chrome
(דיווח גם ברבעון השלישי)

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

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

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

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

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

כמו כן, קיבלנו מפתחים בשעות קבלה ציבוריות כדי לשתף שיטות מומלצות והדגמות, וגם קיבלנו שאלות ותשובות ממנהלי מוצרים ומנהלי הנדסה כדי לאפשר דיון או שאלות בזמן אמת.
Core Web Vitals איך זמן האחזור של ממשק ה-API של ארגז החול לפרטיות משפיע על מדדי הליבה לבדיקת חוויית המשתמש באתר? צמצום זמן האחזור הוא אחד מהיעדים העיקריים בתכנון של ממשקי ה-API של ארגז החול לפרטיות. ההערכה שלנו כרגע היא שלזמן האחזור של ממשקי ה-API תהיה השפעה מינימלית על המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) באתר, מאחר שרוב הקריאות ל-API מתבצעות אחרי העיבוד הראשוני של האתר. אנחנו ממשיכים לעקוב אחרי כל אחד מממשקי ה-API ולבצע שיפורים כדי לצמצם עוד יותר את זמן האחזור, וממליצים להמשיך בבדיקה ובשליחת משוב.

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

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

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

הצגת מודעות ותוכן רלוונטיים

נושאים

נושא המשוב סיכום תגובה מ-Chrome
ההשפעה על הדירוג בחיפוש Google פנייה לגבי השימוש בתמיכה של אתר ב-Topics API כאות פוטנציאלי לדירוג תוצאות החיפוש ב-Google בעלי אתרים מסוימים יכולים לבקש שלא להיכלל בבדיקה של Topics API. צוות ארגז החול לפרטיות לא תאם או ביקש מהארגון של חיפוש Google להשתמש בדירוג דפים כמַתג ממריץ לאתרים לאמץ את Topics API. Google אישרה ל-CMA שחיפוש Google לא ישתמש בהחלטה של אתר לבטל את ההסכמה לשימוש ב-Topics API כאות לדירוג.
מסווג נושאים הוספת כתובת URL ותוכן הדף בנוסף לשם המארח כדי לקבוע את הנושא של דף אינטרנט, במטרה לשפר את התועלת לבעלי עניין שונים. בשלב זה, היסטוריית הגלישה של משתמש מסוים מסווגת לפי שמות המארחים של האתרים שבהם הוא ביקר. אנחנו ב-Chrome ממשיכים לבדוק אפשרויות להביא בחשבון מטא-נתונים ברמת הדף (כמו כל הרכיבים או חלק מהרכיבים של כתובת ה-URL ו/או התוכן של הדף) בסיווג של Topics. צריך לשקול את כל השיפורים בתועלת מול הסיכונים לפרטיות ולשימוש לרעה.

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

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

כדי להסביר, לסיווג של Topics API יש שני רכיבים רלוונטיים: (1) רשימת שינוי ברירת המחדל שמכילה את 10,000 האתרים המובילים ואת הנושאים שלהם, ו-(2) מודל למידת מכונה במכשיר שמסווג שמות של מארחים לנושאים. הרחבת רשימת ההחרגות (1) מאפשרת לנו לשפר את הביצועים של הסיווג באזורים שבהם הביצועים של הסיווג עשויים להיות נמוכים.
תקופת זמן של שבוע אחד תקופת האפוקליפסה של שבוע אחת ארוכה מדי למשתמשים שרוצים לקבל החלטות לטווח קצר יותר. אנחנו בודקים באופן פעיל מה צריך להיות אורך תקופת האפוקליפסה, ונשמח לקבל משוב נוסף לגבי תקופת האפוקליפסה שתתאים יותר לסביבה העסקית.
אחזור של כותרות HTTP חשש לגבי חוסר מידע לגבי אחזור נושאים מכותרת HTTP אנחנו עובדים על כותרות ועל fetch(). מידע נוסף זמין כאן. הוספנו גם מידע על skipObservation למאמר.
הכלי 'נושאים' נועד לעזור רק למפרסמים, ולא למשתמשים נראה ש-Topics/ארגז החול לפרטיות הם גישה שמתמקדת בתעשייה. היתרונות למשתמשים לא ברורים כמו היתרונות לתעשייה. אנחנו מאמינים שהיתרון של Topics למשתמשים הוא תמיכה במודעות שמבוססות על תחומי עניין, שמאפשרות לשמור על האינטרנט פתוח וחינמי. אנחנו גם מאמינים ש-Topics משפר באופן משמעותי את הפרטיות בהשוואה לקובצי cookie של צד שלישי. הסרת קובצי cookie של צד שלישי ללא חלופות קיימות עלולה להשפיע לרעה על בעלי תוכן דיגיטלי, ולגרום לשימוש בשיטות גרועות יותר
שפחות שומרות על הפרטיות, לא שקופות ובאופן ריאלי לא ניתן לאפס אותן או לשלוט בהן על ידי המשתמשים. חברות רבות בודקות באופן פעיל את Topics API ואת ממשקי ה-API של ארגז החול, ואנחנו מחויבים לספק את הכלים שיעזרו לשפר את הפרטיות ולתמוך באינטרנט.


קבוצת הארכיטקטורה הטכנית של W3C פרסמה לאחרונה את העמדה הראשונית שלה לגבי Topics API, ואנחנו נגיב עליה באופן ציבורי. בשלב הזה, מאחר ש-Google קיבלה שאלות מהסביבה העסקית לגבי ההשלכות האפשריות של הבדיקה הזו על הפיתוח וההשקה של Topics API, אנחנו רוצים לאשר מחדש את התוכנית שלנו להפוך אותו לזמין בגרסת Chrome היציבה השנה. Google מעריכה את המשוב של קבוצת הארכיטקטורה הטכנית של W3C, אבל היא רואה חשיבות עליונה בהמשך המאמצים לפיתוח ובדיקה של Topics, תוך התייעצות עם CMA ועם הסביבה העסקית.
דליפת נתונים חשש שנתוני Topics עשויים לדלוף לאתרים אחרים ללא רשות עיצוב Topics API מקטין מאוד את הסבירות לדליפת נתונים מבעל תוכן דיגיטלי יחיד (ואפילו מקבוצה קטנה יותר של בעלי תוכן דיגיטלי) בכל צורה שהיא. בעלי האתרים גם שולטים באופן מלא ב-Topics API, והם יכולים לאסור גישה ל-API הזה באמצעות מדיניות ההרשאות.
חוסר במפרסמים לצורך בדיקה בעלי תוכן דיגיטלי מודאגים מכך שהם לא יכולים כרגע להוכיח למפרסמים את הערך של Topics. במחצית השנייה של 2023, אנחנו מתכננים להפוך את כל ממשקי ה-API שקשורים למודעות לזמינים לבדיקה של שילוב, ולאפשר ניתוח של הסביבה העסקית כדי להבין את הערך של Topics למפרסמים. ה-CMA ינהל את הבדיקה ואת פרסום התוצאות, וגם יבדוק את הנתונים, הניתוח והשיטה. אנחנו מעודדים את הסביבה העסקית לשתף משוב עם Google ועם CMA.
Topics ו-FLEDGE בקשה למידע נוסף על השימוש ב-Topics בתוך הלוגיקה של הבידינג ב-FLEDGE אפשר להשתמש בנושאים בלוגיקת הבידינג של FLEDGE. אנחנו גם עובדים על מדריך לשילוב, שיכלול פרטים נוספים על ההטמעה.
דירוג מותאם אישית של מבצע הקריאה לנושאים לאפשר התאמה אישית של הדירוגים לפי מבצע הקריאה האתגר שקשור לדירוג או לערכים מותאמים אישית של נושאים לכל פתרון טכנולוגי למודעות הוא שזה עלול להפוך למנגנון שבו פתרון טכנולוגי למודעות יכול להשפיע על הנושאים שמוחזרים, ולכן הוא יכול לשמש כוקטור ליצירת טביעת אצבע.
רשימת העדיפויות של מתקשרים בנושאים מאפשרת למבצעי הקריאה להציג רשימת נושאים לפי דירוג עדיפות, ש-Topics API יחזיר על סמך הזכאות. אנחנו ממשיכים לדון ברעיון הזה ומקבלים בברכה משוב נוסף.

FLEDGE

נושא המשוב סיכום תגובה מ-Chrome
Google Ad Manager חשש שמערכת Google Ad Manager היא הגורם הקובע לגבי מכרזי FLEDGE, ותעדיף את Google Publisher Tags ו-Google Ad Manager. FLEDGE מאפשר לכל בעל תוכן דיגיטלי לבחור את המבנה של המכרז, כולל הבחירה של מוכרים ברמה העליונה ושל מוכרי רכיבים. כל קונה ומוכר במכרז רכישת רכיבים יודעים מי המוכר ברמה העליונה, ויכולים לבחור אם להגיש הצעת מחיר או לא.
אין מספיק משתתפים בבדיקה של FLEDGE בקשה לעודד יותר חברות לבדוק את FLEDGE, למשל על ידי שיפור הפונקציונליות של ה-API והרתעה מפני חלופות שמפרות את הפרטיות, כמו טביעת אצבע אנחנו ממשיכים בפיתוח ארגז החול לפרטיות בשלבים, בשיתוף פעולה הדוק עם ה-CMA וה-ICO, ובדיקות הפונקציונליות של FLEDGE הוכיחו את היציבות והיכולות הנדרשות. Google ממשיכה לעודד את סביבת הפרסום לבדוק את ממשקי ה-API של ארגז החול. לאחרונה פרסמנו את המסמך Maximize Ad Relevance (הגדלת הרלוונטיות של המודעות) כדי להראות איך FLEDGE וממשקי API אחרים יכולים לעזור לתמוך בתרחישי שימוש קריטיים בתעשיית הפרסום אחרי ההוצאה משימוש של קובצי cookie של צד שלישי.

חלקים אחרים של ארגז החול לפרטיות כבר תומכים באמצעי מיטיגציה שמיועדים למעקב (ראו UA-CH, ‏ הגנה על כתובות IP ואמצעי מיטיגציה למעקב אחר נטישות), והם ימשיכו להשתפר עם הזמן. המטרה של Google היא לא להפוך את FLEDGE לפתרון הטירגוט היחיד שאפשר להשתמש בו, אלא להמשיך לפעול בשיתוף עם גורמים בתעשייה ועם רשויות רגולטוריות כדי לפתח את טכנולוגיות הפרסום הטובות ביותר לשמירה על הפרטיות בדפדפן Chrome.
תרחישים לדוגמה של למידת מכונה הדרכה נוספת על תרחישים לדוגמה של למידת מכונה לאימון אלגוריתמים של בידינג במכרזים שתהיה תמיכה בהם ב-FLEDGE ובדיווח על שיוך אנחנו מבינים את הצורך לעזור למפתחים למצוא את הדרכים השימושיות ביותר להטמיע את הטכנולוגיות של ארגז החול לפרטיות. התחלנו לפרסם הנחיות שקשורות באופן ספציפי לשימוש בהיבטים השונים של ממשקי ה-API של ארגז החול לפרטיות כקלט ללמידת מכונה. במאמר האחרון, הגדלת הרלוונטיות של המודעות, מוסבר איך תעשיית הפרסום יכולה להשתמש באותות האלה לצורך למידת מכונה. אנחנו מתכננים להמשיך לפרסם הנחיות כאלה בעתיד.
שליחת שאילתות לשרת של FLEDGE Key Value (K/V) למה אפשר לשלוח שאילתות לשרת ה-K/V באופן ציבורי? מטרת שרת ה-K/V היא לספק אותות בזמן אמת למכרזי FLEDGE. לכן, צריכה להיות גישה לשרת ה-K/V מהמקום שבו מתבצעים מכרזי FLEDGE, כלומר במכשירי המשתמשים, ולכן הוא צריך להיות זמין לכולם. רק צד שכבר יש לו את המפתח יכול לאחזר ערך שנשמר בשרת ה-K/V. לכן, אם חברת טכנולוגיית פרסום מעבירה את המפתחות רק לדפדפנים שנמצאים בקבוצת העניין, ולא משתמשת במפתחות שאפשר לנחש באופן אקראי, רק דפדפנים שזקוקים לערך כדי להפעיל את המכרז יוכלו לאחזר אותו.
איך מגדירים טירגוט לפי תאריך ושעה? תמיכה באובייקטים של תאריכים בפונקציית הלוגיקה של הבידינג. יש כמה דרכים לעשות את זה. קונים יכולים לבקש מהמוכר שלהם לספק את התאריך והשעה הנוכחיים, ומוכרים אמורים לספק את המידע הזה בקלות לכל הקונים. הקונים יכולים גם לספק את התאריך והשעה בתשובה שלהם בזמן אמת עם מפתח/ערך. לבסוף, הקונים יכולים לספק את התאריך והשעה כחלק מהתגובה ההקשרית שלהם באותות לכל קונה, שהמוכר יכול להעביר לסקריפט generateBid של הקונה.
העדפות משתמש היכולת של המשתמשים לבחור לחסום נכסי קריאייטיב לפי מפרסם כשהם מוצגים דרך FLEDGE, או פתרונות חלופיים. המשתמשים יכולים לבטל את ההסכמה לשימוש בממשקי API של Google Ads ב-Chrome. במודעות ספציפיות, חברת טכנולוגיית הפרסום הרלוונטית היא הגורם שהכי מתאים להציע אמצעי בקרה על הקריאייטיב שיוצג או על האופן שבו הוא נבחר.
צירי זמן ברורים יותר בקשה למידע נוסף על הזמינות של אמצעי הגנה על הפרטיות ב-FLEDGE, כמו דרישה לשימוש ב-Fenced Frames. אנחנו מתכננים לפרסם לוחות זמנים מפורטים יותר ברבעון הראשון.
דיווח על בלבול בקשה להבהרה לגבי האופן שבו דיווח FLEDGE יפעל עם ממשקי API אחרים, כמו Fenced Frames ו-Private Aggregation API. בשבועות הקרובים אנחנו מתכננים לפרסם הסבר על האינטראקציה בין Private Aggregation API,‏ FLEDGE ו-Fenced Frames.
בידינג בזמן אמת ו-FLEDGE הנחיות לגבי השילוב של FLEDGE עם בידינג סטנדרטי בזמן אמת. שני הגורמים העיקריים שמקשים על טכנולוגיות הפרסום לבצע בידינג בזמן אמת הם גישה לנתונים ברמת האירוע ושילוב קל יותר ב-ARA. אנחנו מתכננים לשלוח עדכונים והסברים לגבי שני הנושאים האלה ברבעון הראשון.
הביצועים של מכרזי FLEDGE דיווח של בודקים על זמן אחזור ארוך במכרזים של FLEDGE אנחנו מעריכים את הדוחות של הבדיקות, שבהם משתפים את התוצאות ותרחישי השימוש, ושיתפנו כמה הצעות לשיפור הביצועים של FLEDGE.

במקביל, הוספנו כלים לדפדפן שמאפשרים למפתחים לאבחן טוב יותר את הגורמים לזמן האחזור הארוך במכרזים, ופעלנו באופן שיטתי כדי לטפל במקורות העיקריים של זמן האחזור שנצפה. השיפורים האחרונים כוללים זמן קצוב לתפוגה למכרזים איטיים, שיטת סינון מהירה של בידינג, דרך לשימוש חוזר ב-worklets של FLEDGE כדי להימנע מתשלום על עלויות הפעלה ועבודה מתמשכת כדי לאפשר לבקשת המודעה לפי הקשר לפעול במקביל לזמן ההפעלה של FLEDGE ולאחזור הנתונים מהרשת. אנחנו צופים שהאופטימיזציה של זמן האחזור תמשיך להתבצע כתוצאה מהשיחה המתמשכת בין מפתחי Chrome לבין בודקי FLEDGE, על סמך הניסיון שלהם בשימוש בממשק ה-API בעולם האמיתי.
מגבלת הזיכרון של קבוצות העניין בקשה להגדלת המגבלה על הגודל של קבוצת תחומי עניין אחת מ-50KB. אנחנו בוחנים את הבקשה ומחפשים משוב לגבי ערך המגבלה שמתאים.
שילוב של הנתונים שמוצגים ב-FLEDGE עם קובץ cookie מאינטראקציה ישירה (First-Party) האם FLEDGE יתמוך בשילוב עם נתונים מאינטראקציה ישירה (First-Party) של מפרסם? FLEDGE נוצר כדי לתמוך בפרסום באמצעות הנתונים מאינטראקציה ישירה (First-Party) שכבר יש למפרסם. עם זאת, FLEDGE לא נועד לתמוך במפרסם שרוצה ללמוד על התנהגות הגלישה של אדם כלשהו באתר כלשהו מלבד האתר שלו. צירוף התנהגות הגלישה מחוץ לאתר לנתונים מאינטראקציה ישירה (First-Party) מנוגד למטרות של ארגז החול לפרטיות.

בשבועות הקרובים נשתף מדריכים לשילוב עם פרטים נוספים על האופן שבו FLEDGE תתמוך בשילוב עם נתונים מאינטראקציה ישירה (First-Party).
ערך של אנונימיות מסוג k איך יתקבל ההחלטה לגבי הערך 'K' ל-'k-anon', והאם הוא יפורסם? הערך של 'K' עדיין לא סופי, ונשתף מידע נוסף ככל שהתוכניות שלנו יתקדמו. אנחנו רוצים לדעת איך ערך k לא ידוע עלול לפגוע בהכנה ל-FLEDGE ובהיקף האימון של מודל ה-ML, ונשמח לקבל משוב נוסף בנושא הזה.
תמיכה במספר ספקי SSP איך תהיה תמיכה בכמה ספקי SSP ב-FLEDGE? FLEDGE תומך במכרזים עם כמה מוכרים, כפי שצוין בהצעה הזו.
החשיפה של לוגיק הבידינג חשש שלוגיקה של בידינג ב-DSP תהיה חשופה ב-JavaScript לפי הלוגיקה הנוכחית של בידינג לפי עיצוב, אחרים יכולים לגשת ל-JavaScript, אבל אנחנו מקבלים בברכה משוב נוסף לגבי הסיבות לכך שזה יכול להוות מקור לדאגה עבור פלטפורמות ניהול מודעות.
prebid.js מהו לוח הזמנים לתמיכה ב-prebid.js ב-FLEDGE? רק גרסאות 7.14 ואילך של Prebid.js תומכות במודול FLEDGE. בעלי תוכן דיגיטלי שרוצים להשתתף בבדיקה צריכים להוסיף את מודול FLEDGE ולשדרג את מכונה של Prebid.
פונקציות בהגדרת משתמש ב-FLEDGE איך יתבצע התמיכה בפונקציות בהגדרת המשתמש (UDF) ב-FLEDGE? אלה פונקציות שמשתמשי הקצה יכולים לתכנת כדי להרחיב את הפונקציונליות של ה-API. הסבר זמין כאן. אנחנו עדיין ממשיכים לפתח את התכונה הזו, ולכן נשמח לקבל משוב נוסף על תרחישי לדוגמה.
הקלה על האילוץ של מקור נתונים זהה במשאבים של קבוצות אינטרס בקשה להקלה על האילוץ של מקור אחד במשאבים של קבוצות תחומי עניין, כדי לאפשר תרחישי שימוש מסוימים ב-AdTech בהטמעה הנוכחית של FLEDGE, למאפיינים biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl ו-trustedBiddingSignalsUrl צריך להיות אותו מקור כמו לבעלים של קבוצת תחומי העניין.

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

מדידת מודעות דיגיטליות

דוחות שיוך (Attribution) (וממשקי API אחרים)

נושא המשוב סיכום תגובה מ-Chrome
תנועה מגרסת מקור לניסיון נפח התנועה הנוכחי בגרסת Origin Trial לא מספיק לביצוע בדיקות של כלי השירות. תוכנית Origin Trials הנוכחית מיועדת לגורמים בסביבה העסקית כדי לבצע בדיקות פונקציונליות כדי לוודא שה-API פועל כמצופה. ברור לנו שיהיה צורך בכמויות גדולות יותר של תנועה כדי לבצע בדיקות תועלת לאחר שהפיתוח של ממשקי ה-API השונים של ארגז החול לפרטיות יהיה בשלב מתקדם יותר. לפי לוח הזמנים הנוכחי של הבדיקות, התהליך יסתיים עד לזמינות הכללית (כלומר, כשהטכנולוגיות של תרחישי השימוש יושקעו ויהיה ניתן להשתמש בהן ב-100% מתנועת הגולשים ב-Chrome) ברבעון השלישי של 2023 (לוח הזמנים המעודכן שלנו זמין בכתובת privacysandbox.com). נשמח לקבל משוב נוסף על בדיקות של תרחישי שימוש שדורשות תנועה נוספת.
חפיפה בפונקציונליות של ממשקי API שונים למדידת ביצועים בארגז החול לפרטיות אם יהיו כמה גישות למדידת ביצועים שחופפות זו לזו בארגז החול לפרטיות, המורכבות תגבר. לדוגמה, Attribution Reporting API ו-Private Aggregation API. אנחנו עובדים על מסמכי עזרה טובים יותר כדי להבהיר את התרחישים השונים לדוגמה לשימוש בממשקי ה-API, ונשמח לקבל משוב נוסף לגבי תחומים שבהם חסר הסבר. לדוגמה, Attribution Reporting API מיועד במיוחד לתמיכה במעקב המרות, ואילו Private Aggregation API ו-Shared Storage הם ממשקי API לכל מטרה שנועדו לתמוך במגוון רחב יותר של תרחישי שימוש למדידות בכמה אתרים.
ניסיון חוזר לשלוח בקשה לדוח שנכשלה הבהרה לגבי מספר הניסיונות לשלוח בקשה לדיווח אם היא נכשלת. פרסמנו הנחיות בנושא הזה. לסיכום, הדוחות נשלחים רק כשהדפדפן פועל או מחובר לאינטרנט. אחרי הכישלון הראשון בשליחה, המערכת תנסה לשלוח את הדוח שוב אחרי 5 דקות. אחרי הכשל השני, המערכת תנסה שוב לשלוח את הדוח אחרי 15 דקות. לאחר מכן, הדוח לא נשלח.
עיכוב בדיווח מהו עיכוב הדיווח הצפוי? אנחנו רוצים לשמוע משוב נוסף מהסביבה העסקית לגבי עיכובים בדוחות, בזמן שאנחנו אוספים נתונים כדי להעריך את העיכובים האלה לעומק במקביל.
רינדור מראש של דפים האם שיוך ARA יפעל בדפים שעברו רינדור מראש? רישום השיוך נדחה בדפים שעברו עיבוד מראש עד להפעלה (הקליק או הצפייה בפועל מתרחשים). כלומר, נמנע מהפעלת ה-ping של הבקשה 'attributionsrc'.
מדידת עלייה בהמרות איך מודדים עלייה בהמרות באמצעות בדיקת AB באותו דומיין באתרים אפשר למדוד את העלייה בהמרות באמצעות בדיקות A/B באותו דומיין באמצעות דיווח שיוך. הם יכולים לקודד את הפרמטרים של הניסוי כמפתחות באמצעות ה-API המצטבר, ולאחר מכן לקבל דוחות סיכום של ערכי ההמרות לפי הקטגוריות של המפתחות האלה.
(דיווח גם ברבעון השלישי) המרות בכמה דומיינים איך עוקבים אחרי המרות בכמה דומיינים, למשל עם 2 יעדים או יותר עדכון לרבעון 4:

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

שיתפנו את בקשת המשיכה הזו, שבמסגרתה חלון התפוגה לא יהיה תלוי בחלון הדיווח, כדי לצמצם את הפשרה בין עיכוב הדיווח לבין תפוגת התוקף של ההמרות. התכונה הזו זמינה עכשיו בגרסה M110.
הונאה וניצול לרעה בקשות ממפרסמים ומשווקים לאפשרות לפלח ולצבור נתונים על סמך אתרי בעלי תוכן דיגיטלי שבהם המודעות שלהם מוצגות. כך הם יוכלו לקבל תובנות נוספות לגבי שיטות פוטנציאליות של פרסום שמקורו בתרמית אנחנו מדברים על המשוב הזה כאן , ונשמח לקבל מכם עוד משוב.
(דווח גם ברבעון השלישי) עיכוב בדיווח ברמת האירוע העיכוב של 2 עד 30 יום בדיווח ברמת האירוע עשוי להיות ארוך מדי בתרחישי שימוש מסוימים. בדיווח ברמת האירוע, חלונות הדיווח שמוגדרים כברירת מחדל הם 2, 7 ו-30 ימים. אפשר לשנות את הערך הזה באמצעות הפרמטר 'expiry'. חברות טכנולוגיית הפרסום יכולות להגדיר את התוקף, לפחות יום אחד, כדי לקבל דוחות פוטנציאליים תוך פחות מ-2 ימים. אנחנו מגבילים את רמת הפירוט של התוקף ליום אחד כמנגנון להגנה על הפרטיות, כי דיווח מפורט יותר על התוקף עלול לגרום להתקפות תזמון. בנוסף, אנחנו מאפשרים להגדיר פרמטרים עצמאיים של 'תפוגה' ברמת האירוע ובדוחות המצטברים. כאן מוסבר איך בוחרים אפשרות. בנוסף, מערכת Google Ads לא תקבל חלונות דיווח מיוחדים שלא ניתנים לשירותי טכנולוגיית פרסום אחרים דרך Attribution Reporting API.
דרישה לאותו מקור דיווח בקשה להסרת הדרישה שהמקור של רישום המקור יהיה זהה למקור של רישום ההמרה כדי לפתור את תרחיש השימוש הזה, אנחנו ממליצים להשתמש בהפניות אוטומטיות (redirects) מסוג HTTP להענקת גישה לרישום. נשמח לקבל משוב נוסף לגבי ההנחיות החדשות.
מעקב המרות צריך להבדיל בין המרה שהתרחשה לפני שעות מסוימות שהמפרסם הגדיר לבין המרה שהתרחשה אחרי שעות מסוימות שהמפרסם הגדיר ב-Attribution Reporting API יש תמיכה בהגדרת חלון תפוגה ועדיפות לשיוך למקור. אם משתמשים בשניהם, מבחינה טכנית אפשר לשייך המרה שהתרחשה בחלון של X ימים בנפרד מהמרה שהתרחשה אחרי X.
סימולציית רעשים בקשה לאפשרות לדמות את נפח ההמרות השונה בכל קטגוריה, כדי להבין את ההשפעה על מפרסמים עם פחות המרות אנחנו שוקלים להוסיף דרכים לדמות את זה בגרסאות עתידיות של Noise Lab. נשמח לקבל משוב נוסף.
דיווח בנייד האם הדוח יישלח גם כש-Chrome פועל ברקע בנייד? בשלב הזה, גם בנייד, הדוח לא יישלח כש-Chrome פועל ברקע. סביר להניח שהמצב הזה ישתנה כשה-API ישתלב עם ארגז החול לפרטיות ב-Android. כאן מוסבר איך בוחרים אפשרות. לתשומת ליבכם: ארגז החול לפרטיות ב-Android לא נכלל בהתחייבויות שאושרו על ידי CMA.
זמינות הנתונים חששות לגבי הגישה הנוספת של Google לנתונים באמצעות ממשקי ה-API של ארגז החול לפרטיות ראשית, ל-Google Ads אין גישה מועדפת לנתונים מ-Attribution Reporting API או מממשקי API אחרים של ארגז החול לפרטיות. הבעיה הזו מופיעה גם בקטע 'משוב כללי' בקטע 'יכולת פעולה הדדית', שכולל פרטים נוספים על ההתחייבויות של Google.

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

הגבלת מעקב סמוי

הפחתת מידע בסוכן משתמש

נושא המשוב סיכום תגובה מ-Chrome
עיכוב ההפעלה של הפחתת מידע בסוכן משתמש עד שהסביבה העסקית של האינטרנט תהיה מוכנה יותר אין מספיק זמן להסתגל לשינויים הצפויים בהפחתת מידע בסוכן משתמש. אנחנו מתייחסים למשוב הזה בדוח המלא בקטע 'חששות של בעלי עניין' בקטע 'האינטראקציה של Google עם CMA'.
עיכוב ההפעלה של הפחתת מידע בסוכן משתמש עד שהסביבה העסקית של האינטרנט תהיה מוכנה יותר בקשה לדחיית ההשקה של הפחתת סוכני משתמשים עד לפריסה של סוכני משתמשים מובְנים (SUA) צוות Google Ads הציע את התוספת של User-Agent מובנה (ראו מפרט) ל-OpenRTB באוקטובר 2021, והיא שולבה בעדכון המפרט של גרסה 2.6 שפורסם באפריל 2022.

יש לנו כמה ראיות לכך ש-SUA נפרס וזמין היום, כפי שמתואר בפוסט בבלוג של Scientia Mobile, שבו מוסבר איך להשתמש ב-UA-CH וב-WURFL API כדי ליצור SUA.

###

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

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

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

התוכניות לצמצום המידע בסוכן המשתמש ול-UA-CH API הוצגו לקבוצה של W3C למניעת הונאות ב-18 במרץ 2022, וגם לקבוצת העבודה של תשלומים באינטרנט ולקבוצת האינטרסים בנושא אבטחת תשלומים באינטרנט ב-20 בינואר 2022. לא הוצגו חששות משמעותיים במהלך ההרצאות או לאחריהן.

Google יצרה קשר באופן יזום עם יותר מ-100 מפעילי אתרים כדי לקבל משוב. בנוסף, Google השתמשה גם בערוצי Blink-Dev כדי להודיע באופן ציבורי על ההשקה של הפחתת סוגי ה-User-Agent, על סמך משוב מגורמים מעורבים בסביבה העסקית.
תזמון חששות לגבי מועד ההשקה וההכנות של התעשייה עיינו בקטע הייעודי UA-CH בהמשך
סטטוס הפלטפורמה של Chrome ביקשתי לעדכן את דף chromestatus עבור UA-CH הרשומה ב-chromestatus עודכנה ב-19 בדצמבר ל'אותות מעורבים'.

הגנה על כתובת ה-IP (לשעבר Gnatcatcher)

נושא המשוב סיכום תגובה מ-Chrome
הצטרפות או ביטול הצטרפות האם צריך להביע הסכמה או לבטל הסכמה לשימוש בפרטיות כתובת ה-IP? המטרה שלנו היא לספק הגנה על כתובות IP לכל המשתמשים. במסגרת המטרה הזו, אנחנו בודקים כרגע אפשרויות לבחירת משתמשים בנושא הגנה על קניין רוחני.
תרחיש לדוגמה של כתובת IP לנתונים מאינטראקציה ישירה (First-Party) האם אפשר להשתמש בכתובות IP כדי לחבר בין תהליכי שימוש של משתמשים בדומיינים של צד ראשון אחרי הפעלת הגנה על כתובות IP? כפי שפרסמנו בעבר, בשלב הראשון ההגנה על כתובות IP תתמקד במעקב בהקשר של צד שלישי, כלומר דומיינים של צד ראשון לא יושפעו.
תרחישים לדוגמה בתחום טכנולוגיות הפרסום איך חברות יכולות להגדיר אמצעי הגנה מפני הונאות באמצעות הגנה על קניין רוחני? אנחנו מבינים את החשיבות של כתובת ה-IP כאות למאמצים למניעת הונאות באינטרנט של היום. במסגרת ההתחייבויות שלנו ל-CMA (פסקה 20), הצהרנו שלא נעביר את הגנת ה-IP ללא מאמץ סביר לתמוך ביכולת של אתרים לבצע פעולות נגד ספאם ותרמית. אחד מהעדיפויות הגבוהות שלנו הוא להבין איך הגנה על זכויות יוצרים משפיעה על תרחישי שימוש למניעת הונאות ועל יכולות הזיהוי, כדי שנוכל להשקיע עוד יותר בטכנולוגיות לשמירה על הפרטיות שעוזרות לחברות לשמור על הבטיחות באינטרנט. אנחנו מעודדים משוב ומשוב על הצעות חדשות שמטרתן לתמוך בצרכים של חברות אבטחה וחברות למניעת הונאות, גם כשהאותות משתנים לאורך זמן.
הונאה וניצול לרעה האם הגנה על כתובת IP כוללת הגנה מפני התקפת מניעת שירות (DoS)? אנחנו מחויבים לשפר את הפרטיות תוך שמירה על בטיחות האינטרנט, והגנה מפני התקפות מניעת שירות היא תרחיש שימוש חשוב למניעת ניצול לרעה שצריך לתכנן עבורו. אנחנו מקווים לצמצם את ההשפעה על אמצעי ההגנה מפני מניעת שירות באמצעות תכנון ההגנה על ה-IP עצמה וגם באמצעות פתרונות חדשים למניעת ניצול לרעה. מאחר שהתכונה 'הגנה על כתובת ה-IP' מתמקדת בהתחלה בשירותים מוטמעים של צד שלישי, חלק מבעלי העניין ציינו שהיא אמורה להשפיע באופן מוגבל על ההגנה מפני מניעת שירות (DoS) לאתרים מאינטראקציה ישירה (First-Party). עם זאת, אנחנו ממשיכים לבקש משוב ציבורי כדי להעריך את הסיכון לתרחישי שימוש של התקפת מניעת שירות (DoS), במיוחד בשירותים מוטמעים של צד שלישי.

במקביל, אנחנו בודקים מנגנונים של משוב על ניצול לרעה ומנגנונים לחסימת לקוחות, שיאפשרו לאתר או לשירות לחסום משתמש ששולח ספאם, בלי לזהות את המשתמש.
סינון תוכן סינון תוכן באמצעות הגנה על כתובת ה-IP לחברה אחת יש צרכים שונים מחברה אחרת בנוגע לסינון תוכן ולהתאמה אישית של חוויית המשתמש. במקרים רבים כאלה, אין כרגע שימוש בכתובות IP, ולכן ההגנה על כתובות IP לא אמורה להשפיע עליהם. לדוגמה, בעל תוכן דיגיטלי שמעוניין להתאים אישית את התוכן שלו ולהגדיל את ההתעניינות בו עשוי להשתמש בקובצי Cookie מהדומיין הנוכחי או בקובצי Cookie מחולקים של צד שלישי (CHIP) כדי להבין את תחומי העניין של המשתמש ואת האינטראקציות הקודמות שלו עם בעל התוכן הדיגיטלי. לחלופין, שותף של טכנולוגיית פרסום שמתמקד בהצגת המודעה המתאימה למשתמש הנכון יכול לשלב את FLEDGE ו-Topics, למשל, כדי לספק תוצאות דומות של מודעות כמו שהוא עושה היום באמצעות קובצי Cookie של צד שלישי או טכנולוגיות מעקב אחרות באתרים שונים.

אנחנו גם בוחנים אפשרות להוסיף ל-IP Protection יכולות חדשות לשמירה על הפרטיות, כמו מיקום גיאוגרפי גס, כדי לתמוך עוד יותר בסינון תוכן במקרים שבהם המנגנונים הקיימים לא מספיקים. נשמח לקבל משוב נוסף על תרחישי שימוש בסינון תוכן שעשויים להיות מושפעים מההגנה על כתובות IP.
(דיווח גם ברבעון השלישי)
תרחישים לדוגמה של שימוש במיקום גיאוגרפי		 הגנה על כתובת ה-IP עשויה למנוע בעתיד שימוש לגיטימי בתכונות שמבוססות על מיקום גיאוגרפי, כמו התאמה אישית של תוכן על סמך מיקום גיאוגרפי. עדכון לרבעון 4:

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

מכסת פרטיות

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

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

חיזוק גבולות הפרטיות באתרים שונים

קבוצות מאינטראקציה ישירה (First-Party Sets)

נושא המשוב סיכום תגובה מ-Chrome
(דווח גם ברבעון השלישי) מגבלת דומיין בקשה להרחבת מספר הדומיינים המשויכים עדכון לרבעון 4:

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

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

כפי שמוסבר בהנחיות לשליחת בקשות, כל ניהול של שינוי בקבוצה יתבצע בהתאם לתהליך אימות ב-GitHub, כולל אימות הבעלות, כדי לצמצם את הסיכון הזה.
מיטיגציה של התנהלות פוגעת חשש שאפשר לנצל לרעה את הקבוצות של צד ראשון אנחנו בוחנים דרכים להרחיב את הבדיקות הטכניות של סוגי קבוצות המשנה, ומחפשים באופן פעיל משוב נוסף מהקהילה כאן.
תרחישים לדוגמה ב-Ads שאלות לגבי השימוש בקבוצות של צד ראשון לצורך תמיכה בטירגוט מודעות אנחנו לא מנסים לתמוך בתרחישי שימוש של טירגוט ב-Google Ads עבור קבוצות של נתונים מאינטראקציה ישירה (First-Party), ואנחנו ממליצים להשתמש בממשקי ה-API של Google Ads שזמינים לתרחישים כאלה.
(דיווח גם ברבעון השלישי) מדיניות חשש ש-FPS לא תואם להתחייבויות של CMA בנושא 'חקיקה רלוונטית בנושא הגנה על מידע', על סמך העובדה שתקנת ה-GDPR לא מטילה הגבלה על מספר האתרים בקבוצה, בעוד ש-FPS קובעת מגבלה של 3 התשובה שלנו לא השתנתה מאז הרבעון השלישי:

"Google ממשיכה להתחייב בפני CMA לתכנן ולהטמיע את ההצעות של ארגז החול לפרטיות באופן שלא יגרום לעיוות בתחרות על ידי מתן עדיפות לעסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום דיגיטלי, על בעלי תוכן דיגיטלי ועל מפרסמים, וגם את ההשפעה על תוצאות הפרטיות ועל הציות לעקרונות של הגנה על נתונים כפי שמפורטים בחקיקה הרלוונטית בנושא הגנה על נתונים. החשש שצוין לא חושף אי-תאימות ל-GDPR. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם CMA כדי לוודא שהעבודה שלנו עומדת בהתחייבויות האלה".
הצעה חלופית קבוצות מאומתות בהתאם ל-GDPR בנוסף למשוב שקיבלנו מהסביבה העסקית לגבי ההצעה לאימוץ 'קבוצות מאומתות בהתאם ל-GDPR', יש ל-Chrome חששות לגבי המגבלות הבאות של ההצעה החלופית הזו:

  • 'קבוצות מאומתות בהתאם ל-GDPR' טוענות שהן 'תואמות' ל-GDPR (אבל לא ברור מה המשמעות של הטענה הזו). לעומת זאת, ההתחייבויות של Google מחייבות אותה להביא בחשבון באופן כללי יותר את 'ההשפעה על תוצאות הפרטיות'. בהחלטה שלה לאשר את ההתחייבויות, CMA מציינת שהן נבדלות מההתחייבות של Google להביא בחשבון "תאימות לעקרונות ההגנה על נתונים כפי שהם מפורטים בחקיקה הרלוונטית בנושא הגנה על נתונים". כפי שמוסבר ב-CMA, ההתחייבות הזו משקפת את העובדה ש-Google כפופה לחקיקה הרלוונטית בנושא הגנה על נתונים, גם בנוגע להתחייבויות וגם באופן כללי.
  • יש לנו חששות לגבי פרטיות בהצעה לאפשר לדומיינים להופיע במספר קבוצות. קבוצות מהדומיין הנוכחי נועדו לתמוך בתרחישים ספציפיים לדוגמה, שתלויים כרגע בקובצי cookie של צד שלישי, בלי להפעיל מעקב נרחב באתרים שונים. אם נאפשר לדומיינים להצטרף לכמה קבוצות, נגרום להסרת אמצעי הגנה מרכזי על הפרטיות שמובנה בהצעה לגבי קבוצות מהדומיין הנוכחי, בלי להוסיף הגבלות משמעותיות אחרות.
  • ב-GDPR Validated Sets מוצע גם "להגדיר קבוצה כקבוצה של נאמני מידע ומעבדי מידע שיש להם מדיניות שימוש משותפת". הדרישות האלה דומות לדרישות שהיו בהצעה המקורית שלנו לגבי קבוצות של דומיינים מהצד הראשון, שלפיהן כל הצדדים בקבוצה חייבים לשתף מדיניות פרטיות משותפת. מאז הסרנו את הדרישה הזו על סמך משוב חזק מהסביבה העסקית, שעורר חששות לגבי דרישות שמבוססות על מדיניות הפרטיות. לדוגמה, קיבלנו מפירסמי אתרים מידע על כך שלא ניתן לשמור על מדיניות פרטיות משותפת בגלל הבדלים גיאוגרפיים ומוצריים, בין היתר, וגם בגלל אתגרים אחרים שציינו חברי קהילת W3C (1, 2, 3). לדעתנו, אותם אתגרים יחולו גם על ההצעה הזו.

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

Fenced Frames API

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

Shared Storage API

נושא המשוב סיכום תגובה מ-Chrome
אחסון משותף לטכנולוגיות פרסום אי-ודאות לגבי השימוש באחסון משותף בתרחישי שימוש של טכנולוגיות פרסום אפשר להשתמש ב-Shared Storage API וב-Private Aggregation API למטרות מדידה שונות שדורשות מדידת אחסון בכמה אתרים. דוגמאות מפורטות כאן.

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

CHIPs

נושא המשוב סיכום תגובה מ-Chrome
(דיווח גם ברבעון 3) דרישה למחיצות מוסיפים דרישה מפורשת להתנהגות למאפיין 'מופרדים למחיצות' בקובצי cookie מהדומיין הנוכחי. עדכון לרבעון 4:

לאחר דיונים ב-GitHub ובשיחות של PrivacyCG, הגענו להסכמה לגבי ההתנהגות הבאה: קובצי cookie מחולקים שמוגדרים בקובצי cookie מהדומיין הנוכחי ישתמשו במפתח מחיצה של (A,A), כאשר 'A' הוא האתר ברמה העליונה. אנחנו נתעד את ההתנהגות הזו במאמר ההסבר ובמפרט.
ניהול קובצי cookie האם יש כלים לניהול או לרגולציה של קובצי cookie מהדומיין הנוכחי או של קובצי cookie של צד שלישי? אפשר להשתמש בכלים למפתחים של Chrome וב- NetLog כדי לבדוק אתרים כשהחסימת קובצי ה-Cookie של צד שלישי מופעלת. שני הכלים מדווחים על חסימת קובצי cookie עקב הגדרות המשתמש. נשמח לקבל משוב על סוגים נוספים של אתרי ביקורת שתרצו לראות.

FedCM

נושא המשוב סיכום תגובה מ-Chrome
ה-IdP דורש ידע על RP כדי לאפשר סשן בעיה כשמשתמש מנסה להתחבר ל-IdP של Feide משני RP שונים אנחנו דנים בפתרונות אפשריים לבעיה הזו.
יכולת פעולה הדדית חששות לגבי ההשפעה של FedCM על הקשר בין המשתמשים לאתרים שהם מתחברים אליהם באמצעות FedCM, ועל 'יכולת הפעולה ההדדית' בין אתרים לאחר הסרת קובצי ה-cookie של צד שלישי מ-Chrome, אנחנו שואפים להמשיך לתמוך בשירותי אימות זהות מאוחדת שמסתמכים כרגע על קובצי cookie של צד שלישי. אנחנו צופים ש-FedCM תהיה רק אחת מהאפשרויות הזמינות לשירותים כאלה. ספקי זהויות (IdP) וצדדים נסמכים (RP) יכולים להשתמש בטכנולוגיות אחרות שעשויות להתאים יותר לצרכים שלהם.

נראה שהחששות לגבי הקשר בין המשתמש ל-RP ו'יכולת הפעולה ההדדית' נובעים מאי-הבנה של ההצעה של FedCM. FedCM משאיר ל-IdPs את ההחלטה לגבי המידע ששותף עם RP, ובאיזה אופן, אחרי שהמשתמש בחר להיכנס לאתר של ה-RP הזה. FedCM לא מחייב את ספקי ה-IdP "ליצור מזהה פסאודונימי ייחודי לכל [RP] שבו המשתמש מבצע אימות". במקום זאת, FedCM פתוח לכל ספק IdP כדי שיוכל לבחור אם לשתף את המזהה בפועל של המשתמש, גרסה של המזהה לפי אתר או גרסה אחרת של המידע הזה.

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

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

נלחמים בספאם ובהונאות

Private State Token API

נושא המשוב סיכום תגובה מ-Chrome
טיפול בבקשות של בוטים מה קורה אם המנפיק מגלה שטוקנים של מצב פרטי הונפקו לרובוטים? כדי למנוע מאסימונים שהונפקו לרובוטים להישאר בסביבה העסקית במשך זמן רב, המנפקים צריכים לבצע רוטציה של המפתחות שבהם הם משתמשים כדי לחתום על אסימונים באופן קבוע, כך שתוקפם של אסימונים ישנים שהונפקו באמצעות לוגיקה של הנפקה שעשויה להיות שבורה יפוג, והאתרים יוכלו לממש אסימונים חדשים יותר עם לוגיקה מעודכנת של הנפקה.
שליחת טפסים באותו אתר האם אפשר להשתמש באסימוני מצב פרטי לשליחת טפסים באותו אתר שכוללים ניווט בדף מלא (כלומר Content-Type: application/x-www-form-urlencoded) במקום בקשה מממשקי ה-API של fetch/XMLHttpRequest? בשלב הזה אין תמיכה באפשרות הזו בגרסה הראשונה של טוקנים של מצב פרטי. אם יש ביקוש משמעותי לתרחיש השימוש הזה, נשמח לקבל משוב מהסביבה העסקית.
אימות בצד השרת שאלות לגבי האפשרות לאמת טוקנים של מצב פרטי בצד השרת האסימונים מומשו מול המנפיק, ואז המנפיק יוצר רשומת מימוש שיכולה להכיל את האסימון עצמו או ערך חתום כלשהו שמבוסס על האסימון. השרתים יכולים להשתמש ברשומת המימוש הזו כדי לאמת את האותנטיות של האסימון, ואנחנו צופים שסביבות עסקיות שונות של מנפיקים יפיקו תקנים שונים לצורך פרשנות של רשומות המימוש שלהן.