דוח רבעוני לרבעון 2 של שנת 2023, שמסכם את המשוב לסביבה העסקית שהתקבל לגבי הצעות של ארגז החול לפרטיות והתשובות של Chrome.
כחלק מההתחייבויות שלה ל-CMA, Google הסכימה לספק באופן ציבורי דוחות רבעוניים לגבי תהליך המעורבות של בעלי עניין בארגז החול לפרטיות הצעות (ראו סעיפים 12 ו-17(ג)(ii) של התחייבויות). דוחות סיכום המשוב האלה של ארגז החול לפרטיות נוצרים על ידי צבירת נתונים משוב שהתקבל ב-Chrome מהמקורות השונים, כפי שמפורט במשוב סקירה כללית, כולל, בין היתר: GitHub בעיות, טופס המשוב זמין בכתובת privacysandbox.com, פגישות עם התעשייה בעלי עניין ובפורומים של סטנדרטים באינטרנט. Chrome מקבל בברכה את המשוב שהתקבל מהסביבה העסקית ובוחנים באופן פעיל דרכים לשילוב הלמידה ההחלטות לגבי העיצוב.
נושאי המשוב מדורגים לפי השכיחות לכל API. כדי לעשות את זה, לוחצים על נתונים מצטברים של כמות המשוב שצוות Chrome קיבל בנושא מסוים, ולארגן אותם בסדר יורד של כמות. המשוב הנפוץ זוהו נושאים באמצעות בדיקת נושאי דיון מפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שמופיעים באמצעות הצוותים הפנימיים של Google ובאמצעות טפסים ציבוריים.
באופן ספציפי יותר, פרוטוקולי הפגישות של פגישות אינטרנט רגילות היו נבדקים ולמשוב ישיר, לגבי הרשומות של Google לגבי פגישות 1:1 עם בעלי עניין, הודעות אימייל שהתקבלו למהנדסים בודדים, את רשימת התפוצה של ה-API ואת הציבור אנחנו מביאים בחשבון את טופס המשוב. לאחר מכן Google תאם בין הצוותים מעורבים בפעילויות ההפצה השונות האלה כדי לקבוע את היחסי את השכיחות של הנושאים שעולים ביחס לכל API.
ההסברים על התגובות של Chrome למשוב פותחו מתוך התגובות שפורסמו שאלות נפוצות, תגובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת במיוחד למטרות תרגיל הדיווח הציבורי. שיקוף המוקד הנוכחי של פיתוח ובדיקה, שאלות ומשוב התקבלו במיוחד ביחס ל-Topics, Protected Audience ו-Attribution. ממשקי API לדיווח.
ייתכן שהמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עדיין לא התקבל תגובה נחשבת של Chrome.
מילון מונחים של ראשי תיבות
- CHIPS
- קובצי Cookie עם חלוקה עצמאית למחיצות
- DSP
- פלטפורמה בצד הביקוש
- FedCM
- ניהול של פרטי כניסה מאוחדים
- FPS
- קבוצות של צד ראשון
- IAB
- הרשות לפרסום אינטראקטיבי
- IDP
- ספק זהויות
- IETF
- ארגון המשימות ההנדסה באינטרנט
- IP
- כתובת פרוטוקול האינטרנט
- openRTB
- בידינג בזמן אמת
- הארכה
- גרסת המקור לניסיון
- PatCG
- קבוצה קהילתית של טכנולוגיית פרסום פרטי
- הגורם המוגבל
- הצד הנסמך
- SSP
- פלטפורמה בצד הספק
- TEE
- סביבת ביצוע מהימנה
- UA
- מחרוזת סוכן המשתמש
- UA-CH
- רמזים ללקוחות של סוכן משתמשים
- W3C
- World Wide Web Consortium
- WIPB
- עיוורון של כתובות IP מכוונות
משוב כללי, ללא טכנולוגיה או ממשק API ספציפיים
| עיצוב של משוב | סיכום | התגובה של Chrome |
|---|---|---|
| משילות מידע (data governance) & תאימות לתקנות | הנחיות לסביבה העסקית לגבי שימוש בארגז החול לפרטיות בהתאם לדרישות הרגולטוריות. | כמו בכל טכנולוגיה חדשה, כל חברה אחראית לוודא שהשימוש שלה בארגז החול לפרטיות עומד בדרישות החוק. ל-Google אין אפשרות לספק ייעוץ משפטי. עם זאת, אנחנו מודעים לכך שזהו תחום עניין מרכזי בסביבה העסקית. עבור כל API, פרסמנו מסמכים טכניים מקיפים, שאמורים להיות הבסיס להערכות המשפטיות הנדרשות. אנחנו פועלים כדי להנגיש חומרים נוספים לתמיכה בחברות של חברות מאמצים לפעול בהתאם לדרישות רגולטוריות. |
| הצעה לבדיקה כמותית של CMA | מידע נוסף על ההצעה לבדיקות כמותיות של ה-CMA | אנחנו עובדים בשיתוף עם ה-CMA כדי לתכנן ניסויים שיספקו תמונה לגבי ההשפעה של ההוצאה משימוש של קובצי Cookie של צד שלישי ויישום של ההצעות לארגז החול לפרטיות בסביבה העסקית. באפריל, ה-CMA פרסמה הנחיות כלליות לגבי מה שצפוי במהלך תקופת הבדיקה והניסוי, ואחריה הנחיות מפורטות בחודש יוני. אנחנו מעודדים שליחת שאלות או משוב לגבי ההצעה של ה-CMA לבדיקה כמותית ישירות עם ה-CMA. |
| מצבי בדיקה שמופעלים ב-Chrome | מידע נוסף והבהרות לגבי לוחות הזמנים של הבדיקות | ב-18 במאי פרסמנו פוסט בבלוג שכללנו מידע נוסף על שני המצבים של הבדיקה שמתבצעת באמצעות Chrome. הפרטים האלה לא סופיים, ונפרסם הנחיות נוספות להטמעה במהלך הרבעון השלישי של שנת 2023. |
| אחסון מחולק למחיצות | האם ייעשה שימוש באחסון מחולק למחיצות (Partitions) במהלך בדיקה שמתבצעת על ידי Chrome? | חלוקת האחסון למחיצות תישלח לכל המשתמשים לפני ההוצאה משימוש של קובצי Cookie של צד שלישי. לכן, הניסוי יופעל בכל זרועות הניסוי. לאתרים תהיה אפשרות להפעיל תקופת ניסיון של הוצאה משימוש כדי לקבל שוב אחסון ללא חלוקה למחיצות במהלך התקופה הזו. |
| תמיכה בסביבת הייצור | מהו התהליך שמיושם ב-Chrome כדי לתמוך בבעיות טכניות בארגז החול לפרטיות ובהעברות לטיפול ברמה גבוהה יותר שמשפיעים על הסביבה העסקית? | Google מציעה מגוון ערוצים שמאפשרים לצוותי טכנולוגיות הפרסום לדווח על בעיות ולאפשר העברה לטיפול ברמה גבוהה יותר. מידע נוסף על פורומים ציבוריים ופרטיים לקבלת משוב והעברה לטיפול ברמה גבוהה יותר זמין בפוסט למפתחים. |
| ציר הזמן להרשמה | מסגרת הזמן הנוכחית להרשמה קצרה מדי | אנחנו עדיין בודקים את המועד האחרון לאכיפה ונשמח לשמוע מהסביבה העסקית מהו לוח הזמנים שמתאים יותר. |
| מספר DUNS | מידע נוסף על הדרישה של מספר D-U-N-S להרשמה ולאימות | המשתתפים יכולים למצוא את הדרישות לקבלת מספר D-U-N-S באתר של Dun & Bradstreet. הדרישות משתנות בהתאם לשוק, ולכן המשתתפים צריכים לבדוק באתר לגבי השוק הספציפי שמעניין אותם. עם זאת, באופן כללי, המשתתפים יצטרכו לספק מידע בסיסי על העסק שלהם, כמו שם העסק, הכתובת ופרטים ליצירת קשר עם בעל העסק או המנהל. ייתכן שהמשתמשים יתבקשו גם לספק מידע פיננסי, כמו ההכנסה השנתית של העסק. לאחר שהבקשה תושלם, צוות D&B יבדוק אותה ותנפיק מספר D-U-N-S אם הבקשה תאושר. |
| מעבר מגרסת המקור לניסיון לזמינות לכלל המשתמשים (GA) | האם המעבר מחוויית מקור לתקופת ניסיון לזמינות לכלל המשתמשים ישפיע על הבודקים הנוכחיים של גרסת המקור לניסיון? | החל מיולי, בודקים יוכלו לגשת לממשקי ה-API של המדידה והרלוונטיות שלהם לכלל המשתמשים. כך תהיה חפיפה בין הזמינות של גרסת המקור לניסיון לבין הזמינות לכלל המשתמשים. |
| מחקר של AdExchanger | מידע נוסף על מתודולוגיית הסקר | בסקר התבקשו המשיבים להעריך את שיעורי הסנכרון ואת ההכנסות של העסקים שלהם. של המשיבים הם בדקו את המתודולוגיה למתן מענה על שאלות אישיות. |
| ערכי פרמטרים | איך נקבעים ערכי פרמטרים כמו רמת רעש, ספי אנונימיות ותקציב הפרטיות? | בהודעת ההסבר הזו של GitHub מפורטים העקרונות הכלליים יותר שעומדים מאחורי ממשקי ה-API של ארגז החול לפרטיות. אנחנו עדיין עובדים על ערכים רבים, ונשמח לקבל משוב בנושא הזה. |
הצגת תוכן רלוונטי Google Ads
נושאים
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| שמירה על הפרטיות | מחקר להערכת Topics API בנושא שימור פרטיות | אנחנו מעורבים באופן פעיל בקהילת המחקר, ומציגים את המחקר שלנו לגבי מאפייני הפרטיות של Topics API במאמרים, בדוחות ובמצגות. שמחנו לראות שיותר חברים חיצוניים מקהילת המחקר מעורבים בתחום הזה. Topics API מגן על משתמשים מפני מעקב כללי באינטרנט, כי הוא מקשה מדי על מעקב אחר משתמשים בקנה מידה נרחב. המאמרים האלה מראים שאנחנו מצליחים לעשות זאת בעזרת Topics API. זהו קובץ פרטי יותר מקובצי cookie של צד שלישי, והוא מגן על המשתמשים ועדיין תומך באתרים שהם נהנים מהם. |
| טקסונומיית הנושאים לא מפורטת מספיק | טקסונומיה של נושאים רחבים לא כוללת נושאים מפורטים יותר, כולל נושאים ספציפיים לאזור. | בתגובה למשוב שקיבלנו בעבר מהסביבה העסקית, ב-15 ביוני פרסמנו פוסט בבלוג שבו פירטנו טקסונומיה מעודכנת חדשה שמשולבת בה שיפורים רבים בעקבות משוב מהסביבה העסקית. כחלק מעבודתנו על הטקסונומיה המעודכנת, יצרנו שיתופי פעולה עם מספר חברות בכל הסביבה העסקית, כמו Raptive (לשעבר CafeMedia) ו-Criteo. הטקסונומיה המעודכנת מסירה קטגוריות ששמענו עליהן פחות שימושיות, לטובת קטגוריות שתואמות יותר לתחומי העניין של המפרסמים, תוך שמירה על המחויבות שלנו להחרגה של נושאים שעשויים להיות רגישים. אנחנו מעודדים את הסביבה העסקית לבדוק את הטקסונומיה העדכנית ביותר ולספק משוב על השינויים. |
| תהליך העדכון של הטקסונומיה והסיווג | במאמר הזה מפורט מידע נוסף על קצב הפרסום של הטקסונומיה של Topics והמסווגים, ועל האופן שבו חברות יכולות להתכונן לקראת עדכונים כאלה. | כפי שפורסם בפוסט בבלוג שפורסם לאחרונה, אנחנו צופים שהטקסונומיה תשתנה עם הזמן, ושניהול הטקסונומיה יעבור בסופו של דבר לגורם חיצוני שמייצג בעלי עניין מכל הענף. שיתפנו גם את התוכנית להגדלת נפח החשיפה גם בקבוצה topics-anunce. |
| ההשפעה על אותות מאינטראקציה ישירה | לעלייה במספר הנושאים בעדכון הטקסונומיה האחרון עשוי להיות ערך רב, וכתוצאה מכך להפחית את הערך של אותות אחרים שמבוססים על תחומי עניין מאינטראקציה ישירה. | בדוח של CMA לרבעון הראשון של שנת 2023, "אנחנו מבינים ש-Google דנה בטקסונומיה החדשה עם מספר משתתפים בשרשרת האספקה של טכנולוגיות פרסום. לא כל בעלי התוכן הדיגיטלי גדולים אמרו שתועלת רבה יותר של נושאים תגביר את הלחץ התחרותי על הפתרונות שמבוססים על נתונים מאינטראקציה ישירה (First-Party), אבל נקודת המבט הראשונית שלנו היא שתועלת רבה יותר לטובת התחרות הכוללת – בייחוד היכולת של בעלי תוכן דיגיטלי קטנים להמשיך לייצר הכנסות ממלאי שטחי הפרסום אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. נקודת המבט שלנו תואמת לתגובה הזו של ה-CMA. |
| תועלת לסוגים שונים של בעלי עניין | לטכנולוגיות פרסום שפועלות כפלטפורמות SSP ולפלטפורמות DSP יש יתרונות משמעותיים על פני שחקנים אחרים בסביבה העסקית. | התגובה שלנו ללא שינוי לעומת הרבעונים הקודמים: "Google התחייבה ל-CMA לתכנן ולהטמיע את ההצעות של ארגז החול לפרטיות באופן שלא יעוות את התחרות על ידי העדפה עצמית של העסק של Google, ושיקולי בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי תוכן דיגיטלי ומפרסמים, בלי קשר לגודל שלהם. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שהעבודה שלנו עומדת בהתחייבויות האלה. עם התקדמות הבדיקה של ארגז החול לפרטיות, אחת מהשאלות המרכזיות שנבחן היא הביצועים של הטכנולוגיות החדשות ביחס לסוגים שונים של בעלי עניין. המשוב הוא קריטי בהקשר הזה, ובמיוחד משוב ספציפי ופרקטי שיכול לעזור לנו לשפר עוד יותר את העיצובים הטכניים. עבדנו עם ה-CMA לפיתוח הגישה שלנו לבדיקות כמותיות, ואנחנו תומכים בפרסום של CMA לגבי עיצוב הניסוי כדי לספק מידע נוסף למשתתפים בשוק והזדמנות להגיב על הגישות המוצעות." |
| נושאים צאצאים | כאשר הקריטריונים לבחירת נושא הם תדירות הביקורים בדפדפן, האם פיצול הפילוח יוביל לכך שנושאים שהם צאצאים לא יגיעו אף פעם לראש הרשימה? | Chrome בוחן כרגע מתודולוגיות דירוג אחרות ובוחן אותות אחרים שעשויים לשפר את הדירוג. בהמשך נעביר את התוכניות המעודכנות שלנו לסביבה העסקית. |
| רגישות | המטרה של Topics API היא להבטיח שפרטי המשתמשים שהושגו או נגזרים מ-Topics API יהיו פחות רגישים ממה שאפשר להסיק באמצעות שיטות המעקב הקיימות. | אנחנו סבורים ש-Topics API הרבה יותר פרטי מהטכנולוגיות הנוכחיות, מגביל באופן משמעותי את הזיהוי מחדש של המשתמשים ונועד להחריג נושאים רגישים. אנחנו מבינים שאפשר להתאים נושאים או לשלב אותם עם נתונים מאינטראקציה ישירה (First-Party) כדי ליצור קטגוריות רגישות, אבל אנחנו מאמינים ש-Topics API הוא צעד קדימה להגנה על פרטיות המשתמשים, ואנחנו מחויבים להמשיך לשפר את ה-API. |
| מבנה הטקסונומיה | הוספה של מזהה, ניהול גרסאות ומבנה של מטא-נתונים נוספים לטקסונומיית הנושאים | בשלב הזה, אנחנו כוללים את מזהה הטקסונומיה בתגובת ה-API. כשאנחנו עוברים לניהול לטווח ארוך, כדאי לבדוק את האובייקט Topics ולהוסיף מטא-נתונים נוספים לניהול גרסאות, אם יש בכך צורך. |
| שליטה של בעלי תוכן דיגיטלי | לבעלי האתרים צריכה להיות השפעה על סוגי הנושאים שבהם צריך לסווג את האתרים שלהם. | סיווג שגוי של אתרים עשוי לגרום לאות Topics קצת פחות שימושי בתור אות באופן כללי, אבל האתרים הספציפיים שמסווגים באופן שגוי לא ייפגעו מכך יותר ולא פחות מאתרים אחרים. הסיבה לכך היא שמידע לפי ההקשר של אתר יהיה זמין תמיד עבור מכירות פומביות באתר, שיספקו מידע דומה לנושא הנכון, גם במקרה של סיווג שגוי. נשמח לקבל משוב בנושא הזה. כשמאפשרים לבעלי תוכן דיגיטלי לשלוט בסיווג שלהם, עלולים להיות לכך סיכונים. אתרים עלולים לסווג את האתרים שלהם באופן שגוי באופן מכוון, לצמצם את התועלת לכולם או לקודד משמעויות רגישות בנושאים פחות נפוצים, תוך פגיעה בפרטיות המשתמשים. |
| תוספי Chrome | מתן הרשאה לתוספים ל-Chrome לנהל ולסנן Topics, בדומה לתוספים הנוכחיים של ניהול קובצי cookie | זה כבר אמור להיות אפשרי, כמו שהסברנו ב-GitHub, אבל נשמח לקבל משוב נוסף מהסביבה העסקית. |
| מעבר לזמינות לכלל המשתמשים (GA) | האם תהיה השפעה על Topics API במעבר מגרסת המקור לניסיון לזמינות לכלל המשתמשים? | לא יאבדו נתונים של משתמשים שעוברים מגרסת המקור 'תקופת ניסיון' ל'זמינות לכלל המשתמשים'. |
| פרטיות | שמות המארחים עשויים להכיל מידע פרטי שעלול לחשוף על ידי Topics API | יש לנו כמה הקלות כדי להבטיח את הפרטיות, כפי שמתואר כאן. |
| הונאה וניצול לרעה | איך למנוע מניפולציה של Topics באמצעות ביקורים שמקורן בתרמית | כאן מוסבר על הקלות. |
| מסווג נושאים | האם אתרים יכולים לבקש לשנות את הסיווג של Topics שלהם? | אנחנו מעוניינים לשמוע מהסביבה העסקית בנושא הזה, וכאן אפשר לקבל משוב. |
| אתרים של ספקי נושאים | להגדיר אתרים מסוימים שמארחים תוכן בנושאים רבים כ"אתרים של ספקי נושאים מיוחדים" ואת האימון של המסווגים, לפי התגים שמופיעים בדפי האינטרנט. | אנחנו מדברים כאן על ההצעה, ונשמח לקבל משוב נוסף. |
Protected Audience API (לשעבר FLEDGE)
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| עיצוב תנועה | ההשפעה על הביצועים של סינון מבוסס-SSP כדי לבצע אופטימיזציה של עומס שאילתות לשנייה (QPS) | השקענו הרבה זמן במחשבה על עיצוב תנועה, וההמלצה היא שפלטפורמות SSP ינצלו את השמירה במטמון. |
| בדיקת נפח | מתקשים לבדוק את Protected Audience API כי פלטפורמות SSP ופלטפורמות DSP מתקשים לקבל נפחי תנועה גדולים. | אנחנו כל הזמן יוצרים קשרים עם שותפי SSP ו-DSP כדי לאמץ את התכונה 'קהלים מוגנים' ולבדוק אותם. התחילה זמינות לכלל המשתמשים, ואנחנו בטוחים שאחוז התנועה שמופעלת בה מודעות בהתאמה אישית, יאפשר לשותפים לבצע את הבדיקה בצורה טובה יותר. |
| רמת המורכבות | כדי להטמיע פתרונות Protected Audience API, צריך להשקיע הרבה מאמץ ועלויות. | ברור לנו שקשה להשתמש בטכנולוגיות חדשות, כולל ארגז החול לפרטיות. הצוות של ארגז החול לפרטיות עובד בשיתוף פעולה הדוק עם מגוון רחב של בעלי תפקידים כדי ללמד ולתמוך במאמצים שלהם. הצוות של ארגז החול לפרטיות בודק כל הזמן אילו פתרונות משפרים אחרים יכולים לעזור, כדי לתמוך באימוץ הסביבה העסקית. |
| סביבות הפעלה מהימנות | תמיכה בסביבות ביצוע מהימנות (TEE) בסביבות ענן לא ציבוריות | אנחנו בוחנים אפשרויות תמיכה אפשריות מעבר לפתרונות מבוססי ענן, אבל בשלב הזה לא ניתן לתמוך ב-TEE בארגון עקב מגבלות אבטחה מקומיות שמצריכות הערכה של ארגז החול לפרטיות. לאור דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שעומדים בפני פריסות מקומיות, אנחנו מאמינים שהמשך להרחיב ולשפר פריסות מבוססות-ענן (למשל, תמיכה ב-GCP בנוסף ל-AWS) הוא הגורם המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל ממך משוב נוסף על הסיבה לכך שהדרישה הזו נחוצה. |
| מבנה העלויות | בידינג ו הצעה לשירותי מכרזים תגביר את העלות ואת המורכבות של טכנולוגיות הפרסום בהשוואה למודלים בצד הלקוח. | אנחנו מפתחים כרגע מדריך להערכת העלויות של תמיכה בתהליכי העבודה של הבידינג והמכרזים שרת מכרזים שיהיה קשור לשימוש בטכנולוגיית פרסום, וישיג את אחד מהיעדים של העיצובים שלנו. |
| צירי זמן של K-Anon | מתי המערכת תאכוף את ההגבלות המתוכננות k-anonymity ב-'renderUrl'? | אנחנו עובדים על הסבר לגבי לוח הזמנים לאכיפה שנשיק בקרוב. |
| הגבלות של runAdAuction | האם Chrome יכול להגביל את runAdAuction כך שיהיה אפשר להתקשר רק מהדף העליון? |
אמנם העיצוב שלנו תומך באופן מלא ב-runAdAuction כך שניתן יהיה לקרוא לו קריאה מהדף העליון, אבל אנחנו מאמינים שבעלי אתרים יגבילו את התוכן הזה כך שיהיה ניתן להתקשר אליו רק מהדומיין העליון, בצורה מזיקה יותר.שמענו באופן ספציפי מהסביבה העסקית שארגז החול לפרטיות צריך לצמצם את העומס על בעלי תוכן דיגיטלי ומפרסמים. המשוב הזה תואם לעיקרון הכללי של פיתוח אתרים שבעלי אתרים יכולים להשתמש בכלים של צד שלישי בהפעלת האתרים שלהם. המטרה של ארגז החול לפרטיות הייתה לעודד סביבה עסקית תקינה בלי שתצטרכו לבדוק איך פועלים בעלי תוכן דיגיטלי וטכנולוגיות פרסום. אנחנו מאפשרים לבעל התוכן הדיגיטלי לבחור איך ומי יתקשר אל runAdAuction באתר שלו, וכך אנחנו מאמינים שאנחנו מספקים לבעלי התוכן הדיגיטלי גמישות שמאפשרת להם למצוא את המסלול הטוב ביותר לדרישות שלהם. |
| תמיכה בהטמעה | האם Chrome יכול ליצור הטמעה בקוד פתוח של מכרזים עם כמה אתרי מכירה, או לתרום לה? | המטרה של ארגז החול לפרטיות היא לפתח טכנולוגיות לשמירה על הפרטיות שלא מסתמכות על קובצי cookie של צד שלישי או על מזהים אחרים באתרים שונים. המטרה שלנו היא לעודד סביבה עסקית בריאה בלי שנצטרך לקבוע איך טכנולוגיות הפרסום יפעלו. פרסמנו הנחיה בנוגע לאופן הפעולה של ממשקי ה-API במאגר שלנו ב-GitHub, ואנחנו פתוחים לאפשרות של בדיקת פתרונות עם גורמים בתחום. אנחנו לא מתכננים לפתח אף הטמעה ספציפית, כי המשימה העיקרית שלנו היא לפתח טכנולוגיות פלטפורמה, ולא להכתיב אסטרטגיות לשימוש בטכנולוגיות האלה. הטכנולוגיות שלנו יעזרו לחברות פרסום דיגיטלי לספק ללקוחות את אמצעי ההגנה המתאימים ביותר על הפרטיות, בצורה הטובה ביותר. |
| מכרזים עם כמה אתרי מכירה | Chrome יאלץ שיתוף של 'הקשר' הזוכה במכרזים של רכיבים? | Protected Audience API נועד לאפשר לצדדים שפותחים מכרז עם כמה אתרי מכירה להעביר מידע למכרז של הרכיבים (הערה: רק לפני התחלת המכרז). עם זאת, אין לנו דרך לאפשר לדפדפן להבחין אם פיסת מידע היא הזוכה לפי ההקשר או לא, לכן לא נוכל לאכוף חסימה או לדרוש מידע מסוים. |
| העדפות משתמשים למעקב אחר הסכמה | צוות AdTech שואל את בעלי התוכן הדיגיטלי (PA) איך להטמיע בצורה נכונה מעקב אחר הסכמת משתמשים | התשובה שלנו כוללת את מה שאמרנו ברבעון הראשון: "במודעות ספציפיות, טכנולוגיית הפרסום הרלוונטית היא הגורם המתאים ביותר לאפשר לו לקבוע אילו נכסי קריאייטיב יוצגו או איך הם נבחרים." שוחחנו על כמה תרחישים שקשורים לבעיה הזו במהלך הפגישה של חודש מאי WICG עם Protected Audience, ונשמח לקבל משוב ודיון נוסף בנושא הזה. |
| קהלים בהתאמה אישית | האם Protected Audience API ייתמך בתרחישים לדוגמה של SSP שקשורים ליצירת קהלים בהתאמה אישית? | Protected Audience API מאפשר לספקי SSP וספקי טכנולוגיות פרסום אחרים להיות הבעלים של קהלים בהתאמה אישית ולנהל אותם. אנחנו מפתחים הנחיות נוספות לגבי השילוב של SSP עם ה-API של ה-PA. הנחיות נוספות יהיו זמינות עבור פלטפורמות SSP וספקים אחרים של טכנולוגיות פרסום כדי לתמוך במאמצי השילוב שלהם. |
| פורמטים | האם הסרטון נתמך על ידי Protected Audience API? | מודעות וידאו מוצגות באחת משתי דרכים: כ-XML או כ-HTML של VAST (מודעת וידאו Outstream שבסופו של דבר יכולה לטעון קובץ VAST XML גם לנגן וידאו). הקונים יכולים להחזיר כל אחד מהפורמטים באמצעות כתובת URL לעיבוד. מפרט VAST עודכן לאחרונה כדי לתמוך ב-Attribution Reporting API. אתרים שמציגים מודעות וידאו יצטרכו להתכונן לאופן שבו מודעות מוצגות דרך Protected Audience API. המשמעות היא לוודא שתגי מיקומי המודעות יכולים להעביר את כתובת ה-URL מ-iframe של Protected Audience לנגן הווידאו. בתחום Fenced Frames, נפעל כדי לטפל בצרכים של סרטונים לפני שיהיה צורך להשתמש ב-Fenced Frames לא לפני שנת 2026. |
| קצב | איך פועל התרחיש לדוגמה של קצב ההתקדמות עם Protected Audience API? | תודה על המשוב. נרצה לראות יותר מקרים של הבקשה הזו, עם פרטים נוספים שמגיעים משותפי SSP נוספים, כי עד עכשיו הבעיה הזו השאירה דרור DSP. |
| תדירות עדכון | ייתכן שהתדירות של השיחות מ-dailyUpdate (עד אחת לכל קבוצת תחומי עניין ביום) לא מספיקה לתרחישי שימוש מסוימים, כמו עדכון פרטי מוצר. |
תודה על המשוב. יש פתרונות אחרים שמאפשרים לטכנולוגיות פרסום להשתמש באותות שרעננים בקצבים שונים, כמו חיפושי K/V. |
| בקרת איכות המודעות | איך בעלי תוכן דיגיטלי מטמיעים בקרת איכות של מודעות? | כיום, Protected Audience API מציע לבעלי תוכן דיגיטלי אפשרות לעדכן את מערכות ה-SSP שלהם לגבי אמצעי בקרה מסוימים שהם יכולים להגדיר כחלק מהגדרת המכרז, לפני הצעת המחיר (כלומר רשימות של ישויות שנחסמו על סמך תוויות המשויכות למודעות). נשמח לקבל משוב על פונקציונליות נוספת שהסביבה העסקית עשויה להידרש. |
| ניפוי באגים | מתי הפונקציונליות של forDebuggingOnly תוסר? |
אנחנו מתכננים להוציא משימוש את forDebuggingOnly עקב אירועי אובדן, בעקבות ההוצאה משימוש של קובצי cookie של צד שלישי. אנחנו מתכננים להוציא משימוש את forDebuggingOnly למקרה של זכייה באירועים בשנת 2026 לכל המוקדם. |
| קבוצות תחומי עניין במכשירים שונים | הצעה לאפשר קבוצות של תחומי עניין חוצות-מכשירים לסוכני משתמש מאומתים | אנחנו בודקים את ההצעה הזו, אבל מידת הספציפיות של טירגוט חוצה-מכשירים יוצרת חששות משמעותיים בנוגע לפרטיות, כפי שמתואר בבעיה הזו ב-GitHub. |
| (דווח גם ברבעון 1) רימרקטינג דינמי | האם יהיה אפשר להשתמש ברימרקטינג דינמי עם Protected Audience API אחרי ההוצאה משימוש של קובצי Cookie של צד שלישי? | אנחנו מאמינים שאפשר להשתמש בתרחיש לדוגמה הזה באמצעות Protected Audience, כפי שמוסבר כאן. |
| נתונים קשורים לקליקים | הוספת נתונים שקשורים לקליקים אל browserSignals. |
כרגע אנחנו מבקשים הבהרה לגבי המועד שבו התרחש הקליק כדי לספק מיקום ראשוני. |
| (דווחו גם ברבעון הרביעי של 2022) פונקציות בהגדרת המשתמש ב-Protected Audience | איך תהיה תמיכה בפונקציות בהגדרת המשתמש (UDF) ב-Protected Audience API? אלו פונקציות שמשתמשי קצה יכולים לתכנת כדי להרחיב את הפונקציונליות של ה-API. | גם מומחי הפרסום שהעלו את הבעיה ציינו שהם עדיין בודקים מה ניתן לעשות עם UDF, כך שאין כאן עדיין משוב פרקטי שצריך להגיב עליו, לא לפחות עד לזמינות לכלל המשתמשים. |
| מטבע | אין לייצג סכומי מטבע באמצעות נקודות צפות. | טיפלנו בבעיה הזו כאן בפירוט. |
| יכולות לבחירת מודעות שאינן DSP | איך שרתי מודעות ממלאים במכרזים של Protect Audience API? | אנחנו מודעים לבקשות שנשלחות משרתי מודעות להמשיך להציע שירותי בחירת מודעות לאחר הגשת הצעות המחיר / שירותי אופטימיזציה של קריאייטיב דינמי. אנחנו בודקים כרגע את ניתוח הפערים המפורט שקיים בין Protected Audience API הנוכחי לבין הבקשות האלה. |
| GenerateBid | תמיכה ל-Google Ads הצעה להחזיר יותר ממודעה מועמדת אחת לכל קבוצת עניין במודעה מתוך generateBid, ולקבל דירוג של המועמדים האלה ב-'scoreAd'. |
הבעיה הזו נמצאת כרגע בבדיקה. נשמח לקבל משוב נוסף. |
| הזמנה במכירה פומבית | האם המכרזים של Protected Audience API צריכים להיות האחרונים שיתרחשו כדי לקבל נתונים על התוצאות של כל המכרזים האחרים? | אין דרישה טכנית כדי ש-Protected Audience API יפעל לאחרונה. |
| ניווט שאינו ביוזמת המשתמש | חשיפת ניווט שלא ביוזמת המשתמש | אנחנו בודקים את הבקשה ודנים בה כאן ונשמח לקבל משוב נוסף. |
| שמירה במטמון | אם מצב המשתמש משתנה, מערכת SSP לא יכולה ליצור מהמטמון 'perBuyerSignals' של DSP מסוים. | אנחנו מבינים ששמירה במטמון לא מתאימה לכל תרחיש לדוגמה של אותות לכל קונה, ואנחנו בודקים אפשרויות נוספות. נשמח לקבל משוב נוסף מהסביבה העסקית כדי להבין אם שמירה במטמון יכולה להתאים לתרחישים לדוגמה שלהם. |
| דוחות שיוך (Attribution) וקהל מוגן | איך Attribution Reporting API ו-Protected Audience API יכולים לפעול יחד? | כרגע אפשר להשתמש בשילובים ב-Protected Audience API בשני המצבים של Attribution Reporting API (דוחות ברמת האירוע ודוחות סיכום). ב-1 ביוני שיתפנו מידע נוסף על השילוב המשופר של Protected Audience API ו-Attribution Reporting. תוכלו לקרוא עליהם כאן. |
| נקודת קצה (endpoint) של שרת | האם נקודת הקצה של השרת תהיה שרת הצבירה המהימן בעיצוב הסופי? | נקודת הקצה (endpoint) של השרת היא נקודת קצה שמתנהלת בטכנולוגיית פרסום, שלא תלויה בשרתי הצבירה המהימנים שמשמשים לעיבוד הדוחות שנאספו ושעברו שינויים. בשלב זה, אנחנו לא מתכננים שינויים בנקודת הקצה של הדיווח. מטרת העיצוב הנוכחי היא לוודא שהדוחות המצטברים (עם מטענים ייעודיים מוצפנים) לא ידלפו נתונים מאתרים שונים, כך שלא יהיה צורך בנקודת קצה מהימנה. סיבוך נוסף הוא שסביר להניח שלטכנולוגיות פרסום שונות יהיו אסטרטגיות קיבוץ רצויות שונות. נשמח לקבל משוב נוסף. |
| WebIDL | המפרט הנוכחי של Protected Audience API לא תואם למפרט WebIDL. | אנחנו בודקים את המשוב הזה ומדברים על הבעיה כאן. |
| ניהול הסכמה | איך תטופל ההעברה של אותות הסכמה ב-Protected Audience API? | מידע לפי הקשר לא נכלל ב-Protected Audience API. אנחנו מדברים על הבעיה הזו ונשמח לקבל משוב נוסף. |
| שיווק מבוסס-חשבון | האם ניתן יהיה להשתמש בתרחישים לדוגמה של שיווק מבוסס-חשבון? | Protected Audience API תומך במגוון תרחישים לדוגמה של שיווק מבוסס-קהלים. אנחנו ממשיכים להבין איך Protected Audience API יכול לתמוך בצורה הטובה ביותר בתרחיש לדוגמה הזה, ונשמח לקבל משוב נוסף על הבעיה הזו מהסביבה העסקית. |
| מכרז רכיבים | מהו הדירוג של הרכיבים שמשתתפים במכרז? | המכרזים של הרכיבים לא מדרגים את הקבוצות של תחומי העניין באופן ישיר. הם מדרגים את המודעות ואת הצעות המחיר ששירות DSP שולח מהפונקציה generateBid. הפונקציה generateBid() פועלת לכל קבוצה של תחומי עניין, וה-DSP מחזיר את הערך הבא כשמריצים את generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| תרומות חיצוניות | בקשה לתמיכה בתרומות חיצוניות על בסיס קוד GitHub של מפתחות/ערך. | אנחנו רוצים לעדכן את התהליכים הרלוונטיים כדי לתמוך בתרומות חיצוניות לקוד GitHub. |
| גודל קבוצת תחומי העניין | מהו המספר המקסימלי הנתמך של מפתחות ש-IG יכול לתמוך בהם? | המגבלה הנוכחית היא 50kb על הגודל של IG אחד, והמפתחות נספרים כחלק מזה. נשמח לקבל דיון נוסף בנושא מגבלת הגודל. |
| קיבוץ | איך אפשר להפחית את מספר הקריאות לשרת K/V? | אפשר להשתמש בכותרות של HTTP Cache-Control כדי לצמצם את מספר הקריאות ל-K/V. לדוגמה, אפשר לשמור אותו במטמון במכרזים של רכיבים, וגם במיקומי מודעות בדף יחיד. |
| ניהול הגרסאות | תמיכה בגרסאות מרובות של קוד טכנולוגיית פרסום (AdTech) | שירותי בידינג ומכרזים יתמכו בכמה גרסאות של קוד טכנולוגיית פרסום (ATP). ב-בידינג וב-Auction API, הבקשה SelectAd יכולה לציין את גרסת הקוד שבה נעשה שימוש בבקשת המכרז (כלומר, לבידינג / למכרז וגם לדיווח). |
| Shared Storage | תמיכה בכתיבה לנפח אחסון משותף בשירות הבידינג והמכרזים. | בשלב הזה, שירותי בידינג ומכרזים לא תומכים בנפח אחסון משותף, אבל נשמח לקבל משוב נוסף על החשיבות של תרחישים לדוגמה כאלה לסביבה העסקית. |
| מאתר לאפליקציה | לתמוך בשיתוף של קבוצות אינטרס מהאתר לאפליקציה. | התכונה 'אינטרנט לאפליקציה' לא נכללת כרגע בפריסה של Protected Audience API ב-Chrome וב-Android, אבל אנחנו רוצים לשמוע מהסביבה העסקית על החשיבות של התרחיש לדוגמה הזה. |
| K-אנונימי | איך מטפלים בחלופות מסוג K-Anonymity | אנחנו מדברים על הבעיה ונשמח לקבל משוב נוסף. |
מדידה של מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| הגדרות של דוחות חלופיים ברמת האירוע 'המרות בעקבות צפייה' | משוב על הגדרות חלופיות של דוחות ברמת האירוע של המרות לאחר צפייה (VTC) | קיבלנו משוב על כך שההגדרות הנוכחיות ברמת האירוע לא אופטימליות, ואנחנו מבקשים משוב על הגדרות גלובליות אופטימליות. נשמח לקבל משוב נוסף בנושא, ואנחנו חושבים שהסבר גמיש ברמת האירוע עוזר גם לטפל בבעיה. |
| הגדרות גמישות ברמת האירוע | מה הסטטוס של תכונת ההגדרות הגמישות ברמת האירוע? | שיתפנו מסמכים בנושא הגדרה גמישה ברמת האירוע. התכונה עדיין בשלב ההצעה ואנחנו מחפשים משוב נוסף כדי להבין אם התכונה תהיה בעלת ערך לסביבה העסקית. |
| הגדרות גמישות ברמת האירוע | איך אפשר ליישב דיווחים סותרים מגורמים שונים? | הטיפול ברוב תרחישי הדיווח נעשה באמצעות דוחות נצברים. לעומת זאת, ההצעה להגדרה גמישה ברמת האירוע מיועדת במיוחד לקבלת גמישות נוספת עבור דוחות ברמת האירוע, שמשמשים בדרך כלל בתרחישים לדוגמה של אופטימיזציה. נשמח לקבל תגובות או משובים נוספים לגבי הסביבה העסקית. |
| רישום מקור | מה קורה אם רישום המקור קורה לאחר רישום הטריגר? | נכון לעכשיו, אם רישום מקור מתרחש אחרי רישום הטריגר, לא ניתן יהיה לשייך את המקור והטריגר זה לזה. נראה שזה תרחיש קיצוני. נשמח לקבל כל משוב נוסף בנושא, ונטפל בו אם מדובר בתרחיש שבו רבים מהטכנולוגיות של פרסום מודעות נתקלים בו. |
| עבודה עם מספר סוכנויות פרסום | איך מערכות DSP יכולות להשתמש ב-Attribution Reporting API כשמפרסמים עובדים עם כמה סוכנויות פרסום? | ה-API תומך בהפניות לכתובות אחרות, ולכן ניתן להשתמש בו גם כשהמפרסם עובד עם מספר סוכנויות פרסום. בנוסף, חלות כמה מגבלות לגבי הפניות אוטומטיות כדי לוודא שה-API משפר את הפרטיות. זיהינו גם פתרון אפשרי לעקיפת ה-API של נפח אחסון משותף לתרחיש הספציפי שהעלו טכנולוגיית הפרסום. נשמח לקבל כל משוב נוסף לגבי התרחיש הזה. נמשיך לפתח את המשוב הזה על סמך המשוב הזה. |
| מגבלות של יעדים | תרחיש לדוגמה של מודעות שהרענון שלהן מתבצע באופן אוטומטי, עשוי להיות מושפע ממגבלות יעד. | שוחחנו על הבעיה הזו בפגישה של WICG ב-1 במאי, ורצינו לקבל משוב לגבי מגבלה סבירה. הוספנו להסבר על דוחות השיוך (Attribution) עם דוחות ברמת האירוע, שלפיו הדפדפן יכול להגביל את מספר הדומיינים מסוג eTLD+1 של 'יעד' שמיוצגים על ידי אתרי מקור. (ראו בקשת משיכה). |
| דוחות שיוך (Attribution) וקהל מוגן | איך Attribution Reporting API ו-Protected Audience API יכולים לפעול יחד? | נכון לעכשיו, השילובים זמינים ב-Protected Audience API בשני המצבים של Attribution Reporting API (דוחות ברמת האירוע ודוחות סיכום). ב-1 ביוני שיתפנו מידע נוסף על השילוב המשופר של Protected Audience API ו-Attribution Reporting. תוכלו לקרוא עליהם כאן. |
| הגדרות גמישות ברמת האירוע | כדאי לשתף שיטות מומלצות לסימולציית רעשים עכשיו, כשהפרמטרים ניתנים להגדרה. | יש לנו קוד משותף ב-GitHub שכל אחד יכול להשתמש בו כדי להעריך את תוספת המידע ואת השפעת הרעש בהתאם להגדרות הגמישות ברמת האירוע שהם רוצים לבדוק. נשמח לשמוע מכל מי שבוחר לבדוק באמצעות הקוד ולשתף משוב. |
| מדידת שיוך (Attribution) חוצה אפליקציות ואתרים | מתי תהיה אפשרות להשתמש במדידה של שיוך באתרים שונים ובאפליקציות? | ב-9 במאי הודענו על ניסוי ב-Attribution Reporting API באפליקציות ובאתרים שונים. אנחנו מתכננים להוסיף את התכונה 'זמינות לכלל המשתמשים' (GA) לרלוונטיות ולמדידה של ממשקי ה-API ב-Chrome 115, אבל בשלב הזה אנחנו לא מתכננים להרחיב את הזמינות של מדידת שיוך באפליקציות שונות ובאתרים שונים עם Chrome 115. |
| ביטול כפילויות בהמרות | איך אפשר להתאים פתרונות מדידה עצמאיים מול ARA? | כמו בשיטות הרגילות הקיימות, מפרסמים עובדים עם ספק צד שלישי של שירותי מדידה בלתי תלוי כדי לבטל כפילויות בדיווח על המרות. אנחנו מציעים משאבים לביטול כפילויות של המרות בדוחות ברמת האירוע. |
| אובדן נתונים במהלך עדכונים במסד הנתונים של דוחות השיוך (Attribution) | האם תאבדו נתונים כש-Chrome יעדכן את מסד הנתונים של דוחות השיוך (Attribution) כפי שהוכרז? | החל מגרסה 115 היציבה של Chrome, נתחיל להפעיל את ממשקי ה-API של רלוונטיות ומדידה עבור חלק ממשתמשי Chrome כברירת מחדל. הזמינות הכללית הזו תגבר ככל שנעקוב אחר בעיות אפשריות. היעד הוא להגיע ל-100% זמינות לאורך תקופה של שבועות, עד הרבעון השלישי של שנת 2023. השינוי הזה יתבצע במקביל לסיום של ניסוי המקור לרלוונטיות ולמדידה. החל מיולי, בודקים יוכלו להירשם לקבלת גישה לממשקי ה-API האלה בזמינות לכלל המשתמשים. כך תהיה חפיפה בין הזמינות של גרסת המקור לניסיון לבין הזמינות לכלל המשתמשים באמצעות הרשמה. אסימון המקור לניסיון יהיה בתוקף עד 19 בספטמבר, אבל מומלץ להירשם לממשקי ה-API לפני התפוגה כדי לצאת באופן חלק מגרסת המקור לניסיון, בלי להפסיק את הבדיקות המתמשכות. כפי שצוין בהודעה הזו, הנתונים שנרשמו בגרסאות ישנות יותר (M113 ודגמים קודמים) לא יועברו אחרי העדכון, ולכן יכול להיות שתאבדו נתונים. אובדן הנתונים הזה לא יופיע בדיווח על תוצאות ניפוי הבאגים, ואנחנו ננסה למנוע אובדן נתונים בגרסה 114 עד 115. |
| חיוב | שימוש בדוחות שיוך (Attribution) לחיוב לפי עלות להמרה | כפי שצוין במאמר הזה, יכול להיות ש-Attribution Reporting API לא מתאים לצורכי חיוב של עלות להמרה, בגלל הרעש שנוסף לדוחות ברמת האירוע ולדוחות הסיכום. אנחנו מעודדים את השחקנים בסביבה העסקית לשתף משוב על ההשפעה על מודלים שונים של חיוב באמצעות Attribution Reporting API ב-GitHub. |
Aggregation Service
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| שינוי עיכוב בדוחות המצטברים | תגובות חיוביות להצעה לשינוי העיכוב בדוחות המצטברים להיות בין [10-60 דקות] ל-[0-10 דקות] בעקבות משוב מהסביבה העסקית | אנחנו שמחים לראות תגובה חיובית לשינוי המוצע, ומעודדים את הסביבה העסקית להמשיך לספק משוב על ההצעות שלנו. |
| פתרון מקומי | האם אפשר לפרוס את שירות הצבירה במרכזי נתונים בארגון? | אנחנו בוחנים אפשרויות תמיכה אפשריות מעבר לפתרונות מבוססי ענן, אבל בשלב הזה לא ניתן לתמוך ב-TEE בארגון עקב מגבלות אבטחה מקומיות שמצריכות הערכה של ארגז החול לפרטיות. לאור דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שעומדים בפני פריסות מקומיות, אנחנו מאמינים שהמשך להרחיב ולשפר פריסות מבוססות-ענן (למשל, תמיכה ב-GCP בנוסף ל-AWS) הוא הגורם המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל ממך משוב נוסף על הסיבה לכך שהדרישה הזו נחוצה. |
| עיבוד מחדש של דוחות לתקופות זמן שונות | יכולת לעבד מחדש דוחות לתקופות זמן שונות | קיבלנו בקשות דומות לפיצול קבוצות לפי טווחי תאריכים שונים. אחת מההצעות היא לאפשר למשתמשים להרחיב את המזהה המשותף באמצעות תווית שהוגדרה על ידי טכנולוגיית הפרסום, כך שהדוחות יפוצלו לקבוצות שונות. אנחנו בשלב מוקדם של הערכת התהליך הזה, ונעדכן את הסביבה ככל שההצעה תמשיך. |
| ההשלכות על הפרטיות של סביבת ביצוע מהימנה | סנטימנט חיובי בנוגע להשלכות על הפרטיות של סביבות ביצוע מהימנות | אנחנו שמחים לשמוע על תגובות חיוביות מהסביבה העסקית להצעות שלנו, ונשמח לקבל משוב נוסף כשנמשיך לפתח את הערוץ. |
| תנאים והגבלות | מהו המועד האחרון לאישור התנאים וההגבלות של שירות הצבירה? | אמנם עדיין לא הכנו מועד אחרון לאישור התנאים וההגבלות, אבל אנחנו ממליצים לחברות של סביבה עסקית לאשר את התנאים וההגבלות בהקדם האפשרי כדי למנוע עיכובים בהרשמה. אנחנו ממליצים לחברות לפנות אלינו אם יש להן שאלות. |
| גילוי מפתחות | תכונת הגילוי העיקרי תאפשר לבודקים להריץ שאילתות בדוחות נצברים בלי שיצטרכו רשימה מפורשת של שילובי מקשים אפשריים, כדי לעבד דוחות סיכום של שיוך חוצה-רשתות, לשיפור הביצועים והדיוק. | אנחנו בוחנים כרגע פתרונות אפשריים ופתרונות אפשריים, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
Private Aggregation API
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| מקור הדיווח | איך מוגדר מקור הדיווח? | מקור הדיווח הוא תמיד מקור הסקריפט של הגורם שמפעיל את הצבירה הפרטית. |
| רווח למפתחות של 128 ביט | בהירות לגבי מגבלת נפח המפתחות של 128 ביט | אנחנו נהפוך את מגבלת מרחב המפתחות הזו לברורה יותר ונפתור את חוסר העקביות בין הדפים. מומלץ להשתמש באסטרטגיות גיבוב (hashing) כדי להישאר במרחב המפתחות הזה. |
| תרומה מקסימלית לכל דוח | המגבלה הנוכחית של 20 פריטי תוכן לכל דוח נמוכה מדי. | במקום להגדיל את המספר המקסימלי של תכנים שנוספו, אנחנו מוכנים לשקול לפצל את הדוחות במקום לצמצם את המגבלה. אנחנו נערב את הסביבה העסקית בזמן שההצעה הזו מתפתחת. |
| דיווח על היקף החשיפה | בקשה לדיווח על היקף החשיפה בפלטפורמות שונות/מכשירים שונים. היקף החשיפה הוא מדד בסיסי בפרסום של מותג. מפרסמים מסתמכים על הערכות בפלטפורמות שונות ובמכשירים שונים כדי לדווח על היקף החשיפה והתדירות כדי לנתח את הקמפיינים ולהקצות הוצאות. המודלים של היקף החשיפה משתמשים בקובצי cookie של צד שלישי כאות למדידת מודעות שמוצגות בסביבות של צד שלישי. לכן, טכנולוגיות הפרסום ביקשו פתרון חלופי אחרי שקובצי cookie של צד שלישי יצאו משימוש. |
הצוות של ארגז החול לפרטיות בודק תכונות שיתמכו במתודולוגיות של היקף החשיפה בכמה דומיינים אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. נשמח לקבל משוב נוסף מהסביבה העסקית. |
הגבלת מעקב סמוי
הפחתת סוכני משתמשים/רמזים ללקוחות על סוכני משתמשים
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| (דווח גם ברבעון הראשון של 2023) טיפים לגורמי צורה נוספים | בקשה לרמזים על הלקוח של סוכן משתמש (UA-CH) שיספקו גורמי צורה נוספים כמו טלוויזיה, VR | אנחנו עדיין עובדים על כמה החלטות עיצוב מרכזיות (בין אם לספק ערך יחיד כמו "TV" או רשימה של יכולות מתקדמות), אבל עדיין רוצים ליצור את האב טיפוס של הרעיון הזה. |
| מכסת פרטיות | הגבלות של תקציב הפרטיות עלולות לגרום לכך שבקשות UA-CH לא יהיו חד-משמעיות כשנשלחות יותר מדי בקשות. | בשלב זה אין לנו עדכונים חדשים לגבי ההצעה לתקציב הפרטיות, אבל התחייבנו לא להגביל את הבקשות לקבלת רמזים של לקוחות UA לפני שקובצי Cookie של צד שלישי יצאו משימוש. |
| תאימות האתר | אתרים משתמשים במותג UA-CH כדי להגביל את הגישה של דפדפנים מסוימים לאתרים. | יש תרחישים תקינים לדוגמה של רשימת מותגים, ואחד מהם הוא תאימות מדויקת. ב-UA אפשר להשתמש בחינם בכמה מותגים כדי לפתור את הבעיות האלה. |
IP Protection (לשעבר Gnatcatcher)
| עיצוב של משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הונאה ו- התנהלות פוגעת | איך חברות יכולות להגדיר אמצעים למניעת הונאה באמצעות 'הגנה על כתובת ה-IP'? | אנחנו מבינים את החשיבות של תרחישים לדוגמה למניעת הונאות ואת ההשפעה האפשרית על התרחישים האלה. אנחנו מתכננים לפרסם פרטים נוספים על תמיכה במניעת הונאות בהמשך הקיץ. אנחנו מבקשים משוב בסביבה העסקית כדי להבין איך נוכל לתמוך טוב יותר בתרחישים לדוגמה למניעת הונאות. |
| GeoIP | מידע נוסף על לוח זמנים לבדיקה ולפריסה של GeoIP | לאחרונה פורסם ב-Chrome מידע חדש שמפרט את תוכניות GeoIP שלנו. אנחנו מתכננים לפרסם מידע נוסף על לוחות הזמנים לפריסות ברבעון השלישי. אנחנו צופים שנשיק את התכונה 'הגנה על כתובת ה-IP' כתכונת בקשת הסכמה למשתמשים בקרב אחוז קטן מתנועת הגולשים. הסיבה לכך היא שאנחנו מבינים שההצעה הזו עשויה לכלול שינויים משמעותיים עבור החברות, ואנחנו רוצים לתת לסביבה העסקית זמן להסתגלות ולספק משוב לפני השקה רחבה יותר של התכונה. |
| אימות חשבון | איך יפעל בדיוק אימות החשבון באמצעות שרת ה-proxy? | אנחנו מתכננים לפרסם פרטים נוספים על אימות חשבונות בהמשך הקיץ, למרות שכבר שיתפנו כמה שיקולים ראשוניים. |
הפחתת המעקב אחר עזיבה מהדף הראשון
| עיצוב של משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הנחיות לביצוע בדיקה | מידע על האופן שבו אפשר לבדוק את ההקלות במעקב אחר עזיבה מהדף הראשון | במאי פרסמנו פוסט בבלוג שכולל מידע נוסף על האופן שבו אפשר לבדוק את ההפחתה של המעקב אחר עזיבה מהדף הראשון. |
| מאמרי עזרה | בהירות בהצעה למעקב אחר עזיבה מהדף הראשון | ההצעה הנוכחית נמצאת בשלבי פיתוח ו-Chrome ממשיך לעדכן את ההצעה כדי לספק הבהרות ומידע לסביבה העסקית. אנחנו פועלים כדי לספק פרטים נוספים ונשמח לקבל כל משוב נוסף. |
| מחיקה של קובצי cookie | האם התכונה 'הקלות במעקב אחר עזיבה מהדף הראשון' תמחק את כל קובצי ה-cookie בדומיין? | הפחתת המעקב אחר עזיבה מהדף הראשון (BTM) תגרום לניקוי כל האחסון וכל המטמון, כפי שמוסבר כאן. |
| עקיפת הקלות במעקב אחר עזיבה מהדף הראשון | כדי לעקוף את הסיווג של הכלי למעקב אחרי עזיבה מהדף הראשון, אפשר לבצע הפניות אוטומטיות דרך חלונות קופצים או כרטיסיות חדשות. | מפרט ההקלות של המעקב אחר עזיבה מהדף הראשון עדיין נמצא בשלבי פיתוח. עד עכשיו התמקדנו בעיקר בהפניות מחדש באותה כרטיסייה, אבל אנחנו מתכננים לעבוד על תהליכים בחלון קופץ בעתיד. נשמח לקבל משוב נוסף. |
מכסת פרטיות
| עיצוב של משוב | סיכום | התגובה של Chrome |
|---|---|---|
| מיקוד לפי קירבה | תקציב הפרטיות עשוי להשפיע על תרחישים לדוגמה של טירגוט לפי קרבה. | קיבלנו משוב בנושא הזה ונשמח לשמוע על ההשפעות הפוטנציאליות של הסביבה העסקית. |
חיזוק של גבולות הפרטיות באתרים שונים
דומיינים של צד ראשון
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| (דווח גם ברבעונים קודמים) מגבלת דומיין | בקשה להרחבת מספר הדומיינים המשויכים | דפדפן Chrome מעריך את המגבלה המספרית המתאימה לקבוצת המשנה המשויכת, שיאזן בין הפרטיות לבין התועלת בתרחישים לדוגמה שזוהו. בהתחלה, דפדפן Chrome שיתף שמספר המדויק של קבוצת המשנה המשויכת עדיין לא הושלם. |
| תרחיש שימוש מוטמע | תמיכה בתרחישים לדוגמה מוטמעים שדורשים דומיינים של צד ראשון, CHIPs ואחסון משותף | הצוות של Chrome קיבל משוב על התרחיש לדוגמה הזה, והצוות בודק את העניין ומבקש משוב נוסף. |
| ניהול מאגרים | מידע על כללי מדיניות להסרת דומיינים של צד ראשון ממאגר GitHub אם יש פערים או הזנחה | התקבל משוב על התרחיש לדוגמה הזה ב-Chrome. הצוות בודק את העניין ומבקש לקבל משוב נוסף. |
| הדרכה למשתמשים | כדי לעודד שימוש בקבוצות מאינטראקציה ישירה (First-Party), דפדפן Chrome צריך להגביר את המוּדעוּת ואת ההבנה של המשתמשים לגבי קבוצות מאינטראקציה ישירה. | Chrome מחויב לספק למשתמשים מידע על דומיינים של צד ראשון. פורסם גם מאמר במרכז העזרה (שמקושר לממשק המשתמש של Chrome). אנחנו משקיעים ב-Chrome גם להמשיך ללמוד איך ללמד את המשתמשים בצורה הטובה ביותר בהקשרים המתאימים. |
| פרסום קובץ 3PCD | קובצי cookie של צד שלישי ימשיכו להיות קיימים בדומיינים של הצד הראשון אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. | requestStorageAccess ו-requestStorageAccessFor אכן הופכים קובצי Cookie של צד שלישי לזמינים שוב לתרחישי שימוש ספציפיים ומוגדרים בבירור, אבל עכשיו הם דורשים הפעלה פעילה על ידי האתר, במקום שיהיו זמינים כברירת מחדל, כמו במצב הנוכחי של קובצי Cookie של צד שלישי (ב-Chrome).הפעלה כזו בקבוצה יחידה לא תדרוש אישור משתמש, אבל המשתמשים יכולים למנוע זאת על ידי ביטול ההסכמה להתנהגות הזו ב'הגדרות'. מידע נוסף זמין למשתמשים במאמר הזה במרכז העזרה (הקישור אליו מופיע בממשק המשתמש של Chrome). אנחנו מתכננים להרחיב את השימוש במדריך למפתחים הקיים כשקצב ה-FPS יעלה עד 100%. |
| שליחת דומיינים של צד ראשון | צריך לשנות את השם של .well-known/first-party-set הנדרש כך שיכלול תוסף מסוג json. |
ביצענו את השינוי הזה כדי להבטיח שתוכניות מסוימות של אירוח באינטרנט נתמכות. |
| רישום IANA | first_party_sets.JSON צריך להיות רשום ב-IANA |
אנחנו שוקלים את ההצעה ונשמח לקבל משוב נוסף. |
ממשק API של Fenced Frames
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| חסימת מודעות | השימוש ב-Fenced Frames עשוי להקל על חסימת מודעות לחסום מודעות. | תוספים יכולים ליצור אינטראקציה עם מסגרות מגודרות באופן דומה לאופן שבו הם היו יוצרים אינטראקציה עם מסגרות iframe. גם כתובת ה-URL בפועל שאליה המערכת מנווטת במסגרת הגבולות תהיה גלויה לתוספים, ולכן הם יוכלו להחיל כל כלל התאמה לכתובות URL לחסימה, כמו במסגרות iframe. חסימה של כל הפריימים הגודרים ללא תנאי עלולה לגרום לשיבושים בתרחישים לדוגמה שאינם קשורים למודעות של פריימים עם גבולות. |
Shared Storage API
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| אימוץ נרחב יותר | 'אחסון משותף' צריך להיות תקן מקובל בתחום שזמין בכל הדפדפנים. | אנחנו שמחים לקבל את המשוב הזה ומאשרים אותו. Chrome ממשיך להשתתף באופן פעיל ב-W3C כדי לקדם את ההצעה, לבקש משוב ולעודד אימוץ. |
| שערי פלט | שערי הפלט של האחסון המשותף מוגבלים מדי. | אנחנו מביאים בחשבון את המשוב הזה ומקבלים משוב נוסף על הסביבה העסקית לגבי הסיבות לכך ששערי הפלט מוגבלים מדי. |
| תאימות לתקנות | איך האחסון המשותף יטפל בתאימות לתקנות כמו מדיניות שמירת נתונים? | Shared Storage מספק גמישות להטמעת לוגיקה והתאמה אישית שלה, כדי לקבוע את משך החיים והתפוגה של נתונים מאוחסנים. טכנולוגיות פרסום יכולות לעדכן או לנקות נתונים מ-Shared Storage על סמך חותמות זמן של כתיבה. |
| בדיקת A/B | איך אפשר לבצע בדיקות A/B ל-Shared Storage ול-Protected Audience API? | אנחנו פועלים לפרסום הנחיות נוספות בנושא הזה, ומקווים לשתף פרטים נוספים בעתיד. |
| מגבלת נפח האחסון המשותף | מה יקרה ברגע שתגיעו למגבלת האחסון המשותף? | אם הגעתם למגבלה, לא יישמרו קלט נוסף. |
| גישה גורפת באותו דף טעינה | מה קורה כאשר ניגשים ל'אחסון משותף' כמה פעמים באותה טעינת דף? | הדרך הטובה ביותר לטפל בבעיה היא באמצעות הפונקציה window.sharedStorage.append(key, value). במקום לעדכן את הערך של כל מודעה, דבר שעלול לגרום להתנגשויות אם יש מספר מודעות. הפונקציה append רק תוסיף את הערך החדש לסוף הערך הקיים. |
| פונקציונליות של iframe | האם Shared Storage יתמוך בפונקציונליות מסוימת של iframe כאשר הן לא יפעלו יותר לאחר ההוצאה משימוש של קובצי cookie של צד שלישי? | אחרי ההוצאה משימוש של קובצי cookie של צד שלישי, האחסון המקומי במסגרות iframe יפוצל על ידי האתר ברמה העליונה, אבל ה-iframes עצמם לא ייחסמו. לא ניתן לשכפל את הנתונים באחסון המקומי של iframe באתרים מרובים ברמה העליונה, אבל עדיין ניתן להשתמש באחסון המקומי בתוך ה-iframe. |
צ'יפים
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| מגבלת חלוקה | 10KiB לכל אתר מחולק למחיצות עדיין משמעותיים ואני רוצה להקטין אותו. | Firefox כבר ציין מיקום חיובי ב-CHIPS. לתמיכה ב-Webkit, אנחנו ממליצים למפתחים לספק משוב ל-Apple ישירות לגבי הבעיה הזו ב-GitHub לגבי תרחישים לדוגמה שבהם עדיף להשתמש בקובצי Cookie שחולקו למחיצות על פני נפח האחסון המחולק למחיצות. |
| הטמעות מאומתות | CHIPs עשויים להשפיע על תהליך הכניסה הנוכחי ל-SSO בגלל חלוקה למחיצות (partitioning) שונה שמשפיעה על הטמעות מאומתות. | אנחנו מתכוונים להשתמש ב-Storage Access API (עם הנחיות ממשתמשים) כדי לתמוך בתרחיש לדוגמה של הטמעות מאומתות, ולאחרונה שלחנו Intent לאב טיפוס. |
| כללי מדיניות לכל משך החיים | האם כללי המדיניות לכל משך החיים יחולו על קובצי cookie מהדומיין הנוכחי? | בשלב זה, אין לנו כל כוונה להטיל מגבלות לכל משך החיים על קובצי cookie מהדומיין הנוכחי. |
FedCM
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| תמיכה בהרשאות OAuth | מגיעים להסכמה לגבי מתן הרשאה להיקפי הרשאות OAuth שאינם פרופילים | אנחנו מעוניינים באופן פעיל לקבל משוב מקהילת Web Identity דרך W3C FedID CG לגבי הדרכים הטובות ביותר לתמוך בהרשאה מעבר לאימות הבסיסי אחרי ההוצאה משימוש של קובצי ה-cookie של צד שלישי. |
| תמיכה ב-SAML | התאמה לדרישות לתמיכה ב-SAML | הצוות מחפש באופן פעיל מידע מקהילות המחקר והחינוך לגבי צורכי התמיכה של SAML (בנוסף לתמיכה ב-OpenID-connect), אחרי ההוצאה משימוש של קובצי Cookie של צד שלישי. |
נלחמים בספאם ובהונאות
Private State Token API (וממשקי API אחרים)
| עיצוב המשוב | סיכום | התגובה של Chrome |
|---|---|---|
| גילוי אותות חדשים | חלק מהשותפים הביעו סנטימנטים חיוביים ביחס לניסויים של אותות תקינות המכשיר או אמון המשתמשים בעזרת הדפדפן. באופן כללי, הם נזהרים גם לגבי אותות חדשים שנוצרו במיוחד כדי לשמר את הרמות הנוכחיות של זיהוי תרמיות. | אנחנו שמחים לבחון הצעות חדשות יחד עם הקהילה למניעת הונאות ולבטיחות באינטרנט, ואנחנו גם מאשרים ומשתפים את החששות שלהן – זו בדיוק הסיבה ש'נלחמים בספאם ובהונאות' הוא נתיב העבודה המרכזי של ארגז החול לפרטיות, ולכן אנחנו ממשיכים לתת עדיפות להשקעה בשמירה על הבטיחות באינטרנט, בזמן שאנחנו משפרים את פרטיות המשתמשים. |
| משוב חיובי לגבי PST | כמה שותפים הביעו עניין בבדיקה או בשימוש ב-PSTs לתרחישים לדוגמה שונים למניעת הונאות או לבטיחות באינטרנט. | אנחנו שמחים לקבל תמיכה והתעניינות במציאת פתרונות חדשים שמשתמשים ב-PST. יש לנו מקורות מידע וקוד לדוגמה זמינים באתר למפתחים של Chrome, ונשמח לקבל משוב נוסף. |
| הונאה וניצול לרעה | הנחיות למניעת הונאות במודעות או לזיהוי במדידה אחרי ההוצאה משימוש של קובצי Cookie של צד שלישי (כאשר המזהים כבר לא זמינים). | השקנו כלים כמו אסימוני מצב פרטי, שעוזרים לשחזר חלק מהאות שאבד על ידי קובצי cookie של צד שלישי למטרות מניעת הונאה, אבל עם אמצעי בקרה חדשים על פרטיות. אנחנו משקיעים באופן פעיל בהצעות חדשות למניעת הונאות וניצול לרעה כדי לשמר את היכולות בעזרת שינויים אחרים בארגז החול לפרטיות. |
| שיעור פרטי המנפיק לגבי המקור | שיעור המידע בין המנפיק למקור גבוה מספיק כדי לזהות משתמשים ייחודיים. | עדכנו את המפרט כך שיהיה ברור יותר אילו נתוני משתמש ניתן להעביר באמצעות אסימוני מצב פרטי. לפי עיצוב, ניתן להשתמש בעד שישה מפתחות ציבוריים בו-זמנית, מה שעשוי לייצג 'מדינה' למשתמש מסוים. אפשר לעדכן את קבוצות המפתחות האלה רק כל 60 יום (למעט במקרים נדירים שבהם יש צורך ברוטציית מפתחות במקרה חירום), מה שמאט את הסיכוי לצרף נתוני משתמשים נוספים לאורך זמן. עם כל ממשק API חדש לאינטרנט, יש איזון בין שימוש לתועלת לבין מידע נטו חדש למשתמשים שהוא מספק. אנחנו מעריכים שקובצי Cookie של צד שלישי מגיעים לאיזון המתאים כדי להגן על פרטיות המשתמשים, ובמקביל מאפשרים תרחישים לדוגמה מרכזיים למניעת הונאות שמושפעים מההוצאה משימוש של קובצי Cookie של צד שלישי. |
| שילוב אחזור | השילוב של fetch מורכב ומיותר. |
לשימוש ב-fetch יש יתרונות וחסרונות, ואנחנו רוצים להמשיך בסטנדרטיזציה נוספת בסביבה העסקית של האינטרנט, אבל אנחנו חושבים שיהיה מוקדם מדי לבצע את השינוי הזה עד שנבין טוב יותר איך התקן אמור להיראות. אם תזוהה תקן, אנחנו גם מחויבים להעביר את מפתחי האתרים באופן אחראי לסטנדרט הזה. |
| מיקום האחסון | יש לאחסן את ההגדרות של מפתח אסימוני מצב פרטי באותו מיקום שבו נמצא פרוטוקול PrivacyPass. | במהלך הבדיקה של גרסת המקור לניסיון, המפתחים ציינו שהם מעדיפים את הגמישות לאחסון המפתחות שלהם בכתובות URL כלליות במקום בספריית .well-known פורמט המחויבות העיקרית ב-PrivacyPass לא מתאים במיוחד לגרסה שבה ערכות המפתחות נועדו לאפשר 'מטא-נתונים ציבוריים' מרומזים עם ערך מסוים. אם וריאנט של PrivacyPass יעבור סטנדרטיזציה לפי מטא-נתונים ציבוריים (כ-POPRF, מסנוור RSA חלקי או מערכי מפתחות), יכול להיות שנעבור לגרסה עתידית של PST שתתמוך בכך. |
| הטמעת הכותרת של ה-API | שאלות לגבי הטמעת כותרות של API | ככל שה-API הופך לסטנדרטי והשימוש בסביבה העסקית ב-API הזה יתבגר, כך נוכל לתמוך גם בגרסה הרגילה של ה-API הזה ללא כותרת, ובסופו של דבר נוציא משימוש את גרסת הכותרת אם השימוש נמוך מספיק או אם יש מספיק כלים למפתחים או תמיכה בדרכים סטנדרטיות לקורלציה של בקשות הנפקה או מימוש עם נתונים אחרים. כאן אנחנו דנים בנושא. |
| הרשמה | האם רצוי לרשום מנפיקים בספקי דפדפנים? | עדכנו את המפרט כדי לתאר את תהליך הרישום של המנפיק באסימוני מצב פרטי. היא משתמשת בתהליך משלה, אבל היא דומה לתוכניות הרישום בשאר העבודה של ארגז החול לפרטיות, שבה אנחנו מבקשים ממנפיקים להצהיר באופן ציבורי על האופן שבו הם מתכוונים להשתמש ב-PST, ולהכיר במגבלות הטכניות שמגינות על פרטיות המשתמשים. |