דוח משוב – רבעון 2 בשנת 2025

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

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

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

התחשבות בתצפיות של צדדים שלישיים

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

ARA

‫

Attribution Reporting API

CHIPS

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

DSP

פלטפורמה לניהול ביקושים

FedCM

ניהול מאוחד של פרטי כניסה

IAB

Interactive Advertising Bureau

IDP

ספק זהויות

IETF

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

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

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

openRTB

‫

Real-time bidding

הארכה

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

PA API

‫

Protected Audience API (לשעבר FLEDGE)

PatCG

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

RP

צד נסמך

RWS

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

SSP

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

UA

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

UA-CH

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

W3C

World Wide Web Consortium

WIPB

התעלמות מכוונת מכתובות IP

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

נושא המשוב	סיכום	תגובה של Chrome
העתיד של ארגז החול לפרטיות	לאור ההודעה שלא נמשיך בהשקת מנגנון לבחירת המשתמשים לגבי קובצי Cookie של צד שלישי, חלק מממשקי ה-API שימושיים יותר מאחרים כשיש קובצי Cookie של צד שלישי, וחלקם יצטרכו להתפתח כדי להיות שימושיים. יש תחומים נוספים שבהם כדאי להשקיע ב-Chrome מעבר לממשקי ה-API של ארגז החול לפרטיות.	אנחנו מעריכים את המשוב שקיבלנו וממשיכים לקיים דיונים עם בעלי עניין כדי להעריך את התפקיד שממשקי ה-API של ארגז החול לפרטיות יכולים למלא בעתיד, וגם כדי לבחון תחומים חדשים להשקעה עתידית, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
ארגז החול לפרטיות	חלק מהמשתתפים במערכת האקולוגית מאוכזבים מההודעה שלא נמשיך בהשקת מנגנון לבחירת המשתמשים בנוגע לקובצי Cookie של צד שלישי, אבל הם גאים בעבודה שהושלמה, מעריכים את האתגרים הטכניים בארגז החול לפרטיות ומדגישים את הערך של שיתוף הפעולה שלהם עם Chrome ואת התועלת של מענק בדיקת השוק.	אנחנו מעריכים את המשוב ומסכימים ש-Chrome יכול וצריך לשתף פעולה עם מפתחים כדי ליצור טכנולוגיות שישפרו את הפרטיות באינטרנט תוך שמירה על אינטרנט עם הכנסות מפרסום.
שיתוף נתונים בדפדפן	שיתוף נתונים באמצעות דפדפן הוא טכנולוגיה מבטיחה שיכולה לטפל בבעיות של חוסר יעילות בשוק ובבעיות שקשורות לאמון. הדפדפן יכול לשמש כסביבת הפעלה של צד שלישי לשיתוף פעולה.	אנחנו מעריכים את המשוב ומסכימים ש-Chrome יכול וצריך למלא תפקיד בעזרה למפתחים ליצור טכנולוגיות שמחזקות את האמון בין מפתחים משתפים לבין משתמשים.
תנועה ב-Chrome	מהו שיעור התנועה ללא קובצי Cookie ב-Chrome ומהו שיעור התנועה במצב פרטי?	כפי שצוין בהודעה על הכוונה לפרסם התחייבויות של CMA, מצב פרטי משפיע רק על חלק קטן מאוד מפעילות הגלישה. בכל אחת מהמדינות בבריטניה וב-EEA, מצב פרטי בדפדפן Chrome מייצג: פחות מ-10% מהניווטים במכשירים שפועלת בהם מערכת ההפעלה Android; ופחות מ-10% מהניווטים במכשירים שפועלת בהם מערכת ההפעלה Windows. המדדים האלה מתייחסים לניווטים רק ב-Chrome שמבוסס על Chromium בבריטניה וב-EEA. אנחנו לא משתפים נתונים על דפדפנים שחוסמים קובצי Cookie של צד שלישי. מפתחים יכולים לקבוע מתי קובצי Cookie מחולקים למחיצות באמצעות כותרות של גישה לאחסון ולהשתמש באמצעי ההגנה הזמינים בהתאם.
תוויות של Chrome for Testing	מהי התוכנית של Chrome לגבי 1% מהתנועה ללא קובצי Cookie שהופעלה לבדיקה בשנת 2024?	בשלב הזה אין לנו תוכניות לשתף את הנתונים, אבל אנחנו מתכוונים לשתף אותם באופן פומבי ברגע שהם יהיו זמינים.
Chrome Testing	האם הגדרת התווית הנוכחית של הבדיקה כוללת טיפול בתרחישים שבהם גם 3PC וגם ממשקי Privacy Sandbox API זמינים ומופעלים?	ההגדרה הנוכחית של תוויות הבדיקה כוללת טיפול גם בקובצי Cookie של צד שלישי וגם בממשקי Privacy Sandbox API, בצורה של מצב א'.
ארגז החול לפרטיות	חלק מהמפרסמים חושבים שממשקי Privacy Sandbox API הם מורכבים, והם לא מתלהבים מהם בגלל תרגילי מוכנות קודמים. הם תוהים איך אפשר לכמת את היתרון של מי שמטמיע את ממשקי ה-API בשלב מוקדם, ומחפשים מידע על ההשפעות של רימרקטינג, איתור לקוחות פוטנציאליים ומדידה.	אנחנו מעריכים את המשוב ומבינים את התחושות לגבי המורכבות הטכנולוגית והתרגילים למוכנות. בנוגע להבנת הביצועים של הטכנולוגיות הנוכחיות של ארגז החול לפרטיות, תוצאות הבדיקות שלנו הצביעו על כך שהשתתפות בסביבה העסקית היא גורם קריטי בהבנת הביצועים של הפתרונות של ארגז החול לפרטיות. בדיקות בהיקפים קטנים לא יכולות לשחזר את הדינמיקה של השוק ואת התמריצים לשימוש בטכנולוגיות בהיקף גדול.

