דוח משוב – הרבעון הראשון של שנת 2025

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

Google הכינה את הדוח הרבעוני הזה כחלק מההתחייבויות שלה לרשות התחרות והשווקים (CMA) בכפוף לסעיפים 12, ‏ 17(ג)(2) ו-32(א). הדוח הזה עוסק בהתקדמות של Google בנושא ההצעות של 'ארגז החול לפרטיות', צפי הזמנים המעודכן, הסברים מהותיים על האופן שבו Google הביאה בחשבון את התצפיות של צדדים שלישיים וסיכום של האינטראקציות בין Google ל-CMA, כולל משוב מ-CMA והגישה של Google לטיפול במשוב.

Google מעדכנת את CMA לגבי ההתקדמות בהצעות של ארגז החול לפרטיות בפגישות הסטטוס הרגילות שלה, שמתוזמנות בהתאם לסעיף 17(ב) של ההתחייבויות. בנוסף, הצוות אחראי על מסמכי התיעוד למפתחים, שבהם מפורטות סקירות כלליות של התכונות המרכזיות של פרסום פרטי ושל שינויים בקובצי cookie, יחד עם הטמעת API ומידע על סטטוס. עדכונים חשובים משותפים בבלוג למפתחים, לצד עדכונים ממוקדים שמשותפים ברשימות הדיוור השונות למפתחים.

מילון ראשי תיבות

ARA

Attribution Reporting API

CHIPS

קובצי Cookie עם חלוקה עצמאית למחיצות

DSP

פלטפורמה למפרסמים

FedCM

Federated Credential Management

IAB

הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)

IDP

ספק זהויות

IETF

ארגון תקינה בנושאי האינטרנט (IETF)

קניין רוחני (IP)

כתובת פרוטוקול אינטרנט

openRTB

בידינג בזמן אמת

הארכה

גרסת מקור לניסיון

PA API

Protected Audience API (לשעבר FLEDGE)

PatCG

קבוצת קהילה בנושא טכנולוגיות פרסום פרטי

RP

צד נסמך

RWS

קבוצות של אתרים קשורים (לשעבר 'קבוצות של צד ראשון')

SSP

פלטפורמה לספקים

UA

מחרוזת של סוכן משתמש

UA-CH

רמזים על הלקוח (Client Hints) לגבי סוכן משתמש

W3C

World Wide Web Consortium

WIPB

עיוורון מכוון של כתובות IP

משוב כללי, ללא API או טכנולוגיה ספציפיים

