דוח משוב – רבעון 4 לשנת 2023

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

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

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

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

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

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

מילון מונחים של ראשי תיבות

צ'יפים

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

DSP

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

FedCM

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

FPS

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

IAB

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

IdP

ספק זהויות

IETF

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

IP

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

openRTB

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

הארכה

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

PatCG

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

RP

מסיבת נאמנות

SSP (פלטפורמה בצד המכירה)

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

TEE

סביבת ביצוע מהימנה

UA

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

UA-CH

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

W3C

ארגון האינטרנט העולמי

WIPB

עיוורון IP של רצון טוב

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

נושא משוב	סיכום	התגובה של Chrome
ציר זמן בתלת-PCD	שיתוף מידע נוסף על ציר הזמן 3PCD.	כדי להקל על הבדיקה, החל מ-4 בינואר 2024, Chrome הגביל את השימוש במחשבים מסוג 3PC ל-1% מהמשתמשים כברירת מחדל. בכפוף לטיפול בהמשך החששות של ה-CMA, ב-Chrome מתכננים להפסיק בהדרגה את התמיכה במחשבים ל-3PC החל מהרבעון השלישי של 2024, ולהמשיך עד סוף שנת 2024.
ציר זמן בתלת-PCD	ההשפעה של תזמון 3PCD ברבעון הרביעי של 2024 כי הוא מתרחש בתקופת החגים של סוף השנה האזרחית ועשוי להשפיע לרעה על בעלי תוכן דיגיטלי.	אין זמן מושלם להוציא משימוש 3PC. במשך יותר משנה היה לנו ברור שהכוונה שלנו הייתה להוציא משימוש 3PC במחצית השנייה של 2024. ההתחייבויות שלנו ל-CMA, שכוללות את המועד האפשרי לתקופת עמידה בתנאים, לא השתנו. אנחנו מבינים את החששות לגבי התזמון ברבעון הרביעי, אבל ביצוע שינויים בלוח הזמנים הוביל לפחות הכנה לקראת התעשייה, ולא יותר.
בדיקה של Chrome (מצב a/b)	האם הגדרות הבדיקה של מצב א' ומצב ב' הן לכל מכונה או לפרופיל Chrome?	פרסמנו הבהרה במסמך כאן, שדפדפן Chrome בהקשר הזה מתייחס ללקוח Chrome: התקנה של Chrome במכשיר. כל ספרייה של נתוני משתמש מהווה לקוח נפרד.
תקופת ניסיון להוצאה משימוש	שיתוף מידע נוסף על תקופת הניסיון 3PCD.	כאן שיתפנו מידע נוסף על תקופת הניסיון של 3PCD.
תקופת ניסיון להוצאה משימוש	אין מספיק זמן כדי לספק אסימונים להוצאה משימוש בכל האתרים לפני ינואר 2024.	אנחנו מודעים לכך שיש פרק זמן קצר מרגע הפתיחה של הרישום לתקופת ניסיון שהוצא משימוש ועד שתקופת הבדיקה שמתבצעת באמצעות Chrome חוסמת 1% מקובצי ה-cookie. כדי לטפל במגבלות הזמן האלה, Chrome מעניק תקופת חסד למקורות המשתתפים בזמן שהם פועלים לפריסת אסימונים של גרסת ניסיון להוצאה משימוש. במהלך תקופת החסד, שתימשך עד 1 באפריל 2024, למקורות שנרשמו לתקופת הניסיון להוצאה משימוש תהיה גישה למחשבים 3PC ב-Chrome, גם אם הם עדיין לא פרסו את האסימונים שלהם. המטרה של תקופת החסד הזו היא למנוע בעיות תאימות באינטרנט במהלך שלב המעבר. המקורות המשתתפים חייבים לפרוס אסימונים להוצאה משימוש לפני תום תקופת החסד כדי להמשיך לקבל גישה ל-3PC אחרי סיום תקופת החסד.
בדיקה של Chrome (מצב a/b)	מצב ב' קטן מדי מדגימה ולכן אי אפשר למדוד ירידה מדויקת בביצועים.	יש איזון זהיר בין אחוז התנועה לבין הסיכון להשפעה על המשתמשים והפונקציונליות באינטרנט.
פקדי בדיקה	רק בעלי התוכן הדיגיטלי הגדולים ביותר שיש להם משאבי פיתוח משמעותיים יוכלו להבין את הביצועים במהלך הבדיקה ולהעביר אותם ל-CMA.	ספקי שירותים לבעלי תוכן דיגיטלי כבר משתפים תובנות באופן ציבורי עם הסביבה העסקית הרחבה יותר, וסביר להניח שהדבר יימשך גם בעתיד, ככל שהבדיקות של ארגז החול לפרטיות יעלו. אנחנו גם צופים שחברות פרסום דיגיטלי שמסתמכים על ממשקי ה-API של ארגז החול לפרטיות ימשיכו לפתח תכונות לבקשת הלקוחות שלהן, כמו דיווח על סמך תוויות.
נתונים שנאספו על ידי צד שלישי	חשש בנוגע לחברות נתונים של צד שלישי.	יש טעמים שונים של חברות נתונים מצד שלישי. חלק מהם עשויים להכפיל את עצמו, דבר שיהפוך לשיטות אטומות יותר של מעקב באתרים שונים. עסקים אחרים יכולים להסתמך על טכנולוגיות לשיפור הפרטיות ולפתח הצעות ערך חדשות עם הלקוחות שלהם. אנחנו מקווים שאנשים רבים יותר יבחרו להשתמש באפשרות השנייה ולפעול בכיוון שהדרישות הולכות וגדלות מצד המשתמשים והרגולטורים. שינוי ייצור הזדמנויות להתפתחות ולחדשנות.
Google Ad Manager	צריכים הדרכה נוספת מ-Google Ad Manager לגבי האופן שבו בעלי תוכן דיגיטלי יכולים לבדוק את ארגז החול לפרטיות. הדיווחים לא מספיקים לבעלי האפליקציות כדי להבין את ההשפעה.	התשובה סופקה על ידי Google Ad Manager: במרכז העזרה מוסבר איך תתבצע ב-Google Ad Manager איך לבצע את הבדיקה באמצעות תוויות בדיקה ש-Chrome עזר. נכון לעכשיו, מערכת Ad Manager מספקת לבעלי תוכן דיגיטלי דוחות לגבי Topics ו-Protected Audience. נכון למועד שליחת דוח המשוב הזה, מערכת Ad Manager יכולה לדווח על חשיפות שהוצגו דרך Protected Audience API ולהצביע אם נתונים מ-Topics API היו קיימים בחשיפה מסוימת. בעלי תוכן דיגיטלי שרוצים לקבל דוחות מתקדמים יותר, כמו פילוח דוחות על סמך תוויות מותאמות של Chrome, יכולים לקרוא את התוויות ישירות ב-Chrome (באמצעות מסמכי התיעוד של Chrome) ולהעביר אותן כערכי מפתח בבקשות להצגת מודעות אל Ad Manager, וגם דיווח על ערכי מפתח לצורך דיווח על התוויות.
תמריצים לבדיקה	החשש של המפרסם לגבי מספיק זמן לבדיקת ארגז החול לפרטיות ואפשרות לשינויים מהותיים ב-API שעתידים להיות זמינים.	אנחנו מבינים שחלק מהאנשים רוצים עוד זמן, אבל שמענו שוב ושוב מהגורמים מהתחום ששינוי לוח הזמנים ככל הנראה יגרום לירידה במוכנות המערכת האקולוגית, ולא יותר. לוח הזמנים להוצאה משימוש של מחשבי 3PC כפוף לטיפול בבעיות נוספות של ה-CMA בנוגע לתחרות, אבל אנחנו מעודדים את כולם להתכונן לקראת מודל 3PCD בשנת 2024. כמו כל טכנולוגיה, גם ממשקי ה-API של ארגז החול לפרטיות ימשיכו להתפתח. התפתחות זו נובעת מחידושים בטכנולוגיות ובקלט של מערכות אקולוגיות. נמשיך להיות אחראים בעת ביצוע שינויים, ואנחנו לא חושבים ששינויים בטכנולוגיה צריכים להגביל את השימוש ללא הגבלת זמן.
CTV	אין נתיב לתמיכה בווידאו ליניארי או CTV.	נשמח לחקור עוד תרחישים לדוגמה ב-CTV, אבל אנחנו לא חושבים שממשקי API למכשירי CTV יפריעו לתלת-ממד ב-Chrome.
שרתי מודעות של מפרסם	נראה ש-Google מעבירה את טירגוט המודעות ל-DV360. איזו תמיכה תינתן לשרתי מודעות של מפרסמים?	התשובה סופקה על ידי Chrome: PA API מיועד לאפשר לשרתי המודעות של המפרסמים להציג מודעות ולמדוד את הביצועים שלהן באמצעות iFrames / Fenced Frames ודיווח על Beacon. בנוסף, הם יעבדו עם צדדים שלישיים וגורמי צד שלישי כדי לשלב אותם בתהליך הצגת המודעות, כמו שהם עושים היום.
המרכז של Google Ads לניהול נתונים	לאחרונה הכרזנו שכלי ניהול הנתונים של Google Ads מסתמך על התאמה ללקוחות והמרות משופרות, שמאפשרות למפרסמים לשתף עם Google את נתוני הלקוחות מאינטראקציה ישירה (First-Party) כדי לתחזק את כל הפונקציות השיווקיות ש-3PC מבצעים. איך התכונה החדשה הזו תואמת למחויבויות של Google ל-CMA?	התשובה סופקה על ידי Google Ads: הכלי לניהול נתונים של Google Ads פשוט מאפשר להעלות נתונים מאינטראקציה ישירה (First-Party) ממערכות לאחסון נתונים של מפרסמים (מערכות ענן) כדי שהמפרסמים יוכלו להשתמש בהם ב'התאמה ללקוחות' (CM) וב'המרות משופרות (EC)'. כך קל יותר לעסקים קטנים עד בינוניים עם פחות משאבים טכניים. הכלי לניהול נתונים של Google Ads לא מפעיל יכולות חדשות לחלוטין עבור CM או EC מבחינת יכולת כתובת או יכולת מדידה של מודעות ב-Google O&O או לבעלי אתרים של צד שלישי. לפלטפורמות הפרסום של Google יש את אותה גישה ליכולות הזמינות בטכנולוגיות של ארגז החול לפרטיות כמו לחברות אחרות של טכנולוגיות פרסום.
הגדרות Chrome	דף ההגדרות הפנימי של Chrome אמור לספק מידע נוסף על הגודל של קובצי cookie.	הפונקציונליות המבוקשת כבר זמינה ב'כלים למפתחים ב-Chrome'. נשמח לקבל משוב נוסף שיסביר למה כדאי לתת עדיפות לתכונה הזו גם בדף ההגדרות.
היוריסטיקה	אילו כללים בצורה של מערכת Chrome פורס כדי לשמר חוויות משתמש קריטיות במהלך 3PCD?	כדאי לקרוא את התשובה שלנו לשאלה הזו ב-GitHub.
גרסאות דפדפן	מה ההבדל בין דפדפני Chrome יציבים לבין דפדפני Chrome לא יציבים?	התאמה גסה של הגרסה הראשית של Chrome למחזור הגרסאות היציב תפעל.
תאימות	האם Chrome יכול לספק דוחות הקשורים ל-SOX?	Chrome לא יספק דוחות שקשורים ל-SOX. ממשקי ה-API של ארגז החול לפרטיות הם אחד מתוך ממשקי API רבים באינטרנט שזמינים ב-Chrome לאתרים שבהם המשתמש מבקר. כמו בכל ממשקי ה-API לאינטרנט, קורא ה-API לא חותם על הסכם עם Chrome לשימוש בממשק ה-API של ארגז החול לפרטיות. הגישה תלויה רק בשאלה אם מבצע הקריאה ל-API עומד בדרישות הטכניות ושהמשתמש הפעיל את ההגדרות המתאימות. אם כן, קורא ה-API לבדו יקבע איך להשתמש בממשק ה-API, כולל סוגי הנתונים שיישמרו, אילו הצעות מחיר להגיש, איזה דיווח לבקש וכו'.
תאימות	הרחבת השאלות הנפוצות בנושא תאימות לארגז החול לפרטיות, כדי לענות על שאלות נוספות.	אנחנו מעריכים את המשוב ומתכננים להמשיך ולפתח את השאלות הנפוצות.
שאלה לגבי Chrome	האם ההוצאה משימוש של מחשבי 3PC ב-Chrome משפיעה על הזמינות של מחשבים 3PC ב-Android WebView (דפדפן מוטמע)?	נכון לעכשיו, אנחנו לא כוללים WebView בשלב זה של ההשקה והבדיקה של 3PCD או של ארגז החול לפרטיות, מלבד הפעלה של מדידת שיוך (Attribution) באפליקציות ובאינטרנט.
שאלת API	איך אפשר לעקוב אחרי קליקים וחשיפות של מוצרים ממומנים?	התרחיש לדוגמה הזה נכלל ב-Attribution Reporting API.
ציר הזמן	למה ציר הזמן של 3PCD השתנה?	דנו בסיבות לכך כאן.
כניסה יחידה (SSO) לתוסף Chrome	לאפשר תרחיש לדוגמה של כניסה יחידה (SSO) בין אתר לבין תוסף ל-Chrome אחרי 3PCD.	אנחנו דנים בבעיה הזו ונשמח לקבל משוב לגבי תרחישים נוספים לדוגמה.
שימוש ב-API	האם Google יכולה לאשר רשימה של שותפים שאיתם אפשר לבדוק ממשקי API?	פרטי הבודקים שזיהו את עצמם באופן ציבורי זמינים ב-GitHub עבור ממשקי ה-API הבאים: - Topics API - Protected Audience API - Attribution Reporting API - אחסון משותף - CHIPs
מיזם Utiq	מהי נקודת המבט של Chrome לגבי מיזם Utiq?	אנחנו דנים בנושא כאן.
שאלה לגבי Chrome	איך מזהים משתמשים שגולשים בלי מחשב 3PC?	אין הגדרה מפורשת לזיהוי חסימת 3PC. בגישה כללית של 'זיהוי תכונות', מומלץ ליצור בקשה מסוג iframe / אתרים שונים ולנסות להגדיר קובץ cookie דומה לתרחיש לדוגמה הנדרש.
שאלה לגבי Chrome	האם הגלישה במצב פרטי זהה להפעלת בדיקת הדגל (מפעילים את Chrome באמצעות סימון שורת הפקודה --test- third-party-cookie-phaseout)?	מצב גלישה בסתר שונה מהדגל. הדגל חוסם לא רק מחשבי 3PC, אלא גם מאפשר חלוקה למחיצות באחסון של צד שלישי.
שאלה לגבי Chrome	פרטים נוספים על ההשפעה הצפויה של תלת-ממד (3PCD) על כל אזור/מדינה כאשר יתרחש 1%.	לקוחות מצורפים ל-1% באופן אקראי, בכל העולם, אם כי עשויות להיות הבדלים אזוריים. לדוגמה, יכול להיות שיהיו הבדלים בהפצה של מכשירים ובגרסאות של Chrome.
טכנולוגיות חלופיות לשיפור הפרטיות	צריך לאפשר לטכנולוגיות חלופיות לשיפור הפרטיות לבצע מעקב בכמה דומיינים תוך שמירה על הפרטיות, כדי למנוע מונופול בנתונים ב-Chrome וב-Android.	למפתחים יש הזדמנויות רבות לפתח הצעות טכנולוגיות לשיפור הפרטיות בנוסף לאבני הבניין שאנחנו מציעים, וגם לאבני בניין שלא מתייחסות לארגז החול לפרטיות.
מחקר CookieGraph	מהי נקודת המבט של Chrome לגבי שיטת CookieGraph כפי שמתואר במאמר הזה במסגרת ארגז החול לפרטיות?	אנחנו בודקים את המאמר הזה ונשמח לקבל משוב נוסף.