הרשמה ואישור

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

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

נושאים

נושא המשוב	סיכום	תגובה של Chrome
שיפורים ב-Topics API לשיפור הביצועים והתועלת	משוב מבעלי עניין בצד הקונה מצביע על כך ש-Topics API הוא אות בעל ערך, והוא מספק נתונים של עלות לאלף חשיפות (CPM) שהם תחרותיים ביחס לנתונים של קהלים מ-3PC, עבור קמפיינים של מפרסמים. חלק מבעלי התוכן הדיגיטלי רואים באות של Topics API אות איכותי יותר מאותות רגילים באינטרנט הפתוח. בעקבות המשוב הזה על התועלת של Topics API, בעלי עניין מבקשים שיפורים, כמו שיפור הדיוק והעקביות של הטקסונומיה והרחבת אמצעי הבקרה של בעלי האתרים כדי להגדיל את היקף השימוש ב-API.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
התועלת לבעלי עניין מסוגים שונים	בשלב הזה, מסווג הנושאים משתמש רק בשם המארח של הדף כדי להגדיר את הנושאים התואמים. לכן, אתרים גדולים עם תוכן מגוון תורמים נושאים כלליים, ואתרים קטנים תורמים נושאים נישתיים עם ערך פרסומי גבוה יותר.	התשובה שלנו דומה לתשובות שנתנו ברבעונים הקודמים: בדומה לעוגיות של צד שלישי, יש הבדל בערך המידע שמתקבל מאתרים שונים. הערך שאתרים עם תחומי עניין נישתיים תורמים הוא לא עקבי: לא בכל האתרים האלה יש תוכן בעל ערך מסחרי, ולכן הם תורמים פחות ערך. אלה האתרים שיפיקו תועלת מ-Topics API. שקלנו אפשרות לסווג דפים ולא אתרים, אבל יש כמה בעיות משמעותיות שקשורות לפרטיות ולאבטחה בסיווג כזה.
הטקסונומיה של Topics לא מפורטת מספיק	‫Topics API לא מספק רמת פירוט מספקת לבעלי אתרי חדשות עם קטעי תוכן מגוונים בדומיין יחיד, ולכן יכול להיות שהשימוש ב-API לטירגוט מודעות יהיה מוגבל.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
שיפור המסווג	בעלי תוכן דיגיטלי יכולים לתת ל-Chrome הרשאות לסווג נושאים על סמך תוכן הדף (למשל, head, ‏ body).	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.
מדיניות	בקשה להבהרה בנוגע להנחיות לשימוש ב-Topics API בשילוב עם מידע של צד שלישי (3PC).	אין בעיה להשתמש גם ב-Topics API וגם ב-3PC, כי Topics API מספק קבוצת משנה של הפונקציות של 3PC.
כותרת של התכונה 'נושאים שנצפו'	בקשה להבהרה בנוגע להטמעה של הכותרת Observe-Browse-Topics, ובפרט אם החזרה רציפה של הכותרת תגרום לבעיות.	החזרת הכותרת Observe-Browse-Topics: ?1 באופן רציף לא תגרום לבעיות טכניות. הדפדפן מטפל באות הזה ביעילות, ופשוט מציין שהביקור בדף עומד בדרישות לחישוב הנושאים, בלי לגרום לשכפול או לשגיאות. אף על פי שהיא לא נדרשת בכל דף, שליחה שלה ככותרת רגילה בכל המסמכים ברמה העליונה היא אסטרטגיה פשוטה ותקפה.
קטגוריות טקסונומיה	בקשה לעדכן את הטקסונומיה האחרונה של Topics עם נושאים חדשים.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית כאן.
ערכי Null	בקשה לקבלת הנחיות לשיפור הביצועים של Topics API ולהבנת הסיבות לתשובות null, כמו סינון או רגישות.	חשוב להבהיר: התשובות null או תשובות ריקות מ-Topics API הן תכונת פרטיות צפויה, ולא שגיאה. תגובת null יכולה לנבוע מהסיבות הבאות: • כללי פרטיות: סיכוי אקראי של 5% לתגובה null, או כי הסקריפט לא "עקב" אחרי המשתמש באתרים שקשורים לנושא הזה. • מצב המשתמש: היסטוריית גלישה לא מספקת, שימוש במצב פרטי או שהמשתמש ביטל את ההסכמה בהגדרות הפרטיות של המודעות ב-Chrome. • שגיאות טכניות: אתרים של בעלי תוכן דיגיטלי צריכים לשלוח את הכותרת Observe-Browse-Topics: ?1, וכל iframe שקורא ל-API צריך את ההרשאה allow="Browse-topics". כדי לבדוק את הנושא, אפשר להשתמש בדף chrome://topics-internals debugging (ניפוי באגים) כדי לראות אילו נושאים הדפדפן חישב ולמה. תכונות הפרטיות מונעות שיעור מילוי של 100%, אבל אפשר לשפר את הביצועים באמצעות: • עבודה עם בעלי תוכן דיגיטלי: מוודאים שהשותפים שולחים את הכותרת Observe-Browse-Topics: ?1 בצורה נכונה באתרים שלהם. • אימות הקוד: אם אתם משתמשים ב-iframe, ודאו שהמדיניות allow="Browse-topics" מיושמת.

