דוח משוב – רבעון 1 של 2022

דוח רבעוני לרבעון הראשון של שנת 2022 שמסכם את המשובים שקיבלנו על הסביבה העסקית בנוגע להצעות של ארגז החול לפרטיות והתגובה של Chrome.

כחלק מההתחייבויות שלה לרשות התחרות והשווקים, Google הסכימה לספק באופן ציבורי דוחות רבעוניים לגבי תהליך המעורבות של בעלי עניין להצעות שלה במסגרת ארגז החול לפרטיות (ראו סעיפים 12 ו-17(ג)(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 יצר קשר עם קהלים רבים, ו-Chrome יפרסם שאלה נפוצה המאשרת כי הבדיקה תהיה זמינה בכל העולם. בנוסף, Chrome ימשיך לעדכן באופן קבוע לוחות זמנים ציבוריים תוך התייעצות עם ה-CMA.

הצגת מודעות ותכנים רלוונטיים

API / טכנולוגיה	נושא המשוב (דירוג לפי השכיחות)	סיכום שאלות וחששות	תגובה של Chrome
נושאים	שימושיות של נושאים רחבים	עלו חששות בנוגע לכך שטקסונומיית הנושאים בפירוט גס עשויה להיות לא שימושית מספיק לפרסום המבוסס על תחומי עניין.	נבדוק את התועלת של ממשק ה-API באמצעות בדיקות. Chrome מצפה שהטקסונומיה תשתנה על סמך תוצאות הבדיקה.
נושאים	טקסונומיה	בעלי עניין בענף מעוניינים שיהיה להם קל להשפיע על הטקסונומיה.	Chrome נשאר פתוח להזנת קלט בטקסונומיה. אנחנו ב-Chrome מעוניינים מאוד לקבל משוב על מודל הפיקוח לשינוי הטקסונומיה, ולדון באופן שבו גופים אחרים בתחום יכולים למלא תפקיד פעיל יותר בפיתוח ובשמירה על הטקסונומיה בטווח הארוך.
נושאים	שימושיות לסוגים שונים של אתרים	הועלו חששות בנוגע למידת התועלת שיש לאתרים האלה, בהתאם לרמת התנועה שהם מקבלים או למידת המיוחדות של התוכן שלהם.	נבדוק את התועלת של ממשק ה-API באמצעות בדיקות. ב-Chrome אנחנו מצפים שהטקסונומיה ופרמטרים אחרים ישתנו על סמך תוצאות הבדיקה. ייתכן שהתפתחות הטקסונומיה או הפרמטרים לא תדרוש שינויים שאינם תואמים לאחור. בנוסף, Chrome מצפה לקבל משובים ימשיכו להשפיע על ההתפתחות של Topics API אחרי ההוצאה משימוש של קובצי cookie של צד שלישי.
נושאים	המתודולוגיה לסיווג אתרים	ניתן לבקש שאתרים יוכלו לקבוע את הסיווג שלהם לפי נושאים או להשפיע על הסיווג שלהם.	Chrome בודק את הבקשה הזו, אבל הוא קיבל חששות (מקהילת דפדפנים ומפלטפורמות DSP) לגבי הסיכון הפוטנציאלי שאתרים יוכלו "לשחק את המערכת" כדי לטרגט משתמשים באופן שפוגע בפרטיות או כדי להפחית את הרלוונטיות של מודעות. Chrome מבקש משוב ושקלל שינויים אפשריים.
נושאים	אותות רועשים	הצגת נושא אקראי ב-5% מהזמן עלולה ליצור יותר מדי רעש או אות כוזב.	רעש הוא שיטה חשובה להגנה על פרטיות המשתמשים. בנוסף, נבדוק את רמות ה"רעש" לעומת מידת השימושיות של הנושאים במסגרת הבדיקות.
נושאים	הרשאות של צד שלישי בשליטת האתר	ניתן לבקש שאתרים יוכלו לבחור אילו טכנולוגיות פרסום יוכלו לקרוא ל-Topics API מהאתר שלהם.	היכולת המבוקשת הזו כבר נתמכת באמצעות מדיניות ההרשאות 'נושאי גלישה' כפי שמוזכרת במסביר.
נושאים	ההשפעה של Topics API על ביצועי הדפים	שאלות לגבי עיכובים בהצגת המודעה הראשונה כתוצאה מהסתמכות על Topics API	Chrome דן בתמיכה אפשרית ב-Topics בכותרות של בקשות HTTP כדי לשפר את הביצועים. אנחנו מסתמכים על בדיקות כדי לבדוק אם השינויים האלה נחוצים.
נושאים	פרטיות / מדיניות	שאלות לגבי המטרה של סינון תשובות לפי המתקשר אם צדדים שלישיים מסוימים ישתפו את הנושאים שלהם עם כל מי שמתקשר	על סמך משוב שקיבלנו ממשתמשים רבים בתחום, Chrome בחר בעיצוב הזה להגביל את הגישה למידע של אנשים שאחרת לא הייתה להם גישה למידע כזה. כמובן שבעלי תוכן דיגיטלי וצדדים שלישיים שמקבלים את Topics יכולים להחליט בעצמם איזה מידע הם ישתפו עם צדדים באתר שלהם. אם הם מבצעים שיתוף כזה, מומלץ ב-Chrome לפעול בשקיפות מול המשתמשים לגבי שיתוף כזה, ולהציע להם אמצעי בקרה.
נושאים	משאבי עזרה	התעניינות בתיעוד שכולל את הפרטים של מודל המסווג והטקסונומיה שבהם Chrome משתמש, כפי שעשית עבור FLoC, למשל התדירות שבה משתנים המסווג והטקסונומיה	ב-Chrome כבר נעשה שימוש בטקסונומיה של גרסאות המקור לניסיון, ומודל הסיווג שמסווג אתרים לפי Topics זמין בבסיס הקוד של Chrome כחלק מקוד הקוד הפתוח. כחלק מגרסת המקור לניסיון, Chrome שומר לעצמו את הזכות לבצע שינויים בכל אחד מהמשובים והתובנות לגבי אופן הפעולה שלו.
FLEDGE	מכסת תדירות	רצון לשלוט בתדירות לכל משתמש, בתוך קמפיין או בתוך קבוצת מודעות.	FLEDGE יתמוך במכסת תדירות במכירות פומביות במכשיר. יש בעיה פתוחה שהבעיה הזו מפורטת כדי לאפשר ל-FLEDGE לתמוך גם בקמפיינים מבוססי-הקשר או בקמפיינים למיתוג. ניתן להשתמש גם באחסון משותף, ממשק API נוסף בפיתוח ומכסות ספציפיות לאתר לצורך בקרות נוספות של מכסת התדירות.
FLEDGE	ההשפעה של FLEDGE על הביצועים	הועלו חששות לגבי ההשפעה הפוטנציאלית של מגישי הצעות מחיר שאינטנסיביות מבחינת החישוב שלהם במכרז של FLEDGE	Chrome מנהל דיונים פעילים עם מפתחים לגבי ההשפעה הפוטנציאלית על ביצועי האתר. ב-Chrome מוצגת הזדמנות לקבל מידע נוסף במהלך הבדיקה.
FLEDGE	בדיקה של FLEDGE עם תכונות אחרות	מתי ואיך תתבצע בדיקה עם תכונות אחרות (שרת אנונימי של k, שרתי ערך-מפתח וכו') תתבצע.	Chrome משיק באופן מכוון תכונות בשלבים בגרסת המקור לניסיון כדי להקל על הבדיקה. ב-Chrome חשוב להבהיר שחשוב להקפיד על בהירות לגבי ציר הזמן של תכונות אחרות, ולהבהיר זאת כשאפשר.
FLEDGE	תיאום בדיקות	איך לתאם בדיקות במספר טכנולוגיות פרסום.	צוות Chrome בודק את האפשרות לספק תמיכה נוספת כדי לתאם ניסויים על מנת לבצע ניסויים בטכנולוגיות פרסום שונות לגבי אותם משתמשים. זהו גם נושא מרכזי ביצירת שותפויות עם Chrome. גם גופי מסחר בתעשייה הביעו עניין בתפקיד זה.
FLEDGE	מגבלות על קבוצות של תחומי עניין	האם יהיו הגבלות על מספר קבוצות האינטרס שניתן להוסיף אליהן משתמש או שייכללו במכרז?	Chrome פתוח לצמצום המגבלות האלה בנוגע לביצועים של דפי אינטרנט או לחוויית המשתמש במהלך תקופת הבדיקה, על סמך המשוב וההשפעה שנמדדת על זמן האחזור. מתקיים דיון מתמשך בין הבודקים לגבי דרכים נוספות שיאפשרו לקונים ולמוכרים להתאים את השימוש במשאבים.
FLEDGE	יכולות שמקושרות ל-API	איך דוחות השיוך (Attribution) פועלים עם FLEDGE?	הפרטים המלאים עדיין לא הוגשו, ו-Chrome מצפה לקבל עדכון בנושא ברבעון השני. ב-Chrome אנחנו מצפים להמשיך לספק דיווח ברמת האירוע לגבי תוצאות המכרזים (רווחים והפסדים) במהלך תקופת המקור לניסיון.

מדידה של מודעות דיגיטליות

API / טכנולוגיה	נושא המשוב (דירוג לפי השכיחות)	סיכום שאלות וחששות	תגובה של Chrome
דוחות שיוך (Attribution) (וממשקי API אחרים)	בדיקת התנועה	חוששים אם תהיה מספיק תנועה לצורך בדיקה	Chrome מתחיל את גרסת המקור בגרסת המקור עם נפח תנועה נמוך מאוד כדי לוודא שאין באגים או בעיות חמורות באמצעי הבקרה של המשתמשים. לבודקים מוקדמים יש תפקיד חשוב באישור ממשקי ה-API פועלים כמצופה מבחינה טכנית, וכך הם יכולים להגיע מהר יותר לתנועה גדולה יותר. כשהם יהיו בטוחים שממשקי ה-API פועלים כצפוי, Chrome יגדיל את גרסת המקור לניסיון לצורך תמיכה בבדיקת כלי התחזוקה.
דוחות ייחוס (Attribution)	ארגונומיה לרישום אירועים	שאלות לגבי שיטות ההרשמה הנתמכות לאירועים.	התקבלה תגובה מ-Chrome ב-github, כדי להבהיר אילו סוגי רישום נתמכים כיום. המערכת של Chrome אוספת משוב מסביבה על העיצוב הנוכחי כדי לראות אם השינויים המוצעים נותנים מענה מספק לחששות האלה או שיש צורך בעדכונים נוספים.
דוחות ייחוס (Attribution)	יצירת רעש	אני רוצה פרטים נוספים על האופן שבו רעש נוצר בדוחות מצטברים.	דפדפן Chrome פרסם תגובה ב-GitHub כדי לספק פרטים נוספים על הדרך המערכתית של רעש. ב-Chrome מתכננים לספק ספרייה להדמיה של רעש ולבדיקה עם מגוון פרמטרים במהלך ה-OT. נוסף על כך, ב-Chrome יסופקו מסמכים ומדריכים נוספים למפתחים בנושא מצב הדיווח המצטבר.
דוחות ייחוס (Attribution)	נתונים פחות מדויקים לאתרים קטנים	חשש שאתרים או קמפיינים קטנים יותר יקבלו נתונים מדויקים פחות.	ב-Chrome מבינים שלאמצעי הגנה על פרטיות המבוססים על רעש יש השפעה גדולה יותר על פלחי נתונים קטנים יותר. עם זאת, ייתכן ששיטות כמו צבירת נתונים על פני תקופות זמן ארוכות יותר יפתרו את הבעיה הזו. לא ברור גם אם למסקנות המבוססות על פלחי נתונים קטנים מאוד (כמו רכישה אחת או שתיים) יש משמעות למפרסמים. במהלך גרסת המקור לניסיון, Chrome מעודד את הבודקים לנצל את האפשרות להתנסות במגוון רחב של פרמטרים של פרטיות ורעש כדי שיוכלו לספק משוב ספציפי יותר לגבי הבעיה הזו.
דוחות ייחוס (Attribution)	ההשפעה של הזמן שחלף מהקליק להמרה על תשתיות	חשש שהזמן שחלף מהקליק להמרה יפריע להגדרה ולאימות של הקמפיין או לאופטימיזציה של הקמפיין.	התקבלו מספר משובים סותרים ב-Chrome לגבי ההשפעה של עיכובים בדיווח על המרות. עם זאת, מאחר של-Attribution Reporting API יש עיכובים אקראיים בדיווח כדי להגן על פרטיות המשתמשים, Chrome מצפה שתרחישים או חששות ספציפיים יהיו ברורים יותר במהלך תקופת הבדיקה, וייתכן שניתן יהיה לטפל בהם באמצעות תמיכה נוספת בניפוי באגים או הנחיות למפתחים.
דוחות ייחוס (Attribution)	חלון שיוך ארוך יותר	בקשה להארכת חלון השיוך (Attribution) של 30 יום	דפדפן Chrome פרסם תשובה שביקשה משוב נוסף לגבי משך הזמן של חלון השיוך, תוך התחשבות בצמצום הנתונים ובתועלתם.
דוחות ייחוס (Attribution)	חשיפות שלא ניתנות לצפייה	שאלות לגבי השאלה אם חשיפות שאינן ניתנות לצפייה נספרות בדוחות של המרות בעקבות צפייה.	Chrome פרסם תשובה ב-GitHub כדי להבהיר את הנושא של חשיפות שניתנות לצפייה.

הגבלת מעקב סמוי

API / טכנולוגיה	נושא המשוב (דירוג לפי השכיחות)	סיכום שאלות וחששות	תגובה של Chrome
הפחתת מידע בסוכן משתמש	ביצועים	יש חששות לגבי זמן האחזור של קבלת רמזים דרך קריטי-CH (בטעינת הדף הראשונה).	Chrome בודק דרכים לשיפור הביצועים.
הפחתת מידע בסוכן משתמש / רמזים על הלקוח בסוכן משתמש	חששות לגבי מניעת הונאה / התנהלות פוגעת	חשוב שיהיה לכם כמה שיותר מידע במהלך ניפוי באגים בסוגים מסוימים של מתקפות, כולל התקפת מניעת שירות (DoS). אובדן מידע מסוים ממחרוזת UA עלול להציב אתגרים.	Chrome נמצא בדיונים ובוחנים דרכים לשמירה על הפרטיות ובמקביל מספק מספיק מידע שיכול להועיל לניפוי באגים.
הפחתת מידע בסוכן משתמש	בלבול סביב הגדרת OT	כמה משתתפים בתקופת הניסיון בגרסת המקור המליצו לשפר את המסמכים עם דוגמאות לאופן ההרשמה לגרסת המקור לניסיון.	גרסת המקור לניסיון של UA מופחתת עומדת להסתיים, אבל ב-Chrome אנחנו מתכוונים לשפר את ההוראות בנוגע לתקופת הניסיון להוצאה משימוש (כולל להבליט את ההדגמה לדוגמה).
הפחתת מידע בסוכן משתמש	חשש בנוגע לערכים של רמז ספציפי	שאלות נוספות בנוגע לשאלה אם Sec-CH-UA-Model זהה ל-<deviceModel> במחרוזת ה-User-Agent.	Sec-CH-UA-Model זהה ל-<deviceModel> במחרוזת ה-User-Agent. Chrome ינסה להבהיר את העניין במסמכים עתידיים.
הפחתת מידע בסוכן משתמש	חשש בנוגע להרשמה לתקופת ניסיון להוצאה משימוש	שאלות לגבי רישום מספר גדול של דומיינים לתקופת הניסיון להוצאה משימוש	ב-Chrome מוגדרות גישות מרכזיות לעיצוב תקופת הניסיון להוצאה משימוש, אבל ב-Chrome אנחנו סבורים שגרסת המקור לניסיון היא האפשרות הטובה ביותר, מכיוון שהיא מעניקה לכל המפתחים שליטה מלאה (כי הם יכולים לבחור אם לשלוח את הכותרת או לא).
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש	שאלות בנוגע לאופי המנחה של UA-CH	יש חשש ש-UA-CH כללי מדי בהשוואה לגמישות שכותרת סוכן המשתמש מציעה, כפי שהוגדר על ידי rfc7231.	מבחינת Chrome, האופי המנהלי של כותרות UA-CH הוא שיפור חשוב על הגמישות של מחרוזת ה-UA, גם מנקודת המבט של יכולת פעולה הדדית בסופו של דבר בין דפדפנים וגם הגנה על פרטיות המשתמשים (על ידי מניעת הוספה שרירותית של מזהים עם אנטרופיה גבוהה). עם זאת, הבעיה תישאר פתוחה למקרה שגם אחרים ישתפו את הבעיה וירצו לספק משוב.
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש	חשש משימוש ב-API כדי לחסום דפדפנים מסוימים	חשש שאתר משתמש ב-API כדי לחפש את "Google Chrome" או "Microsoft Edge" וחוסם את כל שאר הדפדפנים.	הקונספט של רשימת מותגים נועד לטפל במקרה הזה – דפדפן יכול לשלוח את "Google Chrome" בנוסף למותגים שלו.
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש	בקשה לשיטה לספירת כל הרמזים הנתמכים	עניין בדרך פרוגרמטית להכיר את כל הרמזים הנתמכים לדפדפן.	Chrome מבצע הערכה של הבקשה להוספת תכונה.
הפחתת מידע בסוכן משתמש / רמזים על הלקוח בסוכן משתמש	חששות לגבי מניעת הונאה / התנהלות פוגעת	רמזים של לקוח לא זמינים בטעינה הראשונה עבור HTTP1	אחד מממשקי ה-Client Hints Reliability API (להחיל_CH) זמין רק באמצעות HTTP2 ו-HTTP3. שרתים שעדיין מקבלים שירות באמצעות HTTP1 יצטרכו להסתמך אך ורק על קריטי-CH.
הפחתת מידע בסוכן משתמש	ההשפעה על Chrome ל-Android	שאלות לגבי האופן שבו השינוי משפיע על Chrome ב-Android באופן ספציפי.	התכונות 'הפחתת מידע ב-UA' ו-UA-CH זמינות ב-Chrome ב-Android, בנוסף למחשבים שולחניים. ב-Chrome ל-Android, השינויים יתרחשו רק ב'שלב 6', שתוזמן ל-Chrome 110.
Gnatcatcher (WIPB)	שימושים ושיטות לא תואמים	בהירות לגבי שימושים לא תואמים ושיטות לא תואמות.	אנחנו מעדכנים את ההסבר ב-Chrome עם פרטים נוספים.
Gnatcatcher + הפחתת מידע בסוכן משתמש	הפחתת האותות נגד הונאה	ההשפעה של מניעת הונאה על ידי צמצום בו-זמנית של כתובות IP וגם הגישה ל-UA.	ציפייה להתניות המדיניות נגד עיוורון כתובות IP באופן מכוון (כדי לאפשר שימוש ב-IP בתרחישים לדוגמה למניעת הונאה) תפתור בעיות להגנה מפני שרת proxy של IP.
מעקב אחר ניווט	חשש לשיבושים עתידיים	המפרסמים חוששים מהפסקות פוטנציאליות. גם ספקי זהויות הביעו עניין בתוכניות של Chrome.	ב-Chrome לא מתבצעים שינויים צפויים שעלולים לגרום לכשלים, ואנחנו בודקים תרחישים לדוגמה.
קובצי cookie מסוג SameSite	יכולת פעולה הדדית עם דפדפנים אחרים	שאלות לגבי התוכניות של Chrome לתיקון crbug.com/1221316, מכיוון שזהו תחום שבו ההטמעות של Chrome שונות מדפדפנים אחרים.	Chrome גילה באג במדדים, וכתוצאה מכך הניב מדדים חדשים. מערכת Chrome אוספת נתונים כדי להבין טוב יותר את ההשפעה של תיקון הבאג.
חלוקה למחיצות (partitioning) באחסון	חשש לגבי חלוקה למחיצות (partitioning) של ערוצי הודעות	שאלות בנוגע לערוצי העברת הודעות (למשל, SharedWorker & BroadcastChannel) צריך להיות מחולק למחיצות.	Chrome מעריך את המשוב, אבל ב-Chrome סבורים שחלוקה למחיצות של ערוצי העברת הודעות יחד עם אחסון הכרחית כדי למנוע מעקב סמוי.

חיזוק גבולות הפרטיות בין אתרים

API / טכנולוגיה	נושא המשוב (דירוג לפי השכיחות)	סיכום שאלות וחששות	תגובה של Chrome
ערכות של צד ראשון	דרישות נפוצות של מדיניות פרטיות	לא ניתן לשמור על מדיניות פרטיות משותפת לכל המוצרים, וסמכויות שיפוט שצריכות להיות חלק מאותה קבוצה.	Chrome עדיין מגדיר את דרישות המדיניות שלנו, והוא יזכור את המשוב הזה.
ערכות של צד ראשון	סביר להניח שישות האכיפה העצמאית (IEE) תקבל מספר גדול של אתגרים בנוגע לתקינות ה-FPS	סיכום של האתגרים הצפויים מראש לקביעת תוקף ה-FPS: המדיניות בנושא טקסט או פרטיות לא תואמת למשתמשים בקבוצה, בהירות לגבי האופן שבו יש למשתמשים מוגדרים אתגרים ברורים להגדרה, אתגרים ברורים ברוחב הפס ובתזמון, ומומחיות ספציפית במבנה הארגוני.	Chrome עדיין מגדיר את דרישות המדיניות שלנו, והוא יזכור את המשוב הזה.
ערכות של צד ראשון	תהליך השמירה של רשימת הדפדפנים ב-FPS	חששות לגבי חסמי כניסה של אתרים במדינות שאינן מערביות, גרסאות לא עקביות של רשימת ה-FPS בדפדפנים שונים עקב הבדלים בקצב העדכון, וביכולת של דפדפנים קטנים/חדשים יותר להשתמש ברשימה.	Chrome עדיין מגדיר את דרישות המדיניות, את תהליך האישור ואת זכויות השימוש עבור הרשימה, ויביא בחשבון את המשוב הזה. Chrome גם ישתמש בתובנות מרשימות סטטיות אחרות שבהן נעשה שימוש בפלטפורמת האינטרנט, כמו רשימת הסיומות הציבוריות.
ערכות של צד ראשון	עיצוב טענת נכונות (assertions) דינמי לכל אתר	עיצוב דינמי (בניגוד לרשימה סטטית) עשוי להיות חשוף יותר להצהרות שקריות לגבי בעלות משותפת, ולעיכובים/עיכובים של טעינת דף.	Chrome משתמש כרגע בגישה הסטטית ליצירת רשימות, ותילקח בחשבון את המשוב הזה אם נבחן מחדש את הגישה של טענות נכונות חתומות בעתיד.
ערכות של צד ראשון	תרחישים לדוגמה לשימוש בקבוצות של נתונים מאינטראקציה ישירה (First-Party) (אם ניתן ליצור גרסה מהימנה ושוויונית של רשימת ה-FPS)	כניסה יחידה (SSO) עם הנחיות שניתנות להתאמה אישית ואפשרות לדיווח על שקיפות למשתמשים.	Chrome יתייחס למשוב הזה ויביא בחשבון את השלבים הבאים לפיתוח דומיינים של צד ראשון
צ'יפים	תאימות דפדפן	אני רוצה להבין איך דפדפנים אחרים טיפלו במאפיינים של קובצי cookie שמחולק למחיצות	Chrome ממשיך לפעול במסגרת קבוצות תקנים ציבוריים, כמו W3C, כדי לזהות עיצובים והטמעות שיכולים לעבוד בדפדפנים שונים.
צ'יפים	דרישות עיצוב	חשש שלא ניתן לכלול את הקידומת של השם __Host-	הדרישה למתן שמות לגרסת המקור לניסיון ב-Chrome בוטלה. בסיומה של תקופת הבדיקה, היא תשקול אם להפוך אותה לקבועה.
צ'יפים	שימוש ב-CHIPS בתרחישים לדוגמה של מודעות	שאלות לגבי האפשרות להשתמש ב-CHIPS בתרחישים לדוגמה של מודעות.	CHIPS מאפשר לצד שלישי ליצור קובצי cookie בצד הלקוח שמחולק למחיצות באתר ברמה העליונה (או בקבוצת הצד הראשון שלו). אם בתרחיש לדוגמה נדרש מצב של חלוקה למחיצות, ולא מצב של אתרים שונים, אפשר להשתמש ב-CHIPS בתרחיש לדוגמה הזה.
צ'יפים	שילוב של CHIPS עם FPS	חשש שבדיקה באמצעות CHIPS לא תתאפשר לצד הצעות אחרות של ארגז החול לפרטיות, כמו קבוצות של צד ראשון	אנחנו ב-Chrome בודקים באופן פעיל איך לאפשר בסביבות בדיקה שמאפשרות לקיים בדיקות כאלה. בנוסף, פרסמו ב-Chrome הוראות לביצוע בדיקות מקומיות ל-FPS ול-CHIPS. ניתן להשתמש בהן בינתיים.
FedCM	אקספרסיביות	מתוך חשש שמכיוון שהדפדפן הופך חלק מזרימת הזהות המאוחדת, קשה לתעד את כל הניואנסים שה-IdP רוצים להציג למשתמשים שלהם	Chrome מזהה את הפשרה וימשיך לעבוד עם המערכת האקולוגית כדי לכסות כמה שיותר שטח וליצור אותה בצורה מפורטת ככל האפשר. חלק מהרעיונות ש-Chrome בודק כוללים התאמות אישיות של מיתוג (למשל סמלי לוגו, צבעים) והתאמה אישית של מחרוזות (למשל, "גישה למאמר זה" בניגוד ל "התחברות עם").
FedCM	מעורבות של הדפדפן	חוששים שהדפדפן מעורב יותר בתהליך של איחוד הזהויות מבעבר, כך שניתן לזהות באופן מפורש יותר את האתרים שהמשתמש מחובר אליהם (כמו גם עם אילו IdP).	ב-Chrome ברור שעכשיו יש לדפדפן תפקיד פעיל יותר, אבל רמת המעורבות הנוספת הזו דרושה כדי שהדפדפן יוכל לזהות ולמנוע מעקב בין אתרים ועדיין לתמוך באיחוד.
FedCM	שעליהם חל המבצע ויכולת פעולה הדדית	חשש שדפדפנים אחרים לא יאמצו או מטמיעים את FedCM.	Chrome עובד גם עם ספקי דפדפנים אחרים כדי למצוא פתרונות נפוצים לאיחוד בקבוצת קהילת FedID.
FedCM	אתגרי API שונים	יש חשש ש-FedCM עדיין בשלב מוקדם או לא בוגר, וייקח לו זמן רב להציע את כל התכונות שנדרשות למערכת האקולוגית.	ב-Chrome נמשיך לבחון את הנושא כחלק מבדיקות של הסביבה העסקית.
FedCM	מדיניות ארגונית ואמצעי בקרה למשתמשים	חשש אם תהיה אמצעי בקרה (למשל, מדיניות ארגונית ו/או הגדרות משתמשים) שתאפשר לארגונים להמשיך להשתמש בפריסה של זהות מאוחדת בלי לבצע שינויים. יש הרבה פריסות מקומיות של זהויות מאוחדות שקשה במיוחד לפרוס / לשנות אותן מחדש, לכן יש התנגדות רבה לממשק API חדש של הדפדפן שדורש פריסות מחדש של IdP.	ב-Chrome אנחנו בודקים אמצעי בקרה לאדמינים ולמשתמשים בארגונים, שלדעתו יתנו מענה לבעיות האלה. ב-Chrome מקבלים משוב מארגונים לגבי תרחישי שימוש ספציפיים שברצונם להביא בחשבון.

נלחמים בספאם ובהונאות

API / טכנולוגיה	נושא המשוב (דירוג לפי השכיחות לכל API)	סיכום שאלות וחששות	תגובה של Chrome
ממשק API ל-Trust Token	מגבלות מימוש	החששות לגבי 2 בכל דף מגבילים מדי, במיוחד במקרים שבהם אחד מהם מוטמע באותו דף כמה פעמים או שיש לו דומיין מנפיק שני בארגון. סביר להניח שהאדם הזה יגיע למגבלה בעצמו בלי להביא בחשבון משתתפים אחרים בשוק.	Chrome פתוח להרחיב מעט את מגבלת המימוש לדף אם הוא יגדיל את השימוש בו, אבל יהיה עליו לשמור על רמה נמוכה יחסית כדי ליצור אנטרופיה מוגזמת. בנוסף, שמירה של רשומת מימוש במטמון עשויה לצמצם את הצורך של מנפיק אחד לממש מספר אסימונים עבור משתמש יחיד בפרק זמן קצר.
ממשק API ל-Trust Token	זמן אחזור	בדרך כלל צריך להגיב לבקשות להצעות מחיר תוך 10 אלפיות השנייה או פחות, לכן מימוש אסימון בטעינה של דף ראשון כמעט ולא אפשרי לכלול אותו בקבלת החלטות לגבי תנועה לא חוקית שנמצאת לפני הגשת הצעת המחיר.	ב-Chrome מנסים להבין איך זמן האחזור משפיע על תרחישים לדוגמה לפני הצעות מחיר דרך בדיקות.
ממשק API ל-Trust Token	אימוץ של OpenRTB	בתרחישים לדוגמה של הצעת מחיר מוקדמת, חשוב להעביר את פרטי האסימון המיושמים ל-SSP ולפלטפורמות DSP לצורך קבלת החלטות בנוגע למודעות	ב-Chrome פועל שיתוף פעולה עם IAB כדי להבטיח שניתן יהיה להפיץ אותות שימושיים נגד הונאה או ניצול לרעה דרך openRTB, אף על פי שהם הבעלים של התקן להוספת שדות חדשים שמוגדרים כברירת מחדל.
ממשק API ל-Trust Token	פרטיות	שאלות לגבי הכדאיות לטווח הארוך של כל צורה של הפצה של נתונים באתרים שונים, אם כי במידה מועטה של אנטרופיה (כ-2.5 ביט)	בגלל ההגנות המחמירות על המשתמשים שנועדו למנוע את זיהוי המשתמשים הייחודיים, ב-Chrome יש סיבה טובה לקבל את הסביבה העסקית. Chrome עובד בשיתוף פעולה הדוק עם בעלי עניין מרכזיים כדי להבטיח את הקיימוּת בטווח הארוך.
אותות אימות (attestation) של הפלטפורמה	הערכת ההתעניינות ברעיון חדש/בהצעה חדשה	תמיכה חזקה באותות אפשריים (ולא ניתנים לביצוע), כמו העברת אותות תקינות של המכשיר שהפלטפורמה יכולה לספק	ב-Chrome מתכננים להעביר את הרעיון הזה לקבוצת הקהילה של W3C למניעת הונאה כרעיון חדש למשוב.
שרתים מהימנים למניעת הונאות	הערכת ההתעניינות ברעיון חדש/בהצעה חדשה	קונספט מעניין אבל סביר להניח שדורש בדיקה נוספת של תרחישים רלוונטיים	בהתאם לרמות העניין, Chrome עשוי לערוך רעיונות נוספים לגבי המושג הזה, ולהכין אותו בתור הסבר למשוב על הסביבה העסקית בעתיד.