דוח רבעוני לרבעון הראשון של שנת 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 למשוב פותחו על סמך שאלות נפוצות שפורסמו, תשובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת מיקום באופן ספציפי למטרת תרגיל זה של דיווח ציבורי. בהתאם למיקוד הנוכחי של הפיתוח והבדיקה, השאלות והמשוב שקיבלנו באופן ספציפי בנוגע לממשקי API של Topics, FLEDGE ו-Attribution Reporting.
יכול להיות שמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עוד לא נחשב כתגובה מ-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 |
|---|---|---|
| בדיקה והתנסות | הרלוונטיות של הבדיקות כדי לעדכן את ההערכה של ה-CMA אם ממשקי ה-API של ארגז החול לפרטיות לא יושלמו עד שהבדיקה תתחיל | הפיתוח של ממשקי ה-API של ארגז החול לפרטיות מתקדם בקצב.
הם כבר זמינים לבדיקה בגרסת המקור לניסיון, ובדרך כלל יהיו זמינים ל-100% מתנועת הגולשים בקיץ הקרוב. בנוסף, הבהרנו את לוחות הזמנים לתכונות מסוימות (כמו דיווח ברמת האירוע ב-FLEDGE, רינדור FLEDGE עם מסגרות iframe) שהעדכונים לא יושפעו לפני 2026. אנחנו ממליצים לסביבה העסקית לבדוק את ממשקי ה-API ולתת משוב ל-CMA, על סמך מה שהבודקים מצפים להסתמך עליו ברגע שקובצי ה-cookie של צד שלישי יוצאו משימוש. כך ניתן יהיה להעריך את ההשפעה המשוערת של ההוצאה משימוש של קובצי cookie של צד שלישי. |
| פקדי משתמש | הדרכה ברורה לסביבה העסקית בנוגע לאמצעי הבקרה של המשתמשים בממשקי ה-API של ארגז החול לפרטיות | אנחנו לא יכולים לספק ייעוץ משפטי בנוגע לאמצעי הבקרה של המשתמש בסביבה העסקית. באותו זמן, Chrome מתנסה בהצגת אמצעי בקרה מעודכנים לארגז החול לפרטיות ('פרטיות בפרסום משופרת') לאחוז קטן מאוד מהמשתמשים, כחלק מהמאמץ השוטף שלנו לשפר את הטכנולוגיות של ארגז החול לפרטיות. העדכונים כוללים שפה ופריסות ברורות ומועילות יותר. אחרי ש-Chrome בחן את החידודים האלה והחליט אם להרחיב אותם לאוכלוסייה גדולה יותר, הם יוכלו לשתף מידע נוסף עם הסביבה העסקית. |
| דליפת נתונים | יש סיכון לדליפת נתונים מאינטראקציה ישירה (First-Party) ל-Google ולגורמים אחרים במקרה שהדפדפן נמצא בסיכון | ההסבר של FLEDGE מבהיר שהנתונים של אותה טכנולוגיית פרסום משותפים רק עם אותה טכנולוגיית פרסום (עם המעבדים או השרתים המהימנים שלהם), או כשהלקוח משתף אותם במפורש (למשל, הקונה מציג למוכר את כתובת ה-URL של המודעה שהוא רוצה להציג). יוצא הדופן היחיד הוא שבדיקת האנונימיות k צריכה להתבצע על ידי שרת מרכזי גלובלי, וזה תחום שאנחנו ממשיכים להקדיש לו משאבים משמעותיים. הסבר מפורט על התפיסה שלנו בנושא פרטיות זמין במסביר של פרטיות K-anonymity. לאחר מכן, נשמח לתת פרטים נוספים על ההגנות של טכנולוגיות הפרסום שעליהן מתבססים בתכנון של שרת האנונימיות K. |
| פורום נוסף לדיון | בקשה לפורום נוסף של ה-W3C כדי ששחקנים עם סביבה עסקית לא טכנית יוכלו לשתף משוב | טופס המשוב על ארגז החול לפרטיות מתאים לתגובות כלליות וספציפיות, וגם לתגובות טכניות ולא טכניות. שיפור הקבוצה העסקית לפרסום באינטרנט הוא פורום לדיונים בשיחות שבועיות וגם מאגר של GitHub. בדף משוב של ארגז החול לפרטיות בכתובת developer.chrome.com מוסברים מנגנונים אחרים למתן משוב ולהשתתפות בדיון. ב-Chrome גם ממשיכים לקיים אירועים כמו שעות קבלה ציבוריות, כדי לאפשר שאלות ולשתף תוכן. בנוסף, Chrome אירח יותר מתריסר אירועים בתעשייה ברבעון האחרון או השתתף בו. |
| הבהרה בנוגע לציר הזמן | הבהרה לגבי התאריך המדויק של זמינות לכלל המשתמשים (GA) ברבעון השלישי 2023 | לפי לוח הזמנים שפורסם בכתובת PrivacySandbox.com, זמינות לכלל המשתמשים (GA) מכוונת להתחיל בהשקה החל מגרסה 115 של Chrome. |
| reCAPTCHA | ההשפעה של ממשקי Sandbox API על התרחיש לדוגמה של זיהוי ספאם ב-reCATPCHA | אנחנו מקבלים מדי פעם משוב מ-reCAPTCHA כדי לוודא שההצעות במסגרת ארגז החול לפרטיות לא משפיעות באופן משמעותי על הבטיחות באינטרנט או על הונאות. הם מפתחים תוכנית משלהם כדי להתכונן להוצאה משימוש של קובצי cookie של צד שלישי, ולכן עדיף להיעזר בשאלה הזו. |
| תוספים ל-Chrome | האם טכנולוגיות של ארגז החול לפרטיות, כמו אמצעי המעקב אחר Covert (ACT) יחולו על תוספים ל-Chrome? | לא פרסמנו שום מידע לגבי האופן שבו אפשר להחיל את ACT על תוספים ל-Chrome. עם זאת, אם טכנולוגיה אוספת מידע על משתמש באופן סמוי, הדבר לא עומד בעקרונות הפרטיות שלנו. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| TAG בדיקת עיצוב | TAG פורסם במהלך 'סקירת עיצוב מוקדמת' של Topics. | אנחנו ממשיכים להיות מחויבים ל-Topics. שיתפנו עדכון לגבי המחויבות שלנו ל-Topics בדף העדכונים האחרונים ובגיליון הזה. הגבנו באופן מפורט לביקורת של TAG, ושיתפנו את החזון שלנו, ברמה הגבוהה יותר, כאן. Topics API ימשיך להיות חלק מאוסף ממשקי ה-API שאמורים להיבדק בסביבה העסקית של הפרסום במהלך 2023, ואנחנו מקווים שהמשוב שנקבל במסגרת הבדיקות והחוויה שנצפתה במסגרת ההטמעה תאפשר לנו לתרום באופן משמעותי במאמצים שלנו לעמידה בסטנדרטים של דפדפנים שונים בתחום הזה. נשמח להמשיך ולעבוד עם המערכת האקולוגית כדי להקל על המעבר, במקרים שבהם Topics API עשוי להיות תקן מוסכם עם תאימות לדפדפנים שונים. |
| גישה לנושאים | תמיכה בגישה הפתוחה שיש ל-Chrome כדי לפתח את Topics API | אנחנו מעריכים את התחושות האלה ומצפים להמשיך לעבוד עם קבוצת התעשייה כדי לפתח Topics API שיספק ערך כללי לסביבה העסקית. |
| (דווח גם ברבעון השלישי של 2022) טקסונומיית הנושאים לא מפורטת מספיק |
טקסונומיה של נושאים רחבים לא כוללת נושאים מפורטים יותר, כולל נושאים ספציפיים לאזור. | עדכון לרבעון 1: אנחנו לא מפסיקים לנסות לשפר את הטקסונומיה, וברבעון השני אנחנו מכריזים על טקסונומיה מעודכנת ל-Topics API. כדי לבנות את הטקסונומיה החדשה הזו, עבדנו בשיתוף פעולה הדוק עם חברות בכל רחבי הסביבה העסקית. אנחנו מעוניינים לקבל משוב על הטקסונומיה שיכולה להועיל מאוד לסביבה העסקית. כשאנחנו שוקלים אם להרחיב את מספר הנושאים או לכלול נושאים מפורטים יותר, יש כמה שיקולים, כולל 1) השלכות פוטנציאליות על פרטיות (נושאים רבים יותר עלולים להוביל לסיכון של יצירה של טביעת אצבע דיגיטלית) ו-2) היכולת לאחזר נושאים שנצפו בעבר (למשל עם יותר נושאים, יש סיכוי נמוך יותר שטכנולוגיית הפרסום ראתה את הנושא שנבחר בעבר). |
| (דווח גם ברבעון הרביעי של 2022) ההשפעה על אותות מאינטראקציה ישירה (First-Party) |
אותות של נושאים יכולים להיות חשובים מאוד, וכתוצאה מכך פוחת הערך של אותות אחרים מאינטראקציה ישירה (First-Party). | אנחנו מאמינים שפרסום המבוסס על תחומי עניין הוא תרחיש חשוב לדוגמה באינטרנט, ו-Topics API נועד לתמוך בתרחיש הזה. אנחנו מבינים שחלק מבעלי התוכן הדיגיטלי גדולים חוששים ש-Topics API ישפיע לרעה על האסטרטגיות שלהם לנתונים מאינטראקציה ישירה (First-Party). נשמח לבצע בדיקות של הסביבה העסקית, שיספקו תובנות לגבי ההשפעה של Topics על בעלי תוכן דיגיטלי. |
| תרחישים לדוגמה בנושאים שאינם קשורים למודעות | שימוש ב-Topicss למטרות שאינן הצגת פרסום מבוסס-עניין | Topics נועד לטפל בתרחיש לדוגמה של פרסום מבוסס-עניין, שלדעתנו הוא תרחיש קריטי לשימוש באינטרנט החופשי והפתוח. אנחנו מחפשים כרגע משוב על תרחישים אחרים לדוגמה, ואנחנו מבצעים הערכה. |
| סטטוס ברירת המחדל להצטרפות | השפעות של חקיקה אזורית על ערכי ברירת המחדל לקבלת הסכמה במסגרת Topics | אין זה מתפקידנו להגיב על חוות דעת משפטיות. |
| (מדווח גם ברבעון השלישי של 2022) אתרים שסווגו באופן שגוי |
טירגוט מודעות כשהנושאים מסווגים באופן שגוי לאתר נתון | עדכון לרבעון 1: ברבעון 2 נכריז על מסווג מעודכן ל-Topics API, ונשמח להפעיל את הסביבה העסקית שבה. בתגובה למשוב הנוכחי, האתרים מסווגים באמצעות שילוב של רשימת שינויים מברירת המחדל שנוצרה על ידי אדם, שכוללת את האתרים הפופולריים ביותר ומודל למידת מכונה במכשיר. Chrome ממשיך לבדוק את האפשרויות להוספת אתרים לסיווג של 'נושאים'. יש לשקול את כל השיפורים בתועלת מול סיכוני הפרטיות וניצול לרעה. לדוגמה, כמה מהסיכונים כוללים: אתרים שמשתמשים בתווית עצמית כשיטה לקידוד נושאים שונים (שעשויים להיות רגישים) למשמעויות שונות, אתרים שמציגים מצג שווא של הנושאים שלהם לרווח כספי, אתרים שתוקפים נושאים כדי להבליט את התועלת שלהם לאחרים (לדוגמה, הם שולחים ספאם לנושאים של המשתמשים ברעש חסר משמעות). הציבור יכול לבדוק את הרכיבים האלה באמצעות הכלים שזמינים דרך chrome://topics-internals או דרך colab. באמצעות הבדיקה, אנו צופים שהסיווג ישתפר עם הזמן, ואנו נשמח לקבל משוב על דוגמאות של אתרים שייתכן שלא סווגו כראוי. |
| מסווג נושאים | בקשה להחזרת מידע נוסף שמציג את הסיבות לכך שהמתקשר מוחזר "ללא נושאים" למטרות ניפוי באגים | אנחנו מבינים ומעריכים את הכלים לניפוי באגים שעוזרים למפתחים לשלב את Topics API במערכות שלהם. עם זאת, כתוצאה מחשיפה של מידע נוסף (כמו הסיבה לכך שלא הוחזרו Topics), אנחנו עלולים לשתף בטעות מידע שמאפשר לצדדים לחשוף פרטים נוספים (למשל, אם המשתמש נמצא במצב פרטי, השבית את ה-API וכן הלאה) מעבר למה שמצופה, תוך פגיעה בפרטיות המשתמשים. אנחנו לא מתכננים לספק כלים נוספים לניפוי באגים בשלב הזה, אבל נשמח לקבל משוב על הכלים החשובים. |
| אחזור מידע פרטי (PIR) | בקשה לשימוש ב-Topics API לצורך אחזור מידע פרטי | בעבר חקרנו את האפשרות לשימוש ב-PIR ושיתפנו כאן את החסרונות. |
| מקור הצעת המחיר | האם Topics API ייוצג באופן נפרד מ'קהלים בהגדרת המפיץ' בהצעות המחיר? | Topics API הוא הצעה לארגז חול לפרטיות שפותחה על ידי Chrome, ושונה מההצעה קהלים בהגדרת המפיץ של IAB Tech Lab. אנחנו מצפים ששניהם יהיו מיוצגים באופן נפרד ב-Bidstream. איך Topics API יוצג בבקשות להצעת מחיר ב-OpenRTB? |
Protected Audience API (לשעבר FLEDGE)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| זמינות התכונות של FLEDGE | הבהרה לגבי לוחות הזמנים לבדיקה ולהטמעה של תכונות FLEDGE כמו אכיפה של Fenced Frame , K-Anonymity וכו'. | שיתפנו פוסט בבלוג על מגוון תכונות של FLEDGE בהיקף רחב ומתי התמיכה בהן. נשמח לקבל משוב נוסף לגבי ההכרזה בזמן שאנחנו ממשיכים לפתח את FLEDGE. |
| הגבלות על עיבוד מוצרים | בקשה להרחבה של מודעות שמורכבות מהגבלות של מספר חלקים עבור FLEDGE Fenced Frames | כפי שהודענו בפברואר, השימוש ב-Fenced Frames יישאר אופציונלי עד לפחות 2026, ותהיה תמיכה בהתנהגות של iframes באמצעות urn-iframes. נשמח להמשך דיון בנושא הזה. |
| בעיות שקשורות ליכולת התאמה | ביצועי FLEDGE כסולמות של השימוש | אנחנו ממשיכים לעקוב באופן פעיל אחרי המשוב ומבינים את ההקשר הרחב יותר, כדי שנוכל להציע פתרונות שימושיים. בשלב הראשון חילקנו את המשוב לשתי קטגוריות:
|
| (מדווח גם ברבעון השלישי של 2022) החשיפה של לוגיקת הבידינג |
חשש שהלוגיקה של מתן הצעות מחיר בפלטפורמת DSP תיחשף ב-JavaScript | עדכון לרבעון 1: שיתפנו הצעה שתגביל את היכולת של יריבים לבקש נתונים מהשרת בדרך של ניסוי (גלישה מאולצת), ואנחנו מעודדים שחקנים של המערכת האקולוגית לשתף את המשוב שלהם או את התמיכה שלהם בהצעה. |
| קשיים בבדיקה | יכולת של DSP קטנים יותר לבדוק כראוי את FLEDGE ולצמצם את הסיכון שהמפרסמים ירצו לבדוק רק באמצעות פלטפורמות DSP גדולות יותר | אנחנו מחויבים לעבוד עם פלטפורמות DSP קטנות יותר ומעודדים מאוד לבצע בדיקות מורחבות בקרב פלטפורמות DSP ומפרסמים בכל הגדלים, ככל ש-FLEDGE עובר לזמינות לכלל המשתמשים. נשמח לדעת איך נוכל לעזור להם בצורה הטובה ביותר לבדוק את FLEDGE יחד עם גורמים אחרים בסביבה העסקית, ולקבל בברכה רעיונות ומאמצים בתחום כדי לעודד מפרסמים לבצע בדיקות באמצעות פלטפורמות DSP קטנות יותר. |
| רימרקטינג דינמי | האם ניתן יהיה להמשיך להשתמש ברימרקטינג דינמי לאחר ההוצאה משימוש של קובצי cookie של צד שלישי ש-FLEDGE? | אנחנו שוקלים להשיב לשאלה הזו, ושמחים לצרף שחקנים נוספים בסביבה העסקית כדי לשתף איתם תובנות נוספות לגבי האופן שבו הם מתכוונים להשתמש ברימרקטינג דינמי. |
| הונאה/ניצול לרעה | איך המערכת האקולוגית יכולה להפחית את הסיכונים ולמנוע מגורמים או מקונים רעים למיצוב את עצמם כקהל רצוי? | אנחנו מצפים להמשך העבודה עם גורמים נוספים בסביבה העסקית בנושא הונאות וניצול לרעה, ונשמח לקבל משוב נוסף בנושא. |
| העדפות משתמש | תהליך לשמירת העדפות המשתמש ולשימוש בהן בבחירת מודעות | במודעות ספציפיות, טכנולוגיית הפרסום הרלוונטית היא הגורם בעמדה המתאימה ביותר לשליטה בקריאייטיבים שיוצגו או באופן הבחירה בהם. |
| הצעה לבדיקה כמותית | כדי שבדיקה כמותית תהיה הוגנת, האם הבדיקה צריכה להתבצע על תנועת גולשים ללא קובצי cookie של צד שלישי או עם SSP שמשתמשים רק ב-FLEDGE? איך אפשר להימנע משילוב של אותות מקובצי cookie של צד שלישי? | אנחנו מעריכים את המשוב הזה ופועלים יחד עם ה-CMA כדי לתכנן ניסויים שיספקו תמונה אמינה לגבי ההשפעה של ההוצאה משימוש של קובצי cookie של צד שלישי והשקת ההצעות של ארגז החול לפרטיות על הסביבה העסקית. מומלץ לשתף משוב נוסף לגבי ההצעה של ה-CMA לביצוע בדיקות כמותיות ישירות עם ה-CMA. |
| תיעוד ברור יותר | בקשה לתיעוד ברור יותר בנושא הגדרת מכרזים | אנחנו מקווים לשתף בשבועות הקרובים פוסט בבלוג עם סקירה כללית נוספת על דוחות המכרזים של FLEDGE. |
| מקביליות | האם שירותי הבידינג והמכרז (B&A) יתמכו במקבילית? | פרסום דיגיטלי שמשתמש בשרתי בידינג או מכרזים יכול להפעיל כמה שרתים שיכולים להציג תוצאות במקביל. |
| צמצום מקרי הניצול לרעה | האם שרת ה-k-anonymity של FLEDGE שמשתמש באסימוני מצב פרטי יספיק כדי להבטיח את פרטיות המשתמשים? | המטרה של k-anonymity היא פחות ממוקדת במיקרו-טירגוט, ומתמקדת יותר בעצירה מסוימת בשלב הביניים, שבו FLEDGE מאפשר דיווח ברמת האירוע. שיתפנו עוד רעיונות ונשמח לקבל משוב נוסף. |
| התנגשות בין מודול ES | בקשה לשחרר את generateBid כפונקציה גלובלית מכיוון שהיא מתנגשת עם מודול ES |
אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף. |
| מכרז של רכיבים | לבקש מבעלי האתרים שליטה רבה יותר בעיצובים של מכרזים | הבידינג והמכרזים מתכננים לתמוך במכירה פומבית של רכיבים, בדיוק כמו Chrome במכשיר. |
| צירי זמן של צימרים | בהירות לגבי לוח הזמנים של טכנולוגיות פרסום שמעוניינים בבדיקת שרתים של B&A | בדיוק עדכנו את הכלי להסבר על B&A ועדכנו את הקטע של ציר הזמן כך שיכלול הגדרות ברורות של לוחות זמנים לשלבים שונים של הבדיקה של Chrome-B&A, אחרי התאמה ל-CMA. |
| סכימה לבקרת הזמן הקצוב | שיפור הסכימה של בקרת הזמן הקצוב לתפוגה שזמינה כרגע עבור FLEDGE | זוהי הצעה מעניינת. נוסיף זאת לתור ההצעות למחקר ונדווח על ההתפתחויות שלנו. |
| מקורות בידינג של נכסי קריאייטיב | יכולת לבדוק ולסנן את הצעת המחיר הזוכה, על סמך הקריאייטיב | זוהי הצעה מעניינת. נוסיף זאת לתור ההצעות למחקר ונדווח על ההתפתחויות שלנו. |
reportWin |
הצעה לספק מידע נוסף על הצעת המחיר בעלת הניקוד הגבוה ביותר מבעלים אחר של קבוצת אינטרס, שאינו הזוכה בפונקציה reportWin |
זוהי הצעה מעניינת. אנחנו נשקול להוסיף אותות נוספים בדיווח מצטבר ונשמח לקבל כאן משוב נוסף. |
| סוגי אירועים. | סטנדרטיזציה של סוגי אירועים בממשקי API למדידה כשהם משולבים עם FLEDGE | זוהי הצעה מעניינת. נוסיף זאת לתור ההצעות למחקר ונדווח על ההתפתחויות שלנו. הוא ידרוש תיאום עם המאמצים שלנו בתחום הזה, כי הוא ישפיע על ממשקי API אחרים של ארגז החול לפרטיות מעבר ל-FLEDGE. נשמח לקבל ממך משוב נוסף כאן. |
| פתרונות לטווח ארוך לדיווח ברמת האירוע | רוצים שנתונים מסוימים כמו highestScoringOtherBid יישארו זמינים גם אחרי ההוצאה משימוש של קובצי cookie של צד שלישי |
כפי שהודענו בפוסט בבלוג בפברואר, התמיכה בדוחות על זכיות במכרז ברמת האירוע תימשך עד "לפחות 2026". אין לנו פרטים נוספים לשתף איתך כרגע, אבל נשמח לקבל משוב נוסף שמסביר למה חשוב שנתונים מסוימים יישארו זמינים אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. |
| מגבלת קבוצות אינטרס | מה המגבלה של מספר קבוצות האינטרס שמקור יכול להוסיף להן דפדפן אחד? | ב-Chrome אפשר ליצור עד 1,000 קבוצות של תחומי עניין לכל בעלים, ועד 1,000 בעלים של קבוצות לפי תחומי עניין. הן נועדו לשמש כשכבות הגנה, ולא כדי לפגוע בהן במסגרת פעילות רגילה. |
| אותות ברמת האירוע | תמיכה בהצעה להוספת אותות ברמת האירוע ל-generateBid
ול-reportWin, שאפשר להשתמש בהם באימונים של למידת מכונה |
שיתפנו איתך את ההחלטה שלנו לגבי אותות בעיצוב דפדפן ואותות מוגדרים לפי טכנולוגיות פרסום, ונשמח לקבל משוב נוסף. |
| סקריפט של בידינג | כוללים את מזהה המשתמש בכתובת ה-URL של סקריפט הבידינג. | לא ניתן יהיה לבצע זאת, כי ב-FLEDGE יש דרישה נוספת לכך שהצירוף של הבעלים של קבוצת תחומי העניין, כתובת ה-URL של סקריפט הבידינג והקריאייטיב המעובד חייבים להיות אנונימיים k-אנונימיים כדי שמודעה תוצג. |
| אכיפת K-anon | האם אכיפה של k-anonymity מתבצעת בזוג (componentAd, size)? | כן. פרטים נוספים זמינים בכתובת turtledove/issues/312. |
| דרישות לגבי שירותי בידינג ומכרזים | איך שירותי B&A תומכים במשתתפים שמשתלבים עם FLEDGE במכשיר ועם אחרים עם שירותי B&A? | אנחנו עדיין עובדים על העיצוב, ונשמח לקבל משוב נוסף. |
| ייחוס בעקבות צפייה | האם תהיה תמיכה בשיוך לאחר צפייה? | בשלב זה אין לנו הגדרה סטנדרטית כלשהי של ניראות, ואנחנו מסתמכים על הקריאייטיב עצמו כדי לסמן אירוע של צפייה. אפשר לעיין במידע נוסף כאן: turtledove/בעיות/452. |
| טירגוט לפלחים דומים | האם ארגז החול לפרטיות תומך ב'טירגוט דומה לרשימה קיימת'? | אנחנו דנים בתרחיש לדוגמה, ונשמח לקבל נתונים נוספים. |
| API לניטור בזמן אמת | הצעה לגישת מעקב בזמן אמת לגבי FLEDGE | אנחנו דנים בהצעה ומברכים כאן על נתונים נוספים. |
| דיווח על FLEDGE | צריך לשלוח את הערכים reportWin ו-reportResult לפי סדר אקראי כדי למנוע דיווח יתר או נמוך מדי. |
המוכר צריך להפעיל קודם את reportResult() לפני
reportWin() על ידי הקונה, כדי שאפשר יהיה לכלול אותות של אתר המכירה מ-reportResult() ב-reportWin(). מידע נוסף זמין במסביר. |
| שרתי ערך מפתח בהתאמה אישית (K/V) | האם תהיה תמיכה בשרתי K/V בהתאמה אישית בעתיד? | אנחנו דנים כאן בשאלה ומברכים כל משוב נוסף. |
| מכרז ברמה העליונה | האם צריך להיות שרת מודעות כדי להפעיל מנגנוני מכרזים ברמה העליונה? | ב-FLEDGE API לא מצוין איזה צד צריך לקרוא לו. אין דרישות מהבחינה הזו בעיצוב של FLEDGE. כל אחד יכול להפעיל את המכרז ב-FLEDGE (כולל מכרזים שמוגדרים בהם כמה אתרי מכירה). כפי שצוין בדוח הרבעון הרביעי של 2022, בעזרת FLEDGE כל בעל אתר יכול לבחור את המבנה של המכרז, כולל הבחירה של אתרי מכירה ברמה עליונה ומוכרי רכיבים. |
| היקף ה-API | האם FLEDGE מתכוון לעבוד עם נתונים מאינטראקציה ישירה (First-Party)? | נפרסם תוכן ברבעון השני של 2023 כדי להבהיר שאפשר להשתמש בנתונים מאינטראקציה ישירה (First-Party) בעזרת FLEDGE בשתי דרכים: 1) להשתמש בתור לוגיקה לקביעת השתייכות לקבוצת תחומי עניין, 2) להזין את הנתונים כאותות לבידינג של משתמשים, ולהשתמש בהם במהלך יצירת הלוגיקה של הבידינג. |
| קבוצות אינטרס בכמה דומיינים | האפשרות ליצור קבוצות אינטרס בכמה דומיינים | כל מידע שזמין בזמן הוספת דפדפן לקבוצת עניין, יכול לשמש כדי ליידע את הקהל הזה. כשאנחנו מוציאים משימוש קובצי cookie של צד שלישי, הזמינות של נתונים מאתרים שונים לצורך יצירת קבוצות של תחומי עניין תהיה מוגבלת. |
| לוגיקת הבידינג בצד הלקוח | ניוד הלוגיקה הקיימת של בידינג בצד השרת לצד הלקוח | נשמח לקבל מידע נוסף על התחומים המאתגרים או החסרים בתהליך הניוד, ונשמח לקבל כל משוב נוסף או תובנות נוספות. |
| ערכי שרת K/V | האם הערכים של שרת K/V צריכים להיות מסוג מחרוזת? | הערך צריך להיות מחרוזת, אבל אפשר לאחסן אובייקטים ב-JSON או במאגר של פרוטוקולים ולהזין אותם בהמשכים למחרוזת. |
| רשימת חסימה של מפרסמים | אילו אותות מתאימים לספק קונה לרשימת חסימה של מפרסמים? | המקום המתאים הוא ב-auctionSignals או
ב-perBuyerSignals. |
| יחידת בידינג | תמיכה ביחידות בידינג שונות, כמו עלות להתקנה (CPI) ועלות לאלף חשיפות (CPM) | נשמח לשמוע ממך למה זה נחוץ בהתחשב בעיצוב הנוכחי, ונשמח לקבל משוב נוסף. |
| לוגיקת המכרז | האם הדפדפן או שרת המודעות קובעים את הזוכה במכירה הפומבית? | כל בחירת הזוכים מתבצעת בתוך ארגז החול, וכל ההחלטות מתקבלות על פי קוד המפיץ. הדפדפן פשוט מספק סביבה פרטית אטומה שבה פועל הקוד של הקונה והמוכר. |
| מדיניות הרשאות | האם האכיפה של מדיניות ההרשאות הנוכחית של FLEDGE תימשך אחרי שתקופת הניסיון למקור תסתיים? | בגרסת המקור לניסיון, רשימות ההיתרים הנוכחיות של שתי התכונות הן זמניות וישתנו. נשמח לדעת כמה זמן מומחי הפרסום יצטרכו להתכונן לשינוי, לפני שנתחיל לאכוף אותו. |
| מגבלה על גודל האות | הבקשות לאותות מהימנות של בידינג עוברות איחוד על פני כמה קבוצות של תחומי עניין עם אותו trustedBiddingSignalsUrl, מגבלת הגודל של 2MB היא מגבלה. |
האילוץ קיים למתקשרים במכשיר כדי למנוע עומס על המשאבים במכשיר. למתקשרים משרת שאלות ותשובות יהיו מגבלה פחות מחמירה. |
| אותות דיווח | כדאי להוסיף אות נוסף, שגיאות בסקריפט, כדי לאפשר אחזור של מספר השגיאות בצד הלקוח לכל בעלים של קבוצת תחומי עניין ולכל computeBid או reportWin / reportResult. |
אנחנו מביאים בחשבון חששות פוטנציאליים בנוגע לפרטיות בהצעה הזו, ואנחנו שמחים לגורמים נוספים בסביבה לשתף תובנות נוספות לגבי הסיבה לכך. |
| גודל החלון של K-Anon | מגדילים את חלון K-Anon מהמגבלה הנוכחית של 7 ימים. | הנושא נמצא בבדיקה ואנחנו ממתינים (ואנחנו שמחים) לקלט נוסף מהסביבה העסקית. |
| ביצועי המכשיר | איך FLEDGE מטפל בביצועי מכשירים אם המשתמש שייך למספר גדול של קבוצות של תחומי עניין? | FLEDGE מציע מספר אפשרויות של זמן קצוב לתפוגה, תעדוף והגבלה ב-SSP ובפלטפורמות DSP, שמעניקות לטכנולוגיות הפרסום שליטה פרטנית במצבים שבהם ביצועי המכשיר עשויים להיות סיבה אחת להגבלת ההשתתפות במכרז כאשר המכשיר נמצא במספר גדול של קבוצות של תחומי עניין. |
| בדיקה של שירותי B&A | לבקש מהשחקנים של הסביבה העסקית להשתמש בשרת משלהם בשלב הבדיקה, כדי שיהיו יותר יומנים זמינים לניפוי באגים | B&A מאפשרת למשתמשים להפעיל שרתים מספקי ענן מאושרים, ולהתאים אותם לעומס (scaling). כדי לשמור על פרטיות המשתמשים, אנחנו אוכפים את הביצוע בסביבת ביצוע מהימנה (TEE). בקרוב נפרסם הסבר על ניפוי באגים ב-B&A TEE, ומפתחים תכונות שיתמכו בכך. אנחנו מבקשים משוב נוסף בנושא. |
| דרישות תקינה | האם FLEDGE יעבוד עם ספקי ענן במדינות שונות כדי לתמוך בתאימות לדרישות רגולטוריות מקומיות? | אנחנו תמיד פתוחים להצעות לספקי ענן אחרים, אבל כרגע אנחנו מתכננים לפחות לתמוך ב-GCP וב-AWS כאשר תיאכף ההוצאה משימוש של קובצי cookie של צד שלישי. למידע נוסף, קראו את ההסבר הזה. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| ניתוח נתונים של השפעת הרעש | הנחיות לביצוע ניתוח נתונים לגבי ההשפעה של רעש. | שיתפנו מסמכים נוספים לגבי החלטות בנושא רעש והחלטות עיצוב, שאפשר להשתמש בהן כדי לשנות את ההשפעה של רעש על נתונים של טכנולוגיות פרסום. יש גם מדריך מפורט יותר. |
| דיווח אפס | בהירות לגבי ההטמעה של דוחות אפס | אנחנו עובדים כרגע על הצעה להטמעת דוחות אפס (null), ונשתף פרטים נוספים בקרוב. הטמעת דוחות null תאפשר לנו לצמצם עיכובים בדיווח בלי לפגוע בפרטיות. |
| רמת הרעש | התאמת רמת הרעש על סמך האורך של חלון השיוך | אנחנו מקבלים בברכה את ההצעה הזו ופועלים להוסיף אותה למפרט. נשמח לקבל משוב נוסף. |
| גודל נתוני ההפעלה | למה גודל הנתונים של הטריגר מוגבל ל-3 ביט? | הגודל מוגבל ל-3 ביט ול-8 ערכים נפרדים כדי להבטיח שכמות המידע לגבי המשתמש בין אתרים וההקשרים מוגבלת. אנחנו מזמינים את השחקנים בסביבה העסקית לשלוח משוב כדי להבין אם יש הגיוני להוסיף את הפרמטרים הנוכחיים לדיווח ברמת האירוע. |
| טריגרים של דיווח ברמת האירוע | מתן עדיפות למפתח לביטול כפילויות | אנחנו בודקים פתרונות לבעיה הזו, ונשמח לקבל משוב נוסף. |
| תמיכה בניפוי באגים | בהירות לגבי ניפוי באגים לאחר ההוצאה משימוש של קובצי cookie של צד שלישי | אנחנו מעוניינים לתמוך בניפוי באגים לאחר ההוצאה משימוש של קובצי cookie של צד שלישי ובוחנים אפשרויות. אנחנו מעוניינים במשוב וברעיונות נוספים. |
| חלופות להמרות מסוג קליק | לבקש הדרכה נוספת לגבי חלופות להמרות לאחר קליק | אנחנו ממליצים לסביבה העסקית להשתמש ב-Attribution Reporting API בתור מערכת מדידה פרטית ועמידה בתרחישים רלוונטיים של מדידת המרות. קיימות חלופות אחרות, וספקי טכנולוגיות פרסום יצטרכו להחליט מה הפתרון המתאים על סמך צורכי הפרטיות והתועלת שלהם. |
| תרחישים לדוגמה לחיוב | בהירות לגבי המידה שבה דוחות השיוך (Attribution) יתמכו בתרחישים לדוגמה של חיוב המבוסס על המרות | אנחנו פועלים כדי לפרסם באופן ציבורי את ההיקף של Attribution Reporting API לצורכי חיוב. היקף השימוש ב-Attribution Reporting API לא הוגדר בהתחלה בצורה שתומכת ישירות בחיוב לפי עלות להמרה. הוא תומך בחיוב לפי עלות לקליק ועלות לאלף חשיפות, שהוא מבנה החיוב העיקרי של טכנולוגיות הפרסום. יכול להיות שנתמוך באפשרות הזו בעתיד אם יהיה משוב נוסף של המערכת האקולוגית. |
| תרחישי שימוש לדוגמה | תרחישים לדוגמה לשימוש ב-Measurement API | אנחנו עובדים על הבהרת המסמכים בכל פלטפורמות הדיווח של ארגז החול לפרטיות. |
| איכות קליקים | בקשה להוספת אות כדי להבחין בין קליקים מכוונים וקליקים לא מכוונים על מודעה | אנחנו דנים בבקשה ומברכים על כל משוב נוסף. |
| פתרון למדידת ביצועים | תמיכה בפתרונות מדידה בכמה פלטפורמות DSP | ספקי מדידה יכולים להשתמש ב-Attribution Reporting API כדי לבטל כפילויות בין מספר DSP. כמו כן, אנחנו מציעים תמיכה ברשימה של כתובות URL ב-attributionsrc, שתקל על ספקי DSP לתמוך בבקשות של ספק מדידות ל-Attribution Reporting API. נשמח לקבל כל משוב נוסף על ההצעה שלמעלה. |
| דיווח ברמת האירוע | בקשה לקבלת מספר הימים לפני שהדוח נשלח באופן ישיר | טכנולוגיות פרסום כבר יכולות לחשב את הבקשה הזו על סמך המידע שזמין כרגע. לא קיבלנו משוב נוסף על הסביבה העסקית בנוגע לבקשה הזו, אבל נשמח לקבל משוב בנושא. |
source_registration_time |
הוספת source_registration_time לדיווח שיוך ברמת האירוע. |
אנחנו שוקלים את הבקשה הזו, ונשמח לקבל משוב נוסף שיעזור לנו להבין אם השחקנים בסביבה העסקית נעזרים בתכונה הזו. |
| מצב אנונימי | האם הפתרונות למדידת ביצועים יהיו זמינים כשהמשתמש יהיה במצב פרטי? | לא, הפתרונות למדידת ביצועים לא יהיו זמינים כשהמשתמש נמצא במצב פרטי. קובצי cookie של צד שלישי מושבתים כברירת מחדל במצב פרטי. |
| חדרים נקיים מנתונים | האם ממשקי ה-API של Measurement API יתאימו לחדרים נקיים? | חדר נקי לנתונים הוא סביבה שבה נתוני מזהים ספציפיים ממקורות שונים מועלים למסד נתונים כדי להריץ ניתוחים שמבוססים על מיזוג הנתונים הבסיסיים האלה. שתי מסגרות המדידה לממשקי ה-API של ארגז החול לפרטיות הן דוחות ברמת האירוע ודוחות סיכום. דוחות ברמת האירוע אכן מכילים מזהה אירוע (event-ID) שסופק על ידי פרסום דיגיטלי, ואפשר להשתמש בו בחדר נקי לנתונים, אבל הפרטים מצד ההמרה שמשויכים אליו יהיו מוגבלים ויהיו רועשים. אי אפשר להשתמש בדוחות מוצפנים במצטבר ישירות בחדר נקי, אבל אפשר להשתמש בתוצאות הסיכום של שירות הצבירה בתור קלט לניתוחים שמבצעים או כמידע משלים. |
שירות צבירה
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| (מדווח גם ברבעון הרביעי של 2022) עיכובים בדיווח |
מהו העיכוב הצפוי בדיווח? | עדכון לרבעון 1 של שנת 2023: בהמשך למשוב שקיבלנו מהשותפים, שיתפנו הצעות לקיצור העיכוב ולצמצום ההשפעה של העיכוב. טכנולוגיות הפרסום תמכו בשתי ההצעות במהלך השיחות דרך WICG. |
| אין כלל כפילויות | איך מטפלים ב "דוח מצטבר מתעכב" אם כבר עובדו דוחות נצברים, שיש להם אותו מזהה משותף? | שיתפנו הצעה להוסיף עיכוב נוסף בדיווח על מידע משותף בדוחות נצברים, ואת ההגדרה של המזהה המשותף לשירות הצבירה, כדי לטפל באופן חלקי בהשפעה של אובדן העיכוב על API נצבר. נשמח לקבל כל משוב על ההצעה. |
| עיבוד נתונים | בקשה להפעלת תמיכה בהעברות מרובות של נתונים, תוך שמירה על הפרטיות הדיפרנציאלית באמצעות תקציב הפרטיות | אנחנו דנים באפשרות להשתמש בדרך גמישה יותר לניצול תקציב הפרטיות כדי לאפשר את התרחיש לדוגמה, ונשמח לקבל משוב נוסף. |
| (מדווח גם ברבעון השני של 2022) ארגונומית שאילתות | הפעלת שאילתות על צבירה של מפתחות. | עדכון לרבעון 1 של שנת 2023: הבקשה להוספת התכונה עדיין בבדיקה, אבל אין לנו הצעות לשתף בשלב הזה. |
| המגבלות של גרסת המקור לניסיון | חשוב להסביר את ההיקף של שירות הצבירה, למשל, הכלל "ללא כפילויות" שלא מיושם כרגע בגרסת המקור לניסיון. | אנחנו מנסים לעדכן את המסמכים כדי שיהיה ברור מה יהיה זמין בגרסת המקור לעומת GA. |
API לצבירה פרטית
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| תקציב לתרומה לצבירה פרטית | תקציב התרומה של L1 מוגבל מדי. | כל קריאה ל-Private Aggregation API נקראת 'תרומה'. כדי להגן על פרטיות המשתמשים, אנחנו מגבילים את מספר התכנים שמשתמשים מוסיפים. כשמסכמים את כל הערכים הנצברים בכל מפתחות הצבירה, הסכום צריך להיות נמוך מתקציב התרומה. לפי העיצוב הנוכחי, אנחנו מגבילים את התכנים שיועברו למקור מסוים של דוחות בתקופה של כ-24 השעות האחרונות (כחלון לתקופה). זהו תקציב התרומות L1 שצוין במשוב. אנחנו ממליצים למפתחים להתאים את הערכים שהם תורמים לפי הנפח הצפוי (כלומר, לא רק באמצעות ערך של 1). לכן כדאי להשתמש בערך קטן יותר לאירועים הנפוצים כדי למנוע מיצוי של התקציב. אנחנו מעוניינים לקבל ממך משוב על התקציב לתרומה של ה-API לצבירה פרטית, גם בממד המספרי וגם בהיקף. אנחנו שוקלים להעביר את ההיקף ממשאב למקור לאתר לפי אתר, ולהעביר את ההגדרה הקיימת לחלון של עשר דקות עם טווח יומי גדול יותר. |
הגבילו מעקב סמוי
הפחתת מידע בסוכן משתמש/רמזים על הלקוח (Client-Hints) לגבי הסוכן המשתמש
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| שימוש ב-UA-R | מתוך 10,000 האתרים המובילים בבריטניה, רק אחוז אחד מהאתרים שמשתמשים בפרסום פרוגרמטי שולחים רמזים של לקוח HTTP. ספקי DSP שלא הועברו עשויים להשפיע על היכולות למניעת הונאה. | לאחר ניתוח על אותה קבוצת נתונים, גילינו שאם אתה מביא בחשבון את השימוש ב-UA-CH באמצעות תג HTML <meta>, ואת ממשקי ה-API של JavaScript, מספר האתרים שמשתמשים ב-UA-CH גבוה באופן משמעותי מהנתון של 1% שצוין במשוב. על סמך הנתונים האלה ועובדות נוספות, כולל משוב על הסביבה העסקית, אנחנו משוכנעים שנשיק בהדרגה את שלב 6 של ההפחתה ב-UA בהתאם לציר הזמן שפורסם, ובמקביל נמשיך לעדכן את ה-CMA. שמנו לב שאתרים השיגו זמן של כמעט שנתיים כדי להתכונן למעבר, ותקופת ניסיון להוצאה משימוש עדיין זמינה לאתרים שמרגישים שהם לא מוכנים. |
| רמזים לגורמי צורה נוספים | בקשה מ-UA-CH לספק גורמי צורה נוספים כמו טלוויזיה, VR | אנחנו מקבלים בברכה את ההצעה הזו ופועלים לשלב אותה בעיצוב. נשמח לקבל משוב נוסף. |
| בדיקות אוטומטיות | בקשה לפתרון באג UA-CH ב-Chrome ללא דפדפן גרפי לפני שליחת שלב 6 של ה-UAR | הבאג הרלוונטי תוקן. |
| תמיכה ב-UA-CH ב-iOS | באתר שמסתמך על מידע מפורט של UA לצורך הצגת מודעות, מצוין ש-Chrome ב-iOS לא נתמך. | עבור דפדפנים שאינם Safari iOS (כולל Chrome ב-iOS), יהיה צורך להוסיף תמיכה בפרויקט WebKit ב-UA-CH כדי שניתן יהיה להפעיל אותם (כי הם שולטים בסטאק הרשת). |
הגנה על IP (לשעבר Gnatcatcher)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| (מדווחים גם ברבעון 4) תרחישים לדוגמה של מיקום גיאוגרפי | יכול להיות שהגנה על קניין רוחני תמנע את הפעולה בעתיד, כמו התאמה אישית של תוכן לפי מיקום גיאוגרפי. | התגובה שלנו לא השתנתה מהרבעון הרביעי של 2022: "אנחנו עובדים עם בעלי עניין כדי לוודא ש-Chrome ימשיך לתמוך בתרחישים לגיטימיים לשימוש בכתובות IP. אנחנו מבקשים משוב מהסביבה העסקית לגבי רמת הפירוט של המיקום הגיאוגרפי של כתובת ה-IP." |
| תאימות לדרישות תקינה | אם באזור מסוים יש פחות ממיליון, הסף הנוכחי להגנה על IP ימנע מאתרים להשתמש בכתובות IP לצורך תאימות לתקנות. | אנחנו עובדים עם בעלי עניין כדי להבטיח ש-Chrome ימשיך לתמוך בתרחישים לגיטימיים לשימוש בכתובות IP. אנחנו מעוניינים לקבל משוב מהסביבה העסקית לגבי תאימות לתקנות בנושא הגנה על IP. |
| צמצום מקרי הניצול לרעה | צדדים יכולים לעקוף את ההגנה על ה-IP על ידי שיתוף של כתובות IP ללא אנונימיזציה עם אחרים. | אנחנו מודעים לסיכון שההצעה הנוכחית להגנה על קניין רוחני לא תמנע מבחינה טכנית לשתף כתובות IP ללא אנונימיזציה עם אחרים. אנחנו פועלים כדי לסייע בצמצום סיכונים כדי למנוע את הסיכון לניצול לרעה. בזמן שאנחנו חוזרים על ההצעה, אנחנו מעודדים יותר משוב ודיון. באופן ספציפי, נשמח לשמוע על מקרי שימוש שבהם הצדדים סבורים שעליהם לשתף כתובות IP ללא אנונימיזציה עם צדדים אחרים. |
| חסימת רשת | הצדדים יכולים לעקוף חסימת רשתות באמצעות שרתי proxy להגנה על כתובת IP. | הישות שמבצעת את החסימה תצטרך להשבית את ההגנה על ה-IP בתרחיש הזה. הגבנו לבעיה ונשמח לקבל משוב נוסף. |
| רשימות חסומות של כתובות IP שהושפעו מההצעה להגנה על כתובת IP | הרבה חברות פרסום דיגיטלי משתמשות ברשימת חסימה בסיסית של כתובות IP, למשל רשימת ה-IP של TAG במרכז הנתונים, כדי למנוע הגשת הצעות מחיר על מלאי שטחי פרסום שיש סיכוי גבוה שהוא מקורו בתרמית (או לפחות שלא מתאים למונטיזציה). במקרה שטכנולוגיית המודעות היא גם כלי מעקב ועשויה להיות כפופה להצעת ההגנה על ה-IP, החברה עלולה לאבד את היכולת לבצע בדיקה בסיסית מול מודעות לפני רכישת מלאי שטחי הפרסום. | אנחנו מעודדים משוב נוסף ודיונים בנושא ההצעה להגנה על כתובת IP לגבי בעיות ופתרונות אפשריים. אפשרות אחת היא להחיל רשימות דומות כאלה על ההגנה על ה-IP, כך שאנחנו לא מעבירים לקוחות לשרת proxy שמקורם בכתובות IP שסומנו בעבר. |
חיזוק גבולות הפרטיות בין אתרים
דומיינים של צד ראשון
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| (דווחה גם ברבעון 4) מגבלת דומיינים | בקשה להרחבת מספר הדומיינים המשויכים | התגובה שלנו לא השתנתה מהרבעון הרביעי של 2022: "הבהרנו בשיחות של WICG ש-Chrome מחויב לספק פתרון שימושי שמתחשב גם באינטרסים של המשתמשים בפרטיות. לכן, אנחנו מעריכים מאוד משוב מהקהילה על תרחישים מסוימים שעשויים להיות מושפעים מהגבלת הדומיין, כדי שהצוות יוכל למצוא דרכים לטפל בתרחישים האלה תוך הגנה על פרטיות המשתמשים." |
| שליחת FPS חלופי | הצעה לדרך חלופית לשליחת רשימות גלובליות ל-FPS | בשלב זה אנחנו מתכוננים לשלוח קבוצות של צד ראשון (FPS) ב-Chrome, והקמנו מאגר מרכזי ב-GitHub שמאפשר לשלוח בקשות של קבוצות. אנחנו מקווים ש-FPS ימלא את הפער בפתרונות הקיימים של פלטפורמת האינטרנט, כהכנה להוצאה משימוש של קובצי cookie של צד שלישי, ולכן אנחנו מצפים ללמוד מהם איך מפתחי אתרים מנצלים את FPS. ככל שרשימת הקבוצות מתפתחת עם הזמן, והסביבה העסקית מתאימה את עצמה לעולם של קובצי cookie של צדדים שלישיים, אנחנו יכולים גם להבשיל את התהליך עד לנקודה שבה נוכל לשקול תוכניות מבוזרות חלופיות כמו זו שמוצעת. במסגרת התהליך הנוכחי, אנחנו מצפים להגדיר משך חיים מוגדר, שיאפשר לנו לפתח את תהליך קליטת הנתונים עם הזמן. נוכל לחזור לרעיון הזה אחרי שתהליך ההגשה יתבגר. |
| ניהול המאגר | להפעיל ניהול של מאגר שליחת ה-FPS בקהילה כדי למנוע ניצול לרעה. גורמים זדוניים יכולים בקלות להציף את התהליך של משתמשים במקורות של מבערים כדי להציע קבוצות, וכמות גדולה מאוד של בקשות עלולה להשפיע על הפעולות של הצעות להגדרות אמיתיות. | אנחנו משתדלים שהבדיקות יהיו אובייקטיביות ככל האפשר, באמצעות בדיקות של אימות טכני. לדעתנו, זו הגישה המתאימה ביותר לתהליך השליחה. בהתאם למטרה הזו, אנחנו גם שואפים להבטיח שהתהליך עמיד בפני ספאם או שליחה של מבערים. |
| קבוצות משנה משויכות | האם טכנולוגיית FPS תוכל לתמוך בתרחישים לדוגמה של זרימה של ספקים/SaaS דרך קבוצות משנה משויכות? | תהליכי ה-SaaS של הספק מצד שלישי או תהליכי ה-SaaS הם לא תרחיש לדוגמה שנמצא כרגע במסגרת השימוש בקבוצות של צד ראשון. נשמח לקבל משוב נוסף על השימוש בקובצי cookie באתרים בתרחישים כאלה. |
| שילוב FPS + CHIPS | שליחת בקשה לשילוב FPS + CHIPS כדי לתמוך בתרחישים לדוגמה, כמו A/B Testing | אנחנו דנים בתרחיש לדוגמה הזה, וגם שוקלים לדון בכך לעומק בשיחה עם WICG, ונשמח לקבל משוב נוסף. |
| GDPR | הצעה לקבוצת משנה חדשה של FPS לצורך בניית מודל בהתאם למושגים של GDPR | שוחחנו באופן פנימי על ההצעה הזו ושקלנו אותה ביחס למשוב אחר שקיבלנו, וכן ביחס ליעדים שקבענו לשמירה על הפרטיות. סיפקנו תשובה שהסברנו למה לא נפעל לפי ההצעה הזו בשלב הזה. |
| זיכרון | השינוי הצפוי בגודל הזיכרון בדפדפן כשכוללת את רשימת ה-FPS | יש תקדים שבהם דפדפנים מאחסנים רשימות כאלה עם השפעה מינימלית על הזיכרון, כמו רשימת ההגנה מפני ניתוק המעקב. למרות שרשימת הקבוצות של צד ראשון תועתק באופן מקומי לכל לקוח Chrome, אנחנו נמשיך לעקוב אחרי גודל הקובץ ואנחנו בטוחים שנוכל לבצע אופטימיזציה של טביעת הרגל של הזיכרון. |
ממשק API של Fenced Frames
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| הגבלות Fenced Frames | בהירות לגבי המגבלות שהוטלו על ידי Fenced Frames | בחודש מרץ עדכנו את ההסבר על Fenced Frames שמספק מידע על היכולות שלו, ונשמח לקבל כל משוב נוסף. |
| הרחבת פרטי הגישה | בקשה להרחבת הגישה למידע לגבי מסגרות סמוכות | אנחנו רוצים להבין למה זו הדרישה של הסביבה העסקית, ונשמח לקבל כל משוב נוסף. |
| Fenced Frames ו-iframes | שאלות לגבי שוויון התכונות בין Fenced Frames ו-iframes | כל ממשקי ה-API והדוחות הזמינים של ארגז החול לפרטיות יהיו זמינים ל-iframes ול-FencedFrames באותו אופן. |
| שינוי הגודל של מסגרות Fenced Frame | הגבלת שינויים בגודל הפריים משפיעה על תרחישים מסוימים לדוגמה. | נשמח לקבל מידע נוסף על סוגי התרחישים לדוגמה שמושפעים מההגבלה, ונשמח לקבל משוב נוסף. |
ממשק API לאחסון משותף
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| worklet של צד שלישי | האם צדדים שלישיים יכולים לכתוב לאחסון משותף, בחלוקה לפי מקור? או לקרוא לרכיבי עבודה אחרים למדידה של צד שלישי? | המקור של הקשר הגלישה שבו הקוד מבוצע קובע שלמי האחסון המשותף ייכתבו הנתונים. כשמוסיפים קוד של צד שלישי לדף, ניתן להטמיע אותו כ-iframe עם הקשר גלישה משלו, וכך הקוד של הצד השלישי יכול לכתוב למקור משלו. ניתן גם להטמיע את הקוד של הצד השלישי כסקריפט במקום כ-iframe, שאינו משנה את הקשר הגלישה, והצד השלישי יכול לכתוב באחסון המשותף של המטמיע. שימו לב שרק הבעלים של האחסון המשותף יכול לקרוא ממנו. |
| ביטול כפילויות | לא ניתן יהיה לבטל כפילויות באינטראקציות מחוץ לסביבה העסקית של Chrome. | נפח האחסון המשותף נועד לספק משתני פלט של היקף החשיפה למשתמשים ייחודיים שמבוססים על דפדפן Chrome ב-Chrome. אנחנו מעוניינים לעבוד עם טכנולוגיות של מודעות כדי להבין איך ניתן להשתמש בפלט הזה כחלק מהמודלים הרחבים יותר להגדלת פוטנציאל החשיפה. אנחנו מבינים שהפלטים עצמם מביאים בחשבון רק חלק מהאינטראקציות, ומעוניינים לעבוד עם טכנולוגיות של מודעות כדי לבחון מתודולוגיות נוספות של בניית מודלים שניתן להוסיף להן שכבת-על. |
| חלון מבט לאחור של המרות | בקשה להצגת חלון מבט לאחור של שיעור המרה, כדי לראות שינויים בהמרות לאורך זמן | ניתן להטמיע זאת על ידי עיבוד של נתיבי ההמרות השונים בצד הלקוח באמצעות אחסון משותף, שמאפשר גמישות נוספת בניתוח נתונים מתקדם באחסון דפדפן מאובטח ללא מחיצות. |
| חלון תפוגת תוקף של פריט | בקשה להאריך את חלון התפוגה ל-90 יום | מדיניות שמירת הנתונים עודכנה בנובמבר 2022, והיא קובעת שכל מפתח נמחק אחרי 30 ימים ממועד הכתיבה האחרונה. נשמח לקבל משוב נוסף כדי להבין אם המדיניות החדשה תתרום לסביבה העסקית. |
| רוטציה של קריאייטיב | תרחישי השימוש בסבב קריאייטיב לא משקפים את הפעולות בפועל לאחר המכירה הפומבית. | אנחנו מעוניינים לשמוע מחברות נוספות של טכנולוגיות פרסום בצד הרכישה, כדי לדעת אם התיעוד של סבב נכסי הקריאייטיב מדויק או לא. |
צ'יפים
לא התקבל משוב ברבעון הזה.
FedCM
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| נקודת קצה לטענת נכונות של זהות | אישור מפורש לבקשות שרירותיות לנקודת הקצה של טענת הנכוֹנוּת של הזהות. | שיתפנו פעולה עם Mozilla בבקשת הבקשה הזו כדי להגביל את היכולת של אתרים לשלוח בקשות עם פרטי כניסה ממקורות שונים בשקט, בלי לגרום להפרעה למשתמשים. נמשיך לבדוק משובים אחרים ולטפל בהם גם. |
| אכלוס מראש של הזהות | האם אפשר להשתמש ב-FedCM כדי לאכלס מראש טופסי כניסה עם ספק זהויות מרשימת FedCM? | בתרחיש לדוגמה הזה, זה עלול להוביל לדליפת מידע, כשאתר שלא הייתה באינטראקציה עם המשתמש יכול להריץ שאילתות על ה-IdP האחרון שבו השתמש המשתמש. אנחנו דנים בנושא בהרחבה, ונשמח לקבל משוב נוסף. |
| בחירת חשבון לפי הקשר | הצעה להוסיף אותות הקשריים בממשק המשתמש של בחירת החשבון | אנחנו שוקלים את ההצעה ומברכים על דיונים נוספים. |
נלחמים בספאם ובהונאות
Private State Token API (וממשקי API אחרים)
| נושא משוב | סיכום | התגובה של Chrome |
|---|---|---|
| סקר בנושא יכולות איסוף | בתחילת הרבעון הראשון, סיימנו לאסוף את תוצאות הסקר שלנו, שבהן נדרשות יכולות לתרחישים שונים לדוגמה למניעת הונאה, ושיתפנו אותן באופן גלוי לכולם (דקות, תוצאות) | אנחנו מתכננים לשלב את המשוב הזה בזמן שאנחנו מפתחים הצעות ואבות טיפוס חדשים לממשקי API שמיועדים במיוחד לשמירה על הפרטיות ומיועדים ליכולות נגד הונאה. אנחנו צופים שאנחנו נותנים עדיפות לפיתוח במקרים שבהם יש צורך מספיק, ויש טכנולוגיה קיימת שאפשר להתבסס עליה כדי להציג את היכולת באינטרנט תוך שמירה על פרטיות המשתמשים. לדוגמה, תקינות המכשיר והאתחול קיבלה דירוג גבוה, ולפלטפורמות רבות יש ממשקי API קיימים שחולקים באופן מאובטח הערכה של תקינות המכשיר, כך שמומלץ לחקור אותו בתוך קבוצות הקהילה. |
| PST כוונת לשלוח משוב | כחלק מכוונתנו לשלוח את המוצרים, קיבלנו חשש בנוגע להחלטה שלנו מכיוון שאנחנו משתמשים בגרסה ישנה יותר של Privacy Pass. בנוסף, קיבלנו משוב על כך שהמפרט לא היה ברור בקטעים מסוימים, וצריך לשפר אותו כדי לשמור על תאימות לדפדפנים. | אנחנו מתכננים ליישם הרבה מהשינויים במפרט לפני המשלוח ל-Google Analytics, וגם כמה שינויים ב-API. המשוב התקבל בסוף רבעון 1, ולכן בהמשך אנחנו פונים לבעיות ב-github עם פרטים ספציפיים ועדכון לתוכנית ההשקה שלנו (בתהליך, נכון לפרסום דוח המשוב הזה). עבור השינויים המשמעותיים יותר ב-API, אנחנו מוכנים לשקול אותם, אבל נראה לנו שהדרך הטובה ביותר היא להמשיך בהשקה של זמינות לכלל המשתמשים (GA) ולקבל משוב מעשי ממפתחים נוספים. אנחנו מקווים להמשיך את הדיון הזה ולפתח את התקינה של הדפדפן. אם יימצא תקן חדש, אנחנו שוקלים לאמץ ולפתח תוכנית כדי לעבור אליו בצורה קפדנית. |