Protected Audience API

נושא המשוב	סיכום	תגובה של Chrome
העלות והמורכבות של PA API מקשות על הטמעתו	המשתמשים ב-Protected Audience API ‏(PA API) נותנים עדיפות נמוכה יותר לשילובים של PA API או מבטלים אותם, בגלל עלויות תפעול, היעדר ביקוש מצד מפרסמים ונפח נמוך של מלאי שטחי פרסום בבורסות. חלק מהמשוב כלל יתרונות של הפוטנציאל של PA API, כמו היכולת שלו לספק קהלים עמידים ופוטנציאל חשיפה גבוה יותר בגלל שיעור התאמה גבוה.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
פונקציונליות בפלטפורמות שונות	צריך לתמוך בפונקציונליות בפלטפורמות מרובות באמצעות PA API בפלטפורמות שונות כדי להרחיב את היכולות של הטירגוט מחדש וטירגוט הקהלים. ‫Google צריכה לאפשר גישה לקבוצות של נושאים משותפים (IG) שרשומות ב-Chrome כשמוצגות מודעות בסביבות מקוריות או ב-WebView, וקבוצות של נושאים משותפים שרשומות ב-Android צריכות להיות זמינות במכרזים של Chrome.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
directFromSellerSignals	הגבלת כמות המידע שזמין במכרז ההקשרי מבטיחה שהמשתתפים במכרז תמיד ינותבו דרך שרת הפרסום של Google. בעל האתר צריך להתקשר קודם לכל שותפי הבידינג שלו, אחר כך ל-Google Ad Manager‏ (GAM) כדי להפעיל את המכרז ההקשרי, ולבסוף לאפשר ל-GAM להפעיל מכרזים של IG. בלי לדעת את התוצאה של המכרז ההקשרי בזמן אמת, אף מתחרה לא יכול לתאם באופן הוגן החלטה ברמה העליונה. יכול להיות שבתכונה directFromSellerSignals ב-PA API חסרה שקיפות לגבי מידע על מכרזים, מה שעלול להקשות על הגישה לנתונים הנדרשים. ‫Google צריכה להסיר את directFromSellerSignals או לעדכן אותו כך שלא ניתן יהיה להשתמש בו כדי להסתיר את מחיר הסף במכרז של שרת הפרסום. לדוגמה, אפשר להעביר את המחיר ההקשרי דרך Chrome באמצעות שדה שקוף, קבוע וחתום שכל המשתתפים במכרז (וגם בעל האתר) יכולים לגשת אליו ולאמת אותו.	התשובה שלנו לא השתנתה מהרבעונים הקודמים: תשובה של Chrome: לא ידוע שהמידע שמועבר אל runAdAuction() מגיע מהמוכר, אלא אם המוכר קורא ל-runAdAuction() מתוך iframe משלו. במכרז עם כמה אתרי מכירה, אי אפשר לגרום לכל אתרי המכירה ליצור את המסגרת שקוראת ל-runAdAuction(). הפונקציה directFromSellerSignals פותרת את הבעיה הזו על ידי טעינת תוכן מחבילת משנה של משאבים שטוענת את המקור של אתר המכירה. כך אפשר לוודא שלא ניתן לבצע מניפולציה במידע שמועבר למכרז מההגדרות של מכרזים של מוכרים, ושהמידע אותנטי ושלם. אם בעלי אתרים רוצים להשתמש ב-PA API כדי להבין את המידע שספקי הטכנולוגיה שלהם מעבירים למכרזי PA, הם יכולים לבקש מהספקים האלה את הפונקציונליות הזו. תגובה מ-Google Ad Manager: אנחנו מתמקדים בהבטחת הוגנות במכירות פומביות כבר שנים, כולל ההבטחה שלנו שאף מחיר מאף אחד ממקורות הפרסום הלא מובטחים של בעל האתר, כולל מחירים של פריטים לא מובטחים, לא ישותף עם קונה אחר לפני שהוא יגיש הצעת מחיר במכירה הפומבית. לאחר מכן אישרנו מחדש את ההבטחה הזו בהתחייבויות שלנו לרשות התחרות הצרפתית. במכרזים של Protected Audience, אנחנו מתכוונים לקיים את ההבטחה שלנו באמצעות שימוש ב-directFromSellerSignals, ולא לשתף את הצעת המחיר של אף משתתף במכרז עם אף משתתף אחר במכרז לפני השלמת המכרז במכרזים עם מספר אתרי מכירה. חשוב להבהיר שלא נשתף את המחיר של המכרז ההקשרי עם המכרז הרכיבי שלנו, כפי שמוסבר בעדכון הזה.
דיווח	שליחת בקשה להוספת ישות של ניתוח נתונים או דיווח כדי להפעיל דיווח מרכזי.	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף.
K-Anonymity on buyerReportingId	אפשרות לפסול הצעות מחיר על סמך האנונימיות מסוג k של הפרמטר buyerReportingId, כדי להקל על יצירת קהלים ועל עמידה בחובות דיווח מול ספקי נתונים של צד שלישי.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
שיפור בניפוי באגים בסקריפט generateBid	בקשה למנגנון שיזהה במהירות את השלב הספציפי או את נקודת ההפסקה בסקריפט generateBid שבה התהליך נכשל.	אנחנו מודעים לשימוש הרצוי במדידות בזמן אמת כמנגנון להגדרת נקודות עצירה במכרזים במכשיר. אנחנו מתייחסים למשוב הזה במסגרת הבדיקה שלנו לגבי התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים בנוגע לקובצי Cookie של צד שלישי ב-Chrome תישמר.
Event Listeners למעקב אחר המצב של runAdAuction	הצעה להוסיף תמיכה ב-event listener לפונקציה navigator.runAdAuction של PA API כדי לשפר את המעקב אחרי מחזור החיים של מכרז הפרסום.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית כאן.
שימוש ב-API	הייתי רוצה לקבל הבהרה לגבי האופן שבו PA API ו-Attribution Reporting API ‏(ARA) יכולים לתמוך בתרחישי שימוש בפרסום באינטרנט בהיעדר קובצי Cookie של צד שלישי (3PC), במיוחד עבור משתמשים שהשביתו את קובצי ה-Cookie של צד שלישי אבל לא את ממשקי ה-API של ארגז החול לפרטיות, ובתרחישים שכוללים סנכרון קובצי Cookie שנכשל ו-WebView.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
זמן אחזור	זמן האחזור שמשויך ל-PA API עלול להפריע לאימוץ שלו, כי בעלי תוכן דיגיטלי עשויים להשבית את ה-PA API אם זמן האחזור גבוה מדי.	במהלך הרבעונים האחרונים ביצענו כמה שיפורים בחביון במכשיר. המשך פיתוח והרחבה של שירותי בידינג ומכרזים (B&A) לפי הצורך. עדכנו את המדריך שלנו לשיטות מומלצות בנושא זמן אחזור, ועכשיו הוא כולל מידע נוסף על הדרך להפיק תועלת מהתכונות האלה. אנחנו גם בודקים אפשרות לפתח שיפורים חדשים בנושא השהיה, וחלק מהם מפורטים כאן.
התנהגות הרישום ב-B&A (בדיקה לעומת ייצור)	הבהרה לגבי ההבדלים בהתנהגות הרישום ביומן בין מצב בדיקה למצב ייצור בשירותי B&A. ספציפית, הזמינות של יומני ענן וההשפעה של מצב הייצור על הרישום ביומן.	קודם כל, חשוב להבחין בין גרסאות build של prod לעומת גרסאות build של non_prod לבין הפרמטר הנפרד TEST_MODE, שפשוט מפעיל מפתח הצפנה קבוע לבדיקה. ההסבר שלמטה מתמקד בסוגי הבנייה. בגרסאות build שאינן מיועדות לסביבת ייצור, לשרתי B&A יש רמת פירוט שניתנת להגדרה לרישום ביומן. היומנים המפורטים האלה נכתבים לזרמי stdout/stderr הרגילים. ב-Google Cloud, אפשר לגשת אליהם דרך ממשק הרישום המקורי, וב-Amazon Web Services, אפשר למצוא אותם ביומנים של המסוף המצורף. בגרסאות ייצור, התנהגות הרישום ביומן מוגבלת יותר. רמת הפירוט קבועה ואי אפשר לשנות אותה. למרות שחלק מהיומנים שלא רלוונטיים לפרטיות, כמו הודעות הפעלה של השרת ורוב שגיאות הקריסה, עדיין מודפסים ב-stdout/stderr, אין יומנים ספציפיים לבקשות שזמינים דרך הערוץ הזה. היומנים היחידים של כל בקשה בנפרד מגרסת build של מוצר הם של בקשות שמכילות אסימון ניפוי באגים שניתנה לגביו הסכמה, והם מיוצאים רק דרך OpenTelemetry. חשוב להשתמש בניפוי באגים בהסכמה בצורה מוגבלת, כי תנועה כבדה עלולה לפגוע בביצועי השרת ולהוביל לכשלים בבדיקת תקינות. בנוגע למדדים, כולם מיוצאים דרך OpenTelemetry. מדדים שלא קשורים לפרטיות תמיד מיוצאים כמו שהם, ללא 'הוספת רעשי רקע'. לעומת זאת, מדדים שקשורים לפרטיות תמיד עוברים רעש אקראי כשמייצאים אותם משרת שפועל במצב ייצור. הגדרת הטלמטריה הספציפית קובעת אם המדדים האלה, שקשורים לפרטיות, מיוצאים עם רעש, בלי רעש או עם רעש ובלי רעש.
הכללת הנתיב המלא של הדף באותות מהימנים לבידינג לצורך שמירה על בטיחות המותג	בקשה לעדכון של PA API כך שיכלול את הנתיב המלא של כתובת ה-URL של הדף ברמה העליונה, בנוסף לשם המארח, בבקשת האחזור של trustedBiddingSignals. התרחיש העיקרי לדוגמה הוא הפעלה של אמצעי שליטה מפורטים יותר להגנה על המותג. מפרסמים צריכים לעיתים לחסום את הצגת המודעות בקטעים ספציפיים בדומיין (למשל, news-site.com/politics), אבל הם לא רוצים לחסום את הדומיין באופן כללי. רשימות החסימה האלה יכולות לכלול מיליוני ערכים, ולכן צריך לבדוק אותן בצד השרת. הספציפיקציה הנוכחית, ששולחת רק את שם המארח, לא מאפשרת לשרת trustedBiddingSignals לבצע את ההערכה הנדרשת ברמת הנתיב, וכך מגבילה את היכולות של בטיחות המותג.	אנחנו דנים כרגע בבעיה הזו כאן, אחרי דיונים קודמים נרחבים שאפשר לעיין בהם כאן. נשמח לקבל משוב נוסף. עם זאת, חשוב לנו להבהיר שאנחנו שוקלים להוסיף את המידע הזה רק אם האחזור של trustedBiddingSignals מתבצע לשרת שפועל בתוך סביבת מחשוב אמינה (TEE).

