דוח משוב – רבעון 4, 2024

דוח רבעוני לרבעון הרביעי של שנת 2024 שמסכם את המשוב שקיבלנו מהסביבה העסקית לגבי ההצעות של ארגז החול לפרטיות ואת התגובה של 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, ‏ PA API ו-Attribution Reporting API.

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

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

ARA

Attribution Reporting API

CHIPS

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

DSP

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

FedCM

Federated Credential Management

IAB

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

IDP

ספק זהויות

IETF

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

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

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

openRTB

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

הארכה

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

PA API

Protected Audience API (לשעבר FLEDGE)

PatCG

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

RP

צד נסמך

RWS

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

SSP

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

UA

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

UA-CH

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

W3C

World Wide Web Consortium

WIPB

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
התחייבויות	קטע G בהתחייבויות חיוני ליכולת של ארגז החול לפרטיות לפעול. ללא ערובה לכך שעסק הפרסום של Google יפעל באופן בלעדי בטכנולוגיות של ארגז החול, הסיכון לירידה מתמשכת בתועלת שלהן גדל, וכך גם האפשרות של Google למכור את הטכנולוגיה. מכירת הנכס או הפחתת התועלת שלו יהיו איום קיומי על יכולת הפנייה שמבוססת על פרטיות באינטרנט הפתוח.	ההתחייבויות לא מבטיחות שהפעילות של עסק הפרסום של Google תפעל בלעדית על טכנולוגיות של ארגז החול לפרטיות. Google מתכוונת להשתמש בגישה של תיק השקעות לזיהוי כתובת, שכוללת את הטכנולוגיות של ארגז החול לפרטיות, באותו אופן שבו צדדים שלישיים יכולים להשתמש בהן. אנחנו מבינים שגישת שיטת-השקעות נפוצה בסביבת הפרסום העסקית. אנחנו עדיין מאמינים שחשוב למפתחים לקבל כלים וטכנולוגיות לשמירה על הפרטיות. אנחנו נמשיך להפוך את ממשקי ה-API של ארגז החול לפרטיות לזמינים ולהשקיע בהם כדי לשפר את הפרטיות והשימושיות שלהם.
ניהול	מודל הניהול המוצע לא כולל מנגנונים ספציפיים של אחריות בתהליכי ייעוץ פורמלי או ערעורים.	התשובה לא נכונה. גם (1) מערכת קבלת ההחלטות והפרסומים המשויכים וגם (2) תהליך הערעורים מספקים מנגנונים ספציפיים של אחריות. בנוסף, נאמן המעקב יפקח על הפעולה שלהם בפירוט.
ניהול	משוב על כך שהמודל לא מכיל הוראות ליצירה ולתחזוקה של תקן בפלטפורמות שונות.	אף מודל ממשל לא יכול לאלץ גורמים אחרים, במקרה הזה דפדפנים, לאמץ תקן. לכן לא הצענו מודל שמחייב אימוץ סטנדרטים בפלטפורמות שונות. Google תמשיך להשתתף בפורומים של תקנים שבהם שליחת הצעות ושיתוף ניסיון בהטמעת הצעות הן פעילות נפוצה בתהליך.
ניהול	מומלץ להאריך את תקופת הייעוץ לחודשיים לפחות. מודל הממשל המוצע לא מספק לסביבה העסקית מספיק זמן לנתח את ההשפעות של השינויים המוצעים.	תקופת שלושת השבועות היא לא כל תקופת המשוב לגבי שינוי נתון, כי מחזורי המשוב הקיימים (שהם ארוכים בהרבה) ימשיכו. במקום זאת, תהליך הייעוץ מציע חלון חדש ורשמי למתן משוב במסגרת התהליך הקיים לקבלת החלטות אסטרטגיות. לכן, צדדים שלישיים יוכלו להמשיך לספק משוב בפורומים שונים (כולל GitHub,‏ W3C וגופים שמוגדרים כתקנים של מודעות, כמו IAB Tech Lab) במהלך פיתוח התכונה. המבנה הזה של מחזורי המשוב מאפשר לסביבה העסקית לנתח את השינוי המוצע ולשתף את הדעות שלה לגביו, בלי עיכוב משמעותי בתהליך הפיתוח.
ניהול	בקשה לקבלת פרטים לגבי תוכניות עתידיות של ממשל.	סיכום של מודל הממשל המוצע מופיע בדוח של CMA לרבעון השני/שלישי של שנת 2024 (דפים 3-5 כאן).
בקשת חריגה	בקשה לחריגה לגישה לקובצי cookie של צד שלישי (3PC) עבור המשתמשים שהביעו הסכמה.	הסכמה לגישה לאחסון במכשיר למטרות ספציפיות של עיבוד נתונים לא מעידה על כך שהמשתמש רוצה לשנות את ההגדרה של 3PC ב-Chrome. מתן אפשרות לשינוי הגדרות 3PC של משתמש ברמת האתר עלול לגרום לניצול לרעה, ולא ניתן יהיה לבדוק ב-Chrome את כל התנהגויות האתרים שעשויות להוביל לבקשה לפטור.
ארגז החול לפרטיות	בקשה לקבלת שיעורי הסכמה לשימוש ב-Privacy Sandbox API.	אין לנו תוכניות לשתף את המידע הזה עם הסביבה העסקית. מפתחים יכולים לקרוא לממשקי ה-API שבהם פרסו קוד כבר היום כדי להעריך את הזמינות של ממשקי ה-API של ארגז החול לפרטיות.
Origin Trial	האם יש תוכנית להאריך את תקופת הניסיון במקור?	תקופת הניסיון של גרסת המקור הוארכה עד 14 באפריל 2025.
ארגז החול לפרטיות	בקשה להסבר תמציתי ולא טכני על ארגז החול לפרטיות, שמתמקד בערך העסקי שלו ומבטיח את הסכמת ההנהלה.	לאחרונה הוספנו לקטע 'מקורות מידע לעסקים' באתר privacysandbox.com כאן את המידע הזה.
מצב B	כשדפדפן נמצא ב'מצב ב', האם תיגרם מחיקה של מאגר קובצי ה-cookie הנוכחי (1PC, ‏ 3PC, אחסון מקומי) או שהוא יישאר?	מאגר קובצי ה-Cookie הנוכחי לא יימחק. 3PCs ימשיכו להיות נגישים בהקשר שלהם מאינטראקציה ישירה.
גישה מעודכנת ל-3PC ב-Chrome	האם קבצים 3PC יוסרו לחלוטין מ-Chrome בעתיד?	אנחנו מציעים גישה מעודכנת שמאפשרת למשתמשים לבחור את האפשרות המתאימה להם. כפי שמפורט כאן, במקום להוציא משימוש את קבצי ה-3PC, נשיק חוויה חדשה ב-Chrome שתאפשר לאנשים לקבל החלטה מושכלת שתחול על כל הגלישה שלהם באינטרנט, והם יוכלו לשנות את הבחירה הזו בכל שלב. אנחנו דנים בדרך החדשה הזו עם הרגולטורים, ונשוחח עם גורמים בתחום לפני ההשקה.
בדיקות ב-Chrome	בקשה להמשך הזמינות של תוויות של בדיקות בעזרת Chrome.	הצוות של ארגז החול לפרטיות מבין שחברות רוצות להמשיך להשתמש בתוויות להוצאה משימוש של קובצי cookie. התהליך להארכת הזמינות של התוויות דומה להארכת תקופת הניסיון של גרסת המקור. כחלק מהתהליך הזה, אפשר להאריך את הניסוי רק לשלוש נקודות ציון של Chrome בכל פעם. לדוגמה, הניסוי האחרון של Chrome בנושא כוונה להאריך את הניסוי (I2EE) לגבי תוויות של הוצאה משימוש של קובצי cookie הוארך לגרסאות Chrome M130 עד M132, כולל. כך תהיה תמיכה בתוויות עד לגרסה היציבה M133 שתשוחרר בתחילת פברואר. תוספים נוספים יעברו את אותו תהליך, לכן מומלץ לעקוב אחרי העדכונים בקבוצת האימייל blink-dev.