נושא המשוב	סיכום	תגובה מ-Chrome
בחירת המשתמש	לא ברור איך תראה הגישה המעודכנת של Google לשיפור הבחירה של המשתמשים, איך היא תוצג למשתמשים ומה יהיו שיעורי ההסכמה/הביטול הצפויים. נדרש מידע נוסף כדי להבדיל בין המצב הזה לבין הוצאה משימוש של קובצי cookie של צד שלישי.	באפריל 2025, Google פרסמה פוסט בבלוג בנושא השלבים הבאים של ארגז החול לפרטיות וההגנות מפני מעקב ב-Chrome, שבו הודיעה ש-Google החליטה לשמור על הגישה הנוכחית של הצעת קובצי Cookie של צד שלישי למשתמשים ב-Chrome, ולא להשיק בקשה עצמאית חדשה לגבי קובצי Cookie של צד שלישי. נפרסם עדכונים נוספים כשיהיו לנו.
יצירה של טביעת אצבע דיגיטלית (fingerprinting)	Google לא שיתפה עם בעלי תוכן דיגיטלי או עם משווקים מידע על הדרכים שבהן הם יכולים להסתמך על חלופות למערכות הפרסום של Google בלי להשתמש בזהות של צרכן שמכילה סיכון גבוה יותר כמפתח התאמה משותף (למשל, טביעת אצבע דיגיטלית).	הדגשנו כמה מערכות פרסום שאינן של Google, שמציעות פתרונות לבעלי תוכן דיגיטלי ולמשווקים שמבוססים בחלקם על ממשקי ה-API של ארגז החול לפרטיות. הנתונים האלה כוללים מערכות פרסום שאינן של Google בשווקים ובערוצים שונים. פרטים נוספים ומחקרים מעשיים זמינים בקטע 'משאבי עסק' באתר privacysandbox.com כאן.
ארגז החול לפרטיות	ממשקי ה-API של ארגז החול לפרטיות יחליפו את הרכיבים של נתוני האינטרנט במוצרים מוגמרים של Google. מאחר שהחלופה של Google היא ממשק API, היא מציעה גישה למוצר שבבעלותה ובשליטתה, ומוצר שכפוף לתנאים ולהגבלות שבסמכותה של Google לשנות. הדבר לא מחליף רכיבים שאחרים משתמשים בהם כדי ליצור מוצרים מוגמרים משלהם.	ממשקי ה-API של ארגז החול לפרטיות פותחו והוטמעו לאחר עבודה רבה עם הרגולטורים ומגוון רחב של בעלי עניין בסביבה העסקית. בדומה לטכנולוגיות פלטפורמה אחרות, צריך להביא בחשבון שממשקי ה-API של ארגז החול לפרטיות ישמשו כרכיבים במוצרים מוגמרים של גורמים אחרים. אנחנו מברכים על המאמצים של הסביבה העסקית לפתח טכנולוגיות נוספות שיפעלו לצד ממשקי ה-API של ארגז החול לפרטיות.
בחירת המשתמש	בקשה למידע לגבי האופן שבו הגישה המעודכנת של Google ל-3PC ב-Chrome תעמוד בדרישות רגולטוריות מסוימות, שעשויות להשפיע על חוויית השימוש של בעלי העניין בפלטפורמה לניהול הסכמה.	באפריל 2025, Google פרסמה פוסט בבלוג בנושא השלבים הבאים של ארגז החול לפרטיות וההגנות מפני מעקב ב-Chrome, שבו הודיעה ש-Google החליטה לשמור על הגישה הנוכחית של הצעת קובצי Cookie של צד שלישי למשתמשים ב-Chrome, ולא להשיק בקשה עצמאית חדשה לגבי קובצי Cookie של צד שלישי. נפרסם עדכונים נוספים כשיהיו לנו.
לוח הזמנים וההטמעה של ארגז החול לפרטיות	ספקי טכנולוגיות הפרסום הפסיקו את בדיקות ממשקי ה-API של ארגז החול לפרטיות, והם מחפשים סיבות טובות יותר להשקיע מחדש בטכנולוגיות האלה לצורך פעילויות שיווקיות ומוצריות. ההחלטות שלהם לגבי השקעה חוזרת מושפעות במידה רבה מהצורך בשקיפות רבה יותר לגבי לוח הזמנים של 'הבחירה של המשתמש', וכן מהחששות לגבי זמן האחזור של Protected Audience API‏ (PA API) וממסלול העבודה של B&A. בנוסף, יש חששות לגבי בדיקת ההתחייבויות של CMA שצפויה להתבצע בקרוב, במיוחד לגבי התפקיד של Google כגורם המוביל בפיתוח טכנולוגיות של ארגז חול לפרטיות בלי להסתמך על מזהים של צד שלישי, והכיוון הכללי של היוזמה בעתיד כדי להשפיע על אסטרטגיות ההשקעה.	באפריל 2025, Google פרסמה פוסט בבלוג בנושא השלבים הבאים של ארגז החול לפרטיות וההגנות מפני מעקב ב-Chrome, שבו הודיעה ש-Google החליטה לשמור על הגישה הנוכחית של הצעת קובצי Cookie של צד שלישי למשתמשים ב-Chrome, ולא להשיק בקשה עצמאית חדשה לגבי קובצי Cookie של צד שלישי. נפרסם עדכונים נוספים כשיהיו לנו. המכרזים של Chrome PA API מהירים ב-35% בהשוואה לשנה הקודמת. בנוסף, ראינו עלייה משמעותית בשימוש במכרזים מקבילים, שמניבים תוצאות טובות יותר במכרזים האלה. כאן תוכלו לעיין בתוכנית השיווקית הנוכחית שלנו לבדיקות ביצועים ואבטחה.
ציר הזמן של ארגז החול לפרטיות	מה עודכן בדף ציר הזמן של ארגז החול לפרטיות?	סקירה כללית על Topics API נוספה לאחרונה לדף ציר הזמן של ארגז החול לפרטיות.
ארגז החול לפרטיות	האם יש מאמרים מחקריים בנושא 'פרטיות לעומת תועלת' שיעזרו להבין את ההשפעה של ארגז החול לפרטיות על ההכנסות?	כאן אפשר למצוא מחקרים רלוונטיים בנושא שוק שעונים על השאלות האלה, וכאן אפשר למצוא תוצאות מבדיקות של ממשקי ה-API של ארגז החול לפרטיות.
אימוץ ארגז החול לפרטיות	שותף שהתחיל להשתמש בממשקי ה-API של ארגז החול לפרטיות דיווח על אתגרים ראשוניים בגלל שהחברות הגדולות אימצו את השימוש בהם באיטיות, והדבר השפיע על השקות הבדיקה. עם זאת, הגישה המשותפת של צוות ארגז החול לפרטיות והתגובה שלו למשוב הן דברים שאנחנו מעריכים.	אנחנו מודים על המשוב של המשתמש המוקדם. אנחנו מחויבים לשתף פעולה עם משתמשים מוקדמים, ונמשיך לפעול בתוך הסביבה העסקית ולקבל משוב כדי להעריך את התפקיד של טכנולוגיות ארגז החול לפרטיות בתמיכה בסביבה העסקית.
בדיקות ב-Chrome	חשש לגבי היכולת להמשיך את הבדיקות של ארגז החול לפרטיות בצורה יעילה לאחר הסרת תוויות הבדיקה, שמציגות הבדל משמעותי באיכות התנועה בין Chrome עם קובצי cookie של צד שלישי מושבתים (מצב ב') לבין משתמשים שהשביתו באופן אישי את קובצי ה-cookie של הצד השלישי בהגדרות Chrome.	התשובה שלנו דומה לתשובה שנתתם ברבעונים קודמים: צוות ארגז החול לפרטיות מבין שחברות רוצות להמשיך להשתמש בתוויות להוצאה משימוש של קובצי cookie. התהליך להארכת הזמינות של התוויות דומה להארכת תקופת הניסיון של גרסת המקור. התמיכה בתוויות הורחבה כמה פעמים. אנחנו מתכננים להציע הרחבה נוספת של התמיכה בתוויות להוצאה משימוש של קובצי cookie, ונשתף עדכונים ב-blink-dev כשיהיו זמינים.

הרשמה ואימות

לא התקבל משוב ברבעון הזה.

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

נושאים

נושא המשוב	סיכום	תגובה מ-Chrome
הצטרפות/ביטול הצטרפות	האם האישור של Google על כך שחיפוש Google לא ישתמש בהחלטה של אתר לבטל את ההסכמה לשימוש ב-Topics API כאות לדירוג, יגרום לכך ש-Google לא תוכל להשתמש בהחלטה של אתר להביע הסכמה לשימוש ב-Topics API כאות לדירוג?	התשובה שלנו דומה לתשובה שנתתי ברבעונים קודמים: צוות ארגז החול לפרטיות לא תאם או ביקש מהארגון של חיפוש Google להשתמש בדירוג דפים כמַתג ממריץ לאתרים להשתמש ב-Topics API. מערכת חיפוש Google לא תשתמש בהחלטה של האתר לתמוך ב-Topics API (או לא לתמוך בו) כאות דירוג.
ניראות של נתוני שימוש	בקשה למנגנון של יכולת תצפית עבור פלטפורמת SSP או טכנולוגיית פרסום כללית, כדי לבדוק אם נעשה שימוש בהטמעה של Topics API באינטרנט.	אנחנו בודקים את האפשרות להוסיף תמיכה בפונקציונליות הזו, ואנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית אם התכונה הזו היא בעדיפות גבוהה.
פרטיות	שאלות לגבי הסכמה ופוטנציאל לזיהוי מחדש.	אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.

Protected Audience API

נושא המשוב	סיכום	תגובה מ-Chrome
PA API ו-GAM/AdX	Google לא תשלח ביקוש GAM/AdX לבעלי תוכן דיגיטלי שרוצים להסתמך על שרת מודעות של בעלי תוכן דיגיטלי מתחרה. Google צריכה לאפשר לבעלי תוכן דיגיטלי מתחרים לבחור בעלי תוכן דיגיטלי חלופיים ברמה העליונה של מכרזים של PA API כדי לשלוט במכרז הסופי. המידע מ-PA API יהיה זמין ל-GAM, אבל מוגבל ל-SSPs מתחרים. כתוצאה מכך, בעלי תוכן דיגיטלי לא יכולים להשוות את הביצועים של ביקוש שמקורו ב-PA API ב-GAM, למשל מ-AdX או מ-SSPs שמשולבים ב-PA API.	תגובה מ-Chrome: תקן PA API נועד להיות גמיש ומאפשר לגורמים שונים להפעיל את המכרז ברמה העליונה. הבחירה הזו תלויה בהטמעות וביכולות הספציפיות שספק המודעות של בעל התוכן הדיגיטלי מציע (GAM או מערכת אחרת) ובחברות אחרות שמשתתפות בסביבה העסקית. העיצוב שמתמקד בפרטיות של PA API מגביל באופן עקבי את הדיווח המפורט על כל המשתתפים. הנתונים הספציפיים שמדווחים מ המכרז של PA API עצמו כפופים לאותם כללים והגבלות לשמירה על הפרטיות שמוגדרים ב-API לכל המשתתפים, כולל כל ה-SSP. בעלי תוכן דיגיטלי משתמשים בדוחות המצטברים של PA API, שמשמרים על הפרטיות, כדי להעריך את הביצועים. כך אפשר להעריך את התרומה הכוללת של הביקוש שמגיע דרך PA API, ולהשוות אותו לערוצי ביקוש אחרים, בהתאם לעקרונות של פרטיות מובנית ב-API. התשובה שקיבלנו מ-Google Ad Manager: בעלי תוכן דיגיטלי לא חייבים להשתמש בפונקציונליות של שרת המודעות של GAM כדי לגשת לביקוש מ-AdX. בנוסף, PA API לא תלוי בגורם שמפעיל את המכרז, גם בתכנון של מוכר יחיד וגם בתכנון של כמה מוכרים.
מוכר ברמה העליונה	למוכרים ברמה העליונה (TLS) יש גישה למידע שאף אחד מהמוכרים האחרים של הרכיבים לא יכול לגשת אליו, מה שמעורר חששות לגבי גישה לא שוויונית למידע. כל ישות יכולה להיות TLS, אבל כדי לגשת לביקוש מ-AdX, בעלי תוכן דיגיטלי נדרשים להשתמש ב-GAM בתור שרת המודעות של בעלי התוכן הדיגיטלי. כך יש תמריץ להשתמש ב-GAM כשרתימת המודעות של בעלי התוכן הדיגיטלי, וכך Google יוצרת יתרון תחרותי.	תשובת Chrome: העיצוב של PA API לא קובע איזה ישות יכולה לפעול כ-TLS. התפקיד TLS מחייב תיאום של המכרז וגישה למידע שקשור למכרז בהתאם למבנה של ה-API. התשובה שסופקה על ידי Google Ad Manager: אנחנו מתמקדים כבר שנים בשמירה על הוגנות במכרזים, כולל ההבטחה שלנו שלא נשתף עם קונה אחר מחירים ממקורות הפרסום הלא מובטחים של בעל התוכן הדיגיטלי, כולל מחירי פריטים לא מובטחים, לפני שהוא יציע מחיר במכרז. מאוחר יותר אישרנו את ההתחייבות הזו במחויבויות שלנו לרשות התחרות בצרפת. במכרזים עם PA API, אנחנו מתכוונים לעמוד בהבטחה שלנו ולא לשתף את הצעת המחיר של כל משתתף במכרז עם משתתף אחר במכרז לפני סיום המכרז במכרזים עם מספר מוכרים. חשוב להבהיר: אנחנו לא נשתף את המחיר של המכרז לפי הקשר עם אף מכרז רכיבים, כולל המכרזים שלנו, כפי שמוסבר בעדכון הזה. בנוסף, אנחנו לא משתמשים במידע על הגדרות המכרז של הרכיבים, כולל אותות שהקונים מספקים ל-SSP, כחלק מהמכרז שלנו. בנוסף, כפי שצוין למעלה, מערכת GAM לא דורשת מבעלי תוכן דיגיטלי להשתמש בפונקציונליות של שרת המודעות שלה כדי לגשת לביקוש מ-AdX. לבסוף, כפי שצוין קודם לכן בדוח של Google לרבעון 2 או לרבעון 3 של שנת 2024, פלטפורמות הצד הקונה של Google – Google Ads‏ (לשעבר AdWords) ו-DV360 – קונות חשיפות מבורסות שאינן של Google, כולל דרך PA API.
PA API ו-GAM/AdX	קשה לבעלי תוכן דיגיטלי להבין למה כדאי להפעיל את PA API ב-100% מלאי שטחי הפרסום, כי התיוג של האפשרות לא ממחיש את המטרה שלה. ב-SSP, שבהם הדרך העיקרית לגשת למלאי שטחי הפרסום היא לרוב באמצעות מכרז מרובד שבו GAM פועל כ-TLS, אין למעשה דרך לבצע בדיקות או לייצר הכנסות דרך PA API בלי להיות כפופים ל-GAM.	תשובת Chrome: תקן PA API מגדיר תפקידים טכניים (כמו TLS ומפיץ רכיבים) ותהליך המכרז, ומאפשר גמישות לגבי הפלטפורמות שמבצעות את התפקידים האלה. הפעילויות התפעוליות – כמו הגדרה, תיאום הסכמים – מנוהלות על ידי הצדדים המטמיעים (בעלי תוכן דיגיטלי, רשתות SSP, ספקי TLS) כדי להקל על ההשתתפות באמצעות מסגרת ה-API של PA. התשובה שסופקה על ידי Google Ad Manager: כפי שמתואר במרכז העזרה שלנו, מערכת Ad Manager מספקת לבעלי תוכן דיגיטלי אמצעי בקרה שמאפשר לבצע בדיקות עם מוכרי רכיבים שאינם Google, כמו פלטפורמות SSP אחרות, ב-100% מהמלאי של בעלי התוכן הדיגיטלי שבו ה-API זמין לשימוש (מבטלים את כל דגימת הנתונים או הגבלת הקצב שמערכת GAM עשויה להחיל). אם בעלי תוכן דיגיטלי מפעילים את אמצעי הבקרה הזה, בכל פעם שמוכרי רכיבים שאינם Google מספקים הגדרת מכרז, מערכת GAM תנסה להפעיל מכרז ברמה העליונה שכולל את מכרז הרכיבים שסופק, בתנאי שבעלי התוכן הדיגיטלי קבל את הסכמת המשתמשים הנדרשת כדי לעשות זאת. מערכת GAM מבהירה לבעלי התוכן הדיגיטלי שאמצעי הבקרה הזה עשוי להשפיע על הביצועים, כדי שבעלי התוכן הדיגיטלי יוכלו לקבל החלטה מושכלת.
בצד השרת לעומת במכשיר	פתרונות בצד השרת, כמו בידינג ומכרזים (B&A), יכולים לפתור את הבעיה של עיצוב התנועה תוך שמירה על הפרטיות. פתרונות בצד השרת הם הדרך היחידה האפשרית קדימה, ו-Google צריכה לנטוש את הפתרונות במכשיר.	ארגז החול לפרטיות נועד לתמוך בפתרונות של מכרזים גם בצד השרת (שירותי B&A) וגם במכשיר, וכך לספק אפשרויות שיענו על צרכים שונים של טכנולוגיות פרסום ועל תרחישי שימוש שונים.
אבטחה במכרזים	התקפות על הצעות מחיר ל-PA API מונעות באופן מהותי את האפשרות להשתתף במכרזים ובבידינג במכשיר. בעלי העניין לא מתייחסים לבעיה הזו כבעיה שנפתרה, והם ממשיכים לבקש ערבויות טכניות כדי להבטיח שלא יהיה פגיעה בהצעות המחיר ל-PA API, וגם מצב ניפוי באגים מקיף כדי לאפשר זיהוי אירועים בזמן אמת וניפוי באגים יעיל.	אחת המטרות העיקריות של ארגז החול לפרטיות היא להבטיח את תקינות המכרזים של PA API, כולל צמצום של התקפות פוטנציאליות. תכנון ה-API כולל אמצעי תקינות, ואנחנו מקדמים בברכה דיון טכני נוסף בנושא חששות ספציפיים. במהלך הפגישה של קבוצת הקהילה של W3C למניעת הונאות במאי 2024, הצגנו רשימה מפורטת של התקפות פוטנציאליות על PA API ודיברנו על הפתרונות שלנו לצמצום התקפות כאלה. נשמח לדון בנושאים נוספים ולקבל משוב לגבי 'התקפות פוטנציאליות על הצעות מחיר ל-PA API' שמדאיגות אותך.
תנועה ללא קובצי cookie	האם תהיה אפשרות להפעיל את PA API רק על תנועה ללא קובצי cookie לצורכי בדיקה או למטרות אחרות?	טכנולוגיות הפרסום יכולות לזהות אם יש קבצים מסוג 3PC או לא. הסבר מפורט יותר זמין כאן.
מזהה מושב	בנוגע להצעה בנושא Seat ID, הידע לגבי Seat ID חיוני לרוב הבקשות להצעות מחיר, ולכן יש חשש לקשר בין Seat ID לרישום הקריאייטיב. בנוסף, האם היא תחול רק על 'המודעה הראשית' או גם על מודעות רכיבים?	ההצעה BuyerAndSellerReportingId פותרת את הבעיה של חוסר מזהה המושב של הקונה במהלך רישום הקריאייטיב של המודעה הראשית. המזהה הזה נועד להעביר את מזהה המושב של הקונה אל המוכר. אנחנו בודקים את התמיכה במודעות רכיבים.
מעקב ודיווח	בקשה להוספת תכונה למעקב בזמן אמת (RTM) לצורך (1) שליחת דוחות RTM על מכרזים שבוטלו, וגם (2) קטגוריות חדשות שמאוכלסות על ידי דפדפנים כדי להבהיר איזה סוג ביטול התרחש.	נראה ש-RTM הוא לא פתרון מתאים לבדיקה של שיעור ההשתתפות. RTM הוא ממשק API למעקב עם זמן אחזור קצר, שנועד לזהות הפסקות זמניות, קריטיות ופתאומיות בשירות. לעומת זאת, דיווח על שיעור ההשתתפות לא מחייב דיווח בזמן קצר, והוא לא הפסקה זמנית קריטית ומפתיעה. הדרך הטובה ביותר לענות על חששות לגבי שיעורי ההשתתפות היא לפנות למוכרים שאיתם הקונים עובדים, ולא לקונים שמבצעים בדיקה דרך הדפדפן. בנוסף, מאחר שמכרזים שבוטלו הם דבר נפוץ מאוד, אם הדפדפן ייצור דוחות RTM מכל מכרז שהתבטל, יכול להיות שהם יטשטשו דוחות RTM של הפסקות זמניות פעילות בשירות.
מסמכים בהירות	דיווח על חוסר התאמה במסמכי התיעוד במאמר ההסבר של PA API, שבו מצוין שה-nonce צריך להיות מחרוזת UUID, אבל בפועל הוא מחזיר הבטחה (promise).	כאן מופיעה הצעה להבהרה.
הקשר קפוא	כשעובדים עם הקשר קפוא, אילו אפשרויות זמינות כדי לטפל בבעיות ובאתגרים שקשורים ל-(1) קיבוץ, ל-(2) ספריות חיצוניות ול-(3) סוגי נתונים שלא נתמכים?	כאן יש תשובה לשאלה הזו.
מפרטים	נוספה ל-Private Aggregation API פעולה גנרית מסוג contributeToHistogramOnEvent. כתוצאה מכך, ההגדרה ב-PA API הפכה לפעולה עם עומס יתר, ו"אסור להעמיס יתר על המידה פעולות של Web IDL בממשק, בממשק חלקי [...]", ולכן ההגדרה הזו לא חוקית עכשיו.	הבעיה הזו נובעת מאי-עקביות זמנית בין המפרטים של PA API לבין המפרטים של Private Aggregation API, בזמן שאנחנו ממזגים שינויים דומים בשניהם. מיזגנו בקשת משיכה כדי לטפל בבעיה הזו.
קבוצות אינטרס	בקשה להנחיה לגבי השיטה המומלצת והיעילה במשאבים לסיום ההשתתפות של קבוצת תחומי עניין (IG) בבידינג כשקמפיין מושהה.	ריכזנו כאן כמה הצעות: לדעתנו, המנגנון עם זמן האחזור הנמוך ביותר, הפחות קבוע אבל גם עם הכי פחות שחרור משאבים הוא שימוש באותות הבידינג בזמן אמת כדי להודיע ל-generateBid() שלהם להפסיק להגיש הצעות מחיר. האפשרות השנייה, שמשתמשת בפחות משאבים, היא להגדיר עדיפות שלילית ל-IG הזה בתגובה לאותות הבידינג בזמן אמת, כי כך לא תהיה קריאה ל-generateBid() בכלל. האפשרות השלישית, שמשתמשת בפחות משאבים, היא להסיר את המודעות מה-IG. במודעות IG ללא מודעות, הקריאה ל-generateBid() לא מתבצעת. האפשרות הרביעית, שמשתמשת בפחות משאבים, היא הסרת biddingLogicURL מה-IG. בשלב הזה עדיין אפשר לעדכן את החשבון ב-IG או להצטרף אליו מחדש כדי להפעיל אותו מחדש. אפשרויות נוספות קשורות לעזיבת ה-IG, דרך leaveAdInterestGroup() או clearOriginJoinedAdInterestGroups() או דרך תפוגת התוקף של ה-IG. כפי שצוין למעלה, לאפשרויות השונות יש השפעות שונות על זמן האחזור ועל צריכת המשאבים. ספקי טכנולוגיות הפרסום יכולים לבחור את האפשרות שמציעה את הפשרה הטובה ביותר לתרחישים הספציפיים לדוגמה שלהם.
קהלים	בקשה למנגנון להפעלת פעולות לוגיות על קהלים שנוצרו (למשל, יכולת טירגוט של קבוצה שהיא חיתוך של קבוצות IG A ו-B)	בעזרת PA API, אפשר להריץ פעולות לוגיות על קהלים מאותו אתר כבר היום. אנחנו לא תומכים כרגע בפעולות לוגיות של קהלים באתרים שונים, מטעמי פרטיות כפי שמוסבר במודל הפרטיות שלנו. אנחנו ממשיכים לערוך מחקר בתחום הזה ונשתף עדכונים לאורך הדרך.
בקשה לתכונה	הצעה להסרת ההגבלה על הצעות מחיר נוספות שדורשות לדעת מראש את ה-TLS.	אנחנו מדברים על ההצעה הזו כאן ונשמח לקבל משוב נוסף.
גישה מעודכנת ל-3PC ב-Chrome	האם ממשקי ה-API של ארגז החול לפרטיות, כמו PA API, יישארו זמינים באופן כללי לכל המשתמשים בגרסת Chrome Stable, או שממשקי ה-API (או קבוצת משנה של ממשקי API) יהיו זמינים רק למשתמשים שדחו קבצים של צד שלישי?	אנחנו לא מתכוונים לאפשר למשתמש שסירב לשימוש בקובצי Cookie של צד שלישי להשפיע על הזמינות של ממשקי ה-API של ארגז החול לפרטיות בגרסה היציבה של Chrome.
איתות משופר	האם יש תוכניות להוסיף פונקציונליות שמציינת אם ה-TLS מתכוון להפעיל מכרז של PA API?	אנחנו בודקים את האפשרות להוסיף תמיכה בפונקציונליות הזו. נשתף פרטים נוספים על לוח הזמנים כשיהיו לנו, ונשמח לקבל משוב נוסף לגבי הבקשה הזו.
מזהה מבצע	חשש שהדרישה לשרת KV בהצעה של מזהה העסקה עשויה להיות תהליך יקר שגוזל זמן בצד השרת.	ההצעה לגבי מזהי עסקאות מאפשרת ל-SSP לבצע שאילתות על המטא-נתונים של מזהי העסקאות שנבחרו משרת המפתח/ערך במהלך מכרזים של PA, כך שלא יהיה צורך לטעון מראש את כל המטא-נתונים הקשורים לעסקאות במכשיר. ההצעה הזו מפותחת בתגובה לבקשות מ-SSP, ונשמח לקבל משוב נוסף על הסביבה העסקית כאן. אנחנו מבינים שצריך לבצע עבודה כדי להגדיר את שרת המפתחות-הערכים, אבל באופן כללי אנחנו עדיין חושבים שזו תועלת נטו לחברות טכנולוגיית הפרסום. אנחנו ממשיכים לקבל משוב והצעות לשיפור התהליך.
מכסת תדירות בפלטפורמות שונות ב-Instagram	בקשה למכסת תדירות ב-IG דרך PA API.	למכסת התדירות ב-IG יש מאפייני פרטיות מאתגרים שלא הצלחנו למצוא להם פתרונות. אנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית אם התכונה הזו היא בעדיפות גבוהה.
דיווח על מספרי עסקאות ומזהי מושבים	בקשה לקבלת מזהי עסקאות או מושבים בדוחות מצטברים.	הפונקציות של המזהה לצורכי דיווח שאנחנו עובדים עליהם כאן יאפשרו דיווח על מזהי עסקאות ומזהי מושבים. הערך של selectedBuyerAndSellerReportingId מסופק ל-reportResult(), ולכן הדרך הקלה ביותר לדווח עליו היא באמצעות דיווח ברמת האירוע (כלומר, קידוד מזהה העסקה בכתובת ה-URL שמועברת ל-sendReportTo()). אם רוצים להשתמש בדיווח מצטבר, אפשר לעשות זאת גם כך. התכונה 'מזהה דיווח' פועלת כרגע ב-10% מהתנועה בערוץ היציב של Chrome. אנחנו שוקלים להרחיב את ההשקה ל-100%.
קבוצות אינטרס	יש להשתמש באותו סדר עדיפות גם בבחירה וגם בהערכה של IG, ולהשתמש בסדר העדיפות הזה בכל מצבי ההערכה.	אנחנו מדברים על זה כאן ונשמח לקבל משוב נוסף.
קבוצות אינטרס	הצעה להשתמש בהפעלה ובהענקה של גישה לקהלים כדרכים להגדלת השימוש בממשקי API של ארגז החול לפרטיות.	אנחנו מודעים לבקשה הזו מגורמים רבים שקשורים לנושא, ואנחנו בודקים פתרון. אנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית.
קבוצות אינטרס	אתגרים ביצירת ממשקי API של מודעות פרוגרמטיות, במיוחד בנושא הענקת גישה ובעלות כשמבצעים כמה רכישות או בשם בעלי תוכן דיגיטלי.	קיבלנו בקשה מתומכים מרובים לתמוך בהענקות גישה מתקדמות יותר ל-IG, ואנחנו רואים את הערך המוסף של פלטפורמות ה-SSP בתהליך הזה. אנחנו עורכים מחקר כדי למצוא את הפתרון הטוב ביותר שיאפשר לגורמים שונים להשתתף בתהליך הרחבת הקהל. נשמח לקבל משוב נוסף מהסביבה העסקית.
ביצועים בצד הלקוח	בקשה לקבלת הנחיות להקלה על האחסון במטמון בצד הלקוח של trustedBiddingSignals, כדי לבצע אופטימיזציה של עלויות התשתית וזמן האחזור.	אנחנו מדברים על זה כאן ונשמח לקבל משוב נוסף.

מכרז מוגן (שירותי B&A)

נושא המשוב	סיכום	תגובה מ-Chrome
שירותי K/V	איך מתבצעת הקיבוץ של בקשות מהדפדפן לשרת ה-KV של המוכר? מה תיראה הבקשה מהדפדפן עבור המוכר – בקשת GET או בקשת POST? בנוסף, נדרשת הבהרה לגבי הדרישות של אנונימיות מסוג k.	בגרסה 1, Chrome שולח בקשת GET לשירות ה-KV של המוכר כדי לאחזר את trustedScoringSignalsURL עם האותות בפרמטרים של השאילתה בבקשה. הפרמטרים יכללו את hostname,‏ renderUrls,‏ adComponentRenderUrls ו-experimentGroupId. אנחנו בודקים כרגע תוספים מסוימים לשליחת מידע נוסף לצורך סריקת קריאייטיב, אבל הם עדיין לא הושקו. כשמגדירים את maxTrustedScoringSignalsURLLength כ-0, יכול להיות ש-Chrome יקבץ את כל האותות לבקשה אחת (יכול להיות שהיא תחרוג ממגבלת האורך של כתובת ה-URL בשרת), אבל זה לא מובטח. נכון לעכשיו, Chrome בוחר לכלול בקשות באותו אשכול אם הן מוכנות להישלח בטווח של 10 אלפיות השנייה זו מזו, אבל אנחנו בודקים כרגע איך לבצע אופטימיזציה לכך. כשעובדים עם trustedScoringSignals, חשוב לזכור ש-Chrome מכבד כותרות שמאוחסנות במטמון. כותרות כמו הכותרת Stale-While-Revalidate 'Cache-Control' יכולות לצמצם את זמן האחזור הממוצע על ידי מתן אפשרות ל-Chrome להשתמש בעותק ששמור במטמון (ולעדכן את המטמון לקראת המכרז הבא), וכך להסיר את אחזור האותות מהנתיב הקריטי. לבסוף, בנוגע ל-k-anonymity, נראה שהקטע הספציפי במאמר ההסבר לא מעודכן. במקור, היינו מתכוונים לדרוש שכתובות ה-URL של האותות המהימנים יהיו אנונימיות לפי k, אבל הדרישה הזו בוטלה. נסיר את המשפט הזה מההסבר.
שירותי B&A	השדרוג לגרסה האחרונה של B&A נמשך זמן רב. יתרון נוסף הוא זמני build מהירים יותר או קובצי אימג' שנוצרו מראש.	ספקי טכנולוגיות הפרסום יכולים ליצור את הקבצים הבינאריים בעצמם ולתקף אותם באמצעות הגיבוב שסופק. בעתיד נבחן את האפשרות לספק ארטיפקטים שנוצרו מראש או לשפר את זמני ה-build.
בקשה להוספת תכונה ל-API	בקשה לתאימות ל-macOS של סקריפטים ל-build, קובצי אימג' של קונטיינרים וכלי להפעלה של שירותי בידינג ומכרזים (B&A), כדי לאפשר פיתוח ובדיקה מקומיים.	כרגע אנחנו תומכים ב-amd64, מספיק כדי לפרוס בפלטפורמות הענן הנתמכות (GCP ו-AWS). יכול להיות שנבדוק תמיכה בארכיטקטורות אחרות בעתיד.
AWS	האם יצירת תפקידים ב-IAM היא דרישה לבניית גרסאות build בסביבת הייצור?	כן, תפקידי IAM נדרשים כדי לקבל את ההרשאות המתאימות ולתקשר עם רכזי הפרויקטים. המפתחות משמשים לפענוח הטקסט המוצפן של ProtectedAudienceInput שנוצר במכשיר, כפי שמתואר כאן. בנוסף, התפקידים האלה נדרשים כדי לעבור אימות שרת/TEE של גרסאות build בסביבת הייצור עם אותם רכזים. אפשר לקרוא על כך בהרחבה במדריך שלנו לשירות עצמי.
דגלים של B&A	בקשה להוסיף למסמכי העזרה הגדרות של הדגלים הזמינים של B&A. נכון לעכשיו, ההגדרות האלה נמצאות בקוד של Terraform, בקבצי cc ובקבצי proto, אבל מומחי טכנולוגיות הפרסום יוכלו להיעזר במסמכי העזרה לגבי הדגלים האלה כמקור מידע אמין להבנת האופן שבו אפשר להתאים אישית את הפריסות.	אנחנו בודקים את האפשרות לתעד את התיאורים של הדגלים של Terraform, ונשמח לקבל משוב נוסף כאן.
AWS Bidding Service	בקשה לקבלת הנחיות לגבי שירות הבידינג ב-AWS, התנהגות ברירת המחדל של הרישום ביומן והגדרותיו.	כדי לנפות באגים בשירותי הבידינג ב-TEE (כמו שירות הבידינג), מומלץ להשתמש בניפוי באגים בהסכמה של חברת טכנולוגיית הפרסום. כך תוכלו להפעיל רישום ביומן מפורט ולתעד נתוני בקשה/תגובה לבקשות הבדיקה הספציפיות שלכם ישירות מהלקוח, כדי לעזור בניפוי באגים.
תיעוד של TEE K/V	בקשה להבהרה לגבי תחילת האכיפה של TKV כפי שמפורט באתר הפיתוח.	נודיע מראש מספיק זמן לפני שנחייב את השימוש ב-TEE. עד אז, תוכלו להמשיך להשתמש בשרת שלכם כדי לקבל אותות של מפתח/ערך בזמן אמת.
בדיקה וניתוח של בדיקות A/B	הניתוח והבדיקה של B&A עדיין יקרים ולא נראים מוכנים לייצור.	כדי שנוכל לבדוק את הנושא לעומק, נצטרך מידע נוסף על ניתוח העלויות ועל הגורמים שהובילו להערכה של מוכנות הסביבה לייצור.
אופטימיזציה של שרת מהימן	הצעה למיזוג פרמטרים ספציפיים למוכרי רכיבים לפרמטר אחד בשם inputsPerSeller, באמצעות מחרוזת JSON כערך שלו.	אנחנו דנים בהצעה הזו ונשמח לקבל משוב נוסף כאן.
אבטחה	איך משתמשים ב-B&A כדי לצמצם את סיכוני האבטחה של TKV?	אפשר למנוע קריאות חיצוניות ל-TKV. אפשר להגדיר את האפשרות הזו ב-GCP וליהנות מתמיכה מלאה בה. ב-AWS, צריך לפתח תמיכה נוספת בגלל ההוצאה משימוש של AWS App Mesh, שאפשרה זאת בעבר. נשמח לקבל משוב נוסף כאן.
שירותי B&A	בקשה להבהרה לגבי התיאור/המסרים בנוגע לערך של HTTP Streaming לאופטימיזציה של בדיקות A/B.	ארגז החול לפרטיות תומך ביכולות סטרימינג בהעברת נתוני B&A כדי לשפר את זמן האחזור עבור טכנולוגיות הפרסום הדיגיטלי שבוחרות להשתמש בו. זוהי אופטימיזציה אופציונלית של הביצועים במצב משולב.
Prebid	בקשה לקבלת עדכונים על תרומות לספריית Prebid בקוד פתוח, כדי לאפשר למערכת האקולוגית להשתמש בתכונות של בדיקת בידינג ובדיקת מודעות של PA API.	במרץ 2025, השקנו ב-Chrome את האופטימיזציה המועדפת של Prebid בגרסה יציבה, כפי שמתואר במפת הדרכים הציבורית של B&A (ראו מרץ 2025).
עיצוב תעבורת נתונים	בקשה למנגנונים לתיעוד אותות לפי הקשר שהתקבלו על ידי B&A, כדי להבין טוב יותר מתי המודעות האינטראקטיביות מופעלות ולשפר את הלוגיקה של 'כוונת הבידינג' בתגובה לפי הקשר. כך אפשר להשתמש טוב יותר במשאבי הרשת כדי למנוע 'תנועה חסרת תועלת' (שנקראת גם 'עיצוב תנועה').	אנחנו מדברים כרגע על הצעה כאן ונשמח לקבל משוב נוסף.
מסמכים בהירות	דרוש הבהרה לגבי השגיאה 'לא ניתן לגשת לשרת ה-proxy של Service/Vsock' שזוהתה במהלך הגדרת השילוב של בדיקת B&A.	הסיבה לכך היא דרישות זיכרון מינימלי.הסבר על הגדרות AWS עודכן כך שישקף את הדרישה הזו.

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

דוחות שיוך (Attribution) (וממשקי API אחרים)

נושא המשוב	סיכום	תגובה מ-Chrome
נתונים בזמן אמת	חוסר הנתונים בזמן אמת משפיע על כל מי שעובד בתחום. עיכוב בקבלת נתונים בזמן אמת הוא בעיה רצינית למפרסמים. הקונים עוברים לפלטפורמות שיש בהן Google Analytics, כי זה המקום היחיד שבו הם יכולים לקבל הוכחה לכך שהם הגיעו לקהלים.	עיכובים בנתונים בזמן אמת שנכללים ב-Attribution Reporting API‏ (ARA) מיושמים כמנגנונים להגנה על הפרטיות כדי לצמצם את היכולת של חברות טכנולוגיית הפרסום להשתמש בדוחות ברמת האירוע כדי לעקוב אחרי משתמשים באתרים שונים. עם זאת, ARA מספק גמישות לגבי אופן המסירה של דוחות השיוך. הוא מאפשר לדווח על אירועים בחלון זמן מינימלי של שעה אחת, וגם לשלוח דוחות סיכום באופן מיידי לספקי טכנולוגיות הפרסום ללא עיכוב.
שימוש ב-API	בקשה לאישור לגבי ההגדרה הנכונה לתהליך שיוך (Attribution) בין אפליקציות לאתרים, במיוחד כשמפעילים שיוך מאתר לאתר ושיוך מאתר לאפליקציה במקביל.	כשמריצים קמפיינים מסוג 'מאתר לאתר' וקמפיינים מסוג 'מאתר לאפליקציה' במקביל, פלטפורמת הפרסום צריכה לבחור רק פלטפורמה אחת כדי לרשום כל מקור או טריגר, כדי למנוע ספירה כפולה. מומלץ מאוד להשתמש במערכת ההפעלה (OS) כשהדבר אפשרי, כי מערכת ההפעלה יכולה לבצע שיוך גם מאתר לאתר וגם מאתר לאפליקציה, כל עוד המקורות והטריגרים באינטרנט הוקצו בצורה נכונה. במקרה כזה, צריך להשיב עם הכותרת Attribution-Reporting-Register-OS-Source למקורות ועם הכותרת Attribution-Reporting-Register-OS-Trigger לטריגרים. אפשר להשתמש בכותרת Attribution-Reporting-Support כדי לזהות אם יש תמיכה ברמת Chrome ו/או Android. הכותרת Attribution-Reporting-Info שימושית כשאין כותרת Attribution-Reporting-Support בבקשה. במקרה כזה, הדפדפן יקבל את ההחלטה לגבי רישום הפלטפורמה על סמך הזמינות של תמיכה בפלטפורמה במכשיר של המשתמש.
מפרט API	רציתי לקבל הבהרה לגבי כותרת הבקשה של HTTP עם התמיכה בדיווח על שיוך (Attribution) שמוגדרת על ידי Attribution Reporting API, ואם הכותרת אמורה להכיל גם מפתחות לאינטרנט וגם מפתחות למערכת ההפעלה, ללא קשר לפלטפורמה.	הכותרת Attribution-Reporting-Support כפופה להוספת פרמטרים מסוג 'GREASE' על ידי הדפדפן, כדי להבטיח שהשרתים משתמשים בניתוח כותרות מובנות שתואם למפרט. בכותרת הזו, צריך לפרש רק מפתחות של מילון מובנה. הערכים והפרמטרים לא בשימוש כרגע. כאן אפשר לראות דוגמה.
דיווח שמבוסס על 3PC	בקשה לקבלת הנחיות לפתרון פערים במדידה בין ARA לבין 3PC בקמפיינים פרסומיים.	ARA תומך בשני סוגים של דוחות ניפוי באגים שאפשר להשתמש בהם כדי לפתור בעיות ולטפל בפערים. אפשר להשתמש בדוחות ניפוי באגים של הצלחת שיוך כדי להשוות בקלות בין תוצאות ARA לתוצאות של טכנולוגיות מדידה אחרות, ובדוחות ניפוי באגים מפורטים כדי לקבל מידע נוסף ולפתור בעיות פוטנציאליות ברישומי השיוך.
שימוש ב-API	במהלך הבדיקה של ARA, התגלו בעיות מסוימות: דיווח לא מפורט מספיק שהוביל לנתונים רועשים ולאופטימיזציה לא גמישה של הקמפיינים, ערכי סף גבוהים שמונעים ממפרסמים קטנים יותר להשתמש בתכונה, וקושי בהשוואת קמפיינים בגלל מדדי ביצועים עסקיים לא עקביים.	ARA מספק גמישות באמצעות מספר פרמטרים שספקי טכנולוגיות הפרסום יכולים להתאים אישית כדי להשיג את התרחישים הספציפיים לדוגמה שלהם למדידת ביצועים. הדוחות ברמת האירוע תומכים בדיווח גמיש ברמת האירוע, שמאפשר לטכנאי הפרסום להתאים אישית את חלונות הדיווח, את מספר הדוחות שהם יכולים לקבל ואת נתוני הטריגר שהם רוצים למדוד. כך הם יכולים לשנות את ההשפעה של הרעש על הנתונים שלהם ולעמוד בתרחישי שימוש שונים. באופן דומה, בדוחות המצטברים יש דרכים שונות שבהן טכנאי הפרסום יכולים להתאים אישית את ההגדרות שלהם, כמו מספר המאפיינים שאחריהם הם עוקבים, תדירות הקיבוץ שלהם והשימוש שלהם בתקציב התרומה כדי לשנות את ההשפעה של הרעש ולהגיע גם לתרחישי שימוש שונים.
מפרט API	שאלה לגבי התלות של ARA ב-3PC, במיוחד לגבי השאלה אם הוא עדיין נמצא בשלב בדיקה שבו נדרשים ה-3PC האלה.	ARA מופעל בנפרד מ-3PC, אבל צריך להפעיל 3PC כדי לאפשר דיווח על ניפוי באגים במעבר ל-ARA, כדי להשוות בין תוצאות ARA לתוצאות שיוך שמבוססות על קובצי cookie.
שימוש ב-API	פנייה לגבי רישום מקורות לצורך שיוך (Attribution) מאפליקציה לאתר בגרסאות ישנות יותר של Android‏ (11,‏ 12 ו-13) באמצעות ARA.	כרגע יש תמיכה ב-ARA ב-Android S ואילך (12 ומעלה).
שימוש ב-API	בקשה לקבלת שיעורי ההצטרפות ל-ARA ופרטי הפצה.	התשובה שלנו לא השתנתה מארבעי החודשים הקודמים: "אין לנו תוכניות לשתף את המידע הזה עם הסביבה העסקית. מפתחים יכולים להפעיל את ממשקי ה-API שבהם פרסו קוד כבר היום כדי להעריך את הזמינות של ממשקי ה-API של ארגז החול לפרטיות"
זמינות ה-API	כש-ARA מופעל, האם 3PCs מופעל או מושבת?	כש-ARA מופעל בדפדפן של המשתמשים, אין לו השפעה על הגדרות קובצי ה-cookie של המשתמשים. יכול להיות שהתכונה ARA מופעלת ושהמשתמש הפעיל או השבית את קובצי ה-Cookie.
דיווח	האם יש רשימה מוגדרת מראש של ערכים שאנחנו יכולים לקבל בכותרת Attribution-reporting-support?	כפי שמפורט ב הנחיות שלנו, הערך הוא מילון כותרות מובנה, שהסמנטיקה שמוגדרת בו כרגע היא נוכחות או היעדר של מפתחות ה-OS והאינטרנט. צריך להתעלם מכל שאר החלקים בכותרת. במילים אחרות, כדי לנתח את הנתונים צריך להשתמש בניתוח כותרות מובנה, ולא בהתאמה פשוטה של מחרוזות.

Aggregation Service

נושא המשוב	סיכום	תגובה מ-Chrome
בקשה לתכונה	בקשות להוספת תכונות ל-Aggregation Service: שילובים של שרת לשרת, מדידה במכשירים שונים, דיווח קל על שיוך של כמה נקודות מגע ועל תרומה, שיוך בערוצים שונים ותמיכה בלולאות אופטימיזציה מתקדמות של למידת מכונה (למשל, אימון מודל פרטי).	אנחנו בודקים את הבקשות האלה ונשתף פרטים נוספים כשיהיו לנו. אנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית לגבי העדיפות של הבקשות האלה.
בקשה לתכונה	בקשה להגדיר את הפרמטר EBS delete_on_termination כ-True בסביבת Terraform, כדי לצמצם את החששות לגבי האיפוס בזמן העדכון של קבוצת השירותים של הצבירה.	אנחנו בודקים את הבקשה הזו ונשתף פרטים נוספים כשיהיו לנו. אנחנו מזמינים אתכם לשלוח משוב נוסף מהסביבה העסקית לגבי הבקשה הזו, כדי שנוכל להבין אם היא בעדיפות גבוהה. אפשר לעשות זאת כאן.
מסמכים בהירות	בקשה לקבלת הנחיות לגבי מה שאפשר לשנות (למשל, ערכי סף למעקב) ומה לא צריך לשנות.	אנחנו שוקלים לפרסם מסמכי עזרה והנחיות נוספים לגבי ההתאמות האישיות הזמינות לשירות הצבירה.
פריסה	בקשה להבהרה לגבי פריסה חדשה שנכשלת בפקודה bazel.	ייתכן שהפריסה נכשלת בגלל גרסת bazel שמשמשת בסביבה. מסמכי התיעוד יותאמו כך שיכללו הסבר על ניפוי באגים כשיש כשלים ב-Terraform, וגם יצוין בהם גרסת bazel הנדרשת.

Private Aggregation API

נושא המשוב	סיכום	תגובה מ-Chrome
שימוש ב-API	בקשה לקבלת הדרכה לגבי כמה אתגרים בהטמעה, כמו אובדן נתונים פוטנציאלי עקב מגבלות שדווחו על אחסון משותף, קשיים בעוצמה גבוהה שדורשים רשימות מורכבות של היתרים ב-Aggregation Service (מומלץ להשתמש בתווית Wildcard), וירידה במהירות הבדיקה שנגרמת בגלל הכלל 'ללא כפילויות' של Aggregation Service.	לגבי המגבלות של Shared Storage, המגבלה של 20 תרומות (שמתוארת כאן) היא לכל הפעלה, ולא לכל חודש. בנוסף, מבצעי הקריאות ל-API יכולים לשנות את המגבלה הזו. המגבלה הזו נועדה לעזור בניהול העלות של עיבוד הדוחות בשירות הצבירה, ולא להגביל את השירות לדיווח. בנוגע לשאילתות עם תווים כלליים, אנחנו בודקים את הבקשה הזו ונשתף פרטים נוספים כשיהיו זמינים. בנוגע לכלל 'ללא כפילויות', כדי לאפשר בדיקה, אנחנו תומכים באופן זמני במצב ניפוי באגים כדי לעקוף את הכלל הזה. פרטים נוספים מפורטים כאן .
סינון של מזהים וקטגוריות	האם אפשר לבקש משירות הצבירה את אותו קטגוריון עם שני מזהי סינון שונים בשתי פעולות צבירה נפרדות, כלומר, האם מזהה הסינון יכול לשמש כחלוקה משלימה של דומיינים?	כן, יש תמיכה בתכונה הזו. כשמבצעים צבירת נתונים, המערכת מעבדת רק תרומות עם מזהה סינון שתואמת לרשימה בפרמטרים של המשימה, והשאר יישארו זמינות לעיבוד בהפעלות נפרדות.
ייחוס לכמה נקודות מגע	בקשות להבהרה לגבי הטמעת שיוך של כמה נקודות מגע (MTA): 1) האם יש מגבלה על מספר התרומות אם ערך הצבירה לא חורג מ-2^16? 2) האם יש מגבלה על מספר מפתחות הסיכום הייחודיים (קטגוריות) שאפשר לשמור בהקשר נתון? 3) איך שירות הצבירה מעבד דוחות סיכום כשלכל סוכן משתמש (דפדפן) יש מפתח צבירה ייחודי, כפי שעשוי לקרות ב-MTA?	1) הגדרנו מגבלות ברירת מחדל על התרומות, אבל למבצע הקריאה ל-API יש אפשרויות לשנות אותן, כפי שמוסבר כאן. המטרה של המגבלות היא לעזור למפעילי ה-API לנהל את העלות של עיבוד הדוחות בשירות האגרגציה. 2) אין מגבלה כזו, אבל מומחי טכנולוגיות הפרסום צריכים להביא בחשבון את רמת הפירוט של מפתחות הסיכום כדי לשפר את יחס האות לרעש, כפי שמוסבר בהרחבה כאן. 3) אפשר לעיין בהנחיות האלה, במיוחד בהנחיות לגבי יחס אות לרעש שצוינו למעלה בקטע 2).

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