מכרז מוגן (שירותי בידינג ומכרזים)

נושא המשוב	סיכום	תגובה של Chrome
בדיקת הזמינות	מידע לגבי הזמינות של Key/Value (KV) v2 לבדיקה בסביבות Chrome ו-B&A.	‫KV v2 זמין גם ב-B&A וגם ב-Chrome. הדרכה נוספת זמינה כאן.
הטמעה של שרת KV	בקשה להבהרה בנוגע לשימוש בשרת KV, במיוחד בנוגע למיפוי של כתובות URL של הצגת קריאייטיב לנתוני בקשות, לצורך בתיאום בין פלטפורמות SSP ו-DSP להגדרת פרמטרים בכתובת ה-URL של הצגת הקריאייטיב, ולזמינות של מסמכים שמפרטים את התיאום הנדרש ואת אחסון הנתונים במצב KV.	שירות ה-KV משתמש ב-renderURL כמפתח. אם כתובת ה-URL חדשה, היא נשמרת. אם הוא קיים, הערך שלו מוחזר לשימוש בפונקציה scoreAd. פורמט ההחזרה תלוי בהגדרה: 'הבאת שרת משלך' (BYOS) מאפשרת כל ערך, בעוד ששירות ה-KV המהימן דורש פונקציה מוגדרת על ידי המשתמש. למרות שלא תמיד נדרש תיאום עם פלטפורמות DSP, הוא חיוני לתכונות כמו החלפת מאקרו (למשל, ‪${AD_WIDTH}) in the renderURL, which enables dynamic ad customization and verification. מומלץ להתחיל בבדיקה פשוטה עם פלטפורמת DSP אחת כדי לקבוע את רמת התיאום הנדרשת. אנחנו גם בתהליך של עדכון מסמכי התיעוד של KV, ונשתף אותם באופן ציבורי כשהם יהיו זמינים.
BYOS for B&A	למה B&A לא מציע מצב BYOS כמו מצב BYOS של KV?	התכונה 'שיוך והמרה' דורשת סביבת מחשוב אמינה (TEE), ולכן לא ניתן להשתמש במודל BYOS, כי היא מטפלת בשילובים של נתונים רגישים מאוד שנדרש בהם יישום של מנגנוני פרטיות, כפי שמוסבר בהמשך. בפלטפורמות למפרסמים (DSP): הפלטפורמה למפרסמים מעבדת את ההקשר של בעל התוכן הדיגיטלי (יכול להיות שכתובת ה-URL המלאה אם היא נשלחה באופן מפורש על ידי המוכר באמצעות auctionSignals / perBuyerSignals) בשילוב עם נתונים מפורטים של קהלים מבוססי-כוונות (IG) של משתמשים. ה-TEE חיוני לעיבוד מאובטח של השילוב הזה ולמניעת שחזור פוטנציאלי של פרטי זיהוי של משתמשים. ב-KV BYOS, אי אפשר לשלוח את כתובת ה-URL המלאה. לגבי פלטפורמות SSP: גם אם יודעים רק את השילוב של קבוצות האינטרסים המשתתפות (והבעלים של פלטפורמות ה-DSP שלהן) במכרז, אפשר ליצור חתימה מזהה. כאן נכנס לתמונה פתרון ההסוואה, שדורש שימוש ב-TEE. לכן, כדי לעבד בצורה מאובטחת את האותות הרגישים המשולבים האלה ולאכוף את מנגנוני הפרטיות, נדרשת סביבה מבוקרת ומאומתת של TEE.

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