הרשמה ואימות

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

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

נושאים

נושא המשוב	סיכום	תגובה מ-Chrome
מפרטים	האם מודל הסיווג משותף בין Android (לפי שם האפליקציה) לבין Chrome (לפי שם המארח)?	לא, אלה מודלים נפרדים כי יש להם טקסונומיות שונות.
רמת הפירוט של הטקסונומיה של Topics	הנושאים כלליים מדי ולא מועילים כשמשתמשים בהם בשילוב עם מידע מאינטראקציה ישירה.	מטרת הטקסונומיה של Topics היא לשמור על איזון בין התועלת לפרטיות. בדקנו מנגנונים אפשריים להפוך את Topics לספציפיים יותר, אבל בסופו של דבר החלטנו שלא לעשות זאת, בין היתר מטעמי אבטחה ופרטיות. טכנאי הפרסום יכולים להשיג את התוצאות הטובות ביותר על ידי שילוב של כל הכלים הזמינים, כמו למידת מכונה ואותות ללא פגיעה בפרטיות מממשקי API לשמירה על הפרטיות, יחד עם נתונים לפי הקשר, נתוני קריאייטיב ונתונים מאינטראקציה ישירה (First-Party). הדרכה נוספת בנושא זמינה כאן.
שימוש ב-API	לכיסוי של Topics API יש נתח קטן.	אלה כמה מהסיבות הנפוצות לכיסוי נמוך: - אמצעי בקרה של משתמשים/ביטול ההסכמה - אמצעי בקרה של בעלי תוכן דיגיטלי/ביטול ההסכמה - האתר עומד בדרישות (האתרים הבאים לא אושרו להתאמה ל-Topics: אתרים לא מאובטחים, WebView,‏ Chrome ב-iOS ומצב פרטי) - מגבלות על משתמשים (לא ניתן לעקוב אחרי משתמשי Chrome מתחת לגיל 18 או משתמשים שמשתמשים במצב פרטי, ולא ניתן להקצות להם Topics) - דרישה למעקב אחרי מוכרים (המבצע הקריאה חייב לראות את המשתמש בעבר באתר שמשויך לנושא שעומד בדרישות) - עדכנות ההטמעה (נדרשים כ-4 שבועות כדי להגדיל את נפח המעקב אחרי מבצעי הקריאה)
שימוש ב-API	בקשה למידע על השימוש ב-Topics API, כי נראה שבכרטיסייה Networking (רשתות) יש קריאה שנשלחה ונלכדה, אבל ב-chrome://topics-internals/ לא מוצגת תצפית שתועדה.	כשמשתמשים במנגנון כותרת ה-HTTP כדי לקיים אינטראקציה עם Topics API, הנושאים נשלחים בכותרת הבקשה Sec-Browsing-Topics, אבל הם נצפים רק אם השרת משיב עם כותרת התגובה Observe-Browsing-Topics: ‎?1. פרטים נוספים מפורטים כאן.
המעורבות של Chromium	במחשב, האם Chrome ישתף עם דפדפנים אחרים המבוססים על Chromium את אותו הקשר של תצפיות ודירוגים? במכשירים ניידים, האם דפדפן Chrome ל-Android ישתף עם דפדפני Android אחרים שמבוססים על Chromium או על Chromium מובנה באפליקציה את אותו הקשר של תצפיות ודירוגים?	Chrome לא משתף את נתוני Topics עם דפדפנים אחרים במכשיר.
מפרטים	איך המערכת של Topics API קובעת אם צפייה בדף על ידי משתמש נחשבת כ 'רשומה בהיסטוריית הנושאים'?	כדי לעמוד בדרישות לחישוב הנושאים השבועיים, לביקור בדף צריכה להיות קריאה מסוג 'מעקב' (יכולה להיות מכל מבצע קריאה). בלי קריאה מסוג 'צפייה', הביקור לא ייכלל בהיסטוריית הנושאים.
אבטחה	איך Topics API מונע מגורם מבצע קריאה לקבל את הנושאים שנצפו על ידי גורמים מבצעי קריאה אחרים?	הסבר מפורט זמין כאן.
טקסונומיה	איך משתמשים בתחביר של מבנה העץ ב-Topics API בתצפית בכל תקופת זמן?	בזמן החישוב של 5 הנושאים המובילים, המערכת מביאה בחשבון רק את הנושאים המקוריים שסופקו על ידי הסיווג. הדירוגים נקבעים על סמך (1) תדירות הביקורים בדפים ו (2) ציון תעדוף (ראו מפרט). במספר האנשים שצפו בנושאים האלה נכללים גם אנשים שצפו בנושא הראשי או באחד מהנושאים המשניים שלו.
מפרטים	בקשה למידע נוסף לגבי 5% הרעש האקראי בתגובה.	תמיד יש 5 נושאים מובילים בכל תקופת זמן לקביעת נושאים. אם היסטוריית הגלישה לא מספקת 5 נושאים, המערכת בוחרת נושאים אקראיים עד שמגיעים ל-5 נושאים. אנחנו קוראים לנושאים כאלה 'נושאים מורחבים'. מבצעי הקריאה לא יקבלו אחד מהנושאים האלה עם התוספות האקראיות, אלא אם הם זיהו את המשתמש (הפעילו את ה-API) באתר עם הנושא בשבועות האחרונים. כשמתבצעת קריאה ל-API, מחושב גיבוב לכל משתמש, לכל אתר לכל תקופת זמן. אם ה-hash הזה נמוך מההסתברות להחזרת נושא עם רעש, המערכת תחזיר את הנושא האקראי לכל משתמש, לכל אתר לכל תקופת זמן לקביעת נושאים. עם זאת, הנושא עם הרעש מוחזר רק אם מבצע הקריאה החוזרת צפה בנושא התואם ללא רעש עבור המשתמש/האתר/התקופה הזו (ראו הסבר). הסינון הזה מבטיח שהנושאים שהושפעו מהרעש יופיעו ב-5% מהמקרים של מבצע הקריאה, ללא קשר ליכולת התצפית שלו.
מפרטים	איך פועלים נושאים כפולים בשבועות שונים? האם ה-API בוחר באופן עצמאי בין שבועות ואז ממזג אותם?	הנושאים של כל שבוע (תקופת זמן) מחושבים בנפרד. הנושא הספציפי שנבחר להחזרה מכל תקופת זמן לקביעת נושאים תלוי באתר שבו מבצע הקריאה נמצא. אנחנו לא מביאים בחשבון שהנושא עשוי לחזור על עצמו במהלך תקופות שונות לשיחה של מבצע קריאה מסוים (ולכן כדאי לבחור נושא אחר), אבל נשמח לקבל משוב נוסף על הבעיה הזו כאן.

