דוח משוב – הרבעון השני והשלישי של שנת 2024

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

כחלק מההתחייבויות שלה ל-CMA, Google הסכימה לפרסם דוחות רבעוניים על תהליך המעורבות של בעלי העניין בהצעות שלה לארגז החול לפרטיות (ראו פיסקאות 12 ו-17(ג)(2) בהתחייבויות). ב-22 ביולי 2024, Google הודיעה שהיא לא תפסיק להוציא משימוש קובצי Cookie של צד שלישי (3PC) ב-Chrome. במקום זאת, הציע לנו ליצור גישה מעודכנת לשיפור אפשרויות הבחירה של המשתמשים. לכן, בהסכמת CMA, Google לא שלחה ל-CMA דוח ציבורי לרבעון השני של שנת 2024 כדי לתת ל-Google ול-CMA מספיק זמן להביא בחשבון את ההשלכות של ההודעה של Google.

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

נושאי המשוב מדורגים לפי השכיחות לכל API. כדי לעשות זאת, אנחנו אוספים את כמות המשוב שקיבל צוות Chrome לגבי נושא מסוים וממיינים אותו בסדר יורד לפי כמות. הנושאים הנפוצים במשוב זוהו על ידי סקירת נושאי הדיונים בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שמוצגות בפורומים הפנימיים ובפורומים הציבוריים של Google.

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

ההסברים על התשובות של Chrome למשוב נוצרו על סמך שאלות נפוצות שפורסמו, תשובות בפועל שניתנו לבעיות שהעלו בעלי עניין וקביעת עמדה ספציפית למטרות הדיווח הציבורי הזה. סקירת המוקד הנוכחי של הפיתוח והבדיקה, שאלות ומשוב שקיבלנו במיוחד בנוגע לממשקי ה-API של Topics, Protected Audience ו-Attribution Reporting.

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

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

ARA

Attribution Reporting API

CHIPS

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

DSP

פלטפורמה בצד הביקוש

FedCM

Federated Credential Management

FPS

קבוצות של צד ראשון

IAB

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

IDP

ספק זהויות

IETF

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

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

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

openRTB

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

הארכה

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

PAT API

Protected Audience API (לשעבר FLEDGE)

PatCG

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

RP

צד נסמך

RWS

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

SSP

פלטפורמה בצד הספק

TEE

סביבת מחשוב אמינה

UA

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

UA-CH

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

W3C

World Wide Web Consortium

WIPB

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
הוצאה משימוש של קובצי cookie של צד שלישי (3PCD)	מהם התוכניות של Google בנושא 3PCD, והאם נבדקו ההשפעות לטווח הארוך על תעשיית הפרסום הדיגיטלי?	אנחנו מציעים גישה מעודכנת שמאפשרת למשתמשים לבחור את האפשרות המתאימה להם. כפי שמפורט כאן, במקום להוציא משימוש את קבצי ה-3PC, נשיק חוויה חדשה ב-Chrome שתאפשר לאנשים לקבל החלטה מושכלת שתחול על כל הגלישה שלהם באינטרנט, והם יוכלו לשנות את הבחירה הזו בכל שלב. אנחנו דנים בדרך החדשה הזו עם הרגולטורים, ונשוחח עם גורמים בתחום לפני ההשקה.
בחירה של המשתמש	ההכרזה על הבחירה של המשתמשים השפיעה על העניין של הגורמים בסביבה העסקית בשימוש בפתרונות של ארגז החול לפרטיות. קיבלנו משוב מעורב לגבי ההודעה על הבחירה של המשתמשים, כולל בקשות לתכונות כמו יכולות מעקב.	הגישה המעודכנת משפרת את אפשרויות הבחירה של המשתמשים, ולכן עדיין חשוב שלמפתחים יהיו חלופות לשיפור הפרטיות במקום מזהים באתרים שונים. עדיין אין לנו פרטים לשתף לגבי המראה של החוויה החדשה, אבל אנחנו כן מצפים לעלייה משמעותית בנפח התנועה ללא קובצי cookie ב-Chrome. כלומר, ממשקי ה-API של ארגז החול לפרטיות הם חיוניים לעסקים. נמשיך להשקיע בטכנולוגיות של ארגז החול לפרטיות כדי לשפר עוד יותר את הפרטיות והתועלת.
ממשק משתמש לבחירת המשתמש	שאלות לגבי ציר הזמן של תכונות ההסכמה/ביטול ההסכמה, סוג האפשרות של המשתמש שנבחנת והאופן שבו ממשק המשתמש ישפיע על סביבות הבדיקה האוטומטיות.	אין לנו עדכונים לגבי לוח הזמנים בשלב זה. אחרי שהחלטנו שלא להמשיך עם 3PCD, רצינו לספק עדכון לסביבה העסקית בהקדם האפשרי. נשתף עדכון לגבי לוח הזמנים לבחירת המשתמשים ברגע שיהיה לנו עדכון.
בדיקות ב-Chrome	בקשה להמשך הזמינות של תוויות בדיקה בסיוע Chrome כדי למדוד את השימוש בשוק ואת ההשפעה הכלכלית של 3PCD אחרי המחצית הראשונה של 2024.	אנחנו מודעים לכך שבודקים ירצו להמשיך להשתמש בקבוצות של דפדפנים מתויגים לצורך בדיקה ותיאום, גם אחרי שהבדיקה באמצעות Chrome תסתיים במחצית הראשונה של שנת 2024. אנחנו בודקים את השלבים הבאים לגבי התוויות בהתאם לההודעה על הבחירה של המשתמשים. בינתיים, צוות Chrome פרסם כוונה להרחיב את התמיכה בקבוצות דפדפנים מתויגות דרך Chrome Milestone 132, החל מינואר 2025.
ארגז החול לפרטיות ב-Android	ארגז החול לפרטיות ב-Android וארגז החול לפרטיות ב-Chrome קשורים זה לזה באופן בלתי נפרד, ואין לנו אפשרות להעריך כראוי את ארגז החול לפרטיות בלי Android. תהליך הרכישה הרגיל של הלקוח, שכולל היבטים שקשורים למכשירים שונים ולמגע בכמה נקודות, הוא קריטי גם לארגז החול לפרטיות ב-Chrome וגם לארגז החול לפרטיות ב-Android.	לתשומת ליבך, ארגז החול לפרטיות ב-Android לא נכלל בהיקף ההתחייבויות של Google ל-CMA. אם המשוב ספציפי ללוחות הזמנים ולהשקה של Android, אין לנו עדכונים לשתף בשלב הזה, מלבד העובדה שאנחנו ממשיכים להתקדם ב-Android, שאנחנו מתייחסים אליו כאל מקור עבודה עצמאי לשיפור הפרטיות. כפי שציינו קודם, הזמינות של ממשקי API של ארגז החול לפרטיות ב-Android תיקבע גם לפי הקצב שבו המשתמשים מעדכנים את המכשירים שלהם, וזה משהו ש-Google לא יכולה לשלוט בו.
מצב ב' התנועה מוגבלת	נפח התנועה במכרז המודעות שזמין במצב ב' היה נמוך מהצפוי.	יש כמה סיבות לכך שנפחי המכרזים של Protected Audience API‏ (PA API) עשויים להיות נמוכים מהצפוי, למשל: - החברות שאנחנו יודעים שהטמיעו את PA API כללו רק פורמטים של באנר. - יכול להיות שפלטפורמות בצד המכירה לא תמיד יפעילו מכרז. - יכול להיות שבדפדפן אין קבוצות של תחומי עניין (IG). - יכול להיות שלא יוצגו הצעות מחיר. עם זאת, לא ידוע לנו מי ניסה לבדוק את PA API ולא קיבל תנועה.
הרשאות גישה להפסקות זמניות בשירות	קבלת מידע על הפסקות זמניות בשירות ועל בעיות שמשפיעות על ממשקי ה-API של ארגז החול לפרטיות.	יש דף סטטוס ציבורי לממשקי ה-API של ארגז החול לפרטיות שיש להם שירותים מחוץ לדפדפן. צוות Chrome נותן עדיפות עליונה לאמינות הפלטפורמה שלנו ולכל ממשקי ה-API הקריטיים שבהם משתמשים אתרים ושירותים גדולים באינטרנט, כולל הטכנולוגיות של ארגז החול לפרטיות. עד כה הייתה רק הפסקה זמנית אחת בשירות. היא הייתה קשורה להגדרה זמנית לבדיקה של 1%. בקרוב לא נצטרך יותר את ההגדרה הניסיונית שגרמה להפסקה הזמנית בשירות, ולכן אנחנו בטוחים שהבעיה הזו לא תתרחש אחרי שה-API יפעלו בדרך הרגילה ב-Chrome.
מחקר בנושא תרשים קובצי Cookie	מהי נקודת המבט של Chrome לגבי שיטת Cookie Graph כפי שמתואר במאמר הזה במסגרת ארגז החול לפרטיות?	במאמר מועלות כמה נקודות מעניינות לגבי הזיהוי והשכיחות של קובצי cookie של צד ראשון (1P) שהוגדרו על ידי דומיינים שונים מהדומיין שבו המשתמש ביקר. כפי שצוין במאמר, קובצי ה-cookie האלה שימושיים מאוד לאיסוף נתונים אנליטיים ומידע על האינטראקציה של משתמשים עם אתר. הנתונים האלה חיוניים למפתחים כדי לספק למשתמשים חוויית גלישה טובה יותר. הטיעון העיקרי של המאמר שגוי, כי קובצי cookie מהדומיין הנוכחי נחשבים לווקטור של מעקב באתרים שונים. עם זאת, הדבר נכון רק בהנחות האגרסיביות מאוד שמפורטות במאמר: המשתמשים מוכנים לשתף את המידע האישי המזהה שלהם עם האתר. למכשירים יש טביעת אצבע יציבה שאפשר להשתמש בה כדי לעקוב אחרי משתמש באתרים שונים. לתשומת ליבכם: אלה וקטורים של זיהוי מחדש שאפשר לנצל אותם בלי להשתמש בקובצי cookie של צד ראשון (לדוגמה, באמצעות שיתוף נתונים בצד השרת), וצריך לטפל בהם בנפרד מהמאמצים הנוכחיים שלנו שמתמקדים במנגנוני מעקב מבוססי-מצב כמו צדדים שלישיים (3PC). לסיום, חשוב לנו לציין שבסקירה המפורטת קובצי cookie לניתוח נתונים וקובצי cookie לפרסום מתייחסים לקובצי cookie למעקב, וקובצי cookie חיוניים מתייחסים לקובצי cookie ללא מעקב, אבל זה לא בהכרח המצב. אכן, ניתוח נתונים ראשון-צד או שירותי ספקים שמחולקים לאתרים, כמו ווידג'טים למציאת חנויות, ווידג'טים לצ'אט או קובצי cookie של מאזן עומסים, עשויים להיות מוגבלים לתחום אחד בלבד. לעומת זאת, חלק מקובצי ה-cookie הנחוצים ביותר עשויים לעקוב אחריכם באתרים שונים למטרות מניעת הונאות.
שינויים בחוויית המשתמש	שינויים בממשק המשתמש בגרסה 112 של Chrome, שמציבים את אמצעי הבקרה על קובצי cookie של צד ראשון בקטע 'נתוני האתר במכשיר' בהגדרות Chrome, עשויים להקשות על המשתמשים לחסום את כל קובצי ה-cookie.	השינוי הזה בוצע במסגרת המאמצים שלנו להפריד את אמצעי הבקרה של 3PC (או אחסון ללא מחיצות) מכל סוגי הנתונים האחרים של האתר, ולהגביר את רמת הבקרה עליהם. אמצעי הבקרה של צד שלישי מוצגים בחלונית 'פרטיות ואבטחה', ואילו אמצעי הבקרה של קובצי cookie מאינטראקציה ישירה (1P) וכל סוגי הנתונים האחרים מהאתר – שהפונקציונליות הקריטית של האתרים תלויה בהם בדרך כלל – נכללים בקבוצה 'נתונים מהאתר במכשיר'. אנחנו נמשיך לעקוב אחרי המשוב בנושא הזה, אבל אנחנו מאמינים שההפרדה הנוכחית יוצרת איזון טוב בין ניראות של אמצעי בקרה משמעותיים לשמירה על הפרטיות לבין שמירה על חוויית גלישה פונקציונלית.
חיובים ותשלומים	החיובים והתשלומים לא נבדקים במלואם כי הבדיקות מתמקדות יותר באזורים אחרים של ממשקי ה-API של ארגז החול לפרטיות.	מתי ומה המפתחים והחברות בוחרים לבדוק הם הבחירה שלהם. ממשקי ה-API זמינים לבדיקה לכלל המשתמשים מאז ספטמבר 2023.
בדיקה	לא כל התנועה הניסיונית ש-DSPs מקבלים מ-SSPs מסומנת. חלק מ-DSPs ציינו שיכול להיות שיש הבדל בין החלק של החשיפות הניסיוניות ללא תוויות בקבוצת הטיפול לבין החלק של החשיפות הניסיוניות ללא תוויות בקבוצת הבקרה.	מערכת Chrome לא יכולה לקבוע אם חברות יעבירו תוויות בבקשות להצעות מחיר. אנחנו מספקים שיטה לקבלת תווית מהדפדפן. לאחר מכן, בסביבה העסקית הם יוכלו להעביר את התוויות לשותפים אם השותפים שלהם לא יכולים לקרוא את התוויות באופן ישיר.
3PCD ב-Android WebView	בקשה להנחיות להפעלת הדגל 'בדיקת הסגירה ההדרגתית של קובצי cookie של צד שלישי' ב-Android WebView לצורך בדיקת ההוצאה משימוש.	מודעות 3PC חסומים כברירת מחדל ב-Android WebView.
פרטיות דיפרנציאלית לצמצום סיכונים באימון מודלים	למה משתמשים בפרטיות דיפרנציאלית באימון מודלים?	פרטיות דיפרנציאלית, בשילוב עם סביבות ביצוע מהימנות (TEE), היא הכרחית לאימון מודלים כדי למנוע דליפת נתונים ולהגן על מידע רגיש מפני איומים. הגישה הזו מבטיחה שמשקל המודלים לא יכול לחשוף נתונים של משתמשים ספציפיים.