הרשמה ואימות

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

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

נושאים

נושא משוב	סיכום	התגובה של Chrome
שימושיות לסוגים שונים של בעלי עניין	בעלי תוכן דיגיטלי מודאגים מההשפעה של נושאים על מכירות מבוססות-נתונים. לאתרים גדולים יותר מוקצה נושא 'חדשותי' כללי, אין נתונים שמקשרים אותו לבעל האתר הספציפי. בעלי אתרים מומחים מוסרים את הנתונים שלהם תמורת מידע מוגבל.	אנו מכירים בכך שאתרים עם דומיינים בעלי עניין כללי יותר עשויים לתרום נושאים פחות מפורטים מאשר אתרים עם דומיינים בעלי תחומי עניין נישתיים יותר. עם זאת, לא כל אתרי נישה תורמים נושאים בעלי ערך מסחרי. בנוסף, הדינמיקה הזו משקפת את המצב קוו - שאתרים מסוימים מספקים ערך רב יותר מאחרים במערכות רלוונטיות של מודעות המבוססות על 3PC. Topics (וארגז החול לפרטיות באופן כללי) מעניקים לבעלי תוכן דיגיטלי שליטה רבה יותר על האופן שבו חברות הפרסום הדיגיטלי משתמשות במידע שלהם. יתרה מכך, המידע הזמין דרך Topics API רחב יותר מזה של אותות קיימים.
שרתי מודעות של בעלי תוכן דיגיטלי	ייתכן ששרתי המודעות של בעלי התוכן הדיגיטלי שמשתמשים בשרתי מודעות ייעודיים לא יוכלו לצפות ישירות ב-Topics API.	כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
הצהרה	צריך להרחיב את דרישת האימות (attestation) כדי לטפל בתוצאות הלא רצויות הידועות של העברת מידע בין הקשרים.	בשלב הזה, האימות לא מיועד לכסות את קטגוריית הסיכון הרחבה הזו, אלא לטפל בניצול לרעה של ה-API.
נפח התנועה מ-Topics	נפח החשיפות הנוכחי שהתקבלו לא מספיק לצורך בדיקה.	ב-Chrome אנחנו מודעים למשוב לגבי נפח הנושאים הזמינים בסביבה העסקית הפרוגרמטית. אנחנו בודקים את הסיבות האפשריות - גם בתוך הדפדפן וגם בקרב בודקים רלוונטיים. אם ייקבע שיש צורך בכך, Chrome יעריך אילו שינויים פוטנציאליים בעיצוב ה-API זמינים כדי להגדיל את שיעור הכיסוי ולאפשר בדיקה בקנה מידה גדול מספיק, תוך שמירה על פרטיות המשתמשים.
שימוש ב-API	האם יש הגבלת קצב של יצירת בקשות לשימוש ב-Topics API?	כדי למנוע ניצול לרעה של המשתמשים ולהגן על חוויית המשתמשים באינטרנט, אנחנו מיישמים מגבלות מסוימות לקצב שליחת נושאים. אפשר לקרוא כאן פרטים נוספים.
טקסונומיה של גרסה 2	הנחיות של IAB לגבי הכללת פרטי הנושא בפרוטוקול RTB פתוח?	כן, כאן ניתן למצוא הנחיות של IAB בנושא הכללת Topics API בפרוטוקול Open RTB.
ההשפעה על אותות מאינטראקציה ישירה	גרסה 2 של טקסונומיה של נושאים מפורטים, בשילוב עם תהליך להחזרת הערך הגבוה ביותר של הפילוח המפורט הזה (נושאים מובילים), יגרמו לשיבוש השוק להצגת נתונים בפרסום.	התשובה שלנו לא השתנתה מהרבעון השלישי: " למרות שטקסונומיה מפורטת יותר של Topics עשויה להפחית באופן עקיף את הפתרונות האחרים, כמו פתרונות שמבוססים על נתונים מאינטראקציה ישירה (First-Party) של בעל התוכן הדיגיטלי או פתרונות שמסתמכים על עסקאות ישירות, אנחנו מפתחים את Topics API, והמטרה העיקרית שלנו היא להבטיח תמיכה בתרחישים לדוגמה של פרסום לפי תחומי עניין אחרי 3PCD בצורה יעילה ככל האפשר, לטובת כל בעלי העניין. אנחנו מאמינים שתועלת רבה יותר ל-Topics API תשפר את התחרות באופן כללי ותביא תועלת לסביבה העסקית הכוללת".
רשימת בודקים	איך בעלי האפליקציות שלכם משתמשים ב-Topics וב-PA API?	אין לנו אפשרות לשתף מידע כזה. אתם יכולים להיעזר ב רשימת הבודקים, שבה בעלי תוכן דיגיטלי יכולים להביע הסכמה לשיתוף סטטוס הבדיקה שלהם.
בחירת נושאים	לאפשר למשתמשים לבחור באופן יזום תחומי עניין?	בהחלט שקלנו לאפשר למשתמשים להוסיף נושאים באופן יזום. אנחנו לא מתכננים לטפל בנושא בטווח הקצר, אבל אנחנו פתוחים לבחון את האפשרות הזו לטווח ארוך יותר.
בחירת נושאים	אם לטכנולוגיית פרסום יש קוד באתר שמאפשר לצפות בנושאים שונים, האם היא יכולה לדעת מהם הנושאים שהמשתמשים עשויים לחפש?	חברת פרסום דיגיטלי יכולה לקבוע מהם הנושאים המשויכים לאתר. ה-API לא משתף את המידע הזה בזמן אמת, כי הוא עלול לגרום לעלויות זמן אחזור.
טקסונומיה של גרסה 2	מאחר שנושאים יכולים להחזיר עד 3 נושאים, מהי ההתנהגות הצפויה כשנשיק את גרסה 2 של הטקסונומיה?	ה-API עדיין יחזיר עד 3 Topics, ובתשובה יכלול את גרסת הטקסונומיה הרלוונטית של כל נושא.
(דווח גם ברבעונים קודמים) תצפית על נושאים	מומלץ לאפשר לבעלי אתרים להעניק ל-Chrome הרשאות לקטגוריות של נושאים לפי תוכן הדף (לדוגמה, ראש או גוף).	התשובה שלנו לא השתנתה מהרבעון השלישי: "בעבר שקלנו להציע פונקציונליות לסיווג אתרים לפי נושאים על סמך התוכן בדפים, והחלטנו שלא להתקדם בגלל בעיות של פרטיות ואבטחה. הצעה זו עשויה להפחית חלק מהחששות האלו, אך לא ברור עד כמה. בשל תקופת הניסוי הקרובה של CMA, אנחנו לא צופים שהשינוי הזה יתרחש לפני 3PCD. נשמח לקבל משוב נוסף כאן."
בחירת נושאים	באיזה אופן מתבצעת הסיווג של הדומיינים עם Topics API בהתחשב בכך שהם כלליים?	אנחנו משתמשים רק בשם מארח כדי לסווג אתרים לפי נושאים. כך לא ייגרם נזק לאתר המסווג באופן נרחב. הסיבה לכך היא שמידע תלוי-הקשר של אתר יהיה תמיד זמין במכרזים באתר שלו, שיספקו מידע ספציפי יותר לנושא הרחב.
טקסונומיה של גרסה 2	אני רוצה להתאים טוב יותר את הנושאים לסטנדרטים אחרים (למשל, IAB).	נשמח לשמוע פרטים נוספים על הסיבות לכך שהם קיוו להתאמה מדויקת יותר בין הטקסונומיה של IAB לבין הטקסונומיה של Topics. אילו פעולות הם צריכים לבצע כדי לאמץ את Topics API, ואיך טקסונומיה ייחודית יותר משפיעה על השלבים האלה? אנחנו שוקלים להשיק מיפוי בין טקסונומיית הנושאים לבין טקסונומיית התוכן של IAB. כדאי להבין אם הפעולה הזו תענה על האתגרים שאיתם מתמודדים בעלי האתרים.
אחסון נתונים ושימוש בהם	האם יש לך מידע נוסף על אופן האחסון של הנתונים ולהיכן הנתונים מועברים?	מידע על הנושאים נוצר ומאוחסן באופן מקומי במכשיר של המשתמש. אם תתקבל בקשה, ה-API מחזיר עד 3 נושאים למתקשרים. לפי תצוגת Google, המתקשרים אחראים לציית לתקנות המקומיות בעת טיפול ואחסון של מידע של נושאים. בנוסף, כל המתקשרים חייבים לציין שהם לא משתמשים ב-Topics כדי לזהות מחדש משתמשים באתרים שונים. למידע נוסף, אפשר לעיין בשאלות הנפוצות בנושא תאימות לפרטיות.
טקסונומיה של גרסה 2	ההשפעה של שדרוג טקסונומיית הנושאים ומצב הדפדפן במהלך המעבר מגרסה 1 לגרסה 2.	הנושאים שהוסקו בעזרת הטקסונומיה הקודמת עדיין זמינים, וטכנולוגיית המודעות תוכל לאחזר אותם בסופו של דבר עד שיפוג התוקף שלהם (לפני 4 שבועות).
תיאור API	חוויית המשתמש ב-Topics API מטעה.	שיתפנו את המשוב הזה עם צוות ה-UX.
שאלת API	איך מסווגים דומיינים של Yahoo עם Topics בהתחשב באופן כללי?	אנחנו משתמשים רק בשם מארח כדי לסווג אתרים לפי נושאים. חשוב להבין שאתר עם סיווג רחב לא נפגע.
שיעור הזמינות של הנושאים נמוך	הבודקים מקבלים מ-Google Ad Manager כמות נמוכה של Topics.	ב-Google Ad Manager יישמו מספר אופטימיזציות כדי לשפר את הכיסוי – קונים אמורים לראות עלייה בכיסוי. יש כמה גורמים צפויים שעשויים להגביל את הכיסוי (למשל: העדפות משתמש, דרישות תצפית על ידי המתקשר, אפשרות לזמן אחזור או הפסקות קצרות).