Protected Audience API

נושא המשוב	סיכום	תגובה מ-Chrome
A/B Testing	הפתרון של אחסון משותף שמתואר כאן מוסיף זמן אחזור ויש לו שיעור כישלון גבוה (כלומר, חלק משמעותי מהתנועה מסתיים ללא מזהה אוכלוסייה). מזהה עם אנטרופיה נמוכה (למשל, 3 ביט) יכולים להספיק לבדיקות A/B יעילות בלי להשפיע באופן משמעותי על הפרטיות.	לדעתנו, הפתרון של אחסון משותף עדיין מהווה גישה קיימת, אבל אנחנו בוחנים את הבקשה הזו ונשמח למשוב נוסף מהסביבה העסקית אם התכונה הזו היא בעדיפות גבוהה.
דיווח	בקשה לביטים נוספים ב-reportWin(), במיוחד מאחר שהבנו שהדוחות החדשים על קליקים ועל חשיפות ב-PA API ישתמשו ב-6 עד 8 ביט, וכך יקטנו בפועל מספר הביטים הנותרים שזמינים לדוחות אחרים של PA API.	אנחנו לא שוקלים יותר להגדיל את מספר הביטים של modelingSignals מעבר ל-12 הביטים הנוכחיים, בגלל חששות לגבי פרטיות. אנחנו מזמינים את חברי הסביבה העסקית לשלוח משוב על הצעתנו להדרכה פרטית של מודלים. המטרה של ההצעה היא לתמוך בצרכים של הדרכת למידת מכונה בסביבה מאובטחת, ללא מגבלת ביטים שהוגדרה על ידי ארגז החול לפרטיות.
קבוצות אינטרס	כדאי לבקש מחזורי חיים של 90 יום לקבוצות של תחומי עניין (IG), כי 30 יום לא מספיק.	כפי שציינו בפוסט בבלוג שלנו, אנחנו מתכננים להאריך את משך החיים של ה-IG ל-90 יום, ופרסמנו הסבר כאן. אנחנו עובדים כרגע על ההטמעה, ונשתף לוח זמנים להשקה כשיהיה לנו.
קבוצות אינטרס	בקשה לעדכונים דינמיים להענקת גישה ל-IG.	אנחנו מודעים לבקשה הזו מגורמים רבים שקשורים לנושא, ואנחנו בודקים פתרון. אנחנו נשתף עדכונים ב-GitHub במהלך התהליך, ונשמח לקבל משוב נוסף מהסביבה העסקית.
במכשיר	להוכיח את הערך של הפלטפורמה לסביבה העסקית כדי להמשיך להשקיע בפתרונות API של PA במכשיר.	צוות ארגז החול לפרטיות ממשיך לפתח ממשקי API שמבוססים על טכנולוגיות לשיפור הפרטיות (PET), כולל PA API, כדי להציע למפתחים אפשרויות נוספות לשמירה על הפרטיות בדפדפן. הטכנולוגיות האלה זמינות עכשיו באופן נרחב בדפדפני Chrome (לא רק ב-1% מהמכשירים, כפי שחלק מהמפתחים הבינו בטעות). גם אם המשתמשים מפעילים מודעות צד שלישי וגם אם לא, המפתחים יכולים להחליט לשלב במוצרים שלהם פתרונות מבוססי-PET, בדיוק כמו שחברות רבות בוחרות לאמץ פתרונות אחרים מבוססי-PET מחוץ לדפדפן. מפתחים רבים כבר נהנים מהשקעה בפתרונות של ממשקי API ל-PA במכשיר, ומרחיבים את האות הגורמי של הקהל עם אינטראקציה ישירה (First-Party) כדי לשפר את פוטנציאל החשיפה באתרים שונים. אנחנו מבינים שמפתחים מסוימים יבחרו להשתמש בממשקי ה-API של ארגז החול לפרטיות או בפתרונות אחרים שמבוססים על PET רק אם יתבצעו השבתות נוספות של קבצים אלה. המפתחים האלה ממתינים למידע שיאפשר להם להעריך כמה דפדפנים ימשיכו להשתמש בקובצי cookie של צד שלישי. אנחנו מבינים שהמפתחים האלה יחכו עד שימצאו את המידע שהם מחפשים כדי לקבל החלטות לגבי המוצרים.
קבוצות אינטרס	לאפשר ל-SSPs לקחת חלק ביצירת ה-IG ובתפקידים שמשויכים אליהם. בעלי פלטפורמות ה-SSP רואים בכך חלק חשוב מהערך המוסף שלהם, והם רוצים לעזור לבעלי תוכן דיגיטלי למכור מודעות IG דרך פלטפורמות ה-SSP שלהם.	קיבלנו בקשה מתומכים מרובים לתמוך בהענקות גישה מתקדמות יותר ל-IG, ואנחנו רואים את הערך המוסף של פלטפורמות ה-SSP בתהליך הזה. אנחנו בודקים את הנושא כדי למצוא את הפתרון הטוב ביותר שיאפשר לגורמים שונים להשתתף בתהליך הרחבת הקהל. נשתף עדכונים ב-GitHub במהלך הפיתוח, ונשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח	אי-התאמות במספר הדוחות של 'בידינגים שאינם אפס' בין forDebuggingOnly לבין Private Aggregation API.	אנחנו מצפים לפערים בשני תרחישים: קודם כול, מצב ניפוי הבאגים של Private Aggregation API זמין רק כשיש 3PCs מורשים במכשיר, בעוד ש-API forDebuggingOnly תמיד זמין ללא דגימה (ההתנהגות האחרונה הזו תשתנה בסופו של דבר, כפי שמפורט כאן). שנית, ל-Private Aggregation API יש מגבלות על תרומות, ואילו ל-forDebuggingOnly אין. עם זאת, המשוב הזה מציין שיכול להיות שיש משהו אחר שגורם לפערים בלתי צפויים, ואנחנו עובדים עם גורם צד שלישי כדי לפתור את הבעיה הזו.
קליקביליות	כפי שצוין בהצעה המעודכנת לשליחת אות של 'קליקביליות', הצפיות והקליקים ירשמו על ידי החזרת כותרת תגובה חדשה של HTTP לבקשות שהופעלו על ידי המאפיין 'attributionsrc' שעומדות בדרישות. כותרת התגובה הזו תכלול רשימה של מקורות שאפשר להשתמש בהם כדי לציין אילו צדדים אחרים יכולים לכלול את הצפיות והקליקים האלה בספירה המצטברת שלהם. האם המשמעות היא שמערכת טכנולוגיית הפרסום יכולה להגדיר את המקור באופן שרירותי?	במאמר ההסבר על 'מספר הקליק' צוין שמערכת טכנולוגיית פרסום שתורמת אירוע צפייה או קליק למספרים המצטברים של הצפיות והקליקים ('מקור נתונים שנותן נתונים') עשויה לכלול פרמטר אופציונלי בכותרת התגובה שמאפשר לה לציין 'מקור אחד או יותר של בעלי IG שעבורם האירוע הזה עשוי להיכלל במספרים המחושבים של הצפיות והקליקים שיועברו להפעלות generateBid() שלהם במכרזים של קהלים מוגנים' ('מקורות כשירים'). עם זאת, הצפיות והקליקים האלה לא נכללים באופן אוטומטי בספירת הצפיות והקליקים. במקום זאת, כל ספק טכנולוגיית פרסום צריך לציין ב-IGs שלו את קבוצת 'מקורות המידע שנותנים נתונים' שמהם צריך לכלול אירועי צפייה וקליק, ורק נתונים מהמקורות האלה שנותנים נתונים תורמים למספרי הצפיות והקליקים שמוצגים בקריאות generateBid() של ספק טכנולוגיית הפרסום. כדי להשתמש במנגנון הזה, צריך להגיע להסכמה משני הצדדים. המנגנון הזה מונע מגורמים זדוניים להשפיע על מספרי הצפיות והקליקים של פלטפורמות אחרות של טכנולוגיות פרסום. המשמעות היא גם שפלטפורמת טכנולוגיית פרסום 'מספקת' שמגדירה 'מקורות כשירים' באופן שרירותי לא תשפיע על מספרי הצפיות והקליקים של המקורות הכשירים האלה, אלא אם המקורות הכשירים האלה יכללו במפורש ובכוונה את המקור המספק ב-IG שלהם.
אימון מודל פרטי	יש מקרים שבהם השימוש ב-DP-SGD (Differential Privacy – Stochastic Gradient Descent) יגרום להאטה משמעותית בתהליך האימון, כי הוא פוגע בצפיפות של הגרדיאנטים שמחושבים במהלך החזרה לאחור (backprop). האם יש שיטות שמוצעות כדי להתמודד עם הבעיה הזו או מחשבות לגבי הבעיה הזו?	אנחנו מודעים לכמה שיטות לשמירה על רמת דילול גבוהה ב-DP-SGD (למשל, השיטה הזו), ואנחנו בודקים אפשרות לתמוך בשיטות כאלה בתשתית לאימון מודלים פרטיים. נשתף עדכונים בהתאם להתפתחות המצב, ונשמח לקבל משוב נוסף כאן.
טירגוט שלילי	בקשה לקבלת עדכונים על השקת הפונקציונליות של סינון תוכן שלילי ב-IG, כפי שמתואר כאן.	כפי שציינו בתשובה שלנו כאן, אנחנו מתכננים לתמוך ב-IG שליליים בבידינג ב-PA API. נשתף לוח זמנים להשקה כשהוא יהיה זמין, ונשמח לקבל משוב נוסף כאן.
בידינג	האם אפשר לשלב כמה מודעות IG כשמגישים הצעות מחיר?	נכון לעכשיו, אי אפשר לעשות זאת באמצעות PA API. ממשק ה-API של PA מבוסס על העיצוב שבו ה-IG קשור למידע שאתר יחיד יודע על המשתמש. זהו עקרון מרכזי בדיונים עם הסביבה העסקית הרחבה. הגישה הזו מאפשרת לחברות פרסום דיגיטלי ליצור מגוון פתרונות שעוזרים למפרסמים להרחיב את הקהלים שלהם מהסוג 'מידע מהמפרסם' ברחבי האינטרנט. אנחנו מודעים לכך שהצעה של Microsoft ל-Ads Selection API כוללת עיצוב שונה שבו הקהלים מבוססים על מידע ממספר אתרים. אנחנו נמשיך לעקוב אחרי הגישה שלהם, אבל לפני שנשקול לבצע שינויים דומים ב-Chrome, נצפה לדיון נוסף בסביבה העסקית, כולל בקהילת הפרטיות.
מודעות מותאמות	חששות לגבי היכולת של PA API לתמוך באופן מספק בפורמטים השונים ובדרישות הרינדור של מודעות מותאמות, וגם לגבי היכולת של PA API לספק את הגמישות והאופטימיזציה הנדרשות לקריאייטיב כדי לבצע פרסום יעיל באמצעות מודעות מותאמות.	אנחנו חוקרים באופן פעיל את האפשרות להרחיב את התמיכה במודעות מותג, ונשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח	בקשה לשיפור העמידות של סקריפטים לדיווח שמתחרים על משאבים עם סקריפטים לבידינג, ויכול להיות שהם יאבדו אם עוברים ממסגרת המכרז שפועלת.	אנחנו מקווים לפרסם תשובה ב-GitHub בקרוב, אבל אנחנו לא צופים שהבעיות האלה ישפיעו באופן משמעותי על דיווח תקין בפועל.
החלפת מאקרו	החלפות מק"רו שהועברו בהגדרות המכרז לא פועלות עם חלק מההגדרות של צד שלישי.	הסיבה העיקרית לכך היא שלא כל התנועה שסומנה בתווית 'מצב A/B' הייתה מופעלת בתכונה הזו. לאחרונה החלטנו להפעיל את התכונה הזו (ותכונות אחרות באותה סיטואציה) בכל תנועת הגולשים שמסומנת במצב A/B. אנחנו צופים שנבצע את השינוי הזה במהלך הרבעון הראשון של 2025. נשמח לקבל משוב נוסף כאן.
מאמרי עזרה	אבקש הבהרה כי נראה שיש אי-התאמה במסמכים לגבי יחידת המדידה של ערך העדכניות באובייקט browserSignals בתוך generateBid().	ענינו על כך בפירוט נוסף כאן ועדכנו את המסמכים שלנו בהתאם. התשובה הנכונה היא שיחידת המידה היא אלפיות השנייה.
דיווח	בקשה לדיווח של צד שלישי: ספקי DSP ו-SSP מקבלים התראות על חשיפות מ-Chrome, אבל ספקים טכניים בשכבת הביניים לא מקבלים אותן כברירת מחדל.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
קבוצות אינטרס	בקשה לקבלת הנחיות לגבי החרגה דינמית של 'Buyers in interest group' כשמשתמשים בתהליכי עבודה מקבילים של מכרזים ב-IG.	כאן מפורטות הנחיות בנושא.
מודעות מותאמות	מכרזים עצמאיים של PA API לטעינת דף נתונה מונעים סינון של מודעות באותו דף.	אנחנו חוקרים דרכים נוספות לתמוך במודעות 'מותאמות אישית', כולל ווידג'טים של המלצות שנקראים 'מותאמים אישית' וכוללים כמה מודעות ביחידה אחת. אנחנו מבינים שיכול להיות שהעיצוב הנוכחי לא תומך בסינון מודעות באותו דף, ושהגנות אחרות כמו 'מסגרות מגודרות' עשויות למנוע זאת גם כן.
מודעות מותאמות	יכול להיות שיהיה צורך להתאים את התכונות הקיימות של PA API, כמו סריקה של נכסי קריאייטיב, דיווח וכו', שמסתמכות על אותות שמבוססים על כתובות URL, כדי לטפל באובייקטי JSON שמשמשים בנכסי קריאייטיב של מודעות מותאמות.	אנחנו חוקרים את הנושא של תמיכה נוספת במודעות מותאמות, ובודקים את האפשרות להתאים את PA API כדי לעזור ברינדור של מודעות מותאמות.
אימות מודעות	בטיחות המותג של צד שלישי ב-PA API מושפעת בגלל זמן האחזור והמגבלות של האחסון במטמון של perBuyerSignals, שגורמות לבעיות בתוכן דינמי.	אנחנו מבינים את הצורך של פלטפורמות ה-SSP וה-DSP לקבוע TTL אופטימלי לשמירת נתונים במטמון, שיאזן בין יעדי עיצוב התנועה לבין TTL מקסימלי לבטיחות המותג, כדי להבטיח שהנתונים שנשמרים במטמון יישארו רלוונטיים לבטיחות המותג. אנחנו בודקים את הבעיה הזו ונשתף עדכונים בהתאם להתפתחות שלה.
אימות מודעות	כדי לבצע מדידה של בטיחות המותג לאחר ביצוע הצעת המחיר, נדרש שתתבצע החלפה של המאקרו FullpageURL על ידי פלטפורמות ה-SSP.	deprecatedReplaceInURN היא ההצעה הנוכחית ל-SSPs כדי לספק את האות הזה.
אימות מודעות	חוסר סטנדרטיזציה בפורמטים של המאקרו שבהם משתמשים ספקי ה-SSP לאימות לאחר הגשת הצעת המחיר עלול לגרום לאי-עקביות ולשגיאות בעיבוד ובניתוח הנתונים.	פלטפורמות SSP ושירותי אימות מודעות צריכים לשתף פעולה ישירות כדי להגדיר הנחיות ומפרטים ברורים לשימוש במאקרו, במטרה לקדם את התקינה של פורמטים של מאקרו בפלטפורמות SSP שונות, כדי להבטיח עקביות ולמנוע שגיאות בעיבוד הנתונים ובניתוח שלהם. זו פעילות שמתאימה לארגונים כמו IAB Tech Lab, שמתמקדים בתקני פרסום.
אימות מודעות	מפרסמים ומאמתי מודעות זקוקים למנגנון שמקשר בדיקות לפני הגשת הצעת המחיר ובדיקות לאחר הגשת הצעת המחיר באותו הקשר של בעל התוכן הדיגיטלי, לצורך ניפוי באגים ופתרון בעיות.	אחת מהאפשרויות לאימות לאחר שליחת הצעת המחיר היא באמצעות אותות שמבוססים על מכרזים ועל קמפיינים, שמוטמעים בדיווח ברמת האירוע. כך ניתן יהיה לבצע צירופים עם יומני החלטות לפני בידינג. אנחנו בוחנים דפוסים אפשריים להשגת המטרה הזו, ונשתף עדכונים ככל שהתהליך יתקדם.
אימות מודעות	בקשה לבדוק פתרונות שרת של מפתח/ערך מהימן (TKV) (בבעלות DSP ובבעלות כלי אימות המודעות) לצורך בידינג מראש, ולטפל במגבלות של מסגרות מגודרות לצורך בידינג לאחר מכן.	אנחנו בודקים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית כאן כדי למצוא פתרון שיכול לתמוך בהגנה על המותג בשלב שלפני הבידינג, ולפשט את דרישות התיאום בין הצדדים.
מודעות מותאמות	בקשה לבדיקת רינדור לאחר בידינג בצד המוכר של מודעות רגילות.	אנחנו חוקרים את הנושא של תמיכה נוספת במודעות מותג, ואנחנו שוקלים להתאים תכונות קיימות כמו זו כדי לעזור ברינדור של מודעות מותג.

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