Attribution Reporting (ועוד ממשקי API)

נושא המשוב	סיכום	תגובה של Chrome
מדיניות בנושא רעש	ההטמעה של ARA הייתה חשובה לחלק מהמשתתפים בשוק, ו-Google צריכה להמשיך לתחזק דיווח ברמת האירוע. ‫Google צריכה לשקול להקל את המדיניות בנושא רעשי רקע בתרחישים שבהם זמינים גם ARA וגם 3PC. מפרסמים שמתמקדים בביצועים משתמשים יותר ויותר בהטמעה הנוכחית של השדה 'ערך' באירוע הגמיש של ARA, ומדיניות פחות מגבילה בנושא רעשי רקע תעזור להפחית עיכובים ודיווח לא מדויק.	המנגנון הזה הוא חלק בסיסי מהעיצוב של ARA, שמטרתו להגן על פרטיות המשתמשים על ידי מניעת מעקב אחרי משתמשים ספציפיים. אנחנו בודקים את המשוב שקיבלנו לגבי הבעיות בדיווח שנגרמות מרעשי רקע, וממשיכים להעריך את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, וגם שיפורים פוטנציאליים עתידיים. זאת בעקבות ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים בנוגע לעוגיות של צד שלישי ב-Chrome תישמר.
תוכנית ניהול למוצר ותמיכה לטווח ארוך	בקשה לקבל מפת דרכים של מוצרים עבור ARA, וגם אישור של השקעה ותמיכה לטווח ארוך, בהתחשב בהודעה על כך שלא ימשיכו בהשקת מנגנון לבחירת המשתמשים עבור 3PC.	הצוות של ארגז החול לפרטיות עובד עם הסביבה העסקית כדי להבין את התפקיד של ממשקי Privacy Sandbox API בעתיד, וכדי להעריך השקעות עתידיות.
מדידה בסביבות שונות (מאפליקציה לאתר)	בקשה לפתרון שכולל שימוש ב-ARA כדי לאפשר מדידה בסביבות שונות, להציע זרימת נתונים נקייה ואמינה יותר ולשפר את היכולת לקשר בין אינטראקציות של משתמשים בפלטפורמות שונות.	ה-ARA כבר תומך במעבר מאפליקציה לאתר באותו מכשיר. כאן וכאן אפשר למצוא פרטים נוספים על פתרון המדידה באפליקציות ובאתרים.
שיוך חוצה-דפדפנים	גישה מאוחדת ל-ARA בכל הדפדפנים תשפר באופן משמעותי את היכולת למדוד את החזר ה-ROI באינטרנט הפתוח, ותספק חלופה יציבה לקראת שינויים רגולטוריים פוטנציאליים. צוות Chrome צריך לשתף פעולה עם צוות Safari כדי למצוא פתרון כזה.	אנחנו כבר בודקים אפשרות ליצור API שניתן להפעלה הדדית עם ספקי דפדפנים אחרים בקבוצות PATCG ו-PATWG ב-W3C. העבודה הזו היא ראשונית, ובעלי עניין מוזמנים לעיין בהתקדמות שלנו כאן.
מדידה במכשירים שונים או אופליין	חוסר היכולת לתמוך במדידת המרות חוצות-מכשירים בתוך ARA היא מגבלה משמעותית. חשוב מאוד גם למדוד המרות אונליין לאופליין, והדפדפן יכול למלא תפקיד בשיתוף פעולה עם ספקי מדידה.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
שיוך לכמה נקודות מגע	בקשה לאפשר למפרסמים להשתמש בנתונים של ארגז החול לפרטיות כ'אמת בסיסית' אובייקטיבית כדי לאמת ולכייל את מודלי השיוך הקיימים שלהם. אפשר להשיג את זה באמצעות נתונים שסופקו על ידי הדפדפן של ARA בתור אות כיול מהימן, וליצור בסיס של נתונים אמיתיים.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
מדידת תנועה ללא הסכמה או של משתמשים שלא הביעו הסכמה	פתרון ששומר על הפרטיות, כמו Interoperable Private Attribution, יאפשר מדידה של תנועה שלא התקבלה לגביה הסכמה. השימוש בפתרון הזה יאפשר לכם לקבל תמונה מקיפה יותר של ביצועי הקמפיין, כי הוא כולל נתונים ממשתמשים שבחרו שלא להשתתף במעקב. כך תוכלו לפתור בעיה משמעותית במדידה שנוצרת בגלל דרישות ההסכמה.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
שיוך של נתוני שרת-לשרת	בקשה לאפשר לחברות פרסום דיגיטלי עם תשתית מתוחכמת בצד השרת להשתלב עם ARA בצורה גמישה יותר, כדי להתאים לתרחישי שימוש שקשה לנהל רק בצד הלקוח, תוך שמירה על פרטיות המשתמשים.	אנחנו לוקחים את המשוב הזה בחשבון כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.
הרשמה לכמה דומיינים	אני רוצה לקבל הבהרה לגבי המגבלות וההסתייגויות כשמצטרפים ל-ARA עם כמה דומיינים, במיוחד לגבי שירות הצבירה ושיוך המרות ממקורות שונים.	בהמשך מפורטות המגבלות העיקריות כשמשתמשים ב-ARA עם כמה דומיינים: • השיוך מוגבל למקור יחיד. אי אפשר להתאים קליק מאחד הדומיינים להמרה בדומיין אחר. השיוך מוגבל לאותו מקור גם עבור המקור וגם עבור הטריגר. • Aggregation Service לא תומך בצירוף של נתונים ממקורות שונים. דוחות ממקורות שונים צריכים להיות בקבוצות ולעבור עיבוד בנפרד. אנחנו בודקים דרכים לתמוך בזה בעתיד. בקצרה, למרות שאפשר לרשום כמה דומיינים תחת ישות אחת, כל הפונקציות של ARA, כמו שיוך וצבירה, צריכות כרגע להתבצע על בסיס כל מקור בנפרד.