Protected Audience API (לשעבר FLEDGE)

נושא משוב	סיכום	התגובה של Chrome
גזירה	חוסר בהירות לגבי האופן שבו פלטפורמות SSP יוצרות בידול במכרז החדש.	קיבלנו משוב על כמה תוכניות אסטרטגיות שבהן Protected Audience ו/או ממשקי API אחרים של ארגז החול לפרטיות מופיעים במרכז. תמונה גדולה יותר: בהרבה מקרים, צמצום המזהים באתרים שונים נתפס מבחינת הצד המוכר של הסביבה העסקית כשלב חיובי לא רק מבחינת הפרטיות, אלא גם מבחינה מסחרית. עסקים קטנים וגדולים שמטמיעים את השינוי הזה צפויים למצוא הזדמנויות חדשות.
הצגת מודעות	Chrome הוא הדרך היחידה להצגת מודעות חוסכת חדשנות. עיבוד של 'קהל מוגן' מפחית את היעילות של הסטנדרטים המקובלים כיום בכל הנוגע לפרסום מותאם.	עיבוד מודעות בדפדפנים תמיד השתמש בטכנולוגיות של הדפדפן לעיבוד. זה לא משתנה. אולי הבעיה הזו קשורה ספציפית לתוכניות שמצריכות שימוש ב-Fenced Frames יחד עם Protected Audience בעתיד. אחת הסיבות לכך שהתוכניות האלה הן "בעתיד" היא בדיוק הסיבה שאנחנו רוצים שטכנולוגיית Fenced Frames תתמוך בחדשנות וביצירת סביבה עסקית בכל הנוגע להצגת מודעות. למפתחים ולחברות יש זמן לשקול את הכיוון של Fenced Frames, כולל האופן שבו ניתן לתמוך בגישות של מודעות מותאמות.
קלט	עד שטכנולוגיות פרסום רבות התחילו לחקור את ממשקי ה-API של ארגז החול לפרטיות, החוויה של Concrn Protected Audience API (PA API) הושלמה פחות או יותר.	ממשקי ה-API ימשיכו להתפתח על סמך המסקנות שאנחנו לומדים מהשימוש, וגם על סמך רעיונות חדשים שמגיעים מ-Chrome ומחוצה לו. ממשקי ה-API של המדידה והרלוונטיות שקיימים כיום יציבים, אבל הפיתוח לא מעיד על כך שהפיתוח הופסק, ונשמח לקבל משוב נוסף.
עיצוב מכירה פומבית	העיצוב של Protected Audience API מציב את כל הלוגיקה של יצירת הקהלים ובחירת המודעות בידי הפלטפורמה בצד הרכישה. כך, פלטפורמת SSP לא יכולה להציע לוגיקה ליצירת קהלים ולבחירת מודעות בקמפיינים שמופעלים בפלטפורמה שלה.	ההגדרה 'קהל מוגן' לא מזהה מי יוצר קהלים ומי מגיש הצעות מחיר לקהלים. SSP יכול ליצור קבוצת תחומי עניין (IG) שזמינה לבידינג. SSP יכול גם לספק לוגיקה של בידינג, שנראה תואמת להנחיות שספקי SSP רבים פונים ישירות לסוכנויות. תמיד יש מקום לתרחישים נוספים לדוגמה, אבל היסודות של Protected Audience API גמישים מספיק כדי לתמוך בגישות שונות ליצירה ולהפעלה של קהלים. המשמעות של מאפייני הפרטיות של היסודות האלה היא גם שנתונים גולמיים ברמת המשתמש לא משותפים בין אתרים.
עיצוב מכירה פומבית	האם המכרז של Protected Audience פועל בניגוד למאמצים לאופטימיזציה של נתיב האספקה של הסביבה העסקית (SPO) כדי לצמצם את המספר הכולל של מתווכים בין המפרסם לבין בעל התוכן הדיגיטלי, ו/או כפילות של הזדמנות נתונה להצגת מודעה?	לא. אם הקונה יוצר שילוב ישיר עם בעל התוכן הדיגיטלי, מודעה זוכה ב-Protected Audience API תוצג לכל היותר בשתי ישויות של מוכרים (למשל, SSP ושרת מודעות של בעל תוכן דיגיטלי). בעלי האפליקציות עדיין יכולים להחליט לגבי כפילות של אותה בקשה דרך כמה מתווכים. אין להשפיע על 'קהל מוגן' בדרך זו או אחרת. מכרזים של Protected Audience API מתקיימים מחוץ למערכת של זמן אמת משרת-לשרת, כדי לא להדליף נתוני משתמשים מאתרים שונים. בחלקם עשויים להיות שכפולים של בקשה להצגת מודעה. כדי לאפשר הוכחה טכנית לפרטיות, נדרש פשרות מסוימות. עם זאת, ייתכן שבטווח הארוך הסביבה העסקית תחליט להשתמש ב-Protected Audience API ללא מכרזים מסורתיים בצד השרת. בחירה באפשרות הזו יכולה להוביל לאופטימיזציה נוספת של נתיבי האספקה.
עיצוב מכירה פומבית	'קהל מוגן' עובר למודל שבו פלטפורמות SSP הן רק לעיתים רחוקות המכרז 'האחרון' שמופעלת בדף, אבל אוכפים את המודל הזה על ידי תכנון ה-API.	אנחנו לא מסכימים. בהטמעות המוקדמות שראינו בפועל, פלטפורמות SSP שמשתתפים במכרזים של רכיבים יכולות לגבור על התפוקה של המכרז לפי הקשר, שמתרחש לפני שהמכרז של Protected Audience פועל. פלטים של מכרזים של רכיבי SSP ב-Protected Audience API נחשבים אחרונים אחרי סיום מכרז מלא לפי הקשר.
עיצוב מכירה פומבית	מכרז לפי הקשר יכול להיות רלוונטי רק כדי לספק אותות נתונים לגבי ההזדמנות במכרז לעדכון 'קהל מוגן'.	אנחנו צופים שמכרזים לפי הקשר ימשיכו להיות רלוונטיים מסיבות שונות, כמו מבצעים, קמפיינים שמטורגטים לפי קהל שלא מאינטראקציה ישירה, ועוד המון תרחישים לפי הקשר. ההשוואה הזו מועילה גם כאשר אין IGs או שהצעות המחיר ב-Protected Audience API לא מגיעות לערכי סף תחתון או כאשר הן לא מצייתות לכללי איכות המודעות.
עיצוב התנועה	ספקי DSP פועלים ב-QPS קבוע. התאמת מכרזים של 'קהל מוגן' תצמצם את התועלת של תשתית מדור קודם.	למיטב הבנתנו, הדבר משתנה ביחס לשאילתות לשנייה הוא שספקי SSP רבים משתמשים במזהים בין אתרים כתכונה שניתנת לקביעה אם לשלוח בקשה מסוג DSP או לא. הדבר נכון בין אם בעל האפליקציה רוצה להפעיל מכרז של Protected Audience API או לא. בדקנו את תכנון התנועה עם פלטפורמות SSP רבות ומצאנו פתרונות, כולל שמירה במטמון וסינון מבוסס-הקשר. עם הזמן, אנחנו צופים שמפתחים ינצלו את תכונת צבירת הנתונים הפרטית כדי לסייע טוב יותר בהבנת העדפות הבידינג של DSP ולסנן בהתאם. בסופו של דבר, חלק מהתשתית מהדור הקודם שמבוססת על מזהים באתרים שונים לא תהיה יעילה יותר.
האותות הזמינים	אי בהירות לגבי המגוון המלא של האותות הזמינים כשמתקיימים מכרזים, ואיך ההסדר עם המכרז לפי הקשר פוגע בכך.	באופן כללי, למגישי הצעות המחיר ניתן לקבל מידע בזמן יצירת ה-IG, ממכרז לפי הקשר ומחיפוש ערך מפתח בזמן אמת. עבור ניקוד, מידע יכול להיות מסופק כאשר המכרז מוגדר, כולל מידע הקשרי על הדף ועל המכרז לפי הקשר, וכן מחיפוש ערך מפתח בזמן אמת ב-renderUrls של מודעות.
(דווח ברבעונים קודמים) רינדור הסרטונים	תמיכה בעיבוד וידאו באמצעות Protected Audience ו-Fenced Frames.	התשובה שלנו לא השתנתה לעומת הרבעונים הקודמים: "Protected Audience API תומך בעיבוד וידאו באמצעות מנגנון שמסתמך על iframes. עם זאת, עדיין לא פיתחנו פתרון שתואם ל-Fenced Frames, וזאת אחת מהסיבות שבגללן החלטנו לדחות את האכיפה של Fenced Frames לשנת 2026. כלומר, אם שותף מחליט לאכוף עכשיו את Fenced Frames, אותו שותף לא יתמוך יותר בסרטון."
רינדור וידאו	התמיכה של PA API לווידאו ב-iframes מוגבלת לסרטונים בפורמט HTML5, ולא תומכת בתקן VAST הנפוץ בשימוש.	ניתן להטמיע מודעות המבוססות על VAST באמצעות מנגנון העיבוד של iframe שזמין כיום ב-Protected Audience API. Google מכירה בכך שנדרשת הנדסה חדשה מצד הקונים, המוכרים ופלטפורמות הפרסום לבעלי תוכן דיגיטלי, ונמשיך לפעול כדי להקל על המעבר מאופן הפעולה הקודם של VAST.
(דווח ברבעונים קודמים) מכרזים ברמה העליונה	יכולת להשתמש בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי להעניק ל-Google Ad Manager שליטה במכרז ברמה העליונה של PA API.	התגובה שלנו לא השתנתה לעומת הרבעונים הקודמים: "התשובה סופקה על ידי Google Ad Manager: התוכניות של Google Ad Manager עבור Protected Audience API לא כוללות תמיכה בשרת המודעות של Google לבעלי תוכן דיגיטלי ללא שליטה במכרז של Protected Audience API, מהסיבות הבאות. כדי להציג ללקוחות שלנו כראוי את השוק להצגת מודעות של בעלי תוכן דיגיטלי, שרת המודעות של Google לבעלי תוכן דיגיטלי צריך לשלוט במכרז של Protected Audience ברמה העליונה. כשרתי מודעות של בעלי תוכן דיגיטלי, התפקיד שלנו הוא לספק לבעלי תוכן דיגיטלי תחזיות כדי שיוכלו לנהל משא ומתן לגבי קמפיינים במכירה ישירה בלי להזמין יתר, וכדי להתאים את קצב ההזמנות הישירות שלהם בצורה אופטימלית. כדי לעשות זאת, צריך להריץ את המכרז הסופי כדי להשוות בין כל הביקושים הישירים והעקיפים הכשירים. יצירת תחזית וקצב ניצול הם הפונקציות העיקריות שבעלי התוכן הדיגיטלי מצפים לקבל משרת מודעות. בלי חיזוי מדויק, בעלי תוכן דיגיטלי עלולים למכור יותר מדי מלאי שטחי הפרסום שלהם, וזה יסכן את המוניטין העסקי שלהם. גם קצב הפרסום של המודעות הוא קריטי, כי אי אפשר למלא הסכמי הזמנה עם מפרסמים גם בסיכון ליחסים הישירים בין בעל התוכן הדיגיטלי לבין המפרסם, ויכול להיות שתהיה לכך השפעה משמעותית על הפעילות העסקית של בעלי התוכן הדיגיטלי. לכן, אנחנו לא מתייחסים לפעילות של שרת מודעות של בעל תוכן דיגיטלי להפעלת המכרז של Protected Audience ברמה העליונה, כשהפעילות שלו שונה מפעילויות אחרות של שרת המודעות של בעל התוכן הדיגיטלי."
(דווח ברבעונים קודמים) directFrom SellerSignals	DirectFromSellerSignals מאפשר ל-Google Ad Manager למנוע לבעל התוכן הדיגיטלי לראות את המחיר של המכרז לפי ההקשר.	התשובה שלנו לא השתנתה לעומת הרבעונים הקודמים: "התשובה של Chrome: לא ידוע כי המידע שמועבר אל runAdAuction() מגיע מהמפיץ, אלא אם בית העסק קורא ל-runAdAuction() מה-iframe שלו. במכרז עם כמה אתרי מכירה, כל המוכרים לא יכולים ליצור את המסגרת שקוראת ל-runAdAuction(). DirectFromSellerSignals יטפל בבעיה הזו על ידי טעינת תוכן מחבילה של משאבי משנה שנטענה ממקור של אתר מכירה. כך אפשר להבטיח שהאותנטיות והמהימנות של המידע שמועבר במכרז מההגדרות של המכרזים של אתרי המכירה לא ניתנות לשינוי. אם בעלי תוכן דיגיטלי רוצים להשתמש ב-Protected Audience API כדי להבין מידע כלשהו שספקי הטכנולוגיה שלהם מעבירים למכרזים של Protected Audience, הם יכולים לבקש מספקי הטכנולוגיה האלה את הפונקציונליות הזו. התשובה סופקה על ידי Google Ad Manager: הקפידנו במשך שנים על הוגנות במכרזים, כולל הבטחנו ששום מחיר ממקורות פרסום לא מובטחים של בעלי תוכן דיגיטלי, כולל מחירים לא מובטחים של פריטים, לא ישותף עם קונה אחר לפני שהוא יגיש הצעת מחיר במכרז. לאחר מכן, אישרנו מחדש במסגרת ההתחייבויות שלנו למכרז בצרפת. במכרזים עם Protected Audience API, אנחנו מתכוונים לפעול בהתאם להבטחה שלנו באמצעות DirectFromSellerSignals, ולא לשתף את הצעת המחיר של משתתף כלשהו במכרז עם משתתפים אחרים במכרז לפני השלמת המכרז במכרזים עם כמה אתרי מכירה. חשוב להבהיר: אנחנו לא משתפים את המחיר של המכרז לפי הקשר גם עם המכרז שממנו אנחנו מרכיבים את המוצר, כמו שמוסבר בעדכון הזה."
(דווח ברבעונים קודמים) ערך K-anonymity	איך ייקבע הערך 'K' ל-'k-anon' ומתי הוא יפורסם?	פרסמנו את הערך של K-anonymity בדצמבר 2023. אחרי שיתחיל תהליך ה-3PCD, נעלה את סף k-anonymity לערך הסופי של 50 (k=50) ונגדיר את תקופת העדכון לשעה אחת (p=1). ערך האנונימיות K של 50 הוערך כמספק איזון אופטימלי בין תועלת לפרטיות. הערך הזה מספיק כדי לסכל התקפות בוטים בסיסיות ולשמור על פרטיות דיפרנציאלית, אבל גם נמוך מספיק כדי שה-API ימשיך להיות שימושי בתרחישי השימוש הרצויים.
(דווח ברבעונים קודמים) ב-DebuggingOnly	פוטנציאל לשימוש לרעה ב-forDebuggingOnly.reportAdAuctionWin אם הוא יישאר אחרי 3PCD.	כאן שיתפנו את ההצעה שלנו לגבי האופן שבו אפשר להמשיך לתמוך בתרחישים לדוגמה לשימוש בניפוי באגים לאורך זמן. נשמח לקבל משוב נוסף לגבי ההצעה.
(דווח ברבעונים קודמים) מדיניות מקור זהה	בקשה להקל על מדיניות המקור הזהה כדי לאפשר הפעלת תת-דומיינים.	הבקשה הזו נמצאת בבדיקה והסברנו אותה כאן.
(דווח ברבעונים קודמים) גודל רכיב המודעה	יש להגדיל את מספר רכיבי המודעה מ-20 ל-40.	דנו בבקשה הזו במהלך השיחה עם WICG ב-4 באוקטובר ובבעיה הזו ב-GitHub. אנחנו מתכננים לטפל בה עד סוף הרבעון הראשון של 2024.
(דווח ברבעונים קודמים) תפוגת התוקף של מפתח שרת ערך המפתח	דיון על הסרת מפתחות שרת לאחר תפוגת ה-IGs המתאימים.	כדי לנהל את תהליך ה-TTL עדיף לא בסביבת TEE, אלא נשמח לקבל משוב נוסף כאן.
טריגרים של קבוצת תחומי עניין	האם IG יחיד יכול להפעיל מספר generateBids במכרז (רכיבי) יחיד?	בכל פעם שהדפדפן קורא לפונקציה generateBid() של IG, ה-IG הזה מורשה להחזיר ערך של הצעת מחיר. לדוגמה, יכול להיות שבמכרז עם כמה אתרי מכירה, IG נקרא כמה פעמים, בכל פעם באחד מהמכרזים שמרכיבים אותו. הבעלים של ה-IG לא צריכים לעשות שום דבר כדי להפעיל או לתמוך בהתנהגות הזו.
שאלות בנושא תאימות	מה היקף ההסכמה שנאסף דרך דפדפן Chrome של המשתמש?	לקבלת פרטים, ניתן לעיין בקטע 'מה הגישה של 'ארגז החול לפרטיות' לעמידה בדרישות בנושא פרטיות ב-Chrome?' שבדף שאלות נפוצות בנושא תאימות לפרטיות.
מכירות פומביות של ריבוי תגים	איך אפשר להשתתף במכרזים עם כמה תגים?	אנחנו בודקים את הבקשה ונשמח לקבל משוב נוסף כאן.
זמינות להגנה על כתובות IP	מה ההשפעה על לוחות הזמנים של התכונות Protected Audience, כמו אכיפה של Fence Frame והסרה או הסרה של דיווח ברמת האירוע, אם ההגנה על ה-IP לא מוכנה עד לתאריכים שצוינו?	כפי שצוין כאן, אנחנו מאמינים שצריך לקשר את לוחות הזמנים של Protected Audience ללוחות הזמנים להשקה של תכונות אחרות להגנה על פרטיות.
modelingSignals	אפשר לבקש שדה חדש בנוסף ל-ModelSignals, שאפשר לקודד רק מידע על תצוגה וקליקים.	אנחנו מבינים את התועלת שבתהליך הזה ומעריכים את הבקשה, ונשמח לקבל משוב נוסף כאן.
IG שלילי	האם ניתן לאפשר ל-IG רגיל לציין שם IG שלילי?	בשלב הזה לא ניתן לעשות זאת על פי הודעת ההסבר, אבל נשמח לקבל משוב נוסף על הסביבה העסקית שמסבירה למה הדרישה הזו רלוונטית.
שימוש ב-API	יצירת דוח מצטבר ברמת generateBid()	ניתן להפעיל צבירה פרטית בתוך createBid.
פקודות מאקרו	נתב אותות מ-perBuyerSignals באמצעות פקודות מאקרו ב-IFrame אל צד שלישי.	כאן נדון בתרחיש לדוגמה הזה, ונשמח לקבל משוב נוסף.
שימוש ב-API	אם מחזירים שגיאת אחזור של אותות דירוג מהימנים, האם עדיין תתבצע קריאה ל-ScoreAd() ?	ScoreAd() עדיין אמורה לפעול אם קריאת האחזור לא הצליחה.
שימוש ב-API	כתיבת מטא-נתונים.shard_num בקובצי riegeli עבור קובצי delta/snapshot.	אנחנו מוסיפים עכשיו תמיכה ב-shard_num כדי לבטל את החסימה. ריגלי לא מאומץ באותה מידה כמו אברו, לדוגמה, אבל לא נוטשים אותו. מכיוון שבתוכנית TEE יש הרבה יותר אילוצים ותקורה, החלטנו לתת עדיפות לביצועים על פני חוויית המשתמש. אנחנו שוקלים לספק שירות gRPC כדי ליצור קבצים מבקשות. אנחנו עשויים גם להעריך פורמטים אחרים כמו Avro לגבי ההשפעה שלהם על הביצועים.
בדיקת API	איך PA API ו-Measurement APIs תומכים בבדיקות מצטברות?	בארגז החול לפרטיות אין אפשרות למדוד המרות מצטברות באמצעות מכרזים מנוגדים בפועל. אתם יכולים להשתמש באחסון משותף ובצבירה פרטית, אבל הפעולה הנגדית תהיה רק אחרי המכרז.
שימוש ב-API	האם השימוש ב-BidWasmHelperURL לעדכונים יומיים משפיע על סף k-anonymity?	מכיוון ש k-anonymity כבר לא נכללת בעדכוני IG, ניתן לעדכן את BiddingWasmHelperURL בלי להשפיע על הסף.
שימוש ב-API	האם אנחנו יכולים לקבל התראות על שגיאה של PA API?	נשמח לקבל משוב מהסביבה העסקית לגבי סוג הודעות השגיאה שיידרשו להם כדי לפתור בעיות ב-PA API.
גדלים של מודעות	גדלים של מודעות לא מוצגים במכרז או בדיווח.	אנחנו מטפלים בבעיה בבקשת המשיכה הזו.
שימוש ב-API	האם נדרשת קריאה לנקודת הקצה לעדכון של IG עבור ה-IG אם היא לא משתתפת במכרז הזה?	כן. ה-UpdateURL נקרא עבור כל ה-IG של בעלים נתון, גם אם הם לא הגישו הצעת מחיר באותו מכרז. הדרישות היחידות הן: - הבעלים חייב להיכלל במכרז נתון (כלומר, להיכלל כקונה ב-AuctionConfig) - אסור ש-interestGroup של הבעלים הנתון עודכן ב-24 השעות האחרונות.
הצעת מחיר מוקדמת ב-PA API	איזו גרסה של Prebid.js תידרש בשלב הבדיקה?	לפי המסמכים הטכניים שלנו, הגרסה צריכה להיות 8.9.0 ומעלה.
הפעלה של נתונים מאינטראקציה ישירה (First-Party) ב-PA API	איך הם יכולים להפעיל נתונים מאינטראקציה ישירה (First-Party) משלהם כדי להגדיר את ה-IG ולהשתמש בו?	אפשר להשתמש ב'הקצאת הרשאות' וב'קבוצות אינטרס שליליות' במשימה הזו.
PA API ותיוג בצד השרת	איך PA API פועל עם תיוג בצד השרת?	תג הבסיס בדפדפן של המשתמש צריך להפנות את הקריאה ל-API לשאר התגים בצד השרת, וכך גם הוא יוכל לרשום את הקריאה.
בדיקה של Chrome (מצב a/b)	האם הציפייה שפלטפורמות SSP יעבירו את התוויות האלה גם בבקשות להצעות מחיר בזמן אמת (RTB), ואם כן, איך?	כן, הציפייה היא שהתוויות יועברו מ-SSP ל-DSP. אנחנו מעודדים ישויות לגשת לתווית ולשתף עם שותפים את הערך שלא השתנה באמצעות תוסף המכשיר הזה.
אחסון נתונים ושימוש בהם	האם יש לך מידע נוסף על אופן האחסון של הנתונים ולהיכן הנתונים מועברים?	לא נספק הכוונה משפטית אלא מעבר לגישה או לחשיבה הכללית שלנו בנוגע לאחסון נתונים, לשמירת נתונים ולנושאים אחרים הקשורים לפרטיות. כאן אפשר לעיין בשאלות נפוצות על תאימות למדיניות בנושא פרטיות.
בטיחות API	חששות לגבי קוד זדוני בצד הלקוח שמבצע מניפולציה של הערך המוחזר של הפונקציה generateBid() .	דנו בבעיה כאן , וחלק מהמשוב שלך שולב בהצעה של צבירה פרטית.
יעד מותאם אישית	כשמשתמשים בקריאות ל-ReportEvent של יעד מותאם אישית, האם במקרה כזה, ידוע לך אם מקור דיווח בהתאמה אישית (לא לקונה או למוכר) נרשם מראש כחלק מ-IG ב-AllowReportingOrigins, וצריך להצהיר עליו על ידי פלטפורמת ה-DSP ב-reportWin באמצעות registerAdBeacon?	לא, אין צורך לרשום אותו שוב ב-reportWin וניתן להשתמש בו ישירות ב-reportEvent, לפי התיעוד כאן.
הגבלות על ממשקי API	גודל IG במהלך היצירה והעדכון.	גודל העדכון עודכן ל-1MB, שתואם למכסה החדשה של 1MB (מ-50KB) ליצירת IG.
הגבלות K-anon	K-anon למודעות בגדלים שונים.	פרסמנו את ערך K-anonymity בדצמבר 2023 שלפיו נקבע שגודל המודעה K-anonymity יתחיל לבדוק את גודל המודעה 'מתישהו אחרי 2025'. אין דרך לעקוף את המידה כי הוא יכול להיות וקטור של מעקב באתרים שונים, כפי שמתואר בקריאה ל-WICG ב-11 באוקטובר.
בטיחות API	האם נגן זדוני יכול לזייף את 'שם המארח' של דף כלשהו?	ה-API תומך במפתח משנה שמוגדר לשם המארח של בעל האפליקציה. נראה שהדפדפן מגדיר את המפתח, ולכן קשה לעקוף את המנגנון הזה.
שימוש ב-API	לא מומלץ להשתמש בפונקציות ForDebuggingOnly בסביבת ייצור.	אנחנו עומדים לטעון בפני הסביבה העסקית שהפונקציות forDebuggingOnly אינן מתאימות בכלל, למעט פתרון בעיות לאחר 3PCD.
נדרשים עוד כלים לניפוי באגים	ForDebuggingOnly לא מאפשר לך להבין בעיות שעלולות להתרחש לפני ScoreAd().	אנחנו אוספים משוב נוסף על הפער הזה, ונשמח לקבל משוב נוסף כאן.
קבוצות אינטרס קבועה לביטול הצטרפות	בקשה שמאפשרת למשתמשים לבטל באופן קבוע את הסכמתם ליצירת IG מיוחד.	האסטרטגיה שלנו הייתה לא לאפשר למשתמשים לבטל את הסכמתם ברמת IG, כי הסמנטיקה לא מובנת למשתמשים כפי שהם.
שיפור התיעוד	צריך להשתמש באותיות רישיות באופן זהה לפרמטר generateUrls במפרט ובהסבר.	אנחנו מעריכים את המשוב ונמשיך לעדכן אותך במסמכי התיעוד.
תמיכה בעסקאות של Protected Audience	בקשה לאפשרויות נוספות עבור תמיכה בעסקה עבור Protected Audience.	צוות Chrome בוחן כרגע מה נוכל לעשות כדי לתמוך בכך באמצעות 3PCD.
פקודות מאקרו	נדרשת תמיכת מאקרו כדי לשמור על הגודל של IG מתחת לגודל IG מקסימלי.	עדכון שבוצע לאחרונה בהסבר התייחס לבקשה הזו באופן חלקי.
API של ReportLoss ברמת האירוע	בקשה ל-ReportLoss API ברמת האירוע.	דוחות אובדן ברמת האירוע מכילים סיכון חמור לפרטיות, אבל אנחנו מאמינים שבמקום זאת, אפשר להשיג את היעדים הבסיסיים של הבקשה הזו בעזרת שינויים מתאימים ב-Private Aggregation API. נשמח לקבל ממך משוב נוסף כאן.
שימוש ב-API	איך שיטות forDebuggingOnly פועלות אם הציון של הצעת המחיר לא גבוה מ-0?	אם הציון נמוך מ-0, אז זהו אובדן אוטומטי. לכן, reportAdAuctionloss יופעל.
תקינה	אין התאמה בין המשתמשים של PA API generateBid() בערך הקלט/פלט של הפונקציה.	אנחנו ממליצים לכל השותפים להעלות את הבעיה הזו (או דומה) ל-IAB Tech Lab. הקבוצה הזו עובדת באופן ספציפי על התקנים המקובלים בתחום לממשקי API כמו Protected Audience.
בטיחות API	אילו נתונים מבדיקות IG שלנו יכולה Google לראות?	'אנונימיות K' מסתמכת על אמצעי הגנה חזקים על פרטיות כדי למנוע הדלפה של מידע אישי רגיש של משתמשים לכל גורם, כולל Google. Google גם מפתחת הטמעה של צד שלישי (במהירות) כדי למזער את הסיכון הזה.
בדיקה של Chrome (מצב a/b)	האם ניתן להחריג משתמשים מוגבלים מסוג 'k-anon' מהבדיקה?	אנחנו חושפים את סטטוס האנונימיות של k בדוחות, כמו שמוסבר כאן.
הגנה על המותג	תמיכה בהגנת המותג בתרחישים לדוגמה שבהם המודעות לא מוצגות, בהתאם לרשימת מילות המפתח או האתרים החסומים.	תרחישים לדוגמה כאלה להגנה על המותג אמורים להיות זמינים כבר באמצעות PA API. כדי שקמפיין הפרסום יטרגט באופן שלילי קבוצה מסוימת של דומיינים, הם יכולים לשמור את רשימת החסימה של הדומיינים ב-IG עצמו, אולי באמצעות מסנן Bloom אם כל אחד מהם יתפוס יותר מדי מקום. לחלופין, הם יכולים להחזיר את ההחלטה של אישור או דחייה משרת ערך המפתח שלהם, באמצעות UDF שמחפש את התשובה על סמך השילוב של המפתח שמזהה את קמפיין הפרסום ושם הדומיין שנכלל בבקשה 'ערך מפתח'. Protected Audience API גם מאפשר ל-SSP וגם ל-DSP להעביר למכרז כל מידע לגבי ההקשר של הדף. לדוגמה, אתם יכולים לכלול בדף רשימת נושאים או מילות מפתח רגישים. לוגיקת הבידינג של פלטפורמת ה-DSP יכולה להשוות בין מידע זה לבין כל מידע שנשמר לגבי המקומות שבהם אין להציג את המודעה, ולבחור לא להגיש הצעת מחיר במקרים הרלוונטיים. נשמח לקבל משוב מהסביבה העסקית על כל תרחישי שימוש ספציפיים שלדעתה הם לא אפשריים.
הענקת הרשאות	איך פועלת האצלת ההרשאות?	שיתפנו כאן תיעוד לגבי האצלת הרשאות.
בקשות באצווה	יש להשתמש בבקשת POST לחלק מכתובות ה-URL של PA API כדי לתמוך ב'בקשת אצווה'.	אנחנו מקבלים בברכה את ההצעה ומקבלים נשמח לקבל ממך משוב נוסף כאן.
שיפור ה-API	שדות שכדאי לא להשתמש בהם (למשל X-fledge-bidding-signals-format-version).	אנחנו דנים בנושא, ונשמח לקבל משוב נוסף כאן.
שיפור ה-API	בקשה להעברת הסכמה בהתאם ל-GDPR לספקי צד שלישי של פרסום מודעות ומדידת ביצועים.	הפונקציונליות הזו נתמכת באמצעות ממשק ה-API להחלפת מאקרו של החלפת המאקרו שהוצא משימוש, כפי שמוסבר כאן.
אופטימיזציה של קריאייטיב דינמי	איך Protected Audience תומך באופטימיזציה של נכסי קריאייטיב דינמיים?	אנחנו דנים בתרחיש לדוגמה הזה ושיתפנו פתרונות פוטנציאליים כאן.
שיפור ה-API	בקשה לכך שכתובת URL להצגת מודעות של צד שלישי תוכל לקבל הקשר IG ובעיקר שם IG שתואם ל-IG שזכה במכרז.	בקשות כאלה עשויות להגביר את סיכוני המעקב של משתמשים. אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן.
בטיחות API	יש לך חשש שגודל של "IG blob" יגרום לדליפה של מידע לגבי ה-IG שנבחרו.	כפי שצוין בסעיף שיקולי הפרטיות בהסבר של Chrome B&A API, גודל ה-blob לא תלוי בקלט של navigator.getInterestGroupAdAuctionData(). הוא כולל רק את כל ה-IGs במכשיר. ההגדרה הזו מבטיחה שגודל ה-blob יהיה עקבי יחסית בדף ומוגבל את היכולת להדליף מידע בין אתרים. עיצבנו אותו כך, בדיוק מהסיבה הזו.
בדיקה של Chrome (מצב a/b)	מה העמדה של פלטפורמות SSP אחרות לגבי החמצה של הטעינה הראשונה ביחס להגדרת קובצי cookie ובדיקות שמתבצעת באמצעות Chrome?	לא שמענו חששות משמעותיים (למרות שאחרים הכירו במצב זה), אבל נשמח לקבל משוב על הסביבה העסקית אם מדובר בבעיה משמעותית.
תמיכה בבדיקות A/B	בקשת תמיכה בבדיקות A/B של PA API.	טיפלנו בבקשה הזו בפגישה של WICG בנובמבר, ונשמח לקבל משוב נוסף כאן.
גדלים של מודעות	מי בוחר את גודל המכרז של 'קהל מוגן'?	יש תשובה לשאלה הזו בשאלות הנפוצות האלה.
שיפור ה-API	צריך לבקש להגדיר את שירות המפתח/ערך כך שיקבל את הנתיב /bidding-signals/v1/getvalues.	הוספנו קידומות לנתיבי תמיכה לבקשת המשיכה הזו.
שימוש ב-API	כיצד יכול בעל אתר ליצור IG עם הקוד שלו אם הוא אמור להיות בבסיס של המפרסם, כדי שהמפרסם יוכל להגיש עליו הצעת מחיר?	התשובות חייבות להגיע משותף פרסום דיגיטלי כלשהו – DSP או SSP שרוצה להשתתף במכרזים של Protected Audience ובונה דרך ליצירת קהלים האלה להגיע ממקור חיצוני. דיברנו על כך בבעיה הזו ב-GitHub.
שיפור ה-API	בקשה לאפשרות לקשר IG שלילי למודעות ב "קבוצות בעלות עניין חיובי".	אנחנו שוקלים את הבקשה הזו ומשתפים כאן הצעה בנוגע לתמיכה שבה.
מספר הפיצולים	בקשת תמיכה בהעברת 'תמיכת shard_num' במטא-נתונים.	בעקבות המשוב הזה, הוספנו תמיכה ב-shard_num.
שימוש ב-API	בקשה להערכת תקורה של מפתחות בשרת K/V.	שיתפנו את המשוב שלנו ונשמח לקבל ממך משוב נוסף כאן.
אנונימיות-K	בקשה להבהרה ושיפור של רמת הפירוט של המונה K-Anonymity.	כאן יש לנו הבהרה לגבי רמת הפירוט של המונה K-Anonymity.
ניפוי באגים	בקשה לשיפור יכולות ניפוי הבאגים של PA API בעקבות השינויים שהוצעו לאחרונה ב-forDebuggingOnly.	אנחנו דנים בבקשה כאן ונשמח לקבל משוב נוסף כאן.
גודל מודעה	בקשה לשינוי הגודל של מיקום המודעה כאות BTS נוסף.	שיתפנו הצעה לתמיכה בבקשה הזו, ונשמח לקבל משוב נוסף כאן.
בטיחות API	האם אפשר להגביל את השימוש ב-"runAdAuction()" לפי מקור?	כאן שיתפנו תשובה מפורטת.
משך החיים של IG	בקשה להארכת משך החיים של IG מ-30 ל-90 יום.	אנחנו שוקלים את הבקשה, ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	האם אפשר להפעיל מכרז של Protected Audience API במקביל להפעלת בידינג ב-header ובקריאה של שרת המודעות של בעל התוכן הדיגיטלי?	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.
ניפוי באגים	בקשה לתמיכה טובה יותר בתוספים לניפוי באגים ב-Chrome PA API הקשורים לכלי הפיתוח.	אנחנו תומכים במתן כלים נוספים לניפוי באגים, ונשמח להציע הצעות נוספות כאן.
שימוש ב-API	התראות על הפסדים לא מופעלות אם לא התקבלו הצעות מחיר מאתרי המכירה שמרכיבים את הקמפיין.	כאן הסברנו את הנימוק.
שיפור ה-API	בקשה לתמיכה ב-TextEncoder ב-worklet של Protected Audience API.	אנחנו בוחנים את הבקשה ושולחים משוב נוסף כאן.
שימוש ב-API	קריאות לרשת והפעלה של לוגיקה בלקוח יכולים לחסום את ה-thread הראשי ולגרום לאתגרים בביצוע JS שיכולים להשפיע על ה-SEO.	אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	האם פלטפורמות DSP יכולות להשתמש במשפך הבידינג הנוכחי שלהן בצד השרת כדי להעריך ולשלוח את המועמדים למודעות כחלק מ-PerBuyerSignal, לשימוש במכרזים במכשיר?	אנחנו דנים בשאלה הזו ונשמח לקבל משוב נוסף כאן.
הרחבת הנתונים של הזדמנויות להצעות מחיר	בקשה להרחבת הנתונים של ההזדמנויות להצעות מחיר שהועברו על ידי הדפדפן ל-SSP עם רשימה של דומיינים מקור ייחודיים של ה-IG הפעילים בדפדפן.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.
ORTB	בקשה לשני קטעי הוק (hooks) חדשים ל-AuctionConfig וליצירת התאמה של תגובות להצעות מחיר ב-ORTB.	אנחנו בודקים את הבעיה הזו ונשמח לקבל משוב נוסף כאן.
הניצחון הקודם	בקשה ש-IG יגדירו "prevWinsTransformer", שלוקח את הזכיות הקודמות של ה-IG ומפיק דבר שניתן בסדרה.	אנחנו בודקים את הבעיה הזו ונשמח לקבל משוב נוסף כאן.
סוגי תוכן	אסטרטגיה להתפתחות של סוגי תוכן, למשל JSON למשהו כמו CBOR.	אנחנו בודקים את הבעיה הזו ונשמח לקבל משוב נוסף כאן.
הצעת מחיר מוקדמת ב-Protected Audience API	בקשה לדף של בעל תוכן דיגיטלי לדוגמה שנעשה בו שימוש בהצעת מחיר מוקדמת כדי להפעיל תהליך מקצה לקצה במכרז של 'קהל מוגן'.	אנחנו שוקלים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית כדי להבין למה צריך לתעדף את הבקשה. ראינו גם משתתפים בסביבה העסקית שיצרו דפים לדוגמה של בעלי תוכן דיגיטלי, שזמינים להדגים למשתמשים אחרים בסביבה העסקית.