נושא המשוב	סיכום	תגובה מ-Chrome
זמן אחזור	לא בוצעו פעולות מספיקות לצמצום זמן האחזור. שירותי B&A עשויים לצמצם את הבעיה הזו בטווח הארוך, אבל Google לא התחייבה לזמינות רחבה שלהם לפני השינויים ב-3PC ב-Chrome.	ביצענו כמה שיפורים בזמן האחזור במכשיר בחודשים האחרונים. אנחנו גם מפתחים ומתאימים את היקף השירותים של B&A לפי הצורך. לאחרונה עדכנו את מדריך השיטות המומלצות בנושא זמן אחזור, שכולל מידע נוסף על דרכים לנצל את התכונות האלה. אנחנו גם ממשיכים לפתח שיפורים חדשים בזמן האחזור, חלק מהם מפורטים כאן.
(דיווח גם ברבעונים קודמים) אבטחת מכרזים	בקשה להבהרה נוספת לגבי הגישות למניעת ניסיונות לזיוף המכרז במכשיר או לצמצום שלהם (למשל, כולל אם Google מתייחסת לכך כסיכון משמעותי).	התשובה שלנו לא השתנתה מארבעי החודשים הקודמים: "מנגנוני הדיווח של מודעות PA API שומרים את המידע שמשמש להבדיל בין תנועה של בני אדם לתנועה של בוטים היום. בנוסף, אפשר להשתמש בשיטות הנוכחיות שמבוססות על דומיינים כדי לכלול או להחריג דומיינים ב-PA API. הנושא הזה מתואר בפירוט נוסף בתגובה שלנו לדוח של IAB Tech Lab בנושא ארגז החול לפרטיות."
פתרונות מקומיים	חששות לגבי האפשרות שהספקים הגדולים ביותר לא יאמץ את ארגז החול לפרטיות או את B&A בגלל חוסר התמיכה בענן פרטי, וכן בגלל תוכנית העבודה הארוכה והלא שקופה להוספת תמיכה בכך.	אנחנו מחויבים להרחיב את התשתיות שבהן פועלים שירותי ארגז החול לפרטיות. לאחרונה הודענו על תמיכה בענן Azure, וממשיכים לבדוק פתרונות אפשריים להגנה על הפרטיות והאבטחה בעננים פרטיים. מאז ההודעה שלנו באוקטובר, עשינו התקדמות במסגרת המחקר שלנו לגבי גישות אפשריות לאבטחת הפרטיות של משתמשי Chrome בסביבת Trusted Execution Environment (TEE) בארגון. אנחנו נמצאים עכשיו בשלב במחקר שבו אנחנו רוצים לאמת גישות שונות עם בעלי עניין בסביבה העסקית, ואנחנו מתכננים להתחיל לאסוף משוב ברבעון הראשון. משוב שיתקבל מהסביבה העסקית ושיתוף פעולה עם גורמים שונים בסביבה הזו יעזרו לנו לשפר את הפתרונות האפשריים.
בדיקה	האם אפשר ליצור סביבות TEE לבדיקה של פתרונות דיווח של PA API (דיווח בזמן אמת וצבירה פרטית)?	כדי לבדוק את שירות האגרגציה, טכנאי הפרסום יכולים להשתמש בנתוני בדיקה ובכלים לבדיקות מקומיות כדי ליצור דוחות סיכום לבדיקה פונקציונלית. כאן אפשר לעיין ב-Codelab בנושא בדיקה מקומית. כדי לבדוק את 'צבירה' ב-TEE, טכנאי הפרסום יצטרכו להשלים את תהליך ההרשמה כפי שמתואר בדרישות המוקדמות של הקוד למעלה. נשמח לקבל משוב נוסף על הבקשה הזו כאן.
שילוב של מפתח/ערך (K/V) של עסקה	בקשה לאפשרות לשלוף מידע מבוסס-עסקה מ-KV לתרחישים לדוגמה לשימוש עסקי.	אנחנו בודקים את הבקשה הזו ונעדכן ב-GitHub.
מדד לעסקה ללא יתרון	שליחת בקשה לקבלת אות או לקבלת אפשרות להבין מתי פלטפורמת SSP לא זכתה ומדוע.	אנחנו בודקים את הבקשה הזו ונעדכן על כך ב-GitHub.
בקשה לתכונה	בקשה לארגז החול לפרטיות לספק מבנה של מילון שיעזור להתאים קבוצה של מודעות לקבוצה המתאימה של מזהי מבצעים.	אנחנו בודקים את הבקשה הזו, יחד עם דרכים אחרות לצמצום הגודל של ה-IG בנוגע לאחסון מזהי עסקאות. נשלח עדכון ב-GitHub.
ביצועים	פתרונות למדידת ההזדמנויות האפשריות להשתתפות במכרזים של מודעות שלא נוצלו, אולי בגלל גודל הסקריפט לבידינג.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.
מפרטים	נכון לעכשיו, מערכת B&A קוראת רק את השדה prevWins במקום את השדה העדכני ביותר prevWinMs, שהחליפו את prevWins במפרט.	נכון ש-B&A לא מעביר את משך הזמן באלפיות השנייה ב-prevWins אל generatebid(). Chrome שולח את משך הזמן בשניות כדי להבטיח פחות עומס יתר על עומס התועלת. התיקון הוא ש-B&A יבצע את ההמרה משניות למילי-שניות. מערכת B&A תספק את prevWins ואת prevWinsMs ב-browserSignals כדי שהיא תהיה תואמת למכרזים במכשיר. הערה: גם במכרזים במכשיר לאינטרנט, הערכים של prevWins ו-prevWinsMs תואמים לאותו ערך, ו-prevWinsMs = prevWins * 1000. אנחנו נותנים עדיפות לתיקון הבעיה.
מאמרי עזרה	במסמכים לא מוסבר בבירור איך לבדוק את Seller Front End‏ (SFE). כדאי להוסיף הנחיות נוספות לבדיקות מיד אחרי השלמת הפריסה, וגם להסביר איך משתמשים ב-Bazel ל-builds.	ה-Codelab הזה פורסם כמדריך שיעזור לסביבה העסקית הרחבה יותר לבדוק את ה-SFE שלהם.
פריסה	האם יש תוכניות לספק קבצים בינאריים מוכנים מראש ל-B&A?	אנחנו שוקלים לספק קובצי בינאריים מוכנים מראש ל-B&A, אבל אין לנו לוח זמנים ספציפי לכך. עד אז, ספקי טכנולוגיות הפרסום יכולים ליצור את הקבצים הבינאריים בעצמם ולאמת אותם באמצעות הגיבוב שסופק.
פריסה	האם צריך לתמוך בכל סוגי התזמור (שרת, לקוח, מעורב) או שיש סוג אחד שצריך לתת לו עדיפות על פני האחרים?	אין לנו המלצות ספציפיות לגבי המצבים שצריך להטמיע בפלטפורמת טכנולוגיית הפרסום. הבחירה תלויה בגורמים שונים, אבל בסופו של דבר היא תלויה באינטרסים של הלקוחות שלכם.
בדיקה	דרוש הבהרה לגבי בדיקות שנכשלו במהלך build של בדיקת A/B.	יכול להיות שהסיבה לכך היא בדיקה לא יציבה. יעץנו לחברת טכנולוגיית הפרסום להשתמש בדגל --no-tests בכל פקודות ה-build של build_and_test_all_in_docker כדי לדלג על הפעלת הבדיקות.
יומנים	רציתי לקבל הבהרה לגבי הסיבה לכך שבמצב בדיקה, היומנים ב-Log Explorer ב-GCP מתויגים למכונה הווירטואלית שמריצה את SFE, אבל במצב ייצור, היומנים לא מתויגים למכונה הווירטואלית.	קשה להכליל כי זה תלוי במה שרואים בדיוק, אבל באופן כללי: - היומנים מ-non_prod הם כנראה יומני stderr שהועברו על ידי ספק הענן (במקרה הזה, GCP), ו-GCP הוסיף את התג. - בדרך כלל, יומנים שנוצרים על ידי המכונה הווירטואלית מתויגים עם מכונה הווירטואלית, בעוד שיומני ה-binary לא מתויגים על ידי GCP. - היומנים מ-prod מיוצאים על ידי Open Telemetry ב-TEE, עם תגים שונים. כאן מפורטים כמה פרטים על מה שזמין ב-non_prod וב-prod.
B&A	שגיאה 403 על סודות חסרים כשיומן OTEL מושבת.	הבעיה תוקנה במסגרת העדכון 4.1, והמסמכים עברו עריכה בהתאם.
B&A	קובץ outputs.tf חסר בתצורת Terraform של GCP גורם לשגיאה.	השגיאה תוקנה.
בדיקה	שגיאה באחזור מפתח פרטי במצב בדיקה.	במקרים כאלה, צריך לוודא שהשרתים פועלים עם TEST_MODE=true. כאן מוסבר איך עושים את זה.
תוכנית עבודה	האם יש תוכניות להגדיר את getInterestGroupAdAuctionData כך שתקבל יותר ממקור אחד של מוכר ותחזיר מפה של מקור המוכר ל-B&A payload ciphertext?	כן, אנחנו מתכננים להוסיף תמיכה באפשרות לאפשר ל-navigator.getInterestGroupAdAuctionData() לקבל מספר מוכרים.
מפרטי KV	האם אפשר להעביר את כתובת ה-KV (trustedScoringSignalsURL) כהתחייבות?	הסבר נוסף זמין כאן.
B&A	בקשה ליצירת כותרת פלטפורמה חדשה כדי לציין לצד המוכר ב-B&A אילו יכולות נדרשות מהלקוח (הדפדפן) כדי שאפשר יהיה לקיים מכרז פרטי.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
עיצוב תעבורת נתונים	הצעה לצמצום העלויות המצטברות של אירוח שרתי B&A, במיוחד עבור פלטפורמות DSP.	אנחנו מדברים על ההצעה הזו כאן ונשמח לקבל משוב נוסף.
Bring-Your- Own-Binary	מומלץ לעדכן את ההסבר כך שיציין במפורש שכל הקבצים הבינאריים נתמכים.	העדכון הזה זמין עכשיו. אפשר לעיין בהסבר כאן.
קריאות KV	האם generateBid() ממתין לסיום כל הקריאות של מאגר המפתחות-הערכים (KV) או פועל בנפרד? איך צבירה של KV משפיעה על התזמון שלו?	הסבר נוסף זמין כאן.
ביצועים	בקשה למסמכים נוספים בנושא שימוש חוזר בסקריפטים של בידינג והמלצה להגדרת כותרות של בקרת מטמון בסקריפטים.	מסמך העזרה נוסף כאן.
ביצועים	בקשה לבדוק את האפשרות לטעון משאבים (למשל, סקריפטים לבידינג) באופן אסינכרוני כדי לצמצם את זמן האחזור במכרזים במכשיר.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
רישום ביומן של הסכמה	דרוש הבהרה לגבי השגיאה שמופיעה כשמנסים להשתמש ברישום ביומן של הסכמה על ידי הגדרת CONSENTED_DEBUG_TOKEN.	במקרים כאלה, צריך לוודא שהמפתח CONSENTED_DEBUG_TOKEN נמצא במנהל הסודות, שהערך של ENABLE_OTEL_BASED_LOGGING מוגדר כ-true והערך של TELEMETRY_CONFIG מוגדר כ-mode: PROD. מידע נוסף זמין במאמר ההסבר כאן, שמפנה למקור כאן.
יומנים	האם אירועים מסוג forDebuggingOnly זמינים דרך B&A?	האפשרות forDebuggingOnly ל-B&A הייתה זמינה במכרזים של מוכר יחיד מאפריל 2024. אנחנו מתכננים להפעיל את התכונה הזו במכרזים עם כמה מוכרים בקרוב מאוד.
יומני worklet	בקשה להפוך את הרישום ביומן של רכיבי worklet לתואמים ל-ChromeDriver.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
דוחות ניפוי באגים	איך דוחות ניפוי הבאגים של ARA יהיו זמינים לטכנאי הפרסום לאחר הגישה המעודכנת ל-3PC ב-Chrome? האם לספקי טכנולוגיות הפרסום עדיין תהיה גישה לדוחות ניפוי הבאגים של ARA לגבי משתמשים שעדיין שומרים קובצי cookie של צד שלישי וממשקי ה-API של ארגז החול לפרטיות מופעלים אצלם?	למומחים לטכנולוגיות פרסום תהיה גישה לפתרונות לניפוי באגים שמבוססים על קובצי cookie ופתרונות ללא קובצי cookie, לגבי משתמשים שהגדירו גם 3PC וגם ARA. כשקובצי ה-cookie מושבתים, תהיה להם גישה רק לפתרון ניפוי הבאגים המצטבר. פרטים נוספים על פתרונות ניפוי הבאגים זמינים כאן וכאן.
זיהוי תכונות	בקשה לקבלת הנחיות לביצוע זיהוי תכונות ל-ARA בצד השרת.	נכון לעכשיו, אפשר לזהות את התמיכה בתכונות ARA על סמך גרסת Chrome שמופיעה במחרוזת סוכן המשתמש. נשמח לקבל מכם משוב נוסף בנושא הזה.
בקשה לתכונה	בקשה לשדה source_registration_time שמשמש ב-ARA Aggregate shared_info, כדי שיהיה מפורט יותר, למשל, מעוגל כלפי מטה לשעה אחת או לדקה אחת (לעומת יום אחד), וגם ניתן להגדרה כך שייקח בחשבון את אזור הזמן (כרגע רק UTC).	עיגול השדה source_registration_time ליום הקרוב ביותר הוא מנגנון פרטיות שמשמש לצמצום היכולת של טכנולוגיית פרסום לקשר משתמש ספציפי לרישום של מקור ספציפי. נכון לעכשיו, השדה source_registration_time מבוסס על שעון UTC, וטכנולוגיית הפרסום יכולה לשנות את דוחות המודעות שלה בהתאם לכך. נשמח לקבל משוב נוסף על הסביבה העסקית בנוגע לבקשה הזו כאן.
מפרטים	בקשה להבהרת המפרט של 'trigger_data' ושל 'priority', במיוחד כשמשתמשים בהם עם ערך מערך.	בשדות האלה לא ניתן להזין ערכים של מערך. הסוגריים המרובעים בהסבר לא מייצגים מערך, אלא מציינים שהטקסט הוא לא ערך לדוגמה, אלא placeholder עם תיאור. כפי שמציין הטקסט בסוגריים המרובעים: - trigger_data הוא int-64 - priority הוא int-64 עם סימן אף אחד מהשדות לא מקבל ערכים של מערך. כדאי גם להשתמש בכלי לאימות כותרות ב-ARA כדי להתנסות בערכים שונים ולזהות שגיאות אם המסמכים מבלבלים.
תמיכה במודעות של Accelerated Mobile Pages‏ (AMP)	האם יש תמיכה במודעות AMP ב-ARA?	ההצעה שלנו לגבי האופן שבו נוכל לתמוך ב-AMP זמינה כאן, ונשמח לקבל משוב נוסף.
מפרטים	איזו כתובת URL תיחשב כ'אתר מקור' למודעות מוטמעות בכמה שכבות ב-ARA?	כתובת ה-URL מהאתר ברמה העליונה.
(דווחו גם ברבעונים קודמים) בקשה להוספת תכונה	בקשה להקטנת הערך המינימלי של event_report_window מ-3,600 שניות (שעה אחת) ל-1,800 שניות (30 דקות).	כדי לקבוע את חלון הדיווח המינימלי, צריך למצוא איזון בין שיקולים של תועלת לבין שיקולים של פרטיות. חלון הדיווח המינימלי של שעה אחת לדוחות ברמת האירוע חיוני לשמירה על הפרטיות ולמניעת סוגים מסוימים של התקפות לשחזור היסטוריה. נשמח לקבל משוב נוסף על הבקשה הזו כאן.
רעש	רצית להבין לעומק איך רעשי רקע מוטמעים בדוחות ברמת האירוע של ARA, כדי להבטיח פרשנות מדויקת של הנתונים ושימוש יעיל בהם.	פרטים נוספים זמינים כאן וכאן.
דיווח	כברירת מחדל, השדה shared_info בדוחות מצטברים לא מכיל יותר את השדה source_registration_time.	הסיבה לכך היא שינויים ב-API, כפי שמפורט כאן.
דיווח	השדה filtering_id לא מופיע בכרטיסייה 'דוחות שניתן לצבור' בממשק המשתמש של chrome://attribution-internals/.	השדה filtering_id גלוי כרגע בפרטי הכרטיסייה 'הפעלת רישומים' כשלוחצים על שורה, וכך אפשר לאשר את התוקף שלו. אנחנו מבינים את התועלת שבהצגת הדוח הזה בכרטיסייה 'דוחות שניתן לצבור', ועל כך כתבנו כאן.
מקור השיוך (Attribution)	בקשה להבהרה לגבי אופן הפעולה של מקור השיוך.	הסבר זמין כאן.
שיוך (Attribution) מאפליקציה לאתר	בקשה להנחיה לגבי הטמעות שבהן לא ברור אם המקורות יהיו מערכת הפעלה או אינטרנט.	כאן מפורטות הנחיות בנושא.

