דוח רבעוני לרבעון 4 של שנת 2022 שמסכם את המשוב שהתקבל לגבי הסביבה העסקית בנוגע להצעות של ארגז החול לפרטיות והתגובה של Chrome.
כחלק מהמחויבויות שלה ל-CMA, Google הסכימה לספק באופן ציבורי דוחות רבעוניים על תהליך המעורבות של בעלי עניין להצעות של ארגז החול לפרטיות (ראו סעיפים 12 ו-17(c)(ii) במחויבויות). דוחות סיכום המשוב של ארגז החול לפרטיות נוצרים על ידי צבירת משובים ש-Chrome מקבל מהמקורות השונים, כפי שמפורט בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין ב-privacysandbox.com, פגישות עם בעלי עניין בתחום ופורומים של תקני אינטרנט. ב-Chrome מקבלים בברכה את המשוב שמתקבל מהסביבה העסקית, ובוחנים באופן פעיל דרכים לשלב את התובנות שנלמדו בקבלת החלטות לגבי תכנון.
נושאי המשוב מדורגים לפי מידת השכיחות לכל API. כדי לעשות את זה, מתבצעת צבירה של כמות המשוב שצוות Chrome קיבל לגבי עיצוב נתון, תוך ארגון בסדר יורד של כמות. כדי לזהות את הנושאים הנפוצים במשוב, עיינתי בדיונים שנשאלו בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שהעלו הצוותים הפנימיים והטפסים הציבוריים של Google.
באופן ספציפי, נבדקו פרוטוקולים של פגישות עם גופים סטנדרטיים באינטרנט, וכדי לקבל משוב ישיר, נלקחו בחשבון הרשומות של Google לגבי פגישות אישיות עם בעלי עניין, אימיילים שהתקבלו מהמהנדסים, רשימת הדיוור של ה-API וטופס המשוב הציבורי. לאחר מכן, Google תאמה בין הצוותים שלקחו חלק בפעילויות ההפצה השונות כדי לקבוע את השכיחות היחסית של הנושאים שעלו ביחס לכל ממשק API.
ההסברים של Chrome למשוב פותחו על סמך שאלות נפוצות שפורסמו, תשובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת מיקום באופן ספציפי למטרת תרגיל זה של דיווח ציבורי. עדכון בנושא הנוכחי, של הפיתוח והבדיקות, של השאלות והמשוב שקיבלנו באופן ספציפי על ממשקי ה-API של Topics, Flidge ו-Attribution.
יכול להיות שמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עוד לא נחשב כתגובה מ-Chrome.
מילון של ראשי תיבות
- צ'יפים
- קובצי Cookie עם חלוקה עצמאית למחיצות
- DSP
- פלטפורמה בצד הביקוש
- FedCM
- ניהול פרטי כניסה מאוחדים
- FPS
- דומיינים של צד ראשון
- IAB
- הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)
- IdP
- ספק זהויות
- IETF
- כוח המשימה של ההנדסה באינטרנט
- IP
- כתובת פרוטוקול אינטרנט
- openRTB
- בידינג בזמן אמת
- הארכה
- גרסת מקור לניסיון
- PatCG
- קבוצת קהילת הטכנולוגיות של פרסום פרטי
- RP
- מפלגה מהימנה
- SSP (פלטפורמה בצד המכירה)
- הפלטפורמה לספקים
- TEE
- סביבת מחשוב אמינה
- UA
- מחרוזת סוכן משתמש
- UA-CH
- רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
- W3C
- ארגון התקינה באינטרנט
- WIPB
- עיוורון IP ללא כוונה
משוב כללי, ללא API/טכנולוגיה ספציפיים
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| (גם בדוחות ברבעון 3) היתרונות לסוגים שונים של בעלי עניין |
חשש שהטכנולוגיות של ארגז החול לפרטיות נותנות עדיפות למפתחים גדולים יותר, ושאתרי נישה (קטנים יותר) תורמים יותר מאשר אתרים גנריים (גדולים יותר) | התגובה שלנו לא השתנתה מרבעון 3: Google התחייבה ל-CMA לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא מעוות את התחרות על ידי העדפה עצמית של העסק של Google, ו לוקח בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי תוכן דיגיטלי ומפרסמים, בלי קשר לגודלם. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה. במהלך הבדיקה של ארגז החול לפרטיות, אחת מהשאלות המרכזיות שנשאל אותה היא את הביצועים של הטכנולוגיות החדשות אצל סוגים שונים של בעלי עניין. המשוב הוא קריטי מהבחינה הזו, ובמיוחד משוב ספציפי ומעשי שיכול לעזור לנו לשפר את העיצובים הטכניים. פעלנו בשיתוף עם מנהלי הקהילה כדי לפתח את הגישה שלנו לביצוע בדיקות כמותיות, ואנחנו תומכים ב-CMA לפרסם הערה לגבי תכנון ניסויים כדי לספק מידע נוסף למשתתפים בשוק והזדמנות להגיב על הגישות המוצעות". |
| (מדווח גם ברבעון השלישי) בקשות מסמכים |
בקשות למשאבים נוספים שמפרטים איך לנהל את הבדיקה, הניתוח וההטמעה | עדכון לרבעון 4: אנחנו מעריכים שהחומרים הנוכחיים שלנו הועילו למפתחים, ואנחנו ממשיכים להיות מחויבים לספק עוד חומרים כדי שהמפתחים יוכלו להבין איך הטכנולוגיות החדשות יכולות לעבוד בשבילם. במהלך הרבעון האחרון הוספנו קטע "חדשות ועדכונים" לאתר privacysandbox.com ופרסמנו סקירה מקיפה לגבי האופן שבו ארגז החול לפרטיות יכול לעזור לשפר את הרלוונטיות של מודעות בעתיד. בנוסף, קיימנו מפגשים ציבוריים במהלך שעות העבודה עם המפתחים, כדי לשתף שיטות מומלצות והדגמות ומפגשי שאלות ותשובות עם מומחי מוצרים והנדסה כדי לאפשר דיונים או שאלות בזמן אמת. |
| דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) | איך זמן האחזור של ה-API של ארגז החול לפרטיות משפיע על מדדי ליבה לבדיקת חוויית המשתמש באתר? | שמירה על זמן אחזור מינימלי היא אחת המטרות העיקריות בעיצוב של ממשקי ה-API של ארגז החול לפרטיות. כרגע אנחנו צופים שזמן האחזור של ה-API אמור להשפיע במידה מינימלית על מדדי הליבה לבדיקת חוויית המשתמש באתר, מאחר שרוב ממשקי ה-API מופעלים לאחר העיבוד הראשוני של האתר. אנחנו ממשיכים לעקוב אחר כל אחד מממשקי ה-API ולבצע שיפורים כדי לצמצם עוד יותר את זמן האחזור, ומעודדים את המשך הבדיקה והמשוב. ניתן להתייחס לזמן האחזור בתהליך הבידינג בזמן אמת בקטע FLEDGE בקטע Performance of FLEDGE Auctions (ביצועים של מכרזים ב-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 ו/או התוכן של הדף או חלקם) בסיווג של הנושאים. יש לשקול את כל השיפורים בתועלת מול סיכוני הפרטיות וניצול לרעה. לדוגמה, ביחס למטא-נתונים באופן ספציפי, קיימים כמה מהסיכונים הבאים: - אתרים שמשנים מטא-נתונים ברמת הדף כשיטה לקידוד משמעויות שונות (ועשויות להיות רגישות) לנושאים; - אתרים שמשנים את המטא-נתונים ברמת הדף כדי להציג מצג שווא לגבי הנושאים שלהם למטרת רווח כספי; - מטא-נתונים ברמת הדף ב-Google Sites שמשנים באופן דינמי את המטא-נתונים ברמת הדף כשיטה למעקב באתרים שונים |
| (דווח גם ברבעון 3) ההשפעה על אותות מאינטראקציה ישירה |
אותות של נושאים יכולים להיות חשובים מאוד, וכתוצאה מכך לפגוע בערך של אותות אחרים שמבוססים על תחומי עניין מאינטראקציה ישירה. | התגובה שלנו לא השתנתה מהרבעון השלישי: "אנחנו מאמינים שפרסום המבוסס על תחומי עניין הוא תרחיש חשוב באינטרנט, ו-Topics API נועד לתמוך בתרחיש הזה. כפי שתואר [בדוח הרבעון השלישי], בעלי עניין אחרים בסביבה העסקית הביעו חששות בנוגע לכך ש-Topics לא שימושי מספיק כדי לספק ערך. בכל המקרים, שיפור הטקסונומיה הוא מאמץ מתמשך, ואנחנו מצפים שהטקסונומיה תשתנה בעקבות בדיקות של המערכת האקולוגית וקבלת קלט". |
| עדכון הטקסונומיה | איך תעודכן רשימת הטקסונומיה? | אנחנו מבקשים משוב לגבי הטקסונומיה שיכולה להועיל לסביבה העסקית. הטקסונומיה שנכללת בהצעה הראשונית של Topics API נועדה לאפשר בדיקות פונקציונליות. ב-Chrome אנחנו שוקלים באופן פעיל כמה גישות לעדכון הטקסונומיה. לדוגמה, Chrome עשוי להשתמש במושג של ערך מסחרי עבור כל נושא כדי לקבוע איזו קטגוריה לכלול באיטרציות עתידיות. |
| ביצועי המסווג האזורי של Topics | הביצועים של מסווג הנושאים נמוכים בדומיינים אזוריים | שיפור המסווג הוא מאמץ מתמשך. על סמך המשוב שקיבלנו, אחת האפשרויות היא להרחיב את רשימת 'שינוי נושאים'. על סמך הניתוח שלנו, נרחיב את הכיסוי הגלובלי וישפר את הדיוק. כדי להסביר, הסיווג של Topics API כולל שני רכיבים רלוונטיים: (1) רשימת שינויים שכוללת את 10,000 האתרים המובילים והנושאים שלהם, ו-(2) מודל למידת מכונה במכשיר שמסווג את שמות המארחים לנושאים. באמצעות הרחבה של רשימת הביטול (1), אנחנו יכולים לשפר את ביצועי הסיווג באזורים שבהם הביצועים של המסווג עשויים להיות נמוכים. |
| תקופה של שבוע | התקופה של שבוע היא ארוכה מדי עבור משתמשים שרוצים לקבל החלטות לטווח קצר יותר. | אנחנו בוחנים באופן פעיל מה משך הזמן המתאים של תקופות של זמן מערכת, ונשמח לקבל משוב נוסף לגבי איזו תקופה טובה יותר עבור המערכת האקולוגית. |
| אחזור כותרת HTTP | חשש שאין מספיק מידע לגבי אחזור נושאים של כותרת HTTP | אנחנו עובדים על הכנת הכותרות וה-fetch(). יש לנו גם מידע זמין כאן. כמו כן, הוספנו להסבר את המידע על דילוג על תצפית. |
| המטרה של הנושאים היא לעזור רק למפרסמים, לא למשתמשים | נראה ש'ארגז החול לפרטיות' הוא גישה שממוקדת בענף. התועלת למשתמשים לא ברורה יותר מהתועלת לתעשייה. | אנחנו מאמינים שהיתרון עבור המשתמשים הוא ש-Topics תומך במודעות מבוססות-עניין ששומרות על האינטרנט פתוח וחופשי, ואנחנו גם חושבים שהתכונה משפרת באופן משמעותי את הפרטיות בהשוואה לקובצי cookie של צד שלישי. הסרה של קובצי cookie של צד שלישי בלי חלופות שימושיות עלולה להשפיע לרעה על בעלי התוכן הדיגיטלי, ויכולה להוביל לגישות פחות פרטיות שהן פרטיות פחות, לא שקופות, שמשתמשים לא יכולים לאפס אותן או לשלוט בהן באופן מציאותי. חברות רבות בודקות באופן פעיל את Topics ואת Sandbox API, ואנחנו מחויבים לספק את הכלים לקידום הפרטיות ולתמיכה באינטרנט. קבוצת הארכיטקטורה הטכנית של W3C פרסמה לאחרונה את התצוגה הראשונית שלה לגבי Topics API, ואנחנו נגיב עליו באופן ציבורי. בשלב הזה, מכיוון ש-Google קיבלה שאלות מסביבת פעילות לגבי מה שקרה בבדיקה הזו לגבי הפיתוח וההשקה של Topics API, אנחנו רוצים לאשר מחדש את התוכנית שלנו להפוך אותו לזמין ב-Chrome היציב השנה. צוות הארכיטקטורה של Google מעריך את המשוב של קבוצת הארכיטקטורה הטכנית של W3C, אבל מבחינתנו יש חשיבות עליונה במאמצים לפיתוח ולבדיקה של Topics תוך התייעצות עם מנהלי הקהילה ועם הסביבה העסקית. |
| דליפת נתונים | חשש ש'נושאים' יודלפו לאתרים אחרים ללא רשות | בגלל העיצוב של Topics API, לא סביר להניח שנתונים של בעל תוכן דיגיטלי יחיד (ואפילו קבוצה קטנה יותר של בעלי תוכן דיגיטלי) יודלפו בדרך כלשהי. גם לאתרים של בעלי תוכן דיגיטלי יש שליטה מלאה על Topics API, והם יכולים למנוע גישה ל-API הזה באמצעות מדיניות ההרשאות. |
| אין מספיק מפרסמים לבדיקה | בעלי התוכן הדיגיטלי חוששים שבשלב הזה אין להם אפשרות להציג למפרסמים את הערך של Topics. | במחצית השנייה של שנת 2023, אנחנו מתכננים שכל ממשקי ה-API שקשורים למודעות יהיו זמינים לבדיקות אינטגרציה, ונאפשר למפרסמים לנתח את הסביבה העסקית של Topics API למפרסמים. הבדיקה והפרסום של התוצאות יהיו בפיקוח של ה-CMA, שיבדוק את הנתונים, הניתוח והמתודולוגיה. אנחנו מעודדים את הסביבה העסקית לשתף משוב עם Google ועם ה-CMA. |
| נושאים ו-FLEDGE | בקשה למידע נוסף על אופן השימוש ב-Topics במסגרת לוגיקת הבידינג של FLEDGE | אפשר להשתמש ב-Topics במסגרת לוגיקת הבידינג של FLEDGE. בנוסף, אנחנו עובדים על מדריך השילוב שיכיל פרטים נוספים על ההטמעה. |
| דירוג מותאם אישית של מתקשר לנושאים | מתן הרשאה להתאמה אישית של הדירוגים לפי המתקשר | האתגר עם דירוג נושאים או ערכים בהתאמה אישית לכל פרסום דיגיטלי הוא שהמערכת יכולה להפוך למנגנון שבאמצעותו טכנולוגיית פרסום יכולה להשפיע על הנושאים שמוחזרים, וכך ליצור וקטור של טביעת אצבע דיגיטלית (fingerprinting). |
| רשימת נושאים של שיחות בעדיפות גבוהה | המתקשרים יכולים לספק רשימת עדיפות מדורגת של נושאים שיוחזרו על ידי Topics API בהתאם לכשירות שלהם. | אנחנו ממשיכים לדון ברעיון הזה ונשמח לקבל נתונים נוספים. |
FLEDGE
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| Google Ad Manager | אתם חוששים ש-Google Ad Manager הוא הגורם המכריע במכרזים של FLEDGE, והוא יקבל עדיפות על ידי Google Publisher Tag ו-Google Ad Manager. | FLEDGE מאפשר לכל בעל תוכן דיגיטלי לבחור את מבנה המכרז, כולל הבחירה של אתרי מכירה ברמה העליונה וספקים של רכיבים. כל קונה ומוכר במכרז רכיבים יודעים מיהו המוכר ברמה העליונה, ויכולים לבחור אם להגיש הצעת מחיר או לא. |
| אין מספיק משתתפים שבודקים את FLEDGE | אפשר לבקש לעודד חברות נוספות לבדוק את FLEDGE. לדוגמה, על ידי שיפור הפונקציונליות של ה-API ומניעת חלופות שמפריעות לפרטיות כמו יצירה של טביעת אצבע דיגיטלית (fingerprinting) | ארגז החול לפרטיות מתקדם בשלבים, וביחד עם ההנחיות של ה-CMA וה-ICO, והבדיקה הפונקציונלית של FLEDGE הוכיחה את היציבות והיכולות הנדרשות. Google ממשיכה לעודד את הסביבה העסקית לבדוק את ממשקי ה-API של Sandbox, ולפרסם לאחרונה את התיעוד בנושא רלוונטיות של מודעות למקסימום כדי להראות איך FLEDGE וממשקי API אחרים יכולים לעזור בתמיכה בתרחישים קריטיים של שימוש בתעשיית המודעות לאחר ההוצאה משימוש של קובצי cookie של צד שלישי. חלקים אחרים של ארגז החול לפרטיות כבר תומכים במיטיגציות לצורך כיסוי המעקב (פרטים ב-UA-CH, בהגנה על IP ובהקלות במעקב אחר עזיבה מהדף הראשון) וימשיכו להשתפר עם הזמן. המטרה של Google היא לא להפוך את FLEDGE לפתרון הטירגוט היחיד בר-קיימא, אלא להמשיך לעבוד בשיתוף פעולה עם התעשייה והרגולטורים כדי לפתח בדפדפן Chrome את טכנולוגיות המודעות הטובות ביותר לשמירה על הפרטיות. |
| תרחישים לדוגמה בלמידת מכונה | ב-FLEDGE ובדוחות השיוך (Attribution) תהיה תמיכה בהסברים נוספים על תרחישי השימוש בלמידת מכונה לצורך אימון אלגוריתמים של בידינג במכרזים | אנחנו מכירים בצורך לעזור לבודקים למצוא את הדרכים השימושיות ביותר ליישום הטכנולוגיות של ארגז החול לפרטיות. התחלנו לפרסם הנחיות שקשורות באופן ספציפי לשימוש בהיבטים השונים של ממשקי ה-API של ארגז החול לפרטיות כמקורות קלט ללמידת מכונה. בחלק האחרון, "מקסימום רלוונטיות של מודעות", מוסבר איך תעשיית המודעות יכולה למנף את האותות האלה לצורך למידת מכונה, ואנחנו מתכננים להמשיך לפרסם הנחיות כאלה גם בעתיד. |
| שאילתה לגבי שרת FLEDGE Key Value (K/V) | למה אפשר לשלוח שאילתות לגבי שרת ה-K/V באופן ציבורי? | המטרה של שרת ה-K/V היא לספק אותות בזמן אמת למכרזי FLEDGE. לכן, שרת ה-K/V צריך להיות נגיש מהמקום שבו מתבצעות מכרזים של FLEDGE האלה (במכשירי משתמשים, ומחייב שהוא יהיה זמין לציבור). ערך שמאוחסן בשרת קיים יכול לאחזר את הערך רק על ידי גורם שכבר יש לו את המפתח. לכן, אם טכנולוגיית פרסום מספקת את המפתחות רק לדפדפנים שנכללים בקבוצת תחומי העניין, ואינה משתמשת במפתחות שניתן לנחש באופן אקראי, רק דפדפנים שזקוקים לערך כדי להפעיל את המכירה הפומבית שלהם יוכלו לאחזר אותו. |
| כיצד לבצע מיקוד לפי תאריך/שעה? | תמיכה באובייקטים של תאריך בפונקציה הלוגית של הבידינג. | אפשר לעשות זאת בכמה דרכים. הקונים יכולים לבקש מהמפיץ לספק את התאריך והשעה הנוכחיים, והמפיצים צריכים לספק את המידע הזה בקלות לכל הקונים. הקונים יכולים גם לציין את התאריך והשעה בתגובת ערך המפתח בזמן אמת. לבסוף, הקונים יכולים לציין את התאריך והשעה כחלק מהתשובה ההקשרית שלהם באותות לכל קונה, והמוכר יכול להעביר אותם לסקריפט של הצעת המחיר של הקונה. |
| העדפות משתמש | המשתמשים יכולים לבחור לחסום קריאייטיבים לפי מפרסם כשהם מוצגים דרך 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. במקביל, הוספנו לדפדפן כלים שמאפשרים למפתחים לנתח טוב יותר מה גורם להאטה של מכרזים, ומטפלים באופן שיטתי במקורות העיקריים של זמן האחזור שזוהה. השיפורים האחרונים כוללים זמן קצוב לתפוגה של מכרזים איטיים, שיטת סינון של מגישי הצעות מחיר מהירים, דרך לשימוש חוזר בפתרונות של FLEDGE כדי להימנע מתשלום עלויות ראשוניות ועבודה מתמשכת כדי לאפשר את הבקשה להצגת מודעה לפי הקשר במקביל עם זמן ההפעלה של FLEDGE ואחזורי הרשת. אנחנו צופים שהאופטימיזציה של זמן האחזור תימשך בין מפתחי Chrome לבין בודקי FLEDGE, על בסיס חוויית השימוש שלהם ב-API בפועל. |
| מגבלת זיכרון לגודל קבוצת תחומי העניין | בקשה להגדיל את מגבלת הגודל של קבוצת אינטרס יחידה מ-50KB | אנחנו שוקלים את הבקשה בפועל ומחפשים משוב כדי להבין איזה ערך מגבלה עובד. |
| שילוב הנתונים שמוצגים ב-FLEDGE עם קובץ cookie מהדומיין הנוכחי | האם FLEDGE יתמוך בשילוב עם נתונים מאינטראקציה ישירה של המפרסם? | FLEDGE תוכנן לתמוך בפרסום באמצעות נתונים מאינטראקציה ישירה (First-Party) של המפרסם כבר. עם זאת, FLEDGE לא מיועד לעזור למפרסם ללמוד את התנהגות הגלישה של משתמש באתר שאינו האתר של המפרסם עצמו. צירוף התנהגות הגלישה מחוץ לאתר לנתונים מאינטראקציה ישירה (First-Party) מנוגד ליעדים של ארגז החול לפרטיות. אנחנו מתכננים לשתף מדריכי שילוב עם פרטים נוספים על האופן שבו FLEDGE תתמוך בשילוב עם נתונים מאינטראקציה ישירה (First-Party) בשבועות הקרובים. |
| ערך של אנונימיות K | כיצד ייקבע הערך "K" ל-"k-anon" והאם הוא יפורסם? | הערך של "K" עדיין בשלבי פיתוח ונשתף מידע נוסף ככל שהתוכניות שלנו יתפתחו. אנחנו רוצים ללמוד על האופן שבו ערך k לא ידוע עלול לפגוע במוכנות של FLEDGE ובהיקף אימון המודלים ללמידת מכונה (ML), ונשמח לקבל משוב נוסף בנושא. |
| תמיכה במספר SSP | איך תהיה תמיכה בריבוי SSP ב-FLEDGE? | FLEDGE תומך במכרזים עם כמה אתרי מכירה, כפי שמתואר בהצעה הזו. |
| החשיפה של לוגיקת הבידינג | חשש שהלוגיקה של מתן הצעות מחיר בפלטפורמת DSP תיחשף ב-JavaScript | לאור הלוגיקה הנוכחית של שיטות הבידינג ב-JavaScript, אנשים אחרים יכולים לגשת ל-JavaScript, אבל נשמח לקבל משוב נוסף שמסביר מדוע אפשרות זו מדאיגה את פלטפורמות DSP. |
| prebid.js | מהו לוח הזמנים לתמיכה ב-prebid.js ב-FLEDGE? | רק גרסאות 7.14 ואילך של Prebid.js תומכות במודול FLEDGE. בעלי תוכן דיגיטלי שרוצים לבצע בדיקה צריכים להוסיף את מודול FLEDGE ולשדרג את מופע ה-Prebid שלהם. |
| פונקציות בהגדרת משתמש ב-FLEDGE | איך תהיה תמיכה בפונקציות בהגדרת המשתמש (UDF) ב-FLEDGE? אלו פונקציות שמשתמשי קצה יכולים לתכנת כך שירחיבו את הפונקציונליות של ה-API. | הסבר זמין כאן. אנחנו עדיין עובדים על זה, ולכן נשמח לקבל משוב נוסף על תרחישים לדוגמה. |
| הסרת מגבלת המקור הזהה על משאבים של קבוצות תחומי עניין | בקשה להקל את המגבלה על אותו מקור על משאבים של קבוצת תחומי עניין כדי להפעיל תרחישים מסוימים לשימוש בטכנולוגיות פרסום | בהטמעה הנוכחית של FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl ו-trustedBiddingSignalsUrl חייבים להיות מאותו מקור כמו הבעלים של קבוצת תחומי העניין.האילוץ קיים כדי למנוע פרצות מסוימות על ידי תוקפים, כפי שמוסבר כאן. |
| בעלות על קבוצת עניין | בקשה להגביל את היכולת של טכנולוגיית מודעות להשתמש ב-joininterestGroup לאותן קבוצות תחומי עניין באתרים שונים | אנחנו מתמקדים באופן השימוש בקהלים, לא באופן שבו הם נוצרים. אנחנו דנים בגישות הפוטנציאליות כאן, ונשמח לקבל משוב נוסף. |
| תפוגה של מפתח שרת ערך המפתח | דיון לגבי הסרת מפתחות שרת לאחר תפוגת קבוצות האינטרס המתאימות | אנחנו בודקים דרכים נוספות לטפל בתפוגת התוקף של מפתחות, ונשמח לקבל משוב כאן. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| תנועת הגולשים בתקופת הניסיון בגרסת המקור | התנועה מתקופת הניסיון הנוכחית של המקור לא מספיקה לביצוע בדיקות שימושיות. | גרסאות המקור לניסיון הנוכחיות מיועדות לשחקנים בסביבה העסקית לבצע בדיקות פונקציונליות כדי לוודא שה-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 יפעל בדפים לעיבוד מראש? | רישום השיוך נדחה בדפים לעיבוד מראש עד להפעלה (הקליק או הצפייה בפועל מתרחשים). פירוש הדבר הוא שאנחנו נדחה את הפינג של בקשת 'attributionsrc'. |
| מדידה של עלייה בהמרות | איך מודדים עלייה בהמרות באמצעות בדיקת AB באותו דומיין | אתרים יכולים למדוד עלייה בהמרות באמצעות בדיקות A/B על אותו דומיין דרך דיווח השיוך. הם יכולים לקודד את פרמטרי A/B שלהם כמפתחות באמצעות ה-API המצטבר, ולאחר מכן לקבל דוחות סיכום של ערכי ההמרות לפי קטגוריות המפתח האלה. |
| (גם בדוחות ברבעון 3) המרות חוצות-דומיינים | איך לעקוב אחר המרות חוצות-דומיינים, למשל באמצעות 2 יעדים או יותר | עדכון לרבעון 4: פרסמנו הצעה להסיר את הגבלת היעד של דף הנחיתה שמאפשרת לעקוב אחרי שיחות בכמה דומיינים. הצעה זו יושמה. |
| (מדווח גם ברבעון 3) ההגדרה 'תפוגה' בדוח ההמרות |
בקשה לתמיכה במסנן דוח / בתוקף למשך פחות מ-24 שעות | עדכון לרבעון 4: שיתפנו את בקשת המשיכה הזו שתפריד בין חלונות התפוגה והדיווח כדי לצמצם את הפשרה בין הזמן שחלף מהקליק להמרה לבין תפוגת התוקף של ההמרות. התכונה הזו הושקה עכשיו בגרסה M110. |
| הונאה וניצול לרעה | בקשות ממפרסמים ומשווקים לאפשר פילוח וצבירה של נתונים על סמך האתרים של בעלי אתרים שבהם המודעות שלהם מוצגות. כך תוכלו לקבל תובנות נוספות לגבי שיטות עבודה פוטנציאליות להצגת מודעות שמקורן בתרמית | אנחנו דנים במשוב הזה כאן , ונשמח להוסיף לו פרטים נוספים. |
| (דווח גם ברבעון 3) עיכוב בדיווח ברמת האירוע | עיכוב של יומיים עד 30 ימים בדיווח ברמת האירוע עשוי להיות ארוך מדי לתרחישי שימוש מסוימים. | כברירת מחדל, לדיווח ברמת האירוע יש חלונות דיווח של 2, 7 ו-30 ימים. אפשר לשנות את זה באמצעות הפרמטר 'expiry'. טכנולוגיות פרסום יכולות להגדיר את תפוגת התפוגה, עם יום אחד לפחות, כדי לקבל דוחות פוטנציאליים תוך פחות מיומיים. אנחנו מגבילים את רמת הפירוט של מקרי תפוגה ליום אחד כמנגנון הגנה על פרטיות, כי דיווח מפורט יותר עלול לגרום להתקפות מתוזמנות. כמו כן, אנחנו מאפשרים להגדיר פרמטרים עצמאיים של 'תפוגה' ברמת האירוע ובדוחות המצטברים. כאן מוסבר איך בוחרים אפשרות. כמו כן, ב-Google Ads לא יופיעו חלונות דיווח מיוחדים שלא קיימים טכנולוגיות פרסום אחרות דרך Attribution Reporting API. |
| דרישה זהה של מקור דיווח | בקשה להסרת הדרישה כדי שהמקור של רישום המקור יהיה זהה למקור הרישום של ההמרה | כדי לפתור תרחיש זה, מומלץ להשתמש בהפניות אוטומטיות ב-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)'. |
| עיכוב ההפחתה בסוכן המשתמש עד שהסביבה העסקית של האינטרנט תהיה מוכנה יותר | בקשה לעיכוב ההשקה של ההפחתה בסוכן המשתמש עד לפריסה של Structured User Agents (SUA) | צוות Google Ads הציע את התוספת של סוכן המשתמש המובנה (לעיון במפרט) ל-OpenRTB באוקטובר 2021, והיא הוטמעה בעדכון למפרטים 2.6 שהושק באפריל 2022. יש לנו כמה הוכחות לכך ש-SUA נפרס וזמין היום, כפי שמראים בפוסט בבלוג של Scientia Mobile שהדגים איך להשתמש ב-UA-CH וב-WURFL API כדי ליצור SUA. |
###
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| בדיקת UA-CH באמצעות טכניקות אחרות של מעקב סמוי | הנחיות לבדיקה של כל ממשקי ה-API של ארגז החול לפרטיות והטכניקות ליצירה של טביעת אצבע דיגיטלית (fingerprinting) שהוצעו יחד בגישה הוליסטית | תוכנית הבדיקה שלנו תוכננה כדי לשקף את לוחות הזמנים האסינכרוניים לפיתוח חלק מהאמצעים למניעת טביעת אצבע דיגיטלית, בניגוד לשאר ההצעות של Sandbox. היא מתייחסת למציאות שכמה אמצעים למניעת טביעות אצבע (כמו תקציב פרטיות, הגנה על כתובת IP והקלות במעקב אחר עזיבה מהדף הראשון) יהיו מפותחים ומוכנים להשקה לזמינות לכלל המשתמשים (GA) רק לאחר ההוצאה משימוש של קובצי cookie של צד שלישי. אמנם האמצעים למניעת טביעות אצבע לא ייכללו בבדיקות כמותיות, אבל הם יהיו כפופים להערכה איכותנית על סמך העובדות שהיו זמינות בזמן של היעדר טביעת אצבע. |
| (גם בדוחות ברבעון 2) ביצועים |
חששות לגבי זמן האחזור של קבלת רמזים דרך קריטי-CH (בטעינת הדף הראשון) | מידע ייעודי על UA-CH מופיע בהמשך |
| משוב חסר | יכול להיות שלא יהיה מספיק משוב שהתקבל מהסביבה העסקית לגבי השינוי ב-UA-CH, וזה מוביל לחששות לגבי חוסר מודעות בסביבה העסקית. | שיתפנו באופן יזום את התוכניות שלנו כדי להבטיח השקה זהירה ולצמצם את השיבושים בפעילות. התוכניות של User-Agent Reduction ו-UA-CH API הוצגו ב-18 במרץ 2022 לקבוצת הקהילה נגד הונאות של W3C, וגם לקבוצת העבודה של Web Payments וגם לקבוצת האינטרס של Web Payments Security ב-20 בינואר 2022. לא עלו חששות משמעותיים במהלך המצגת או אחריה. Google עבדה באופן יזום עם יותר מ-100 מפעילי אתרים כדי לקבל משוב. בנוסף, Google השתמשה בערוצי Blink-Dev גם כדי לפרסם באופן ציבורי את ההשקה של הפחתת סוכן המשתמש על סמך משוב מבעלי עניין בסביבה העסקית. |
| תזמון | גורמים שמעלים חששות בנוגע לתזמון ההשקה ולמוכנות התעשייה | מידע ייעודי על UA-CH מופיע בהמשך |
| סטטוס פלטפורמת Chrome | נשלחה בקשה לעדכון דף chromestatus של UA-CH | הערך של chromestatus עודכן ב-19 בדצמבר ל "אותות מעורבים". |
הגנה על IP (לשעבר Gnatcatcher)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| הבעת הסכמה או ביטול הסכמה | האם הבעת הסכמה או ביטול הסכמה בנוגע לפרטיות בכתובת IP? | המטרה שלנו היא לספק לכל המשתמשים הגנה על IP. לאור זאת, אנחנו בוחנים כרגע את האפשרויות של בחירות המשתמשים להגנה על כתובות IP. |
| תרחיש לדוגמה של כתובת IP לנתונים מאינטראקציה ישירה (First-Party) | האם אפשר להשתמש בכתובות IP כדי לחבר את התהליכים שעוברים המשתמשים בדומיינים של צד ראשון אחרי שההגנה על כתובות IP נשמרת? | כפי שפורסם בעבר, ההגנה על כתובות IP תתמקד בהתחלה במעקב בהקשר של צד שלישי, ולא תהיה לכך השפעה על דומיינים של צד ראשון. |
| תרחישים לדוגמה בתחום הפרסום הדיגיטלי | איך חברות יכולות להגדיר אמצעים למניעת הונאה באמצעות הגנה על קניין רוחני? | אנחנו מכירים בחשיבות של כתובת IP כאות למאמצים למניעת הונאה באינטרנט כיום. כחלק מהמחויבויות שלנו ל-CMA (פסקה 20), אמרנו שלא ניישם הגנה על קניין רוחני בלי שנעשה מאמצים סבירים לתמוך ביכולת של אתרים לבצע פעולות למניעת ספאם ומניעת הונאה. אחד מהנושאים שעומדים בראש סדר העדיפויות שלנו הוא להבין איך ההגנה על IP משפיעה על תרחישים לדוגמה ויכולות זיהוי שמשמשים נגד הונאה, כדי שנוכל להשקיע עוד יותר בטכנולוגיות לשמירה על הפרטיות שעוזרות לחברות לשמור על הבטיחות באינטרנט. אנחנו מעודדים שליחת משוב וקבלת הצעות חדשות במטרה לתמוך בצרכים של חברות אבטחה ומניעת הונאה, גם כאשר האותות משתנים עם הזמן. |
| הונאה וניצול לרעה | האם ההגנה על ה-IP כוללת הגנה מפני התקפת מניעת שירות (DoS)? | אנחנו מחויבים לשיפור הפרטיות תוך שמירה על בטיחות האינטרנט, והגנה מפני התקפות מניעת שירות היא תרחיש חשוב למניעת ניצול לרעה. אנחנו מקווים למזער את ההשפעה על ההגנות מפני מניעת שירות (DoS), באמצעות התכנון של ההגנה על ה-IP עצמו וגם באמצעות פתרונות חדשים למניעת ניצול לרעה. מכיוון שהגנה על קניין רוחני מתמקדת בהתחלה בשירותים מוטמעים של צד שלישי, חלק מבעלי העניין ציינו שההשפעה שלה על ההגנה מפני מניעת שירות (DoS) של אתרים של צד ראשון אמורה להיות מוגבלת. עם זאת, אנחנו ממשיכים לבקש משוב ציבורי כדי להעריך את הסיכון למקרי שימוש ב-DoS, במיוחד בשירותים מוטמעים של צד שלישי. במקביל, אנחנו בוחנים מנגנונים של שליחת משוב לרעה וחסימת לקוחות שיאפשרו לאתר או לשירות לחסום משתמש ספאמי, ללא זיהוי של המשתמש. |
| סינון תוכן | סינון תוכן עם הגנה על כתובת IP | לחברות שונות יש צרכים שונים בכל הנוגע לסינון תוכן ולהתאמה אישית של חוויית המשתמש. תרחישי שימוש רבים כאלה אינם מסתמכים כרגע על כתובות IP, ולכן אינם אמורים להיות מושפעים מהגנת IP. לדוגמה, בעל תוכן דיגיטלי שרוצה להתאים את התוכן שלו ולעודד יותר מעורבות יכול להשתמש בקובצי cookie מהדומיין הנוכחי או בקובצי cookie שמחולקים למחיצות (CHIP) של צד שלישי כדי להבין את תחומי העניין של המשתמש ואת האינטראקציות הקודמות שלו עם בעל התוכן הדיגיטלי. לחלופין, שותף טכנולוגיות פרסום שמתמקד בהצגת המודעה המתאימה למשתמש הנכון יכול לשלב את FLEDGE ו-Topics אנחנו גם בוחנים את האפשרות להוסיף יכולות חדשות לשמירה על הפרטיות בהגנה על ה-IP, כמו מיקום גיאוגרפי גס, כדי לתמוך בסינון התוכן במקומות שבהם המנגנונים הקיימים לא מספיקים. נשמח לקבל משוב נוסף לגבי תרחישים לדוגמה לסינון תוכן שעשויים להיות מושפעים מההגנה על ה-IP. |
| (מדווח גם ברבעון השלישי) תרחישים לדוגמה של מיקום גיאוגרפי |
הגנה על קניין רוחני עשויה למנוע שימוש בתרחישים לגיטימיים של מיקום גיאוגרפי בעתיד, כמו התאמה אישית של תוכן על סמך מיקום גיאוגרפי. | עדכון לרבעון 4: אנחנו עובדים עם בעלי עניין כדי להבטיח ש-Chrome ימשיך לתמוך בתרחישים לגיטימיים לשימוש בכתובות IP. אנחנו מבקשים משוב על הסביבה העסקית לגבי רמת הפירוט של מיקום גיאוגרפי של כתובת IP כאן. |
תקציב פרטיות
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| תיעוד ברור יותר | דוגמאות נוספות כדי שבעלי העניין יוכלו לצפות מראש שההגדרות יוגבלו לאחר ההטמעה של תקציב הפרטיות | ההצעה לתקציב הפרטיות עדיין נמצאת בדיון פעיל ולא יושמה על ידי אף דפדפן. התאריך המוקדם ביותר של זמינות מדורגת מייצג את התאריך המוקדם ביותר שבו ניתן היה לאכוף את תקציב הפרטיות. זה לא יקרה לפני ההסרה של קובצי cookie של צד שלישי ב-2024. אין לנו כרגע מסמכים נוספים שנוכל לשתף. כשנקבל החלטה סופית יותר, נשתף פרטים נוספים לגבי ההצעה. בינתיים, אנחנו מזמינים את בעלי העניין לשתף משוב שיעזור להם בפיתוח ההצעה. |
חיזוק גבולות הפרטיות בין אתרים
דומיינים של צד ראשון
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| (דווחה גם ברבעון 3) מגבלת דומיינים | בקשה להרחבת מספר הדומיינים המשויכים | עדכון לרבעון 4: השקנו נתוני FPS לבדיקות מקומיות, כולל תהליך שליחה של סט הדמיה ב-GitHub וסימון לבדיקה מקומית של rSA ו-rSAFor. בנוסף, אירחו שתי פגישות פתוחות למפתחים ב-FPS כדי להמשיך לענות על שאלות של תרחישים לדוגמה בקבוצת המשנה המשויכת. אנחנו ממליצים למפתחים לבדוק את הפונקציונליות של FPS כדי לספק משוב על האופן שבו מגבלת הדומיין בקבוצת המשנה המשויכת תשפיע על נוחות השימוש של ה-FPS בתרחישים לדוגמה שלהם. הבהרנו בשיחות של WICG ש-Chrome מחויב לספק פתרון שמיש ומשקלל גם את האינטרסים של המשתמשים בפרטיות. לכן, אנחנו מודים לכם על המשוב מהקהילה לגבי מקרי שימוש ספציפיים שיכול להיות שמגבלת הדומיין משפיעה עליהם, כדי שהצוות יוכל לשקול דרכים לטפל בתרחישים האלה תוך הגנה על פרטיות המשתמשים. |
| לפרטים נוספים על האמצעים לצמצום הבעיה לניצול לרעה | מה קורה אם מתווסף דומיין לקבוצה שהמשתמשים לא הסכימו לה? | פרסמנו הנחיות להגשת בקשות לדומיינים של צד ראשון כאן ב-2 בדצמבר 2022. כפי שמוסבר בהנחיות לשליחת משוב, כל ניהול שינויים בקבוצות יתבצע בהתאם לתהליך האימות ב-GitHub, כולל אימות בעלות, כדי לצמצם את הסיכון. |
| צמצום מקרי הניצול לרעה | חשש שניתן לנצל תצורות של דומיינים של צד ראשון | אנחנו בוחנים דרכים להרחבת הבדיקות הטכניות לסוגים שונים של תתי-קבוצות, ואנחנו מעוניינים לקבל מידע נוסף מהקהילה כאן. |
| תרחישים לדוגמה במודעות | שאלות אם כדאי להשתמש בקבוצות של דומיינים של צד ראשון כדי לתמוך בטירגוט מודעות | אנחנו לא מנסים לתמוך בתרחישים לדוגמה של טירגוט מודעות לדומיינים של צד ראשון, ומומלץ להשתמש בממשקי ה-API של Google Ads שזמינים בתרחישים כאלה. |
| (מדווחת גם ברבעון השלישי) | חשש ש-FPS לא תואם להתחייבויות של ה-CMA לגבי "החקיקה החלה להגנה על נתונים", על בסיס ה-GDPR שלא מגבילה את מספר האתרים בכל קבוצה, ואילו ב-FPS קובעים הגבלה של 3 אתרים | התשובה שלנו לא השתנתה מהרבעון השלישי: "Google ממשיכה להתחייב ל-CMA לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא מעוות את התחרות על ידי העדפה עצמית של העסק של Google, ו לוקח בחשבון את ההשפעה על התחרות בפרסום בדיגיטל, בעלי התוכן הדיגיטלי והמפרסמים, וכן את ההשפעה על תוצאות הפרטיות ועל עמידה בעקרונות ההגנה על נתונים המפורטים בחקיקה החלה על הגנה על נתונים. הבעיה שצוינה לא חושפת מידע על חוסר תאימות לתקנת ה-GDPR. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה". |
| הצעה חלופית | קבוצות שאומתו על ידי GDPR | בנוסף למשוב שסופק על ידי הסביבה העסקית לגבי ההצעה לאמץ את התכונה 'קבוצות שתואמות ל-GDPR', יש ל-Chrome חששות לגבי המגבלות הבאות של ההצעה החלופית הזו:
כיוון שהחלופה הזו הועלתה, Chrome עדכן את ההצעה של דומיינים של צד ראשון ופרסם הנחיות לשליחה ליצירת קבוצות חדשות. |
ממשק API של Fenced Frames
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| הגבלות על Fenced Frames במהלך ההארכה | מהן ההגבלות הנוכחיות לגבי Fenced Frames בתקופת הניסיון בגרסת המקור? | אנחנו עובדים על מסמכים לגבי ההגבלות וסטטוס ההטמעה, ומתכננים לשתף אותם במהלך הרבעון הראשון של 2023. |
| מודעות מרובות ב-Fenced Frame יחיד | בקשה להציג מספר מפרסמים ב-Fenced Frame אחד במכרז אחד | בשלב זה, הבקשה הזו לא נמצאת בשלבי פיתוח, אבל נשמח לקבל משוב נוסף אם השחקנים בסביבה העסקית מתייחסים לתכונה הזו כחשובה. |
| חבילות אינטרנט | מהן הדרישות והתמיכה המתוכננות עבור חבילות אינטרנט עם Fenced Frames? | בשלב זה, אין לנו עדכון לגבי הדרישה הזו בעתיד. על כל השינויים נודיע מראש ולא ייאכפו לפני ההוצאה משימוש של קובצי cookie של צד שלישי. הסטטוס הנוכחי זמין בהסבר הזה. |
ממשק API לאחסון משותף
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| נפח אחסון משותף לטכנולוגיות פרסום | אי-ודאות בנוגע לשימוש באחסון משותף עבור תרחישים לדוגמה של פרסום דיגיטלי | אפשר להשתמש ב-Shared Storage וב-Private Aggregation API לסוגים שונים של מטרות מדידה שזקוקות למדידה של נפח אחסון באתרים שונים. כאן מפורטות כמה דוגמאות. אנחנו מצפים שספקים של פתרונות DSP ומדידה יהיו המשתלבים העיקריים בתרחישים לדוגמה של שימוש במודעות. |
צ'יפים
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| (דווח גם ברבעון השלישי) דרישה שחולקה למחיצות | צריך להוסיף דרישה להתנהגות מפורשת במאפיין 'מחיצות' בקובצי cookie מהדומיין הנוכחי. | עדכון לרבעון 4: לאחר דיונים שקיימנו קריאות ל-GitHub ול-PrivacyCG, הגענו למסקנה שקובצי cookie עם חלוקה למחיצות (Partitions) שמוגדרים בקובצי cookie מהדומיין הנוכחי ישתמשו במפתח מחיצה (א', א') כאשר A הוא האתר ברמה העליונה. אנחנו נתעד את ההתנהגות הזו בהסבר ובמפרט. |
| ניהול קובצי cookie | האם יש כלים לניהול קובצי cookie של צד ראשון או של צד שלישי או לניהול קובצי cookie של הדומיין? | אפשר להשתמש בכלי הפיתוח ל-Chrome וב- NetLog כדי לבדוק אתרים שמופעלת בהם חסימת קובצי cookie של צד שלישי. שני הכלים מדווחים כשקובצי cookie חסומים בהתאם להגדרות המשתמש. נשמח לקבל משוב על סוג אתרי הביקורת הנוספים שרוצים לראות. |
FedCM
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| ל-IdP נדרש ידע ב-RP כדי לאפשר סשן | בעיה כשמשתמש מנסה להתחבר ל-Fide IdP משני גורמים מוגבלים שונים | כאן אנחנו דנים בפתרונות אפשריים לבעיה הזו. |
| יכולת פעולה הדדית | חששות בנוגע להשפעה של FedCM על הקשר בין משתמשים לבין האתרים שאליהם הם מתחברים באמצעות FedCM, ועל 'יכולת פעולה הדדית' בין אתרים | המטרה של FedCM היא להמשיך לתמוך בשירותי זהות מאוחדת שמסתמכים כרגע על קובצי cookie של צד שלישי גם לאחר שקובצי cookie של צד שלישי יוסרו מ-Chrome. אנחנו צופים ש-FedCM תהיה רק אפשרות אחת שזמינה לשירותים כאלה. ספקי זהויות (IdP) וצדדים מסתמכים (RP) רשאים להשתמש בטכנולוגיות אחרות שמתאימות יותר לצרכים שלהם. נראה שחששות בנוגע לקשר של המשתמש-RP ול'יכולת הפעולה ההדדית' נובעת מחוסר הבנה של ההצעה של FedCM. FedCM משאיר אותו ל-IdP כדי להחליט איזה מידע לשתף עם גורם מוגבל (RP) ובאיזה טופס, לאחר שהמשתמש בוחר להיכנס לאתר של הגורם המוגבל. לפי FedCM, מזהי IdP לא נדרשים "ליצור מזהה פסאודונימי ייחודי לכל [RP] שאיתו המשתמש מבצע אימות". במקום זאת, FedCM פתוח לאפשר לכל IdP לבחור אם לשתף את המזהה האמיתי של המשתמש, גרסה לאתר של המזהה הזה או גרסה אחרת של המידע הזה. (מפרט של FedCM מזהה מתאם חוצה-אתרים כסיכון לפרטיות שמשויך ל-API, ומפורט בו מזהים מכוונים (לכל אתר) כדי לצמצם את הסיכון. עם זאת, ההחלטה אם להשתמש במזהים מופנים נשארת בידי ה-IdP ולא בהתאם לדפדפן). FedCM כבר מספק למשתמשים את אפשרויות הבחירה בנוגע לזהות. לדוגמה, אם למשתמש יש כמה זהויות עם אותו IdP (למשל, פרופיל עבודה ופרופיל אישי), FedCM מאפשר למשתמש לבחור באיזו זהות להשתמש כדי להתחבר לאתר של הגורם המוגבל. מעבר לכך, כל גורם מוגבל (RP) מחליט בעצמו באילו IdP יתמוך באתר שלו. היבט אחד בהחלטה הזו מתייחס למנגנון שעליו מסתמך ה-IdP, בין אם מדובר ב-FedCM או בטכנולוגיה אחרת. שוב, הדפדפן לא מכתיב את האפשרויות האלה לגבי פריטי RP או IdP. |
נלחמים בספאם ובהונאות
ממשק API של אסימון מצב פרטי
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| טיפול בבוטים | מה קורה אם המנפיק מגלה שהונפקו אסימוני מצב פרטי לבוטים? | כדי שאסימונים שהונפקו לבוטים לא יישארו בסביבה העסקית למשך זמן רב, המנפיקים צריכים להחליף את המפתחות שבהם הם משתמשים כדי לחתום על אסימונים באופן קבוע, כך שתוקף האסימונים הישנים שהונפקו בהתאם ללוגיקת ההנפקה האפשרית לא תקין, והאתרים יממשו אסימונים חדשים יותר עם לוגיקת הנפקה מעודכנת. |
| שליחת טפסים באותו אתר | האם אפשר להשתמש באסימוני מצב פרטי עבור שליחות של טפסים מאותו אתר שכוללות ניווט בדף מלא (כלומר Content-Type: application/x-www-form-urlencoded) במקום בקשה מממשקי ה-API של fetch/XMLHttpRequest? | בשלב הזה, האפשרות הזו לא נתמכת בגרסה הראשונה של אסימוני המצב הפרטי. אם יש ביקוש גבוה לתרחיש לדוגמה מהסוג הזה, נשמח לקבל משוב מהסביבה העסקית. |
| אימות בצד השרת | שאלות לגבי אפשרות האימות של אסימוני מצב פרטי בצד השרת | אסימונים מומשו לטובת המנפיק, ולאחר מכן המנפיק יוצר רשומת מימוש שיכולה להכיל את האסימון עצמו או ערך חתום שנגזר מהאסימון. השרתים יכולים להשתמש ברשומת המימוש הזו כדי לאמת את האותנטיות של האסימון. אנחנו צופים שסביבות פעילות שונות של המנפיק יקבעו סטנדרטים שונים לפירוש רשומות המימוש שלהם. |