שירותי מכירות פומביות מוגנים

נושא משוב	סיכום	התגובה של Chrome
סביבות ביצוע מהימנות (TEEs)	יקר יותר להפעיל סביבות ביצוע מהימנות בעננים ציבוריים, לעומת מרכזי נתונים של טכנולוגיות פרסום מקומיות?	מודל האבטחה הנוכחי של סביבת ה-TEE שלנו מנצל את השיטות של הטמעת ענן ציבורי. באופן ספציפי, סביבת TEE מבוססת-חומרה אינה מגינה מפני כל ההתקפות הפיזיות. ספקי שירותי הענן הציבוריים הקיימים שלנו, AWS ו-GCP, תכננו והטמעו הקלות בסיכוני גישה פיזית, כולל מיטיגציות מצד עובדים. פרטים נוספים זמינים בהמשך לגבי תמיכה מקומית. ספקי טכנולוגיות פרסום ציינו שהפעלה של שירותי ענן יקרה יותר ממרכזי נתונים של טכנולוגיות פרסום מקומיות. אמנם אין לנו אפשרות להעריך הצהרות אלה, אבל נשמח לקבל עוד משוב על העלויות ולהמשיך לבחון את האפשרויות להרחבת התמיכה בסביבת TEE.
(דווח ברבעונים קודמים) שירותי TEE מקומיים	מהן הדרישות כדי להפוך לספק TEE?	התגובה שלנו דומה לרבעונים הקודמים: "למרות שאנחנו ממשיכים לחקור את התמיכה באפשרויות מעבר לפתרונות ציבוריים מבוססי-ענן, אנחנו שוקלים את האפשרות לקבוע אילו פריסות יהיו קבילות מנקודת מבט של אבטחה, אבל אין לנו כרגע תוכניות לתמוך בסביבת TEE מקומית. בשלב הזה, בהתחשב בדרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שנובעים מפריסות מקומיות, אנחנו מאמינים שהמשך ההרחבה והשיפור של פריסות מבוססות-ענן הוא המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל משוב נוסף לגבי הסיבה שדרישה כזו היא הצורך והאפשרי בהתחשב במגבלות הפרטיות והאבטחה."
מגבלות של שרת מפתח/ערך	מגבלות המפתחות לכל מכרז לכל שרת	אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן.
הגבלות K-anon	אישור שאנונימיות K לא תיאכף בעתיד במפתחות K/V.	כרגע אין לנו תוכניות לאכוף k-anon במפתחות של בקשות שרת K/V מאחר שאנחנו מתכננים להעביר שרתי K/V ל-TEE בעתיד.
שירות K/V לבניין	האם ל-Google יש פריטי מידע שנוצרו מראש עבור שירות ה-K/V?	בשלב זה אין לנו פריטי מידע שנוצרו מראש עבור שרת המפתח/ערך של Protected Audience API, אבל יכול להיות שנשקול לספק אותם אם יהיה ביקוש גבוה לכך מהסביבה העסקית.
תמיכה ב-EgId במדיניות B&A	בקשה לתמיכה בשדה testGroupId בקוד הבידינג והמכרז, ובבקשה לשירות KeyValue מ-BuyerFrontEnd	ל-B&A אין כרגע תמיכה במאפיין experimentGroupId, אבל המטרה שלנו היא להשיק אותו עד שלב בטא 2 (נכון לעכשיו, פברואר 2024). כאן שיתפנו מידע נוסף.
שימוש ב-API	איחוד בקשות ב-HTTP יכול לעזור בהגנה מפני תוקפים בנתיב, אבל המפעיל של סביבת ה-TEE ילמד את הגודל.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.
שיפור התיעוד	המפרט לא ברור כיצד יטופלו שרת ה-k-v.	אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	מה המטרה של "Ad-Auction-Results" ו-adAuctionHeaders?	כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שיפור התיעוד	לא ברור אם העיצוב של גרסה 2 הופץ אל FLEDGE.md.	במאמר FLEDGE.md מוסבר איך Chrome שולח בקשות אל BYOS-KV. עיצוב הפרוטוקול v2 מוגבל ל-TEE-KV בלבד ובשלב הזה הוא לא נתמך ב-Chrome.

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