Aggregation Service

נושא המשוב	סיכום	תגובה מ-Chrome
בקשה לתכונה	בקשה להגדרת זמן קצוב לתפוגה ל-AgS ו/או לקבלת גישה רחבה יותר לסטטוס של משימות שפועלות לטווח ארוך.	אנחנו שוקלים להוסיף תכונות שתומכות במעקב אחרי משימות ממושכות. נשמח לקבל מכם משוב נוסף בנושא הזה.
Terraform	Terraform מנסה לשנות את מדיניות IAM של החשבון גם אם לא מוגדר service_account_token_creator_list.	מפתחים יכולים להוסיף את ההרשאות הנוספות שלהם בקובץ modules/adtech_setup/main.tf המקומי.
בקשה למסמכים	בקשה למסמכים או ל-codelab שמסבירים איך לעקוב אחרי בריאות השירות של הצבירה.	תיאור של ההתראות הקיימות שאפשר להשתמש בהן כדי לעקוב אחרי בריאות השירות והמשימה מופיע בקובצי Terraform הרלוונטיים של המפעיל (alarms.tf ו-monitoring.tf) במאגר coordinator-services-and-shared-libraries. אנחנו נעלה מסמכי תיעוד והנחיות נוספים בנושא מעקב אחרי משימות של שירותי צבירת נתונים.
שינוי קנה מידה	איך עוקבים אחרי בעיות שקשורות להתאמה לעומס?	פרסמנו גרסה מעודכנת של ההנחיות האלה, שמתעדת את ההיקף המוגדל של שירות האגרגציה. כרגע אין אות ישיר שמציין שהכשל קרה כי המכונה לא יכולה לתמוך בהיקף של המשימה. אותות עקיפים כוללים: 90% צריכת זיכרון לפני כשל, משימה שנכשלת באופן קבוע. נשמח לקבל משוב נוסף מהסביבה העסקית לגבי הצורך באות כזה.
מפרטים	מהו משך הזמן האופייני להרצה של קבוצות של דוחות AgS?	כאן מפורטות הנחיות.