Aggregation Service

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

Private Aggregation API

נושא המשוב	סיכום	תגובה של Chrome
מגבלות ורמות רעש	חששות לגבי מגבלות על גדלים של מפתחות צבירה וערכי צבירה ב-Private Aggregation API.	הגודל של מפתח וערך הצבירה נבחר כך שתהיה גרנולריות גבוהה, תוך הגבלת העלויות של הרשת והאחסון. כדי למקסם את הגמישות, מומלץ גם להשתמש בגיבוב כשמקצים מפתחות. יש גורמים נוספים שמגנים על נתוני המשתמשים, אבל הוספת נתונים מיותרים היא חלק חשוב מהאמצעים להגנה על הפרטיות ב-Private Aggregation API. אנחנו לוקחים בחשבון את המשוב שקיבלנו ונמשיך לבדוק את האפשרויות המתאימות לפרמטרים, וגם את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים בנושא קובצי Cookie של צד שלישי ב-Chrome תישמר.
פרטיות לעומת שימושיות	הגישה של ארגז החול לפרטיות עשויה לתת עדיפות לפרטיות על פני שימושיות, מה שעלול להקשות על ההטמעה. הצעה לאפשר שיתוף מפורט יותר של נתונים בהסכמת המשתמשים כדי לשפר את המדידה ואת התאמה אישית של המודעות.	הגודל של מפתח וערך הצבירה נבחר כך שתהיה גרנולריות גבוהה, תוך הגבלת העלויות של הרשת והאחסון. כדי למקסם את הגמישות, מומלץ גם להשתמש בגיבוב כשמקצים מפתחות. אנחנו מתייחסים למשוב הזה כשאנחנו מעריכים את התפקיד שממשקי ה-API של ארגז החול לפרטיות ימלאו בעתיד, לאור ההודעה של Google מאפריל 2025 שלפיה הגישה הנוכחית להצעת בחירה למשתמשים לגבי קובצי Cookie של צד שלישי ב-Chrome תישמר.

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

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