Attribution Reporting (וממשקי API אחרים)

נושא משוב	סיכום	התגובה של Chrome
מדידה בסביבות שונות	איך Chrome מתכנן לתמוך במדידה בסביבות שונות בשלב הביניים שבו הוסרו מחשבים 3PC מ-Chrome לנייד, אבל ארגז החול לפרטיות ל-Android עדיין לא זמין?	בצד של Android, אנחנו עובדים על הרחבת הכיסוי של PSB/ARA – Attribution Reporting API (ARA) זמין ב-Android 13 ו-14, ואנחנו מתכננים להרחיב את הזמינות ל-Android 11 ו-12 בהמשך השנה, למרות שהדבר עשוי להשתנות. לא נוכל להרחיב את התכונה ל-Android מגרסה 10 ואילך, אבל אנחנו צופים שאחוז מכשירי Android שעדיין נמצאים ב-Android מגרסה 10 ומטה יהיה נמוך יותר ב-3PCD ויקטן באופן טבעי עם הזמן ככל שהמשתמשים משדרגים. נשמח לקבל משוב נוסף מהסביבה העסקית לגבי הבקשה הזו.
סינון	סינון של 'המרות' מסריקת קריאייטיבים.	פנינו לבעלי העניין האלה כדי להבין טוב יותר את הבקשה שלהם, ונשמח לקבל משוב נוסף מהסביבה העסקית בנושא הזה.
שרתי מודעות של צד שלישי	איך PA API ו-ARA פועלים עם תגים של שרת מודעות של צד שלישי?	בדומה לאופן שבו פיקסלים פועלים כיום עם תגי חשיפות וקליקים, שרת מודעות יכול להגדיר מקור ולהפעיל הרשמות ל-ARA באופן עצמאי (כולל ממכרזים של 'קהל מוגן'), או להגדיר הפניות אוטומטיות כדי להעביר ולאשר רישומים של מקור ולהפעיל הרשמות של ARA.
DCM	תמיכה ב-Attributionsrc על ידי DCM ושרתי מודעות אחרים של צד שלישי.	זו בעיה שקשורה ל-DCM, וצוות DCM טיפל בה בבעיה הזו ב-GitHub.
מפתח צבירה היררכי	האם יש צורך לפצל את כל תקציב התרומות לכל המפתחות ההיררכיים האלה?	שוחחנו עם בעל העניין הזה והחלטנו עליו. כשמשתמשים במבנה מפתחות היררכי, טכנולוגיית המודעות חייבת להביא בחשבון שתקציב התרומה משותף לכל הפלט של המפתחות של החשיפה.
שימוש בתת-דומיינים שונים	האם להפעיל את דיווח השיוך כך שיפעל עם מקורות וטריגרים הרשומים בתת-דומיינים שונים אבל אותו eTLD+1?	שוחחנו על השאלה הזו עם בעלי העניין והצענו את הפתרונות הבאים. הם יכולים לשנות את הגדרת כתובת ה-URL כך שמקור הדיווח יהיה זהה במקור ובטריגר, או להפנות את המשתמשים מכתובת ה-URL הנוכחית לכתובת URL משותפת, לפני ביצוע הרישום. נשמח לקבל משוב נוסף על הסביבה העסקית אם הפתרונות המוצעים לא מתאימים לתרחיש לדוגמה שלהם.
(דווח גם ברבעונים הקודמים) תמיכה בסביבת ייצור	אילו רמות שירות זמינות לתמיכה בשותפים שמשתמשים ב-ARA?	התגובה שלנו לא השתנתה ביחס לרבעונים הקודמים: "Google מספקת לטכנולוגיות פרסום מגוון ערוצים כדי לאפשר לטכנולוגיות הפרסום לדווח על בעיות טכניות ולאפשר את כל הפעולות הנדרשות לטיפול ברמה גבוהה יותר כדי לפתור בעיות כאלה. בנוסף, Chrome מצפה לפתח ולהתרחב תהליך חדש לפתרון בעיות טכניות והעברות לטיפול ברמה גבוהה יותר שמשפיעות על תקינות הסביבה העסקית. אנחנו ב-Chrome מחויבים להבטיח משאבים לצורך כך. בפוסט למפתחים מופיע מידע נוסף לגבי משוב והעברה לטיפול ברמה גבוהה יותר בפורומים הציבוריים והפרטיים.
(דווח גם ברבעונים הקודמים) ציר הזמן	האם Google תכין את 'שלב 2 מלא ברמת האירוע הגמישה' לפני תחילת הבדיקה הכמותית של CMA?	שלב 2 ברמת האירוע הגמישה המלאה צפוי להיות זמין ב-Chrome ברבעון הראשון של 2024. אפשר לעקוב אחרי הסטטוס כאן.
(דווח גם ברבעונים הקודמים) משפך ההמרות	דיווח על מספר דומיינים ששימשו להמרה.	התרחיש לדוגמה הזה אפשרי מכיוון שהוספתם כמה יעדים. נשמח לקבל משוב נוסף.
דיווח על תוויות בדיקה	האם יכולות הדיווח יאפשרו לבודקים לדווח באיזו קבוצה המשתמש (דפדפן Chrome) שייך (מצב A/B)?	אנחנו עובדים על פרסום מדריך לבדיקה לתיעוד תוויות בדיקה של Chrome ב-ARA.
מאמרי עזרה	במסמכי התיעוד של Attribution-Reporting-Register-Source תצוין האפשרות שתוקף התוקף יעוגל ליום הקרוב ביותר. איך היא תעוגל?	אם מעוגלים ליום הקרוב ביותר, הערך של יום אחד וחצי יעוגל ל-2 ימים.
שימוש בתת-דומיינים שונים	מבקשים לקבל דוחות של Attribution Reporting API בתת-דומיין אחר כמקור, וטריגרים לרישום.	אי אפשר לעשות את זה. אפשר להחיל הפניות אוטומטיות מסוג HTTP, אבל אין הגדרה כזו. נשמח לקבל משוב נוסף מהסביבה העסקית שתסביר למה הבקשה הזו מועילה.
עיכוב בדיווח ברמת האירוע	חלון הדיווח והשיוך של 7 ימים, אבל בגלל העיכוב בדיווח ברמת האירוע, יכול להיות שיחלפו יותר מ-8 ימים עד שכל הדוחות יוגשו.	אנחנו מאשרים את המשוב, ונשמח לקבל משוב נוסף מהסביבה העסקית כדי לבדוק אם העיכוב הזה בדיווח ברמת האירוע הוא בעיה, במיוחד בעקבות המעבר מחלונות דיווח על אירועים קבועים לגמישים.
טריגרים של המרות	טריגרים של המרות שמתרחשים בין הסיום של האירוע event_report_window (1h) הראשון לבין מועד התפוגה (יום אחד) לא יפיקו דוחות.	הוספנו הגדרות אישיות גמישות ברמת האירוע, שנעות מחלונות קבועים לדיווח על אירועים גמישים.
רעש	האם דוחות ברמת האירוע מראים "המרות מזויפות" כפי שמתואר בהסבר של GitHub?	כן, הרעש מיושם בדוחות ברמת האירוע ומייצג את כל מצבי הפלט האפשריים, כולל trigger_data שונים, לא מדווח בכלל מתי התרחש טריגר בפועל או שהוא עשוי לדווח על כמה דוחות מזויפים לגבי האירוע. אחוז הרעשים מבוסס על קוד פתוח שניתן להפוך לגמיש באמצעות הגדרות גמישות ברמת האירוע.
סינון	שימוש בסינון באמצעות Attribution Reporting API עדיין יגרום לניצול של תקציב התרומה, למרות שלא מתועד בו מפתח הצבירה.	המצב הזה פועל כמו שצריך כי הפרמטר aggregatable_trigger_data תומך רק בסינון לפי החלקים של מפתחות הטריגר עצמם, ולא על הערכים או המפתחות. מסננים ברמה עליונה יכולים לתמוך בסינון של המפתחות עצמם, אבל הסינון משותף לפי אירוע + צבירה, ולכן הוא לא רלוונטי כאן. אם יש צורך בסינון לפי מפתחות, נשמח לקבל משוב נוסף מהסביבה העסקית כאן.
מגבלת אחסון	לבקש להוסיף מגבלת אחסון כדי להביא בחשבון גם את מקור הדיווח.	עלייה מ-1,024 ל-4,096 במסגרת המגבלה הזו תיכנס לתוקף החל מגרסה M120. נשמח לקבל משוב נוסף מהסביבה העסקית כאן.
ייחוס ישיר	איך אפשר לקבל מדדים לגבי מצבים שבהם משתמש מבקר ישירות אצל מפרסם בלי לעבור על בעל התוכן הדיגיטלי, מאחר שתהליך הדיווח הרגיל של שיוך (Attribution) לא עוסק בתרחיש הזה?	ARA מיועד רק לשחזור מידע בין אתרים (כלומר, צירוף של מידע בין אתרים של בעלי תוכן דיגיטלי/מפרסמים). אם לא נדרש מידע מאתרים שונים, ARA לא יעזור לכם. אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן.
מועד הדיווח	קבלת Schedule_report_time של השעה משרת זמן במקום שימוש בשעון המכונה המקומי.	בשלב זה אין לנו תוכניות להשתמש בשרת זמן ולא שמענו הרבה ביקוש מטכנולוגיית המודעות. נשמח לקבל משוב נוסף מהמערכת האקולוגית כדי לקבוע אם זו תהיה תכונה שימושית.

