דוח רבעוני לרבעון 3 של שנת 2022 שמסכם את המשוב שהתקבל לגבי הסביבה העסקית בנוגע להצעות של ארגז החול לפרטיות והתגובה של Chrome.
כחלק מהמחויבויות שלה ל-CMA, Google הסכימה לספק באופן ציבורי דוחות רבעוניים על תהליך המעורבות של בעלי עניין להצעות של ארגז החול לפרטיות (ראו סעיפים 12 ו-17(c)(ii) במחויבויות). דוחות סיכום המשוב של ארגז החול לפרטיות נוצרים על ידי צבירת משובים ש-Chrome מקבל מהמקורות השונים, כפי שמפורט בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין ב-privacysandbox.com, פגישות עם בעלי עניין בתחום ופורומים של תקני אינטרנט. ב-Chrome מקבלים בברכה את המשוב שמתקבל מהסביבה העסקית, ובוחנים באופן פעיל דרכים לשלב את התובנות שנלמדו בקבלת החלטות לגבי תכנון.
נושאי המשוב מדורגים לפי מידת השכיחות לכל API. כדי לעשות את זה, מתבצעת צבירה של כמות המשוב שצוות Chrome קיבל לגבי עיצוב נתון, תוך ארגון בסדר יורד של כמות. כדי לזהות את הנושאים הנפוצים במשוב, עיינתי בדיונים שנשאלו בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שהעלו הצוותים הפנימיים והטפסים הציבוריים של Google.
באופן ספציפי, נבדקו פרוטוקולים של פגישות עם גופים סטנדרטיים באינטרנט, וכדי לקבל משוב ישיר, נלקחו בחשבון הרשומות של Google לגבי פגישות אישיות עם בעלי עניין, אימיילים שהתקבלו מהמהנדסים, רשימת הדיוור של ה-API וטופס המשוב הציבורי. לאחר מכן, Google תאמה בין הצוותים שלקחו חלק בפעילויות ההפצה השונות כדי לקבוע את השכיחות היחסית של הנושאים שעלו ביחס לכל ממשק API.
ההסברים של Chrome למשוב פותחו על סמך שאלות נפוצות שפורסמו, תשובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת מיקום באופן ספציפי למטרת תרגיל זה של דיווח ציבורי. עדכון בנושא הנוכחי, של הפיתוח והבדיקות, של השאלות והמשוב שקיבלנו באופן ספציפי על ממשקי ה-API של Topics, Flidge ו-Attribution.
יכול להיות שמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עוד לא נחשב כתגובה מ-Chrome.
מילון של ראשי תיבות
- צ'יפים
- קובצי Cookie עם חלוקה עצמאית למחיצות
- DSP
- פלטפורמה בצד הביקוש
- FedCM
- ניהול פרטי כניסה מאוחדים
- FPS
- דומיינים של צד ראשון
- IAB
- הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)
- IdP
- ספק זהויות
- IETF
- כוח המשימה של ההנדסה באינטרנט
- IP
- כתובת פרוטוקול אינטרנט
- openRTB
- בידינג בזמן אמת
- הארכה
- גרסת מקור לניסיון
- PatCG
- קבוצת קהילת הטכנולוגיות של פרסום פרטי
- RP
- מפלגה מהימנה
- SSP (פלטפורמה בצד המכירה)
- הפלטפורמה לספקים
- TEE
- סביבת מחשוב אמינה
- UA
- מחרוזת סוכן משתמש
- UA-CH
- רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
- W3C
- ארגון התקינה באינטרנט
- WIPB
- עיוורון IP ללא כוונה
משוב כללי, ללא API/טכנולוגיה ספציפיים
| נושא המשוב | סיכום | תגובה של Chrome |
| (מדווח גם ברבעון השני)
שימושיות לסוגים שונים של בעלי עניין |
חשש שהטכנולוגיות של ארגז החול לפרטיות מעדיפים מפתחים גדולים יותר, ושאתרים נישתיים (קטנים יותר) תורמים יותר מאשר אתרים גנריים (גדולים יותר). | עדכון לרבעון 3:
Google התחייבה ל-CMA לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא יעוות את התחרות על ידי מתן עדיפות לעסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי התוכן הדיגיטלי והמפרסמים, בלי קשר לגודלם. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה. עם התקדמות הבדיקה של ארגז החול לפרטיות, אחת מהשאלות המרכזיות שנשאל אותה היא את הביצועים של הטכנולוגיות החדשות עבור סוגים שונים של בעלי עניין. משוב הוא קריטי מהבחינה הזו, במיוחד משוב ספציפי ומעשי שיכול לעזור לנו לשפר את העיצובים הטכניים. עבדנו עם ה-CMA כדי לפתח את הגישה שלנו לבדיקות כמותיות, ואנחנו תומכים בכך ש-CMA תפרסם הערה לגבי תכנון הניסוי כדי לספק מידע נוסף למשתתפים בשוק והזדמנות להגיב על הגישות המוצעות. |
| (מדווח גם ברבעון השני)
בקשות לתיעוד |
בקשות למשאבים נוספים שמפרטים איך לנהל את הבדיקה, הניתוח וההטמעה | עדכון לרבעון 3:
אנחנו מעריכים את העובדה שהחומרים הנוכחיים שלנו הועילו למפתחים, ומחויבים לספק חומרים נוספים במהלך השבועות והחודשים הקרובים כדי שמפתחים יוכלו להמשיך להבין כיצד הטכנולוגיות החדשות יכולות לעבוד בשבילם. בנוסף, קיימנו מפגשים ציבוריים במהלך שעות העבודה למפתחים כדי לשתף שיטות מומלצות והדגמות, וכן מפגשי שאלות ותשובות עם גורמי מפתח בתחום המוצר וההנדסה, כדי לאפשר דיון בזמן אמת או העלאת שאלות. |
| תמיכה בדפדפנים שונים | ספקי דפדפנים אחרים משתמשים בממשקי ה-API של ארגז החול לפרטיות. | ספקים אחרים של דפדפנים, כמו Apple, Mozilla ו-Microsoft, משתתפים באופן פעיל בפורומים ציבוריים שבהם דנים עקרונות הפרטיות וגישות מבוססות-דפדפן. אנחנו מקבלים עידוד מהדיונים המשותפים בפורומים, כמו פגישת TPAC השנתית האחרונה של W3C והפורומים המתמשכים של W3C PATCG, שבהם אנחנו רואים סימנים של התכנסות. |
| הבדלים בין פלטפורמות | כדאי לבקש התאמה בין קבוצות התכונות באתרים וב-Android עד כמה שניתן, כדי לצמצם את המשאבים הדרושים למעבר. | אנחנו משקיעים מאמצים רבים כדי להתאים את הגישות שלנו ב-Chrome וב-Android כדי למנוע בלבול או פיצולים בתעשייה. ההבדלים בגישה שלנו נובעים בעיקר מהבדלים טכניים נדרשים בין פלטפורמות האינטרנט והפלטפורמות של אפליקציות לנייד, שהמפתחים כבר מביאים בחשבון. |
| משאבים לבדיקת ממשקי ה-API של ארגז החול לפרטיות | קשיים בהקצאה של כמות מספיקה
משאבים לבדיקת ממשקי ה-API של ארגז החול לפרטיות על רקע המצב הכלכלי הנוכחי. |
Google משפרת כל הזמן את התיעוד והתמיכה הזמינים לבודקים, כדי להקל על המורכבות של השימוש בממשקי ה-API וכדי לעזור להם להשתמש בממשקי ה-API. המאמצים האלה כוללים: רשימות תפוצה ספציפיות ל-API, שעות עבודה פתוחות ועדכונים שוטפים ב-developers.chrome.com. |
| אות לביטול הסכמה ל-Sandbox API | בקשה לספק אות 'משתמש ביטל את ההסכמה לשימוש בממשקי API של Sandbox', שישמש טכנולוגיות פרסום ואתרים. | נתקלנו במקרים רבים היסטוריים שבהם אתרי אינטרנט מגיבים לבחירות של משתמשים, כמו "להשבית קובצי cookie של צד שלישי", על ידי לחיצה על המשתמש לשנות את ההגדרות שלו, ולפעמים גם חסימת הגישה לאתרים, אלא אם כן. ניתן להשתמש באות לביטול הסכמה גם כאות נוסף ליצירה של טביעת אצבע דיגיטלית (fingerprinting). בשלב זה, Google לא מתכוונת לספק אות לביטול ההסכמה. |
| (מדווח גם ברבעון השני)
לוחות זמנים ברורים יותר |
לוחות זמנים ברורים ומפורטים יותר להשקה | עדכון לרבעון 3:
כפי שמוסבר בקטע 'שינויים בתגובה למשוב' שבהמשך, Google עדכנה את ציר הזמן של ארגז החול לפרטיות ביולי כדי לתת לשוק זמן נוסף לבדיקות ראשוניות ולקבלת משוב, וכן זמן נוסף לבדיקה אחרי שממשקי ה-API של ארגז החול לפרטיות יושקו באופן מלא לפני ההוצאה משימוש של קובצי ה-cookie של צד שלישי. |
| (מדווח גם ברבעון השני)
לוחות הזמנים להוצאה משימוש של קובצי cookie של צד שלישי |
בקשות למניעת עיכובים נוספים להוצאה משימוש של קובצי cookie של צד שלישי | עדכון לרבעון 3:
ביולי הוכרז ב-Chrome לוח זמנים מעודכן להוצאה משימוש של קובצי cookie של צד שלישי, שמשקף את המחויבות שלנו לפעול באופן אחראי, לאור המורכבות של הטכנולוגיות והחשיבות שלהן לסביבה העסקית. לפני השינוי נלקחנו בחשבון משובים מרגולטורים ומהתעשייה, ואנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם כל בעלי העניין. |
| קובצי cookie מהדומיין הנוכחי | האם מוצעות גם הגבלות על קובצי cookie של הדומיין? אם כן, יש חששות בנוגע ליציבות לטווח ארוך, סיכון משינויים לא צפויים נוספים בדפדפן וכתוצאה מכך בזבוז של מאמצי ההנדסה כיום. | לא שקלנו את ההגבלות על השימוש בקובצי cookie מהדומיין הנוכחי. אנחנו מתמקדים בארגז החול לפרטיות בהוצאה משימוש של קובצי cookie של צד שלישי. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא המשוב | סיכום | תגובה של Chrome |
| (מדווח גם ברבעון השני)
שימושיות לסוגים שונים של בעלי עניין |
הועלו חששות בנוגע למידת התועלת שיש לאתרים האלה, בהתאם לרמת התנועה שהם מקבלים או למידת המיוחדות של התוכן שלהם. | עדכון לרבעון 3:
נבדוק את התועלת של ממשק ה-API באמצעות בדיקות. בהתאם לדרישות של סעיף 17.ג.ii בהתחייבויות, Google תשתף עם מנהלי הקהילה את התוצאות של הבדיקות האלה. ב-Chrome אנחנו מצפים שהטקסונומיה ופרמטרים אחרים ישתנו על סמך תוצאות הבדיקה. ייתכן שהתפתחות הטקסונומיה או הפרמטרים לא תדרוש שינויים שאינם תואמים לאחור. בנוסף, Chrome מצפה לקבל משובים ימשיכו להשפיע על ההתפתחות של Topics API אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. |
| פרטיות/מדיניות | בקשה להסרת הדרישה לסינון נושאים לכל מתקשר. | ב-Chrome נעשה שימוש במשוב של KOFs בנושא פרטיות, מומחים בנושא פרטיות, מומחי אבטחה, קבוצות לזכויות דיגיטליות ואנשים אחרים בתחום, ו-Chrome בחר בעיצוב הזה להעניק גישה למידע רק לאנשים שאחרת הייתה להם גישה כזו. הסיבות לכך כוללות, בין היתר, הגבלה של דליפת נתונים מצטברת בין צדדים, הבטחת שקיפות ויכולת הסבר, אימוץ גישה פשוטה להטמעה ולתיאור והגבלת הסיכון ליצירה של טביעת אצבע דיגיטלית (fingerprinting). בעלי אתרים וצדדים שלישיים שמקבלים את Topics יכולים להחליט בעצמם איזה מידע הם ישתפו עם צדדים באתר שלהם. אם צדדים שלישיים משתפים מידע זה, מומלץ ב-Chrome לפעול בשקיפות מול המשתמשים בכל הנוגע לשיתוף כזה, ולהציע להם אמצעי בקרה. |
| אתרים בסיווג שגוי | האתרים מסווגים באופן שגוי לנושא שגוי, מה שעלול להוביל לטירגוט מודעות לא מדויק. | האתרים מסווגים באמצעות שילוב של רשימת שינויים מברירת המחדל שנוצרה על ידי אנשים, שכוללת את האתרים הפופולריים ביותר ומודל למידת מכונה במכשיר. Chrome ממשיך לבדוק את האפשרויות להוספת אתרים לסיווג של 'נושאים'. יש לשקול את כל השיפורים בתועלת מול סיכוני הפרטיות וניצול לרעה. לדוגמה, כמה מהסיכונים כוללים:
הציבור יכול לבדוק את הרכיבים האלה באמצעות הכלים שזמינים דרך chrome://topics-internals או דרך colab. באמצעות הבדיקה, אנו צופים שהסיווג ישתפר עם הזמן, ואנו נשמח לקבל משוב על דוגמאות של אתרים שייתכן שלא סווגו כראוי. |
| דרישות גישה | הדרישות הנוכחיות של Topics עבור ישות DOM בדף כסקריפט או iframe כדי לקבל גישה עלולות להוביל להתנהגויות לא רצויות על ידי שחקנים בסביבת הפרסום. | מיזגנו שינוי בהסבר של GitHub. אנחנו מתכוונים לתמוך בנושאים בכותרות HTTP. |
| טקסונומיית הנושאים לא מפורטת מספיק | הסיווגים הנוכחיים של הנושאים רחבים מדי, ואינם כוללים נושאים מפורטים יותר, כמו נושאים אזוריים. | שיפורים בטקסונומיה הם מאמץ מתמשך, ואנחנו מצפים שהטקסונומיה תמשיך להתפתח עם בדיקות של הסביבה העסקית והקלט.
אנחנו מבקשים משוב לגבי הטקסונומיה שיכולה להועיל מאוד לסביבה העסקית. כשאנחנו שוקלים אם להרחיב את מספר הנושאים או לכלול נושאים מפורטים יותר, יש כמה שיקולים, כולל 1) השלכות פוטנציאליות על פרטיות (למשל, יותר נושאים עלולים ליצור סיכון ליצירה של טביעת אצבע דיגיטלית) ו-2) היכולת לאחזר נושאים שנצפו בעבר (למשל, ככל שיהיו יותר נושאים, יש פחות סיכוי שטכנולוגיית הפרסום ראתה את הנושא שנבחר בעבר). בדגש על האפשרות השנייה, Google שואפת למקסם את היכולת של המתקשרים לאחזר נושאים שנצפו בעבר, במסגרת דרישת הסינון הקיימת, מתוך מטרה להשיג גם תועלת וגם פרטיות. |
| מגבלת נושאים | מפרסמים לא יכולים להציג מודעות בשלושה נושאים בכל אתר, כי הם מכילים מעט מדי מידע. | משוב מהסביבה העסקית, ובמיוחד תוצאות הבדיקה של גרסאות המקור לניסיון, ימשיכו להשפיע על ההתפתחות של ה-API. חשוב לציין ש-Topics API צפוי להשלים אותות אחרים, כמו הקשר, כדי למצוא פרסומת שמתאימה למבקר. כך שלמפרסם יש מידע נוסף מעבר לנושאים. |
| (מדווח גם ברבעון השני)
בקרות ובטיחות של המשתמשים |
נושאים מסוימים עשויים להיות שרתי proxy בקבוצות רגישות, והמשתמשים זקוקים לאמצעי בקרה נוספים כדי למנוע תוצאות שליליות. | עדכון לרבעון 3:
הנושאים מייצגים צעד משמעותי קדימה לשיפור השליטה והשקיפות של המשתמשים. המשתמשים יוכלו לבטל את ההסכמה לנושאים, לבדוק את הנושאים שהוקצו להם, להסיר נושאים ולהבין אילו חברות נמצאות באינטראקציה עם הנושאים שלהן בדף נתון. בנוסף, המשתמשים יכולים גם לנקות את הנושאים שלהם על ידי מחיקת היסטוריית הגלישה שלהם, שממנה נגזרים הנושאים. אמצעי הבקרה האלה מוטמעים כרגע בדפדפן Chrome ברמת המכשיר. אנחנו מקבלים בברכה דיון מתמשך לגבי אמצעי בקרה מתקדמים יותר על משתמשים, כמו אלה שמפתחים מציעים. עם זאת, עלינו לוודא שהתוספות החדשות מכוילות היטב כדי לתת מענה לחששות שהועלו, ולא לגרום לביצוע שינויים קלים. |
| ההשפעה על אופטימיזציה למנועי חיפוש (SEO) | בעלי אתרים מתאימים את שמות המארחים של האתר שלהם כך שישקפו בצורה טובה יותר את Topics API, כדי להשפיע באופן שלילי על אופטימיזציה למנועי חיפוש (SEO). | אנחנו מזהירים אתרים מפני שינוי שמות המארחים שלהם אך ורק למען 'נושאים'. זה נכון שאתר יכול להשפיע כך על הנושאים שהוקצו לו. אך היתרונות לבעלי האתרים אם הם עושים זאת לא ברורים, לכל היותר, ועלולים לפגוע בערך של Topics עבור כל הסביבה העסקית, אם אתרים מנסים 'לשחק' את מודל הסיווג. גם ההקצאות של הנושאים לא קבועות, ואנחנו מצפים שהטקסונומיה תמשיך להתפתח עם הבדיקות והקלט. במסגרת הבדיקה הזו, אנחנו מעודדים שליחת משוב, כולל דוגמאות לאתרים שייתכן שסווגו באופן שגוי. |
| הונאה וניצול לרעה | לספק לצד הקונה דרך לאמת שהנושא שהוא רואה נוצר באמת על ידי הדפדפן. | אנחנו מעריכים את ההצעה לתמוך במנגנון שקונים באמצעות טכנולוגיית פרסום יכולים לאמת את הנושאים שמפיצים עוברים במכרזים של פרסום פרוגרמטי. אנחנו מעודדים את הסביבה העסקית לתרום לדיון פעיל כאן. אנחנו מתמקדים כרגע בשיפורים אחרים בעדיפות גבוהה יותר, אבל ברור לנו שזו יכולה להיות תוספת עתידית חשובה לעיצוב. |
| הונאה וניצול לרעה | לאפשר בדיקה ציבורית של גורמים שהם משתמשים לגיטימיים בנתוני Topics, באמצעות אותו סוג של פרסום ובדיקה שגלויים לכולם שקבוצה של צד ראשון תהיה כפופה אליהם. | אנחנו מעריכים את ההצעה ומסכימים לכך שאחריות הציבור היא כלי חשוב שעוזר להשיג את היעדים של ארגז החול לפרטיות. קריאות ל-Topics API הן ציבוריות מטבען, כי כל אחד יכול להיכנס לאתר ולראות קריאות של דומיין אל ה-JavaScript API. לכן, אנשים פרטיים וארגונים יכולים לצפות בפעילות הרלוונטית, להעריך אילו אתרים משתמשים ב-Topics ובאיזה אופן. אנחנו סבורים שזוהי גישה טובה יותר מאשר הערכה של חלק ה"לגיטימיות" של אתר בפונקציונליות של Topics API עצמו. |
| ההשפעה על אותות מאינטראקציה ישירה | אותות של נושאים יכולים להיות חשובים מאוד, וכתוצאה מכך לפגוע בערך של אותות אחרים שמבוססים על תחומי עניין מאינטראקציה ישירה. | אנחנו מאמינים שפרסום המבוסס על תחומי עניין הוא תרחיש חשוב לדוגמה באינטרנט, ו-Topics API נועד לתמוך בתרחיש הזה. כפי שתואר למעלה, בעלי עניין אחרים בסביבה העסקית הביעו חששות בנוגע לכך ש-Topics API לא שימושי מספיק כדי לספק ערך. בכל המקרים, שיפור הטקסונומיה הוא מאמץ מתמשך, ואנחנו מצפים שהטקסונומיה תשתנה עם בדיקות של המערכת האקולוגית וכמות המידע שמתקבלת מהם. |
FLEDGE
| נושא המשוב | סיכום | תגובה של Chrome |
| מכרז של FLEDGE | איך שולחים נתונים בפלטפורמת SSP אל Google Ads כדי להגיש הצעות מחיר על מכרז FLEDGE. | חברות המשתתפות בבדיקות נהוג לפרסם מסמכים על תוכניות הבדיקה שלהן ולעבוד יחד במידת הצורך.
עבדנו עם ה-CMA כדי לפתח את הגישה שלנו לבדיקות כמותיות, ואנחנו תומכים בכך ש-CMA תפרסם הערה לגבי תכנון ניסויים כדי לספק מידע נוסף למשתתפים בשוק שמתכננים להשתתף בניסויים והזדמנות להגיב על הגישות המוצעות. צוות Ad Manager פרסם מסמכים על מפיצים שרוצים לבדוק את FLEDGE עם בעלי תוכן דיגיטלי שמשתמשים ב-Ad Manager כשרת המודעות שלהם כאן. יש פירוט טכני נוסף שמפורט כאן. |
| FLEDGE ב-Fenced Frames בתצוגת עץ | פריימים מגודרים מאפשרים לבצע בדיקה פחות מגבילה, ובעתיד לא מוגדר מגבילים יותר. ציר הזמן הלא ידוע הזה מאתגר את המערכת האקולוגית. | חברות יכולות לבדוק את FLEDGE עם Fenced Frames כבר היום. כדי לספק אפשרות הצטרפות קלה יותר, חברות יכולות להטמיע קודם את FLEDGE. אחרי ההטמעה של FLEDGE, הם יכולים לבדוק את Fenced Frames עם העיצוב של FLEDGE. |
| מדיניות טיפול בנתונים | מהי מדיניות הטיפול בנתונים של קבוצות של אינטרסים או FLEDGE? | בעיצוב של FLEDGE, כל הנתונים ששמורים בקבוצות של תחומי עניין, או לגבי האנשים בקבוצות של תחומי העניין, נשארים במכשיר. אף אחד מהנתונים האלה לא נשלח לשרת של Google.
חלק מאמצעי ההגנה על הפרטיות ש-Chrome מתכנן עבור FLEDGE אכן כרוכים באינטראקציה עם שרת k-anonymity שמופעל על ידי Google. האינטראקציה הזו תוכננה בקפידה כדי למנוע שיתוף מידע על המשתמשים ולהתנהל בסביבת ביצוע אמינה (TEE) כדי להבטיח שוויון של המידע בכל סביבת הפרסום. \ Google התחייבה ל-CMA לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא יעוות את התחרות על ידי העדפה עצמית של העסק של Google, ותביא בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי התוכן הדיגיטלי והמפרסמים. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה. |
| כללי מדיניות בנושא גיל | איך Chrome מוודא שהקהלים שנוצרו על ידי FLEDGE עומדים בהגבלות גיל? | בעלי תוכן דיגיטלי ומפרסמים יכולים להעריך אם הקהלים שהם יוצרים באמצעות FLEDGE מצייתים לדין החל. כדי להגביר את ההגנה על המשתמשים, גם במהלך תקופת הבדיקה, ממשקי ה-API של ארגז החול לפרטיות לא יהיו פעילים למשתמשים שמחוברים ל-Chrome אם הגיל שמשויך לחשבון שלהם הוא מתחת לגיל 18. (עבור משתמשים שאינם מחוברים לחשבון, Chrome לא אוסף אותות פרופיל שיאפשרו לדפדפן להסיק את גיל המשתמש). |
| שירותי מפתח/ערך של FLEDGE | מידע ברור יותר לגבי השירותים שמספקים מפתח/ערך של FLEDGE, למשל מספר המפתחות ובאיזו תדירות ניתן לעדכן אותם. | לחברות שמשתמשות ב-FLEDGE יכולות להיות כמה מפתחות שהם יכולים להכיל ב-RAM. לפרטים נוספים, ניתן לעיין בהסבר כאן.
אנחנו פועלים כדי לספק דרך מהירה יותר לשינוי נתונים ולקבל הצעות מחיר בהתאם לדרישות. |
| בדיקה | קשה לבדוק את FLEDGE ב-Google Ads | במסמכי התיעוד של Google Ads מוסבר איך להשתתף בצורה הטובה ביותר בגרסת המקור לניסיון ולהריץ אותה. |
| ממשק API של שירותי בידינג ומכרזים | מה הכיוון של Google לגבי ה-API של שירותי הבידינג והמכרזים? האם הוא יקבל עדיפות מעל או מתחת ל-FLEDGE של דפדפן Chrome במכרזים של מכשירים? | אנחנו עדיין מחויבים לעיצוב הנוכחי של FLEDGE בבידינג במכשיר. שירותי הבידינג והמכרזים הוצעו לבדוק פתרונות אפשריים לתמיכה בקבוצת משנה של תרחישי שימוש שבהם כוח החישוב או מהירות הרשת של המכשיר עשויות להיות מוגבלות. |
| דיווח מצטבר | בקשה לתמיכה בדוחות מצטברים על סמך כל האותות הזמינים ליצירת הצעת מחיר. | אנחנו מתכננים לשתף עוד בנושא באופן ציבורי בקרוב. |
| מודעות לפי הקשר | הצגת מודעות לפי הקשר באמצעות FLEDGE. | בדקנו את האפשרות הזו, ולכן, מהסיבות שמפורטות בדיון הזה, לא מומלץ כרגע להשתמש ב-FLEDGE למודעות לפי הקשר. |
| בדיקה בעולם האמיתי | הנחיות לבידוד של FLEDGE מקובצי cookie של צד שלישי לצורך בדיקות בעולם האמיתי. | אנחנו בודקים דרכים לספק אוכלוסיות לבדיקה.
עבדנו עם ה-CMA כדי לפתח את הגישה שלנו לבדיקות כמותיות, ואנחנו תומכים בכך ש-CMA תפרסם הערה לגבי תכנון הניסוי כדי לספק מידע נוסף למשתתפים בשוק והזדמנות להגיב על הגישות המוצעות. |
| בדיקה של FLEDGE ו-Attribution Reporting API | מהי הדרך הטובה ביותר להטמיע את Attribution Reporting API באמצעות FLEDGE? האם מומלץ להפריד בין FLEDGE לבין Attribution או לבצע את הבדיקה יחד? | בסופו של דבר נתמוך בבדיקה של FLEDGE ושל Attribution Reporting API כפתרון משולב, אבל מומלץ למפתחים לבדוק קודם את Attribution Reporting API באופן עצמאי ולאחר מכן עם FLEDGE, לאחר השלמת השילוב. |
| החשיפה של הצעת המחיר | בקשה לערפל את המחירים של הצעות המחיר. | אפשר להגדיר נקודות עצירה ב-'generateBid() ' או ב-'scoreAd() ' כדי לגשת לערכים של הצעות המחיר מכלי הפיתוח. צוות Chrome הביא בחשבון את וקטור ההתקפה הצר שהועלה במשוב הזה על FLEDGE. עם זאת, המודלים של האבטחה והפרטיות של Chrome מחשיבים משתמשים כאמינים עושים כל מה שהם רוצים באמצעות מידע במכשיר שלהם, ולכן אין דרך מעשית להסתיר את נתוני הצעות המחיר לפי הבקשה. |
| בקשות לתיעוד | תיעוד ודוגמאות לבדיקה בסביבה עסקית פעילה. | אנחנו מעריכים את העובדה שהחומרים הנוכחיים שלנו הועילו למפתחים, ומחויבים לספק חומרים נוספים במהלך השבועות והחודשים הקרובים כדי שמפתחים יוכלו להמשיך להבין כיצד הטכנולוגיות החדשות יכולות לעבוד בשבילם.
בנוסף, ערכנו שעות פעילות ציבוריות של המפתחים החיצוניים כדי לשתף שיטות מומלצות והדגמות ומפגשי שאלות ותשובות עם נציגים של מוצרים והנדסיים, כדי לאפשר דיון בזמן אמת או העלאת שאלות. |
| API לצבירה פרטית | רוצה לקבל מידע נוסף על Private Aggregation API? | יש הודעת הסבר ציבורית שכוללת את המידע העדכני ביותר שאנחנו יכולים לשתף בשלב הזה. נוסיף מסמכים נוספים לאחר פיתוח ה-API וההגדרה שלו לפי תרחישים לדוגמה. |
| זמן האחזור של הנתונים | האם אחזור הנתונים בשרת של מפתח/ערך FLEDGE יתבצע בזמן אמת? | יכול להיות שיהיה חוסר פעילות קטן לפי סדר הדקות, ולא בשעות, עד שהשרת יוכל להחזיר נתונים מעודכנים לשאילתות, כמו שמוסבר בבעיה פתוחה ב-GitHub. אנחנו מעוניינים גם לקבל משוב ממפתחים. |
| שירותי בידינג ומכרזים | האם מחירי הצעות המחיר יוסתרו מהמשתמש אם נעשה שימוש בשירותי בידינג ומכרז (B&A)? | בגישה של B&A בצד השרת, המחיר של הצעת המחיר הבודדת לא מוצג למשתמש, כי הבקשה להצעת מחיר מועברת משירות המכרזים של SSP ישירות לשירות המכרז של פלטפורמת ה-DSP, ולכן היא לא זמינה יותר בדפדפן.
עם זאת, הצעת המחיר שזכתה במכרז עדיין תוצג לדפדפן (הסבר מפורט למעלה, בנוגע לבקשות לערפול הצעות מחיר). |
| שירותי בידינג ומכרזים | איך נוכל לטעון שירותי מכרזים ומתן הצעות מחיר לאיזון? | בשלב זה אין לנו הנחיות כלשהן לגבי איזון עומסים, אבל זהו שיקול חשוב מבחינת הביצועים והפרטיות גם יחד. נספק פרטים נוספים בעתיד. |
| מגבלות FLEDGE | לשלוח בקשה להגדלת מכסת משך הזמן של joinAdInterestGroup מ-30 ימים ל-90 ימים. | לדעתנו מסגרת הזמן של 30 יום לשמירת נתונים תואמת לממשקי API אחרים לפרסום של ארגז החול לפרטיות, כמו מגבלת 30 הימים בדוחות השיוך (Attribution) ותקופת המבט של 3 שבועות לאחור ב-Topics API. מסגרת הזמן הזו עונה גם על הצרכים של טכנולוגיות הפרסום וגם של המשתמשים בנוגע לפרטיות.
עם זאת, נשמח לקבל משוב נוסף כדי שנוכל להמשיך לדון בנושא כאן. |
| נפח אחסון משותף ב-FLEDGE | האם אפשר להשתמש ב-Shared Storage API ב-FLEDGE? | אנחנו מתכוונים לתמוך ב-Shared Storage API ב-FLEDGE בעתיד, ואנחנו פועלים כדי להפוך אותו לזמין בגרסת מקור לניסיון שתפורסם בקרוב. |
| בקרת תדירות לפי קליקים | האם אפשר להגדיר מכסת תדירות לפי קליקים (לא זכיות) ב-FLEDGE? | FLEDGE מציין ש-Fenced Frame יכול לקרוא ל-navigator.leaveAdInterestGroup() (ללא פרמטרים) כדי לעזוב את קבוצת תחומי העניין שגרמה להצגת המודעה. ניתן לבצע את הקריאה הזו בפעם הראשונה שמתבצע קליק כדי למנוע הצעות מחיר בעתיד, כסוג של מכסת תדירות. נכון לעכשיו, אי אפשר להגדיר מכסה אחרי יותר מקליק אחד. |
| FLEDGE ב-Fenced Frames בתצוגת עץ. | אין אפשרות לדווח על קליקים באמצעות דיווח על מודעות מסוג Fenced Frame, אם הם מתרחשים ב-Fenced Frame. | פרסמנו הצעה לפתרון הבעיה כאן. |
| מדידה | נדרשת הדרכה באיסוף נתונים על זמן האחזור ממגישי הצעות המחיר במכרז של FLEDGE. | אנחנו פועלים לפרסום מסמך למדידת ביצועים בקרוב. |
| דוחות | איך תטופל הדיווח על FLEDGE? | הדוחות של FLEDGE על זכייה, תוצאת מכרז, אירוע, למשל קליקים יהיו זמינים דרך ממשקי FLEDGE API כמו reportResult() . בדיווח עם ההמרות מהמודעות, השילוב עם Attribution Reporting API לא יהיה תלוי ב-FLEDGE, אבל מתקיימים דיונים מתמשכים עם הסביבה העסקית לגבי גישות אפשריות.
ניתן להשתמש ב-Private Aggregation API לדיווח על תוצאות במכרזים מתוך סביבות הביצוע המבודדות. ההסבר מופיע כאן. |
| גודל קבוצת תחומי עניין | האם יש לטכנולוגיות פרסום דרך לבדוק את הגודל של קבוצת תחומי עניין (כלומר, מספר המשתמשים בקבוצה)? | החברות בקבוצות לפי תחומי עניין נשמרת על ידי הדפדפן, במכשיר של המשתמש ולא משותפת עם ספק הדפדפן או עם אף אחד אחר.
עם זאת, באופן תיאורטי, בעלים של קבוצת תחומי עניין יכול לעקוב אחר כל קריאה ל-navigator.joininterestgroup(...). מעקב אחר השיחה הזו אינו מבטיח את הגודל המדויק של IG (מכיוון שמשתמשים יכולים לעזוב את הקבוצה בכל עת), אך הוא נותן לבעלים גבול עליון ואומדן של הגודל שלו. |
| ביצועים | האם קוד JS/WebAssembly של בידינג נאסף בכל מכרז? | קוד JS/WebAssembly של בידינג נאסף פעם אחת בכל מכרז. |
| ביצועים | מה ההיקף של BiddingDurationMsec? | BiddingDurationMsec כולל/ה הידור של זמן הסקריפט. הוא לא כולל את זמן ההורדה, את זמן הידור Wasm, את זמן הרשת, אחזור הזמן משרת ערכי מפתחות או כל דבר שקודם להידור של JS. |
| התאמה אישית | האם ניתן לעדכן את רכיב המודעה כך שהוא יותאם אישית למשתמש? | ניתן לעדכן את רכיב המודעה כאשר קבוצות תחומי עניין מתעדכנות על ידי המתקשר בעת קריאה ל-joinInterestGroup או כש-Chrome מבצע קריאה אל DailyUpdateURL. פעולה זו מאפשרת למבצע הקריאה החוזרת לעדכן את רכיב המודעה על סמך ידע של המשתמש מהאתר הנוכחי או על סמך מידע אנונימי (k-anonym) בהתאמה.כאן אפשר למצוא את ההצעה המקורית של Turtledove ברמת המוצר, שכוללת ניתוח כלשהו של RTB House על ההשפעה על מדדי ליבה של התרחיש לדוגמה של ההמלצה. |
| קבוצת אינטרס | האם בעלים של קבוצת אינטרסים יכול להסיר באופן מותנה משתמשים מסוימים? | חברות בקבוצת תחומי עניין נשמרת רק בדפדפן של המשתמש וניתן להסיר אותה רק בצד המשתמש (למשל, על ידי ניקוי נתוני האתר).
עם זאת, בעלים של קבוצת תחומי עניין יכול לקרוא ל-navigator.leaveAdInterestGroup() (עם לוגיקה מותנית מסוימת), אם המשתמש חוזר לדף שבשליטתו של הבעלים של קבוצת תחומי העניין. |
| ביצועים | איך מודדים את הביצועים של generateBid? | אפשר למדוד את זמני ההידור והביצוע באמצעות BiddingDurationMsec. אפשר למדוד את זמן ההורדה באמצעות הכתובת chrome://net-export. בגרסאות האחרונות של Chrome, זמן ההידור והביצוע יופיע בכרטיסייה 'ביצועים של כלי הפיתוח'. |
| עדכונים לגבי תדירות של קבוצות של תחומי עניין | מה תהיה התדירות של העדכון של קבוצת האינטרס מהדפדפנים? | לגבי קבוצות של תחומי עניין שלא עודכנו ב-24 השעות האחרונות, Chrome מנסה לעדכן אותן כשמתבצעת קריאה ל-navigator.updateAdInterestGroups() , או אחרי ההזדמנות להשתתף במכרז. הסבר נוסף זמין כאן. |
| ספקים של שירותי צבירה | מתי תהיה תמיכה בספקי ענן אחרים בשירות הצבירה? | כרגע אין לנו עדכונים לגבי השעות הספציפיות, אבל נפרסם פרטים נוספים ברגע שיהיה לנו עדכון. בשלב הזה, רק שירות AWS עומד בדרישות האבטחה של שירות הצבירה. |
| ציר הזמן לבדיקות של FLEDGE | כמה זמן תימשך הבדיקה של FLEDGE ב-BYOS? האם יהיה מספיק זמן לעבור ממודל BYOS למודל שמבוסס על TEE? | כדי להבטיח שלסביבה העסקית יהיה מספיק זמן לבדיקה, אנחנו לא צופים שנדרוש את השימוש ב-TEE עד זמן מה לאחר ההוצאה משימוש של קובצי cookie של צד שלישי. לפני שהמעבר ייכנס לתוקף, נספק הודעה משמעותית למפתחים שיתחילו בבדיקות ובהטמעה. אין לנו כרגע עדכונים נוספים, אבל נשתף אותם כשיהיו לנו. כאן אפשר למצוא את המידע העדכני ביותר. |
| מגבלת גודל הנתונים | מהי מגבלת גודל הנתונים של Wasm בפונקציית הבידינג. | קיימת דרישה שעדכונים לקבוצת תחומי עניין לא יכולים לגרום לקבוצת תחומי עניין שחורג מ-50kb, כפי שמתואר כאן. עם זאת, מגבלת גודל הנתונים ל-Wasm עדיין לא מוגדרת ולכן נשמח לקבל מידע בנושא. |
| אותות של מכרזים | האם יהיה מבנה נתונים סטנדרטי ל-AuctionSignals? | האפשרות הזו עדיין לא מוגדרת, אבל נשמח לקבל משוב. |
| שאילתה לשרתים של טכנולוגיות פרסום | האם ניתן להריץ שאילתות על נתונים של שרת פרסום דיגיטלי בזמן אמת משרת K/V? | לא. שרת K/V פועל במודל אמון שאוכף "ללא רשת, גישה לדיסק, טיימרים או רישום ביומן" כדי למנוע דליפה של נתוני משתמשים. פרטים נוספים זמינים בהסבר על מודל האמון כאן. |
| תדירות העדכון של רכיבי המודעות | בשלב זה לא ניתן לעדכן את השדה adComponents (רכיבי מודעות) (כרגע רק בהגדרת IG) לפי היסטוריית הגלישה של המשתמש | המטרה של ארגז החול לפרטיות היא לתמוך בצרכים של הסביבה העסקית של האינטרנט ללא מעקב באתרים שונים, כלומר למנוע גישה להיסטוריית הגלישה. מומלץ להשתמש בחלופות כמו Topics. |
| תוצאות מכרז | האם יש לטכנולוגיות הפרסום דרך לדעת מהם התעריפים הזוכים במכרזים? | תוצאת המכרז מדווחת באמצעות קריאה לפונקציות reportResult() וה-reportWin() בקוד המכרז שסופק על ידי המוכר והקונה הזוכה, בהתאמה, כך שלכל אחת מהן יש הזדמנות לבצע רישום ביומן ודיווח על תוצאת המכרז. |
| (מדווח גם ברבעון השני)
תמיכה בטירגוט שלילי לקבוצת תחומי עניין |
ממשק API התומך בטירגוט לפי קבוצות של תחומי עניין שליליים: הצגת מודעות רק אם משתמש לא משתייך לקבוצה של תחומי עניין. | עדכון לרבעון 3:
שיתפנו הצעה חדשה ואנחנו מעוניינים לקבל משוב. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה של Chrome |
| דרישות הארכה | הסרה של הגבלות של מדיניות ההרשאות במהלך / עבור ה-OT בלבד. | ניתן לעיין בשינויים שצוינו לגבי מדיניות ההרשאות במהלך הבדיקה. המטרה הבסיסית של בעלי העניין, ששינוי זה מתייחס אליה, היא לאפשר לפלטפורמות DSP לבדוק את ה-API בכמות גדולה יותר של מסגרות iframe ממקורות שונים. במקור, פלטפורמות DSP היו צריכות לתאם עם בעלי אתרים/פלטפורמות SSP כדי לוודא שהוגדרה מדיניות ההרשאות הנכונה לבדיקת ה-API במסגרות iframe ממקורות שונים. עם זאת, לאחר השינוי הזה, פלטפורמות DSP יוכלו לקרוא ל-API כברירת מחדל, ופלטפורמות SSP/בעלי תוכן דיגיטלי יוכלו להשבית את ה-API במידת הצורך במהלך גרסת המקור לניסיון. |
| רעש | משוב על כך שרמת ה"רעש" גבוהה מדי ושמשפיעה על מידת התועלת של הדיווח. | נשמח לקבל משוב בנוגע לרעש. נשתמש בו כדי לקבוע איך להגדיר פרמטרים מסוימים שקשורים לרעש. אנחנו גם מתכננים לפרסם עוד משאבים, כלים ומסמכים אחרים שיעזרו לבודקים בנושא. |
| המרות חוצות-דומיינים | איך לעקוב אחר המרות חוצות-דומיינים, למשל כשמדובר ב-2 יעדים או יותר? | אנחנו דנים כרגע בשאלה הזו ומחפשים משוב בנושא. |
| דרישות לניפוי באגים | לבקש ממך לאפשר למפתחים לבדוק את תקציב הפרטיות שנותר בזמן פריסה או בדיקה של דוח סיכום? | אפשר לעקוב אחרי בקשת התכונה הזו. |
| מדיניות השימוש ב-API | מתן משוב לגבי כללי מדיניות שיכולים להשתמש ב-API נתון, בהתאם להגבלות על פעולות כמו יצירה של טביעת אצבע דיגיטלית (fingerprinting) | זהו רעיון מעניין מאוד ונשמח לשתף פעולה עם ספקי דפדפנים אחרים ועם הסביבה העסקית הרחבה יותר של האינטרנט. |
| הגדרת תפוגה בדוח ההמרות | בקשה לתמיכה במסנן / תפוגה של דוח למשך פחות מ-24 שעות. | ביקורים ברמת השעה מהווים מקור לחששות בנוגע לפרטיות, מאחר שהם מאפשרים לטכנולוגיות הפרסום לדעת באיזו שעה בדיוק המשתמש מבקר באתר של המפרסם. תפוגת היום ברמת היום תאפשר לטכנולוגיית המודעות לסנן חשיפות לא חוקיות בלי לקבוע באיזו שעה המשתמש נכנס לאתר. |
| תפוגה של אסימון OT | בקשה להארכת התוקף של אסימוני ה-OT הקיימים כדי לצמצם את התקורה התפעולית. | אנחנו מבינים שיש לחדש את האסימונים ואנחנו פועלים כדי להקל על המפתחים ולספק הודעה נוספת. |
| תמיכה אזורית | שירות הצבירה לא תומך כרגע בכל האזורים. | זוהי מגבלה נוכחית על גרסת הבטא. אנחנו צופים תמיכה באזורים נוספים במהלך התקדמות הבדיקה, אבל אין עדיין לוח זמנים ברור לכך. |
| עיכוב בדיווח ברמת האירוע | עיכוב של יומיים עד 30 ימים בדיווח ברמת האירוע עשוי להיות ארוך מדי לתרחישי שימוש מסוימים. | שיתפנו כאן הצעה לאפשר לטכנולוגיות פרסום לקבוע מתי דוחות ברמת האירוע יישלחו עם תאריך תפוגה. ברירת המחדל היא 30 יום, אבל אפשר להגדיר אותה לזמן קצר יותר. |
| (מדווח גם ברבעון השני)
ייחוס לכמה נקודות מגע |
אפשר להשתמש בשיוך לכמה נקודות מגע, כמו במכשירים שונים או באפליקציות שונות. | עדכון לרבעון 3:
השיטות הנוכחיות של שיוך לכמה נקודות מגע מחייבות קישור דטרמיניסטי בין חשיפות המשתמש (ולכן גם הזהות שלו) באתרים שונים. כתוצאה מכך, הפונקציונליות הזו במתכונתה הנוכחית לא תואמת ליעדים של ארגז החול לפרטיות, שמטרתו לתמוך בתרחישי שימוש מרכזיים במודעות ללא מעקב באתרים שונים. |
| ציר הזמן לשילוב של FLEDGE ודיווח שיוך (Attribution) | מה לוח הזמנים לשילוב של FLEDGE ו-Attribution Reporting API? | אין לנו כרגע עדכונים לשתף, אבל נפרסם מידע נוסף ברגע שנוכל להתחייב ללוח זמנים ספציפי. |
| סוגי טריגר מרובים | כדאי לבקש יותר גמישות ברישום לטריגרים. | אנחנו מציעים מערכת ביטול כפילויות ל-API נצבר |
| מדידה | לבקש לקבל נתוני מדידה לגבי ביצועים טובים של מלאי. | אנחנו מעריכים את המשוב ומבקשים הבהרות נוספות לגבי התרחישים לדוגמה בבקשה הזו. |
| תפוגת התוקף של ההמרה | בקשה לתמיכה בסטטוס תפוגה של המרה בתג טריגר במקום בתג המקור בלבד. | אנחנו מעריכים את המשוב ומבקשים הבהרות נוספות לגבי התרחישים לדוגמה בבקשה הזו. |
| דיווח על כמות גדולה של דוחות | לבקש מדידה נוספת בדוחות על קבוצות. | המשוב חשוב לנו בזמן שאנחנו ממשיכים לחשוב על ההשפעה של שירות הצבירה. אנחנו מעוניינים לשמוע איך טכנולוגיות פרסום חושבות על קיבוץ דוחות ועל התדירות הצפויה שלהם, וגם משוב על השינויים באסטרטגיית הקיבוץ לאורך השנה. |
| Epsilon | מתי ייקבע הערך של אפסילון? | אנו פועלים בשיתוף עם בודקי המערכות האקולוגיות כדי להשלים את הגדרת הערך אפסילון והאופן שבו הוא יוטמע ב-Google Analytics. הערך יהיה גלוי לציבור, יחד עם הדיון שהוביל להחלטה לגבי הערך. אם יש לכם משוב, תוכלו לפרסם אותו בבעיה הזו של GH. |
הגבילו מעקב סמוי
הפחתת מידע בסוכן משתמש
| נושא המשוב | סיכום | תגובה של Chrome |
| תלות של הפרויקט בפריסה | טיפול בהתאם ליחסי תלות של הפריסה של סוכן המשתמש (SUA). | השקנו את "שלב 4", כלומר צמצום של גרסאות משניות ל-100% ממשתמשי Chrome בגרסאות 101 ואילך. כאן אפשר לראות את העדכון. |
| בדיקה | בקשה להארכת תקופת הניסיון של הפחתת המקור של סוכן המשתמש מ-Meta. | הארכנו את גרסת המקור לניסיון, וקיבלנו הרשאה להסיר מגבלות תנועה כדי לכלול אתרים גדולים יותר. מגבלות התנועה הקלות חלות על כל אתר, גדול כקטן. |
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב | סיכום | תגובה של Chrome |
| (מדווח גם ברבעון השני)
חששות לגבי מניעת הונאה / התנהלות פוגעת |
תכונות מסוימות שעלולות ללכת לאיבוד באמצעות UA-CH: מעקב אחר הפניות מחדש של קליקים וקליקים שמקורם בתרמית. | עדכון לרבעון 3:
קיבלנו משוב חיובי מחברות שדיווחו שהן לא משפיעות לרעה על הערוצים שלהן למניעת הונאות (התוצאות נמצאות כאן וכאן). הצוות ממשיך לחקור את הבעיות הפוטנציאליות האלו מול בעלי עניין בתחום מניעת הונאה ומדידה. |
| מדיניות הרשאות | האם מדיניות ההרשאות נשמרת במטמון? | מדיניות ההרשאות לא נשמרת במטמון כמו שמוסבר בבעיה הזו ב-GitHub. |
Gnatcatcher (WIP)
| נושא המשוב | סיכום | תגובה של Chrome |
| תרחישים לדוגמה של מיקום גיאוגרפי | Gnatcatcher עשוי למנוע שימוש בתרחישים לגיטימיים של מיקום גיאוגרפי בעתיד, כמו התאמה אישית של תוכן על סמך מיקום גיאוגרפי. | אנחנו עובדים עם בעלי עניין כדי להבטיח ש-Chrome ימשיך לתמוך בתרחישים לגיטימיים של שימוש בכתובות IP. |
חיזוק גבולות הפרטיות בין אתרים
דומיינים של צד ראשון
| נושא המשוב | סיכום | תגובה של Chrome |
| מדיניות | חשש ש-FPS לא תואם לתנאים של התחייבויות ה-CMA לגבי "החקיקה החלה להגנה על נתונים", על סמך תקנת ה-GDPR שאין בה הגבלה על מספר האתרים בכל קבוצה, ואילו ב-FPS קובעים הגבלה של 3 אתרים. | Google התחייבה לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא יעוות את התחרות על ידי העדפה עצמית של העסק של Google. כמו כן, Google התחייבה להביא בחשבון את ההשפעה על התחרות בפרסום בדיגיטל, בעלי התוכן הדיגיטלי והמפרסמים, וכן על ההשפעה על תוצאות הפרטיות ועל ציות לעקרונות ההגנה על נתונים, כפי שהוגדרו בחקיקה החלה להגנה על נתונים. הבעיה שצוינה לא חושפת מידע על חוסר תאימות לתקנת ה-GDPR. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה. פרטים נוספים מופיעים בקטע 'שינויים בתגובה למשוב' שבהמשך. |
| משאבי עזרה | אפשר לבקש דוגמאות נוספות ולעדכן הסברים קיימים. | הדוגמאות בהסברים שלנו נמצאות בבדיקה. נבהיר או נסיר אותן לפי הצורך. |
| שיתוף העדפות | הצעה להגדיר העדפות לגבי אותן קבוצות צד. | אנחנו מקבלים בברכה את המשוב ודנים ברעיון כאן. |
| אכיפה | תהליכי אכיפה שקופים עלולים לגרום לניצול לרעה של גורמים זדוניים. | אנחנו מעריכים את המשוב ומעורבים באופן פעיל בשיחה עם בעלי עניין ב-GitHub (תוך שקלול נקודות שהועלו בבעיה הזו ומנסים לשלב הצעות שהועלו בנושא הזה) ובפורומים אחרים כדי להעריך את הסיכון ולזהות מיטיגציות פוטנציאליות. |
| בעלות משותפת | הצעה להצהרה על בעלות משותפת בפורמט שמחשב יכול לקרוא. | אנחנו מברכים ומודים לך על המשוב להצעה שלנו. |
| בעלות על תת-דומיינים | האם תת-דומיינים שונים עם בקרי נתונים שונים, מדיניות פרטיות שונה או מופעלים על ידי ישויות שונות, צריכים להיות חלק מאותה קבוצה של דומיינים של צד ראשון? | על סמך משוב, אנחנו מתכננים להסיר את התרחיש הנפוץ של שימוש ב-eTLD. |
| מניעת ניצול לרעה | רוצה לקבל פרטים נוספים על האמצעים לצמצום הבעיה? | ניהול התהליך נמצא בשלבי בדיקה ואנחנו נפרסם פרטים נוספים בחודשים הקרובים. |
| וקטור התקפה פוטנציאלית | ניתן להשתמש בקבוצה המשויכת מטעה לדפים שניתן למצוא בקלות כדי להפנות תנועה לדפים אחרים שמוצגים באופן מטעה בתור דפים בלתי תלויים. | אנחנו אוספים באופן פעיל דיווחים מהציבור ובוחנים דרכים אפשריות לטיפול בבעיה הזו. |
| הגדרת אימות | אימות הקבוצה באמצעות כללי מדיניות נפוצים שניתנו בהסכמה. | חברים שונים בקהילת תקני האינטרנט ובסביבה העסקית הרחבה יותר ציינו כי הדבר בלתי אפשרי. |
| מגבלת דומיינים | צריך לשלוח בקשה להרחבת מספר הדומיינים המשויכים. | אנחנו דנים במגבלת הדומיינים ב-FPS, ונשמח לקבל משוב נוסף מהקהילה לגבי מספר הדומיינים המשויכים שנדרשים לתרחישים לדוגמה. |
| אינטראקציית שירות של תת-קבוצה | חשש בנוגע לשירות ולאינטראקציה הקשורה לקבוצת המשנה. | אנחנו מעריכים את המשוב שלך, ונבדוק אם התכונה הזו ברורה יותר במפרטים עתידיים. |
| (מדווח גם ברבעון השני)
שיפור הפרטיות |
אתרים רבים מדי באותה קבוצה עשויים להוביל לתוצאות הדומות לקובצי cookie של צד שלישי. | עדכון לרבעון 3:
בהצעה האחרונה מוצגת מגבלה של שלושה דומיינים לקבוצת המשנה ה'משויכת' (שאינה כוללת דומיינים ברמה העליונה עם קוד מדינה (ccTLD) ודומיינים של שירותים). Chrome פועל בשיתוף עם הסביבה העסקית כדי לקבוע אם המגבלה הזו מתאימה. |
| (מדווח גם ברבעון השני)
דרישות נפוצות של מדיניות פרטיות |
לא ניתן לשמור על מדיניות פרטיות משותפת לכל המוצרים, וסמכויות שיפוט שצריכות להיות חלק מאותה קבוצה. | עדכון לרבעון 3:
מדיניות פרטיות נפוצה כבר לא מחייבת להיות חלק מאותה קבוצה. |
ממשק API של Fenced Frames
| נושא המשוב | סיכום | תגובה של Chrome |
| למה כדאי להוסיף רכיב חדש במקום מאפיינים במסגרות iframe? | שאלה לגבי הצעה מסוג Frenced Frame במקום הצעות iFrame קיימות. | נשמח לקבל את המשוב ונשמח לקבל רעיונות איך למזג את המצב הנוכחי, כפי שמתואר כאן. |
| תצפית על צומת במסגרות מגודרות | שאלות בנוגע לניראות של מידע בתוך Fenced Frame. | במהלך דיון פעיל ובמהלך הזמן להוספת תגובות במסמך הזה וב-GitHub. אנחנו מזמינים את השותפים לשתף איתנו תרחישים לדוגמה כדי להבין טוב יותר את אפשרויות התמיכה. |
| מלאי שטחי פרסום של מודעות וידאו ומודעות מותאמות | האם Fenced Frames תומך במלאי מודעות וידאו ו-Native? | מבחינת יכולות הפעלת סרטונים, Fenced Frames אינם שונים מ-iframes, ולכן היא לא מצוין במפורש בתיעוד ציבורי. אם נתקלת בבעיות במודעות וידאו, כדאי לשלוח משוב כדי שנוכל לבדוק את העניין לעומק. |
| חבילות אינטרנט | האם פרסום או רינדור של מודעות לפי חבילות אינטרנט יהיו דרישה בעתיד עם Fenced Frame x FLEDGE? | היעד לטווח הארוך הוא לתמוך בחבילות אינטרנט לעיבוד תוכן של מודעות בתוך מסגרת. עם זאת, היישום הנוכחי של FLEDGE אינו תומך בכך ומחייב רינדור של משאב HTML שאוחזר מ-renderUrl. |
| מאפייני הנכס | בקשה ל-render_url לתמיכה במאקרו עבור הגובה והרוחב של מיקום המשבצת, כדי שנוכל להגיב עם קריאייטיב בגודל מתאים | אנחנו דנים בנושא הזה כאן. |
ממשק API לאחסון משותף
| נושא המשוב | סיכום | תגובה של Chrome |
| שילוב עם FLEDGE | איך יתבצע השילוב בין אחסון משותף לבין FLEDGE? | למרות שכרגע אנחנו לא פועלים כך, אנחנו מעוניינים לבחון את הרעיון הזה כדי לוודא שנוכל להבטיח את השמירה של אמצעי ההגנה על הפרטיות. אנחנו ממליצים לגורמים המעוניינים לשלוח הצעות לתרחישים לדוגמה שבהם ההצעה הזו עשויה לתמוך במאגר github האחסון המשותף או במאגר github של FLEDGE. . |
| שמירת נתונים | ניקוי של נפח אחסון משותף מצמצם את השימוש בסוללה. האם הארכת תקופת השמירה או האפשרות למחוק מפתחות/ערכים ספציפיים נחשבות לחלופות? | אנחנו תמיד שואפים לאזן בין היתרונות של פרטיות המשתמשים לבין התועלת שניתן להפיק מהם. אנחנו פתוחים לשליחת משוב על התאמות, ומעודדים את השותפים לשלוח משוב נוסף ופרטים נוספים בזמן שהם בודקים את נפח האחסון המשותף. |
| אות שלילי | אות שלילי מ-Mozilla לגבי ההצעה לנפח אחסון משותף. | אנחנו מודים ל-Mozilla על בדיקה יסודית של ההצעה שלנו. בכוונתנו להגיב למשובים שלהם בעתיד הקרוב. |
צ'יפים
| נושא המשוב | סיכום | תגובה של Chrome |
| דרישה שחולקה | צריך להוסיף דרישה להתנהגות מפורשת במאפיין 'מחיצות' בקובצי cookie מהדומיין הנוכחי. | שוחחנו על כך בשיחה עם PrivacyCG, והסענו לנו לגבי הבעיה ב-GitHub עם הערות. אנחנו ממשיכים לעבוד עם דפדפנים, מפתחים וקהילת הפרטיות כדי להתאים התנהגות מסוימת ולציין אותה. |
| הטמעות מאומתות | CHIPS עשוי להשפיע על תהליך הכניסה הנוכחי של SSO, בגלל חלוקה למחיצות (partitioning) שונה שמשפיעה על הטמעות מאומתות. | אנחנו מודעים לתרחיש לדוגמה של הטמעות מאומתות, ואנחנו פועלים לבדיקת פתרונות. |
| מגבלת מחיצות של קובצי cookie | חשש: ייתכן שהמגבלה הנוכחית של 10 קובצי cookie לא תספיק לתרחישים מסוימים. | אנחנו מתחילים להוציא משימוש את המגבלה על מספר קובצי ה-cookie במגבלת זיכרון של 12Kb. כך אנחנו יכולים לטפל בחששות בנוגע למגבלת קובצי ה-cookie, וגם להבטיח שהביצועים וטביעת הרגל הפחמנית של הדפדפן לא ייפגעו. |
| ציר הזמן של תקופת הניסיון המקורית | כדי להרחיב את OT, צריך להסיר את הדרישה להגדרת גבולות של שם המארח. | הארכנו את תאריך היעד של תקופת המקור לניסיון, בעקבות המשוב שקיבלנו מהסביבה העסקית. |
| בדיקת המגבלות ב-Chrome | האפשרות לבדוק CHIPS ב-Firefox עקב המגבלה הנוכחית ב-Chrome. | היישום ב-Firefox שונה פחות או יותר באופן כללי, מגבלת קובצי ה-cookie ב-Chrome נמוכה יותר ו-CHIPS הוא מנגנון הצטרפות, אך Firefox מחולק למחיצות כברירת מחדל. |
| (מדווח גם ברבעון השני)
הטמעות מאומתות |
האם מצב הכניסה נשמר עם CHIPS? | עדכון לרבעון 3:
מצב הכניסה לחשבון לא נשמר כרגע, אבל זה לא התרחיש לדוגמה הנדרש עבור CHIPS. אנחנו מודעים לתרחיש לדוגמה של הטמעות מאומתות, ואנחנו פועלים לבדיקת פתרונות. |
FedCM
| נושא המשוב | סיכום | תגובה של Chrome |
| (מדווח גם ברבעון השני)
וקטור תקיפה אפשריים |
וקטורי תקיפה פוטנציאליים באמצעות עיטור קישורים והתקפות תזמון. | עדכון לרבעון 3:
עבדנו עם Mozilla כדי להגיע להבנה משותפת של האופן שבו יש לטפל בבעיית התזמון, והפרטים מופיעים כאן. אנו יוצרים כעת אבטיפוס של שינוי ארכיטקטוני זה ומצפים להפעיל ניסויים ברבעונים הקרובים. |
| ספקי זהויות | Account Chooser: ספק זהויות יחיד. מבקשים לאשר כמה ספקי זהויות. | עבדנו עם ספקי דפדפנים ו-FedID CG כדי להסביר איך לאפשר שימוש במספר ספקי זהויות והגענו לנוסחה ששווה לנסות. תיאור ההצעה מופיע כאן ואנו מצפים לפתח אבות טיפוס ולבצע ניסויים ברבעונים הקרובים. |
| בעיות ידועות עם Federation | בקשה לספירת מקרים שבהם איחוד עלול להיתקל בבעיות הוצאה משימוש של קובצי Cookie של צד שלישי. | ה-FedID CG כולל פריט עבודה שצריך למונה את הדרכים שבהן איחוד נקטע כאן וכאן. בנוסף, החברה יוצרת מטריצת החלטות למיפוי שברים בממשקי API של פלטפורמת Web Platform כאן. |
| פרמטר הכרזה | האם הפרמטר Nounce יכול להשפיע על תהליך הכניסה? | זה יכול להיחשב למעקב באתרים שונים, אבל אנחנו עדיין אוספים נתונים ומנתחים איך לטפל במקרים כאלה. |
| הסכמת המשתמש | קישור בין גורמים מסתמכים (RP) והסכמת משתמשים לכל מקור. | המפרט הזה לא יכול לקבוע איך מקורות באותו דומיין משתפים קובצי cookie. לפי המפרט, ניתן להעביר אסימון מזהה ממקור ה-IdP למקור של ה-RP, אבל ה-RP הוא זה שקובע אם לשמור את מצב הכניסה של המשתמש בקובץ cookie הנעול למקור היחיד הזה, או בקובץ cookie שמשותף עם מקורות באותו דומיין. |
| חשבון IDP
ניידות מידע |
אפשרות המשתמש להעביר מזהי IdP אם הוא בוחר בעת העברה בין שני ספקי זהויות (IdPs). | נראה שזה משהו שהמשתמש צריך לבצע ישירות בדף ההרשמה של ספק הזהויות החדש שלו, ולא דרך ה-FedCM API. |
| מחיקת החשבון | ביטול IdP לצורך מחיקת חשבון באמצעות ה-IdP. | הבקשה הזו לגבי התכונה פתוחה לקלט ובבדיקה. |
| הצהרה על זכויות יוצרים בממשק המשתמש | טענות לגבי היבטים של ממשק ספציפיים לדפדפן. | כדי לטפל בבעיה, יש לעיין בקטע משיכה. |
| בדיקת הפניה ל-IdP | IDP מחפש את הגורם המפנה של RP. | נוספה למפרט בדיקת הגורם המפנה של IdP. מידע נוסף זמין בקטע בקשת משיכה. |
| תהליך הכניסה | לבקש לבצע התאמה אישית של תהליכי הכניסה על סמך העדפות RP. | אנחנו מקדמים את הרעיון ודנים בו באופן פעיל. |
נלחמים בספאם ובהונאות
API ל-Trust Tokens
| נושא המשוב | סיכום | תגובה של Chrome |
| הונאה וניצול לרעה | כלים שמאפשרים לוודא שבוט לא הטעה את המנפיק כדי שיתן לו אסימון, ושבוט לא השתלט על אסימון שהונפק למשתמש אמיתי וכדי למנוע מבוטים להנפיק אסימונים זדוניים? | בוטים יכולים לקבל אסימונים ממנפיק, אבל אנחנו מעודדים את המנפיקים להגביל את התדירות שבה הם מנפיקים אסימונים ואת השיטות היעילות להנפקת אסימונים ולעדכן את לוגיקת ההנפקה שלהם, בזמן שגורמים זדוניים מנסים לעקוף אותם. סביר להניח שמנפיקים שאין להם לוגיקה מספיק חזקה להנפקת אסימונים ייפגעו בסביבה העסקית, ככל שאתרים יקבעו עדיפות, בהתאם למנפיקים חזקים יותר. |
| הונאה וניצול לרעה | האם יש דרך שבה מימוש אסימון Trust יוכל לציין שהוא יקבל אסימוני Trust רק מישויות ספציפיות? | כן, זה אפשרי. בקטע מימוש אסימון אמון בהסבר מוסבר איך זה עובד. |
| הונאה וניצול לרעה | האם יש דרך שבה מנפיק Trust Token יכול להגדיר רשימת מממשים ולא לאפשר לאף אחד אחר לממש אסימונים? | לא בשלב זה, אבל הצוות בודק את התרחיש לדוגמה. |
| ציר הזמן | מתי ה-Trust Token API יהיה זמין לכלל המשתמשים? | ברגע שנוכל להתחייב ללוח זמנים, נשתף מידע נוסף באופן ציבורי. |
| (מדווח גם ברבעון השני)
תקורה של תחזוקה |
לא ברור כמה זמן תהיה תמיכה בגרסאות פרוטוקול. | עדכון לרבעון 3:
כדי לאפשר מעבר חינני בין גרסאות, אנחנו מתכננים להוסיף עוד תמיכה בממשקי ה-API לתמיכה בכמה גרסאות בו-זמניות. עם זאת, אנחנו עדיין עובדים על מסגרת הזמן לתמיכה או להוצאה משימוש. |