הפחתת מידע בסוכן משתמש/רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש

נושא המשוב	סיכום	תגובה מ-Chrome
בקשה לתכונה	בקשה להוספת Sec-CH-UA-Robot להנחיות לקוח של סוכן משתמש (UA-CH), כי היא תאפשר לשרתים לזהות תנועה אוטומטית לצורכי התאמת תוכן, אבטחה וניתוח נתונים.	זהו תרחיש לדוגמה חשוב שנדון בקבוצות תקנים אחרות (כאן אפשר למצוא פרטים נוספים). אנחנו ממליצים לגורמים שמעוניינים בנושא להשתתף ולשלוח משוב. עם זאת, אנחנו סבורים ש-UA-CH לא יכול להיות הפתרון המתאים, מכיוון שתנועה אוטומטית יכולה לשנות בקלות את כותרות הבקשות של HTTP.

הגנה על כתובת ה-IP (לשעבר Gnatcatcher)

נושא המשוב	סיכום	תגובה מ-Chrome
פרטיות של כתובות IP	השארת כתובות IP זמינות לשימוש של Google מנוגדת ליעדים המוצהרים של Google בנושא פרטיות. אמנם Google טוענת שהיא מבצעת אנונימיזציה של נתונים באמצעות הגנה על כתובות IP, אבל המשתמשים צריכים להתחבר ל-Chrome כדי להשתמש בהגנה על כתובות IP, כך ש-Google עדיין לומדת את הזהויות שלהם.	הסיבות להתחברות הן למטרות של מניעת הונאות ושימוש לרעה, בעיקר הגבלת הקצב של הגישה לשרתים הווירטואליים. בנוסף, כדי להגן על פרטיות המשתמשים בהקשר של דרישת האימות, תכנון האסימון שלנו נעשה באמצעות חתימה עיוורת. כלומר, האסימון שהונפקה במהלך ההתחברות שונה מהאסימון שמשמש במהלך העברת הבקשות דרך שרת proxy, ולכן לא ניתן לקשר את האסימונים שהונפקו לזהות של המשתמש ב-Google בשלב מאוחר יותר. כלומר, Google לא יודעת מי המשתמש כשהתנועה שלו עוברת דרך שרת proxy במצב פרטי, למרות דרישת האימות למניעת הונאות.
פרטיות של כתובות IP	השימוש ב-IP הוא צעד בכיוון הלא נכון. אי אפשר למחוק אותם מהדפדפן, כמו קובצי cookie, ולמשתמשים אין את אותם אמצעי בקרה על שקיפות כמו שיש להם לגבי קובצי cookie. אם קובצי ה-cookie יוצאו משימוש, התעשייה תעבור להשתמש בכתוביות IP כפתרון חלופי, ותעדיף את השמירה על עצמה על פני הפרטיות.	כפלטפורמה, Chrome נועד לספק למשתמשים תכונות שמשפרות את חוויית הגלישה שלהם באינטרנט. משתמשי Chrome שבוחרים לגלוש במצב פרטי נהנים מהגנה משופרת מפני מעקב בכמה אתרים בו-זמנית, באמצעות הגבלת הזמינות של פרטי כתובת ה-IP בהקשרים של צד שלישי.
רשימת דומיינים מוסתרים	מהם קריטריוני הבחירה של רשימת הדומיינים הממוזערים (MDL)?	ב-Chrome פיתחו קריטריונים לזיהוי של הדומיינים שצריכים להיכלל ב-MDL, ולכן יקבלו כתובות IP אנונימיות בהקשר של צד שלישי. Google חברה ל-Disconnect.me, חברה מובילה בתחום הפרטיות באינטרנט שעובדת גם עם דפדפני אינטרנט אחרים. מערכת Chrome תשתמש ב-Disconnect.me כדי לזהות דומיינים שתואמים לקריטריונים של Chrome. בנוסף, ב-Chrome פיתחו שיטת זיהוי לפונקציות JavaScript נפוצות שמספקות תוצאות עקביות מממשקי API של אינטרנט יציבים עם אנטרופיה גבוהה, ולכן אפשר להשתמש בהן כדי ליצור מזהים סטטיסטיים עם אנטרופיה גבוהה. לאחר מכן, הפונקציות האלה מזוהות כשהן נטענות באתרים בהקשר של צד שלישי, וכתוצאה מכך נוצרת רשימה של דומיינים שמציגים סקריפטים עם המאפיינים האלה. הסקריפטים האלה הופכים לחלק מ-MDL ולכן עוברים דרך שרת proxy. צינור עיבוד הנתונים לזיהוי שמחפש את הדפוסים האלה של שימוש לרעה ב-API מתייחס לכל הדומיינים, כולל הדומיינים של Google.
מניעת הונאות	משוב על אסימוני חשיפת נתונים סטטיסטיים (PRT) לגבי העיכוב המוצע של 24 שעות ושיעור החשיפות המוצע, שמונעים זיהוי הונאות בזמן אמת. בקשה לעיכובים קצרים יותר (שעה אחת) ולשיעורים גבוהים יותר (לפחות מספרים דו-ספרתיים). הצעות נוספות כוללות הפעלת שיעורי חיוב שונים על סמך אותות סיכון (שרתי VPN, דפדפנים אוטומטיים) והרשאה לחשוף אסימונים ספציפיים באופן ממוקד.	רוב המפתחים שדיברנו איתם מספקים ללקוחות שלהם דיווחים שעתיים, וכמה מהם מעדכנים את רשימות החסימה של כתובות ה-IP במהלך היום. תקופת השהיה קצרה יותר מאפשרת עדכונים תכופים יותר, ותקופה של פחות משעה תפעיל מחדש את המדידה של IVT בנתונים הסטטיסטיים השעתיים, אבל היא גם עלולה להגדיל את הסבירות לזיהוי מחדש של משתמשים. אנחנו פתוחים לבדוק את האפשרות לקצר את תקופות ההשהיה ולשנות את קצב החשיפה על סמך מחקרים של הסביבה העסקית ומשוב מבעלי עניין. נשמח לקבל משוב נוסף כאן.
רשימת דומיינים מוסתרים	שאלה לגבי הכללתו של דומיין ב-MDL למרות שאין לו תרחיש שימוש בפרסום. חשש שאפשר יהיה להשתמש ב'קישור כתובות IP' כדי ליצור פרופילים על סמך כתובות IP.	אנחנו מבינים את החשיבות של הטמעת תהליך ערעורים לגבי הגישה שלנו שמבוססת על רשימות. ערעורים מאפשרים לחברות לטעון שהדומיין שלהן ב-MDL לא עומד בקריטריונים להכללה וצריכים להסיר אותו, וכך לאפשר לדומיין להמשיך לקבל את כתובות ה-IP המקוריות של המשתמשים בהקשר של צד שלישי במצב פרטי. השקנו עכשיו את תהליך הערעורים כדי לתת לבעלי הדומיינים מספיק זמן להגיש ערעור ולקבל החלטה לפני ההשקה של הגנה על כתובות IP במצב פרטי בגרסה היציבה של Chrome. פרטים נוספים על תהליך הערעור זמינים כאן.
רשימת דומיינים מוסתרים	משוב על כך שבעלי תוכן דיגיטלי בודקים את ההשלכות של הכללתם של השותפים שלהם ב-MDL. הם הרגישו בטוחים יותר אחרי שקראו את ההסבר על הגנה על כתובות IP, שבו מפורטות ההוראות לגבי GeoIP.	אנחנו ב-Chrome מבינים את החשיבות של תמיכה בתרחישי שימוש מבוססי-מיקום. שרת ה-proxy יקצה כתובות IP שמייצגות את המיקום המשוער של המשתמש, כולל המדינה. מידע נוסף זמין במאמר הסבר על איתור גיאוגרפי לפי כתובת IP.
רשימת דומיינים מוסתרים	שאלה לגבי MDL: האם עדיין אפשר לטרגט ברמת המדינה?	אנחנו ב-Chrome מבינים את החשיבות של תמיכה בתרחישי שימוש מבוססי-מיקום. שרת ה-proxy יקצה כתובות IP שמייצגות את המיקום המשוער של המשתמש, כולל המדינה. מידע נוסף זמין במאמר הסבר על איתור גיאוגרפי לפי כתובת IP.
זיהוי הונאות	חששות לגבי ההשפעה של הגנה על כתובות IP על מערכות לזיהוי הונאות. האם המשתמשים יראו כתובות IP של שרת proxy או כותרת? האם ל-SSP ול-DSP יוצגו אותן כתובות IP של שרת proxy לשימוש נתון? חוסר עקביות עלול להשפיע על זיהוי הונאות ועל OpenRTB.	משתמשים שגולשים במצב פרטי עם הגנה על כתובת ה-IP וששולחים בקשות לדומיינים ב-MDL יקבלו כתובת IP של שרת proxy על סמך פיד גיאוגרפי מוגדר. ארגונים יכולים לבקש שה-PRTs יועברו ככותרת נוספת בתעבורה דרך שרת proxy, שבה ניתן לחשוף דגימה קטנה של כתובות IP מקוריות לאחר תקופת עיכוב. אנחנו מניחים שספקי SSP רבים יעבירו את כתובת ה-IP של שרת ה-proxy שלהם בבקשות להצעות מחיר בצד השרת לשותפי הביקוש שלהם, אבל אין ערובה שפלטפורמות ה-DSP הזוכות יראו את אותה כתובת IP של שרת ה-proxy בזמן החשיפות.
זיהוי הונאות	שאלות לגבי תדירות העדכון של קובץ המיקום הגיאוגרפי של כתובת ה-IP, תזמון העדכון של פרטים לגבי דיווח על התנהגות שמקורה בתרמית ועל נכסי PRT, ואופן הזיהוי של פעילויות שמקורן בתרמית על ידי טכנולוגיית הפרסום.	ההסבר על שרתי ה-PRT פעיל, וכך גם הרשימה של כתובות ה-IP של שרתי ה-Proxy והאזורים הגיאוגרפיים הממופים שלהם. מומלץ לבדוק מדי פעם את הקובץ הזה כדי לראות אם יש עדכונים ושינויים, כי כתובות ה-IP יתחלפו עם הזמן. כתובת האימייל הציבורית לדיווח על ניצול לרעה תפורסם קרוב יותר להשקה.
מיקום גיאוגרפי	בקשה לקבלת רשימה ציבורית של כתובות IP שמשמשות לשרתים proxy.	הקובץ שממפה כתובות IP למיקומים גסים לצורך הגנה על IP זמין כאן. חשוב לדעת שהקובץ הזה מתעדכן מדי פעם.
שימוש ב-API	טענת נכוֹנוּת (assertion) לפיה נראה שהתכונה 'הגנה על כתובת ה-IP' מופעלת כברירת מחדל, ולא ניתנת למשתמשים אפשרות לבטל את ההסכמה לשימוש בה.	הגנה על כתובת ה-IP תהיה זמינה למשתמשים במצב פרטי ב-Chrome, בפלטפורמות Android ו-Desktop. המשתמשים יוכלו להשבית את ההגנה על כתובת ה-IP. בגרסאות של Chrome בניהול ארגוני, אפשר להפעיל את ההגנה על כתובת ה-IP, אבל היא תהיה מושבתת כברירת מחדל.
שימוש ב-API	פנייה לגבי הזמינות של דגל ניסיוני להפעלה ובדיקה של הגנה על כתובות IP במהדורות הבטא וה-Canary של Chrome.	בשלב זה אין לנו דגל ניסוי זמין לבדיקה של התכונה המלאה של הגנה על זכויות יוצרים באינטרנט. הניסויים הפונקציונליים שאנחנו עורכים כוללים רק תנועה דרך שרת proxy שמגיעה לדומיינים של Google.
פרטיות של כתובות IP	איך פועלות ההגדרות של הבקשות ל-3PC כשהדפדפן עובר למצב פרטי?	קובצי cookie של צד שלישי חסומים כברירת מחדל במצב פרטי.
מצב פרטי	רציתי לקבל הבהרה לגבי האופן שבו התכונה 'הגנה על כתובת ה-IP' פועלת במצב פרטי כשהמשתמש לא מחובר ל-Chrome.	ההגנה על כתובת ה-IP לא פעילה אם המשתמש לא נכנס לחשבון ב-Chrome לפני שהוא עבר למצב פרטי. הסיבות לכך הן למטרות של מניעת הונאות ושימוש לרעה, כלומר הגבלת הקצב של הגישה לשרתי ה-proxy. בתכונה 'הגנה על כתובות IP' נעשה שימוש באימות לקוח כדי להגביל את היכולת של גורמים זדוניים לנצל את שרת ה-proxy כדי להגביר התקפות על שירותים ב-MDL. לכן, הגנה על כתובת ה-IP תהיה זמינה רק למשתמשים שעברו אימות באמצעות חשבון Google שאליו הם מחוברים בדפדפן Chrome לפני פתיחת חלון פרטי חדש.
מצב פרטי	בקשות להערכת ההשפעה של הגנה על כתובת ה-IP לפני ההשקה, כולל: (1) הצעה להשתמש בדגל של מצב הדפדפן או בדיווח מצטבר של API כדי לכמת את השימוש במצב פרטי; (2) שליחת כותרת של הגנה על כתובת ה-IP למשך תקופה מסוימת לפני הפעלת התכונה; ו (3) שליחת התכונה לאחוז קטן וידוע מתנועת הגולשים לצורך אקסטרפולציה.	אנחנו מבינים את העניין של הסביבה העסקית ביכולת להבין ולמדוד את ההיקף וההשפעה של הגנה על קניין רוחני. עם זאת, אנחנו ב-Chrome פועלים כדי לשמור על הפרטיות של הבחירה של המשתמשים לגלוש במצב פרטי. ב-Chrome לא קיימת שיטה לזיהוי משתמשים שמשתמשים במצב פרטי, ונקטנו פעולות כדי להגביל אותות אחרים שעשויים לחשוף את מצב הגלישה של המשתמש. אנחנו שוקלים דרכים להקל על הבדיקה הזו בלי להשפיע על הפרטיות של משתמשים שגולשים במצב פרטי, ונשמח לקבל משוב נוסף מהסביבה העסקית.