הרשמה ואימות (attestation)

נושא המשוב	סיכום	תגובה מ-Chrome
צירוף	בקשה להבהרה לגבי אופן ההרשמה לאימות בין המקור שמשויך לחשבון לבין המקור של טכנולוגיית הפרסום עם תת-דומיין www.	חברת טכנולוגיית הפרסום תצטרך להצטרף רק ל-https://example.com. כשהוא מבצע את האימות (attestation) ב-https://example.com/.well-known/privacy-sandbox-attestations.json, השדה https://www.example.com מכוסה כי הוא תת-דומיין.
מפרט API	הצעה להוסיף למאגר סכימה של JSON לקובץ האימות.	אנחנו בודקים את ההצעה הזו ונשמח לקבל משוב נוסף כאן.

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

נושאים

נושא המשוב	סיכום	תגובת Chrome
שקלול נושאים	הדבר החשוב ביותר שצריך להבין לגבי Topics הוא נדירות האות. העיצוב הנוכחי אמור להתפתח כך שיאפשר להוסיף ערך משקל לצד כל נושא שנצפה. המשקל יהיה המשקל היחסי של נושא מסוים בדפדפן מסוים, בהשוואה לכל הדפדפנים שמשתמשים בנושא.	אנחנו רוצים להבין טוב יותר למה מידת הנדירות של אות היא האות החשוב ביותר. נשמח לקבל משוב נוסף מהסביבה העסקית על התועלת של תרחיש לדוגמה הזה כאן.
אמינות הנושאים	Google צריכה לספק ביטחוןים טובים יותר לגבי האמינות של Topics לאורך זמן.	נמשיך לבצע שינויים בממשקי ה-API שלנו על סמך משוב מהסביבה העסקית, ונדבר עליהם באופן ציבורי לפני ביצוע השינויים. ההצעה שלנו למבנה ממשל מעודכן תספק ביטחון נוסף.
מסווג	לעתים קרובות, אתרים של בעלי תוכן דיגיטלי מסווגים באופן שגוי או שהם מוקצים לנושאים ברמה גבוהה מדי כדי לשרת מטרות משמעותיות.	כפי שמוסבר במאמר בנושא הסיווג של Topics, האתרים מסווגים באמצעות שילוב של רשימת שינוי ידני שנוצרה על ידי בני אדם, שמכילה את האתרים הפופולריים ביותר, ושל מודל למידת מכונה במכשיר. אנחנו ב-Chrome ממשיכים לבדוק אפשרויות לאתרים שיעזרו לנו לסווג את התוכן לפי Topics. יש לשקול כל שיפור ביכולות השימוש מול הסיכונים הקשורים לפרטיות ולניצול לרעה. לדוגמה, כמה מהסיכונים כוללים: - אתרים שמשתמשים בתיוג עצמי כשיטה לקידוד משמעויות שונות (שעשויות להיות רגישות) לנושאים שונים, וכן - אתרים שתוקפים נושאים כדי לצמצם את התועלת שלהם לאחרים (למשל, הפצת ספאם בנושאים של המשתמש באמצעות רעש חסר משמעות). הציבור יכול לבדוק את הרכיבים האלה, והכלים זמינים בכתובת chrome://topics-internals או ב-colab הזה. אנחנו צופים שהסיווג ישתפר עם הזמן באמצעות בדיקות, ונשמח לקבל מכם משוב עם דוגמאות לאתרים שסווגו בטעות.
API Question	חששות לגבי העובדה ש-Topics API מעניק יתרונות מתמשכים ואנטי-תחרותיים ל-SSP שמניבים הכנסות מתוכן בעייתי.	בדומה ל-3PC, הדפדפן לא מתייחס למי הוא מחזיר את Topics, כל עוד הישות הזו רשומה ומאומתת.
(דיווח גם ברבעונים קודמים) שימושיות לסוגי גורמים שונים בעניין	מכיוון שהסיווג של Topics משתמש כרגע רק בשם המארח של הדף כדי להגדיר את הנושאים התואמים, אתרים גדולים עם תוכן מגוון תורמים לנושאים כלליים, ואילו אתרים קטנים תורמים לנושאי נישה עם ערך פרסום גבוה יותר.	התגובה שלנו דומה לרבעונים הקודמים: בדומה לקובצי Cookie של צדדים שלישיים, יש הבדל בערך המידע שנתרמו על ידי אתרים שונים. האתרים בתחומי עניין ספציפיים תורמים ערך באופן לא עקבי: לא לכל האתרים בתחומי עניין ספציפיים יש הקשר בעל ערך מסחרי, ולכן הם תורמים פחות ערך. אלה האתרים שייהנו מ-Topics API. האפשרות של סיווג ברמת הדף במקום ברמת האתר נלקחה בחשבון, אבל יש כמה בעיות משמעותיות שקשורות לפרטיות ולאבטחה בסיווג כזה.
מסווג	לעתים קרובות, לאתרים קטנים יותר מוקצה סיווג לא מדויק או לא מוקצה סיווג בכלל, ולכן הם לא יכולים להשתתף בהחלפת הערכים.	לגבי הנזק לכאורה, אתרים ספציפיים שעלולים להיות מסווגים באופן שגוי לא יפגעו יותר לעומת אתרים אחרים, כי המידע ההקשרי של האתר תמיד יהיה זמין עבור מכרזים באתר שלו, שיספקו מידע דומה לנושא הנכון, גם במקרה של סיווג שגוי. בדרך כלל נעשה שימוש בנושאים כדי לאסוף מידע פרסומי שעשוי להיות שימושי מאתרים חיצוניים, במקום מהאתרים שלהם.
גרסת הטקסונומיה	איך נוכל לגשת לגרסה של הטקסונומיה כדי להבטיח תאימות לאחור?	גרסת הטקסונומיה היא חלק מכותרת הבקשה שנשלחת עם בקשת אחזור שמופעלת בה תמיכה בנושאים. לדוגמה, אם הכותרת היא "(1 2);v=chrome.1:2:5, ();p=P000000000", הגרסה היא chrome.1:1:2. כאשר chrome.1 היא גרסת התצורה, הספרה 2 היא גרסת הטקסונומיה והספרה 5 היא גרסת המודל. התיאור הזה מתואר במפרט, והוא נוסף גם להסבר.
נתוני נושאים	בקשה להבהרה לגבי אופן העדכון של נתוני Topics.	לא צוין עדכון הטקסונומיה. כך לספקי הדפדפנים יש גמישות בהטמעה. עם זאת, ריכזנו כאן את שיטות הניתוח של עדכון הטקסונומיה של Chrome מ-V1 ל-V2: - עץ טקסונומיה יחיד נשמר לנושאים מ-V1 ומ-V2. - אותו מזהה נושא מייצג את אותה משמעות. - העץ רק גדל, ומוסיף נושאים או קשרים חדשים, מבלי להתכווץ. - עם זאת, יכול להיות שחלק מהנושאים או מהקישורים יהיו 'לא פעילים' בגרסה מסוימת, מה שעלול ליצור רושם של מחיקה או ארגון מחדש. דוגמאות: - הקטגוריה 'טנדרים' כוללת עכשיו את הקטגוריה 'משאיות, רכבים מסחריים ורכבי שטח' בתור הורה ביניים. - ל'מחקר שפה זרה' יש עכשיו 'חינוך' כהורה שני, ו'קובץ העזר' המקורי שלו הופך ללא פעיל. ההשפעה של נושאים 'לא פעילים': המערכת לא תשתמש בנושאים האלה לצורך סיווג חדש. עם זאת, הם עדיין נלקחים בחשבון כשאנחנו אוכפים חסימות של משתמשים: אם משתמש חסם נושא בגרסה 1, נושאי הצאצאים שלו ימשיכו להיות חסומים בגרסה 2 (גם אם נושא הצאצא מופיע בגרסה 2 כנושא הורה אחר).
מסווג	רציתי להבין מהן הסיבות לסווגים שגויים ואילו אפשרויות תיקון זמינות.	ראשית, נציין שהחלטת Chrome לגבי נושאי אתר משמשת רק כקלט של האלגוריתם Topics שלו, לקביעת תחומי העניין של המשתמש למטרות פרסום. הוא לא פותח למטרות סיווג כלליות יותר. אנחנו מתעניינים בדיוק הכולל של מודל הסיווג שלנו, ומנסים לשפר את הדיוק או את החזרה (recall) שלו במידת האפשר, אבל ברמה הגלובלית ולא ברמת הסיווג של האתר הספציפי. הסיבה לכך היא שסיווג שגוי, כשזה קורה, לא פוגע באתר שסווג באופן שגוי, אלא מפחית את איכות האות של Topics API כשבוחרים מודעה באתרים אחרים. כשבוחרים מודעות באתר שסווג בטעות, הנושאים האמיתיים של האתר כבר ידועים לאותו אתר, וניתן להשתמש בהם כקלט לשאילתות פרסום. נשמח לקבל משוב נוסף כאן.
בדיקת API	האם אפשר לבדוק את Topics ואת ממשקי ה-API של ארגז החול לפרטיות ב-Chromium?	Topics API לא מגיע עם Chromium, אלא עם Chrome.
Topics Caller	בקשה לשיפור הערך המוסף של Topics על ידי ניצול שירותי TEE עבור טכנולוגיות פרסום, כדי לתמוך בעלות של ניתוח מתקדם בדרכים שתואמות לפרטיות.	השבנו למשוב דומה כאן. התייחסנו לתדירות הפוכה, ובסופו של דבר, אחרי בניית מודל של תדירות הפוכה, מצאנו שהיא לא מתואמת היטב לערך הנושא לפי הערך שסופק על ידי קונים ומוכרים. נשמח לקבל משוב נוסף כאן.
מפרטי API	האם ההגדרה של קבוצת משתמשים לפי תחומי עניין בדפדפן עלולה לחסום את Topics API?	השבנו למשוב הזה כאן. Topics API הוא פיתוח של FLoC, והוא פועל בהתאם למדיניות ההרשאות של FLoC. כמו שמוסבר בהסבר: "הערה: גם הגרסה הישנה של Permissions-Policy: Interest-cohort=() מ-FLoC תמנע חישוב של נושאים".
דירוג נושאים	כשמקבלים את הנתונים של '5 הנושאים המובילים', האם נספר את תדירות הביקורים באתר על סמך כל מבקר שעומד בדרישות, או תמיד נספר על סמך כל היסטוריית הביקורים בדפדפן? בנוסף, האם המערכת מדרגת את הנושאים בנפרד לכל מבצע קריאה?	הוא מבוסס על התדירות של קבוצת משנה של היסטוריות גלישה. רשומה בהיסטוריית הגלישה (דף) כשירה להשתתף רק אם בדף היה לפחות קריאה אחת ל-Topics. פרטים נוספים על האחסון של היסטוריית הנושאים זמינים כאן. כפי שמוגדר בהודעה שלנו על שיפורים ב-Topics API, הדירוג תלוי בתדירות וגם ברמת עדיפות בינארית (פרטים נוספים זמינים כאן וכאן). עם זאת, הוא לא תלוי בתדירות של האנשים שמתקשרים. חשוב לשים לב: זה לא אומר שכל המתקשרים יכולים לראות את כל 5 הנושאים המובילים בתקופה הבאה. כפי שמפורט בהסבר, "רק גורמים שזיהו שהמשתמש ביקר באתר בנושא הרלוונטי ב-3 השבועות האחרונים יכולים לקבל את הנושא". הדפדפן צריך לעקוב אחרי 5 הנושאים המובילים שאותם הבחין מבצע הקריאה החוזרת (הנושאים האלה תואמים ל5 הנושאים המובילים עם דומיינים של מבצעי הקריאה החוזרת במפרט). נשמח לקבל משוב נוסף על הבעיה הזו כאן.