Private Aggregation API

נושא המשוב	סיכום	תגובה מ-Chrome
בקשה לתכונה	בקשה לאפשר תרומות של ערכים מסוג float (כולל ערכים שליליים) ל-contributeToHistogramOnEvent עם רגישות של 2^16	אנחנו מדברים על ההצעה הזו כאן ונשמח לקבל משוב נוסף.

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

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

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

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

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

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

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

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

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

נושא המשוב	סיכום	תגובה מ-Chrome
(דיווח גם ברבעונים קודמים) מגבלת הדומיינים של קבוצות של אתרים קשורים (RWS)	המגבלה הנוכחית של חמישה דומיינים משויכים לא מספיקה כדי לעמוד בדרישות של תרחישים לדוגמה של מדידה בכמה אתרים.	התשובה שלנו דומה לתשובות שנתתנו ברבעונים קודמים: בשלב הזה, אנחנו לא מתכוונים להגדיל את המגבלה המספרית. המגבלה נקבעה על סמך שיקולים של פרטיות המשתמשים, משוב מבעלי עניין בסביבה העסקית ב-W3C והתחשבות בהטמעות דומות בדפדפנים אחרים. מידע נוסף זמין בפוסט בבלוג שלנו (1, 2). מומלץ לבדוק תרחישים לדוגמה שבהם נדרשת גישה לקובצי cookie בכמה אתרים מעבר למגבלה המספרית, ולשקול להיעזר בהנחיות שלנו לגבי תרחישים לדוגמה לזיהוי, הטמעות מאומתות ותרחישים לדוגמה לפרסום. נשמח לקבל משוב נוסף על הבעיה הזו כאן.