Bounce Tracking Mitigations

נושא המשוב	סיכום	תגובה מ-Chrome
תאימות	לסירוב של Google לאשר שימוש בשיטה של הפחתת ההשפעה של מעקב אחר נטישות (BTM) שתואמת לחקיקה בנושא הגנה על נתונים אין בסיס משפטי, והוא הופך את תהליך הערעורים של Sandbox לפרטיות ללא תועלת.	כפי שהסברנו בדוח המשוב הקודם שלנו, לסטטוס התאימות אין קשר להחלה של BTM, ו-Google לא מקבלת החלטות לגבי תאימות בהטמעת BTM. במקום זאת, בדומה לשיטות אחרות להגנה על הפרטיות ב-Chrome, התכונה BTM מתמקדת בשיפור השליטה של המשתמשים באפשרות לשתף את הנתונים שלהם ובאופן שבו הם משותפים. תהליך הערעורים המנוהל על ידי צד שלישי שצוין בדוח של CMA לרבעון 2/3 ספציפי לתחומים שבהם Google מקבלת החלטות לגבי הכללה או החרגה של חברות ספציפיות ברשימות.
תאימות	דיון על האופן שבו הדפדפנים מבטיחים תאימות לפעולות שקיבלו הסכמה חוקית בהקשר של GDPR, תוך הדגשת תרחישים שבהם הדפדפנים עשויים לדכא פעולות (כמו הפניות אוטומטיות או הגדרת קובצי cookie) שהמשתמשים הביעו הסכמה מפורשת לביצוען, וכתוצאה מכך נוצר קונפליקט בין הסכמה משפטית לבין הגדרות הפרטיות בדפדפן.	הדפדפן לא יכול לראות את אופי הקשר בין משתמש לאתר. בנוסף, בהתאם להתנהגות הנוכחית של BTM, כבר יש פתרונות חלופיים שמאפשרים למשתמש להביע הסכמה מפורשת למעקב אחר ביקורים לאתר מאתר נתון. מידע נוסף בנושא תאימות זמין בשאלות נפוצות בנושא תאימות שקשורות לפרטיות.
אתרים לשימוש כפול	האם יש לך שאלות לגבי ההגדרה של 'אתרים לשימוש כפול' במסגרת התוכנית 'תוכנית שותפי ה-Google Ads' (BTM)? האם מעברים מ-WebView או מאפליקציה לאינטרנט (Chrome) ייחשבו כ'אתרים לשימוש כפול'?	הדפדפן לא יכול לראות אם שרשרת עזיבה החלה במעבר מ-WebView או מאפליקציה. לכן, מערכת BTM לא מטפלת בתהליכים האלה באופן מיוחד. במקום זאת, המערכת מפרשת את התהליך כנטישה בין אתרים, שמתחילה בדף about:blank, וממשיכה בתהליך הרגיל.

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

