דוח רבעוני לרבעון הראשון של שנת 2023 שמסכם את המשוב שקיבלנו מהסביבה העסקית לגבי ההצעות של ארגז החול לפרטיות ואת התגובה של Chrome.
כחלק מההתחייבויות שלה ל-CMA, Google הסכימה לפרסם דוחות רבעוניים על תהליך המעורבות של בעלי העניין בהצעות שלה לארגז החול לפרטיות (ראו פיסקאות 12 ו-17(ג)(2) בהתחייבויות). דוחות הסיכום האלה של המשוב על ארגז החול לפרטיות נוצרים על ידי צבירת המשוב ש-Chrome מקבל מהמקורות השונים שמפורטים בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין בכתובת privacysandbox.com, פגישות עם בעלי עניין בתעשייה ופורומים של תקני אינטרנט. אנחנו ב-Chrome מקבלים בברכה את המשוב שאנחנו מקבלים מהסביבה העסקית, ומחפשים דרכים לשלב את הלקחים האלה בהחלטות העיצוב שלנו.
נושאי המשוב מדורגים לפי שכיחות לכל ממשק API. כדי לעשות זאת, אנחנו אוספים את כמות המשוב שקיבל צוות Chrome בנושא מסוים וממיינים אותו בסדר יורד לפי כמות. כדי לזהות את הנושאים הנפוצים של המשוב, בדקנו את נושאי הדיון בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שהופיעו בצוותים הפנימיים של Google ובטפסים ציבוריים.
באופן ספציפי יותר, נבדקו פרוטוקולים של פגישות של גופי תקני האינטרנט, ועבור משוב ישיר, נלקחו בחשבון הרשומות של Google לגבי פגישות אישיות עם בעלי עניין, אימיילים שהתקבלו על ידי מהנדסים ספציפיים, רשימת התפוצה של API וטופס המשוב הציבורי. לאחר מכן, Google תיאמה בין הצוותים המעורבים בפעילויות השונות של יצירת קשרים כדי לקבוע את השכיחות היחסית של הנושאים שצצו בקשר לכל ממשק API.
ההסברים על התשובות של Chrome למשוב נוצרו על סמך שאלות נפוצות שפורסמו, תשובות בפועל שניתנו לבעיות שהעלו בעלי עניין וקביעת עמדה ספציפית למטרות הדיווח הציבורי הזה. בהתאם למוקדי הפיתוח והבדיקה הנוכחיים, קיבלנו שאלות ומשוב במיוחד לגבי Topics API, FLEDGE API ו-Attribution Reporting API.
יכול להיות שעדיין לא תהיה תגובה של Chrome למשוב שקיבלתם אחרי סיום תקופת הדיווח הנוכחית.
מילון ראשי תיבות
- CHIPS
- קובצי Cookie עם חלוקה עצמאית למחיצות
- DSP
- פלטפורמה בצד הביקוש
- FedCM
- Federated Credential Management
- FPS
- קבוצות מאינטראקציה ישירה (First-Party Sets)
- IAB
- הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)
- IDP
- ספק זהויות
- IETF
- ארגון תקינה בנושאי האינטרנט (IETF)
- קניין רוחני (IP)
- כתובת פרוטוקול אינטרנט
- openRTB
- בידינג בזמן אמת
- הארכה
- גרסת מקור לניסיון
- PatCG
- קבוצת הקהילה של טכנולוגיית פרסום פרטית
- RP
- צד נסמך
- SSP
- פלטפורמה לספקים
- TEE
- סביבת מחשוב אמינה
- UA
- מחרוזת של סוכן משתמש
- UA-CH
- רמזים על הלקוח (Client Hints) לגבי סוכן משתמש
- W3C
- World Wide Web Consortium
- WIPB
- עיוורון מכוון של כתובות IP
משוב כללי, ללא API או טכנולוגיה ספציפיים
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| בדיקה ותקופת ניסיון | הרלוונטיות של הבדיקה לצורך מתן מידע ל-CMA אם ממשקי ה-API של ארגז החול לפרטיות לא יושלמו עד לתחילת הבדיקה | הפיתוח של ממשקי ה-API של ארגז החול לפרטיות מתקדם בקצב מהיר.
הם כבר זמינים לבדיקה בגרסת Origin Trial, והם יהיו זמינים לכלל התנועה בקיץ הזה. בנוסף, הבהרנו את לוחות הזמנים של תכונות מסוימות (כמו דיווח ברמת האירוע ב-FLEDGE, עיבוד FLEDGE עם מסגרות iframe) שלא יושפעו לפני 2026. אנחנו ממליצים לגורמים בסביבה העסקית לבדוק את ממשקי ה-API ולספק משוב ל-CMA על סמך מה שבדיקות הקודמות מצביעות על כך שהם יعتمدו עליו אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. כך תוכלו לעזור להם להעריך את ההשפעה הצפויה של ההוצאה משימוש של קובצי cookie של צד שלישי. |
| פקדי משתמש | הנחיות ברורות לסביבה העסקית לגבי ההשלכות של אמצעי הבקרה של המשתמשים על ממשקי ה-API של ארגז החול לפרטיות | אנחנו לא יכולים לספק ייעוץ משפטי לגבי השימושים שיכולים להתבצע על ידי משתמשים ששולטים בסביבה העסקית. במקביל, אנחנו מבצעים ב-Chrome ניסויים בהצגת אמצעי בקרה משופרים של ארגז החול לפרטיות ('פרטיות משופרת במודעות') לאחוז קטן מאוד של משתמשים, כחלק מהמאמצים המתמשכים שלנו לשפר את הטכנולוגיות של ארגז החול לפרטיות. העדכונים כוללים שפה ותצוגות מפורטות יותר ומועילות יותר. אחרי שמערכת Chrome תערוך הערכה של השיפורים האלה ותחליט אם להרחיב אותם לקהל גדול יותר, היא תוכל לשתף מידע נוסף עם הסביבה העסקית. |
| דליפת נתונים | סיכון לדליפה של נתונים מאינטראקציה ישירה (First-Party) ל-Google ולצדדים אחרים במקרה שהדפדפן נפרץ | במאמר ההסבר שלנו על FLEDGE מוסבר בבירור שנתונים של חברת טכנולוגיית פרסום אחת משותפים רק עם אותה חברת טכנולוגיית פרסום (עם ה-worklets או עם השרתים המהימנים שלה), או כשחברת טכנולוגיית הפרסום משתפת אותם באופן מפורש (למשל, קונה מציג למוכרים את כתובת ה-URL של המודעה שהוא רוצה להציג). היוצא מן הכלל הוא שבדיקה של אנונימיות מסוג k חייבת להתבצע על ידי שרת מרכזי גלובלי, ואנחנו ממשיכים להקדיש משאבים משמעותיים לתחום הזה. במאמר בנושא פרטיות מוסבר בפירוט איך אנחנו מתייחסים לפרטיות. בנוסף, אנחנו פתוחים לספק פרטים נוספים על אופן הפעולה של אמצעי ההגנה של טכנולוגיית הפרסום שנעשה בהם שימוש בתכנון השרת עם אנונימיות של k. |
| פורום נוסף לדיון | בקשה ליצירת פורום נוסף ב-W3C לגורמים לא טכניים בסביבה העסקית, כדי לשתף משוב | טופס המשוב של Privacy Sandbox מתאים להערות כלליות ספציפיות, טכניות ולא טכניות. Improving Web Advertising Business Group הוא פורום לדיון באמצעות שיחות שבועיות ומאגר ב-GitHub. בדף משוב של ארגז החול לפרטיות מוסבר על מנגנונים אחרים לשליחת משוב ולדיון. אנחנו ממשיכים גם לקיים אירועים ב-Chrome, כמו שעות פעילות פתוחות לציבור, כדי לענות על שאלות ולשתף תוכן. בנוסף, ברבעון האחרון Chrome אירח או השתתף ביותר מתריסר אירועים בתחום. |
| הבהרה לגבי ציר הזמן | הבהרה לגבי התאריך המדויק של השקת המוצר לכלל המשתמשים (GA) ברבעון השלישי של שנת 2023 | בהתאם ללוח הזמנים שפורסם ב- PrivacySandbox.com, ההשקה של ארגז החול לפרטיות בגרסת 'זמין לכולם' תתחיל עם השקת גרסת Chrome 115. |
| reCAPTCHA | ההשפעה של ממשקי ה-API של ארגז החול על תרחיש לדוגמה של זיהוי ספאם ב-reCATPCHA | אנחנו מקבלים משוב מ-reCAPTCHA מדי פעם כדי לוודא שהצעות ל-Privacy Sandbox לא משפיעות באופן משמעותי על הבטיחות באינטרנט או על הונאות. הם מפתחים תוכנית משלהם כדי להתכונן להוצאה משימוש של קובצי Cookie של צדדים שלישיים ולהתאים את עצמם אליה, ולכן הכי טוב לפנות אליהם בנושא הזה. |
| תוספים ל-Chrome | האם טכנולוגיות של ארגז החול לפרטיות, כמו אמצעי נגד מעקב סמוי (ACT), יחולו על תוספים ל-Chrome? | לא הודענו אם ה-ACT יחול על תוספים של Chrome. עם זאת, אם טכנולוגיה אוספת מידע על משתמש באופן חשאי, זה לא עומד בעקרונות הפרטיות שלנו. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| בדיקת עיצוב של תגים | TAG פרסם בדיקה מוקדמת של העיצוב של Topics. | אנחנו עדיין מחויבים ל-Topics, ועדכנו את המחויבות שלנו בדף העדכונים האחרונים ובגיליון הזה. השבנו, נקודה אחר נקודה, לבדיקה של TAG, ושיתפנו את החזון שלנו ברמה גבוהה יותר כאן. Topics API יישאר חלק מהאוסף של ממשקי ה-API שסביבת הפרסום צריכה לבדוק במהלך 2023. אנחנו מקווים שהמשוב מהבדיקה והניסיון של המטמיעים יעזרו לנו בעתיד לפתח סטנדרטים בתחום הזה שתואמים לדפדפנים שונים. אנחנו מצפים להמשיך את המעורבות שלנו בסביבה העסקית כדי להקל על המעבר האפשרי, שבו Topics API יכול להיות תקן מוסכם עם תאימות לדפדפנים שונים. |
| הגישה לנושאים | תמיכה בגישה הפתוחה של Chrome לפיתוח Topics API | אנחנו מודים לך על המשוב ומצפים להמשיך לעבוד עם קבוצת התעשייה כדי לפתח את Topics API כך שיניב ערך לסביבה העסקית הכוללת. |
| (דווח גם ברבעון השלישי של 2022) הטקסונומיה של הנושאים לא מספיק מפורטת |
הטקסונומיה של הנושאים הרחבים לא כוללת נושאים מפורטים יותר, כולל נושאים ספציפיים לאזור. | עדכון לרבעון הראשון: אנחנו ממשיכים לנסות ולשפר את הטקסונומיה, ובמהלך הרבעון השני נודיע על טקסונומיה מעודכנת ל-Topics API. כדי ליצור את הטקסונומיה החדשה הזו, עבדנו בשיתוף פעולה הדוק עם חברות מכל רחבי הסביבה העסקית. אנחנו מחפשים משוב פעיל לגבי הטקסונומיה שתהיה הכי שימושית לסביבה העסקית. כשבודקים אם להרחיב את מספר הנושאים או לכלול נושאים מפורטים יותר, יש כמה שיקולים, כולל 1) השלכות פוטנציאליות על הפרטיות (ככל שיש יותר נושאים, כך יש סיכון גבוה יותר ליצירת טביעת אצבע דיגיטלית) ו-2) היכולת לאחזר נושאים שנצפו בעבר (לדוגמה, ככל שיש יותר נושאים, כך יש פחות סיכוי שפלטפורמת טכנולוגיית הפרסום תראה את הנושא שנבחר בעבר). |
| (הדיווח על כך יתבצע גם ברבעון הרביעי של 2022) השפעה על אותות מאינטראקציה ישירה (First-Party) |
אות Topics עשוי להיות בעל ערך רב, וכתוצאה מכך הוא גורם לירידה בערך של אותות אחרים שמבוססים על תחומי עניין ומגיעים ממקור ראשון. | אנחנו מאמינים שפרסום מבוסס-אינטרסים הוא תרחיש לדוגמה חשוב באינטרנט, ו-Topics נועד לתמוך בתרחיש הזה. אנחנו מבינים שלחלק מבעלי התוכן הדיגיטלי הגדולים יש חשש ש-Topics ישפיע לרעה על האסטרטגיות שלהם לשימוש בנתונים מאינטראקציה ישירה. אנחנו מצפים לבדיקת הסביבה העסקית, שתספק תובנות לגבי ההשפעה של Topics על בעלי תוכן דיגיטלי. |
| תרחישים לדוגמה לשימוש ב'נושאים' שלא קשורים ל-Google Ads | שימוש בנושאים למטרות אחרות מלבד הצגת מודעות לפי תחומי עניין | התכונה Topics נועדה לטפל בתרחיש לדוגמה של פרסום מבוסס-תחומי עניין, שלדעתנו הוא תרחיש קריטי לשימוש באינטרנט הפתוח והחופשי. אנחנו מחפשים כרגע משוב לגבי תרחישים לדוגמה אחרים, ומעריכים את האפשרויות. |
| סטטוס ברירת המחדל של ההסכמה | ההשפעה של חקיקה אזורית על הגדרת ברירת המחדל של הסכמה לשימוש בנושאים | אין לנו אפשרות להגיב על חוות דעת משפטיות. |
| (דיווחנו על כך גם ברבעון השלישי של 2022) אתרים שסווגו בטעות |
טירגוט מודעות כשהנושאים מסווגים באופן שגוי באתר נתון | עדכון לרבעון הראשון: ברבעון השני נכריז על סיווג מעודכן של Topics API, ונשמח לקבל מכם משוב עליו. בתגובה למשוב הנוכחי, האתרים מסווגים באמצעות שילוב של רשימת שינוי ידני שנוצרה על ידי בני אדם, שמכילה את האתרים הפופולריים ביותר, ושל מודל למידת מכונה במכשיר. אנחנו ב-Chrome ממשיכים לבדוק אפשרויות לאתרים שיעזרו לנו לסווג את התוכן לפי Topics. צריך לשקול את כל השיפורים בתועלת מול הסיכונים לפרטיות ולשימוש לרעה. לדוגמה, חלק מהסיכונים כוללים: אתרים שמשתמשים בתיוג עצמי כשיטה לקידוד משמעויות שונות (שעשויות להיות רגישות) בנושאים, אתרים שמציגים מצג שווא של הנושאים שלהם למטרות רווח, אתרים שמתקפים נושאים כדי לפגוע בתועלת שלהם לאחרים (לדוגמה, ספאם בנושאים של המשתמשים עם רעש חסר משמעות). הציבור יכול לבדוק את הרכיבים האלה, באמצעות הכלים שזמינים דרך chrome://topics-internals או דרך colab הזה. אנחנו צופים שהסיווג ישתפר עם הזמן באמצעות בדיקות, ואנחנו מקבלים בברכה משוב עם דוגמאות לאתרים שעשויים להיות מסווגים באופן שגוי. |
| מסווג נושאים | בקשה להחזרת מידע נוסף עם הסיבות כשהערך 'No Topics' מוחזר למבצע הקריאה החוזרת למטרות ניפוי באגים | אנחנו מבינים ומעריכים את העובדה שכלי ניפוי באגים עוזרים למפתחים כשהם משלבים את Topics API במערכות שלהם. עם זאת, אם נחשוף מידע נוסף (למשל, הסיבה לכך שלא הוחזרו נושאים), יכול להיות שנשתף בטעות מידע שמאפשר לצדדים לחשוף פרטים נוספים (לדוגמה, אם משתמש נמצא במצב פרטי, השבית את ה-API וכו') מעבר למה שאנחנו מתכוונים לחשוף, וכך נזיק לפרטיות המשתמשים. אנחנו לא מתכננים לספק כלים נוספים לניפוי באגים בשלב הזה, אבל נשמח לקבל משוב לגבי כלים שיכולים להיות שימושיים. |
| אחזור מידע פרטי (PIR) | בקשה להטמעת Private Information Retrieval ב-Topics API | בדקנו בעבר את השימוש ב-PIR ושיתפנו את הפשרות האלה כאן. |
| מקור הצעות מחיר | האם 'נושאים' יוצגו בנפרד מקהלים שהוגדרו על ידי המוכר בזרם ההצעות? | Topics API היא הצעה לארגז החול לפרטיות שפותחה על ידי Chrome, והיא שונה מהצעה של IAB Tech Lab בנושא קהלים שהוגדרו על ידי מוכרים. אנחנו מצפים שהם יוצגו בנפרד בתוך מקור הבידינג. איך Topics יוצגו בבקשות בידינג ב-OpenRTB |
Protected Audience API (לשעבר FLEDGE)
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| זמינות התכונות ב-FLEDGE | הבהרה לגבי לוחות הזמנים לבדיקה ולהטמעה של תכונות FLEDGE, כמו אכיפת מסגרות מוקפות, אנונימיות מסוג K וכו'. | שיתפנו את הסטטוס של תכונות FLEDGE ברמות שונות, וגם את התאריכים שבהם הן יהיו נתמכות. אנחנו מקבלים בברכה משוב נוסף על ההכרזה הזו, בזמן שאנחנו ממשיכים לפתח את FLEDGE. |
| הגבלות על עיבוד מוצרים | בקשה להקלה על ההגבלות על מודעות המורכבות מכמה חלקים לגבי פריימים מגודרים של FLEDGE | כפי שהודענו בפברואר, השימוש ב-Fenced Frames יישאר אופציונלי לפחות עד שנת 2026, וההתנהגות של iframes תהיה נתמכת על ידי urn-iframes. נשמח לדון בנושא הזה בהרחבה. |
| בעיות שקשורות למדרגיות | ביצועי FLEDGE ככל שהשימוש גדל | אנחנו פועלים כדי לקבל משוב נוסף ולהבין את ההקשר כדי שנוכל להציע פתרונות פרקטיים. השלב הראשון היה להפריד את המשוב לשתי קטגוריות, וזה מה שעשינו:
|
| (דיווחנו על כך גם ברבעון השלישי של 2022) חשיפה של לוגיקת הבידינג |
חשש שלוגיקה של בידינג ב-DSP תהיה חשופה ב-JavaScript | עדכון לרבעון הראשון: שיתפנו הצעה שתמנע מיריבים לבקש נתונים מהשרת באופן ניסיוני (Force Browsing). אנחנו מזמינים את הגורמים בסביבה העסקית לשתף את המשוב שלהם או את התמיכה שלהם בהצעה. |
| קשיים בבדיקות | היכולת של פלטפורמות DSP קטנות יותר לבדוק את FLEDGE בצורה נכונה, ולצמצם את הסיכון שלפיו מפרסמים יתעניינו רק בבדיקה עם פלטפורמות DSP גדולות יותר | אנחנו מחויבים לעבוד עם פלטפורמות DSP קטנות יותר, וממליצים מאוד להרחיב את הבדיקות בקרב פלטפורמות DSP ומפרסמים בכל הגדלים לקראת ההשקה הרשמית של FLEDGE. נשמח לשמוע איך נוכל לעזור להם לבדוק את FLEDGE עם גורמים אחרים בסביבה העסקית, ונשמח לקבל רעיונות ומאמצים בתעשייה כדי לעודד מפרסמים לבדוק את FLEDGE בפלטפורמות DSP קטנות יותר. |
| רימרקטינג דינמי | האם עדיין תהיה אפשרות להשתמש ברימרקטינג דינמי באמצעות FLEDGE אחרי הוצאת קובצי ה-cookie של צד שלישי משימוש? | אנחנו שוקלים תגובה לשאלה הזו, ומזמינים את הגורמים בסביבה העסקית לשתף תובנות נוספות לגבי האופן שבו הם מתכוונים להשתמש ברימרקטינג דינמי. |
| הונאה/ניצול לרעה | איך הסביבה העסקית יכולה לצמצם את הסיכונים ולמנוע מגורמים זדוניים או מקונים להציג את עצמם כקהל רצוי? | אנחנו מצפים להמשיך את הקשר עם הגורמים בסביבה העסקית בנושאי הונאה ושימוש לרעה, ונשמח לקבל משוב נוסף בנושא הזה. |
| העדפות משתמש | התהליך לשמירת העדפות המשתמש ולהשתמש בהן בבחירת מודעות | במודעות ספציפיות, חברת טכנולוגיית הפרסום הרלוונטית היא הגורם שהכי מתאים להציע אמצעי בקרה על נכסי הקריאייטיב שיוצגו או על האופן שבו הם נבחרים. |
| הצעה לבדיקות כמותיות | כדי שהבדיקה הכמותית תהיה הוגנת, האם כדאי לבצע את הבדיקה על תנועה ללא קובצי cookie של צד שלישי או עם פלטפורמות SSP שמשתמשות רק ב-FLEDGE? איך אפשר למנוע את ערבוב האותות מקובצי cookie של צד שלישי? | אנחנו מוקירים את המשוב הזה ועובדים בשיתוף עם ה-CMA כדי לתכנן ניסויים שיספקו תמונה מהימנה של ההשפעה של ההוצאה משימוש של קובצי Cookie של צד שלישי וההכנסה של ההצעות של ארגז החול לפרטיות על הסביבה העסקית. מומלץ לשלוח משוב נוסף על ההצעה של CMA לבדיקות כמותיות ישירות ל-CMA. |
| מסמכי תיעוד ברורים יותר | בקשה למסמכים ברורים יותר בנושא הגדרת מכרזים | אנחנו מקווים לפרסם בשבועות הקרובים פוסט בבלוג עם סקירה כללית נוספת על הדיווח על מכרזים ב-FLEDGE. |
| טעינה במקביל | האם שירות הבידינג והמכרזים (B&A) יתמוך במקבילות? | טכנולוגיית פרסום שמשתמשת בשרתים של בידינג או מכרזים יכולה להפעיל כמה שרתים שיכולים להציג תוצאות במקביל. |
| מיטיגציה של התנהלות פוגעת | האם השרת של FLEDGE עם k-anonymity באמצעות טוקנים של מצב פרטי יספיק כדי לשמור על פרטיות המשתמשים? | המניע לשימוש באנונימיות מסוג k הוא פחות ממוקד במיקרו-טירגוט ויותר ביצירת פתרון חלופי זמני במהלך השלב הביניים שבו FLEDGE מאפשר דיווח ברמת האירוע. שיתוף עוד מחשבות וקבלת משוב נוסף. |
| התנגשויות במודול ES | בקשה להסיר את generateBid כפונקציה גלובלית כי היא מתנגשת עם המודול של ES |
אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף. |
| מכרז רכיבים | בקשה למתן שליטה רבה יותר למוציאים לאור על תכנון המכרזים | תכנון של בידינג ומכרזים שתומכים במכרזים של רכיבים, כמו ב-Chrome במכשיר. |
| לוחות זמנים של לפני ואחרי | הסבר על ציר הזמן לספקי טכנולוגיות פרסום שרוצים לבדוק את שרתי ה-B&A | עדכנו את ההסבר על בדיקות B&A ועדכנו את הקטע 'ציר זמן' כדי לכלול הגדרות ברורות של צירי זמן לשלבים שונים של בדיקות B&A ב-Chrome, לאחר התאמה ל-CMA. |
| סכמה לבקרת זמן קצוב לתפוגה | שיפור של תוכנית הבקרה של זמן הקצאת הזמן (timeout) שזמינה כרגע ל-FLEDGE | זוהי הצעה מעניינת. נוסיף את הבקשה הזו לתור של הבקשות לבדיקה, ונעדכן אותך על ההתקדמות. |
| Creative bidstreams | יכולת לבדוק ולסנן את הצעת המחיר הזוכה על סמך הקריאייטיב | זוהי הצעה מעניינת. נוסיף את הבקשה הזו לתור של הבקשות לבדיקה, ונעדכן אותך על ההתקדמות. |
reportWin |
הצעה לספק מידע נוסף על הצעת המחיר עם הדירוג הגבוה ביותר, מבעלים אחר של קבוצת תחומי עניין שאינו הזוכה בפונקציה reportWin |
זוהי הצעה מעניינת. אנחנו נבחן את האפשרות להוסיף אותות נוספים לדיווח המצטבר, ונשמח לקבל מכם משוב נוסף כאן. |
| סוגי אירועים | סטנדרטיזציה של סוגי האירועים ב-API למדידת ביצועים כשמשולבים עם FLEDGE | זוהי הצעה מעניינת. נוסיף את הבקשה הזו לתור של הבקשות לבדיקה, ונעדכן אותך על ההתקדמות. תידרש תיאום עם המאמצים הרחבים יותר שלנו בתחום הזה, כי זה ישפיע על ממשקי API אחרים של ארגז החול לפרטיות, מלבד FLEDGE. אנחנו מקבלים בברכה משוב נוסף כאן. |
| פתרונות לטווח ארוך לדיווח ברמת האירוע | עניין בשמירה של נתונים מסוימים, כמו highestScoringOtherBid, גם אחרי ההוצאה משימוש של קובצי cookie של צד שלישי |
כפי שציינו בפוסט בבלוג מחודש פברואר, נמשיך לתמוך בדיווח על זכיות במכרזים ברמת האירוע "לפחות עד 2026". אין לנו פרטים נוספים לשתף כרגע, אבל נשמח לקבל משוב נוסף על הסיבות לכך שחשוב לשמור על זמינות של נתונים מסוימים אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. |
| המגבלה על קבוצות אינטרס | מה המגבלה על מספר קבוצות העניין שמוצגות לאותו דפדפן? | ב-Chrome אפשר ליצור עד 1,000 קבוצות של תחומי עניין לכל בעלים, ועד 1,000 בעלים של קבוצות של תחומי עניין. הן נועדו לשמש כמגבלות, ולא להגיע אליהן במהלך הפעולה הרגילה. |
| אותות ברמת האירוע | תמיכה בהצעה להוסיף אותות ברמת האירוע ל-generateBid ול-reportWin, שאפשר להשתמש בהם באימוני למידת מכונה |
כאן פירטנו את ההחלטה שלנו לגבי אותות שמיועדים לדפדפן ואותות שמוגדרים על ידי טכנולוגיית הפרסום, ונשמח לקבל משוב נוסף. |
| סקריפט בידינג | צריך לכלול את מזהה המשתמש בכתובת ה-URL של סקריפט הבידינג. | לא ניתן יהיה לעשות זאת כי ל-FLEDGE יש דרישה נוספת: כדי שמודעה תוצג, הקבוצה המורכבת מהבעלים של קבוצת תחומי העניין, כתובת ה-URL של סקריפט הבידינג והקריאייטיב שעבר עיבוד חייבת להיות אנונימית לפי k. |
| אכיפת אנונימיות מסוג k | האם אנונימיות מסוג k-anonymity נאכפת על הצמד (componentAd, size)? | כן, זה יקרה. מידע נוסף זמין ב-turtledove/issues/312. |
| הדרישות לשירותי בידינג ומכרזים | איך שירותי B&A תומכים במשתתפים שמשלבים את FLEDGE במכשיר ובמשתתפים אחרים שמשלבים שירותי B&A? | אנחנו עדיין משלימים את העיצוב, ונשמח לקבל משוב נוסף כאן. |
| שיוך לאחר צפייה | האם תהיה תמיכה בשיוך לאחר צפייה? | בשלב הזה אין לנו הגדרה רגילה כלשהי של יכולת צפייה, ואנחנו מסתמכים על הקריאייטיב עצמו כדי לסמן אירוע צפייה. מידע נוסף זמין בכתובת turtledove/issues/452. |
| טירגוט לפי דמיון | האם ארגז החול לפרטיות תומך ב'טירגוט לפי דמיון'? | כאן אנחנו מדברים על תרחיש לדוגמה, ונשמח לקבל מכם משוב נוסף. |
| Real-time monitoring 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 או ב-Protocol Buffer ולבצע סריאליזציה שלהם למחרוזת. |
| רשימת חסימה של מפרסמים | אילו אותות יתאימו כדי לספק לקונה רשימת מודעות חסימה של מפרסמים? | המקום המתאים הוא auctionSignals או perBuyerSignals. |
| יחידת בידינג | תמיכה ביחידות בידינג שונות, כמו עלות להתקנה ועלות לאלף חשיפות | נשמח לדעת למה יש צורך בכך, בהתאם לעיצוב הנוכחי, ונשמח לקבל משוב נוסף. |
| הלוגיקה של המכרז | האם הדפדפן או שרת המודעות מחליטים מי המנצח במכרז? | כל בחירת הזוכים מתבצעת בתוך ארגז החול, וכל ההחלטות מתקבלות על ידי הקוד של המוכר. הדפדפן מספק פשוט סביבה סגורה ופרטית שבה פועל הקוד של הקונה והמוכר. |
| Permissions-Policy | האם המדיניות הנוכחית של FLEDGE בנושא הרשאות תמשיך להיות נאכפת אחרי שגרסת המקור לניסיון תסתיים? | במהלך תקופת הניסיון למקורות, רשימות ההיתרים שמוגדרות כברירת מחדל בשתי התכונות הן זמניות וישתנו. אנחנו רוצים לדעת כמה זמן יידרש למומחים הטכניים של מודעות להתכונן לשינוי לפני שנתחיל לאכוף אותו. |
| אילוץ על גודל האות | המערכת משלבת בקשות של אותו trustedBiddingSignalsUrl מקבוצות שונות של תחומי עניין. מגבלת הגודל של 2MB היא אילוץ. |
האילוץ הזה קיים למבצעי קריאה במכשיר כדי למנוע עומס יתר על המשאבים במכשיר. למבצע קריאה משרת B&A תהיה אילוץ פחות מחמיר. |
| אותות לדיווח | מוסיפים אות נוסף, script-errors, כדי לאפשר אחזור של מספר השגיאות בצד הלקוח לכל בעל קבוצת תחומי עניין לכל computeBid או reportWin / reportResult. |
אנחנו שוקלים את הבעיות הפוטנציאליות שקשורות לפרטיות בהצעה הזו, ומזמינים את הגורמים בסביבה העסקית לשתף תובנות נוספות לגבי הצורך בכך. |
| גודל החלון של K-Anon | הגדלת גודל החלון של K-Anon מהמגבלה הנוכחית של 7 ימים. | אנחנו בוחנים את האפשרות הזו כרגע וממתינים (ומקבלים בברכה) משוב נוסף מהסביבה העסקית. |
| ביצועי המכשיר | איך FLEDGE מטפל בביצועי המכשיר אם המשתמש נמצא במספר גדול של קבוצות של תחומי עניין? | FLEDGE מציע כמה אפשרויות של זמן קצוב לתפוגה, תעדוף ומגבלות ב-SSP וב-DSP, שמעניקות לטכנאי הפרסום שליטה מפורטת במצבים שבהם ביצועי המכשיר עשויים להיות אחד מהסיבות להגבלת ההשתתפות במכרזים כשהמכשיר נמצא במספר גדול של קבוצות של תחומי עניין. |
| בדיקת שירותי B&A | בקשה לשחקנים בסביבה העסקית להשתמש בשרת שלהם במהלך שלב הבדיקה כדי שיהיה להם גישה ליותר יומנים לניפוי באגים | באמצעות B&A, המשתמשים יכולים להפעיל שרתי ענן של ספקי ענן שאושרו ולהתאים אותם לעומס. כדי לשמור על פרטיות המשתמשים, אנחנו אוכפים את הביצועים בסביבת מחשוב אמינה (TEE). בקרוב נשיק הסבר על ניפוי באגים ב-B&A TEE, ואנחנו מפתחים תכונות שתומכות בכך. אנחנו מחפשים משוב נוסף בנושא. |
| דרישות רגולטוריות | האם FLEDGE יפעל בשיתוף עם ספקי ענן במדינות שונות כדי לתמוך בתאימות לדרישות הרגולטוריות המקומיות? | אנחנו תמיד פתוחים להצעות לגבי ספקי ענן אחרים, אבל בשלב זה אנחנו מתכננים לתמוך לפחות ב-GCP וב-AWS כשהוצאת קובצי ה-cookie של צד שלישי תיכנס לתוקף. מידע נוסף זמין במאמר הזה. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| ניתוח נתונים של השפעת הרעש | הנחיות לביצוע ניתוח נתונים של ההשפעה של רעש | שיתפנו מסמכים נוספים לגבי רעש, לגבי החלטות לגבי רעש ועיצוב שאפשר להשתמש בהן כדי לשנות את ההשפעה של הרעש על נתוני טכנולוגיית הפרסום. יש גם מדריך מפורט יותר. |
| דיווח על ערכים null | הבהרה לגבי ההטמעה של דוחות null | אנחנו עובדים כרגע על הצעה להטמעת דוחות null, ובקרוב נשתף פרטים נוספים. הטמעת דוחות null תאפשר לנו לקצר את זמני הדוחות בלי לפגוע בפרטיות. |
| רמת הרעש | התאמת רמת הרעש לפי אורך חלון השיוך | אנחנו מקבלים בברכה את ההצעה הזו ואנחנו בודקים אם להוסיף אותה למפרט. נשמח לקבל משוב נוסף כאן. |
| גודל הנתונים של הטריגר | למה גודל הנתונים של הטריגר מוגבל ל-3 ביט? | הגודל מוגבל ל-3 ביט ו-8 ערכים נפרדים, כדי לוודא שהמידע על המשתמש באתרים שונים או בהקשרים שונים מוגבל. אנחנו מזמינים את הגורמים בסביבה העסקית לשלוח משוב לגבי ההגדרה הנוכחית של הפרמטרים לדיווח ברמת האירוע, כדי שנוכל לבדוק אם היא הגיונית. |
| טריגרים לדיווח ברמת האירוע | מתן אפשרות לקביעת עדיפות במפתח להסרת כפילויות | אנחנו בודקים פתרונות לבעיה הזו ונשמח לקבל מכם משוב נוסף. |
| תמיכה בניפוי באגים | הסבר על ניפוי באגים אחרי ההוצאה משימוש של קובצי cookie של צד שלישי | אנחנו רוצים לתמוך בניפוי באגים אחרי ההוצאה משימוש של קובצי cookie של צד שלישי, ואנחנו בוחנים את האפשרויות. אנחנו מחפשים משוב ורעיונות נוספים. |
| חלופות להמרות לאחר קליקים | בקשה לקבלת הנחיות נוספות לגבי חלופות להמרות לאחר קליקים | אנחנו ממליצים לסביבה העסקית להשתמש ב-Attribution Reporting API כמערכת מדידה פרטית ועמידה לתרחישי שימוש רלוונטיים למעקב המרות. יש חלופות אחרות, וספקי טכנולוגיות הפרסום יצטרכו להחליט איזה פתרון מתאים להם על סמך הצרכים שלהם בתחום הפרטיות והשימושיות. |
| תרחישים לדוגמה בנושא חיוב | הסבר על מידת התמיכה של דוחות השיוך בתרחישי שימוש בחיוב המבוסס על המרות | אנחנו פועלים כדי לפרסם מידע ציבורי שיבהיר את ההיקף של 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 בדוחות השיוך (Attribution) ברמת האירוע. |
אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף לגבי השחקנים בסביבה העסקית, כדי לבדוק אם התכונה הזו שימושית להם. |
| מצב אנונימי | האם פתרונות המדידה יהיו זמינים כשהמשתמש נמצא במצב פרטי? | לא, פתרונות למדידת ביצועים לא יהיו זמינים כשהמשתמש נמצא במצב פרטי. קובצי cookie של צד שלישי מושבתים כברירת מחדל במצב פרטי. |
| חדרים נקיים לנתונים | האם ממשקי ה-API למדידת ביצועים יהיו תואמים לחדרים נקיים? | חדר נקי לנתונים הוא סביבת עבודה שבה מעלים למסד נתונים נתונים של מזהים ספציפיים ממקורות שונים, כדי להריץ ניתוחים על סמך מיזוג הנתונים הבסיסיים האלה. שתי מסגרות המדידה של ממשקי ה-API של ארגז החול לפרטיות הן דוחות ברמת האירוע ודוחות סיכום. דוחות ברמת האירוע מכילים מזהה אירוע שסופק על ידי חברת טכנולוגיית הפרסום, שאפשר להשתמש בו ב-cleanroom לנתונים, אבל המידע המשויך בצד ההמרה יהיה מוגבל ויש בו רעש. אי אפשר להשתמש בדוחות מוצפנים שניתן לצבור אותם ישירות בחדר נקי, אבל אפשר להשתמש בתוצאות הסיכום שסופקו על ידי שירות הצבירה כקלט לניתוחים שאתם מבצעים או כמידע משלים. |
Aggregation Service
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| (דיווח גם ברבעון הרביעי של 2022) דיווח על עיכובים |
מהו עיכוב הדיווח הצפוי? | עדכון לרבעון הראשון של 2023: בהמשך למשוב שקיבלנו מהשותפים, שיתפנו הצעות לקיצור זמן האחזור ולצמצום ההשפעה של זמן האחזור. שתי ההצעות קיבלו תמיכה מצוותים של טכנולוגיות פרסום במהלך שיחות ב-WICG. |
| כלל ללא כפילויות | איך מטפלים ב'דוח עם נתונים מצטברים שעבר עיכוב' אם כבר בוצע עיבוד של דוחות עם נתונים מצטברים עם אותו מזהה משותף? | שיתפנו הצעה להוספת עיכוב נוסף לדוחות למידע המשותף של דוחות שניתן לצבור, ולהגדרת מזהה משותף לשירות הצבירה, כדי לטפל באופן חלקי בהשפעה של אובדן עיכוב על API המצטבר. נשמח לקבל משוב על ההצעה. |
| עיבוד נתונים | בקשה להפעלת תמיכה במספר מעברים של נתונים תוך שמירה על פרטיות דיפרנציאלית, באמצעות תקציב פרטיות | אנחנו מדברים על האפשרות להשתמש בדרך גמישה יותר לניצול תקציב הפרטיות כדי לאפשר את התרחיש הזה, ונשמח לקבל משוב נוסף. |
| (דיווחנו על כך גם ברבעון השני של 2022) ארגונומיה של שאילתות | הפעלת שאילתות על צבירה של מפתחות. | עדכון לרבעון הראשון של 2023: אנחנו עדיין בוחנים את הבקשה שלך להוספת תכונה, אבל אין לנו הצעות לשתף איתך בשלב הזה. |
| הגבלות על גרסאות מקור לניסיון | להבהיר את היקף שירות האגרגציה, למשל 'הכלל של איסור כפילויות' שלא חל כרגע בגרסת הניסיון למקור. | אנחנו שוקלים לעדכן את המסמכים שלנו כדי להבהיר מה יהיה זמין בגרסת ה-GA לעומת גרסת ה-GA הזמינה לכולם. |
Private Aggregation API
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| תקציב התרומה ל-Private Aggregation | התקציב לתרומות ברמה L1 מוגבל מדי. | כל קריאה ל-Private Aggregation API נקראת 'תרומה'. כדי להגן על פרטיות המשתמשים, מספר התרומות שאפשר לאסוף מאדם פרטי מוגבל. הסכום של כל הערכים שניתנים לצבירה בכל מפתחות הצבירה חייב להיות קטן מתקציב התרומה. במסגרת העיצוב הנוכחי, אנחנו מגדירים מגבלה על התרומות של מקור דיווח מסוים במהלך כ-24 השעות האחרונות (כחלון מתגלגל). זהו תקציב התרומה ברמה L1 שצוין במשוב. אנחנו ממליצים למפתחים לשנות את הערכים שהם תורמים בהתאם לנפח הצפוי (כלומר, לא להשתמש רק בערך 1). לכן, כדאי להשתמש בערך קטן יותר לאירועים הנפוצים יותר כדי להימנע ממיצוי התקציב. אנחנו מחפשים כרגע משוב על תקציב התרומות של Private Aggregation API, גם לגבי המגבלה המספרית וגם לגבי ההיקף. אנחנו שוקלים להעביר את ההיקף מ'לכל מקור' ל'לכל אתר' ולהעביר את המגבלה הקיימת לחלון של עשר דקות עם מגבלה יומית גדולה יותר. |
הגבלת מעקב סמוי
הפחתת מידע בסוכן משתמש/רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| אימוץ UA-R | מתוך 10,000 האתרים המובילים בבריטניה, רק 1% מהאתרים שמשתמשים בפרסום פרוגרמטי שולחים רמזים ללקוחות 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. | בדפדפנים ל-iOS שאינם Safari (כולל Chrome ל-iOS), תצטרכו להוסיף תמיכה ב-UA-CH לפרויקט WebKit כדי שאפשר יהיה להפעיל אותם (כי הם שולטים ב-stack הרשת). |
הגנה על כתובת ה-IP (לשעבר Gnatcatcher)
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| (דיווח גם ברבעון הרביעי) תרחישים לדוגמה של שימוש במיקום גיאוגרפי | הגנה על כתובות IP עשויה למנוע בעתיד שימוש לגיטימי בתכונות שמבוססות על מיקום גיאוגרפי, כמו התאמה אישית של תוכן על סמך מיקום גיאוגרפי. | התשובה שלנו לא השתנתה מאז הרבעון הרביעי של שנת 2022: "אנחנו עובדים עם בעלי עניין כדי להבטיח ש-Chrome ימשיך לתמוך בתרחישי שימוש לגיטימיים של כתובות IP. אנחנו מחפשים משוב מהסביבה העסקית לגבי רמת הפירוט של מיקום גיאוגרפי לפי כתובת IP". |
| תאימות לדרישות תקינה | אם האוכלוסייה באזור מסוים היא פחות ממיליון איש, הסף הנוכחי של מיליון איש להגנה על כתובות IP ימנע מהאתרים להשתמש בכתובות IP לצורך תאימות רגולטורית. | אנחנו עובדים עם בעלי עניין כדי להבטיח ש-Chrome ימשיך לתמוך בתרחישי שימוש לגיטימיים של כתובות IP. אנחנו מבקשים משוב מהסביבה העסקית לגבי תאימות לתקנות בנושא הגנה על קניין רוחני. |
| מיטיגציה של התנהלות פוגעת | צדדים יכולים לעקוף את הגנת ה-IP על ידי שיתוף כתובות IP לא אנונימיות עם אחרים. | אנחנו מודעים לכך שיכול להיות שהצעה הנוכחית להגנה על כתובות IP לא תמנע מבחינה טכנית שיתוף של כתובות IP לא אנונימיות עם אחרים. אנחנו עובדים על פתרונות שימנעו את הסיכון הזה. במהלך העבודה על ההצעה, נשמח לקבל מכם עוד משוב ודיון. באופן ספציפי, אנחנו רוצים לדעת על תרחישי שימוש שבהם צדדים סבורים שהם צריכים לשתף כתובות IP לא אנונימיות עם צדדים אחרים. |
| חסימה ברשת | גורמים יכולים לעקוף את חסימת הרשת באמצעות שרתים proxy להגנה על כתובות IP. | הישות שמבצעת את החסימה תצטרך להשבית את ההגנה על כתובת ה-IP בתרחיש הזה. הבעיה טופלה ונשמח לקבל משוב נוסף. |
| רשימות החסימות של כתובות IP שמושפעות מהצעה להגנה על זכויות יוצרים באינטרנט | חברות רבות בתחום טכנולוגיית הפרסום משתמשות ברשימת חסימות בסיסית של כתובות IP, כמו רשימת כתובות ה-IP של מרכז הנתונים של TAG, כדי למנוע בידינג על מלאי שטחי פרסום שיש סיכוי גבוה שהוא לא תקין (או לפחות לא ניתן לייצר ממנו הכנסות). אם חברת טכנולוגיית פרסום היא גם שירות מעקב, והיא עשויה להיות כפופה להצעה להגנה על זכויות יוצרים, יכול להיות שהחברה הזו תאבד את היכולת לבצע בדיקה בסיסית של מודעות לפני רכישת מלאי שטחי פרסום. | אנחנו מעודדים משוב נוסף ודיון בנושא ההצעה להגנה על קניין רוחני, בקשר לבעיות פוטנציאליות ולפתרונות. אפשרות אחת היא להחיל רשימות דומות כאלה על הגנה על כתובות IP, כך שלא נפעיל שרת proxy ללקוחות שמגיעים מכתובות IP שסומנו בעבר. |
חיזוק גבולות הפרטיות באתרים שונים
קבוצות מאינטראקציה ישירה (First-Party Sets)
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| (דווח גם ברבעון 4) מגבלת דומיינים | בקשה להרחבת מספר הדומיינים המשויכים | התשובה שלנו לא השתנתה מאז הרבעון הרביעי של 2022: "בהתאם לשיחות שלנו ב-WICG, אנחנו ב-Chrome מחויבים לספק פתרון שמתאים לשימוש ומביא בחשבון גם את האינטרסים של המשתמשים בנושא פרטיות. בהקשר הזה, נשמח לקבל משוב מהקהילה לגבי תרחישים לדוגמה ספציפיים שעשויים להיות מושפעים מהמגבלה על דומיינים, כדי שהצוות יוכל לבחון דרכים לטפל בתרחישים האלה תוך המשך הגנה על פרטיות המשתמשים." |
| שליחת סרטון עם FPS חלופי | הצעה לדרך חלופית לשליחת רשימות גלובליות ל-FPS | בשלב הזה אנחנו מתכוננים להשיק את התכונה 'קבוצות של צד ראשון' (FPS) ב-Chrome, והקמנו מאגר מרוכז ב-GitHub לקבלת שליחת קבוצות. אנחנו מקווים ש-FPS ימלא את הפער בפתרונות הקיימים לפלטפורמות אינטרנט לקראת ההוצאה משימוש של קובצי cookie של צד שלישי, ולכן אנחנו מצפים ללמוד מהם איך מחברי אתרים משתמשים ב-FPS. ככל שרשימת הקבוצות תגדל עם הזמן והסביבה העסקית תתאים את עצמה לעולם ללא קובצי Cookie של צד שלישי, נוכל גם לשפר את התהליך עד שנוכל להביא בחשבון סכמות חלופיות מבוזרות, כמו זו שהצענו. בתהליך הנוכחי, אנחנו מתכננים להגדיר משכי חיים קבועים, שיאפשרו לנו לשפר את תהליך ההטמעה לאורך זמן. נוכל לבחון מחדש את הרעיון הזה אחרי שתהליך השליחה יתפתח. |
| ניהול מאגרים | להפעיל בקרב הקהילה תהליך של ניהול תוכן במאגר של נתוני FPS שנשלחו, כדי למנוע ניצול לרעה. גורמים זדוניים יכולים בקלות להעמיס על התהליך באמצעות שימוש במקורות זמניים כדי להציע קבוצות, ועומס עצום של בקשות עלול להשפיע על הפעולות של הצעות קבוצות אמיתיות. | אנחנו משתמשים בבדיקות אימות טכניות כדי לנסות להפוך את הבדיקות לאובייקטיביות ככל האפשר. לדעתנו זוהי הגישה הכי גמישה לתהליך השליחה. בהתאם ליעד הזה, נשתדל גם לוודא שהתהליך עמיד בפני שליחת ספאם או שליחת בקשות מחשבונות חד-פעמיים. |
| קבוצות משנה משויכות | האם מערכת FPS תוכל לתמוך בתרחישי שימוש של ספקים או שירותי SaaS של צד שלישי באמצעות קבוצות משנה משויכות? | תהליכי הצד השלישי / SaaS הם לא תרחיש שימוש שנכלל כרגע בהיקף של קבוצות מאינטראקציה ראשונה. נשמח לקבל משוב נוסף על האופן שבו אתם משתמשים בקובצי cookie בכמה אתרים לתרחישי השימוש האלה. |
| שילוב של FPS ו-CHIPS | בקשה לשילוב של FPS ו-CHIPS כדי לתמוך בתרחישי שימוש כמו בדיקות A/B | אנחנו מדברים על התרחיש הזה, ואנחנו גם שוקלים להמשיך את הדיון בנושא הזה בשיחת WICG. נשמח לקבל משוב נוסף כאן. |
| GDPR | הצעה לקבוצת משנה חדשה של FPS שתתבסס על מושגי GDPR | דנו בהצעה הזו באופן פנימי והשווינו אותה למשוב אחר שקיבלנו, וגם למטרות שלנו בנושא פרטיות. התשובה שלנו מסבירה למה לא נמשיך כרגע בטיפול בהצעה הזו. |
| זיכרון | השינוי הצפוי בגודל הזיכרון של הדפדפן כשהרשימה של FPS משולבת | יש מקרים קודמים שבהם דפדפנים שמרו רשימות מהסוג הזה עם השפעה מינימלית על הזיכרון, כמו רשימת ההגנה מפני מעקב של Disconnect. רשימת הקבוצות מאינטראקציה ראשונה תועתק לכל לקוח Chrome באופן מקומי, אבל אנחנו נמשיך לעקוב אחרי גודל הקובץ, ובטוחים שנוכל לבצע אופטימיזציה של שטח האחסון בזיכרון. |
Fenced Frames API
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| מגבלות על פריימים ללא שיתוף נתונים | הסבר על המגבלות של פריימים מגודר | בחודש מרץ עדכנו את הסרטון להסבר על פריימים מגודר, שבו מפורט מידע על היכולות של התכונה. נשמח לקבל מכם משוב נוסף. |
| הרחבת פרטי הגישה | בקשה להרחבת הגישה למידע על התמונות הסמוכות | אנחנו רוצים להבין טוב יותר למה זו דרישה בסביבה העסקית, ונשמח לקבל משוב נוסף. |
| מסגרות ללא שיתוף נתונים ומסגרות iframe | שאלות לגבי התכונות המשותפות של 'מסגרות מגודרות' ו-iframe | כל הדוחות וממשקי ה-API הזמינים של ארגז החול לפרטיות יהיו זמינים ל-iframe ול-FencedFrames באותו אופן. |
| שינוי הגודל של מסגרות ללא שיתוף נתונים | הגבלת השינויים בגודל הפריים משפיעה על תרחישי שימוש מסוימים. | אנחנו רוצים לקבל מידע נוסף על סוגי תרחישי השימוש שמושפעים מההגבלה, ונשמח לקבל משוב נוסף. |
Shared Storage API
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| רכיבי worklet של צד שלישי | האם צדדים שלישיים יכולים לכתוב באחסון משותף שמחולק לפי מקור? או להפעיל וורקלטים אחרים למדידת ביצועים על ידי צד שלישי? | המקור של הקשר הגלישה שבו הקוד מופעל קובע לאיזה אחסון שיתופי הנתונים האלה נכתבים. כשמצרפים קוד של צד שלישי לדף, אפשר להטמיע את הקוד של הצד השלישי כ-iframe עם הקשר גלישה משלו, שמאפשר לקוד של הצד השלישי לכתוב למקור שלו. אפשר גם להטמיע את הקוד של הצד השלישי כסקריפט במקום כ-iframe, כך שלא יתבצע שינוי בהקשר הגלישה, וצד שלישי יכול לכתוב באחסון המשותף של המטמיע. חשוב לזכור שרק הבעלים של האחסון המשותף יכול לקרוא ממנו. |
| ביטול כפילויות | לא ניתן יהיה לבצע מחיקה כפולה של אינטראקציות מחוץ לסביבה העסקית של Chrome. | המטרה של אחסון משותף היא לספק פלט ייחודי של פוטנציאל החשיפה מבוסס-דפדפן Chrome בתוך Chrome. אנחנו רוצים לעבוד עם ספקי טכנולוגיות פרסום כדי להבין איך אפשר להשתמש בפלט הזה כחלק ממודלים רחבים יותר של פוטנציאל החשיפה. אנחנו מבינים שהפלט עצמו עשוי לכלול רק חלק מהאינטראקציות, ואנחנו רוצים לעבוד עם טכנולוגיות פרסום כדי לבחון שיטות נוספות ליצירת מודלים שאפשר להוסיף. |
| חלון מבט לאחור להמרות | בקשה להגדרת חלון מבט לאחור לשיעור ההמרה כדי לראות שינויים בהמרות לאורך זמן | כדי להטמיע את הפתרון הזה, מעבדים את נתיבי ההמרות השונים בצד הלקוח באמצעות אחסון משותף. כך אפשר ליהנות מגמישות נוספת לניתוח נתונים מתקדם, במקום אחסון מאובטח בדפדפן ללא מחיצות. |
| חלון התפוגה של הפריט | בקשה להארכת חלון התפוגה ל-90 יום | מדיניות שמירת הנתונים עודכנה בנובמבר 2022, ומציינת שכל מפתח נמחק לאחר שלושים יום מהכתיבה האחרונה. נשמח לקבל משוב נוסף כדי שנוכל להבין אם המדיניות החדשה תתאים לסביבה העסקית. |
| סבב קריאייטיב | תרחישי לדוגמה של רוטציית קריאייטיב לא משקפים את הפעולות בפועל לאחר המכרז. | אנחנו רוצים לשמוע מיותר חברות טכנולוגיות פרסום בצד הקונה אם מסמכי התיעוד של רוטציית הקריאייטיב מדויקים או לא. |
CHIPs
לא התקבל משוב ברבעון הזה.
FedCM
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| נקודת קצה לאימות זהות | לאפשר באופן מפורש בקשות שרירותיות לנקודת הקצה של טענת הנכוֹנוּת של הזהות. | שיתפנו פעולה עם Mozilla בבקשת משיכה הזו כדי להגביל את היכולת של אתרים לשלוח בקשות עם פרטי כניסה ממקורות שונים בשקט, בלי להטריד את המשתמשים. אנחנו נמשיך לבדוק משוב נוסף ולטפל בו. |
| אכלוס הזהות מראש | האם אפשר להשתמש ב-FedCM כדי לאכלס מראש טפסים לכניסה באמצעות ספק זהויות מרשימת FedCM? | החשש בתרחיש לדוגמה הזה הוא שאתר שלא היה לו אינטראקציה עם המשתמש יוכל לשלוח שאילתה ל-IDP האחרון שבו המשתמש השתמש, וכך לגרום לדליפת מידע. אנחנו דנים בבעיה הזו ונשמח לקבל משוב נוסף. |
| בחירת חשבון לפי הקשר | הצעה להוספת אותות לפי הקשר בממשק המשתמש לבחירת חשבון | אנחנו שוקלים את ההצעה הזו ונשמח לדיונים נוספים. |
נלחמים בספאם ובהונאות
Private State Token API (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה מ-Chrome |
|---|---|---|
| סקר לאיסוף מידע על יכולות | בתחילת הרבעון הראשון סיימנו לאסוף את תוצאות הסקר לגבי היכולות הנדרשות בתרחישי שימוש שונים למניעת הונאות, ושיתפנו אותן באופן ציבורי (דקות, תוצאות) | אנחנו מתכננים לשלב את המשוב הזה ככל שנפתח הצעות ותוכניות אב חדשות לממשקי API ייעודיים לשמירה על הפרטיות, עם יכולות למניעת הונאות. אנחנו נותנים עדיפות לפיתוח כשיש צורך מספיק ויש טכנולוגיה קיימת שאפשר להסתמך עליה כדי להציג את היכולת הזו באינטרנט, תוך שמירה על פרטיות המשתמשים. לדוגמה, הנושא 'תקינות המכשיר והפעלה' דורג גבוה, ויש בפלטפורמות רבות ממשקי API קיימים שמאפשרים לשתף באופן מאובטח הערכה של תקינות המכשיר. לכן, זהו נושא מתאים לבדיקה בקבוצות הקהילה. |
| משוב על כוונה לשלוח הודעה ב-PST | כחלק מהכוונה לשלוח את הבקשה, קיבלנו הודעה על חשש ממשיכת התהליך, מאחר שאנחנו משתמשים בגרסה ישנה יותר של Privacy Pass. קיבלנו גם משוב על כך שהמפרט לא היה ברור בחלקים מסוימים, ויש לשפר אותו כדי לשפר את התאימות לדפדפנים. | אנחנו מתכננים להטמיע הרבה מהשינויים המוצעים במפרט לפני השקת הגרסה היציבה, וגם כמה שינויים ב-API. המשוב הגיע ממש בסוף הרבעון הראשון, ולכן אנחנו פועלים בנושא הבעיות ב-GitHub עם פרטים ספציפיים ועדכון לתוכנית ההשקה שלנו (העדכון מתבצע כרגע, נכון למועד פרסום דוח המשוב הזה). אנחנו פתוחים לשקול את השינויים המשמעותיים יותר ב-API, אבל לדעתנו הדרך הטובה ביותר היא להמשיך בהשקה לזמינות רחבה ולקבל משוב מעשי ממפתחים נוספים. אנחנו מקווים שנוכל להמשיך את הדיון הזה ולקדם את התקנת התקן בדפדפנים. אם יתפתח תקן חדש, נבחן את האפשרות לאמץ אותו ולפתח תוכנית למעבר אליו. |