שירות צבירה

נושא משוב	סיכום	התגובה של Chrome
(דווח גם ברבעונים קודמים) פתרון מקומי	האם ניתן לפרוס את שירות הצבירה במרכזי נתונים מקומיים?	אנחנו בוחנים אפשרויות נתמכות מעבר לפתרונות מבוססי-ענן, אבל בשלב זה לא ניתן לתמוך בסביבת TEE מקומית, בהינתן מגבלות אבטחה מקומיות שמחייבות הערכה הממושכת של ארגז החול לפרטיות. לאור דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שנובעים מפריסות מקומיות, אנחנו מאמינים שהמשך הרחבה ושיפור של פריסות מבוססות-ענן (למשל תמיכה ב-GCP בנוסף ל-AWS) הוא המועיל ביותר לסביבה העסקית. עם זאת, נשמח לקבל כאן משוב נוסף שמסביר למה הדרישה הזו נדרשת.
מובלעת	אם המובלעת לא פועלת או מקבלת הודעת שגיאה בפתאומיות, איך ה-Aggregation Service API מטפל בה?	נשתמש בניסיונות חוזרים אם ה-enclave נכשל בהפעלה ובהתאמה לעומס (autoscaling) כדי להציג מכונות חדשות אם מכונה נתפסת כלא תקינה. טכנולוגיות Adtech יכולות גם לחקור כשלים באמצעות יומנים. כדי לנפות באגים בכשלים של enclave ב-AWS, טכנולוגיות פרסום יכולות לבדוק את הסטטוס של מכונת EC2 שלהן באמצעות התחברות ל-AWS Console Manager. טכנולוגיות פרסום יכולות גם להתחבר למופע המארח של Nitro Enclave ולבדוק את סטטוס המובלעת באמצעות הכלי nitro-cli. אם יש שגיאות או כשלים, הם יכולים להשתמש בממשק שורת הפקודה של AWS כדי להציג את היומנים ולבחון לעומק. כדי לנפות באגים בכשלים של enclave ב-GCP, טכנולוגיות adtech יכולות לבדוק את סטטוס המכונה שלהם באמצעות Cloud Console. הם יכולים גם לבדוק אם יש שגיאות באמצעות הפקודה list-errors-command.
שימוש בתת-דומיינים שונים	בקשה לרישום מספר דומיינים (תת-דומיינים) כדי להשתמש במספר מופעים של שירותי צבירה, גם בסביבות פיתוח וגם בסביבות ייצור.	השקנו את האתר כדי שטכנולוגיות פרסום יכולות לרשום כמה תת-דומיינים של אותו אתר בחשבון AWS אחד או בפרויקט GCP אחד. הם גם יוכלו לרשום את אותו דומיין בכמה חשבונות AWS או פרויקטים של GCP. נשמח לקבל משוב מהסביבה העסקית.
תקציב פרטיות	איך לנפות באגים בצורה טובה יותר בבעיות של מיצוי תקציב הפרטיות	בשלב הזה אנחנו בוחנים פתרונות כדי לספק פרטים נוספים על ניצול התקציב, וכדי לשפר את המסמכים שלנו כדי לתכנן אסטרטגיות שטכנולוגיית המודעות יכולה להשתמש בהן כדי למזער את המקרים של השגיאה הזו. נעדכן את הדף של שירות הצבירה ב-GitHub כשתתקבל הצעה.
ערך אפסילון	בקשה להגדלת ערך אפסילון.	ערך אפסילון של שירות הצבירה יישמר בטווח של עד 64, כדי לאפשר ביצוע ניסויים ומשוב על פרמטרים שונים במהלך 3PCD. נודיע לסביבה העסקית מראש לפני שערכי הטווח של אפסילון יעודכנו.
קבצים בינאריים	צריך לפרסם קבוצה מלאה יותר של קבצים בינאריים עבור גרסאות של שירות צבירה.	אנחנו בודקים את הבקשה ונשמח לקבל משוב נוסף.
שימוש ב-API	שיתוף נתונים עם המתאם, לאור התנאים וההגבלות של המתאם.	אנחנו מעוניינים בהבהרה לגבי הבעיה הזו, ונשמח לקבל משוב נוסף.