קבוצות של אתרים קשורים (לשעבר 'קבוצות מאינטראקציה ישירה')

נושא המשוב	סיכום	תגובה מ-Chrome
שימוש ב-API	חששות לגבי אפשרות לניצול לרעה של RWS בשילוב עם הגנה על קניין רוחני. חשיפת כתובות IP לארגונים בתוך קבוצת RWS עשויה לעודד ארגונים להצטרף לכמה קבוצות RWS כדי לקבל גישה לנתוני כתובות IP ניידים לצורך מעקב אחר משתמשים ב'פרטיות מוחלטת'.	הדרישות של הקבוצות לאתרים המשויכים, לאתרי השירות ולקבוצות ככלל, שמופעלות על ידי אימותים אוטומטיים, מצמצמות את התמריץ לנסות להצטרף לכמה קבוצות. כדי לצרף פעילות משתמשים בין קבוצות באמצעות כתובות IP, צריך לכלול דומיין MDL בקבוצה. לשם כך, צריך תיאום בין הבעלים של הקבוצה לבין הבעלים של הדומיין. אותו סיכון רלוונטי לאתרים בודדים (כלומר, ללא קבוצה של אתרים קשורים) שמתואמים עם דומיינים של MDL. התשובה לשאלה הזו מפורטת כאן.

