דף זה תורגם על ידי Cloud Translation API.

דוח משוב – רבעון 3 לשנת 2023
קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

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

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

CHIPS: קובצי Cookie עם חלוקה עצמאית למחיצות
DSP: פלטפורמה בצד הביקוש
FedCM: Federated Credential Management
FPS: קבוצות מאינטראקציה ישירה (First-Party Sets)
IAB: הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)
IDP: ספק זהויות
IETF: ארגון תקינה בנושאי האינטרנט (IETF)
קניין רוחני (IP): כתובת פרוטוקול אינטרנט
openRTB: בידינג בזמן אמת
הארכה: גרסת מקור לניסיון
PatCG: קבוצת הקהילה של טכנולוגיית פרסום פרטית
RP: צד נסמך
SSP: פלטפורמה לספקים
TEE: סביבת מחשוב אמינה
UA: מחרוזת של סוכן משתמש
UA-CH: רמזים על הלקוח (Client Hints) לגבי סוכן משתמש
W3C: World Wide Web Consortium
WIPB: עיוורון מכוון של כתובות IP

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

נושא המשוב	סיכום	תגובה מ-Chrome
מוכנות המערכת האקולוגית	בעלי פלטפורמות ה-SSP העלו חשש לגבי בעלי התוכן הדיגיטלי שלא מוכנים ולא מבצעים את עבודת הפריסה הנדרשת.	אנחנו מפעילים תוכנית פעילות ענפה בנושא ארגז החול לפרטיות שמתמקדת במיוחד בהדרכה של בעלי תוכן דיגיטלי. הפעילות הזו כוללת ועידות וובינר ייעודיות ופגישות עם בעלי תוכן דיגיטלי ו-SSP כדי לעודד את תהליך הפריסה.
הוצאה משימוש של קובצי cookie של צד שלישי	החששות לגבי ההוצאה משימוש של קובצי Cookie של צד שלישי (3PCD) גוברים ברבעון הרביעי של 2023 עקב הפסקה זמנית של שירותי טכנולוגיה בתעשייה.	דנו בלוחות הזמנים של ארגז החול לפרטיות עם CMA, והסדר הזמנים צפוי להוביל לנכונות לשימוש במחצית השנייה של 2024. ארגז החול לפרטיות יפרסם מידע מפורט יותר על תזמון ההגדלה של 3PCD. במסגרת ההתחייבויות, 3PCD כפופה לטיפול בבעיות התחרות של CMA.
Google Ad Manager	מערכת Google Ad Manager מסרבת לחשוף את ממשק ה-API, ולכן קשה לבצע בדיקות.	תגובה שסופקה על ידי Google Ad Manager: מהסיבות שמפורטות בתשובה הזו של Google Ad Manager, התוכניות של Google Ad Manager לשילוב Protected Audience API לא כוללות תמיכה בשרת המודעות של Google לבעלי תוכן דיגיטלי ללא שליטה במכרז ברמה העליונה.
Google Ad Manager	ל-Google Ad Manager יש מחיר רצפה סודי שחשוף רק ל-AdX או ל-SSP של Open Bidding.	במסמכי העזרה הציבוריים של Google Ad Manager מצוין שהמודעה הזוכה במכרז לפי הקשר מועברת למערכת הלוגיקה של הניקוד ברמה העליונה, ולא למכרז רכישת רכיב כלשהו, כולל AdX או בידינג פתוח. בנוסף, במסמך הזה מוסבר על הלוגיקה של הניקוד ברמה העליונה: "מערכת Ad Manager תבדוק את הצעת המחיר הזוכה בכל מכרז של רכיב, כולל המכרז של רכיב Ad Manager עצמו להצעות מחיר של קבוצות תחומי עניין של הקונים, וגם את המודעה הטובה ביותר לפי הקשר (שנבחרת באמצעות הקצאה דינמית), ותציג את המודעה עם הצעת המחיר הגבוהה ביותר."
Google Ad Manager	מוצרי Google Ads צריכים להיות כפופים לאותם כללים שמוגדרים למוצרי מודעות של צדדים שלישיים.	מוצרי Google Ads כבר כפופים לאותם כללים כמו צדדים שלישיים.
בדיקה שמתבצעת באמצעות Chrome	מוסיפים תוויות לדפדפנים שלא נכללים בקבוצה A או בקבוצה B.	אנחנו לא שוקלים לעשות זאת בשלב הזה, כי לפי החקירה שלנו, הוספת תוויות שלא קשורות לניסוי עלולה לעורר חששות לגבי פרטיות בקשר לתנועה במצב פרטי.
סוכנות פרסום	האם סוכנויות או חברות ללא JavaScript באתרים יכולות להשתמש בממשקי API של ארגז החול לפרטיות?	כל אחד יכול להפעיל את ממשקי ה-API של ארגז החול לפרטיות. אם סוכנות או כל גורם אחר רוצה לפתח טכנולוגיות ישירות בממשקי ה-API, הוא יכול לעשות זאת. ממשקי API בצד הלקוח דורשים שילוב עם הלקוח, בדיוק כמו קובצי cookie. לממשקי API רבים, כמו קובצי cookie, יש גם ממשק של כותרת HTTP. כבר ראינו מסגרת אחת של ענף הפרסום, Prebid, שמפתחת שילובים של ממשקי ה-API בצד הלקוח. ארגונים אחרים יכולים לעשות את אותו הדבר.
פתרונות בצד הלקוח	למה Google משתמשת בפתרונות בצד הלקוח לארגז החול לפרטיות, אם מהנדס הביע בעבר חשש לגבי יכולת ההתאמה של פתרונות כאלה בשנת 2012?	טכנולוגיות לשיפור הפרטיות (PET) כתחום מחקר התפתחו באופן משמעותי מאז 2012, וכך גם אפליקציות שאפשר להשתמש בהן באופן מסחרי. הליבה של ארגז החול לפרטיות היא שילובים של אמצעי PET שלא היו אפשריים לפני יותר מעשור. בנוסף, עוצמת המחשוב האישי גדלה, וכך גם הציפיות של הצרכנים מהדפדפנים והציפיות של הרגולטורים בנושא פרטיות.
למידת מכונה	מהו השימוש המתוכנן של Google בארגז החול לפרטיות למטרות של למידת מכונה?	רוב הסביבה העסקית של טכנולוגיות הפרסום משתמשת היום בלמידת מכונה, ולא צפוי שינוי בנושא הזה. 'ארגז החול לפרטיות' לא מונע מחברות טכנולוגיית פרסום או מכל גורם אחר להמשיך להשתמש בלמידת מכונה. בנוסף, ארגז החול לפרטיות לא מחייב חברות שמשתמשות בממשקי ה-API שלו להשתמש בלמידת מכונה. סביר להניח שחברות ימשיכו לפתח מוצרים ושירותים שיענו על הצרכים של הלקוחות שלהן, בין אם הם כוללים למידת מכונה ובין אם לא. כמובן שכל מודל למידת מכונה שיוצרים המפתחים של ארגז החול לפרטיות יהיה ידוע להם, ולכן לא יהיה מוסתר מהם.
אימות נתונים	איך חברות יכולות לוודא שהנתונים שהן מקבלות משימוש בארגז החול לפרטיות מדויקים, והאם Google מוכנה לעבור בדיקה על ידי ישות כמו Media Ratings Council‏ (MRC)?	ממשקי ה-API של ארגז החול לפרטיות נוצרו בפלטפורמת הקוד הפתוח שמפעילה את Chrome. גם החלקים של ממשקי ה-API שנועדו לפעול בסביבות הפעלה מהימנות הם בקוד פתוח וניתן לבצע בהם ביקורת. כל מי שרוצה יכול לבדוק את הקוד, כולל MRC.
(דווח גם ברבעונים קודמים) תמיכה בסביבת הייצור	מהו התהליך ב-Chrome לתמיכה בבעיות טכניות בארגז החול לפרטיות ובהעברת בקשות לטיפול ברמה גבוהה יותר שמשפיעות על הסביבה העסקית?	Google מספקת מגוון ערוצים שמאפשרים לטכנאי הפרסום לדווח על בעיות טכניות ולבצע העברה לטיפול ברמה גבוהה יותר, אם יש צורך, כדי לפתור את הבעיות האלה. בנוסף, הצוות של Chrome מתכנן להמשיך לפתח ולשפר את התהליך לפתרון בעיות טכניות והעברת בקשות לטיפול ברמה גבוהה יותר שמשפיעות על בריאות הסביבה העסקית. אנחנו ב-Chrome מחויבים להקצות משאבים למאמץ הזה. בפורומים הציבוריים והפרטיים שלנו תוכלו לשלוח משוב ולבצע העברה לטיפול ברמה גבוהה יותר.
מצבי בדיקה שמתבצעים באמצעות Chrome	מידע נוסף על לוחות הזמנים וההטמעות המדויקות של מצבי הבדיקה ב-Chrome.	פרסמנו פוסט בבלוג על מצבי הבדיקה, ואנחנו פועלים כדי לשתף מידע נוסף בקרוב. אנחנו מקבלים הצעות לגבי הגודל של תוויות מצב הבדיקה.
שילוב עם סטנדרטים אחרים בתחום	האם ממשקי ה-API של ארגז החול לפרטיות יתחברו ל-TCF v2.* או ל-Consent Mode, או לשניהם?	אין לנו תוכניות לשלב את ממשקי ה-API של ארגז החול לפרטיות ישירות עם TCF גרסה 2 או עם סטטוס ההסכמה. עם זאת, חברות וקבוצות מסחר בתעשייה מוזמנות להתאים את המוצרים והמסגרות שלהן כך שיפעלו בשילוב עם ממשקי ה-API של ארגז החול לפרטיות. לדוגמה, במסגרות כמו TCF, כל משתתף צריך לקבוע את הגישה שלו לתאימות על סמך האות של TCF שהוא מקבל ועל סמך כללי המדיניות המשויכים של TCF. אנחנו מצפים שהחברות יבחרו מתי ואיך להשתמש בפונקציות השונות שאנחנו מציעים באמצעות אבני הבניין של ארגז החול לפרטיות.