API לצבירה פרטית

נושא משוב	סיכום	התגובה של Chrome
ניפוי באגים	מפעילים אפשרויות נוספות לניפוי באגים במהלך הבדיקה של מצב ב'.	כמו שהסברנו בבעיה הזו ב-GitHub, אנחנו עומדים לאפשר מצב ניפוי באגים במצב ב'. הזכאות הזו תשתנה בגרסת בטא של M121 ב-50% מהתנועה במצב ב' החל מ-31 בינואר. נודיע לך לפני המעבר לערוץ יציב.

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

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

נושא משוב	סיכום	התגובה של Chrome
ChromeOS	תמיכה ב-User-Agent Client Hints עבור סיביות של מערכת ההפעלה של Chrome.	כאן שיתפנו תגובה לבקשה הזו.

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

נושא משוב	סיכום	התגובה של Chrome
התנהלות פוגעת	יכול להיות ש-Google תוכל להציג את נתוני הגלישה של משתמשים באמצעות התכונה 'הגנה על IP'.	מנהרות ההגנה על כתובות IP מנתבת את התנועה דרך שני שרתי proxy (אחד מופעל על ידי Google והשני על ידי חברה אחרת). כך אפשר להבטיח ש-Google לא תוכל לראות את נתוני הגלישה. כל התנועה מוצפנת בין Chrome לבין שרתי ה-proxy, כך שלשרת ה-proxy של Google אין מידע לגבי האתרים שבהם גולשים. בנוסף, המערכת משתמשת באסימוני אימות מסונורים כדי למזער את הגישה למזהי משתמשים בשרתי ה-proxy. כל מה ש-Google proxy יראה הוא שלקוח לא ידוע בכתובת IP ספציפית משתמש במערכת שרת ה-proxy. אין מידע זמין על אתרים שביקרו בהם או על מודעות שנטענו.
תמיכה במצב 'דפדפן ללא GUI'	איך ינוהלו בוטים שמשתמשים ביישומי פלאגין ומצב 'דפדפן ללא GUI'?	הפחתת הניצול לרעה של ההגנה על ה-IP נמצאת בראש סדר העדיפויות של הצוות. בדקנו בקפידה את התרחישים האלה (וכן איומים פוטנציאליים רבים אחרים), ואנחנו עובדים על אפשרויות שיעזרו לצמצם את הסיכויים לכך שניצול לרעה או הונאה יושלמו. בשלב הזה אנחנו לא יכולים לספק פרטים נוספים, אבל אנחנו מצפים לספק אותם בעתיד הקרוב ומצפים להמשך הדיון.
שרתי proxy קיימים	איך פועלת ההגנה על IP עם ההגדרות הקיימות לשרת proxy ב-Chrome?	עדיין תהיה תמיכה בהגדרות קיימות של שרתי proxy. המשתמשים יוכלו להגדיר שרתי proxy משלהם כמו קודם.
דיווח על שימוש לרעה	איך יטופל דיווח על התנהלות פוגעת?	בעתיד הקרוב נפרסם פרטים נוספים, אבל אנחנו מתכננים לפתוח מנגנון שבו ארגונים ומשתמשים יוכלו לשתף דיווחים עדויות לניצול לרעה.
תקנות	איך ההגנה על ה-IP תפעל בהתאם לחוקים ולתקנות המקומיים?	Google מחויבת לציית לחוקים ולתקנות המקומיים, וייתכן שלא נאפשר לעקוף חסימות כאלה ברמת המדינה. התכונה הזו לא מיועדת לעקיפה.
הגבלת יכולות	האם הגנת IP תחסום את תגובת הסייבר שלנו?	אנחנו שואפים לאזן בין הגנה על משתמשים מפני מעקב באינטרנט על סמך כתובות ה-IP שלהם, תוך צמצום ההפרעה לפעולה הרגילה של השרתים, כולל השימוש בכתובות IP למניעת שימוש לרעה. בשלב הזה אנחנו לא יכולים לספק פרטים נוספים, אבל אנחנו מצפים לספק אותם בעתיד הקרוב ומצפים להמשך הדיון.
ציר הזמן	אם נאכוף את המדיניות לפני סוף 2024, יהיה כמעט בלתי אפשרי להתכונן לכך.	Chrome יפעיל את התכונה 'הגנה על IP' כהגדרת הצטרפות למשתמשים באזורים מסוימים, מתוך הבנה שמדובר בשינוי משמעותי באופן שבו חלק מהחברות מסתמכות על כתובות IP, בניסיון לצמצם את השיבושים ככל שהמערכת האקולוגית מתאימה את עצמה. ההגנה על ה-IP תעבור לברירת המחדל עד 2025.
שימוש ב-API	האם משתמש יקבל אפשרות להפעיל או להשבית את ההגדרה 'הגנה על IP' בפעם הראשונה שהוא יפתח את Chrome?	אנחנו מתכננים לאפשר למשתמשים לבחור אם להשתמש בהגנה מפני IP או לא. המנגנון של הצגת האפשרות הזו למשתמשים עדיין נמצא בשלבי פיתוח.
שימוש ב-API	כמה נתונים נרשמים ביומן ולמשך כמה זמן נשמרים הנתונים האלה?	בעתיד נשתף פרטים נוספים, אבל אנחנו מתכננים לתעד כמויות מינימליות של נתונים.
משוב שלילי	המשתמשים יכולים להשתמש ברשתות VPN אם הם מעדיפים להשתמש בהן. אין צורך ב-PS API.	המטרה של 'הגנה על IP' היא למנוע את השימוש בכתובות IP לצורך מעקב בין אתרים. היא לא מיועדת להיות שירות VPN.
בטיחות API	איך למנוע מאינטראקציה ישירה גישה לכתובת IP ומידע להעברה דרך הפרמטר של הכותרת?	אנו מתמקדים בהתחלה בצדדים שלישיים, כי רואים את ההשפעה הגדולה ביותר. נמשיך לעקוב אחרי הסביבה העסקית כדי לקבוע אם יש צורך לשנות את הגישה שלנו כדי למנוע עקיפה בקנה מידה נרחב.
שימוש ב-API	נדרש אישור אם הבנת נכון את השימוש ב-API.	בהגנה על IP נעשה שימוש בגישה מבוססת-רשימות כדי לזהות איזו תעבורת נתונים של צד שלישי עוברת דרך שרתי ה-proxy. מקורות שמופיעים ברשימה אבל ניגשים אליהם בהקשר מאינטראקציה ישירה לא יועברו דרך שרת proxy דרך השירות הזה לחיבורים האלה. לדוגמה, אם חברת ניתוח נתונים נמצאת ברשימת הדומיינים ומשתמש מנווט ישירות לאתר, האתר עדיין יוכל לראות את כתובת ה-IP של המשתמש במקום את כתובת ה-IP דרך שרת proxy. עם זאת, אם הדומיין ברשימה שולח בקשת רשת בהקשר של צד שלישי, החיבור יתבצע דרך שרת proxy וכתובת ה-IP המקורית של המשתמש לא תהיה גלויה לאתר. המטרה הסופית שלנו היא למנוע מעקב אחר משתמשים באתרים שונים. אנחנו עובדים על כמה פרטים לפני שאנחנו משתפים מידע נוסף על הדומיינים של צד שלישי שבהם אנחנו מתכננים להתמקד בהתחלה.
VPN	חשש שההצעה של Google עלולה לפגוע בספקי VPN אחרים.	המטרה של 'הגנה על IP' היא למנוע את השימוש בכתובות IP לצורך מעקב בין אתרים. היא לא מיועדת להיות שירות VPN.
ציר הזמן	מהו ציר הזמן של ההגנה על ה-IP?	במסגרת ההגנה על ה-IP תוענק הסכמה לשימוש בהתחלה. כך ניתן להבטיח שיש למשתמשים שליטה על החלטות הפרטיות, ו-Google יכולה לעקוב אחר התנהגויות בנפחים נמוכים יותר. ההגנה על ה-IP תושק באופן הדרגתי ותועבר לברירת המחדל לא לפני 2025. כמו כל ההצעות שלנו בנושא פרטיות, אנחנו רוצים לוודא שנלמד תוך כדי תנועה, וברור לנו שעשויים להיות שיקולים אזוריים שצריך לשקול. אנחנו משתמשים בשיטה שמבוססת על רשימות, ורק דומיינים ברשימה בהקשר של צד שלישי יושפעו מכך. אנחנו מודעים לכך שההצעות האלה עלולות לגרום לשיבושים לא רצויים בתרחישים לגיטימיים, ולכן אנחנו מתמקדים רק בסקריפטים ובדומיינים שנחשבים למעקב אחר משתמשים.
הגבלת יכולות	לא ניתן יותר לחפש ב-WHOIS את כתובות ה-IP של המשתמש.	עמדתנו היא שכתובת ה-IP היא מזהה יציב שלשימוש בו עלולות להיות השלכות על פרטיות המשתמשים, כולל שימוש במטא-נתונים המשויכים אליו, כגון ASN. בעזרת התכונה 'הגנה על IP', אנחנו מנסים למצוא את האיזון הנכון בין פרטיות לבין תמיכה בחוויית משתמש מועילה באינטרנט, למשל הגישה שלנו לגבי מיקום גיאוגרפי של כתובות IP. אם המטא-נתונים האלה לא מספיקים למקרה שלך, אפשר להמשיך לדון בנושא.
גורם מפנה מסוג HTTP	האם יישמר מקור ההפניה (referrer) המקורי של ה-HTTP?	אנחנו לא מתכננים לשנות את הכותרת של הגורם המפנה במסגרת ההגנה על ה-IP, כפי שמתואר כאן.
קוד פתוח	האם קודי המקור של ההגנה על ה-IP יהיו בקוד פתוח?	רוב התוכנות כאן הן בקוד פתוח כחלק מהפרויקטים של Chromium ו-Envoy Proxy, אבל חלק מהרכיבים הם קוד סגור, כמו שמוסבר כאן.

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