Fenced Frames API

נושא המשוב	סיכום	תגובה מ-Chrome
פרסום מותאם	משוב על כך שהפורמט 'פריימים מוקפים', כפי שהוא מתוכנן כרגע, לא תואם למודל העסקי שלהם לפרסום מותאם אישית, שמחייב שהמודעות יתאימו בצורה גמישה לתוכן שמסביב.	אנחנו ממשיכים להעריך את הצרכים של הסביבה העסקית ואת המוצרים הקיימים של 'מסגרות מוקפות'. בכל מקרה, כפי שצוין קודם, שימוש ב-Fenced Frames יהיה נדרש לא לפני 2026.

Shared Storage API

נושא המשוב	סיכום	תגובה מ-Chrome
באג ב-API	דיווח על כך שמערכת Chrome מתעדת שגיאה כשמנגנון התקציב של Shared Storage API מונע את הפעלת הפעולה selectURL, למרות שזו התנהגות צפויה. מבקשים מ-Chrome להוריד את רמת הרישום ביומן משגיאה לאזהרה או למידע, כי אין לקריאה החוזרת אפשרות לפעול לפי השגיאה.	השינוי הזה הוטמע וכלל ב-Chrome M134, שזמין החל מ-4 במרץ 2025.

CHIPS

נושא המשוב	סיכום	תגובה מ-Chrome
תיעוד API	דרוש הבהרה לגבי אמצעי ההגנה על האבטחה שמציעים קובצי cookie מחולקים בהשוואה לקובצי cookie עם SameSite=Lax/Strict. הצעה: במסמכי התיעוד צריך לציין במפורש שקובצי cookie מחולקים לא מספקים את אותה רמת הגנה מפני התקפות XSS ו-CSRF כמו קובצי cookie עם SameSite=Lax/Strict.	נעדכן את ההסבר ואת המפרט כדי להבהיר את הסמנטיקה וההגנות שמציעים קובצי cookie מחולקים.