Fenced Frames API

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

Shared Storage API

נושא המשוב	סיכום	תגובה מ-Chrome
שימוש ב-API	ממשק ה-API של אחסון משותף לא זמין במכשירים מסוימים כשממשקי API אחרים של ארגז החול לפרטיות פועלים.	ההתנהגות הזו צפויה בקבוצת משנה קטנה של משתמשים (כ-1%) שמשתתפים בניסוי של אחסון שיתופי. ההגדרה הניסיונית הזו משמשת להערכת הביצועים וההטמעה של ממשקי API בתרחישים שונים.
שימוש ב-API	האם הכתיבה ב-Shared Storage מתבצעת במקור של בעל התוכן הדיגיטלי או במקור של תסריט הבידינג? בבדיקות הראשוניות לא נמצאו פעולות כתיבה כשמקור בעל התוכן הדיגיטלי היה שונה ממקור הסקריפט.	הבעיה נפתרה, והיא נשארת פתוחה רק במקרה של באג אפשרי ב-devtools. פרטים נוספים זמינים כאן. Shared Storage כותב למקור הקונה בהקשר הבידינג של הקריאה generateBid. הכתיבה לא קשורה למקור של בעל התוכן הדיגיטלי, גם אם דף בעל התוכן הדיגיטלי נמצא בדומיין אחר.
שימוש ב-API	מהן אמצעי ההגנה שנועדו למנוע מגורם זדוני לקרוא דוחות של אחסון משותף?	נפח האחסון המשותף מחולק למחיצות באמצעות קריאה ל-origin, כך שגורם זדוני או טכנולוגיית פרסום לא יכולים לקרוא נתונים של נפח האחסון המשותף מטכנולוגיית פרסום אחרת. דוחות Private Aggregation נשלחים ישירות לאותו מקור באמצעות TLS, כך שלא ניתן ליירט אותם.