Protected Audience API (לשעבר FLEDGE)

נושא המשוב	סיכום	תגובה מ-Chrome
(דווחו גם ברבעונים קודמים) עלויות	האם ריצה של TEEs בעננים ציבוריים יקרה יותר בהשוואה למרכזי נתונים מקומיים של טכנולוגיות פרסום?	מודל האבטחה הנוכחי של TEE נהנה מהשיטות של הטמעות בענן הציבורי (פרטים נוספים זמינים במאמר הסבר על הדרישות של TEE בענן הציבורי). לדוגמה, סביבות TEE מבוססות-חומרה לא מגינות מפני כל ההתקפות הפיזיות. ספקי הענן הציבורי הקיימים שלנו, AWS ו-GCP, תכננו והטמיעו מיטיגציות לסיכוני גישה פיזית, כולל מן העובדים. אמנם חלק מטכנולוגיות הפרסום הזכירו לנו שהשימוש בשירותי ענן יקר יותר מאשר מרכזי נתונים טכנולוגיים מקומיים. עם זאת, טכנולוגיות פרסום אחרות פועלות בעננים ציבוריים, בין אם מדובר בעלות או ביתרונות אחרים. אנחנו ממשיכים לבדוק אפשרויות להרחבת התמיכה ב-TEE, כולל מחוץ לעננים ציבוריים. במסגרת העבודה הזו, אנחנו מבצעים מחקר על מרכזי נתונים בארגון, ואנחנו פועלים בשיתוף עם הסביבה העסקית כדי לבחון פתרונות פוטנציאליים להענקת תמיכה כזו. בשלב המחקר הנוכחי, אנחנו לא יכולים להבטיח שהתוצאה תהיה פתרון בר-ביצוע לסביבה העסקית.
PA API ו-Google Ad Manager (GAM)	ל-GAM אין אפשרות להשיג תוצאת שוק הוגנת. מערכת GAM לא מצליחה להציג מודעות בזמן, לא מדווחת על מספר המודעות שהוצגו באמצעות PA API ולא מאפשרת לקבוע איזו שיטה תיבחר להצגת מודעה, למשל על ידי השבתת PA API עבור משבצות מסוימות.	תגובה מ-Google Ad Manager: אנחנו ב-GAM מבצעים אופטימיזציה של זמן האחזור בהצגת מודעות דרך ה-PA API, וממשיכים לבצע אופטימיזציה של זמן האחזור. כך, העלייה בהכנסות של בעל התוכן הדיגיטלי מהביקוש ל-PA API תהיה גבוהה יותר מהעלויות שנגרמו כתוצאה מזמן האחזור הנוסף של המכרז של PA API. בבדיקה הראשונית שלנו נראה שבעלי תוכן דיגיטלי נהנים מהכנסה נטו מ-PA API מתנועת גולשים ללא מחשבי 3PC. מה שמעיד על כך שהביקוש הנוסף מ-PA API גדול יותר מהעלויות עקב זמן האחזור. אפשר למצוא פרטים נוספים על הגישה שלנו בשאלות הנפוצות. בנוסף, מערכת GAM מספקת לבעלי תוכן דיגיטלי דיווח על מודעות שמוצגות דרך PA API. הנתון הזה כולל מודעות שמוצגות כש-GAM הוא מוכר רכיבים, ומודעות שמוצגות דרך מוכרי רכיבים אחרים כש-GAM הוא מוכר ברמה העליונה. פרטים נוספים על דיווח זמינים במרכז העזרה. לבסוף, GAM מאפשר לבעלי תוכן דיגיטלי להפעיל או להשבית את השימוש ב-PA API בתנועה שלהם באמצעות בקרה בתוך ממשק המשתמש (פרטים נוספים זמינים במרכז העזרה שלנו). אנחנו פתוחים לאפשרות של שליחת משוב על אמצעי בקרה נוספים שבעלי תוכן דיגיטלי רוצים. נתעדף כל בקשה להוספת תכונה בהתאם לתהליך הרגיל שלנו לתעדוף תכונות.
PA API ו-GAM/AdX	נראה ש-Google החליטה פשוט לא לקנות חשיפות של PA API שהמערכת של GAM לא מקבלת עליה את ההחלטה הסופית לגבי המכירה, בדומה ל-AdWords שקונה רק מבית. נראה שמדובר בניצול לרעה של מיקום שוק, כי GAM/AdX יכולים לשלוח הגדרה של מכרז רכיב למוכר חלופי ברמה העליונה, כמו בכל פלטפורמת מסחר אחרת.	תשובת מנהל פלטפורמת Google Ads: זו לא העמדה של Google. פלטפורמות הצד הקונה של Google (Google Ads ו-DV360) קונות חשיפות מבורסות שאינן של Google. זה נכון גם לגבי חשיפות של PA API וגם לגבי חשיפות של מודעות API שלא הוגדרו כ-PA.
תגובה של השוק	החששות של Mozilla: הקהל המוגן של Google מגן על המפרסמים (ועל Google) יותר מאשר מגן עליכם.	אנחנו מעריכים את ההערכה של Mozilla ונמשיך לערב את המשוב של Mozilla בפורומים של תקנים ציבוריים. אחד מהנושאים שצוינו בהערכה שלהם הוא שההטמעה הנוכחית של PA API עדיין לא אוכפת את כל אמצעי ההגנה המתוכננים. הגישה שלנו להשקת PA API נועדה למצוא את האיזון הנכון בין עידוד השימוש לבין יישום אמצעי הגנה על הפרטיות בהקדם האפשרי. במסגרת התוכנית הזו, הגדרנו תוכנית עבודה להטלת הגבלות על הפרטיות לאורך זמן, כדי להקל על השילובים עם ממשקי ה-API וגם כדי לתת לנו זמן לאסוף משוב נוסף שנוכל לשלב באמצעי ההגנה העתידיים (למשל, תכונות VAST בפריימים מגודר). אנחנו גם מברכים על ההודעות האחרונות של Mozilla לגבי הגישה שלה לפרטיות ולפרסום בדיגיטל: "אינטרנט חופשי ופתוח לא צריך לבוא על חשבון הפרטיות" וגם "שיפור הפרסום אונליין באמצעות מוצרים ותשתית".
(דווחו גם ברבעונים קודמים) תוצאות המכרזים	בקשה למכרז יחיד להחזיר כמה כתובות URL לעיבוד עם הדירוג המתאים שלהן. כך קל יותר לבטל כפילויות בפרסום מותאם אישית, וכך אפשר למנוע בעיות שקשורות לממשק המשתמש ולזמן האחזור.	התשובה שלנו דומה לתשובות ששלחנו ברבעונים קודמים: חשבנו על שיתוף של כמה כתובות URL לעיבוד, והציון המתאים שלהן, מתוך מכרז יחיד של PA API, אבל לא הטמענו את האפשרות הזו בגלל חששות לגבי פרטיות. אנחנו מבינים את הרצון להימנע מהצגת אותה מודעה כמה פעמים למשתמש בדף אחד, ואנחנו בודקים את הבקשה הזו. אנחנו מזמינים אתכם לשלוח משוב נוסף מהסביבה העסקית כאן לגבי התמיכה הנוספת שנדרשת ב-PA API כדי לתמוך בצורה אופטימלית בתרחיש לדוגמה של פרסום מותאם.
ביצועים	חששות לגבי זמן אחזור שמשפיע על PA API.	שמענו חששות לגבי זמן האחזור, ולכן פיתחנו כמה תכונות כחלק מ-PA API שיאפשרו למערכות SSP להגדיר מגבלות על זמן האחזור של DSP וגם לבצע שיפורים שיכולים לקצר את זמן האחזור. לאחרונה עדכנו את מדריך השיטות המומלצות לזמן אחזור שכולל מידע נוסף על היתרונות של התכונות האלה. אנחנו גם ממשיכים לפתח שיפורים חדשים בזמן האחזור, חלק מהם מפורטים כאן.
בתי עסק ברמה העליונה	Google צריכה לאפשר לבעלי תוכן דיגיטלי לבחור מוכרים חלופיים של מכרזים ברמה העליונה של PA API.	ה-API של PA לא מתייחס למי שמתחיל את המכרז, גם בתכנון של מוכר יחיד וגם בתכנון של כמה מוכרים. הבחירה של כל חברה אם לתמוך במכרזים של PA API ואיך לעשות זאת היא באחריותה.
(דווח גם ברבעונים קודמים) טירגוט שלילי	בקשה לפתרון לתרחיש לדוגמה שבו מפרסם לא רוצה להציג מודעות לקהל מסוים.	אנחנו תומכים בטירגוט שלילי של IG באמצעות הצעות מחיר נוספות (לפי הקשר), שנותנות מענה לצרכים שבהם המפרסם לא רוצה להציג מודעות לקהל מסוים. הפרטים מפורטים במאמר הזה ובבקשת התמיכה הזו ב-GitHub. אנחנו גם בודקים פתרונות שתומכים בטירגוט שלילי ב-IG לבידינג ב-PA API, ונשמח לקבל משוב נוסף כאן.
(דווח גם ברבעונים קודמים) פרסום מותאם	בקשה לתמיכה במסגרת מוקפת למודעות מותאמות.	אנחנו שוקלים לתמוך בתרחיש לדוגמה הזה, ומדברים על פתרונות זמניים ופתרונות אפשריים כאן.
WebView	רציתי לקבל הבהרה לגבי התרחיש שבו ה-IG שהצטרף ב-Chrome לא היה זמין למכרז שהתבצע ב-WebView.	אנחנו כן רוצים לתמוך בתרחישים לדוגמה האלה ברגע שתהיה תשתית מספקת לשמירה על הפרטיות. אין לנו הודעות נוספות בשלב הזה, אבל נשמח לקבל משוב נוסף כאן.
מודעות IG שליליות	בקשה לעדכון עיבוד כתובות URL כדי לתמוך ב-IG שליליים באמצעות התכונה החדשה של הכותרת.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.
סינון לפי גיוון	בקשה לקבלת הנחיות להטמעת סינון מגוון כשמריצים פרסום מותאם ב-PA API עם מספר מוכרים ומספר מכרזים.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
(דווח גם ברבעונים קודמים) מסננים לחסימה	בקשה לקבלת הנחיות לאכיפת כללי 'חסימה על ידי בעל תוכן דיגיטלי' (מסננים) כשמריצים פרסום מותאם ב-PA API עם מספר מוכרים.	כאן יש לנו הנחיות בנושא, ונשמח לקבל משוב נוסף.
הגבלות	מבקשים להתיר הגבלות ברמת הדומיין במקום ברמת תת-הדומיין.	ההגבלות ברמת תת-הדומיין או ברמת המקור מבוססות על מודל האבטחה הבסיסי של האינטרנט, ולכן זהו עיצוב ברירת המחדל שלנו. פרטים נוספים מופיעים כאן וכאן.
בידינג מהימן	בקשה לסוכן משתמש ולרמזים קשורים על הלקוח בבקשות לקבלת אותות בידינג מהימנים.	אנחנו עוקבים אחרי הבקשה לתכונה הזו . נשמח לקבל ממך משוב נוסף.
(דווחו גם ברבעונים קודמים) כמה חשבונות IG	שימוש בכמה מודעות IG באותו בידינג.	אין תמיכה באפשרות הזו כרגע ב-PA API, כי היא תוביל לשינוי במודל הפרטיות הבסיסי. נשמח לדון בנושא כאן.
(הנתונים האלה דווחו גם ברבעונים קודמים) ביצועים	העברת יותר לוגיקה ללקוח עלולה לפגוע בביצועי הדף ובחוויית המשתמש, וכתוצאה מכך גם בשיעורי האופטימיזציה למנועי חיפוש של האתר.	אנחנו מדברים על הבעיה הזו ונשמח לקבל משוב נוסף כאן.
הדינמיקה של המכרז	השימוש ב-PA API מפחית את המידע על הדינמיקה של המכרז (למשל: מי משתתף בכל רכיב במכרז וכו') וכך מפחית את מספר בעלי האתרים עם יכולת מעקב וקשה לדעת אם העסקאות נשמרות.	כאן הצגנו פתרון למעקב אחר מבצעים. אנחנו מתכננים לשנות חלק מהשדות הקיימים וליצור כמה שדות חדשים באובייקט ה-IG, כדי לאחסן מזהי DealID ו-SetID, ולאפשר להם להפיץ את הנתונים מ-generateBid אל ציון מודעה או תעבורת נתונים יוצאת (egress) באמצעות דיווח ברמת האירוע. כך תוכלו לספק תמיכה מספקת לתרחיש לדוגמה של העסקה. אנחנו מקבלים בברכה משוב על מטא-נתונים אחרים שספקי טכנולוגיות הפרסום מתייחסים אליהם כקריטיים לדינמיקה של המכרזים וכחשובים לשמירה על יכולת המעקב של בעלי התוכן הדיגיטלי. אנחנו ממליצים למומחים טכנולוגיים בתחום הפרסום לספק דוגמאות ספציפיות למטא-נתונים שהם מתכוונים אליהם, ומאילו צדדים לאילו צדדים הם צריכים לעבור.
GAM	חששות לגבי הדרישה להשתמש ב-GAM בתור שרת המודעות של בעלי האפליקציות כדי לגשת לביקוש ב-AdX.	התשובה שקיבלנו מ-Google Ad Manager: מערכת GAM לא דורשת מבעלי תוכן דיגיטלי להשתמש בפונקציונליות של שרת המודעות שלה כדי לגשת לפונקציונליות של פלטפורמת המודעות שלה.
(דווח גם ברבעונים קודמים) מכרז רכיבים	הזוכים במכרזים של רכיבי API של PA יהיו גלויים ל-GAM, מה שעלול לעורר חששות לגבי גישה לא שוויונית למידע.	התשובה שלנו לא השתנתה מאז הרבעונים הקודמים: התשובה שסופקה על ידי Google Ad Manager: "אנחנו מתמקדים כבר שנים בשמירה על הוגנות במכרזים, כולל ההבטחה שלנו שלא נשתף עם קונה אחר מחירים ממקורות פרסום לא מובטחים של בעלי תוכן דיגיטלי, כולל מחירים של פריטים לא מובטחים, לפני שהקונה יציע מחיר במכרז. מאוחר יותר אישרנו את ההתחייבות הזו במחויבויות שלנו לרשות התחרות בצרפת. במכרזים של PA API, אנחנו מתכוונים לקיים את ההבטחה שלנו ולא לשתף את הצעת המחיר של כל משתתף במכרז עם משתתף אחר במכרז לפני סיום המכרז במכרזים עם מספר מוכרים. חשוב להבהיר: אנחנו לא נשתף את המחיר של המכרז לפי הקשר עם אף מכרז רכיבים, כולל המכרזים שלנו, כפי שמוסבר בעדכון הזה. בנוסף, אנחנו לא משתמשים במידע על הגדרות המכרז של הרכיבים, כולל אותות שהקונים מספקים ל-SSP, כחלק מהמכרז שלנו. למעשה, נשמח לשינויים ב-PA API שיאפשרו למוכרי רכיבים לציין את הגדרות המכרז של הרכיבים שלהם באופן שהמוכר ברמה העליונה לא יוכל לראות".
GAM	האם מערכת GAM תבקש חלוקת הכנסות על הרצת מכרזים ברמה העליונה או על דיווח עליהם, אם מערכת GAM לא השתתפה ביצירת מכרז של רכיב API של IG או של PA?	התשובה שסופקה על ידי Google Ad Manager: כשבעלי תוכן דיגיטלי בוחרים להשתמש ב-GAM כשרתי המודעות שלהם, מערכת GAM מריצה את המכרז ברמה העליונה ומחייבת על הצגת המודעות עבור הפונקציונליות של שרתי המודעות שלה (אותה עמלת הצגת מודעות שחלה מחוץ למכרזים של PA API). עם זאת, אם המודעה הזוכה מגיעה ממפיץ רכיבים שאינו GAM – כלומר, GAM לא השתתף ביצירת המכרז של רכיבי IG או PA API – מערכת GAM לא מטפלת בחיוב ולא מחייבת עמלת מדיה באחוזים.
קליקביליות	האם הרישום של אירועי הקליקים כפוף לאותה פרטיות דיפרנציאלית?	בשלב הזה, לא מתוכנן להחיל על התכונה הזו הגבלות של 'k-anon', כי 'מספר הקליקים' יהיה זמין רק כ-browserSignal בתוך הפונקציה generateBid(). הוא לא זמין כמאפיין חדש בדוחות ברמת האירוע.
ביצועים	עלויות גבוהות של תעבורת נתונים יוצאת (egress) כתוצאה מתגובה לא מותנית לבקשות להצעות מחיר לפי הקשר.	אנחנו לא יכולים לספק מידע ישיר על פלטפורמות ה-DSP שיש להן מודעות IG, מטעמי פרטיות. עם זאת, אנחנו בודקים פתרונות חלופיים שיכולים לספק תובנות תוך שמירה על הפרטיות.
מודעות מותאמות ומודעות וידאו Outstream	שליחת בקשה לעדכונים לגבי נקודת המבט של Chrome לגבי מודעות מותאמות ומודעות וידאו Outstream.	המיקום של Chrome תלוי בתרחיש לדוגמה הרלוונטי. בעמדות וידאו, העמדה של Chrome היא שהתפקיד שלנו הוא לעודד את הסביבה העסקית להתמזג בפתרונות אפקטיביים של מודעות וידאו In-stream באמצעות ממשקי ה-API שלנו. בינתיים, ההצעה הממשית היחידה שאנחנו מודעים לה היא ההצעה של GAM. במודעות מודפסות, אנחנו אוספים משוב באופן פעיל כאן, ואנחנו מתכננים לעדכן בקרוב את טכנאי הפרסום לגבי שלבים נוספים של תהליך הגילוי.
מעקב בזמן אמת (RTM)	תנועה המסומנת בתווית לא שולחת דוחות RTM.	אנחנו מודעים לפערים האלה ופועלים כדי לספק פתרון. נשתף עדכון כשהתכונה תהיה זמינה כאן.
תמיכה בתוספי קהלים	בקשה לעדכון לגבי התמיכה בתוסף 'הרחבת קהל' או בקהלים שנוצרו על ידי מוכרים ב-PA API.	אנחנו פועלים כדי לספק פתרון לתרחיש לדוגמה הזה. אנחנו אוספים משוב מהסביבה העסקית לגבי מה שאנחנו צריכים לבנות ולתמוך בו. נשתף עדכון כשיהיה אפשר, ונשמח לקבל משוב נוסף כאן.
ניפוי באגים	בכלי הפיתוח של Chrome אין חלונית למעקב אחרי הביצועים המפורטים של PA API. לדוגמה, יכול להיות שהביצועים הכוללים יושפעו ממספר ה-IG או ממספר הקונים.	המשוב הספציפי הזה קשור ליכולות של ממשק המשתמש של הכלי למפתחים ב-Chrome לסייע במעקב, אבל ב-7 באוקטובר השקנו את היכולת של טכנולוגיות הפרסום להגדיר אירועים מותאמים אישית שיכולים לשמש כבסיס למעקב ולהתראות. פרטים נוספים זמינים כאן, ואנחנו מקווים שהעדכון הזה יטפל בחלק משמעותי מהמשוב הזה. אנחנו מזמינים אתכם לשלוח משוב נוסף על התכונה הזו, בין אם הוא קשור לנקודות הנתונים הנתמכות ובין אם הוא קשור לחוויית המפתחים. תוכלו לעשות זאת כאן בפורום הדיון המתאים ב-GitHub.
אותות	חששות לגבי היכולת של פלטפורמות DSP להבטיח ש-perBuyerSignals יישלח ל-SSPs ללא קשר לתוצאות של מכרזים לפי הקשר.	ההנחה היא שבמכרז לפי הקשר יש רק הצעת מחיר אחת מנצחת מ-DSP אחד, או ליתר דיוק הצעת מחיר אחת שאפשר לנסות לשפר במכרז API של PA. בתהליך ה-API של PA, ה-SSP מחליט לאילו פלטפורמות DSP הוא רוצה לשלוח הזמנה כדי לבדוק אם יש להן ביקוש (בצורת IG במכשיר). יכול להיות מאוד, ואפילו סביר מאוד, שמערכת ניהול רשתות (DSP) שהפסידה במכרז לפי הקשר תקבל 'הזמנה מחדש' להשתתף במכרז של PA API. בשלב 'ההזמנה מחדש', אם ה-DSP יחליט לאשר, הוא יעביר ל-SSP את כל האותות שמערכת אימות המודעות רוצה לוודא שה-DSP יבחן, אם קיימים כאלה בקמפיין. במילים אחרות, במכרז ה-API של PA תמיד יש דרך ל-DSP לשלוח אותות perBuyer ל-SSP, ללא קשר למה שקרה במכרז לפי הקשר.
אותות	הבקשה להוספת prevClicks לאובייקט browserSignals מועברת אל generatedBid().	אפשר לטפל בבקשה הזו באמצעות ההצעה שלנו לתמוך באותות של נטייה ללחיצה. הכרזנו על התכונה הזו בפוסט האחרון שלנו בבלוג ובהסבר התואם. נשמח לקבל ממך משוב נוסף על ההצעה הזו כאן.
(דווחו גם ברבעונים קודמים) אותות ליצירת מודלים	בקשה להגדלת מספר הביטים של האותות למודלים מ-12 ביט ל-30 ביט.	הגבנו למשוב הזה עם הצעה נגדית כאן. אנחנו פועלים באופן פעיל בתחום כדי להבין את הדעות של הגורמים השונים לגבי ההצעה שלנו, ואנחנו שוקלים כרגע את היתרונות לתעשייה מול ההשפעה על משתמשי Chrome וגורמים אחרים בעלי עניין.
מאמרי עזרה	בקשה לקבלת הדרכה על שימוש בשרתים של מפתח/ערך (K/V) וב-TEE.	הדרכה לגבי שימוש ב-TEE בהקשר של K/V זמינה בפרטי תכנון מודל האמון של שירות K/V כאן.
משך החיים של דיווחים שליליים על חשבון	בקשה להארכת משך החיים של מודעות IG שליליות ל-365 ימים.	גורמים שליליים יכולים למנוע הצגת מודעות, אבל גורמים זדוניים עדיין יכולים להשתמש בהם כדי לחשוף מידע על משתמשים, וכתוצאה מכך לגרום לסיכונים לזיהוי מחדש (למשל, אחת הדרכים שבהן גורמים זדוניים לתקוף היא פשוט להגיש הצעות מחיר גבוהות עם IG שליליים שוב ושוב כדי להבין אם משתמש ביקר או לא ביקר באתרים מסוימים). אם נשאיר את TTL ל-365 יום, לגורמים זדוניים יהיו הרבה יותר נתונים על תגובות IG שליליות, וכתוצאה מכך יהיו סיכוני פרטיות גבוהים יותר. לכן, אנחנו לא יכולים לתמוך בבקשה הזו כדי להגן על פרטיות המשתמש.
מפרטי API	אילו ערכים אפשר להוסיף כדי להעביר אותם כחלק מ-perBuyerSignals? האם בית העסק יכול להגדיר את זה באופן שרירותי?	בעזרת perBuyerSignals, המוכרים יכולים לספק לקונים את כל המידע שהם רוצים שיהיה זמין במכרז. הסביבה העסקית צריכה להחליט מה היא רוצה להוסיף, אבל נשמח לקבל דיון נוסף כאן.
החלפות של מאקרו של גודל מודעה	אני מחפש הנחיות לגבי החלפות של מאקרו של גודל מודעה שלא פועלות.	בקרוב נשתף פרטים נוספים באופן ציבורי.
החלפת מאקרו של SSP לאחר הצעת המחיר: התחזות לכתובת URL ברמה העליונה	אילו מנגנונים ב-Chrome יכולים להוסיף כדי לאפשר לספקי אימות לאמת את כתובת ה-URL ברמה העליונה במסגרת ארגז החול לפרטיות? האם יש נקודות נתונים או אותות חלופיים שאפשר להשתמש בהם בתוך פריימים מגודר כדי להבטיח את הדיוק של כתובת ה-URL ברמה העליונה שסופקה על ידי ה-SSP?	אנחנו מדברים על המשוב הנוסף הזה כאן.
בקשה לתכונה	בקשה לספק UACH עם אנטרופיה נמוכה באחזור של updateURL ובדיווחים חוזרים על ביצועי קמפיינים בזמן אמת.	הבקשות האלה נמצאות בבדיקה כאן, ונשמח לקבל משוב נוסף כאן וכאן.
בקשה לתכונה	צריך לבקש שתכנון ניפוי הבאגים בהסכמת השרת המהימן יופעל כשלקוח נתון מופעל, לשליחת דוחות ללא דגימה ברמת האירוע forDebuggingOnly דרך forDebuggingOnly.reportAdAuctionWin() ו-forDebuggingOnly.reportAdAuctionLoss().	זו בקשה פעילה שאנחנו עוקבים אחריה כרגע, ונעדכן את הסביבה העסקית כשיהיה זמין. נשמח לקבל משוב נוסף כאן.
שימוש ב-API	בקשה לקבלת הנחיות לגבי ספירת היקף החשיפה למשתמשים ייחודיים והיקף החשיפה לחשיפות.	אנחנו דנים בהצעה לפתרון לקריאת קובצי IG מתוך כלי עבודה לאחסון משותף, שבעזרתו תוכלו לשלוח דוחות מצטברים פרטיים. פרטים נוספים זמינים כאן, ונשמח לקבל משוב על ההצעה ועל התועלת שלה לסביבה העסקית.
שימוש ב-API	חוסר בהירות לגבי מה שבעלי תוכן דיגיטלי צריכים לבדוק, אילו ממשקי API חשובים, אילו ממשקים צריך להפעיל ומה צפוי בעתיד.	אנחנו פועלים כדי לספק תמיכה טובה יותר לבעלי תוכן דיגיטלי ולתפקיד שלהם בסביבה העסקית.
שימוש ב-API	האם אפשר להוסיף מאזינים לאירועים של Worklet של מכרז מודעות?	אי אפשר לעשות זאת באמצעות אירועים רגילים, אבל אירועים של פרוטוקול Chrome Devtools יטפלו בחלק מהבעיה הזו. לתשומת ליבך: סביר להניח שאירועים רגילים ישפיעו על הבידוד או על הפרטיות, אבל פרטים נוספים זמינים כאן.
K-Anonymity	בקשה להבהרה לגבי דרישות הרינדור של המודעות (למשל, לפחות 50 אנשים היו רואים את המודעה, אם היה מותר להציג אותה).	מסמכי התיעוד למפתחים מספקים סקירה כללית של הציפיות שלנו לגבי פיתוחים עתידיים. באופן ספציפי, הוא מסביר שהסף הראשוני של k=10 אנשים הוא k=10. רשימת התפוצה blink-dev מספקת עדכונים על מה שקורה בזמן אמת ב-Chrome. כפי שמוגדר ב-thread של רשימת התפוצה k-anonymity, אנחנו אוכפים כרגע באופן ניסיוני את הדרישה ל-k-אנונימיות על כ-1% מהתנועה היציבה ב-Chrome, ואף פעם לא אוכפים אותה על הפלחים עם התוויות המפורשות ('מצב א' ו'מצב ב').
מכנסיים מחויטים	האם ניתן להסיר את זרימת ה-TEE K/V באופן זמני או לצמצם את הצורך לקרוא את כל מקטעי ה-N, לסכום כלשהו שמאזן את ההגנה על הפרטיות מול התועלת (כלומר, ביצועים/עלות של מפתח/ערך)?	בקשות מהסוגים האלה מטופלות רק במכונות שהן לא בסביבת ייצור, שבהן אפשר לשלוט בניהול ההקצאות (chaffing). עדיין נדרשת שריפה של נתונים למניעת זליגה (chaffing) במכונות ייצור. נוכל להעריך את המצב אחרי שנקבל משוב מהשימוש בסביבה ללא ייצור.
מכנסיים מחויטים	בקשה להוסיף דגל להשבתת chaffing מקובץ בינארי של K/V לצורכי ניפוי באגים או ללא ייצור.	הדגל הזה מופיע במהדורה 1.0.0.
באג ב-API	ממשק ה-API הפסיק לפעול אחרי השדרוג ל-Chrome 126, למרות שה-API הופעל בהגדרות.	התברר שהבעיה קשורה לדגל Chrome 'enable-fenced-frames', שהמשתמשים הפעילו למטרות פיתוח. איפוס הדגל הזה לברירת המחדל יפתור את הבעיה.
דיווח	בקשה להפוך את ההסכמה לשימוש ב-API לדיווח בזמן אמת לא תלויה במוכרים עבור קונים.	הבקשה הזו נמצאת בבדיקה כאן. פתרון ה-RTM הושק לאחרונה, ואנחנו שמחים לקבל משוב ספציפי מטכנולוגיות הפרסום שכבר הטמיעו את התכונה.
דיווח	בקשה לדיווח של צד שלישי: ספקי DSP ו-SSP מקבלים התראות על חשיפות מ-Chrome, אבל ספקים טכניים בשכבת הביניים לא מקבלים אותן כברירת מחדל.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.

שירותי מכרזים מוגנים

נושא המשוב	סיכום	תגובה מ-Chrome
TEEs	במסגרת סטנדרטים טכניים, Google שדוגלת בהטמעה ידנית היא מגבלה מחמירה על הבחירה של ספק שירותי ענן. אפשר לפעול בהתאם לתקנים הטכניים החלים בלי לבקר ב-Bureau of Cloud Providers, כפי ש-Google כנראה חושבת. העיכוב האיחור של ספקים חלופיים בשנת 2025 (המוקדם ביותר) הוא לא מקובל, כי הוא יכלול השפעות על הרשת שיעודדו את מתן הפתרונות של Google.	שירות האגרגציה הוא השירות היחיד שצריך להריץ בשירות TEE כדי לטפל בחלק מתרחישי השימוש ב-AdTech. שירות הצבירה תומך גם ב-Amazon Web Services‏ (AWS) וגם ב-Google Cloud Platform‏ (GCP). על סמך המשוב מהטכנולוגיות של מודעות, אנחנו סבורים שתמיכה כזו מספיקה בשלב הזה. בספקים נוספים של ענן – Google פרסמה קריטריונים מפורטים ל-TEEs בספקים של ענן ציבורי. המטרה שלהם היא להבטיח שפתרונות ה-TEE עומדים ביעדים של ארגז החול לפרטיות בנושא פרטיות ואבטחה. באופן ספציפי, שרתי TEE של ארגז החול לפרטיות מעבדים נתוני משתמשים לא מוצפנים מאתרים שונים (למשל, נתונים מאתרים של בעל התוכן הדיגיטלי ושל המפרסמים לצורך שירות צבירת נתונים). הם צריכים להיות מאובטחים כדי לעמוד ביעדים של ממשקי ה-API בנושא פרטיות המשתמשים. סביבה מאובטחת נדרשת גם כדי להבטיח שה-API ימשיך להגן על המידע העסקי הסודי של החברות (לדוגמה, מניעת גישה של משתתפים אחרים במכרז של PA API לנתונים העסקיים הקנייניים של הקונה). למיטב ידיעתנו, אין כרגע טכנולוגיית TEE שמגנה באופן מלא על נתוני המשתמשים מפני מפעיל שעשוי להיות מרושע. לכן, אנחנו כוללים כמה דרישות כדי לאמת את מהימנות ספק הענן. לא ברור לנו למה הכוונה ב'משרד ספקי הענן', והוא לא חלק מהדרישות. נשמח לקבל מכם משוב על הדרישות. אנחנו גם ממשיכים להעריך את התמיכה בספקים חדשים, כולל על סמך בקשות שנשלחות באמצעות התהליך שמתואר במאמר ההסבר. עד עכשיו קיבלנו רק בקשה לתמיכה ב-Azure, ואנחנו בודקים אותה.
B&A	קשה להעריך את המורכבות הטכנית וההיתכנות של שירות B&A, כי העיצוב ממשיך להתפתח.	כדי לטפל בבעיות האלה, פרסמנו הסברים מפורטים ב-GitHub על העיצוב של B&A, לוחות זמנים של הזמינות ותוכנית עבודה של תכונות שתומכות ב-PA API. אנחנו תומכים בטכנולוגיות פרסום שמנסות לפרוס את B&A, ומקבלים משוב מהסביבה העסקית ב-GitHub.
B&A	אתם מחפשים הדרכה ודרך טובה יותר לחשב את העלות של השימוש ב-TEE לבדיקה ובדיקה חוזרת (B&A) כדי להתחיל להשתמש בו או לעבור אליו מהמכשיר.	לאחרונה פרסמנו את המדריך לקביעת הגודל של מכונות שרת K/V, שכולל כלים למדידת עלויות בצורה מדויקת יותר.
שרת K/V	שירות אימות המודעות מבקש להשתמש בכתובת ה-URL המלאה של הדף לשרת ה-K/V כדי לבצע אימות מודעות.	אנחנו בודקים כרגע את האפשרות לספק את כתובת ה-URL המלאה של הדף לשרת K/V שפועל ב-TEE למטרות אימות מודעות. כתובת ה-URL המלאה של הדף לא תהיה זמינה ב-K/V BYOS.
אבטחה במכרזים	חיפוש תכונות אבטחה למכרזים כדי להבטיח שגורמים זדוניים לא ייגשו למידע אישי רגיש או לא יפעלו כמתחזים – אילו תכונות מגינות על המכרז מפני התקפות שליחה מחדש ואיך אפשר ליישם אמצעי אבטחה?	מודל האבטחה הנוכחי של B&A יכול להגן על תקינות המכרזים. בדיקת B&A פועלת ב-TEE שמגן על הסודיות של האותות והקוד של טכנולוגיות הפרסום מפני גורמים זדוניים. בארכיטקטורה של B&A, עומס העבודה (payload) של בקשת B&A מוצפנת (טקסט מוצפן של בקשה) ועוברת מהלקוח דרך שרת מודעות לא מהימן לשירות SellerFrontEnd‏ (SFE, שמופעל על ידי ספקי SSP ב-TEE). הטקסט המוצפן של הבקשה מכיל מזהה יצירת גרסת build שמבוסס על חותמת זמן. ה-SFE יבדוק את חותמת הזמן של הבקשה ויידחה כל בקשה שחוזרה על עצמה ולא נשלחה בטווח של n שניות +/- לפי שעון השרת. בנוסף לכך, B&A יכול להחזיר מטען ייעודי (payload) מרופד בגודל קבוע של תגובה עבור תקשורת שרת לשרת. הפתרונות האלה יכולים לעזור לצמצם את התקפות ההפעלה מחדש (replay) במערכת, כשגורם זדוני מנסה להפעיל מחדש את אותו עומס נתונים של בקשה כדי לקבל מידע נוסף על התוכן שלה. שירותי B&A נמצאים בתהליך תיעוד ועדכון של מודלים של אבטחה בהסברים.
שליחת אותות דרך שרת K/V של	צריך לבקש לכלול נתוני perBuyerSignals שנשלחים דרך שירות K/V במסגרת בקשת האותות המהימנים לבידינג מ-Chrome.	אנחנו בודקים את ההיתכנות של הכללת מידע מ-perBuyerSignals, שמועבר לשרת K/V שפועל בסביבת TEE, כולל כתובת URL מלאה של הדף.
שרת K/V	בקשה לקבלת לוח זמנים מפורט יותר להטמעה של אילוצים על פרטיות ב-K/V וב-B&A.	אנחנו מבינים את הצורך בגישה הדרגתית לאימוץ TKV ומעריכים את הבקשות הספציפיות שלך לגבי K/V ו-B&A. עם זאת, לאחר בדיקה יסודית, החלטנו שלא להקל בשלב הזה על אמצעי ההגנה על הפרטיות בממשקי ה-API האלה. אנחנו מאמינים שהאמצעים האלה, כמו יצירת נתונים חסרי משמעות, חיוניים לשמירה על פרטיות המשתמשים ולשמירה על האמון בארגז החול לפרטיות.
שרת K/V	מחפשים הדרכה לגבי התאמת קנה המידה של מאגר ה-K/V באמצעות הגדרה תואמת.	המדריך לקביעת הגודל של מכונות שרת K/V שפורסם לאחרונה יכול לעזור לכם בנושא הזה. הכלי יספק את ה-QPS (יצוין בתור "RPS" בהסברים) בכל שילוב של פרמטרים.
שרת K/V	מוסיפים את פרטי בית העסק בבקשה של שרת K/V.	אנחנו מדברים על הנושא הזה ונשמח לקבל משוב נוסף כאן.
שירותי K/V + B&A	בקשה להבהרת לוח הזמנים או מפת הדרכים של השקת K/V ו-B&A.	גם ל-K/V וגם ל-B&A יש שלבים ולוחות זמנים: לשרת K/V בשילוב עם מכרזי PA API במכשיר (לעומת B&A), ציר הזמן הציבורי זמין כאן. מידע על ההגדרה של 'זמינות לכלל המשתמשים' ב-K/V מופיע בקטע 'מפת הדרכים', שמגדיר את קבוצת התכונות לגרסת הבטא ול-Google Analytics. למידע על B&A, אפשר לראות את ציר הזמן הציבורי כאן ואת מפת הדרכים כאן. אנחנו מגדירים בדיקת קנה מידה כ'בדיקה מלאה ויציבה בקנה מידה של ייצור'. כאן אפשר למצוא את קבוצת התכונות הספציפית בשלב הזה. ל-B&A יש גם שלבי אלפא ובטא, כך שבדיקת ההתאמה לעומס תכלול את קבוצת המשנה של התכונות של השלבים הקודמים. גם לגבי K/V וגם לגבי B&A, נשמח לדעת אם הגדרות השלבים האלה עוזרות לך להבין מה יהיה זמין ומתי. אם עדיין יש פערים, אפשר לפנות אלינו. נשמח להפוך אותם לספציפיים יותר כדי לעזור לך בתכנון.

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

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

הנושא של המשוב	סיכום	תגובה מ-Chrome
תגובה של השוק	הדרישה שמערכות שיוך מתחרות ישתמשו רק בדיווח ברמת האירוע ובדיווח מסכם/צבירה במסגרות צרות היא הגבלה שרירותית על התחרות. הוא מונע טירגוט מחדש ושיוך ספציפיים למכשיר בזמן אמת ברמת האירוע, גם אם יש אמצעי הגנה כדי להבטיח תאימות להגנה על נתונים (למשל, הסרת פרטי זיהוי).	העיצוב שצוין מבוסס על יעדי הפרטיות של ה-API – למשל, הגנה על מידע מאתרים שונים שמועבר מאתר אחד לאתר אחר. לדוגמה, ARA תומכת בשיוך ברמת האירוע באמצעות דוחות אירועים. הדוחות על אירועים מתעכבים לפחות שעה אחת. העיכוב הזה נחוץ כדי שיהיה קשה לשייך את הדוח ברמת האירוע לזהות המשתמש באתר של המפרסם באמצעות התקפות צדדיות של תזמון, כפי שמתואר כאן. בנוסף, יש דרכים אחרות לבצע שיוך, מעבר ל-ARA, כמו איסוף מידע ישירות ממשתמשים שמספקים נתונים מזהים ביודעין. נשמח לקבל משוב על תרחישים לדוגמה שלא ניתן להשיג באמצעות גבולות הפרטיות הנוכחיים של ממשקי ה-API של ארגז החול לפרטיות.
למשטחים שונים	בקשה לאישור אם ממשקי ה-API של ARA ו-Shared Storage תומכים בתרחישים לדוגמה של מספר פלטפורמות, ואיפה הדבר מוצג.	בשלב זה, אין תמיכה ב-ARA ובאחסון משותף בשיוך בכמה מכשירים (במספר פלטפורמות). יש תמיכה בחישוב שיוך (Attribution) בין אפליקציות לאתרים באותו מכשיר (באמצעות ARA).
(דווחו גם ברבעונים קודמים) במכשירים שונים	האם ARA תומך בהמרות חוצות-מכשירים?	התגובה שלנו דומה לתגובה שלנו ברבעונים קודמים: הצגת מודעות במכשירים שונים מציבה אתגרים חדשים בנושא פרטיות, בנוסף לאתגרים של 3PC, ומוסיפה גם אתגרים של הפצת טכנולוגיה, בהתאם למגוון המכשירים והפלטפורמות שבהם משתמש עשוי להשתמש. אנחנו בודקים פתרונות פוטנציאליים, אבל אנחנו מתמקדים בתרחישים קריטיים לדוגמה שנתמכים כרגע על ידי ARA, ואין לנו כרגע לוח זמנים לתמיכה במכשירים שונים.
שינוי קנה מידה	חששות לגבי האפשרות שה-Attribution Report API‏ (ARA) מוגדר כרגע, ואפשר להשיק אותו בצורה מהימנה ולשנות את ההיקף שלו כדי שישרת את כל משתמשי Chrome.	ARA זמין כרגע לכל משתמשי Chrome ופועל כצפוי. בנוסף, אנחנו ממשיכים לבדוק את המהימנות והיכולת להתאמה לעומס של ARA ולעקוב אחריהן, כי מספר חברות טכנולוגיות הפרסום שמנסות את ARA הולך וגדל. אנחנו מקבלים בברכה משוב נוסף על הסביבה העסקית בנושא הזה כאן.
(דווח גם ברבעונים קודמים) ניקוי כפילויות	חששות לגבי האופן שבו ARA מציע להגביל את מנגנון השיוך (Attribution) במכשירים, כך שבעלי אתרים לא יוכלו לבצע ביעילות לוגיקה של שיוך לאחר השלמת ההמרה בדוחות סיכום, כולל מחיקה של כפילויות של המרות מאותו סוג באותו קליק על מודעה.	התשובה שלנו לא השתנתה מארבעי החודשים הקודמים: ניפוי כפילויות במכשירים ובצינורות מדידה הוא אתגר ידוע ועדכני שפתרונות הפרסום הדיגיטלי נתקלים בו גם היום עם 3PC. בעזרת ARA, טכנאי הפרסום יכולים להחליט מתי לרשום המרות ספציפיות ולהוסיף מטא-נתונים ספציפיים כדי לציין את צינורות המדידה שבהם השתמשו כדי לעקוב אחרי ההמרות (כלומר, חלק ממפתח הצבירה), שניתן להשוות אליהם צינורות מדידה אחרים. אנחנו מקבלים בברכה משוב נוסף על הסביבה העסקית בנושא הזה כאן.
מעקב המרות	בקשה לאפשרות לפעול עם המרות מכמה דומיינים.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף על סביבת הפרסום.
דיווח	הדפדפן ימתין יומיים לפחות עד 30 ימים לשליחת ההמרה. מצב כזה יכול לגרום לחששות, מאחר שרוב המפרסמים בעלי העניין הם מפרסמים שמתמקדים בביצועים, ועובדים כמעט בזמן אמת.	הגדרות ברירת המחדל של דוחות ברמת האירוע כוללות את חלונות הדיווח הבאים כברירת מחדל: יומיים, 7 ימים ו-30 ימים. כשמשתמשים בדיווח גמיש ברמת האירוע, טכנולוגיות פרסום של מודעות יכולות לשנות את מספר חלונות הדיווח ואת האורך של חלונות הדיווח מערכי ברירת המחדל. אפשר לשנות את חלונות הדיווח ל-1 שעה לפחות, כדי לעזור למפרסמים שמתמקדים בביצועים. אנחנו מקבלים בברכה משוב נוסף על הסביבה העסקית בנושא הזה כאן.
שיוך (Attribution) אונליין לאופליין	האם יהיו אפשרויות הטמעה לפרסום אונליין-לאופליין ב-ARA, או שיש הצעות אחרות למדידת שיוך (Attribution) אופליין-לאונליין?	בשלב הזה, אין תוכניות לתמוך בתרחישים של מדידה מאונליין לאופליין ב-ARA. יש אתגרים משמעותיים בנושאי פרטיות ואבטחה שצריך לקחת בחשבון כשמקבלים את סוג התמיכה הזה. כאן נשמח לקבל משוב נוסף על הסביבה העסקית לגבי תרחישים לדוגמה של התמיכה הזו.
דיווח על ניפוי באגים	איך לאחסן ו/או לאחזר מזהה פרסום כך שיהיה זמין לגישה לרישומי Chrome (מקור/טריגר) לצורך שיוך של אפליקציה לאתר?	כדי להפעיל את דוחות ניפוי הבאגים, ספקי טכנולוגיות הפרסום צריכים להוכיח לנו שהם כבר יכולים לזהות את המשתמש באפליקציה ובאינטרנט. המטרה היא לוודא שלא ייחשף מידע חדש בדוחות ניפוי הבאגים. ספק טכנולוגיית הפרסום יכול להוכיח את ההצטרפות על ידי מתן מפתח הצטרפות ייחודי לכל משתמש. מפתח האיחוד הזה יכול להיות מזהה ה-AdID או מפתח איחוד של צד ראשון. אם טכנולוגיית הפרסום משתמשת ב-AdID, ל-Chrome אין תמיכה מובנית בגישה ל-AdID מהדפדפן, וה-API מצפה שלכל טכנולוגיית פרסום תהיה שיטה משלה להעברת ה-AdID במהלך ההרשמה באינטרנט.
רמת פירוט הקטגוריה	האם אפשר להשתמש בשיטות חלוקה לקטגוריות שונות לכל מפרסם?	מומלץ להתנסות בגישות שונות לשינוי התקציב להוספת תוכן כדי למצוא את הגישה שמתאימה ביותר לתרחישי לדוגמה שלכם. ARA נוצר מתוך כוונה להיות גמישים ולהתאים אותם אישית כדי לספק מענה למגוון תרחישים לדוגמה של פרסום דיגיטלי. לכן מומלץ להתנסות בשיטות שונות של קיבוץ לפי מפרסם או לפי קטגוריה. שימוש בשיטות שונות של קיבוץ יכול להיות שימושי כשלמפרסמים יש הבדלים בערכי המדידה שהם רוצים לעקוב אחריהם ובנפח של ערכי המדידה.
מאמרי עזרה	בקשה למסמכים נוספים להטמעת app<>web ל-ARA.	פרסמנו כאן מסמכים ב-App<>Web for ARA.
ביצועים	מספר הבקשות שקשורות ל-ARA עלול להכביד על השרתים של בעלי התוכן הדיגיטלי בהשוואה למספר הבקשות ל-keepalive שנדרשות כדי להפעיל את האתר. צבירת אירועי מקור בבקשה אחת יכולה לעזור להפחית את העומס על השרת. אפשרות אחת היא לאפשר מערך של אובייקטים בקידוד JSON	אפשר לאסוף אירועי מקור בקבוצות על סמך לוגיקה ספציפית, עד גבול מסוים, באמצעות לוגיקה של JavaScript בשילוב עם ה-API. אנחנו בודקים את הבקשה הזו כרגע ונשמח לקבל משוב נוסף מהסביבה העסקית כאן.
בקשה לתכונה	הצעה לפתרון עקיף כי אין תמיכה בשילוב שרת-אל-שרת.	בשלב זה אנחנו לא מתכננים ליישם תמיכה בשילוב שרת לשרת ב-ARA. יש הרבה אתגרים בנושא פרטיות שצריך להמשיך לבחון כדי לאפשר תמיכה בשילוב שרת-אל-שרת. אנחנו מזמינים אתכם לשלוח לנו משוב מהסביבה העסקית לגבי תרחישי שימוש נוספים לתמיכה בין שרתים כאן.
מאמרי עזרה	בקשה למדריך למתחילים שמסביר את החלקים העיקריים של ARA או איך להתחיל לעבוד עם כמה תרחישים לדוגמה פשוטים.	מדריך למתחילים בנושא ARA זמין כאן. אנחנו עובדים על שיפור המסמכים האלה במהלך השנה, ונשמח לקבל משוב נוסף על תרחישי שימוש או תרחישים ספציפיים שדורשים מסמכים נוספים כאן.
שימוש ב-API	בקשה להמלצות לגבי התאמת התרומות לערכים קטנים רבים.	מומלץ להתנסות בגישות שונות לשינוי התקציב להוספת תוכן כדי למצוא את הגישה שמתאימה ביותר לתרחישי לדוגמה שלכם. בתרחיש שבו יש הרבה ערכים קטנים, מומלץ להתנסות בערכים שונים של epsilon כדי לזהות נקודות עיקול שבהן הרעש מ-epsilon עשוי להיות קביל לתרחיש לדוגמה שלכם. פרטים נוספים זמינים במאמר המחקר שלנו בנושא אופטימיזציה של דוחות סיכום ב- ARA.
גמישות ברמת האירוע	מתי תתבצע ההטמעה של 'גמיש ברמת האירוע' (פרטי טריגר מרובים)?	נכון לעכשיו, ההרשמה הגמישה ברמת האירוע תומכת בהתאמה אישית של ההיבטים הבאים בהגדרות ההרשמה: מספר הדוחות שניתן ליצור לכל מקור, מספר חלונות הדיווח ואורכם, וכן עוצמת הנתונים של הטריגר. אנחנו אוספים כרגע משוב נוסף לגבי הסביבה העסקית לגבי שיפורים גמישים נוספים ברמת האירוע, אבל אנחנו לא מתכננים ליישם אותם כרגע. אנחנו מקבלים בברכה משוב נוסף על תרחישי שימוש שעשויים להפיק תועלת מחלק מהשיפורים הגמישים ברמת האירוע שמפורטים כאן.
עיבוד בקטגוריות	בקשה להביא בחשבון הגבלת תרומות מצטברות לקטגוריות, וגם יכולת הרחבה עתידית ותאימות לאחור.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.
Epsilon	מה קורה לטווח האפסון אחרי ש-ARA עובר לזמינות לכולם?	ARA הגיע לזמינות כללית ב-Chrome ברבעון השלישי של 2023. בשלב זה אין תוכנית לשינוי חלון ערך האפסילון. ההצעה שלנו למבנה פיקוח מתוקן תספק הבטחות נוספות במקרים שבהם צפויים שינויים.
דיווח	דוחות Trigger-unknown-error לא מכילים מאפייני מקור בגוף הדוח.	כפי שמפורט במפרט, אין דרישה לשדות אחרים בגוף הדוח של trigger-unknown-error. אנחנו מכירים בכך שהטבלה שמתארת שדות בגוף הדוח עשויה להטעות, מפני שהשדות שקשורים למקור עשויים להופיע או לא להופיע בהתאם לגורם הבסיסי לשגיאה. לדוגמה, יכולה להתרחש שגיאה פנימית לפני שהלוגיקה של התאמת המקור מתבצעת, וכתוצאה מכך לא יהיו נתוני מקור שאפשר לאכלס איתם את דוח ניפוי הבאגים. עדכנו את המסמכים כדי להבהיר את הנושא.
שימוש ב-API	כשעובדים עם שני יעדי מדידה, ספירה וערך, האם צריך לפצל גם את התקציב לתרומה וגם את האפסולון?	כשעובדים עם שני יעדי מדידה, מומלץ לפצל את תקציב התרומה ביניהם.
דיווח	האם ARA תומך בשיוך של כמה נקודות מגע או בדוחות סיוע (נקראים גם דוחות 'תרומה')?	ARA לא תומכת כרגע בשיוך לכמה נקודות מגע או בדוחות סיוע. בשלב זה, אין לנו כל כוונה ליישם את האפשרות הזו. נשמח לקבל מכם משוב נוסף על תרחישי שימוש ועל העדיפות שלהם כאן.
באג ב-API	לגבי ARA, מסמכי התיעוד מציינים ש-XOR משמש לשילוב של מקור והפעלה של רכיבי מפתח צבירת נתונים, אבל בפועל נעשה שימוש ב-OR. חוסר ההתאמה הזה מוביל לבלבול ולשגיאות אפשריות בהטמעה.	המסמכים עודכנו בהתאם לשגיאה הזו.

Aggregation Service

נושא המשוב	סיכום	תגובת Chrome
משימות צבירת נתונים	בקשה לאפשר שימוש במספר תחיליות במשימות צבירת נתונים.	אנחנו בודקים את המשוב הזה ופרסמנו הצעה כאן. נשמח לקבל מכם משוב על ההצעה כאן.
בקשה לתכונה	בקשה לשינוי סקריפט terraform כך שאם service_account_token_creator_list לא מוגדר (או שהוא ריק), המערכת תדלג על שינוי מדיניות IAM של החשבון.	אנחנו בודקים את הבעיה כאן ונשמח לקבל משוב נוסף על הסביבה העסקית.
שימוש ב-API	נדרשת הבהרה לגבי תוכנית Terraform תמיד מציגה שינויים.	הבעיה הזו תוקנה בגרסה 2.8 של AgS.
שימוש ב-API	חיפוש המלצות לקביעת הגדרות לכל מפרסם לתדירות צבירת נתונים, עם סינון גמיש לתרומות.	בשלב זה, אפשר לקבץ בקשות לפי מפרסם באמצעות ARA. אפשר להשתמש בסינון גמיש של נתוני התרומה במקרים מתקדמים יותר שבהם ספקי טכנולוגיות פרסום רוצים לפלח את נתוני התרומה של דוח לפי תדירויות שונות. מידע נוסף על טכנולוגיות פרסום זמין כאן ועל השימוש במזהי סינון עם ARA כאן. אנחנו גם עובדים על מסמכים נוספים בנושא סינון מזהים.
בקשה לתכונה	בקשת תמיכה ב-'log_sum_exp' ב-Aggregation Service‏ (AgS).	פנינו לבעל העניין הזה כדי לקבל פרטים נוספים על תרחיש לדוגמה. נשלח עדכון ברגע שיהיו לנו פרטים נוספים.
בקשה לתכונה	אפשר לבקש לראות יומנים/תובנות/מדדים אחרים כשיש בעיות ב-AgS ובעיות פוטנציאליות ב-AgS שנפרס.	פורסמו עדכונים במסמכי העזרה שלנו, כאן, שכוללים שגיאות, דרכים לצמצום ההשפעה ותיאורים נוספים. אנחנו מקבלים בברכה משוב נוסף על שגיאות/מדדים/יומנים וכו' שלא מתועדים או לא זמינים, ועל פרטים שיהיו שימושיים כאן.
בדיקת API	מה יהיה הערך הסופי של epsilon אחרי תקופת הבדיקה?	בשלב זה אין תוכנית לשינוי חלון ערך האפסילון. אנחנו ממליצים למפתחים לנסות פרמטרים שונים ולשלוח משוב.
דיווח	הדוח נוצר, אבל עדיין מופיע קוד ההחזרה PRIVACY_BUDGET_AUTHORIZATION_ERROR.	כדי למנוע את השגיאה הזו, סיפקנו הנחיות לגבי ציון המקור הנכון לדיווח ודוחות שאפשר לצבור. נשמח לקבל ממך משוב נוסף על הבעיה, במיוחד אם יש שגיאות חוזרות ונשנות.
גילוי מפתחות	מהם התוכניות להצעה של חשיפת המפתחות?	עדיין אין לנו לוח זמנים להשקה של הצעת הגילוי של המפתחות, אבל אנחנו מבקשים מכם לשלוח משוב על ההצעה כאן.
התאמה אישית	מחפשים אפשרויות התאמה אישית שזמינות ל-Aggregation Service.	לא ניתן לבצע התאמות אישיות של שירות האגרגציה בתוך ה-TEE, אבל אפשר לבצע התאמות אישיות של רכיבים מסוימים מחוץ ל-TEE. הסיבה לכך היא תקני הפרטיות והאבטחה שאנחנו צריכים לשמור ב-TEE. אנחנו פועלים לעדכון המסמכים כדי לעזור לטכנולוגיות הפרסום להבין את הארכיטקטורה ואת הרכיבים שניתנים להתאמה אישית. לא נוכל לתמוך בהתאמות אישיות מסוימות. לכן אנחנו ממליצים לטכנאי פרסום להשתמש בהגדרות הרגילות שלנו כשהדבר אפשרי.
Spot לעומת מכונות על פי דרישה	האם המערכת נבדקה באמצעות מכונות זמניות לעומת מכונות על פי דרישה? האם יש חסרונות ספציפיים לשימוש במופעים של ספוט, מלבד האפשרות של חוסר זמינות זמני פוטנציאלי?	לא הקדשנו עדיפות לבדיקות במכונות זמניות כי אנחנו ממליצים למומחים בתחום טכנולוגיות הפרסום להשתמש במכונות על פי דרישה. החיסרון של מכונות זמניות הוא שהמשימה תופסק במהלך ניצול התקציב. אם התקציב נוצל והמשימה הופסקה לפני שצוות טכנולוגיית הפרסום קיבל את דוח הסיכום, טכנולוגיית הפרסום לא תוכל פשוט לנסות שוב את המשימה, אלא תצטרך לבקש שחזור תקציב. מומלץ להשתמש בשחזור התקציב רק במקרים של כשלים קטסטרופליים שנועדו לשמור על הפרטיות. אנחנו ממליצים להשתמש בטכנולוגיות פרסום כדי להגדיר התאמה לעומס (autoscaling) כדי לצמצם את העלויות. אם בוחרים ב-0 עבור שינוי אוטומטי של קנה המידה, לא יהיו מכונות פעילות עד שתתבצע בקשה לביצוע משימה (שימו לב שהפעולה הזו עשויה להגדיל את זמן האחזור, כי המכונות יופעלו בזמן הבקשה).
שגיאות ידועות ופתרונות	דרוש הבהרה לגבי משימה של Aggregation Service שמופיעה בה השגיאה 'שגיאת שירות'	הבעיה נפתרה כאן. כמו כן, עדכנו חלק מהודעות השגיאה שלנו כדי שיהיה קל יותר להבין אותן. לדוגמה, התחלנו להציג שגיאות ספציפיות יותר של הרשאות/אימות ב-AWS, בניגוד למצב הקודם שבו השגיאות האלה הוצגו כשגיאות פנימיות. עדכנו את המסמכים לגבי קודי שגיאות וצעדים לצמצום הבעיה כאן, ונשמח לקבל משוב נוסף על שגיאות שלא מתועדות או זמינות, ואילו פרטים יכולים להיות שימושיים כאן.

Private Aggregation API

נושא המשוב	סיכום	תגובה מ-Chrome
עיצוב מפתחות	בקשה להדרכה לגבי עיצוב מפתחות של צבירה פרטית	אין לנו מדריך ספציפי לצבירה פרטית, אבל אפשר להשתמש גם במסגרת לבדיקת העומס של שירות הצבירה וגם במדריך המתקדם לניהול מפתחות.
תקציב התרומה	ברמה הזו מחושב ומוגבל תקציב התרומות?	התקציב לתרומה הוא 2^16 בחלון זמן מצטבר של 10 דקות ו-2^20 בחלון זמן מצטבר של 24 שעות.

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

הפחתת סוכני משתמשים/רמזים ללקוחות על סוכני משתמשים

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

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

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

הקלה במעקב אחר עזיבה מהדף הראשון

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

מכסת פרטיות

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

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

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

נושא המשוב	סיכום	תגובת Chrome
(דיווח גם ברבעונים קודמים) מגבלת הדומיינים של קבוצת האתרים הקשורים (RWS)	בקשה להגדלת המגבלה של דומיינים משויכים ב-RWS	התשובה שלנו דומה לתשובות שנתתנו ברבעונים קודמים: בשלב הזה, אנחנו לא מתכוונים להגדיל את המגבלה המספרית. המגבלה נקבעה על סמך שיקולים שנוגעים לפרטיות המשתמשים, משוב מבעלי עניין בסביבה העסקית ב-W3C והתחשבות בהטמעות דומות בדפדפנים אחרים. מידע נוסף זמין בפוסט בבלוג שלנו (1, 2). מומלץ לבדוק תרחישים לדוגמה שבהם נדרשת גישה לקובצי cookie בכמה אתרים מעבר למגבלה המספרית, ולשקול להיעזר בהנחיות שלנו לגבי תרחישים לדוגמה לזיהוי, הטמעות מאומתות ותרחישים לדוגמה לפרסום. אם סשני המשתמשים קשורים לפעולות התחברות, מומלץ להשתמש ב-API של ניהול מאוחד של פרטי כניסה (FedCM) כדי לשמור על הפונקציונליות. כאן אפשר לשלוח משוב על תרחישי שימוש אחרים שעשויים להידרש.
טיפול בקובצי cookie בין אתרים	קובצי cookie מאתרים שונים שהוגדרו על ידי תת-דומיין לא מועברים בבקשות הבאות מהדומיין הראשי. הבעיה נמשכת גם עם הגדרות CORS והרשאות מתאימות.	כאן מפורטות הנחיות לגבי שימוש נכון ב-requestStorageAccessFor API, שבו צריך לציין את המקור המלא (כלומר לכלול תתי-דומיינים) כדי שקובצי cookie מאתרים שונים יישלחו בבקשות אחזור עתידיות.
אפשרויות בחירה למשתמשים	בקשה למידע נוסף לגבי requestStorageAccessFor ש-RWS משתמש בו אחרי ההשקה של האפשרות של משתמשים לבחור, ובמיוחד איך תנועת המשתמש המשתמעת או המפורשת, שמאפשרת כרגע גישה ל-3PC, תפעל במערכת החדשה.	אנחנו מצפים שההתנהגות של RWS בכל אחד מהמצבים שבהם המשתמשים יכולים לבחור (כלומר, ללא קשר לכך שהמשתמשים בחרו לשמור או להגביל את קובצי ה-3PC שלהם) תהיה עקבית עם ההתנהגות הקיימת/השליחה ב-Chrome, כאשר קובצי ה-3PC מותרים לעומת קובצי ה-3PC שחוסמים כש-RWS מופעל (ההגדרה 'אישור לאתרים קשורים לראות את הפעילות שלך בקבוצה'). מומלץ להפעיל קודם את hasStorageAccess כדי לבדוק אם לקוד המוטמע כבר יש גישה לקובצי cookie באתרים שונים שלא חולקו למחיצות, לפני שמפעילים את requestStorageAccess. השיטה hasStorageAccess תחזיר את הערך true אם המשתמש בחר לאפשר 3PC. בשלב הזה, השיטה requestStorageAccessFor לא דורשת מחווה של המשתמש אם 3PC מותרים. פתחנו בקשה חדשה בנושא ב-GitHub כדי לדון ולציין מה צריכה להיות ההתנהגות הנכונה במקרה הזה. נשמח לקבל משוב נוסף מהסביבה העסקית.
שימוש ב-API	חששות לגבי חוסר בהירות לגבי שימוש ב-RWS למטרות "מסחריות", ומצב זה מונע את השימוש בהם. בעלי העניין הביעו עניין בקיבוץ של אתר החדשות לצורך פרסום מותאם אישית.	השימוש המיועד ב-RWS הוא לתמוך בפונקציונליות העיקרית של האתר ובתהליכים העיקריים שעוברים המשתמשים. מומלץ להשתמש בממשקי ה-API שלנו לפרסום, שנוצרו במיוחד לתרחישים לדוגמה שקשורים לפרסום מותאם אישית.
שימוש ב-API	דיווח על בעיה ב-requestStorageAccess שבה ניתן להגדיר נתוני localStorage אבל לא קובצי cookie.	הבעיה נגרמה בגלל שגיאת הקלדה במאפיין SameSite. מוודאים שהאיות נכון ומגדירים אותו במפורש כ-None (ללא) ל-3PC.
מפרט API	אי-התאמות בסכימות ה-JSON במאגר, כמו מיקום שגוי של השדה contact והצעות לשיפורים, כולל שימוש במילות המפתח oneOf כדי להבטיח עקביות.	אנחנו בודקים את המשוב הזה ונשתדל לבצע את השיפורים האלה בסכימה בעתיד הקרוב. נשמח לקבל משוב נוסף כאן.
גישה של צד שלישי (3P) ל-RWS	עם הסכמת המשתמש, לאפשר לכלי להציג את הדומיינים של הצד השלישי שיהיו להם גם גישה כזו לנתוני RWS API.	מתן אפשרות לצדדים שלישיים לשלב נתונים משלהם ללא חלוקה למחיצות עם נתוני האתר של RWS יפגע באמצעי ההגנה של ארגז החול לפרטיות מפני מעקב באתרים שונים. עם זאת, אנחנו שוקלים את האפשרות לאפשר לצדדים שלישיים לשמור נתונים שמחולקים למחיצות ב-RWS, ומבקשים מכם לשלוח משוב על העיצוב של פתרון כזה כאן.

Fenced Frames API

הנושא של המשוב	סיכום	תגובה מ-Chrome
API Question	חששות לגבי האופן שבו מסגרות מוגנות ללא גישה לרשת עלולות לפגוע בבטיחות המותג ובהגנה מפני הונאות של מפרסמים.	אנחנו עוקבים אחרי הבעיה הזו בהקשר של התוכנית שלנו לאכיפת Fenced Frames. בקרוב נתחיל לבדוק פתרונות שתואמים לאכיפה של פריימים מגודרים, וכשיהיה לנו הצעה רלוונטית מספיק, נשתף אותה.
שאלה על API	האם עדיין מתוכננת השקת Fenced Frames API בשנת 2026?	כפי שצוין בהודעה הציבורית שלנו, השימוש בפריימים מגודר יהיה נדרש לא לפני 2026.
באג ב-API	כש-reportEvent() שולח בהצלחה נתוני קליקים מסגרת משנה שמקורה במקור אחר, setReportEventDataForAutomaticBeacons() לא מחליף את הנתונים של המסגרת העליונה.	אנחנו מדברים על הבעיה הזו ונשמח לקבל משוב נוסף כאן.

Shared Storage API

נושא המשוב	סיכום	תגובת Chrome
פרסום אפליקציות	אין מקבילה ל-Shared Storage API בארגז החול לפרטיות ב-Android.	אנחנו בודקים פתרונות ל-Android על סמך הצרכים של תרחישי לדוגמה והמגבלות של הפלטפורמה. בשלב הזה אנחנו לא מתכננים לשתף, אבל נשמח לקבל משוב נוסף מהסביבה העסקית בנושא הזה.
שימוש ב-API	בלבול לגבי הצורך ב-worklet נוסף של JavaScript להטמעה של Shared Storage API.	אנחנו בודקים את המשוב הזה ובוחנים אפשרות לעדכן את המסמכי התיעוד שלנו כדי להסביר את הצורך בסקריפטים נוספים של רכיבי עבודה ל-Share Storage API.
חוסר אמינות	יכול להיות ש-Shared Storage API ישתנה באופן משמעותי או יוסר בגלל הביקורות על הפרטיות, ולכן הוא לא בסיס מהימן לבנייה.	אין לנו תוכניות לשינוי משמעותי בתשתית של האחסון המשותף או להוצאתה משימוש. השינויים העיקריים שפורסמו הם בשער הפלט של כתובת ה-URL שנבחרה, שבו יידרשו מסגרות מגודר ודיווח ברמת האירוע יווצא משימוש. עם זאת, השינויים האלה לא ייכנסו לתוקף לפחות בשנת 2026.

CHIPS

נושא המשוב	סיכום	תגובת Chrome
קובצי Cookie עם חלוקה למחיצות	בניגוד ל-Firefox, ב-Chrome לא מבדילים בין מפתחות מחיצות על סמך ישויות אב של מסגרות, וכתוצאה מכך יש חוסר עקביות.	Chrome אימץ את 'ביט שרשרת האב' כדי לפתור את בעיית האבטחה ואת אי-ההתאמה בהתנהגות של Firefox. פרטים נוספים זמינים כאן.
קובצי Cookie עם חלוקה למחיצות	מסגרות iframe מוטמעות עם רמות גישה שונות לאחסון משתפות את אותו קובץ cookie שפוצל, וגורמות לחוסר עקביות במצבי האימות.	בהגדרה הספציפית הזו, מומלץ להשתמש בקובצי cookie ללא חלוקה למחיצות עם קריאה ל-Storage Access API. פרטים נוספים מופיעים כאן.
קובצי Cookie עם חלוקה למחיצות	האם קובצי cookie עם חלוקה למחיצות יימחקו כש-3PC יושבת? יש דרך לבדוק את ההתנהגות הזו?	אין לנו תוכניות לשיתוף בשלב הזה. עם זאת, מפתחים יכולים לבדוק את הפונקציונליות הזו על ידי מחיקה ידנית של קובצי cookie מחולקים דרך החלונית Application (אפליקציה) > Cookies (קובצי cookie) בכלי הפיתוח ל-Chrome.

FedCM

הנושא של המשוב	סיכום	תגובה מ-Chrome
היקף הרישום של ספק הזהויות (IdP) ובוחר הארגון	שאלה לגבי הרחבת הרישום של ה-IdP מהמדיניות הנוכחית של מקור זהה למדיניות של אותו אתר. השינוי הזה יאפשר ניהול זהויות רחב ומותאם יותר, למשל, לאפשר לדף הפתיחה של אוניברסיטה לרשום כמה ספקי זהויות שמבוססים על תת-דומיינים, בלי צורך ברישומים נפרדים ספציפיים למקור. משוב על שיפור היכולת לנפות באגים, טיפול בלקוחות שאושרו לבחירת רשת ברקע, הבהרת ההתנהגות של קובצי cookie, מתן אפשרות להתאמה אישית של הטקסט בחלון הקופץ וטיפול בבעיות של זמן קצוב לתפוגה.	אנחנו מקבלים את המשוב הזה ומשקלים איך אפשר לשלב בורר ארגונים ב-FedCM. אנחנו מזמינים אתכם לשלוח לנו משוב נוסף מהסביבה העסקית כאן, כדי שנוכל להמשיך לשפר את הגישה הזו.
קובצי cookie של IdP	דיון על ההשפעה של הטמעת קובצי cookie לטווח קצר כחלק מהצעה לשימוש בפרטי כניסה לסשן לפי מכשיר (DBSC). יש חששות לגבי חוויית המשתמש ב-FedCM, שבו קובצי cookie של IdP שפג תוקפם דורשים חלון דו-שיח גלוי למשתמש לצורך חידוש.	ה-DBSC המוצע אמור לאפשר חידוש של קובצי cookie ללא אינטראקציה של משתמשים, כדי להבטיח חוויית משתמש רציפה. הרחבנו על הנושא הזה כאן.
מפרט API	שאלה לגבי מידת ההתאמה של השימוש ב-"NetworkError" במפרט FedCM API כאשר גודל המערך "providers" לא שווה ל-1.	אנחנו מסכימים ש-"TypeError" מתאים יותר למצב הזה, כי הוא משקף שגיאת תכנות ולא בעיה ברשת. אנחנו נשקול את השינוי הזה ונבדוק את האפשרות להסיר את ההגבלה הזו בעדכונים עתידיים כשנתקדם לתמיכה ב-IdP. נשמח לקבל משוב נוסף כאן.

מאבק בספאם ובהונאות

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

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