FedCM

נושא המשוב	סיכום	תגובה מ-Chrome
ממשק משתמש ואבטחה	משוב על כך שממשק המשתמש של FedCM דומה מדי לממשק ההתחברות הקודם של Google בנגיעה אחת, שקשה לכמת את ביצועי FedCM בגלל היעדר מעקב פסיבי אחר הצגה, והמלצה לשפה חזקה יותר במסמכי העזרה לגבי PKCE.	אנחנו פועלים באופן פעיל מול בעלי העניין כדי לטפל במשוב שהם מספקים. בין הנושאים שאנחנו ממשיכים לדון בהם: דרכים לספק מדדים טובים יותר ל-IdPs כדי לאפשר להם לעקוב אחרי ביצועי FedCM, ושיפורים אפשריים כדי לטפל בתרחישי שימוש חדשים של FedCM שקשורים לתרחישי שימוש של מינויים.
שימוש ב-API	כשמשתמש מרענן את הדף וקורא ל-navigator.credentials.get כדי להתחבר, מופיע חלון קופץ שמחייב את המשתמש ללחוץ כדי להמשיך. כתוצאה מכך נוצר עיכוב שמשפיע על חוויית המשתמש. האם צדדים נסמכים (RP) יכולים לשמור במטמון את האסימון שמוחזר על ידי navigator.credentials.get כדי לשפר את חוויית המשתמש?	ספקי RP יכולים להשתמש בקובצי cookie משלהם כדי לאחסן את האסימון. לאחר מכן, ספקי ה-RP יכולים לבדוק את קובצי ה-cookie שלהם כדי לקבוע אם משתמש מחובר לפני שמפעילים את navigator.credentials.get. כאן מוסבר בהרחבה על הנושא.
בחירה של כמה ספקי IdP	איך הדפדפן יציג את אפשרויות ההתחברות של כמה ספקי זהויות (IdPs) ב-FedCM?	במסמכי התיעוד למפתחים מוסבר איך מוצגים כמה ספקי IdP. בעלי עניין יכולים להתנסות בפונקציונליות הזו על ידי הפעלת הדגל fedcm-multi-idp בכתובת chrome://flags.
דפדפנים וספקי IdP	האם דפדפן, כמו Chrome, יכול לפעול כ-IdP בעצמו? דפדפנים יכולים להשתמש בנתוני החשבון והפרופיל השמורים שלהם כמקור מהימן לאימות.	מכיוון שאפשר לשנות דפדפנים (למשל באמצעות תוספים), אי אפשר לסמוך על הצהרות על אימות אימייל שמתקבלות ישירות מהדפדפן בלי אימות נוסף שמבוסס על שרת. לכן, לא מומלץ להשתמש בפתרון שמבוסס אך ורק על הלקוח. הרחבנו על הנושא הזה כאן.
מפרט API	דיון לגבי הצורך בפרמטר של האלגוריתם IdentityCredential.disconnect().	השגיאה תוקנה. פרטים נוספים זמינים כאן.
אבטחת API	חששות לגבי דליפת אסימונים בתהליך ההתחברות ל-FedCM אם ל-RP יש נקודת חולשה מסוג XSS. תוקף יכול להריץ את navigator.credentials.get בקוד זדוני כדי לקבל את האסימון.	FedCM לא יוצר סיכוני XSS חדשים. הסיכונים האלה מובנים באפליקציות אינטרנט ובפרוטוקולים קיימים לאימות. כדי לצמצם את הסיכונים האלה, ספקי ה-RP צריכים לאמת את הצהרת ה-aud באסימוני מזהה, ולקבל רק טענות נכוֹנוּת (assertions) שהונפקו במקור שלהם. כפי שצוין כאן, יש שיטות מומלצות מקובלות לאבטחת המרת האסימונים הזו, שקיימות היום וזמינות לשימוש עם FedCM. בנוסף, אפשר להשתמש ב-Storage Access API עם FedCM, וקריאות ל-Storage Access API ניתנות באופן אוטומטי כשיש קריאה קודמת ל-FedCM. הפעולה הזו אמורה להפעיל את תהליך ההפניה האוטומטית המוטמעת שתואר בבעיה ב-GitHub.
מפרט API	השדה client_metadata_endpoint הוא שדה חובה בתגובה של נקודת הקצה של ההגדרות ב-FedCM. אובייקט ריק הוא תשובה תקינה, ו-Chromium מתעלם בשקט מתשובה מסוג 404, מה שמצביע על כך שבפועל נקודת הקצה נחשבת כאופציונלית.	אנחנו מסכימים שאפשר לשנות את המפרט כך שישקף את זה, ולהפוך את client_metadata_endpoint לשדה אופציונלי.
שימוש ב-API	חששות לגבי הקושי לבדוק הטמעות של FedCM בגלל ממשקי משתמש שנשלטים על ידי הדפדפן ולא ניתן לגשת אליהם דרך DOM.	אנחנו תומכים ב-APIs של אוטומציית הדפדפן לצורך בדיקות רגרסיה, ויכול להיות שהן יטפלו בבעיות האלה. המסמכים של ממשקי ה-API האלה מפורטים כאן.
מפרט API	הפרמטר login_url, שהוא חלק נדרש בתגובה של נקודת הקצה של ההגדרות, לא תועד בקטע 3.2 במפרט.	שלחנו עדכון למסמכי העזרה, כך שיכללו את הפרמטר login_url בקטע 3.2.
מפרט API	חשש לגבי גורם מעקב פוטנציאלי ב-FedCM. IdP יכול להוסיף מזהים כפרמטרים של נתיב לנקודות הקצה שצוינו בתשובה של נקודת הקצה של התצורה (accounts_endpoint,‏ client_metadata_endpoint), ולהשתמש במזהים האלה כדי למצוא התאמה בין הבקשות של המטא-נתונים של החשבון לבין הבקשות של המטא-נתונים של הלקוח.	אין לנו עדות לכך ש-IdPs מוסיפים מזהי משתמשים לנקודות הקצה האלה, אבל אנחנו בוחנים דרכים לצמצם את הבעיה הזו כאן.

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

Private State Tokens API (וממשקי API אחרים)

לא התקבל משוב ברבעון הזה.