CHIPS

נושא המשוב	סיכום	תגובה מ-Chrome
קובצי Cookie עם חלוקה למחיצות	יש טיפול לא עקבי בקובצי cookie ביציאות שונות של localhost ב-Chrome וב-Firefox, במיוחד כשמשתמשים במאפיין Partitioned.	ב-Firefox, localhost עם יציאות שונות נחשב למפתחות מחיצה נפרדים. ההתנהגות הזו תואמת לעקרונות האבטחה, אבל היא חורגת מהמפרט ומהגישה של Chrome. אנחנו מתכוונים לדון בנושא הזה עם דפדפנים אחרים בדיון על מפרט HTML, ונודיע לסביבה העסקית אם השינוי הזה יוביל לשינוי במפתח המחיצה של CHIPS. נשמח לקבל משוב נוסף על הבעיה הזו כאן.
קובצי Cookie עם חלוקה למחיצות	טיוטת ה-Clear-Site-Data מאפשרת באופן שגוי לנקות מעבר למחיצה של האתר שמפיץ את הנתונים, בניגוד לדיוני עבר שצוינו כאן.	זהו באג במסמך של מפרט הסטנדרטים, ואנחנו מתכוונים לתקן אותו בקרוב. ההתנהגות הנכונה מפורטת בחלק הזה של ההסבר, והיא תואמת להתנהגות בדפדפנים אחרים שמפורטת במאגר ההסברים על חלוקת אחסון. ההטמעה ב-Chrome כבר פועלת כראוי.

FedCM

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

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

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

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