נושא המשוב	סיכום	תגובה של Chrome
זיהוי ספאם	אם הבקשה הראשונה מאתר שמשתמש במערכת לזיהוי ספאם מסתמכת על רמזים מצד הלקוח, יכול להיות שמערכת המעקב או הזיהוי לא תצליח לזהות את הבקשה או לסווג אותה בצורה נכונה.	בתרחישי שימוש שמסתמכים על גישה לרמזים על הלקוח (Client Hints) לגבי סוכן המשתמש (UA-CH) בבקשה הראשונה, צריך להשתמש ברמזים על הלקוח (Client Hints) שחיוניים.
משוב על API	מומלץ להוציא משימוש את Sec-CH-USA-Wow64 כי הוא כבר לא רלוונטי לאינטרנט המודרני.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף כאן. קיבלנו משוב שלפיו כדאי להרחיב את wow64 מעבר ל-Windows.

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

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

Bounce Tracking Mitigations

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

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

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

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

Fenced Frames API

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

Shared Storage API

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

CHIPS

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

FedCM

נושא המשוב	סיכום	תגובה של Chrome
שימוש ב-API	גישור שקט נכשל למשתמשים עם כמה חשבונות ללא שגיאה ספציפית.	התנהגות התיווך השקט היא תכונה שנועדה למקרה ספציפי מאוד עם חשבון אחד בלבד. מומלץ להשתמש במקום זאת בתהליך גישור 'אופציונלי', שבמהלכו אם לא ניתן לבצע גישור שקט, FedCM יציג למשתמש בורר חשבונות.
שימוש ב-API	הפונקציה navigator.credentials.get מחזירה שגיאות כלליות, ולכן לא ניתן לתעד סיבות ספציפיות לדחייה, כמו סגירת החלון על ידי המשתמש או תקופות צינון.	גם העובדה שמפתחים לא יכולים להבחין בין מצב שבו המשתמש סגר את תיבת הדו-שיח של FedCM לבין שגיאת רשת לבין מצב שבו FedCM נמצא ב'תקופת צינון' כי המשתמש סגר את תיבת הדו-שיח בעבר היא תכונה שנועדה לשמור על פרטיות המשתמש. הבעיה היא שיכולת כזו תאפשר לאתרים להסיק את מצב ההתחברות של המשתמש בספקי זהויות (IdP) שונים.
כניסה	נצפה התנהגות לא עקבית בבחירת חשבונות כשמחוברים לכמה חשבונות.	לא ברור אם חוסר היכולת לסירוגין לבחור חשבון ספציפי בתרחיש של כניסה למספר חשבונות היא באג לסירוגין ב-FedCM או בעיה כלשהי שקשורה למערכת הבדיקה. אנחנו פועלים לפתרון הבעיה הזו יחד עם מי שדיווח עליה, וביקשנו ממנו פרטים נוספים כדי להבין אותה טוב יותר.
שימוש ב-API	אם המשתמש סוגר את תיבת הדו-שיח במהלך ההרשאה באמצעות FedCM, העובדה שהוא נמצא במצב המתנה לא מדווחת באמצעות שגיאה שאפשר לטפל בה.	כן, זה המצב, ובמקרה כזה יופק קוד השגיאה הכללי כדי לשמור על פרטיות המשתמשים.
שימוש ב-API	למה FedCM נכנס לתקופת צינון של 10 דקות אחרי "אימות מחדש אוטומטי" מוצלח?	בהתחשב בכך שהאימות מחדש מתבצע באופן אוטומטי ללא פעולה שהמשתמש יזם, אם המשתמש רוצה לחזור לאתר אבל להיכנס באמצעות חשבון אחר, הוא צריך תקופה שבה FedCM לא יבצע אימות מחדש באופן אוטומטי. במהלך התקופה הזו, המשתמשים יכולים להיכנס באופן ידני באמצעות חשבון אחר. בפוסט הזה בבלוג אפשר לקרוא פרטים נוספים על תקופת ההמתנה.
גרסה קלה של FedCM	יש חשש שההצעה של Lightweight FedCM תוסיף מורכבות לספקי הזהויות (IdP) בגלל הצורך לתמוך בשתי הטמעות לא תואמות (FedCM לעומת Lightweight FedCM).	‫FedCM קל משקל תואם ל-FedCM רגיל. ספקי זהויות יכולים לבחור באיזו שיטת הטמעה להשתמש, והם לא יידרשו לתמוך בשתי השיטות. ‫FedCM קל משקל הוא מנגנון דחיפה ל-FedCM. אם ספק הזהויות בוחר להשתמש בתכונה הזו, הוא יכול לשלוח את פרטי החשבון לדפדפן כשהמשתמש מתחבר, כך שכאשר אתר (Relying Party) מפעיל את FedCM, החשבון יאוחזר מהדפדפן, במקום מנקודת הקצה של החשבונות של ספק הזהויות.
גרסה קלה של FedCM	חששות לגבי חשיפה של נתונים אישיים של משתמשים, כמו שם, כתובת אימייל ותמונת פרופיל, לצד המסתמך בהצעה של Lightweight FedCM.	ההצעה ל-Lightweight FedCM עודכנה מאז שקיבלנו את המשוב הזה, כדי להסיר את השם, כתובת האימייל ותמונת הפרופיל מתגובת השיטה.
גרסה קלה של FedCM	נראה שהניהול של כמה חשבונות מחוברים נוקשה מדי בהצעה של Lightweight FedCM. בשלב הזה, ההצעה לא תומכת בפרקי זמן של סשנים נפרדים או במצבי התחברות מורכבים לכל חשבון.	תוקף התפוגה קשור כרגע ל-IdP באובייקט פרטי הכניסה. רשמנו לעצמנו את נושא התפוגה לכל חשבון כשאלה פתוחה, ונביא את המשוב הזה בחשבון בפיתוחים עתידיים.
גרסה קלה של FedCM	ההבדל בין 'מחובר' לבין 'זמין לבחירה' לא מוגדר בצורה ברורה, וזה עלול להשפיע על חוויית המשתמש בהצעה של Lightweight FedCM.	נכון לעכשיו, אנחנו לא תומכים באפשרות להבחין אם חשבון מחובר או לא מחובר בממשק המשתמש של FedCM. חשבונות שלא מחוברים לא צריכים להופיע. אם משתמש מחובר לחשבון מסוים ובוחר בחשבון אחר שהוא לא מחובר אליו, אפשר להשתמש ב-Continuation API כדי לחבר אותו מחדש.
שימוש ב-API	חוסר עקביות בין השדה given_name ב-getUserInfo לבין השימוש בו בממשק המשתמש של FedCM.	הבעיה הזו נדונה עם Mozilla כאן, כדי להגיע להסכמה לגבי הטיפול ב-given_name ב-getUserInfo.
שימוש ב-API	לא כל השדות שמשמשים בממשק המשתמש של IdentityProviderAccount מועברים אל getUserInfo, ובמיוחד השדות tel ו-username, מה שמצביע על הצורך בסנכרון.	הדיון עם Mozilla וחברים אחרים בקהילת FedID מתקדם בנושא של התאמת השדות מ-IdentityProviderAccount שנשלחים אל getUserInfo.
‫FedCM לארגונים	בקשה לתמיכה ב-FedCM בתרחישים לדוגמה של ספק זהויות (IdP) לשימוש ארגוני.	הבעיה העיקרית היא הצורך במנגנון מהימן שספקי זהויות יוכלו להשתמש בו כדי לסמן לדפדפנים שאדמינים נתנו מראש הסכמה לאפשר למשתמשים לגשת לצדדים מסתמכים ספציפיים, שלא ניתן לחקות אותם או לנצל אותם לרעה על ידי כלי מעקב באינטרנט. הנושא הזה נדון בפגישה של FedID CG ב-22 באפריל (סיכום הפגישה) והוצעו פתרונות פוטנציאליים שמשלבים תוספים לדפדפן ומדיניות ארגונית (למכשירים מנוהלים). נשמח לקבל מכם משוב נוסף על הבעיה הזו כאן.

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

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

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