הרשמה ואימות

נושא המשוב	סיכום	תגובה מ-Chrome
הגבלה	תהליך ההרשמה מאפשר ל-Google להחליט איזו חברה בסביבה העסקית תהיה מורשית להשתמש בממשקי ה-API של ארגז החול לפרטיות.	תהליך ההרשמה והאימות כולל בעיקר אימות של הישות (לדוגמה, לישות יש מספר DUNS, היא יכולה לספק קישור למדיניות פרטיות וכו'), והוא הופך את האימות הציבורי לדרישה לקריאה לממשקי ה-API. ישויות שיעמדו בדרישות ההרשמה יאושרו. לעסקים שאין להם מספר DUNS, אנחנו מספקים תהליך מזורז ללא עלות לקבלת מספר DUNS מ-Dun & Bradstreet. המטרה היא לשפר את ההגנה על הפרטיות של ממשקי ה-API (באמצעות האמצעים שצוינו למעלה) וגם להוסיף שכבת שקיפות לממשקי ה-API של ארגז החול לפרטיות, כדי שגורמים מעורבים יוכלו להבין טוב יותר מי משתמש באיזה ממשק API ואילו אימותים הם מבצעים. אנחנו פתוחים למשוב נוסף מהתחום בנושא הזה, שכבר שימש אותנו לעיצוב התהליך.
תקורה של הרשמה מחדש	התוקף של קובץ האימות פג בכל 12 חודשים, והאתרים צריכים להירשם מחדש.	קיבלנו משוב מהסביבה העסקית ושיפרנו את הגישה שלנו בהתאם. כלומר, תוקף הקבצים לא יפוג יותר אחרי 12 חודשים או כל תקופה מוגדרת אחרת. אנחנו מעדכנים את המדריך למפתחים בנושא הרשמה עם הקשר נוסף.
קובץ אימות	איך משתמשים בקובץ האימות?	כל החברות שמבצעות קריאות ל-API למדידת הרלוונטיות ול-API למדידת ביצועים יידרשו להעלות את קובץ האימות לאתר שלהן עד למועד האחרון לאכיפה, ולשמור אותו גלוי לכולם כל עוד אתם מתכוונים להמשיך לבצע קריאות ל-API. אתרים יכולים לצפות לקבל בקשה אחת בערך לשעה מ-Privacy Sandbox, ויש גם ישויות פוטנציאליות אחרות שעשויות לשלוח שאילתות. הפעולה הזו תתבצע באמצעות המנגנון של מערכת ההרשמה כדי לשלוח שאילתה לשרתים של הישויות הרשמות ולוודא שקובץ האימות תקף. אישורי התאימות ייכללו בדוחות השקיפות ויוצגו לציבור הרחב. אנחנו מצפים שהחברות יפעלו בהתאם לאישורים שהן הצהירו עליהם, וכך גם שאר הגורמים בסביבה העסקית והגופים הרגולטוריים הרלוונטיים.
צירוף	האם ההרשמה מתבצעת לכל אתר או לכל מקור?	ההרשמה מתבצעת ברמת האתר.

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

נושאים

נושא המשוב	סיכום	תגובה מ-Chrome
ביצועים	חששות לגבי הביצועים בנוגע להשפעה של שיעור ההסכמה לשימוש בתכונה 'נושאים' באזור הכלכלי האירופי.	אנחנו ממליצים לגורמים הרלוונטיים לפנות לרשות הרלוונטית להגנה על מידע בנושא הזה. הם יכולים לטפל בבעיות כאלה ולהשפיע על האופן שבו יחולו חוקים על יישומים של טכנולוגיות לשיפור הפרטיות, או אם ייחשבו למעקב ויחולו עליהם אותם הקריטריונים לקבלת הסכמה. כתוצאה מכך, יכול להיות שממשקי API כמו אלה של ארגז החול לפרטיות לא יהיו זמינים בתדירות גבוהה.
צירוף	האם בידינג במורד הזרם מחייב הרשמה ל-Topics API כדי להשתמש באותות של Topics מ-SSP בחלק העליון של הזרם?	אין צורך לרשום את המקלטים במורד הזרם של נושאים מעבר למבצע הקריאה הראשוני ל-Topics API, אבל סביר להניח שרבים מהם רשומים לשימוש ב-API אחר. רשימה של המשתתפים בתוכנית ארגז החול לפרטיות תסופק באופן פרוגרמטי כחלק מהמאמצים של התוכנית לשקיפות. הרשימה הזו תאפשר למתקשרים המעוניינים ב-Topics API לבדוק אם הנמען שאליו הם שולחים נושא רשום בתוכנית.
סינון נושאים	לבקש להחיל סינון של מבצע קריאה אחר על הנושאים שהוא מאחזר בדף, כדי לשתף רק את מה שהקונים זכאים לאחזר.	אנחנו בוחנים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
החרגת אתרים	החרגת אתרים כך שלא ישפיעו על הנושאים של משתמשים.	נושאים לא נקראים כברירת מחדל. חשוב לציין שתוכן הדפים לא נלקח בחשבון בבחירת הנושאים, וכל הנושאים נבחרים בקפידה כדי לוודא שהם לא רגישים. בנוסף, בעלי אתר יכולים למנוע את הכללת האתר שלהם בחישוב הנושאים באמצעות הכותרת הבאה של מדיניות ההרשאות: `Permissions-Policy: browsing-topics=()`
תצפית על נושאים	לאפשר לבעלי אתרים לתת הרשאות ל-Chrome כדי לסווג נושאים על סמך תוכן הדף (לדוגמה, כותרת או גוף).	בעבר הצענו תכונה לסיווג אתרים לנושאים על סמך תוכן הדף, והחלטנו לא להמשיך בהצעה בגלל חששות לגבי פרטיות ואבטחה. ההצעה הזו עשויה לצמצם חלק מהחששות האלה, אבל לא ברור עד כמה. לאור תקופת הניסוי הקרובה של CMA, אנחנו לא צופים שהשינוי הזה יתבצע לפני 3PCD. נשמח לקבל משוב נוסף כאן.
תצפית על נושאים	לספק למוציאים לאור כללי מדיניות הרשאה מפורטים יותר.	אם נציע לבעלי תוכן דיגיטלי מדיניות הרשאות מפורטת יותר, הם יוכלו להשפיע לרעה על התועלת של Topics API לסביבה העסקית כולה, בלי להשפיע לרעה על התועלת של Topics API באתר עצמו. לסקירה מפורטת יותר בנושא, אפשר לעיין בבעיה ב-GitHub‏ Update permissions policy to support separate permissions for retrieve and observe.
נושאים רפואיים ובריאותיים	למה הטקסונומיה של Topics לא כוללת נושאים בקטגוריות 'רפואה' או 'בריאות'?	קטגוריות של רפואה ובריאות נחשבות לנושאים רגישים, ולכן הן לא נכללות בטקסונומיה של Topics.
אחזור נושאים	דרך מהירה יותר ל-DSP לקבל נושאים בלי אחזור באמצעות כותרות.	שיטות הכותרת הן בעלות ביצועים טובים יותר ועלות נמוכה יותר מאשר יצירת iframe בין מקורות (cross-origin) וביצוע קריאה ל-`document.browsingTopics()` ממנו. (צריך להשתמש ב-iframe בין מקורות כדי לבצע את הקריאה, כי ההקשר ברמה העליונה למעקב אחרי נושא חייב להתאים להקשר שממנו ניגשים לנושאים). כאן מוסבר על כך בפירוט.
אחזור נושאים	בקשות לתמיכה בהעברת Topics דרך כותרות בבקשות של תגי סקריפט מ-origin שונה.	מבחינת אבטחה, אי אפשר לעשות זאת. כל מסמך וסביבת הביצוע שלו משויכים למקור אחד – המקור של המסמך. משאבי משנה של צד שלישי שנטענים ומופעל באותה סביבה נחשבים כמשאבים בבעלות המקור של המסמך. המטרה היא למנוע זליגת נתונים ללא הסכמה ממקור אחד למקור אחר. אפשרות אחרת היא לספק מאפיין `browsingTopics` בתגים `<script>`. הנתונים האלה צריכים להיות נקיים מבחינת אבטחה, ולא להוסיף זמן אחזור נוסף. אנחנו פתוחים ל משוב מגורמים מעורבים.
מוּדעוּת	להגביר את המודעוּת הציבורית לגבי Topics API ולשימוש שנעשה ב-API.	יצרנו קשר עם בעלי העניין ששלח את המשוב הזה, והבעיה נפתרה ב-GitHub. בעתיד נמשיך לתמוך בהבנה של הסביבה העסקית לגבי ה-API, ונשמח לשמוע את הדעות של בעלי העניין. בינתיים, אנחנו ממליצים לבעלי עניין שרוצים לקבל מידע נוסף על Topics API לעיין במסמכי התיעוד במדריך למפתחים של Chrome.
התראה	התראה למשתמש כשאתר מסוים עוקב אחרי הנושאים שלו.	טפלנו במשוב הזה ב-GitHub. מידע נוסף על אמצעי הבקרה של Topics זמין במרכז העזרה של Chrome.
למידת מכונה	איך אפשר להשתמש בלמידת מכונה כדי להסיק נושאים של משתמשים?	אנחנו דנים בבעיה הזו ונשמח לקבל משוב נוסף.
התועלת לבעלי עניין מסוגים שונים	יכול להיות שחברות פרסום דיגיטלי קטנות יותר לא יוכלו לעקוב אחרי 'נושאים' בגלל האופן שבו הדפדפנים מחשבים אותם.	רק טכנולוגיות פרסום שזיהו שהמשתמש ביקר בדף בנושא הרלוונטי באחד משלושת השבועות האחרונים יקבלו נושא. אם טכנולוגיית המודעות לא התקשרה ל-API בשלושת השבועות הקודמים עבור המשתמש הזה באתר בנושא הזה, הערך המוחזר יהיה ריק. המשמעות של התכונה הזו היא שטכנולוגיות פרסום שמספר גדול יותר של בעלי אתרים משתמשים בשירותים שלהן, ולכן יש להן יותר הזדמנויות לצפות בביקור של משתמש מסוים באתר, עשויות לקבל יותר נושאים מאשר טכנולוגיות פרסום אחרות. התכונה הזו חיונית להגנה על הפרטיות של ה-API, כי היא מגבילה את הזמינות של מידע על משתמש רק לצדדים שכבר יכולים לראות את אותו מידע בסיסי (כרגע באמצעות קובצי cookie של צד שלישי).
בקשת XHR	מתי תוצא מכלל השימוש ההכללה של Topics בבקשות `XMLHttpRequest`‏ (XHR)?	כפי שהודענו ב-Chrome באוגוסט 2023, התחלנו להוציא משימוש את התמיכה ב-XHR במהלך המעבר מגרסת Origin Trial לגרסת General Availability. במהלך ההשקה של Topics, התמיכה ב-XHR כללה רק משתמשים שהתכונות של OT הופעלו עבורם, והיא הוצאה משימוש באופן מלא כשקבוצות הניסוי הנפרדות של OT מוזגו. אם השתמשתם ב-Topics עם XHR, האתרים שלכם לא ייפגעו. הנושאים פשוט לא יתווספו לכותרות הבקשה של ה-XHR. מומלץ לעבור ל-`fetch` בבקשה, להשתמש במאפיין iframe או להשתמש ב-JavaScript API כדי לאחזר נושאים. כל הדפדפנים המודרניים תומכים ב-Fetch, אבל לא Internet Explorer או Opera Mini.
תהליך העדכון של הטקסונומיה והקלסификатор	מידע נוסף על הטקסונומיה של Topics ועל תדירות הפרסום של הסיווגים, וגם איך חברות יכולות להתכונן לעדכונים כאלה.	התשובה שלנו לא השתנתה מאז הרבעון השני: כפי שציינו בפוסט האחרון בבלוג, אנחנו מצפים שהטקסונומיה תתפתח עם הזמן, וששליטת הטקסונומיה תעבור בסופו של דבר לצד שלישי שמייצג בעלי עניין מכל רחבי התחום. שיתוף התוכנית להגדלת השימוש גם פורסם בקבוצה topics-announce.
התנהלות פוגעת	התקפה פוטנציאלית באמצעות שרשרת הפניות אוטומטיות.	אנחנו בודקים את הבעיה הזו ונשמח לקבל משוב נוסף.
סוגים של מלאי שטחי פרסום של בעלי תוכן דיגיטלי	אילו סוגים של מלאי שטחי פרסום של בעלי תוכן דיגיטלי יהיו נתמכים בבדיקות של Protected Audience ו-Topics?	אין הגבלה מהותית על סוגי מלאי שטחי הפרסום שבהם אפשר להשתמש בקהלים מוגנים או בנושאים.
זמן ההגדלה של נפח החשיפה	מומלץ לא להגדיר זמן התארגנות לקטגוריות חדשות כדי להגיע ל-100%.	בעקבות בקשת המשוב הזו מהסביבה העסקית והדיון בפגישות של PATCG, הודענו על התוכנית שלנו להשקת הטקסונומיה החדשה.

Protected Audience API (לשעבר FLEDGE)

נושא המשוב	סיכום	תגובה מ-Chrome
מכרזים ברמה העליונה	היכולת להשתמש בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי לתת ל-Google Ad Manager שליטה גם במכרז של Protected Audience API ברמה העליונה.	התשובה שקיבלנו מ-Google Ad Manager: התוכניות של Google Ad Manager ל-Protected Audience API לא כוללות תמיכה בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי שליטה במכרז של Protected Audience ברמה העליונה, מהסיבות הבאות. כדי לספק שירות תקין ללקוחות שלנו בשוק הצגת המודעות של בעלי התוכן הדיגיטלי, שרת המודעות של Google לבעלי תוכן דיגיטלי צריך לשמור על השליטה במכרז ברמת העליונה של 'קהל מוגן'. בתור שרת מודעות לבעלי תוכן דיגיטלי, התפקיד שלנו הוא לספק לבעלי התוכן תחזיות כדי שיוכלו לנהל משא ומתן על קמפיינים שנמכרו ישירות בלי להזמין יותר מדי שטחי פרסום, ולנהל את קצב ההצגה של ההזמנות הישירות בצורה אופטימלית. כדי לעשות זאת, צריך להריץ את המכרז האחרון כדי להשוות בין כל הביקוש הישיר והעקיף שעומד בדרישות. תחזיות וקצב הצגת המודעות הן פונקציות ליבה שבעלי תוכן דיגיטלי מצפים לקבל משרת מודעות. בלי תחזיות מדויקות, בעלי תוכן דיגיטלי עלולים למכור יותר מדי ממלאי שטחי הפרסום שלהם, וכך לסכן את המוניטין העסקי שלהם. חשוב גם לקבוע קצב עבודה, כי אי-עמידה בחוזים של הזמנות עם מפרסמים עלולה לפגוע ביחסים הישירים בין בעלי התוכן הדיגיטלי למפרסמים, וכתוצאה מכך להשפיע באופן משמעותי על העסק של בעלי התוכן הדיגיטלי. לסיכום, אנחנו לא מתייחסים לפעילות של שרת המודעות של בעל התוכן הדיגיטלי להפעלת המכרז של Protected Audience ברמה העליונה כפעילות נפרדת מהפעילויות האחרות של שרת המודעות של בעל התוכן הדיגיטלי.
`directFrom SellerSignals`	`directFrom SellerSignals` מאפשר ל-Google Ad Manager למנוע מהבעלים של אתר החדשות לראות את המחיר של המכרז לפי הקשר.	תגובה מ-Chrome: לא ידוע אם המידע שמוענק ל-`runAdAuction()` מגיע מהמוכר, אלא אם המוכר קורא ל-`runAdAuction()` מ-iframe משלו. במכרז עם מספר מוכרים, אי אפשר לדרוש מכל המוכרים ליצור את המסגרת שמפעילה את `runAdAuction()`. `directFromSellerSignals` פתרה את הבעיה הזו על ידי טעינת תוכן מחבילת משאבים משניים שנטענה ממקור של מוכר. כך אפשר לוודא שלא ניתן לשנות את האותנטיות והשלמות של המידע שמוענק למכרז מההגדרות של המכרזים של המוכר. אם בעלי אפליקציות רוצים להשתמש ב-Protected Audience API כדי להבין את המידע שספקי הטכנולוגיה שלהם מעבירים למכרזים של Protected Audience, הם יכולים לבקש את הפונקציונליות הזו מספקי הטכנולוגיה. התשובה של Google Ad Manager: אנחנו מתמקדים כבר שנים בשמירה על הוגנות במכרזים, כולל ההבטחה שלנו שלא נשתף עם קונה אחר מחירים ממקורות הפרסום הלא מובטחים של בעלי תוכן דיגיטלי, כולל מחירים של פריטים ברשימה שלא מובטחים, לפני שהקונה יציע מחיר במכרז. מאוחר יותר אישרנו את ההתחייבות הזו במכתב ההתחייבות שלנו לרשות התחרות הצרפתית. במכרזים עם הגנה על קהל היעד, אנחנו מתכוונים לעמוד בהבטחה שלנו על ידי שימוש ב-`directFromSellerSignals`, ולא לשתף את הצעת המחיר של כל משתתף במכרז עם משתתף אחר במכרז לפני סיום המכרז במכרזים עם מספר מוכרים. חשוב להבהיר שלא נשתף גם את המחיר של המכרז לפי הקשר עם המכרז שלנו לרכיבי מודעות, כפי שמוסבר בעדכון הבהרה נוספת לגבי הדינמיקה של המכרז ברמה העליונה.
חשיפת מידע	הדפדפן עלול לחשוף לוגיקה עסקית רגישה ופרטי חוזים.	מי שמשתמש בדפדפן אינטרנט יכול לראות את כל מה שקורה בדפדפן. כשמכרז של מודעה מתרחש בדפדפן, האדם שהדפדפן שלו זה, יכול לראות את המכרז מתרחש, כולל את סכומי הצעות המחיר שהצדדים השונים בוחרים להגיש. מאחר שדפדפן הוא הנציג של המשתמש, אנחנו לא חושבים שאפשר או שרצוי לנסות לשנות את זה. עם זאת, רק למי שמשתמש בדפדפן יש גישה לפעולות האלה. שרתים, כולל שרתים של Google, לא יכולים לראות מכרז שמתקיים במכשיר באמצעות Protected Audience API.
`PerBuyerExperiment GroupId`	טווח הערכים הנוכחי של `PerBuyerExperiment GroupId` יכול לאפשר לקונים למצוא התאמה בין נתוני ההקשר לבקשה מהשרת המהימן.	שימוש ב-Protected Audience API באופן הזה לא עומד בתנאי האימות החובה של ארגז החול לפרטיות, שלפיו משתמשי ה-API לא ינסו לעקוף את אמצעי ההגנה של ארגז החול לפרטיות. בעתיד, הדרישה ששרתי מפתח/ערך יפעלו בסביבות ביצוע מהימנות (TEE) תספק הגנה טכנית מפני ההתקפה הזו.
מדיניות של מקור זהה	מרחיבים את מדיניות המקור הזהה כדי לאפשר תת-דומיינים.	אנחנו בוחנים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
ניהול גרסאות של API	בקשה לניהול גרסאות ולנתוני גרסה של שינויים ב-Protected Audience API.	אנחנו בוחנים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
מכרזים בכמה פלטפורמות SSP	מאפשרים לאותות מכרז ברמה העליונה לבצע מיזוגים של קובצי JSON עם אות הרכיב `auctionSignals`.	אנחנו בוחנים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
הגבלת הצעת מחיר	הגדלת המגבלה על מספר רכיבי המודעות שכלולים בתוך הצעת המחיר מ-20 ל-40.	אנחנו שוקלים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית לגבי הסיבה לכך.
(דיווח גם ברבעונים קודמים) הביצועים של מכרזים בשילוב עם Protected Audience API	דיווח של בודקים על זמן אחזור ארוך במכרזים עם Protected Audience API.	לגבי שאלות לגבי זמן אחזור, ב-Protected Audience API הופעלה בדרך כלל הפרדיגמה הסטנדרטית הקיימת של בניית אמצעי בקרה שמאפשרים למוכרים להחליט כמה זמן ומשאבים המגישים הצעות המחיר יכולים לנצל, ושל בניית כלים שמאפשרים לקונים להחליט איך להשתמש בצורה הטובה ביותר במשאבים שזמינים להם. אמצעי הבקרה והכלים האלה זמינים כבר היום, אבל היתרונות המלאים שלהם יתגלו רק אחרי שהקונים והמוכרים יתחילו להשתמש בהם. בנוסף, אנחנו ממשיכים לעבוד ב-Chrome על מגוון שיפורים בתשתית כדי לשפר את מהירות המכרזים (crrev.com/1190815, ‏ crrev.com/1199839, ‏ crrev.com/1201837, ‏ crrev.com/1198339, ‏ crrev.com/1197323). אנחנו מזמינים מכם משוב על שני חלקי המאמץ שלנו לקצר את זמני האחזור: כלים חדשים שיועילו לקונים ולמוכרים, ודוחות על צווארי בקבוק שאותם מהנדסי Chrome צריכים לבדוק.
סינון בצד הקונה	הוספת תמיכה בסינון בצד הקונה על סמך קבוצות תחומי עניין.	הצענו כמה דרכים שבהן ספקי SSP ו-DSP יכולים לשנות את העיצובים שלהם כדי לטפל בבעיה הזו: העברת חלק מהעבודה לשרת המפתח/הערך של ה-DSP. רשתות SSP יוצרות חלק מהאותות בהקשר ומעבירות אותם ל-DSP. פלטפורמות SSP ששומרות אותות לפי הקשר במטמון עבור פלטפורמות DSP.
בקרה על קבוצות אינטרס של בעלי תוכן דיגיטלי	תמיכה לבעלי תוכן דיגיטלי שרוצים להעניק גישה לשימוש בקבוצות עניין שנוצרו על ידם.	ניהלנו דיונים עם גורמים רבים בנוגע לבקשה. אנחנו מאמינים שאפשר לטפל עכשיו בכל התרחישים לדוגמה האלה שקשורים ל'הענקת גישה' לקבוצות העניין שנוצרו על ידי בעלי התוכן הדיגיטלי, ואנחנו צריכים לפתח תמיכה נוספת כדי שהתהליך יהיה חלק יותר בחלק מהתרחישים לדוגמה בעתיד.
(דיווח גם ברבעון השני) סביבות מחשוב מהימנות	תמיכה בסביבות מחשוב מהימנות (TEE) בסביבות ענן לא ציבוריות.	התשובה שלנו דומה לתשובות שנתתם ברבעונים קודמים: אנחנו ממשיכים לבדוק אפשרויות תמיכה מעבר לפתרונות מבוססי ענן ציבורי, אבל אין לנו תוכניות כרגע לתמוך ב-TEEs בארגון. בשלב הזה, בהתאם לדרישות האבטחה של ארגז החול לפרטיות ולאתגרים המשמעותיים שמציגות פריסות מקומיות, אנחנו מאמינים שהדרך הטובה ביותר לשפר את הסביבה העסקית היא להמשיך להרחיב ולשפר את הפריסות מבוססות-הענן (לדוגמה, תמיכה ב-Google Cloud בנוסף ל-AWS). עם זאת, נשמח לקבל משוב נוסף לגבי הסיבה לכך שהדרישה הזו נדרשת ומתאפשרת, בהתחשב במגבלות הפרטיות והאבטחה.
סביבת מחשוב אמינה (TEE)	רכיבים בנתיב השירות של TEE, כמו מאזן העומסים, יכולים לראות את כל התנועה ויש להם מידע על כתובת ה-IP של כל בקשה.	נכון לעכשיו, כתובת ה-IP מועברת כמטא-נתונים בכותרות הבקשה לשירות המודעות של המוכר הלא מהימן, גם במקרה של בידינג וגם במקרה של מכרזים של קהלים מוגנים במכשיר. מידע נוסף זמין במאמר העברת מטא-נתונים. בטווח הארוך, אנחנו מתכננים להעביר דרך שרת proxy את התנועה של טכנולוגיות הפרסום והמעקב אחרי משתמשים דרך שרת proxy של כתובת IP, כדי למנוע מהרכיבים לצפות בכל התנועה בנתיב להצגת המודעות.
אורך חיים (TTL)	האם אורך החיים (TTL) לפני שהשירותים יצטרכו לבקש מפתחות חדשים יהיה קבוע, או שהוא אמור להיות גמיש (או דינמי)?	בדרך כלל, ערך ה-TTL הוא סטטי. נכון לעכשיו, משך החיים של המפתחות הציבוריים הוא 8 ימים והרוטציה מתרחשת כל 7 ימים. משך החיים זהה גם למפתחות פרטיים במקרה של שירות האגרגציה. בשירותי בידינג ומכרזים, מפתחות פרטיים וציבוריים מאוחזרים כל N שעות בנתיב שאינו בקשה ונשמרים במטמון בזיכרון, כך שלא חל עיכוב של יותר מ-N שעות בין רוטציית המפתחות לבין קבלת המפתחות האלה על ידי השרתים. המרווח של יום אחד בין רוטציית המפתחות לתפוגת התוקף נועד להבטיח שגם אם יצירת המפתחות נכשלת, השירותים יוכלו להמשיך לפעול. אנחנו שוקלים להאריך את TTL כדי לשפר את העמידות במקרים של הפסקות זמניות בשירות. במקרה של דליפת מפתח, אנחנו מתכננים לאלץ באופן ידני יצירת מפתחות ולבטל את תוקפם מוקדם יותר. חשוב לזכור שהמפתחות הציבוריים נשמרים במטמון בלקוחות, כרגע למשך 24 שעות, כדי להבטיח שבמקרה של הפסקה זמנית בפעילות של התאום, השירותים עדיין יוכלו לפעול.
עיצוב תעבורת נתונים	תמיכה בעיצוב תעבורת הנתונים בשירותי בידינג ומכרזים.	על סמך נתונים מאינטראקציה ישירה (First-Party) של בעלי התוכן הדיגיטלי או נתונים לפי הקשר, הקונים יכולים לציין ביקוש למכרזים של קהלים מוגנים. בעלי עסקים יכולים לבצע גם הם את אותן החלטות בשרת המודעות או בשרת Ad Exchange שלהם. אפשר לאמן את המודלים על נתונים מ-1P ועל כל דוח מצטבר ממערכי מכר של Protected Audience. המוכרים יכולים להשתמש במידע הזה כדי להימנע משליחת בקשות לשרתים של הבידינג והמכרזים כשאין ביקוש למכרזים של קהלים מוגנים. אנחנו מאמינים שזו יכולה להיות דרך יעילה לעצב את התנועה.
מכרז רכיבים	אילו נתוני auctionSignals ברמה העליונה משותפים עם מוכרי רכיבים?	קונים במכרז רכיב מקבלים אותות רק מהמוכר של הרכיב. בקרוב נשתף מסמכים בנושא התהליך הכולל של מכרז משולב עם בידינג בכותרת ומכרז Protected Audience.
עיבוד וידאו	תמיכה ברינדור של סרטונים באמצעות Protected Audience ו-Fenced Frames.	Protected Audience API תומך ברינדור של סרטונים באמצעות מנגנון שמבוסס על iframes. עם זאת, עדיין לא פיתחנו פתרון שתואם לפריימים מגודר, וזו אחת הסיבות לכך שהחלטנו לדחות את האכיפה של פריימים מגודר לשנת 2026. כלומר, אם שותף יחליט לאכוף את התכונה 'פריימים מגודר' כבר עכשיו, הוא לא יקבל תמיכה בסרטונים.
מכסת תדירות	(דווחו גם ברבעונים קודמים) אמצעי בקרה על התדירות לכל משתמש בקמפיין ובקבוצת מודעות.	התשובה שלנו לא השתנתה מהדוחות הקודמים: התכונה 'קהל מוגן' תתמוך במכסת תדירות גם במכרזים במכשיר וגם בקמפיינים לפי הקשר ובקמפיינים למיתוג. אפשר גם להשתמש באחסון שיתופי ובמכסות ספציפיות לאתר כדי להגדיר אמצעי בקרה נוספים למגבלות תדירות.
העדפות מודעות	האם Protected Audience API מספק דרך לבטל את ההסכמה או להוסיף לאתר של המפרסם לרשימת החסימות, או דרך לצאת מכל קבוצות העניין של אותו בעלים?	למשתמשים יש כמה דרכים לחסום את הגישה לממשק Protected Audience API ולתכונות אחרות של ארגז החול לפרטיות.
מדיניות של מקור זהה לכתובת ה-URL של מקור הסקריפטים לבידינג ולמכרזים	הוספת גמישות לדרישה שכל השדות שציינו כתובות URL לטעינה של סקריפטים או JSON חייבים להיות מאותו מקור כמו הבעלים.	אנחנו בוחנים את הבקשה הזו כרגע ונשמח לקבל משוב נוסף מהסביבה העסקית.
`forDebuggingOnly`	קיימת אפשרות לשימוש לרעה ב-`forDebuggingOnly .reportAdAuctionWin` אם הוא יישאר אחרי 3PCD.	בשנים האחרונות קיבלנו משוב מהסביבה העסקית לגבי פערים בפונקציונליות של 'קהל מוגן' אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. אנחנו פועלים כדי לנסח תוכנית שתאפשר לנו לתמוך בקהלים האלה אחרי 3PCD בלי להתפשר על היעדים של ארגז החול לפרטיות. נשמח לקבל הצעות נוספות ומשוב על פונקציונליות חסרה שרוצים לראות בסביבה העסקית.
כמה קבוצות אינטרס	להשתמש בכמה קבוצות של תחומי עניין באותו בידינג.	האפשרות הזו לא נתמכת כרגע ב-Protected Audience API, כי היא תוביל לשינוי במודל הפרטיות הבסיסי. נשמח לקבל ממך תגובות נוספות כאן.
מכרזים במכשיר	האם תהיה תמיכה במכרזים של קהלים מוגנים במכשיר ב-Chrome ל-Android?	כן, תהיה תמיכה במכרזים במכשיר ב-Chrome ל-Android.
(דיווח ברבעון השני של שנת 2023) נתונים שקשורים לקליקים	הוספת נתונים שקשורים לקליקים ל-browserSignals.	אנחנו ממשיכים לבדוק את הבקשה הזו להוספת תכונה, ונשמח לקבל משוב נוסף לגבי הסיבות להענקת עדיפות לתכונה הזו.
ספקים של סביבות מחשוב מהימנות	האם יש הבדלים מהותיים בין המוצרים של סביבות Trusted Execution Environment (TEE) של ספקי ענן שונים?	לא ידוע לנו על הבדלים משמעותיים, אבל אנחנו ממליצים לגורמים בסביבה לקרוא את מדריכי הפריסה הציבוריים כדי לבדוק איזה פתרון מתאים להם ביותר. Google Cloud. AWS.
(דיווח ברבעונים קודמים) תמיכה בטירגוט שלילי של קבוצות אינטרס	ממשק API שתומך בטירגוט שלילי לפי קבוצות תחומי עניין: הצגת מודעות רק אם המשתמש לא שייך לקבוצת תחומי עניין.	אנחנו בודקים את האפשרות להטמיע את התכונה הזו ומדברים על הבקשה.
הפרה שקשורה לתוכן	תמיכה בתכונות שמאפשרות למשתמשים לדווח על מודעות לא תקינות שמוצגות על ידי Protected Audience API בפריימים מגודר.	אנחנו מאמינים ש מנגנון הדיווח הקיים על מודעות בפריים מגודר מספק אפשרויות טובות לטכנולוגיות פרסום שרוצות תהליך דיווח על 'מודעות לא תקינות' שנוצר על ידי משתמשים. כך נוכל לדווח על מודעות לא רצויות באופן שלא ישתנה מהותית מהסטנדרט המקובל בתחום כיום. נשמח לקבל בקשות נוספות לתכונות אם יהיו פערים, כולל במהלך הזמן שלאחר הסרת קובצי ה-cookie של צד שלישי, אבל לפני שהעיבוד של תצוגת המסגרת המגודרת יהיה נפוץ.
דיווח על Private Aggregation API	איך אנחנו יכולים לחשב את הזמן שהמשתמש בילה בקבוצת העניין הזו?	ב-Chrome מגרסה M116 ואילך, אמורה להיות אפשרות להשתמש ב'עדכניות' כפי שמוגדרת בpull/639.
שרת K-Anonymity	מידע נוסף על שרת K-Anonymity.	כאן אפשר למצוא מידע נוסף על שרתי K-Anonymity, ונשמח לקבל משוב נוסף.
כתובות URL של קריאייטיב דינמי	תמיכה בכתובות URL של נכסי קריאייטיב ללא הצהרה מראש, תוך שמירה על אנונימיות מסוג k.	אנחנו דנים בבקשה הזו להוספת תכונה, ונשמח לקבל משוב נוסף על הסיבות להעדפת התכונה הזו.
דרישת אנונימיות מסוג k	האם הדרישה לאנונימיות מסוג k תוחזר לגבי עדכונים של קבוצות של תחומי עניין?	אנחנו לא צופים שינויים בעמדה שמפורטת בפוסט הזה ב-GitHub. כפי שציינו בפוסט הזה, החלטנו להסיר את הדרישה לאנונימיות של k בעדכונים של קבוצות תחומי עניין של קהלים מוגנים. הדרישה הזו לא משפיעה באופן משמעותי על אמצעי ההגנה הכוללים על הפרטיות של ה-API, ואנחנו מתכננים לבחון אמצעי הגנה ישירים יותר (כמו פרטיות של כתובות IP או שרת עדכונים מהימן) בשלב מאוחר יותר, כשהטכנולוגיות הרלוונטיות יתפתחו, יותקנו ויאומצו.
בדיקת גרסת בטא של שירותי בידינג ומכרזים	מתי יתחיל הבדיקה של שירותי הבידינג והמכרזים בגרסת בטא?	כפי שצוין בציר הזמן ובתוכנית, השלב הראשון של בדיקת שירותי הבידינג והמכרזים יתחיל בנובמבר 2023.
חסימה	בקשה לתמיכה בתיאום קריאייטיב של רשתות פרסום (ה-SSP וה-DSP נמצאים באותה חברה או באותו נכס).	תודה על המשוב לגבי תרחיש לדוגמה הזה. אנחנו רוצים לבדוק אם טכנאי פרסום נוספים מעוניינים לקבל תמיכה באפשרות הזו. נשמח לקבל משוב נוסף.
פרסום מותאם	תמיכה במסגרת ללא שיתוף נתונים לפרסום מותאם.	אנחנו שוקלים לתמוך בתרחיש לדוגמה, ומדברים על פתרונות זמניים ופתרונות אפשריים.
K-anonymity	איך אפשר להגדיל את מספר המודעות לפי קבוצות של תחומי עניין שעומדות בערכי הסף של אנונימיזציה לפי מפתח (k-anonymization)?	שיתוף הנחיות טקטיות בנושא הזה
תמיכה ב-POST	תמיכה בשליחת נתוני מכרזים באמצעות בקשות POST.	אנחנו בודקים את הבקשה הזו להוספת תכונה, ונשמח לקבל דיווחים נוספים על בעיות ב-GitHub עם הסבר על הסיבה להענקת עדיפות לנושא.
רמת הפירוט של הדיווח	מהי רמת הפירוט של הדיווח על מודעות בפריים מגודר עם מודעות שמכילות כמה חלקים?	העיצוב הנוכחי לא מאפשר לתעד את מזהה המוצר או המיקום שלו, כי זה עלול לפגוע בפרטיות המשתמשים. אפשר להפעיל רק את האירוע `reserved.top_navigation`, שיישלח כשיש הפעלה של משתמש (למשל קליק) במסגרת המגודרת של רכיב המודעה, וכתוצאה מכך תתבצע ניווט ברמה העליונה.
מכירה פומבית של מודעות	האם פלטפורמת SSP שמשתתפת במכרז רכיבים יכולה להפעיל מכרז רכיבים נוסף בעצמה?	רכיב `componentSeller` לא יכול לכלול גם `componentAuctions`. למכרז עם כמה מוכרים יש רק שתי רמות: 1. מכרזי הרכיבים מתקיימים במקביל. 2. המכרז ברמה העליונה (שבו מתחרה המודעה הזוכה מכל `componentAuction`).
זמינות שירותי הבידינג והמכרזים	האם התכונות 'בידינג' ו'מכרז' יהיו זמינות במהלך שלב הבדיקה ב-Chrome?	שרת הבידינג והמכרזים לא יהיה זמין במהלך שלב הבדיקה בסיוע של Chrome.
אותות לבידינג	מאפשרים לדפדפנים לבקש ולמחוק אותות בידינג.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף לגבי הסיבות לכך שצריך לתת לה עדיפות.
`generateBid()`	היכולת לעדכן את `userBiddingSignals` של קבוצת העניין דרך `updateURL`.	אנחנו שוקלים את ההצעה הזו ונשמח לקבל משוב נוסף ולנהל דיון בנושא.
סוגים של מלאי שטחי פרסום של בעלי תוכן דיגיטלי	אילו סוגי מלאי שטחי פרסום של בעלי תוכן דיגיטלי יהיו נתמכים בבדיקות של קהלים מוגנים ונושאים?	אין הגבלה מהותית על סוגי מלאי שטחי הפרסום שבהם אפשר להשתמש בקהלים מוגנים או בנושאים.
שילוב שרת-אל-שרת	האם נדרש שילוב ישיר בין ה-SSP ל-DSP כדי להשתמש ב-Protected Audience?	אין צורך בשילוב ישיר בין ה-SSP ל-DSP אם ל-DSP אין צורך לעבד אותות לפי הקשר בשרת שלו כדי להעביר את המידע המעובד הזה לפונקציית הבידינג במכשיר.
שדה `bid_currency` ב-B&A	תמיכה בשדה `bid_currency` בשירות Bidding and Auction.	עדיין אין תמיכה ב-`bid_currency` ב-B&A, אבל אנחנו מתכננים להוסיף אותה עד סוף ינואר 2024. כאן אפשר לעיין בלוח הזמנים.
`perBuyerSignals`	האם יש מגבלת גודל ל-`perBuyerSignals`?	אין הגבלה על מספר האותות לכל קונה, אבל שליחת יותר מדי נתונים עשויה להשפיע לרעה על הביצועים של הדפדפן.
תרחישים לדוגמה באתרים שונים	האם אפשר להשתמש בקבוצות של תחומי עניין ב-Protected Audience API בכמה אתרים?	הקהל המוגן לא מיועד לתרחישי שימוש כאלה, כפי שמוסבר במאמר turtledove/issues/282.
בקשות HTTP של קבוצות של תחומי עניין	כוללים את Blob של קבוצת האינטרסים בכותרות ה-HTTP.	אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף לגביה.
בקרת איכות של מודעות	אובדן של בקרת איכות המודעות שקשור למידע באתרים שונים.	אנחנו מביאים בחשבון את המשוב הזה ונשמח לקבל משוב נוסף.
כלי פיתוח ל-Chrome	בקשות יוצאות לרשת של Protected Audience אמורות להופיע בכרטיסייה 'רשת' בכלים למפתחים ב-Chrome.	אנחנו עובדים על הפעלת הפונקציונליות הזו בכרטיסייה 'רשת', ונשמח לקבל משוב נוסף לגבי הסיבות להענקת עדיפות לכך.
סביבת מחשוב אמינה (TEE)	מתי יתווספו למאמר ההסבר על מעקב אחר Trusted Execution Environment פרטים על המדדים שמשפיעים על הפרטיות (והמידה שבה הם משפיעים)?	אנחנו בתהליך עדכון המידע הזה במאמר. הסבר המפורט המעודכן יהיה זמין עד נובמבר 2023.
`directFrom SellerSignals`	למה `directFrom SellerSignals` לא ארוז כחבילת אינטרנט?	כאן פירטנו את הסיבות להחלטה הזו.
הענקת גישה לחשיפות	האם יש דרך יעילה להקצות חשיפות כך שהתוצאה של בחירת קבוצת אינטרס תהיה פעולת טירגוט נוספת?	מספר מכרזים בתצוגת עץ לא תואמים ליעדים שלנו בנושא פרטיות, משתי סיבות. ראשית, כשהמודעה שזכתה במכרז מוצגת בתוך מסגרת מוקפת, יעדי הפרטיות של Protected Audience כוללים את הרינדור של הקריאייטיב שנוצר ללא ידיעת ההקשר: כתובת ה-URL של הדף שמקיף את המודעה או קובץ ה-cookie מהדומיין הנוכחי הם הפרה של הפרטיות. בסביבה הזו, מכרז בתצוגת עץ לא יעיל. שנית, לפי המודל של קהל מוגן, הזוכה בכל מכרז צריך להתבסס על נתונים מאתר נוסף אחד בלבד. מכרזים בתצוגת עץ יכולים לשפר את המצב הזה, וכך תהיה אפשרות לבחור מודעות על סמך פרופיל של כמה אתרים.
קריטריון לנתונים במנוחה	הסבר נוסף על הקריטריון 'נתונים במנוחה' במודל האמון של שירותי מפתח/ערך.	הנתונים ב-Key Value Service נטענים בזיכרון ומשם הם מוצגים, במקום להשתמש במטמון לקריאה.
אות עם נתוני הקונה	האם יש מגבלת גודל מוגדרת לאותות `buyer_data` שמתקבלים מה-DSP?	בשלב הזה אין הגבלות שהוטלו על ידי הדפדפן על אותות `buyer_data` שמתקבלים מ-DSP.

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
במכשירים שונים	כדאי לתכנן תמיכה ב-Attribution Reporting API במכשירים שונים.	בנוסף לאתגרים של 3PC, השימוש במכשירים שונים מציב אתגרים חדשים בנושא פרטיות, וגם אתגרים נוספים בנושא הפצת הטכנולוגיה, בהתאם למגוון המכשירים והפלטפורמות שבהם המשתמש עשוי להשתמש. אנחנו בודקים פתרונות פוטנציאליים, אבל אנחנו מתמקדים בתרחישי השימוש הקריטיים שנתמכים כרגע בדוחות השיוך (Attribution), ואין לנו תוכניות להציג תמיכה במכשירים שונים לפני הסרת קובצי ה-cookie של צד שלישי.
(הנתונים האלה דווחו גם ברבעונים קודמים) גודל הנתונים של הטריגר	למה גודל הנתונים של הטריגר מוגבל ל-3 ביט?	הגודל מוגבל ל-3 ביט ול-8 ערכים נפרדים, כדי לוודא שהמידע על המשתמש מאתרים שונים ומקשרים שונים מוגבל. אנחנו מזמינים את הגורמים בסביבה העסקית לשלוח משוב לגבי הצורך בפרמטרים נוספים לדיווח ברמת האירוע.
משפך המרות	דיווח על כמה דומיינים ששימשו בהמרה.	התרחיש הזה אפשרי מאז הוספת כמה יעדים. נשמח לקבל משוב נוסף.
תמיכה באותו דומיין במדינות שונות	האם דוחות השיוך פועלים עם אתרים שיש להם את אותו דומיין אבל כמה דומיינים ברמה העליונה של המדינה?	הבעיה הזו נדונה ונפתרה עם בעלי העניין שהעלו את השאלה. אם חברת טכנולוגיית פרסום צריכה להשתמש בכמה דומיינים ברמה העליונה של מדינות, היא תצטרך לבצע כמה הרשמות, אחת לכל דומיין ברמה העליונה של מדינה.
דיווח על קהלים מוגנים ושיוך (Attribution)	האם טכנאי הפרסום יכולים לגשת גם להמרות בעקבות צפייה במכרזים של קהלים מוגנים וגם להמרות לאחר קליק לצורך דיווח על שיוך (Attribution)?	כן, ארגז החול לפרטיות אמור לתמוך גם ב-VTC וגם ב-CTC במסגרת 'קהל מוגן'.
עיכובים בדוחות שאפשר לצבור	הפחתת הזמן הנדרש ליצירת דוחות עם נתונים מצטברים.	קיבלנו משוב בנושא הזה לאחרונה ושיתפנו רעיונות כאן. נשמח לקבל משוב נוסף מהסביבה העסקית.
עיכובים בדוחות שאפשר לצבור	צמצום העיכובים באמצעות תהליך בחירת שרת (Mediation).	אנחנו שוקלים את ההצעה הזו ונשמח לקבל משוב נוסף .
עיכובים בדוחות ברמת האירוע	צמצום עיכובים בדוחות ברמת האירוע.	ההצעה המלאה והגמישה לדיווח ברמת האירוע, שמתוארת בקטע הגדרות גמישות ברמת האירוע, יכולה לצמצם את עיכובי הדיווח ברמת האירוע עד לשעה אחת, בתמורה לעלייה ברמת הרעש.
מקור הדיווח לכל מקור	הגבלת המקור המקסימלי לדיווח על מקורות לכל אתר דיווח על מקורות מונעת מטכנאי פרסום לרשום מקורות ממקורות שונים לדיווח על מקור אחד של בעלי תוכן דיגיטלי.	הנושא הזה נדון עם בעלי העניין שהעלו את הבעיה, ואנחנו בודקים פתרון אפשרי של שימוש במקור דיווח אחד לכל אתר שמדווח על מקור לפני שננסה פתרונות אפשריים אחרים שכוללים הפניות אוטומטיות. אנחנו פתוחים גם למשוב נוסף לגבי הסביבה העסקית בנוגע למגבלה הזו.
דיווח על בעיות	איך אפשר לדווח על שגיאות או בעיות ב-Attribution Reporting API ב-Chrome?	נכון לעכשיו, אנחנו ממליצים לטכנאי הפרסום לדווח על שגיאות ב-Attribution Reporting API כנקודת בעיה ב-GitHub. אם הם נתקלים בבעיה שקשורה ל-Chrome, מומלץ ליצור באג ב-Chromium. בקטע יצירת אינטראקציה ושיתוף משוב מוסבר איך ומאיפה אפשר לדווח על בעיות.
ביטול כפילויות	איך אפשר לבטל כפילויות של המרות בצינורות עיבוד נתונים ובמכשירים שונים?	ביטול כפילויות במכשירים ובצינורות מדידה הוא אתגר מוכר ועדכני שפתרונות טכנולוגיות הפרסום נתקלים בו גם היום עם 3PC. באמצעות Attribution Reporting API, מומחי הפרסום יכולים להחליט מתי לרשום המרות ספציפיות ולהוסיף מטא-נתונים ספציפיים כדי לציין את צינורות המדידה שבהם השתמשו כדי לעקוב אחרי ההמרות (כלומר, חלק ממפתח הצבירה), שניתן להשוות אליהם צינורות מדידה אחרים. אנחנו פתוחים לכל משוב נוסף לגבי הסביבה העסקית בנושא הזה.
ביטול כפילויות ועדיפות	בקשה לקבלת עדיפות לפני מחיקה כפולה.	אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף.
מניעת הונאות	סיכון שמשתמש זדוני ינסה לשנות את הנתונים ברמת האירוע.	אימות הדוחות לא פועל בדיווח ברמת האירוע מהסיבות שמפורטות בקטע למה אין תמיכה בדיווח ברמת האירוע?.
סוג ההמרה	איך אפשר להבדיל בין צפייה לבין ניווט בדוחות השיוך (Attribution)?	יש לנו את אפשרות הסינון המובנית הבאה: `source_type`. כאן תוכלו לקרוא פרטים נוספים.

Aggregation Service

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

Private Aggregation API

נושא המשוב	סיכום	תגובה מ-Chrome
כתובת URL של Blob	בקשה לתמיכה בכתובות URL של Blob באחסון משותף.	תמיכה ב-Blob Url נוספה ב-Chrome M116.

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
JavaScript API	הזמינות של User Agent Client Hints JavaScript API.	אין לנו תוכניות להסיר את הפונקציונליות הזו, כי היא הפיתרון המרכזי שלנו לשותפים שרוצים לגשת באופן פעיל לנתונים עם אנטרופיה גבוהה מעבר למה שזמין כברירת מחדל ב-UA הקפוא והמצומצם.
פרטי המכשיר וגורם הצורה	היכולת של אתרים להבין קלט, פלט ומידע אחר שהמכשיר שבו מבקרים באתר יכול לתמוך בו.	הוספנו תמיכה לבקשה הזו בעקבות משוב מהסביבה העסקית.

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

נושא המשוב	סיכום	תגובה מ-Chrome
תנועה כשירה מצד שלישי	מה הכוונה ל'תנועה מתאימה של צד שלישי' במאמר ההסבר?	אנחנו מבינים את החשיבות של השאלה הזו ואנחנו פועלים כדי לזהות איזו תנועה של צד שלישי תהיה כשירה ואיזו לא. נשמח לקבל משוב בנושא הזה.
ביקורות של תעבורת רשת	תמיכה לארגונים לבדיקת תעבורת הנתונים ברשתות שלהם.	רק תנועה של צד שלישי שמוטמעת באתרים של צד ראשון תושפע, וכך אמורה להצטמצם כמות התנועה שצריך לסנן. בנוסף, אנחנו מתכננים לתת למשתמשים אפשרות להחליט אם להשתמש בהגנה על כתובת ה-IP או לא. ב-Chrome שנמצא בשליטת הארגון, יהיו כללי מדיניות ארגוניים להשבתת ההגנה על כתובת ה-IP. לבסוף, אנחנו בודקים אילו אמצעי בקרה (אם בכלל) יסופקו למפעילי הרשת כדי להשבית את ההגנה על כתובת ה-IP. נשמח לקבל משוב בנושא הזה.
בקרת גישה	הגנה על כתובת ה-IP עשויה להשפיע על שירותי אינטרנט שמשתמשים בכתובות IP לבקרת גישה.	אנחנו מבינים את החשיבות של תרחישים לדוגמה למניעת הונאות ואת ההשפעה האפשרית על תרחישים כאלה. אנחנו מבקשים משוב מהסביבה העסקית כדי שנוכל לשפר את התמיכה בתרחישים לדוגמה של מניעת הונאות, שבדרך כלל מתבססים על כתובות IP.
תקשורת בין שרתי ה-proxy בשני הקפיצות	איך מוודאים שאין מידע בין שרתים proxy.	אנחנו בתהליך תכנון האינטראקציות של שרת ה-proxy. המטרה שלנו היא לצמצם את הסיכויים לשיתוף מידע כזה באמצעות אמצעי עסקיים, תהליכיים וטכניים.
אימותים שאינם של Google	תמיכה באימותים שאינם של Google.	אנחנו מתכננים לפרסם פרטים נוספים על אימות החשבון בעתיד, אבל כבר שיתפנו כמה שיקולים ראשוניים.
סיווג של שירותי מעקב	איך ההגנה על כתובת ה-IP תגדיר מהו מכשיר מעקב והגרסאות שלו?	אנחנו מבינים את החשיבות של השאלה הזו ואנחנו פועלים כדי לזהות איזו תנועה של צד שלישי תהיה כשירה ואיזו לא. נשמח לקבל משוב בנושא הזה.
Analytics	הגנה על זכויות יוצרים עלולה להשפיע על הדיוק של שירותי ניתוח הנתונים.	אנחנו רוצים להבין טוב יותר את ההשפעה של הגנה על קניין רוחני, ונשמח לקבל מכם משוב נוסף ודוגמאות מהסביבה העסקית.
שרת Proxy	אם משתמש משתמש בשרת proxy או הגדיר שרת proxy באופן ידני, איך יפעל מסכת ה-IP במקרה כזה?	אנחנו מנסים להבין את ההשפעה של הגנה על כתובות IP על שרתים אחרים. אין לנו תוכניות לשיתוף בשלב הזה. נשמח לקבל משוב בנושא הזה.
חבילת שירות Premium	האם התכונה 'הגנה על כתובת ה-IP' תהיה בתשלום?	הגנה על כתובת ה-IP תהיה זמינה למשתמשי Chrome כחלק מחוויית השימוש הבסיסית בדפדפן. זו לא תהיה תכונה בתשלום.
שרת proxy	האם נעשה שימוש באותם שרתי proxy במהלך סשנים של משתמשים?	בחיבור HTTP/S נעשה שימוש בזוג אחד של שרת proxy, והמקור יקבל כתובת IP אחת מוסתרת. מעבר לכך, אין אילוצים נוקשים על חיבורי HTTP/S שונים שצריכים להשתמש באותם שרתים.
תמיכה בפלטפורמות	באילו פלטפורמות תהיה תמיכה בהגנה על זכויות יוצרים?	בשלב הראשון, הגנה על זכויות יוצרים תהיה זמינה ב-Chrome ל-Android ולמחשב. אנחנו ממשיכים לבדוק איך להרחיב את ההגנה לפלטפורמות אחרות.
ביטול ההסכמה	האם המשתמשים יוכלו להשבית את ההגנה על כתובת ה-IP?	אנחנו מתכננים לתת למשתמשים אפשרות לבחור אם להשתמש בהגנה על כתובת ה-IP או לא.
אנונימיזציה	אילו סוגי בקשות יהיו אנונימיות במסגרת ההגנה על כתובת ה-IP?	בקשות HTTP/S ו-DNS לדומיינים של צד שלישי שעומדים בדרישות עוברות אנונימיזציה דרך שרת ה-proxy לשמירה על הפרטיות. בהמשך נפרסם הסבר נוסף על האופן שבו נגדיר אילו דומיינים ייכללו. שאר התנועה (לדוגמה, שאר בקשות ה-DNS או תנועה אחרת מסוג HTTP/S) לא מושפעת.
הרשאות גישה לנתונים	יכול להיות שתהיה גישה לכתובות הרשת במהלך הקפיצה הראשונה ב-IP Protection.	במודל שרת ה-proxy בשני שלבים, השלב הראשון (שמנוהל על ידי Google) רואה רק את כתובת ה-IP של לקוח המקור ואת הבקשה להתחבר לשלב השני, ואילו השלב השני (שמנוהל על ידי CDN חיצוני) רואה רק קבוצה של ערכים בשלב הראשון (כתובת ה-IP של שרת ה-proxy + יציאה) ואת כתובת ה-IP של היעד. בתגובה שחוזרת מהמקור, הצעד השני יכול להעביר את התגובה לשרת ה-proxy וליציאה של הצעד הראשון שמשויכים לבקשה, בלי ללמוד שום דבר על כתובת ה-IP המקורית של הלקוח (והצעד הראשון רק מחזיר את התגובה ללקוח, בלי ללמוד שום דבר על כתובת ה-IP של היעד). כך, הצעד הראשון לומד רק את כתובת ה-IP של הלקוח ואת הצעד השני, בעוד שהצעד השני לומד רק את כתובת ה-IP של היעד.
WebView	האם התכונה 'הגנה על כתובת ה-IP' תהיה זמינה ב-Android WebView בעתיד?	בשלב הזה אין לנו תוכניות לשיתוף, אבל החזון שלנו הוא לספק את ההגנה הזו באופן נרחב ככל האפשר.

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

נושא המשוב	סיכום	תגובה מ-Chrome
מעקב אחר אינטראקציות	איך מתבצע מעקב אחר אינטראקציות של משתמשים?	ההקלות במעקב אחר עזיבה מהדף הראשון עוקבות אחרי שני סוגים של אינטראקציות של משתמשים: הפעלות של משתמשים כפי שהן מוגדרות במפרט HTML. אלו בעיקר קליקים, הקשות על מקשים, הקשות על מסך מגע וכו'. טענות נכונות (assertions) של webauth. אלה מקרים שבהם משתמש מכה על מפתח אבטחה או משתמש במפתח גישה כצורת אימות. האינטראקציות האלה משויכות לאתר ברמה העליונה בדפים שבהם הן מתרחשות. לדוגמה, אם משתמש לוחץ ב-iframe מוטמע, האינטראקציה משויכת לאתר ברמה העליונה ולא לאתר המוטמע. האינטראקציות מאוחסנות במסד נתונים שמכיל את ה-etld+1 ללא סכימה ואת מועד האינטראקציה. אינטראקציות מגינות על הדומיין המשויך מפני מחיקה של סטטוס הפחתת המעקב אחר נטישות למשך 45 יום.
פטורים ברשימת ההיתרים	האם אפשר לפטור דומיינים?	אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית.

מכסת פרטיות

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

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
גישה מרוכזת	חשש לגבי הגישה למאגר המרכזי לניהול קבוצות של אתרים קשורים.	מאגר ציבורי שקל לגשת אליו הוא רכיב מרכזי בתכנון של RWS, כי הוא מאפשר לפקח על ההגשות. בסופו של דבר, הפונקציונליות של קובצי cookie של צד שלישי ניתנת באמצעות השימוש ב-Storage Access API או ב-rSAFor API, כאשר החברות ב-RWS מספקת גישה שמוענקת באופן אוטומטי (בניגוד להנחיות ב-Storage Access API). לדעתנו, גישה כמו תהליך שליחת הבקשה ל-RWS היא דרישות מתאימה לגישה אוטומטית של קובצי cookie של צד שלישי.
שינוי השם של קובץ JSON	האם צריך לשנות את שם קובץ ה-JSON המתארח בעקבות השינוי בשם ה-API?	כן, הנחיות השליחה השתנו, והדומיין הראשי צריך להציג קובץ JSON בכתובת `/.well-known/related-website-set.json`. אין צורך לשנות קבוצות קיימות ברשימת RWS, אבל אם נשלחו שינויים לקבוצות קיימות, צריך לשנות את קובץ ה-JSON.
(דווח גם ברבעונים קודמים) מגבלת דומיינים	בקשה להרחבת מספר הדומיינים המשויכים	כפי שציינו בפוסט בבלוג ב-31 באוגוסט, העלינו את המגבלה של הדומיינים המשויכים לחמישה דומיינים בעקבות משוב מהסביבה העסקית. החלטנו להגדיל את המגבלה של הדומיינים המשויכים לחמישה דומיינים (בתוספת דומיין ראשי אחד), בהתאם להטמעה שהכי דומה לזו שמוצעת בדפדפן ראשי אחר.
קובצי Cookie של צד שלישי	האם קבוצות של אתרים קשורים יפעלו רק כשקובצי Cookie של צד שלישי מושבתים?	קבוצות של אתרים קשורים יפעלו גם אם המשתמש לא חסם קובצי cookie של צד שלישי, אבל לא תהיה השפעה ניכרת כי קובצי ה-cookie הרלוונטיים זמינים ללא צורך בקבוצות של אתרים קשורים וב-Storage Access API.
עריכות לגיטימיות	איך מאגר 'קבוצות של אתרים קשורים' מונע מאנשים שאינם הבעלים לשנות את הקבוצות?	בהתאם למדריכים לשליחת בקשות, כל אחד יכול לשלוח בקשת תיקון (PR) ב-GitHub כדי לערוך את הקובץ `first_party_sets.JSON`. עם זאת, אם הבקשה תאושר (תעמוד בבדיקות הטכניות וכו'), Google תמזג אותה באופן ידני בקבוצות לרשימת ה-FPS הקנונית פעם בשבוע (ביום שלישי בשעה 12:00 (שעון החוף המזרחי בארה"ב)). אם גורם זדוני ינסה לשנות קבוצה שאינה בבעלות שלו, זה לא אמור להיות בעיה כי הוא לא יוכל לשנות את קובצי `.well-known`, ולכן תהליכי האימות יכשלו.
פריצה לדומיין	פריצה לדומיין עלולה לחשוף נתונים של דומיינים קשורים לגורמים לא מורשים.	אי אפשר לעשות זאת, כפי שמוסבר בבעיה הזו בנושא קהלים מוגנים ב-GitHub.

Fenced Frames API

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

Shared Storage API

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

CHIPs