דוח רבעוני לרבעון 2 של שנת 2023 שמסכם את המשוב שהתקבל לגבי הסביבה העסקית בנוגע להצעות של ארגז החול לפרטיות והתגובה של Chrome.
כחלק מהמחויבויות שלה ל-CMA, Google הסכימה לספק באופן ציבורי דוחות רבעוניים על תהליך המעורבות של בעלי עניין להצעות של ארגז החול לפרטיות (בהתאם לסעיפים 12 ו-17(c)(ii) של המחויבויות). דוחות סיכום המשוב של ארגז החול לפרטיות נוצרים על ידי צבירת משובים ש-Chrome מקבל מהמקורות השונים, כפי שמפורט בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין ב-privacysandbox.com, פגישות עם בעלי עניין בתחום ופורומים של תקני אינטרנט. ב-Chrome מקבלים בברכה את המשוב שמתקבל מהסביבה העסקית, ובוחנים באופן פעיל דרכים לשלב את התובנות שנלמדו בקבלת החלטות לגבי תכנון.
נושאי המשוב מדורגים לפי מידת השכיחות לכל API. כדי לעשות את זה, מתבצעת צבירה של כמות המשוב שצוות Chrome קיבל לגבי עיצוב נתון, תוך ארגון בסדר יורד של כמות. כדי לזהות את הנושאים הנפוצים במשוב, עיינתי בדיונים שנשאלו בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שהעלו הצוותים הפנימיים והטפסים הציבוריים של Google.
באופן ספציפי, נבדקו פרוטוקולים של פגישות עם גופים סטנדרטיים באינטרנט, וכדי לקבל משוב ישיר, נלקחו בחשבון הרשומות של Google לגבי פגישות אישיות עם בעלי עניין, אימיילים שהתקבלו מהמהנדסים, רשימת הדיוור של ה-API וטופס המשוב הציבורי. לאחר מכן, Google תאמה בין הצוותים שלקחו חלק בפעילויות ההפצה השונות כדי לקבוע את השכיחות היחסית של הנושאים שעלו ביחס לכל ממשק API.
ההסברים של Chrome למשוב פותחו על סמך שאלות נפוצות שפורסמו, תשובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת מיקום באופן ספציפי למטרת תרגיל זה של דיווח ציבורי. הנתונים האלה משקפים את המיקוד הנוכחי של הפיתוח והבדיקה, ואת השאלות והמשוב שקיבלנו לגבי Topics API, Protected Audience API ו-Attribution Reporting API.
יכול להיות שמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עוד לא נחשב כתגובה מ-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 |
|---|---|---|
| ניהול נתונים ותאימות לתקנות | הנחיות של המערכת האקולוגית לגבי שימוש בארגז החול לפרטיות בהתאם לדרישות הרגולטוריות. | כמו בכל טכנולוגיה חדשה, כל חברה אחראית לוודא שהשימוש שלה בארגז החול לפרטיות נעשה בהתאם לחוק. Google לא יכולה לספק ייעוץ משפטי לאחרים. עם זאת, אנחנו מודעים לכך שזהו תחום עניין מרכזי מבחינת המערכת האקולוגית. פרסמנו תיעוד טכני נרחב לגבי כל ממשק API, שאמור לספק את הבסיס לביצוע הערכות משפטיות נדרשות. אנחנו פועלים להוספת חומרים נוספים שיתמכו במאמצים של החברות לפעול בהתאם לדרישות הרגולטוריות. |
| הצעה לבדיקה כמותית של CMA | מידע נוסף על ההצעה לבדיקה כמותית של CMA | אנחנו עובדים בשיתוף עם ה-CMA כדי לתכנן ניסויים שיספקו תמונה של ההשפעה של ההוצאה משימוש של קובצי cookie של צד שלישי ושל יישום ההצעות של ארגז החול לפרטיות בסביבה העסקית. בחודש אפריל, פרסמה ה-CMA הנחיות ברמה גבוהה לגבי מה שצפוי לקרות במהלך תקופות הבדיקה והניסיון, ולאחר מכן הנחיות מפורטות בחודש יוני. מומלץ לשתף שאלות או משוב לגבי ההצעה של ה-CMA לבדיקה כמותית ישירות עם ה-CMA. |
| מצבי בדיקה בסיוע Chrome | עוד מידע והבהרות לגבי לוחות הזמנים לבדיקות | ב-18 במאי פרסמנו פוסט בבלוג שבו אנחנו משתפים מידע נוסף על שני המצבים של בדיקה בסיוע Chrome. הפרטים האלה לא סופיים. נפרסם הנחיות נוספות להטמעה במהלך הרבעון השלישי של 2023. |
| אחסון מחולק למחיצות (Partitions) | האם ייעשה שימוש באחסון מחולק למחיצות (Partitions) במהלך בדיקות בסיוע Chrome? | החלוקה למחיצות באחסון תישלח לכל המשתמשים לפני ההוצאה משימוש של קובצי cookie של צד שלישי. לכן, היא תופעל בכל זרועות הניסוי. ב-Google Sites תהיה אפשרות להפעיל תקופת ניסיון להוצאה משימוש כדי לחזור לנפח אחסון ללא מחיצה במהלך התקופה הזו. |
| תמיכה בהפקה | מהו התהליך הנדרש כדי ש-Chrome יתמוך בבעיות טכניות בארגז החול לפרטיות ובהעברות לטיפול ברמה גבוהה יותר שמשפיעות על הסביבה העסקית? | Google מספקת מגוון ערוצים כדי לאפשר לטכנולוגיות הפרסום לדווח על בעיות ולאפשר העברה לטיפול ברמה גבוהה יותר, אם יש צורך. בפוסט למפתחים יש מידע נוסף על פורומים ציבוריים ופרטיים לקבלת משוב וטיפול ברמה גבוהה יותר. |
| ציר הזמן להרשמה | מסגרת הזמן הנוכחית להרשמה קצרה מדי | אנחנו עדיין בודקים את המועד האחרון לאכיפה, ונשמח לשמוע מהסביבה העסקית לגבי לוח הזמנים המתאים יותר. |
| מספר DUNS | מידע נוסף על הדרישה למספר D-U-N-S לצורך הרשמה ואימות | המשתתפים יכולים למצוא את הדרישות לקבלת מספר DUNS באתר של Dun & Bradstreet. הדרישות משתנות בהתאם לשוק, לכן הקפידו לבדוק באתר של השוק הספציפי שבו הם מעוניינים. עם זאת, באופן כללי, המשתתפים יצטרכו לספק מידע בסיסי על העסק שלהם, כמו שם העסק, הכתובת והפרטים ליצירת קשר עם הבעלים או המנהל של העסק. יכול להיות שהמשתתפים יתבקשו גם לספק מידע פיננסי, כמו ההכנסה השנתית של העסק. לאחר השלמת הבקשה, D&B תבדוק אותה ותנפיק מספר DUNS, אם הבקשה תאושר. |
| מעבר מגרסת המקור לגרסת הניסיון לזמינות לכלל המשתמשים | האם המעבר מגרסת המקור לניסיון ל'זמינות לכלל המשתמשים' (GA) ישפיע על הבודקים הנוכחיים של תקופת הניסיון? | החל מיולי, הבודקים יוכלו לגשת לממשקי ה-API של הרלוונטיות והמדידה שיהיו זמינים לכלל המשתמשים. תהיה חפיפה בין הזמינות של גרסת המקור לניסיון לבין הזמינות לכלל המשתמשים. |
| מחקר של AdExchanger | מידע נוסף על מתודולוגיית הסקרים | הסקר ביקש מהמשתתפים להעריך את שיעורי הסנכרון ואת ההכנסות של העסקים שלהם. הם התמקדו במתודולוגיית התשובות של המשיבים לשאלות האישיות שלהם. |
| ערכי פרמטרים | איך נקבעים ערכי פרמטרים כמו רמת הרעש, סף האנונימיות ותקציב הפרטיות? | בהסבר הזה על GitHub מתוארים העקרונות הכלליים יותר שעומדים מאחורי ממשקי ה-API של ארגז החול לפרטיות. ערכים רבים עדיין בשלבי פיתוח, ונשמח לקבל משוב על הנושא הזה. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| שימור הפרטיות | מחקר להערכת Topics API בנושא שימור הפרטיות | אנחנו מעורבים באופן פעיל בקהילת המחקר, ומציגים את המחקרים שלנו על מאפייני הפרטיות של Topics API במאמרים, בדוחות ובמצגות מסדנאות. אנחנו שמחים לראות שיותר חברים חיצוניים בקהילת המחקר מעורבים בתחום הזה. Topics API מגן על המשתמשים מפני מעקב כללי באינטרנט, מאחר שהוא מקשה מדי על מעקב אחר משתמשים בקנה מידה גדול. המאמרים האלה מצביעים על כך שהצלחנו להשיג את המטרה הזו בעזרת Topics API. הוא פרטי יותר מקובצי cookie של צד שלישי והוא מגן על המשתמשים וגם תומך באתרים שהם אוהבים לבקר בהם. |
| טקסונומיית הנושאים לא מפורטת מספיק | טקסונומיה של נושאים רחבים לא כוללת נושאים מפורטים יותר, כולל נושאים ספציפיים לאזור. | בתגובה למשוב שקיבלנו בעבר מהמערכת האקולוגית, פרסמנו פוסט בבלוג ב-15 ביוני שמפרט טקסונומיה מעודכנת חדשה, המשלבת שיפורים רבים בעקבות משוב שמתקבל מהמערכת האקולוגית. במסגרת העבודה שלנו על הטקסונומיה המעודכנת, שיתפנו פעולה עם מספר חברות שונות בכל הסביבה העסקית, כמו Raptive (לשעבר CafeMedia) ו-Criiteo. לפי הטקסונומיה המעודכנת, הקטגוריות שלדעתנו הן פחות שימושיות. הקטגוריות האלה מותאמות יותר לתחומי העניין של המפרסמים, תוך שמירה על מחויבותנו להחריג נושאים שעשויים להיות רגישים. אנחנו ממליצים לסביבה העסקית לבדוק את הטקסונומיה העדכנית ולספק משוב לגבי השינויים. |
| תהליך עדכון הטקסונומיה והסיווג | מידע נוסף על הטקסונומיה של Topics ועל קצב ההפצה של המסווגים, ועל האופן שבו חברות יכולות להתכונן לקראת העדכונים האלה | כפי שפירטנו בפוסט בבלוג האחרון, אנחנו צופים שהטקסונומיה תשתנה עם הזמן, וכדי שהניהול של הטקסונומיה יעבור בסופו של דבר לגורם חיצוני שמייצג בעלי עניין מהענף. שיתפנו גם את תוכנית הגדלת הנפח בקבוצה topics-announce. |
| ההשפעה על אותות מאינטראקציה ישירה | העלייה במספר הנושאים בעדכון האחרון של הטקסונומיה עשויה להיות בעלת ערך רב, וכתוצאה מכך לפגוע בערך של אותות אחרים שמבוססים על תחומי עניין מאינטראקציה ישירה. | בדוח של CMA של הרבעון הראשון של 2023, "אנחנו מבינים ש-Google דנה בטקסונומיה החדשה המוצעת עם מספר משתתפים בשוק לאורך שרשרת האספקה של טכנולוגיות פרסום. לא כל בעלי התוכן הדיגיטלי גדולים אמרו ששימוש רב יותר בנושאים יגדילו את הלחץ התחרותי על פתרונות מבוססי-נתונים מאינטראקציה ישירה. עם זאת, הדעה הראשונית שלנו היא שמידת התועלת המוגברת עדיפה לטובת התחרות הכוללת, במיוחד לאור היכולת של בעלי תוכן דיגיטלי קטנים יותר להמשיך לבצע מונטיזציה מהמלאי שלהם אחרי ההוצאה משימוש של קובצי 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 יוכלו לנהל ולסנן נושאים, בדומה לתוספים הנוכחיים לניהול קובצי cookie | כמו שהסברנו ב-GitHub, זה כבר אפשרי, אבל נשמח לקבל משוב נוסף מהסביבה העסקית. |
| מעבר לזמינות לכלל המשתמשים | האם תהיה השפעה על Topics API כשהמעבר מגרסת המקור לניסיון לזמינות לכלל המשתמשים (GA)? | משתמשים שעוברים מתקופת הניסיון בגרסת המקור לזמינות לכלל המשתמשים לא יאבדו נתונים. |
| פרטיות | שמות מארחים עשויים להכיל מידע פרטי שעשוי להיחשף על ידי Topics API | אנחנו נוקטים מספר מיטיגציות כדי להבטיח שמירה על פרטיות, כפי שמתואר כאן. |
| הונאה וניצול לרעה | כיצד למנוע מניפולציה של 'נושאים' על ידי ביקורים שמקורם בתרמית | כאן מוסבר על מיטיגציות. |
| מסווג נושאים | האם אתרים יכולים לבקש לשנות את סיווג הנושאים שלהם? | נשמח לשמוע מהסביבה העסקית בנושא הזה ולקבל משוב כאן. |
| אתרים של ספקי נושאים | להגדיר אתרים מסוימים שמארחים תוכן עבור נושאים רבים כ "אתרים של ספקי נושאים מיוחדים" ולהכשיר מסווגים על סמך תגים שמופיעים בדפי האינטרנט. | אנחנו דנים כאן בהצעה, ונשמח לקבל משוב נוסף. |
Protected Audience API (לשעבר FLEDGE)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| עיצוב התנועה | ההשפעה על הביצועים של סינון מבוסס SSP כדי לבצע אופטימיזציה של עומס השאילתות לשנייה (QPS) | השקענו זמן רב במחשבה על עיצוב התנועה, וההמלצה היא ל-SSP (פלטפורמות SSP) כדי להיעזר בשמירה במטמון. |
| נפח הבדיקה | קשה יותר לבדוק את Protected Audience, מפני שפלטפורמות SSP ופלטפורמות DSP נאבקות לקבל נפחי תנועה גדולים. | אנחנו מעודדים מעורבות תמידית עם שותפי SSP ו-DSP כדי לאמץ ולבדוק 'קהלים מוגנים'. הזמינות לכלל המשתמשים התחילה ואנחנו בטוחים שאחוז התנועה לאחר הפעלת מודעות בהתאמה אישית (PA) יהפוך אותה לאישית יותר עבור השותפים. |
| רמת המורכבות | כדי להטמיע פתרונות Protected Audience API, צריך להשקיע הרבה מאמץ ועלויות. | ברור לנו שקשה לאמץ טכנולוגיות חדשות, כולל ארגז החול לפרטיות. הצוות של ארגז החול לפרטיות עובד בשיתוף פעולה הדוק עם מגוון רחב של בעלי עניין כדי ללמד ולתמוך במאמצים שלהם, ובוחנים באופן קבוע גורמי מאיצים אחרים כדי לתמוך באימוץ של הסביבה העסקית. |
| סביבות ביצוע מהימנות | תמיכה בסביבות ביצוע מהימנות (TEE) בסביבות ענן שאינן ציבוריות | אנחנו בוחנים אפשרויות תמיכה אפשריות מעבר לפתרונות מבוססי-ענן, אבל בשלב זה לא ניתן לתמוך ב-TEE מקומי, בגלל מגבלות אבטחה מקומיות שמחייבות הערכה מקיפה של ארגז החול לפרטיות. לאור דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שעומדים בפני הפריסות המקומיות, אנחנו מאמינים שהמשך הרחבה ושיפור של הפריסות מבוססות-הענן (למשל תמיכה ב-GCP בנוסף ל-AWS) הוא המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל משוב נוסף שמסביר למה דרישה כזו נחוצה. |
| מבנה העלויות | הגשת הצעות מחיר ושירותי מכרזים תגביר את העלות ואת המורכבות של טכנולוגיות הפרסום בהשוואה למודלים בצד הלקוח. | אנחנו מפתחים כרגע מדריך להערכת העלויות של תמיכה בתהליכי העבודה של הבידינג והמכרזים בשרת של הבידינג והמכרזים, שיהיה מתואם לשימוש בטכנולוגיות פרסום, ויספק אחת ממטרות העיצוב שלנו. |
| צירי זמן של K-Anon | מתי ייאכפו מגבלות ה-k-anonymity המתוכננות ב-'renderUrl'? | אנחנו עובדים על הסבר לגבי לוח הזמנים לאכיפה שנפרסם בקרוב. |
| הגבלות על runAdAuction | האם Chrome יכול להגביל את runAdAuction כך שניתן יהיה לקרוא ל-runAdAuction רק מהדף העליון? |
למרות שהעיצוב שלנו תומך באופן מלא בקריאה לפעולה runAdAuction מהדף העליון, אנחנו מאמינים שבעלי אתרים שמגבילים את התכונה יפגעו רק כך שניתן יהיה לקרוא אותה רק מהדומיין ברמה העליונה.שמענו במיוחד בסביבה העסקית שארגז החול לפרטיות צריך לצמצם את העומס על בעלי התוכן הדיגיטלי ועל המפרסמים. משוב זה תואם לעקרון הכללי של פיתוח אתרים, שלפיו בעלי אתרים יכולים להשתמש בכלים של צד שלישי להפעלת האתרים שלהם. המטרה של ארגז החול לפרטיות הייתה לעודד סביבה עסקית תקינה בלי הצורך לקבוע מראש איך בעלי תוכן דיגיטלי וטכנולוגיות פרסום פועלים. אנחנו מאפשרים לבעלי התוכן הדיגיטלי לבחור איך מתקשרים אל runAdAuction באתר שלהם ומי יפנה אליהם. אנחנו מאמינים שאנחנו מאפשרים לבעלי התוכן הדיגיטלי למצוא את הנתיב הטוב ביותר לדרישות שלהם. |
| תמיכה בהטמעה | האם Chrome יכול ליצור או לתרום להטמעה של קוד פתוח של מכרז עם כמה אתרי מכירה? | המטרה של ארגז החול לפרטיות היא לפתח טכנולוגיות לשמירה על הפרטיות שלא מסתמכות על קובצי cookie של צד שלישי או על מזהים אחרים באתרים שונים. אנחנו רוצים לעודד סביבה עסקית תקינה בלי לקבוע מראש איך טכנולוגיות פרסום יפעלו. פרסמנו הנחיות לגבי אופן הפעולה של ממשקי ה-API במאגר שלנו ב-GitHub, ואנחנו פתוחים לבדיקה של פתרונות בתחום. אנחנו לא מתכננים לפתח הטמעה ספציפית, כי עיקרון העבודה שלנו הוא בניית טכנולוגיות לפלטפורמה, ולא להכתיב אסטרטגיות לשימוש בטכנולוגיות האלה. הטכנולוגיות שלנו יאפשרו לחברות פרסום דיגיטלי לספק ללקוחות שלהן את אמצעי ההגנה המתאימים לשמירה על פרטיות הצרכנים. |
| מכרזים עם כמה אתרי מכירה | האם Chrome יאלץ שיתוף זוכה "לפי הקשר" במכירות פומביות של רכיבים? | Protected Audience API נועד לאפשר לצדדים שמתחילים את המכרז מרובה אתרי המכירה להעביר מידע למכרז הרכיבים (הערה: רק לפני התחלת המכרז). עם זאת, אנחנו לא רואים דרך לדפדפן להבחין אם פיסת מידע מסוימת היא המנצחת מבחינת ההקשר, ולכן אנחנו לא יכולים לאכוף חסימה או לדרוש מידע מסוים. |
| העדפת המשתמש למעקב אחר הסכמה | פרסום דיגיטלי שואל את 'מודעות בהתאמה אישית' (PA) איך ליישם כראוי מעקב אחר הסכמת משתמשים | התגובה שלנו כוללת את מה שאמרנו ברבעון 1: "לגבי מודעות ספציפיות, טכנולוגיית הפרסום הרלוונטית היא הגורם המתאים ביותר להציע את השליטה על הקריאייטיבים שיוצגו או על אופן הבחירה שלהם". שוחחנו על מספר תרחישים שקשורים לבעיה הזו במהלך הפגישה עם 'קהל מוגן של ארגון WICG' במאי, ונשמח לקבל משוב ודיון נוספים בנושא. |
| קהלים בהתאמה אישית | האם Protected Audience API יתמך בתרחישים לדוגמה של SSP שקשורים ליצירת קהלים בהתאמה אישית? | Protected Audience API מאפשר לספקי SSP ולספקים אחרים של טכנולוגיות פרסום לנהל ולנהל קהלים בהתאמה אישית. אנחנו מפתחים הנחיות נוספות לגבי האופן שבו ניתן לשלב SSP עם API של PA API. ההנחיה תהיה זמינה לספקי SSP ולספקים אחרים של טכנולוגיות פרסום כדי לתמוך במאמצי השילוב שלהם. |
| פורמטים | האם וידאו נתמך על ידי Protected Audience API? | מודעות וידאו מוצגות באחת משתי דרכים: כ-VAST XML או HTML (מודעת וידאו Outstream שבסופו של דבר עשויה לטעון גם VAST XML בנגן וידאו). הקונים יכולים להחזיר את כל אחד מהפורמטים באמצעות כתובת URL לעיבוד. מפרט VAST עודכן לאחרונה כדי לתמוך ב-Attribution Reporting API. אתרים שמציגים מודעות וידאו יצטרכו להתכונן לאופן שבו המודעות יוצגו באמצעות Protected Audience API. כלומר, כדי לוודא שתגי מיקום יכולים להעביר את כתובת ה-URL מ-iframe של 'קהל מוגן' אל נגן וידאו. במקרה של Fenced Frames נפעל לטפל בצורכי הווידאו לפני הדרישה להשתמש ב-Fenced Frames, החל משנת 2026. |
| קצב | איך התרחיש לדוגמה של Pacing פועל עם 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) פונקציות בהגדרת משתמש ב'קהל מוגן' | איך תהיה תמיכה בפונקציות בהגדרת המשתמש (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. אפשר לקרוא עליהם כאן. |
| נקודת קצה של השרת | האם נקודת הקצה של השרת תהיה שרת הצבירה המהימן בתכנון הסופי? | נקודת הקצה של השרת היא נקודת קצה שמתוחזקת על ידי טכנולוגיית מודעות, בנפרד משרתי הצבירה המהימנים שמשמשים לעיבוד הדוחות שנאספים ועברו שינוי. בשלב זה אין לנו שינויים מתוכננים בנקודת הקצה של הדיווח. מטרת העיצוב הנוכחי היא להבטיח שהדוחות שנצברים בעצמם (עם מטענים ייעודיים (payloads) מוצפנים) לא ידלפו נתונים מאתרים שונים, כך שאין צורך בנקודת קצה מהימנה. תכונה נוספת היא שככל הנראה לטכנולוגיות שונות של מודעות יהיו אסטרטגיות שונות של קיבוץ מודעות. נשמח לקבל משוב נוסף. |
| 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 יכול לתמוך בהם? | המגבלה הנוכחית היא 50 KB לגודל של IG אחד, והמפתחות נספרים כחלק מזה. נשמח לדיון נוסף לגבי מגבלת הגודל. |
| קובץ אצווה | איך אפשר להפחית את מספר הקריאות של שרת ה-K/V? | ניתן להשתמש בכותרות HTTP Cache-Control כדי לצמצם את מספר הקריאות ל-K/V. לדוגמה, ייתכן שהיא תישמר במטמון של משתמשים מסוימים במכירות פומביות של רכיבים, וגם במיקומי מודעות בדף אחד. |
| ניהול הגרסאות | תמיכה בכמה גרסאות של קוד פרסום דיגיטלי | שירותי בידינג ומכרזים יתמכו בכמה גרסאות של קוד טכנולוגיית הפרסום. ב-Open Bidding וב-Auction API, הבקשה SelectAd יכולה לציין את גרסת הקוד של הבקשה במכרז (כלומר, לצורכי בידינג או מכרז וגם לדיווח). |
| נפח אחסון משותף | תמיכה בכתיבה לנפח אחסון משותף בשירות הבידינג ובשירות המכרזים. | נכון לעכשיו, שירותי הבידינג ומכרזים לא תומכים בנפח אחסון משותף, אבל נשמח לקבל משוב נוסף על החשיבות של תרחישים לדוגמה כאלה לסביבה העסקית. |
| מהאתר לאפליקציה | תמיכה בשיתוף של קבוצות של אינטרסים מאתר לאפליקציה. | ההגדרה של אתר לאפליקציה לא מוגדרת כרגע בפריסה של Protected Audience API ב-Chrome וב-Android, אבל נשמח לשמוע מהסביבה העסקית את החשיבות של התרחיש לדוגמה הזה. |
| K-אנונימיות | איך לטפל בחלופות K-אנונימיות | אנחנו מדברים על הבעיה, ונשמח לקבל משוב נוסף. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הגדרות חלופיות של דוחות ברמת האירוע לאחר צפייה (VTC) | משוב על הגדרות הדוחות של המרות לאחר צפייה חלופיות (VTC) ברמת האירוע | קיבלנו משוב על כך שההגדרות הנוכחיות ברמת האירוע אינן אופטימליות, ואנחנו מבקשים משוב על ההגדרות הגלובליות האופטימליות. נשמח לקבל משוב נוסף בנושא הזה, ואנחנו חושבים שההסבר הגמיש ברמת האירוע עוזר לנו לטפל בבעיה. |
| הגדרות גמישות ברמת האירוע | מה הסטטוס של תכונת ההגדרות האישיות הגמישות ברמת האירוע? | שיתפנו מסמכים בנושא הגדרה גמישה ברמת האירוע. התכונה עדיין נמצאת בשלב ההצעה ונשמח לקבל משוב נוסף כדי להבין אם התכונה תהיה בעלת ערך לסביבה העסקית. |
| הגדרות גמישות ברמת האירוע | איך אפשר ליישב דוחות סותרים שנמסרו לגורמים שונים? | רוב תרחישי הדיווח מקבלים מענה באמצעות שימוש בדוחות מצטברים, ואילו הצעת ההגדרה הגמישה ברמת האירוע מאפשרת גמישות נוספת בדוחות ברמת האירוע, המשמשים לעיתים קרובות בתרחישים לדוגמה של אופטימיזציה. נשמח לקבל כל הערה או משוב נוספים שקשורים לסביבה העסקית בקשר לתרחיש הזה. |
| רישום מקור | מה קורה אם רישום המקור מתרחש לאחר הרישום של הטריגר? | בשלב זה, אם רישום מקור מתבצע לאחר הרישום של הטריגר, לא ניתן יהיה לשייך את המקור והטריגר זה לזה. נראה שזה תרחיש קיצוני. נשמח לקבל כל משוב נוסף בקשר לבעיה הזו, ונטפל בה אם מדובר בתרחיש שנראה שטכנולוגיות פרסום רבות מתמודדים איתו. |
| עבודה עם כמה סוכנויות מודעות | איך מערכות DSP יכולות להשתמש ב-Attribution Reporting API כשמפרסם עובד עם כמה סוכנויות פרסום? | ה-API תומך בהפניות אוטומטיות, ולכן אפשר להשתמש בו גם אם המפרסם עובד עם כמה סוכנויות פרסום. בנוסף, קיימות מספר מגבלות בנוגע להפניות אוטומטיות כדי להבטיח שממשק ה-API משפר את הפרטיות. זיהינו גם דרך לעקוף את הבעיה באמצעות Shared Storage 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) חוצה אפליקציות ואתרים | מתי תהיה אפשרות למדוד שיוך (Attribution) באתרים ובאפליקציות? | ב-9 במאי הודענו על ניסוי במדידת ביצועים של שיוך באפליקציות ובאתרים שונים באמצעות Attribution Reporting API. כרגע, 'זמינות לכלל המשתמשים' (GA) מתוכננת לממשק ה-API של הרלוונטיות והמדידה ב-Chrome בגרסה 115, אבל בשלב זה, מדידת השיוך (Attribution) באפליקציות ובאתרים לא מתוכננת להגיע לזמינות לכלל המשתמשים (GA) בגרסה 115 של Chrome. |
| ביטול כפילויות של המרות | איך ניתן להתאים פתרונות מדידה עצמאיים ל-ARA? | כמו בשיטה הרגילה הנוכחית, המפרסמים יעבדו עם ספק שירותי מדידה עצמאי מצד שלישי כדי לבטל כפילויות בדיווח על המרות. יש לנו מקורות מידע בנושא ביטול כפילויות של המרות לצורך דיווח ברמת האירוע. |
| אובדן נתונים במהלך עדכונים של מסד הנתונים של דוחות השיוך (Attribution) | האם Chrome יעדכן את מסד הנתונים של דוחות השיוך (Attribution) כפי שהוכרז? | בגרסה היציבה של Chrome בגרסה 115, נתחיל להפעיל את ממשקי ה-API של הרלוונטיות והמדידה לחלק ממשתמשי Chrome כברירת מחדל. הזמינות הכללית הזו תגדל ככל שנעקוב אחר בעיות פוטנציאליות. היעד הוא להגיע ל-100% זמינות בתקופה של שבועות, עד הרבעון השלישי של 2023. תקופת הניסיון תסתיים בתאריך המקור לניסיון של הרלוונטיות והמדידה. החל מיולי, בודקים יוכלו להירשם לקבלת גישה לממשקי ה-API האלה כזמינות לכלל המשתמשים. כך נוצרת חפיפה בין הזמינות של גרסת המקור לניסיון לבין הזמינות הכללית באמצעות ההרשמה. האסימון של גרסת המקור לניסיון יהיה בתוקף עד 19 בספטמבר, אבל מומלץ להירשם לממשקי ה-API לפני שיפוג התוקף שלהם, כדי שתוכלו לעבור בצורה חלקה מחוץ לגרסת המקור לניסיון בלי להפסיק את הבדיקות המתמשכות. כפי שציינו בהודעה הזו, הנתונים שרשומים מגרסאות ישנות יותר (M113 וגרסאות קודמות) לא יועברו אחרי העדכון, ולכן יכול להיות שהם יאבדו נתונים. אובדן הנתונים הזה לא יופיע בדיווח על תוצאות ניפוי הבאגים, וננסה למנוע אובדן נתונים מ-114 עד 115. |
| חיוב | שימוש בדיווח שיוך (Attribution) לחיוב עלות להמרה | כפי שצוין במאמר הזה, יכול להיות ש-Attribution Reporting API לא מתאים לצורכי חיוב לפי עלות להמרה, בגלל הרעש שנוסף ברמת האירוע ובדוחות הסיכום. אנחנו מעודדים את השחקנים בסביבה העסקית לשתף ב-GitHub משוב על ההשפעה על מודלים שונים של חיוב, באמצעות Attribution Reporting API. |
שירות צבירה
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| שינוי של דוח צבירה בדוח | תגובות חיוביות להצעה לשנות את משך הזמן המצטבר לדיווח על נתונים מ-[10-60 דקות] ל-[0-10 דקות] בעקבות המשוב שהתקבל מהסביבה העסקית | אנחנו שמחים לראות תגובה חיובית לשינוי המוצע, ומעודדים את הסביבה העסקית להמשיך לספק משוב על ההצעות שלנו. |
| פתרון מקומי | האם אפשר לפרוס את שירות הצבירה במרכזי נתונים מקומיים? | אנחנו בוחנים אפשרויות תמיכה אפשריות מעבר לפתרונות מבוססי-ענן, אבל בשלב זה לא ניתן לתמוך ב-TEE מקומי, בגלל מגבלות אבטחה מקומיות שמחייבות הערכה מקיפה של ארגז החול לפרטיות. לאור דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שעומדים בפני הפריסות המקומיות, אנחנו מאמינים שהמשך הרחבה ושיפור של הפריסות מבוססות-הענן (למשל תמיכה ב-GCP בנוסף ל-AWS) הוא המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל משוב נוסף שמסביר למה דרישה כזו נחוצה. |
| לעבד מחדש דוחות עבור תקופות זמן שונות | יכולת לעבד מחדש דוחות עבור תקופות זמן שונות | קיבלנו בקשות דומות לפיצול קבוצות לפי טווחי תאריכים שונים. אחת מההצעות היא לאפשר את היכולת להרחיב את המזהה המשותף באמצעות תווית המוגדרת על ידי טכנולוגיית המודעה, כך שניתן יהיה לפצל את הדוחות לקבוצות שונות. אנחנו נמצאים בשלבים הראשונים של בחינת התהליך, ונמשיך לעדכן את הסביבה העסקית ככל שההצעה הזו תשתנה. |
| השלכות הפרטיות של סביבת ביצוע מהימנה | רגשות חיוביים לגבי השלכות על פרטיות של סביבות ביצוע מהימנות | אנחנו שמחים לשמוע על תגובות חיוביות בסביבה העסקית בנוגע להצעות שלנו, ונשמח לקבל משוב נוסף ככל שנמשיך לחקור ולפתח את. |
| תנאים והגבלות | מה המועד האחרון לאישור התנאים וההגבלות של שירות הצבירה? | אף על פי שעדיין לא הגדרנו מועד אחרון לאישור התנאים וההגבלות, אנחנו ממליצים לחברות שעוסקות בסביבה עסקית לקבל את התנאים וההגבלות בהקדם האפשרי כדי למנוע עיכובים בהרשמה. אנחנו ממליצים לחברות לפנות אלינו בכל שאלה. |
| גילוי מפתחות | תכונת גילוי המפתח תאפשר לבודקים לשלוח שאילתות לגבי דוחות נצברים, בלי שיצטרכו לרשימה מפורשת של שילובי מפתחות אפשריים לעבד דוחות סיכום לשיוך חוצה-פלטפורמות, ולשפר את הביצועים והדיוק. | אנחנו בוחנים כרגע פתרונות אפשריים ופתרונות עקיפים אפשריים, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
API לצבירה פרטית
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| מקור הדיווח | איך מוגדר מקור הדיווח? | מקור הדיווח הוא תמיד מקור הסקריפט של מבצע הקריאה לצבירה הפרטית. |
| רווח מקשים באורך 128 ביט | בהירות לגבי מגבלת מרחב המקשים של 128 סיביות | נוודא שמגבלת מרחב המפתחות הזו תהיה ברורה יותר ונפתור את אי-העקביות בין דפים. מומלץ להשתמש באסטרטגיות גיבוב (hashing) כדי לא לחרוג ממרחב המפתחות הזה. |
| תרומה מקסימלית לכל דוח | המגבלה הנוכחית של 20 תכנים שנוספו לכל דוח נמוכה מדי. | במקום להגדיל את מספר התרומות המקסימלי, אנחנו פתוחים לשקול לפצל דוחות במקום לחתוך את המגבלה. נמשיך לערב את הסביבה העסקית ביחד עם התפתחות ההצעה הזו. |
| דיווח על היקף החשיפה | בקשה לקבלת דיווח על היקף החשיפה בפלטפורמות שונות או במכשירים שונים. טווח ההגעה הוא מדד בסיסי בפרסום המותג. מפרסמים מסתמכים על הערכות של פלטפורמות/מכשירים שונים לצורך דיווח על היקף חשיפה ותדירות כדי לנתח את הקמפיינים שלהם ולהקצות הוצאות. במודלים של היקף החשיפה, המערכת משתמשת בקובצי cookie של צד שלישי כאות למדידת מודעות שמוצגות בסביבות של צד שלישי. לכן, טכנולוגיות פרסום ביקשו פתרון חלופי אחרי ההוצאה משימוש של קובצי ה-cookie של צד שלישי. |
לאחר ההוצאה משימוש של קובצי cookie של צד שלישי, הצוות של ארגז החול לפרטיות בודק תכונות לתמיכה בשיטות היקף החשיפה בכמה דומיינים. נשמח לקבל משוב נוסף מהסביבה העסקית. |
הגבילו מעקב סמוי
הפחתת מידע בסוכן משתמש/רמזים על הלקוח בסוכן משתמש
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| (דיווחים גם ברבעון הראשון של 2023) רמזים לגורמי צורה נוספים | שליחת בקשה לקבלת רמזים על הלקוח של סוכן המשתמש (UA-CH) כדי לספק גורמי צורה נוספים, כמו טלוויזיה ו-VR | אנחנו עדיין עובדים על כמה החלטות עיקריות לגבי עיצוב (אם לספק ערך יחיד, כמו "טלוויזיה", או רשימה של יכולות של גורמי צורה), אבל עדיין מעוניינים ליצור אב-טיפוס לרעיון הזה. |
| תקציב פרטיות | הגבלות על תקציב הפרטיות עלולות לגרום לבקשות של UA-CH להיות לא-קבועות כשנשלחות יותר מדי בקשות. | בשלב הזה אין לנו עדכונים חדשים לגבי ההצעה לתקציב הפרטיות, אבל התחייבנו לא להגביל את הבקשות לקבלת טיפים ללקוחות UA לפני ההוצאה משימוש של קובצי cookie של צד שלישי. |
| תאימות של אתר | אתרים משתמשים במותג של UA-CH כדי להגביל את הגישה של דפדפנים מסוימים לאתרים. | יש תרחישים תקינים לשימוש ברשימת מותגים, ואחד מהם הוא תאימות מדויקת. ב-UA אפשר להגדיר בחינם כמה מותגים כדי לעקוף את הבעיות האלה. |
הגנה על IP (לשעבר Gnatcatcher)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הונאה וניצול לרעה | איך חברות יכולות להגדיר אמצעים למניעת הונאה באמצעות הגנה על קניין רוחני? | אנחנו מבינים את החשיבות של תרחישים לדוגמה למניעת הונאה ואת ההשפעה האפשרית על תרחישים כאלה. אנחנו מתכננים לפרסם פרטים נוספים בנוגע לתמיכה נגד הונאה בהמשך הקיץ. אנחנו מעוניינים לקבל משוב על הסביבה העסקית שבה נוכל לספק תמיכה טובה יותר בתרחישים לדוגמה למניעת הונאה. |
| GeoIP | מידע נוסף על לוח הזמנים לבדיקה ולפריסה של GeoIP | לאחרונה פורסם מידע חדש ב-Chrome עם פירוט התוכניות שלנו בנושא GeoIP. אנחנו מתכננים לפרסם מידע נוסף על לוחות הזמנים לפריסה ברבעון השלישי. אנחנו צופים שבשלב הראשון נשיק את התכונה 'הגנה על IP' כתכונה להבעת הסכמה למשתמשים בקרב אחוז קטן מתנועת הגולשים. הסיבה לכך היא שאנחנו מבינים שההצעה הזו עשויה להיות כרוכה בשינויים משמעותיים עבור חברות, ורוצים לתת לסביבה העסקית זמן להסתגל ולספק משוב לפני שהתכונה תושק באופן נרחב יותר. |
| אימות חשבון | איך יתבצע אימות חשבון באמצעות שרת Proxy? | אנחנו מתכננים לפרסם פרטים נוספים על אימות חשבונות בהמשך הקיץ, אם כי כבר שיתפנו כמה שיקולים ראשוניים. |
הקלות במעקב אחר עזיבה מהדף הראשון
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הנחיות לבדיקה | מידע על בדיקת הקלות במעקב אחר עזיבה מהדף הראשון | במאי פרסמנו פוסט בבלוג עם מידע נוסף על אופן הבדיקה של הקלות במעקב אחר עזיבה מהדף הראשון. |
| משאבי עזרה | בהירות ההצעה למעקב אחר עזיבה מהדף הראשון | ההצעה הנוכחית עדיין בשלבי פיתוח ו-Chrome ממשיך לעדכן את ההצעה כדי לספק בהירות ומידע לסביבה העסקית. אנחנו פועלים כדי לספק פרטים נוספים ונשמח לקבל כל משוב נוסף. |
| מחיקת קובצי cookie | האם מיטיגציה של מעקב אחר עזיבה מהדף הראשון תמחק את כל קובצי ה-cookie בדומיין? | צמצום של מעקב אחר עזיבה מהדף הראשון (BTM) ינקה את כל נפח האחסון וכל המטמון, כמו שמוסבר כאן. |
| עקיפת ההקלות במעקב אחר עזיבה מהדף הראשון | ניתן לעקוף את הסיווג של הכלי למעקב אחר עזיבה מהדף הראשון על ידי ביצוע הפניות אוטומטיות עם חלונות קופצים או כרטיסיות חדשות. | המפרט של הקלות במעקב אחר עזיבה מהדף הראשון עדיין נמצא בשלבי פיתוח. עד כה התמקדנו בעיקר בהפניות מחדש באותה כרטיסייה, אבל אנחנו מתכננים לעבוד על זרימות קופצות בעתיד. נשמח לקבל משוב נוסף. |
תקציב פרטיות
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| מיקוד לפי קירבה | תקציב הפרטיות עשוי להשפיע על תרחישים לדוגמה של טירגוט לפי קרבה. | קיבלנו משוב על הנושא הזה, ונשמח לשמוע עוד על ההשפעות האפשריות של המערכת האקולוגית. |
חיזוק גבולות הפרטיות בין אתרים
דומיינים של צד ראשון
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| (דווח גם ברבעונים הקודמים) מגבלת דומיין | בקשה להרחבת מספר הדומיינים המשויכים | ב-Chrome מתבצעת הערכה של המגבלה המספרית המתאימה לקבוצת המשנה Associated שתשמור על איזון בין הפרטיות לבין התועלת עבור התרחישים לדוגמה שזוהו. כבר מהשלב הראשון ב-Chrome, שיתפו אותנו שהמספר המדויק של קבוצת המשנה Associated עדיין לא סופי. |
| תרחיש לדוגמה מוטמע | תמיכה בתרחישים לדוגמה מוטמעים שמחייבים דומיינים של צד ראשון, CHIP ואחסון משותף | הצוות של Chrome קיבל את המשוב על התרחיש לדוגמה, והצוות בודק את הבעיה ומברך על משוב נוסף. |
| ניהול מאגרים | מידע על כללי מדיניות להסרה של קבוצות מאינטראקציה ישירה מהמאגר ב-GitHub, אם יש פערים בנתונים או הזנחה. | התקבלה ב-Chrome משוב לגבי התרחיש לדוגמה הזה. הצוות בודק את הבעיה ומזמין משוב נוסף. |
| הדרכת המשתמשים | כדי לעודד את השימוש בקבוצות של דומיינים של צד ראשון, Chrome צריך להגביר את המוּדעוּת של המשתמשים לקבוצות של צד ראשון ולהבין אותן. | אנחנו ב-Chrome מחויבים ללמד את המשתמשים על דומיינים של צד ראשון, ופרסמו מאמר במרכז העזרה (שמקושר מממשק המשתמש של Chrome) בנושא הזה. בנוסף, אנחנו משקיעים ב-Chrome כדי ללמוד איך ללמד משתמשים בצורה הטובה ביותר בהקשרים המתאימים. |
| פרסום בתלת-מימד | קובצי 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 עשוי להקל על חסימת מודעות לחסימת מודעות. | תוספים יכולים לקיים אינטראקציה עם מסגרות מגודרות בדומה לאופן שבו הם יקיימו אינטראקציה עם iframes. כתובת ה-URL בפועל שאליה תתבצע ניווט אל המסגרת המגודרת תהיה גלויה גם לתוספים, ולכן הם יוכלו להחיל כל כלל להתאמת כתובות URL לחסימה כמו במסגרות iframe. פשוט חסימה של כל המסגרות ללא תנאי עלולה לבטל את החסימה של מסגרות מגודרות שאינן מודעות. |
ממשק API לאחסון משותף
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| אימוץ רחב יותר | נפח האחסון המשותף צריך להיות תקן מקובל בתחום שזמין בכל הדפדפנים. | אנחנו מקבלים בברכה את המשוב הזה ומאשרים אותו. Chrome ממשיך להשתתף באופן פעיל ב-W3C כדי לקדם את ההצעה, לקבל משוב ולעודד אימוץ. |
| שערי פלט | שערי הפלט של האחסון המשותף מוגבלים מדי. | אנחנו שוקלים את המשוב הזה ומקדמים בברכה משוב נוסף על הסביבה העסקית שמסבירה למה שערי התפוקה מוגבלים מדי. |
| תאימות לתקנות | איך יטופל האחסון המשותף בנוגע לתאימות לתקנות, כמו מדיניות שמירת נתונים? | בעזרת נפח אחסון משותף אפשר להטמיע לוגיקה ולהתאים אותה אישית כדי לשלוט בכל משך החיים ובתפוגה של כל הנתונים המאוחסנים. טכנולוגיות פרסום יכולות לעדכן או למחוק נתונים של נפח אחסון משותף על סמך חותמות זמן של הכתיבה. |
| בדיקת A/B | איך אפשר לבצע בדיקות A/B עבור אחסון משותף ו-Protected Audience API? | אנחנו פועלים כדי לפרסם הנחיות נוספות בנושא הזה ומקווים לשתף פרטים נוספים בעתיד. |
| מגבלת נפח אחסון משותף | מה יקרה כאשר תגיע למגבלת האחסון המשותף? | אם מגיעים למגבלה, לא יישמרו קלט נוסף. |
| גישה מרובה באותה טעינת דף | מה קורה כשמתבצעת גישה לאחסון משותף כמה פעמים באותה טעינת דף? | הדרך הטובה ביותר לטפל בבעיה היא באמצעות הפונקציה window.sharedStorage.append(key, value). במקום לעדכן את הערך של כל מודעה, שעלול לגרום להתנגשויות אם יש מודעות מרובות. פונקציית הצירוף תוסיף את הערך החדש בסוף הערך הקיים. |
| הפונקציונליות של iframe | האם נפח האחסון המשותף יתמוך בפונקציונליות מסוימת של iframe אחרי שהן יופסקו אחרי ההוצאה משימוש של קובצי cookie של צד שלישי? | לאחר ההוצאה משימוש של קובצי cookie של צד שלישי, האחסון המקומי ב-iframes יפוצל על ידי האתר ברמה העליונה, אבל מסגרות ה-iframe עצמן לא ייחסמו. לא ניתן לשכפל את הנתונים באחסון המקומי של iframe באתרים מרובים ברמה העליונה, אבל עדיין ניתן להשתמש באחסון המקומי בתוך ה-iframe. |
צ'יפים
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| מגבלת מחיצות | 10KiB לכל אתר שמחולק למחיצות הוא עדיין משמעותי, ורצוי להוריד אותו. | Firefox כבר ציין מיקום חיובי ב-CHIPS. לתמיכה ב-Webkit, אנחנו ממליצים למפתחים לשלוח משוב ל-Apple ישירות על הבעיה הזו ב-GitHub. המשוב הזה רלוונטי לתרחישים שבהם קובצי cookie מחולקים למחיצות (Partitions) מעדיפים על פני אחסון מחולק למחיצות (partitioning). |
| הטמעות מאומתות | פריטי CHIP עשויים להשפיע על תהליך הכניסה הנוכחי של SSO, בשל חלוקה שונה למחיצות (partitioning) שמשפיעה על הטמעות מאומתות. | אנחנו מתכוונים להשתמש ב-Storage Access API (עם בקשות ממשתמשים) כדי לתמוך בתרחיש לדוגמה של הטמעות מאומתות, ולאחרונה שלחנו Intent-to-prototype. |
| מדיניות לכל משך החיים של המשתמש | האם מדיניות פוטנציאלית לכל משך החיים תחול על קובצי 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 | מספר שותפים הביעו עניין בבדיקה או בשימוש ב-PST לצורך מניעת הונאות או מקרי שימוש שונים בבטיחות באינטרנט. | אנחנו שמחים לשמוע תמיכה והתעניינות בפתרונות חדשים נוספים שמשתמשים ב-PST. יש לנו משאבים וקוד לדוגמה שזמינים באתר למפתחים של Chrome, ונשמח לקבל משוב נוסף. |
| הונאה וניצול לרעה | הנחיות למניעת הונאות במודעות / זיהוי במדידה אחרי ההוצאה משימוש של קובצי cookie של צד שלישי כשאין יותר מזהים זמינים. | הוספנו כלים כמו אסימוני מצב פרטי, שעוזרים לשחזר חלק מהאותות שאבדו בגלל קובצי cookie של צד שלישי למטרות מניעת הונאה, אבל נוספו אמצעי בקרה חדשים על הפרטיות. אנחנו משקיעים באופן פעיל בהצעות חדשות למניעת הונאה וניצול לרעה כדי לשמר את היכולות הקיימות עם שינויים אחרים בארגז החול לפרטיות. |
| שיעור פרטי המנפיק | שיעור המידע המנפיק מהמקור גבוה מספיק כדי לזהות משתמשים ייחודיים. | עדכנו את המפרט כדי שיהיה ברור יותר אילו נתוני משתמש אפשר להעביר באמצעות אסימוני מצב פרטי. בכוונת תחילה, ניתן להשתמש בעד שישה מפתחות ציבוריים בו-זמנית, שעשויים לייצג "מצב" עבור משתמש ספציפי. ניתן לעדכן את קבוצות המפתחות האלה רק כל 60 יום (למעט במקרים נדירים שבהם יש צורך ברוטציית מפתחות למקרה חירום). רוטציית מפתחות זו מאטה את הפוטנציאל לצירוף נתוני משתמשים נוספים לאורך זמן. כל ממשק API חדש באינטרנט ישמור על איזון בין השימושיות לבין פרטי המשתמשים החדשים שהוא מספק. אנחנו מעריכים שקובצי PST יוצרים את האיזון המתאים בהגנה על פרטיות המשתמשים, תוך הפעלת תרחישים לדוגמה חשובים למניעת הונאה שהושפעו מההוצאה משימוש של קובצי cookie של צד שלישי. |
| אחזור שילוב | השילוב של fetch הוא מורכב ומיותר. |
יש יתרונות וחסרונות בשימוש ב-fetch, ואנחנו רוצים לבצע סטנדרטיזציה נוספת בסביבה העסקית של האינטרנט, אבל לדעתנו יהיה מוקדם מדי לבצע את השינוי הזה עד שיהיה לנו ברור יותר איך ייראה התקן. אם וכאשר יימצא תקן כזה, אנו מחויבים גם להעביר מפתחי אתרים באופן אחראי לסטנדרט הזה. |
| מיקום האחסון | צריך לאחסן את ההגדרות של המפתח של אסימוני המצב הפרטי באותו מיקום שבו נמצא פרוטוקול PrivacyPass. | במהלך הבדיקה במהלך תקופת הניסיון בגרסת המקור, המפתחים ציינו שהם מעדיפים את הגמישות לאחסן את המפתחות שלהם בכתובות URL כלליות במקום בספרייה עם הסיומת .well-known. פורמט ההתחייבות המרכזית ב-PrivacyPass לא מתאים במיוחד לגרסה שבה מערכי המפתחות נועדו לאפשר ערך מרומז של 'מטא-נתונים ציבוריים'. אם וריאנט של PrivacyPass יסומן בסופו של דבר כתקן עם מטא-נתונים ציבוריים (כ-POPRF, מסנוור RSA חלקי או מפתחות גישה), יכול להיות שנעבור לגרסה עתידית של PST כדי לתמוך בכך. |
| הטמעת כותרות ב-API | שאלות לגבי הטמעת כותרת של ממשק API | ככל שה-API עובר סטנדרטיזציה והשימוש בסביבה העסקית של ה-API הזה הולך ומתפתח, אנחנו מקווים לתמוך גם בגרסה הרגילה שאינה כותרת של ה-API הזה. בסופו של דבר, ייתכן שנוציא משימוש את גרסת הכותרת אם השימוש יהיה נמוך מספיק או אם יש מספיק כלים/תמיכה למפתחים לדרכים סטנדרטיות להתאמת בקשות הנפקה/מימוש עם נתונים אחרים. אנחנו דנים כאן. |
| הרשמה | האם כדאי לרשום מנפיקים אצל ספקי דפדפנים? | עדכנו את המפרט כדי לתאר את תהליך הרישום של המנפיק לאסימוני מצב פרטי. התהליך הזה מתבצע אמנם באמצעות תהליך משלו, אבל הוא דומה לתוכניות ההרשמה לשאר העבודה של ארגז החול לפרטיות, שבו אנחנו מבקשים מהמנפיקים לפרסם הצהרה ציבורית לגבי האופן שבו הם מתכוונים להשתמש ב-PST ולאשר את ההגבלות הטכניות שמגינות על פרטיות המשתמשים. |