נושא משוב	סיכום	התגובה של Chrome
מחיקת אחסון	האם המיטיגציה של מעקב אחר עזיבה מהדף הראשון מוחקת את האחסון המשותף והאחסון של דוחות השיוך (Attribution)?	לא התכוונו ש-BTM ימחק את האחסון ב-API של ארגז החול לפרטיות (ARA, PA API, Shared Storage, Private Aggregation, Topics). צריך למחוק מ-BTM רק סוגי אחסון שיש בהם סיכוני פרטיות אם ניגשים אליהם בהקשר של צד שלישי. תיקון באגים מתבצע כרגע.
שימוש ב-API	איזו גרסה של Chrome תופעל BTM? האם מעקב אחר הפניה אוטומטית או עזיבה מהדף הראשון אחרי 10 שניות ייחשב כמעקב עזיבה מהדף הראשון באמצעות BTM או לא?	בגרסה M116, BTM הושקה ל-100% מהמשתמשים שהיו חסומים ל-3PC. בשלב זה, הפניה אוטומטית לאחר 10 שניות לא נחשבת כעזיבה מהדף הראשון.
תרחיש לדוגמה לכניסה	לסנכרן או לשמור באופן אוטומטי על מצב הכניסה לחשבון בכמה דומיינים, בלי להעניש על התנהגות דמוית מעקב?	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
התהליך שעובר המשתמש	נכון לעכשיו, בעזרת BTM יש תהליכי עבודה מורכבים שעוברים משתמשים.	אנחנו דנים בנושא ושיתפנו את דעתנו בנושא כאן.
API לגישה לאחסון	BTM ב-Chromium יכבדו מענקים ל-3PC מ-API לגישה לאחסון (SAA).	שוחחנו על הבעיה הזו עם משתתפים בתחום הסביבה העסקית ב-TPAC 2023, ונשמח לקבל משוב נוסף כאן.
ההשפעה על הדיווח על מודעות	הקלות במעקב אחר עזיבה מהדף הראשון עלולות להוביל לחברות קטנות יותר בסביבה העסקית להסתמכות על ממשקי API אחרים של ארגז החול לפרטיות, כמו ARA, כדי להוציא לפועל תרחישים לדוגמה של מודעות.	ההקלות במעקב אחר עזיבה מהדף הראשון נועדו למנוע עקיפה של 3PCD. ARA הוא אחד מהפתרונות החלופיים הרבים שחברות יהיו זמינות לאחר 3PCD, אבל אף חברה לא נדרשת להשתמש בו.

תקציב פרטיות

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

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

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

נושא משוב	סיכום	התגובה של Chrome
(דווח גם ברבעונים קודמים) מגבלת דומיינים בקבוצות של אתרים קשורים (RWS)	בקשה להגדלת מספר הדומיינים המשויכים.	בשלב הזה, אנחנו לא צופים להגדיל את המגבלה המספרית. המגבלה נקבעה על סמך שיקולים הקשורים לפרטיות המשתמשים, משוב מבעלי עניין בסביבה העסקית ב-W3C, והתעניינות בהטמעות דומות בדפדפנים אחרים. למידע נוסף, אפשר לעיין בפוסטים בבלוג שלנו (1, 2). מומלץ לבדוק תרחישים לדוגמה שבהם נדרשת גישה לקובצי cookie באתרים שונים מעבר למגבלה המספרית, ולשקול להשתמש בהנחיות שלנו לגבי תרחישים לדוגמה לזיהוי, הטמעות מאומתות ותרחישים לדוגמה בתחום הפרסום.
היקף הגישה לקובצי cookie	חשש שכל הדומיינים ב-RWS יקבלו גישה לקריאה ולכתיבה של כל קובצי ה-cookie מכל הדומיינים.	חברות ב-RWS לא מאפשרת לחברים לגשת לקובצי ה-Cookie זה של זה. במקום זאת, הם יאפשרו לחברים לגשת לקובצי cookie שלהם כשהם מוטמעים באתרים אחרים עם אותם RWS (לאחר הפעלה של Storage Access API).
(דיווח גם ברבעונים קודמים) שילוב של RWS עם CHIPS	בקשה לשילוב RWS ו-CHIPS כדי לתמוך בתרחישים לדוגמה כמו A/B Testing	אנחנו ממשיכים לקבל בקשות ותרחישים לדוגמה לשימוש בתכונה הזו כאן. נכון לעכשיו, אנחנו שוקלים את הצורך בתכונה הזו מול הסיכונים של יכולת פעולה הדדית בין דפדפנים.
שימוש ב-API	מה קורה אם משתמש מסיר אתרים באופן ידני מהגדרות Chrome שלו באופן מקומי?	בשלב זה אין לנו אפשרות למחוק באופן ידני אתר מקבוצה. המשתמשים יכולים במקום זאת להשבית את התכונה 'אתרים קשורים' באמצעות לחצן החלפת המצב שמתחת לכיתוב 'חסימת קובצי cookie של צד שלישי' או ל'חסימת כל קובצי ה-cookie של צד שלישי' בחלונית ההגדרות החדשה של חסימת המעקב.
תקשורת בין דומיינים	האם פרוטוקול RWS יאפשר תקשורת בכמה דומיינים?	אנחנו מפעילים כרגע גרסת מקור לניסיון כדי להרחיב את הגישה לסוגים מסוימים של אחסון ללא מחיצה (כולל localStorage ו- Broadcast Channel) דרך Storage Access API שיאפשר את התקשורת הזו. היכולת הזו זמינה בכל התצורות הנתמכות של Storage Access API, באותו RWS ו באתרים שהם לא RWS. בפוסט הזה בבלוג יש מידע נוסף.
requestStorageAccessFor	האם document.requestStorageAccessFor(origin) יכול להחזיר הבטחה שנפתרת עם קובצי cookie מאתרים שונים של המקור?	אי אפשר לעשות את זה. מכיוון שההפעלה מתרחשת מהמקור ברמה העליונה (ששונה מהמקור שמועבר כארגומנט), פעולה כזו תפר את מדיניות המקור הזהה.

ממשק API של Fenced Frames

נושא משוב	סיכום	התגובה של Chrome
(דווח גם ברבעונים הקודמים) פרסום מותאם	תמיכה ב-Fenced Frame בפרסום מותאם.	בעבר שציינו שטכנולוגיות מסוימות של ארגז החול לפרטיות יידרשו בעתיד כדי לחזק את אמצעי ההגנה על הפרטיות. לדוגמה, במסגרת Protected Audience API, נדרוש להשתמש ב-Fenced Frames להצגת מודעות, ונעבור מדיווח ברמת האירוע לא לפני 2026. ציינו תאריכים "לכל היותר" עבור כל אחת מהדרישות העתידיות האלה, כדי להבהיר בתחום ההתפתחות המכוונת של ממשקי ה-API. הזמן הנוסף מאפשר לנו להמשיך לעבוד עם גורמים בתעשייה כדי לתכנן וליישם תמיכה למגוון רחב יותר של תרחישים קריטיים. לדוגמה, אנחנו נפתח את Fenced Frames לקראת הדרישה בשנת 2026 ואילך כדי להמשיך לתמוך במודעות וידאו ובמודעות מותאמות באמצעות Protected Audience API. בהתאם למחויבויות שלנו, אנחנו נתיעץ עם מנהלי הקהילה לגבי שינויים כאלה, ונמשיך לקבל משוב מהסביבה העסקית לפני שניישם את הדרישות האלה 'לא מוקדם יותר'.
הבדלי גודל בין פלטפורמות	דיווחים על כך שגודל התוכן שמוצג ב-Fenced Frame נראה שונה בין מחשבים שולחניים לסמארטפונים.	אנחנו בודקים את הבעיה ונשמח לקבל משוב נוסף כאן.
עיבוד מודעה	תן לי קודים לדוגמה איך לעבד רכיבי מודעות ב-Fenced Frame?	אנחנו רוצים לספק תיעוד לגבי השימוש ב-navigator.adAuctionComponents(numComponents) בתוך Fenced Frame כדי להציג מודעה שמורכבת מכמה חלקים.
שיפור ה-API	כדאי לספק יותר אותות ל-FencedFrames (שיפור, למשל להגנה על המותג).	אנחנו מקבלים בברכה את ההצעה ומקבלים נשמח לקבל ממך משוב נוסף כאן.

ממשק API של Shared Storage

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

צ'יפים

נושא משוב	סיכום	התגובה של Chrome
חלונות קופצים/הפניות אוטומטיות	איך רכיבי CHIP יתמכו בתרחישים לדוגמה של אימות מוטמעים שקשורים לחלונות קופצים ולהפניות אוטומטיות?	לאחרונה סיפרנו על ההשפעה של ביטול ההדרגתיות של ממשק 3PC על תהליך הכניסה שלך, ונשמח לקבל משוב נוסף כאן.
מגבלת מחיצות	הקטנת המגבלה הכוללת לכל אתר לכל מחיצה ל-1KiB.	אנחנו בוחנים את הבקשה ושולחים משוב נוסף כאן. אנחנו נמשיך לעקוב אחר המשוב במהלך ההשקה של 3PCD, והמפתחים משתמשים ב-CHIP ומספקים משוב.
העברה של קובצי cookie	תהליך מומלץ להעברת אפליקציית אינטרנט כדי להנפיק קובצי cookie עם חלוקה למחיצות, שלא גורמת לשיבושים/סשנים של קובצי cookie פעילים?	בתשובה שלנו הצענו הצעה אפשרית להעברה, אבל המפתח הצליח לגבש פתרון חלופי שמתאים יותר להגדרה שלו.
שימוש ב-API	האם הגישה לאחסון עם חלוקה למחיצות (Partitions) מושבתת כשהמשתמש לא מביע הסכמה להגדרת ממשקי ה-API לשמירה על פרטיות בפרסום?	אחסון עם חלוקה למחיצות (Partitions) וקובצי cookie עם חלוקה למחיצות (CHIPs) מופעלים גם אם המשתמש לא הביע הסכמה להגדרת ממשקי ה-API לשמירה על פרטיות בפרסום, מאחר שהם לא מאפשרים העברה של מידע בין אתרים. באופן כללי, העברה של מידע בין אתרים תהיה כפופה למגבלות, לבדיקות או להסכמה של משתמשים. אבל כרגע הגבלות אלה לא חלות על CHIPS.
שימוש ב-API	מה ההיגיון לכך שבסופו של דבר יחסום קובצי cookie שמחולקים למחיצות, במקום שהדפדפן רק יחלק אותם 'בשקט' למחיצות?	אי אפשר לעשות את זה בטווח הקצר והבינוני, כפי שמוסבר כאן.

FedCM

נושא משוב	סיכום	התגובה של Chrome
שימוש ב-API	לא ניתן להציג 'קובץ ידוע' ב-eTLD+1 בסביבת הפיתוח.	עדכנו את Chrome Canary כך שידלג על האחזור של הקבצים הידועים כפי שמתואר כאן.
שימוש ב-API	האם הוגדרו דרישות ספציפיות לגבי אינטראקציה עם המשתמש לבקשת הרשאות כניסה של צד שלישי או לשימוש ב-FedCM?	אין דרישות ספציפיות לאינטראקציה של המשתמשים, כפי שמתואר כאן.
בטיחות API	האם יש תוכניות ליצור זרימה שמאפשרת ללקוח ליזום FedCM, אבל למעשה האסימונים מועברים מ-IdP למערכת קצה עורפי של ה-RP?	אנחנו דנים בדיונים ושולחים משוב נוסף כאן.
הבעת הסכמה	צריך לאפשר ל-IdP להביע הסכמה לקבלת מזהה הלקוח של ה-RP, כדי שהמשתמשים יוכלו להחליט אם הם סומכים על ה-IdP או לא.	אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	בקשה למסמכים נוספים ב-FedCM.	אנחנו מאשרים את המשוב הזה וממשיכים לשפר את התיעוד ככל שנמשיך לפתח את ה-API הזה.

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

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

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