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

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

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

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

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

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

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

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

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

נושא המשוב סיכום תגובה מ-Chrome
משילות מידע ותאימות לדרישות רגולטוריות הנחיות לסביבה העסקית לגבי שימוש בארגז החול לפרטיות בהתאם לדרישות הרגולטוריות. כמו בכל טכנולוגיה חדשה, כל חברה אחראית לוודא שהשימוש שלה בארגז החול לפרטיות עומד בדרישות החוק. Google לא יכולה לספק ייעוץ משפטי לאחרים. עם זאת, אנחנו מודעים לכך שזהו תחום מרכזי של עניין בסביבה העסקית. פרסמנו מסמכים טכניים מקיפים לכל ממשק API, שיכולים לספק את הבסיס לביצוע הבדיקות המשפטיות הנדרשות. אנחנו גם פועלים כדי לספק חומרים נוספים שיעזרו לחברות לעמוד בדרישות הרגולטוריות.
הצעה לבדיקות כמותיות של CMA מידע נוסף על ההצעה לבדיקות כמותיות של CMA אנחנו עובדים בשיתוף עם ה-CMA כדי לתכנן ניסויים שיספקו תמונה של ההשפעה של ההוצאה משימוש של קובצי Cookie של צד שלישי וההכנסה של ההצעות של ארגז החול לפרטיות על הסביבה העסקית. בחודש אפריל, ה-CMA פרסם הנחיה ברמה גבוהה לגבי מה שצפוי במהלך תקופת הבדיקה וההרצה, ולאחר מכן פרסם הנחיה מפורטת בחודש יוני. אנחנו ממליצים לשתף שאלות או משוב על ההצעה של CMA לבדיקות כמותיות ישירות עם CMA.
מצבי בדיקה שמתבצעים באמצעות Chrome מידע נוסף והבהרות לגבי לוחות הזמנים לבדיקות ב-18 במאי פרסמנו פוסט בבלוג עם מידע נוסף על שני המצבים של בדיקות שמתבצעות באמצעות Chrome. הפרטים האלה לא סופיים, ואנחנו נעלה הנחיות נוספות להטמעה בהמשך הרבעון השלישי של 2023.
אחסון מחולק למחיצות האם יתבצע שימוש באחסון מפוצל במהלך הבדיקות שמבוצעות באמצעות Chrome? חלוקת האחסון תשוחרר לכל המשתמשים לפני הניסוי בנושא ההוצאה משימוש של קובצי cookie של צד שלישי. לכן, הוא יופעל בכל קבוצות הניסוי. בתקופה הזו, בעלי אתרים יוכלו להפעיל תקופת ניסיון להוצאה משימוש כדי לקבל חזרה אחסון ללא מחיצות.
תמיכה בסביבת הייצור מהו התהליך ב-Chrome לתמיכה בבעיות טכניות בארגז החול לפרטיות ובהעברות לטיפול ברמה גבוהה יותר שמשפיעות על הסביבה העסקית? Google מספקת מגוון ערוצים שמאפשרים לטכנאי הפרסום לדווח על בעיות ולאפשר העברה לטיפול ברמה גבוהה יותר במקרה הצורך.
מידע נוסף על הפורומים הציבוריים והפרטיים למשוב ולהעברה לטיפול ברמה גבוהה יותר זמין בסקירה הכללית שלנו בנושא משוב.
ציר הזמן של ההרשמה מסגרת הזמן הנוכחית להרשמה קצרה מדי אנחנו עדיין בודקים את מועד האכיפה, ואנחנו רוצים לשמוע מהסביבה העסקית מה לדעתה יהיה לוח הזמנים המתאים ביותר.
מספר DUNS מידע נוסף על הדרישה למספר D-U-N-S להרשמה ולאימות המשתתפים יכולים למצוא את הדרישות לקבלת מספר DUNS באתר של Dun and Bradstreet. הדרישות משתנות בהתאם לשוק, ולכן המשתתפים צריכים לבדוק את האתר של השוק הספציפי שבו הם מעוניינים. באופן כללי, עם זאת, המשתתפים יצטרכו לספק פרטים בסיסיים על העסק שלהם, כמו שם העסק, הכתובת והפרטים ליצירת קשר של בעל העסק או של המנהל שלו. יכול להיות שהמשתתפים יתבקשו גם לספק מידע פיננסי, כמו ההכנסה השנתית של העסק. אחרי שהבקשה תושלם, D&B תבדוק אותה ותנפיק מספר DUNS אם הבקשה תאושר.
מעבר מגרסת המקור לניסיון לזמינות לכולם האם המעבר מגרסת המקור לניסיון לזמינות כללית ישפיע על הבודקים הנוכחיים של גרסת המקור לניסיון? החל מיולי, הבודקים יוכלו לגשת לממשקי ה-API של הרלוונטיות והמדידה במסגרת הזמינות הכללית. כך תהיה חפיפה בין זמינות תקופת הניסיון במקור לבין זמינות לכלל המשתמשים.
מחקר של AdExchanger מידע נוסף על המתודולוגיה של הסקר במסגרת הסקר, התבקשו המשיבים להעריך את שיעורי הסנכרון וההכנסות של העסקים שלהם. החוקרים לא קבעו איך המשיבים יענו על השאלות שלהם.
ערכי פרמטרים איך נקבעים ערכי הפרמטרים כמו רמת הרעש, ערכי הסף לשמירה על פרטיות ותקציב הפרטיות? במאמר ההסבר הזה ב-GitHub מפורטים העקרונות הכלליים יותר שעומדים מאחורי ממשקי ה-API של ארגז החול לפרטיות. עדיין יש ערכים רבים שאנחנו משלימים, ונשמח לקבל משוב בנושא הזה.

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

נושאים

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

ה-Topics API מגן על המשתמשים מפני מעקב כללי באינטרנט על ידי הקשחת המעקב אחר המשתמשים בקנה מידה נרחב. המאמרים האלה מראים שאנחנו עושים זאת בהצלחה באמצעות Topics API. הם מספקים רמה גבוהה יותר של פרטיות בהשוואה לקובצי cookie של צד שלישי, ומגינים על המשתמשים תוך תמיכה באתרים שהם אוהבים לבקר בהם.
הטקסונומיה של הנושאים לא מספיק מפורטת הטקסונומיה של הנושאים הרחבים לא כוללת נושאים מפורטים יותר, כולל נושאים ספציפיים לאזור. בתגובה למשוב הקודם מהסביבה העסקית, פרסמנו ב-15 ביוני פוסט בבלוג שבו פירטנו על מערכת קטגוריות חדשה ומעודכנת שכוללת שיפורים רבים בעקבות המשוב מהסביבה העסקית. כחלק מהעבודה שלנו על הטקסונומיה המתוקנת, פנינו לכמה חברות בסביבה העסקית, כמו Raptive (לשעבר CafeMedia) ו-Criteo. בתחביר המעודכן הוסרו קטגוריות שקיבלנו משוב עליהן שהן פחות מועילות, והן הוחלפו בקטגוריות שתואמות יותר לתחומי העניין של המפרסמים, תוך שמירה על המחויבות שלנו להחריג נושאים שעשויים להיות רגישים.

אנחנו ממליצים לגורמים בסביבה העסקית לבדוק את הטקסונומיה העדכנית ולשלוח משוב על השינויים.
תהליך העדכון של הטקסונומיה והקלסификатор מידע נוסף על הטקסונומיה של Topics ועל תדירות הפרסום של הסיווגים, וגם איך חברות יכולות להתכונן לעדכונים כאלה. כפי שציינו בפוסט בבלוג שפרסמנו לאחרונה, אנחנו מצפים שהטקסונומיה תתפתח עם הזמן, וששליטת הטקסונומיה תעבור בסופו של דבר לגורם חיצוני שמייצג בעלי עניין מכל רחבי התחום. שיתוף התוכנית להגדלת ההיקף נעשה גם בקבוצה topics-announce.
ההשפעה על אותות מאינטראקציה ישירה העלייה במספר הנושאים בעדכון הטקסונומיה האחרון עשויה להיות בעלת ערך רב, וכתוצאה מכך עשויה לפגוע בערך של אותות אחרים מבוססי-אינטרס מאינטראקציה ישירה. בדוח הרבעון הראשון של שנת 2023, CMA ציין: "אנחנו מבינים ש-Google דנה במערכת המוצעת החדשה שלה לסיווג עם כמה גורמים בשוק לאורך שרשרת האספקה של טכנולוגיית הפרסום. כמה בעלי תוכן דיגיטלי גדולים אמרו ששימוש נרחב יותר בנושאים יגדיל את הלחץ התחרותי על הפתרונות שלהם שמבוססים על נתונים מאינטראקציה ישירה (First-Party). עם זאת, ההערכה הראשונית שלנו היא ששימוש נרחב יותר בנושאים עדיף על התחרות באופן כללי – במיוחד על היכולת של בעלי תוכן דיגיטלי קטנים יותר להמשיך לייצר הכנסות ממלאי שטחי הפרסום שלהם אחרי ההוצאה משימוש של קובצי cookie של צד שלישי". הדעה שלנו תואמת לתגובה הזו של CMA.
התועלת לבעלי עניין מסוגים שונים לספקי טכנולוגיות פרסום שמשמשים כ-SSP ו-DSP עשויים להיות יתרונות משמעותיים על פני שחקנים אחרים בסביבה העסקית. התשובה שלנו לא השתנתה מארבעי החודשים הקודמים:

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

לאפשרות לאפשר לבעלי תוכן דיגיטלי לשלוט בסיווג שלהם יש סיכונים. בעלי אתרים עשויים לסווג את האתרים שלהם באופן שגוי בכוונה, וכך לצמצם את התועלת לכולם, או לקודד משמעויות רגישות בנושאים פחות נפוצים, וכך לפגוע בפרטיות המשתמשים.
תוספי Chrome לאפשר לתוספים ל-Chrome לנהל ולסנן נושאים, בדומה לתוספים הקיימים לניהול קובצי cookie כבר אמורה להיות אפשרות לעשות זאת, כפי שצוין ב-GitHub, אבל נשמח לקבל משוב נוסף מהסביבה העסקית.
מעבר לזמינות לכלל המשתמשים (GA) האם תהיה השפעה כלשהי על Topics API במהלך המעבר מגרסת המקור לניסיון לזמינות כללית? משתמשים שעוברים מהגרסת Origin Trial לגרסה הזמינה לכולם לא יאבדו נתונים.
פרטיות שמות המארחים עשויים להכיל מידע פרטי שעשוי להיחשף על ידי Topics API יש לנו כמה אמצעי מיטיגציה כדי להבטיח את הפרטיות, כפי שמתואר כאן.
הונאה וניצול לרעה איך למנוע מניפולציה של 'נושאים' על ידי ביקורים שמקורם בתרמית כאן מוסבר איך לצמצם את ההשפעה של הבעיה.
מסווג נושאים האם בעלי אתרים יכולים לבקש לשנות את הסיווג שלהם ב-Topics? אנחנו רוצים לשמוע מהסביבה העסקית בנושא הזה, ונשמח לקבל משוב כאן.
אתרים של ספקי נושאים להגדיר אתרים מסוימים שמארחים תוכן של הרבה נושאים כ'אתרים של ספקי נושאים מיוחדים', ולתת הדרכה למסווגים על סמך תגים שסופקו בדפי האינטרנט. אנחנו מדברים על ההצעה כאן ונשמח לקבל משוב נוסף.

Protected Audience API (לשעבר FLEDGE)

נושא המשוב סיכום תגובה מ-Chrome
עיצוב תעבורת נתונים ההשפעה על הביצועים של סינון מבוסס-SSP לצורך אופטימיזציה של עומס השאילתות לשנייה (QPS) הקדשנו זמן רב לחשיבה על עיצוב התנועה, וההמלצה שלנו ל-SSP היא לנצל את היתרונות של האחסון במטמון.
נפח הבדיקה קשה לבדוק את התכונה 'קהל מוגן' כי פלטפורמות ה-SSP וה-DSP מתקשות לקבל נפחי תנועה גדולים. אנחנו פועלים כל הזמן בשיתוף עם שותפי SSP ו-DSP כדי לעודד אותם להשתמש ב'קהלים מוגנים' ולבדוק אותם. השקנו את התכונה לכלל המשתמשים, ואנחנו בטוחים שאחוז התנועה עם PA מופעל יאפשר לשותפים לבצע בדיקות בקלות רבה יותר.
רמת המורכבות יישום פתרונות של 'קהלים מוגנים' כרוך במאמצים ובעלויות משמעותיים. אנחנו מבינים שקשה לאמץ טכנולוגיות חדשות, כולל ארגז החול לפרטיות. צוות ארגז החול לפרטיות עובד בשיתוף פעולה הדוק עם מגוון רחב של בעלי עניין כדי לחנך אותם ולתמוך במאמצים שלהם, והוא בוחן באופן שוטף דרכים נוספות לתמוך בהטמעה של ארגז החול בסביבת הפרסום.
סביבות מחשוב מהימנות תמיכה בסביבות מחשוב מהימנות (TEE) בסביבות ענן לא ציבוריות אנחנו בודקים אפשרויות תמיכה פוטנציאליות מעבר לפתרונות מבוססי-ענן, אבל בשלב הזה לא ניתן לתמוך ב-TEEs מקומיים בגלל מגבלות האבטחה המקומיות, שיחייבו הערכה זמן-לוקחת של ארגז החול לפרטיות. בהתאם לדרישות האבטחה של ארגז החול לפרטיות ולאתגרים המשמעותיים שמציגות פריסות בארגון, אנחנו מאמינים שהדרך הטובה ביותר לשפר את הסביבה העסקית היא להמשיך להרחיב ולשפר את הפריסות מבוססות-הענן (למשל, תמיכה ב-GCP בנוסף ל-AWS). עם זאת, אנחנו מקבלים בברכה משוב נוסף לגבי הסיבה לדרישה הזו.
מבנה העלויות ההצעה לשירותי בידינג ומכרזים תגדיל את העלות והמורכבות של ספקי טכנולוגיות הפרסום בהשוואה למודלים בצד הלקוח. אנחנו מפתחים כרגע מדריך לאומדן העלויות של תמיכה בתהליכי העבודה של הבידינג והמכרזים בשרת הבידינג והמכרזים. האומדנים האלה יהיו בקורלציה לשימוש ב-AdTech, וכך יתקיים אחד מהיעדים של התכנון שלנו.
צירי זמן של K-Anon מתי יחולו אילוצים מתוכננים של אנונימיות מסוג k על 'renderUrl'? אנחנו עובדים על הסבר לגבי לוח הזמנים לאכיפת המדיניות, ונפרסם אותו בקרוב.
הגבלות על runAdAuction האם Chrome יכול להגביל את הקריאה ל-runAdAuction רק מהדף העליון? אמנם התכנון שלנו תומך באופן מלא בקריאה ל-runAdAuction מהדף העליון, אבל אנחנו סבורים שתהיה יותר נזק לבעלי תוכן דיגיטלי אם נגביל את הקריאה אליו רק מהדומיין העליון.

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

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

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

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

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

דיברנו על מספר תרחישים שקשורים לבעיה הזו במהלך הפגישה של WICG בנושא קהלים מוגנים במאי, ונשמח לקבל משוב נוסף ולנהל דיון נוסף בנושא הזה.
קהלים בהתאמה אישית האם תרחישי שימוש של פלטפורמות SSP שקשורים ליצירת קהלים בהתאמה אישית יהיו נתמכים על ידי Protected Audience API? Protected Audience API מאפשר לפלטפורמות SSP ולספקי טכנולוגיות פרסום אחרים להיות הבעלים של קהלים בהתאמה אישית ולנהל אותם. אנחנו מפתחים הנחיות נוספות לגבי האופן שבו פלטפורמות SSP יכולות לשלב את עצמן עם PA API, והן יהיו זמינות לפלטפורמות SSP ולספקי טכנולוגיות פרסום אחרים כדי לתמוך במאמצי השילוב שלהם.
פורמטים האם יש תמיכה ב-Protected Audience API בסרטונים? מודעות וידאו מוצגות באחת משתי דרכים: כ-VAST XML או כ-HTML (מודעת וידאו Out-stream שעשויה בסופו של דבר לטעון גם VAST XML לנגן וידאו). הקונים יכולים להחזיר את הפורמטים האלה באמצעות renderURL. מפרט ה-VAST עודכן לאחרונה כדי לתמוך ב-Attribution Reporting API. אתרים שמציגים מודעות וידאו יצטרכו להתכונן לאופן שבו המודעות יוצגו דרך Protected Audience API. כלומר, צריך לוודא שתגי מיקומי המודעות יכולים להעביר את כתובת ה-URL מ-iframe של Protected Audience לנגן וידאו. לגבי פריימים מגודר, נעבוד כדי לענות על הצרכים של הסרטונים לפני שהדרישה להשתמש בפריימים מגודר תתחיל לא לפני 2026.
קצב איך התרחיש לדוגמה של קצב הצגת מודעות פועל עם Protected Audience API? תודה על המשוב. נשמח לקבל מקרים נוספים של הבקשה הזו עם פרטים נוספים משותפי SSP נוספים, כי עד כה הבעיה הזו הייתה בעיקר בעיה של פלטפורמות ניהול מודעות.
תדירות עדכון יכול להיות שתדירות הקריאות מ-dailyUpdate (עד קריאה אחת ליום לכל קבוצת תחומי עניין) לא תספיק לתרחישי שימוש מסוימים, כמו עדכון פרטי המוצר. תודה על המשוב. יש פתרונות אחרים שמאפשרים לטכנולוגיות פרסום להשתמש באותות שמתעדכנים בקצב שונה, כמו חיפושים של מפתח/ערך (K/V).
בקרת איכות של מודעות איך בעלי תוכן דיגיטלי מטמיעים בקרת איכות של מודעות? נכון לעכשיו, Protected Audience API מציע פונקציונליות שמאפשרת לבעלי תוכן דיגיטלי להודיע ל-SSP שלהם על אמצעי בקרה מסוימים שהם יכולים להגדיר כחלק מהגדרת המכרז, לפני הגשת הצעת המחיר (כלומר רשימות דחייה על סמך תוויות המשויכות למודעות). נשמח לקבל מכם משוב על פונקציונליות נוספת שיכולה להועיל לסביבה העסקית.
ניפוי באגים מתי תבוטל הפונקציונליות של forDebuggingOnly? אנחנו מתכננים להוציא משימוש את forDebuggingOnly לאירועי אובדן עקב הוצאה משימוש של קובצי cookie של צד שלישי. אנחנו מתכננים להוציא משימוש את forDebuggingOnly לאירועי זכייה בשנת 2026 לכל המוקדם.
קבוצות אינטרס במכשירים שונים הצעה להפעלת קבוצות תחומי עניין במכשירים שונים עבור סוכני משתמשים מאומתים אנחנו בודקים את ההצעה הזו, אבל הספציפיות הגבוהה של טירגוט במכשירים שונים יוצרת בעיות פרטיות משמעותיות, כפי שמתואר בבעיה הזו ב-GitHub.
(הנתונים האלה מדווחים גם ברבעון הראשון) רימרקטינג דינמי האם עדיין יהיה אפשר להשתמש ברימרקטינג דינמי באמצעות Protected Audience API אחרי ההוצאה משימוש של קובצי cookie של צד שלישי? אנחנו מאמינים שאפשר לבצע את התרחיש לדוגמה הזה באמצעות 'קהל מוגן', כפי שמוסבר כאן.
לוחצים על 'נתונים קשורים'. הוספת נתונים שקשורים לקליק אל browserSignals. אנחנו מבקשים כרגע הבהרה לגבי מועד הקליק כדי לספק מיקום ראשוני.
(דיווח גם ברבעון הרביעי של 2022) פונקציות מוגדרות על ידי משתמשים בקהל מוגן איך תהיה תמיכה בפונקציות בהגדרת משתמש (UDF) ב-Protected Audience API? אלה פונקציות שמשתמשי הקצה יכולים לתכנת כדי להרחיב את הפונקציונליות של ה-API. צוות הטכנולוגיה של מודעות הווידאו שציין את הבעיה הזו ציין גם שהם עדיין בודקים מה הם יכולים לעשות עם UDF, כך שאין עדיין משוב שאפשר לפעול לפיו, לפחות לא עד שהתכונה תהיה זמינה לכולם.
מטבע אסור לייצג סכומי מטבע באמצעות נקודות צפות. טיפלנו בבעיה הזו כאן בפירוט.
יכולות לבחירת מודעות שלא מחייבות DSP מהי התפקיד של שרתי המודעות במכרזים של Protected Audience API? אנחנו מודעים לבקשות של ספקי מודעות להמשיך להציע שירותי בחירת מודעות לאחר הגשת הצעת המחיר או שירותי אופטימיזציה של נכסי קריאייטיב דינמיים. אנחנו בודקים כרגע את ניתוח הפער המפורט שקיים בין Protected Audience API הנוכחי לבין הבקשות האלה.
GenerateBid תמיכה בהצעה של Google Ads להחזיר יותר ממודעת מועמדת אחת לכל קבוצת תחומי עניין של מודעות מ-generateBid, ולתת לכל המועמדות ניקוד ב-scoreAd. אנחנו בודקים את הנושא הזה כרגע. נשמח לקבל משוב נוסף כאן.
הזמנת מכרז האם מכרזים של Protected Audience API צריכים להיות המכרזים האחרונים שפועלים כדי שיוכלו לקבל קלט מהתוצאות של כל המכרזים האחרים? אין דרישה טכנית לכך ש-Protected Audience API יפעל אחרון.
ניווט שלא התחיל על ידי המשתמש חשיפת ניווט שלא ביוזמת המשתמש אנחנו בודקים את הבקשה הזו ומדברים עליה כאן . נשמח לקבל משוב נוסף.
שמירה במטמון אם מצב המשתמש משתנה, ה-SSP לא צריך ליצור את perBuyerSignals של DSP נתון מהמטמון. אנחנו מבינים ששימוש במטמון לא מתאים לכל תרחיש לדוגמה של אותות perBuyer, ואנחנו בודקים אפשרויות נוספות. נשמח לקבל משוב נוסף מהסביבה העסקית לגבי האופן שבו האחסון במטמון יכול להתאים לתרחישי השימוש שלהם.
דוחות שיוך (Attribution) ו-Protected Audience איך אפשר לשלב בין Attribution Reporting API לבין Protected Audience API? השילובים של Protected Audience API זמינים כרגע בשני המצבים של Attribution Reporting API (דוחות ברמת האירוע ודוחות סיכום). ב-1 ביוני פרסמנו מידע נוסף על השיפורים בשילוב של Protected Audience API ודיווח שיוך (Attribution). כאן אפשר לקרוא מידע נוסף עליהם.
נקודת קצה (endpoint) של שרת האם נקודת הקצה של השרת תהיה שרת הצבירה המהימן בתכנון הסופי? נקודת הקצה של השרת היא נקודת קצה שמנוהלת על ידי טכנולוגיית הפרסום, והיא עצמאית משרתי הצבירה המהימנים שמשמשים לעיבוד הדוחות שנאספו והועברו טרנספורמציה. בשלב הזה אין לנו שינויים מתוכננים בנקודת הקצה לדיווח. המטרה של העיצוב הנוכחי היא להבטיח שהדוחות שאפשר לצבור (עם עומסי נתונים מוצפנים) לא יגרמו לדליפת נתונים בין אתרים, כך שלא צריך נקודת קצה מהימנה. בעיה נוספת היא שסביר להניח שלטכנולוגיות פרסום שונות יהיו אסטרטגיות רצויות שונות של קיבוץ. נשמח לקבל משוב נוסף כאן.
WebIDL המפרט הנוכחי של Protected Audience API לא תואם למפרט WebIDL. אנחנו מעריכים את המשוב הזה ומדברים על הבעיה כאן.
ניהול הסכמה איך יתבצע העברת אותות ההסכמה ב-Protected Audience API? מידע לפי הקשר לא נכלל בהיקף של Protected Audience API. אנחנו דנים בבעיה הזו ונשמח לקבל משוב נוסף.
שיווק מבוסס-חשבון האם אפשר יהיה להשתמש ב-Account-Based Marketing בתרחישים לדוגמה? Protected Audience API תומך במגוון תרחישים לדוגמה של שיווק מבוסס-קהל. אנחנו ממשיכים לבדוק איך Protected Audience API יכול לתמוך בצורה הטובה ביותר בתרחיש השימוש הספציפי הזה, ואנחנו מקבלים בברכה משוב נוסף על הבעיה הזו מהסביבה העסקית.
מכרז רכיבים מהו הדירוג של המשתתפים במכרזים של רכיבים? במכרזים של הרכיבים לא ניתנים ציונים ישירות לקבוצות העניין, אלא למודעות ולבידינגים שמערכת ניהול רשתות המודעות שולחת מהפונקציה generateBid. הפונקציה generateBid() פועלת לכל קבוצת תחומי עניין, ומערכת ה-DSP מחזירה את הערך הבא כשמריצים את generateBid: ‏ 

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

תרומות חיצוניות בקשה לתמיכה בתרומות חיצוניות ב-code base של שרת המפתחות/הערכים ב-GitHub. אנחנו רוצים לעדכן את התהליכים הרלוונטיים שלנו כדי לתמוך בתרומות חיצוניות לקוד ב-GitHub.
גודל קבוצת האינטרסים מהו המספר המקסימלי של מפתחות ש-IG יכול לתמוך בהם? המגבלה הנוכחית היא 50KB ל-IG אחד, והמפתחות נספרים כחלק ממנו. נשמח לקבל ממך תגובות נוספות לגבי מגבלת הגודל.
ארגון בקבוצות איך אפשר לצמצם את מספר הקריאות לשרת K/V? אפשר להשתמש בכותרות HTTP Cache-Control כדי לצמצם את מספר הקריאות ל-K/V. לדוגמה, הוא יכול להישמר במטמון במכרזים של רכיבים וגם במיקומי מודעות בדף אחד.
ניהול הגרסאות תמיכה במספר גרסאות של קוד טכנולוגיית פרסום שירותי הבידינג והמכרזים יתמכו במספר גרסאות של קוד טכנולוגיית הפרסום. ב-Bidding and Auction API, בבקשה SelectAd אפשר לציין את גרסת הקוד ששימשה לבקשת המכרז (כלומר לבידינג או למכרז וגם לדיווח).
Shared Storage תמיכה בכתיבת נתונים לאחסון משותף בשירות הבידינג והמכרזים. בשלב זה, שירותי הבידינג והמכרזים לא תומכים באחסון משותף, אבל נשמח לקבל משוב נוסף על הסיבות לכך שתרחישים לדוגמה כאלה חשובים לסביבה העסקית.
מאתר לאפליקציה תמיכה בשיתוף של קבוצות של תחומי עניין מהאתר לאפליקציה. נכון לעכשיו, תרחיש הדוגמה 'מאתר לאפליקציה' לא נכלל בהיקף הפריסה של Protected Audience API ב-Chrome וב-Android, אבל אנחנו רוצים לשמוע מהסביבה העסקית על החשיבות של תרחיש לדוגמה הזה.
K-Anonymity איך מטפלים בחלופות ל-K-anonymity אנחנו דנים בבעיה ונשמח לקבל משוב נוסף.

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

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

נושא המשוב סיכום תגובה מ-Chrome
הגדרות חלופיות של דוחות ברמת האירוע ב-VTC משוב על הגדרות חלופיות של דוחות ברמת האירוע ב-VTC קיבלנו משוב על כך שההגדרות הנוכחיות ברמת האירוע לא אופטימליות, ולכן אנחנו מבקשים מכם לשלוח משוב על הגדרות אופטימליות ברמת האתר. אנחנו פתוחים למשוב נוסף בנושא הזה, ואנחנו חושבים שהסבר הגמיש שלנו לגבי אירועים עוזר גם בנושא הזה.
הגדרות גמישות ברמת האירוע מהו הסטטוס של התכונה 'הגדרות גמישות ברמת האירוע'? שיתוף מסמכים בנושא הגדרות גמישות ברמת האירוע התכונה עדיין בשלב ההצעה, ואנחנו מחפשים משוב נוסף כדי להבין אם היא תהיה מועילה לסביבה העסקית.
הגדרות גמישות ברמת האירוע איך אפשר להתאים בין דוחות סותרים של גורמים שונים? רוב תרחישי הדיווח מטופלים באמצעות דוחות מצטברים, ואילו ההצעה להגדרה גמישה ברמת האירוע נועדה במיוחד לספק גמישות נוספת בדוחות ברמת האירוע, שבדרך כלל משמשים לתרחישי אופטימיזציה. נשמח לקבל מכם הערות או משוב נוסף לגבי הסביבה העסקית לגבי התרחיש הזה.
הרשמה של מקור מה קורה אם רישום המקור מתבצע אחרי רישום הטריגר? בשלב זה, אם רישום המקור מתרחש אחרי רישום הטריגר, לא ניתן יהיה לשייך את המקור לטריגר. נראה שמדובר בתרחיש קיצוני. נשמח לקבל משוב נוסף לגבי הבעיה הזו, ונטפל בה אם נראה שהיא קיימת אצל הרבה טכנולוגיות פרסום.
עבודה עם כמה סוכנויות פרסום איך פלטפורמות DSP יכולות להשתמש ב-Attribution Reporting API כשמפרסם עובד עם כמה סוכנויות פרסום? ה-API תומך בהפניות אוטומטיות, ולכן אפשר להשתמש בו גם אם המפרסם עובד עם כמה סוכנויות פרסום. בנוסף, יש כמה הגבלות בנוגע להפניות אוטומטיות כדי להבטיח ש-API יעזור לשפר את הפרטיות. זיהינו גם פתרון אפשרי באמצעות Shared Storage API לתרחיש הספציפי שצוין על ידי חברת טכנולוגיית הפרסום. נשמח לקבל משוב נוסף לגבי התרחיש הזה, ונמשיך לפתח אותו על סמך המשוב הזה.
מגבלות על יעדי מודעות אם יש הגבלות על יעדים, הן עשויות להשפיע על התרחיש לדוגמה של מודעות עם רענון אוטומטי. דנו בבעיה הזו בפגישה של WICG ב-1 במאי, ואנחנו מחפשים משוב לגבי מגבלה סבירה. הוספנו להסבר על דיווח שיוך באמצעות דוחות ברמת האירוע את ההצהרה שדפדפן יכול להגביל את מספר כתובות ה-eTLD+1 של 'יעד' שמיוצגות על ידי אתרי מקור. (בקשת משיכה).
דוחות שיוך (Attribution) ו-Protected Audience איך אפשר לשלב בין Attribution Reporting API לבין Protected Audience API? השילובים של Protected Audience API זמינים כרגע בשני המצבים של Attribution Reporting API (דוחות ברמת האירוע ודוחות סיכום). ב-1 ביוני פרסמנו מידע נוסף על השיפורים בשילוב של Protected Audience API ודיווח שיוך (Attribution). כאן אפשר לקרוא מידע נוסף עליהם.
הגדרות גמישות ברמת האירוע עכשיו, כשאפשר להגדיר את הפרמטרים, אפשר לשתף שיטות מומלצות לסימולציה של רעש. שיתפנו קוד ב-GitHub שכל אחד יכול להשתמש בו כדי להעריך את הרווח במידע ואת ההשפעה של הרעש בכל הגדרה גמישה ברמת האירוע שהוא רוצה לבדוק. נשמח לשמוע מכל מי שבחר לבדוק את הקוד ולשתף משוב.
מדידת שיוך בין אפליקציות לאתרים מתי תהיה זמינה מדידת שיוך (Attribution) בין אפליקציות לאתרים? ב-9 במאי הכרזנו על ניסוי למדידת שיוך (Attribution) בין אפליקציות לאתרים באמצעות Attribution Reporting API. אנחנו מתכננים להשיק את ממשקי ה-API למדידת הרלוונטיות ולמדידה ב-Chrome 115, אבל בשלב זה אנחנו לא מתכננים להשיק את המדידה המשולבת של שיוך בין אפליקציות לאינטרנט ב-Chrome 115.
הסרת כפילויות מההמרות איך אפשר להתאים פתרונות עצמאיים למדידת ביצועים ל-ARA? כמו בשיטה הרגילה הקיימת, המפרסמים יעבדו עם ספק מדידה עצמאי של צד שלישי כדי לבטל כפילויות בדיווח על המרות. פרסמנו משאבים שיעזרו לכם לבטל כפילויות של המרות לצורך דיווח ברמת האירוע.
אובדן נתונים במהלך עדכוני מסדי הנתונים של דוחות השיוך (Attribution) האם יהיו אובדן נתונים כשמערכת Chrome תעדכן את מסד הנתונים של דוחות השיוך, כפי שהודענו? החל מגרסה 115 של Chrome Stable, נתחיל להפעיל את ממשקי ה-API של התאמה אישית ומדידה עבור חלק ממשתמשי Chrome כברירת מחדל. אנחנו נרחיב את הזמינות הכללית בהדרגה, תוך מעקב אחר בעיות פוטנציאליות. המטרה היא להגיע לזמינות של 100% תוך כמה שבועות, עד לרבעון השלישי של 2023. התאריך הזה יתואם לסיום תקופת הניסיון של המקור 'רלוונטיות ומדידה'. החל מיולי, הבודקים יוכלו להירשם לקבלת גישה לממשקי ה-API האלה במסגרת הזמינות הכללית. כך תהיה חפיפה בין זמינות תקופת הניסיון במקור לבין הזמינות הכללית דרך ההרשמה. אסימון תקופת הניסיון של המקור יהיה בתוקף עד 19 בספטמבר, אבל מומלץ להירשם לממשקי ה-API לפני תאריך התפוגה כדי לעבור בצורה חלקה מתקופת הניסיון של המקור בלי להפריע לבדיקות המתמשכות.

כפי שצוין בהודעה הזו, הנתונים שנרשמו מגרסאות ישנות יותר (M113 וגרסאות קודמות) לא יועברו אחרי העדכון, ולכן ייתכן אובדן נתונים. אובדן הנתונים הזה לא יופיע בדוחות ניפוי הבאגים, ואנחנו ננסה למנוע אובדן נתונים מ-114 ל-115.
חיוב שימוש בדוחות שיוך (Attribution) לחיוב לפי עלות להמרה כפי שצוין במאמר הזה, יכול להיות ש-Attribution Reporting API לא יתאים לצורכי חיוב לפי עלות להמרה, בגלל הרעשי רקע שנוספים לדוחות ברמת האירוע ולדוחות הסיכום. אנחנו מעודדים את הגורמים בסביבה העסקית לשתף משוב על ההשפעה של Attribution Reporting API על מודלים שונים של חיוב ב-GitHub.

Aggregation Service

נושא המשוב סיכום תגובה מ-Chrome
שינוי של עיכוב הדוחות שאפשר לצבור תגובות חיוביות להצעה לשנות את עיכוב הדוחות הניתנים לצבירה מ-[10-60 דקות] ל-[0-10 דקות] בעקבות משוב מהסביבה העסקית אנחנו שמחים לראות תגובה חיובית לשינוי המוצע, ומעודדים את הסביבה העסקית להמשיך לשלוח משוב על ההצעות שלנו.
פתרון מקומי האם אפשר לפרוס את שירות האגרגציה במרכזי נתונים מקומיים? אנחנו בודקים אפשרויות תמיכה פוטנציאליות מעבר לפתרונות מבוססי-ענן, אבל בשלב הזה לא ניתן לתמוך ב-TEEs מקומיים בגלל מגבלות האבטחה המקומיות, שיחייבו הערכה זמן-לוקחת של ארגז החול לפרטיות. בהתאם לדרישות האבטחה של ארגז החול לפרטיות ולאתגרים המשמעותיים שמציגות פריסות בארגון, אנחנו מאמינים שהדרך הטובה ביותר לשפר את הסביבה העסקית היא להמשיך להרחיב ולשפר את הפריסות מבוססות-הענן (למשל, תמיכה ב-GCP בנוסף ל-AWS). עם זאת, אנחנו מקבלים בברכה משוב נוסף לגבי הסיבה לדרישה הזו.
עיבוד מחדש של דוחות לתקופות זמן שונות היכולת לעבד מחדש דוחות לתקופות זמן שונות קיבלנו בקשות דומות לאפשרות לפצל קבוצות של נתונים לטווח תאריכים שונה. הצעה אחת היא לאפשר להרחיב את המזהה המשותף באמצעות תווית שמוגדרת על ידי טכנולוגיית הפרסום, כדי שניתן יהיה לפצל דוחות למקבצים שונים. אנחנו רק בתחילת התהליך של הערכת התהליך הזה, ונעדכן את הסביבה העסקית בהתאם להתפתחות ההצעה.
השלכות על הפרטיות של סביבת מחשוב אמינה תגובות חיוביות לגבי ההשלכות של סביבת מחשוב אמינה על הפרטיות אנחנו שמחים לשמוע על תגובות חיוביות מהסביבה העסקית לגבי ההצעות שלנו, ונשמח לקבל משוב נוסף בזמן שנמשיך לפתח את הנושא.
תנאים והגבלות מהו המועד האחרון לאישור התנאים וההגבלות של שירות האגרגציה? עדיין לא קבענו מועד אחרון לאישור התנאים וההגבלות, אבל אנחנו ממליצים לחברות בסביבה העסקית לאשר את התנאים וההגבלות בהקדם האפשרי כדי למנוע עיכובים בהרשמה. אנחנו ממליצים לחברות לפנות אלינו בכל שאלה.
Key Discovery תכונת זיהוי המפתחות תאפשר לבודקים לשלוח שאילתות לגבי דוחות מצטברים בלי שתצטרכו את הרשימה המפורשת של שילובי המקשים האפשריים, כדי לעבד דוחות סיכום של שיוך בערוצים שונים לשיפור הביצועים והדיוק. אנחנו בודקים כרגע פתרונות אפשריים ופתרונות זמניים, ונשמח לקבל משוב נוסף מהסביבה הכוללת.

Private Aggregation API

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

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

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

נושא המשוב סיכום תגובה מ-Chrome
(הדיווח יתבצע גם ברבעון הראשון של שנת 2023) טיפים לגורמי צורה נוספים בקשה להוספת גורמים נוספים של גורם משתמש (UA-CH) כמו טלוויזיה, VR אנחנו עדיין עובדים על כמה החלטות עיצוב מרכזיות (למשל, האם לספק ערך יחיד כמו 'טלוויזיה' או רשימה של יכולות של גורם צורה), אבל אנחנו עדיין מעוניינים ליצור אב טיפוס של הרעיון הזה.
מכסת פרטיות הגבלות על תקציב הפרטיות עלולות לגרום לכך שבקשות UA-CH לא יהיו חד-משמעיות כשנשלחות יותר מדי בקשות. בשלב הזה אין לנו עדכונים חדשים לגבי ההצעה 'תקציב פרטיות', אבל התחייבנו לא להגביל בקשות להנחיות לקוח של UA לפני שהוצאנו משימוש את קובצי ה-cookie של צד שלישי.
תאימות לאתר אתרים משתמשים במותג UA-CH כדי להגביל את הגישה של דפדפנים מסוימים לאתרים. יש תרחישים לדוגמה שבהם כדאי להשתמש ברשימת מותגים, ואחד מהם הוא תאימות. חשבון UA יכול לכלול כמה מותגים כדי לעקוף את הבעיות האלה.

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

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

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

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

מכסת פרטיות

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

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

קבוצות מאינטראקציה ישירה (First-Party Sets)

נושא המשוב סיכום תגובה מ-Chrome
(דווח גם ברבעונים קודמים) מגבלת דומיינים בקשה להרחבת מספר הדומיינים המשויכים מערכת Chrome בוחנת את המגבלה המספרית המתאימה לקבוצת המשנה המשויכת, שתאזן בין הפרטיות לבין התועלת בתרחישים לדוגמה שזוהו. כבר בהתחלה, נציגי Chrome ציינו שהמספר המדויק של קבוצת המשנה המשויכת עדיין לא נקבע.
תרחיש לדוגמה מוטמע תמיכה בתרחישי שימוש מוטמעים שדורשים קבוצות של צד ראשון, צ'יפים ואחסון משותף קיבלנו את המשוב שלך לגבי תרחיש לדוגמה הזה ב-Chrome, והצוות שלנו בודק את הנושא ומקבל בברכה משוב נוסף.
ניהול מאגרים מידע על כללי המדיניות להסרת דומיינים של צד ראשון מהמאגר ב-GitHub אם יש אי-התאמות או הזנחה המשוב על תרחיש השימוש הזה התקבל ב-Chrome. הצוות בודק את הנושא ומקבל בברכה משוב נוסף.
הדרכה למשתמש כדי להגביר את השימוש ב-Chrome, צריך להגביר את המודעוּת של המשתמשים לקבוצות מאינטראקציה ישירה (First-Party) ולהבין אותן. אנחנו ב-Chrome מחויבים להסביר למשתמשים על קבוצות מאינטראקציה ראשונה, ולשם כך פרסמנו מאמר במרכז העזרה (שמקושר מממשק המשתמש של Chrome). אנחנו גם משקיעים ב-Chrome כדי להמשיך ללמוד איך להדריך את המשתמשים בצורה הטובה ביותר בהקשרים המתאימים.
פוסט 3PCD קובצי cookie של צד שלישי ימשיכו להתקיים בקבוצה של דומיינים מהצד הראשון אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. אמנם requestStorageAccess ו-requestStorageAccessFor מאפשרים שוב להשתמש בקובצי Cookie של צד שלישי בתרחישי שימוש ספציפיים ומוגדרים בבירור, אבל עכשיו הם דורשים הפעלה פעילה על ידי האתר, במקום להיות זמינים כברירת מחדל, כמו המצב הנוכחי של קובצי Cookie של צד שלישי (ב-Chrome).

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

מידע נוסף זמין למשתמשים במאמר במרכז העזרה (הקישור מופיע בממשק המשתמש של Chrome). אנחנו מתכננים להרחיב את המדריך למפתחים הקיים ככל שהקצב של FPS יגדל עד 100%.
שליחת קבוצות מאינטראקציה ישירה משנים את השם של הקובץ הנדרש .well-known/first-party-set כך שיכלול סיומת ‎ .json. ביצענו את השינוי הזה כדי להבטיח תמיכה בתוכניות מסוימות של אירוח אתרים.
רישום ב-IANA first_party_sets.JSON צריך להיות רשום ב-IANA אנחנו בוחנים את ההצעה ונשמח לקבל משוב נוסף כאן.

Fenced Frames API

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

Shared Storage API

נושא המשוב סיכום תגובה מ-Chrome
שימוש נרחב יותר אחסון משותף צריך להיות סטנדרט לכל תעשיית האינטרנט שזמין בכל הדפדפנים. אנחנו מקבלים בברכה את המשוב הזה ומבינים את החשיבות שלו. אנחנו ב-Chrome ממשיכים להשתתף באופן פעיל בפורומים של W3C כדי לקדם את ההצעה, לקבל משוב ולעודד את השימוש בה.
שערי פלט שערי הפלט של האחסון השיתופי מוגבלים מדי. אנחנו מביאים בחשבון את המשוב הזה, ונשמח לקבל משוב נוסף מהסביבה העסקית לגבי הסיבה לכך ששערי הפלט מוגבלים מדי.
תאימות לתקנות איך Shared Storage יטפל בתאימות לתקנות, כמו מדיניות שמירת נתונים? אחסון משותף מספק את הגמישות להטמיע ולשנות לוגיקה כדי לשלוט במחזור החיים ובתוקף של כל נתון שנשמר. טכנאי הפרסום יכולים לעדכן או לנקות נתונים באחסון השיתופי על סמך חותמות זמן של כתיבת.
A/B Testing איך מבצעים בדיקות A/B של אחסון משותף ו-Protected Audience API? אנחנו פועלים לפרסום הנחיות נוספות בנושא הזה, ומקווים לשתף פרטים נוספים בעתיד.
מגבלת האחסון המשותף מה יקרה אחרי שתגיעו למגבלת האחסון השיתופי? אם תגיעו למגבלה, לא יישמרו עוד נתוני קלט.
מספר גישות באותה טעינת דף מה קורה כשמתבצעת גישה לאחסון משותף כמה פעמים באותה טעינת דף? הדרך הטובה ביותר לטפל בבעיה הזו היא באמצעות הפונקציה window.sharedStorage.append(key, value). במקום לעדכן את הערך לכל מודעה, דבר שעלול לגרום להתנגשויות אם יש כמה מודעות. פונקציית ה-append רק תוסיף את הערך החדש בסוף הערך הקיים.
פונקציונליות של iframe האם אחסון משותף יתמוך בפונקציונליות מסוימת של iframe אחרי שהיא תפסיק לפעול בעקבות ההוצאה משימוש של קובצי Cookie של צד שלישי? אחרי ההוצאה משימוש של קובצי cookie של צד שלישי, האחסון המקומי ברכיבי iframe יחולק למחיצות על ידי האתר ברמה העליונה, אבל רכיבי ה-iframe עצמם לא ייחסמו. אי אפשר לשכפל את הנתונים באחסון המקומי של iframe בכמה אתרים ברמה העליונה, אבל עדיין אפשר להשתמש באחסון המקומי בתוך ה-iframe.

CHIPs

נושא המשוב סיכום תגובה מ-Chrome
מגבלת מחיצות 10KB לכל אתר מחולק עדיין גדול מדי, ורצינו להקטין אותו. כבר צוינה ב-CHIPS עמדה חיובית של Firefox. לגבי תמיכה ב-Webkit, אנחנו ממליצים למפתחים לשלוח משוב ישירות ל-Apple ב בעיה הזו ב-GitHub לגבי התרחישים לדוגמה שבהם הם מעדיפים להשתמש בקובצי cookie מחולקים על פני אחסון מחולק.
הטמעות מאומתות רכיבי CHIP עשויים להשפיע על תהליך הכניסה הנוכחי ל-SSO בגלל חלוקה שונה למחיצות שמשפיעה על הטמעות מאומתות. אנחנו מתכוונים להשתמש ב-Storage Access API (עם הנחיות למשתמשים) כדי לתמוך בתרחיש לדוגמה של הטמעות מאומתות, ושלחנו לאחרונה הודעה על כוונת פיתוח אב-טיפוס.
כללי מדיניות לכל החיים האם מדיניות החיים האפשרית תחול על קובצי cookie מהדומיין הנוכחי? בשלב זה, אין לנו כוונה להטיל מגבלות לכל משך החיים על קובצי cookie מהדומיין הנוכחי.

FedCM

נושא המשוב סיכום תגובה מ-Chrome
תמיכה בהרשאות OAuth הגדרת היקפי הרשאות OAuth שאינם קשורים לפרופיל אנחנו מחפשים באופן פעיל משוב מקהילת Web Identity דרך W3C FedID CG לגבי הדרכים הטובות ביותר לתמוך בהרשאה מעבר לאימות בסיסי לאחר ההוצאה משימוש של קובצי cookie של צד שלישי.
תמיכה ב-SAML התאמה לדרישות לתמיכה ב-SAML הצוות מחפש באופן פעיל משוב מקהילות המחקר והחינוך לגבי הצרכים שלהם לתמיכה ב-SAML (בנוסף לתמיכה ב-OpenID Connect) לאחר ההוצאה משימוש של קובצי cookie של צד שלישי.

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

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

נושא המשוב סיכום תגובה מ-Chrome
בדיקת אותות חדשים כמה שותפים הביעו עניין חיובי בבדיקה של אותות שמתקבלים מהדפדפן לגבי תקינות המכשיר או אמון המשתמשים. בדרך כלל, הם גם זהירים לגבי אותות חדשים שנוצרו למטרה ספציפית, כי הם לא בטוחים שהם מספיקים כדי לשמור על רמות הזיהוי הנוכחיות של תרמיות. אנחנו שמחים לבחון הצעות חדשות יחד עם הקהילה למניעת הונאות ולשמירה על בטיחות האינטרנט, וגם להכיר בחששות שלהם ולשתף אותם. זו בדיוק הסיבה לכך ש'מאבק בספאם ובתרמיות' הוא אחד מתחומי העבודה המרכזיים של ארגז החול לפרטיות, ולכך שאנחנו ממשיכים לתת עדיפות להשקעה בשמירה על בטיחות האינטרנט תוך שיפור הפרטיות של המשתמשים.
משוב חיובי על PST כמה שותפים הביעו עניין בבדיקה או בשימוש ב-PST בתרחישי שימוש שונים למניעת הונאות או לבטיחות באינטרנט. אנחנו שמחים לשמוע על התמיכה והעניין שלכם בבחינת פתרונות חדשים שמשתמשים ב-PST. יש לנו מקורות מידע וקוד לדוגמה שזמינים באתר למפתחי Chrome, ונשמח לקבל משוב נוסף.
הונאה וניצול לרעה הנחיות למניעה או לזיהוי של הונאות בפרסום במסגרת המדידה אחרי ההוצאה משימוש של קובצי cookie של צד שלישי, כשהמזהים כבר לא זמינים. השקנו כלים כמו אסימוני מצב פרטיים, שעוזרים לשחזר חלק מהאות שאבד בגלל קובצי cookie של צד שלישי למטרות מניעת הונאות, אבל עם אמצעי בקרה חדשים על הפרטיות. אנחנו משקיעים באופן פעיל בהצעות חדשות למניעת הונאות ושימוש לרעה, כדי לשמור על היכולות של ארגז החול לפרטיות גם אחרי שינויים אחרים.
שיעור העברת המידע מהנפיק למקור שיעור המידע מהנפיק למקור גבוה מספיק כדי לזהות משתמשים ייחודיים. עדכנו את המפרט כדי להבהיר יותר אילו נתוני משתמשים אפשר להעביר באמצעות אסימוני מצב פרטי. מעצם הגדרתו, אפשר להשתמש בעד שישה מפתחות ציבוריים בו-זמנית, שיכולים לייצג 'מצב' של משתמש מסוים. אפשר לעדכן את קבוצות המפתחות האלה רק כל 60 יום (למעט במקרים נדירים שבהם יש צורך בהחלפת מפתחות חירום), ולכן קשה יותר לצרף נתוני משתמשים נוספים לאורך זמן. בכל ממשק API חדש לאינטרנט, יש איזון בין התועלת שהוא מספק לבין המידע החדש על המשתמשים שהוא מספק. אנחנו מעריכים ש-PSTs מספקים את האיזון המתאים בין הגנה על פרטיות המשתמשים לבין תרחישי שימוש מרכזיים למניעת הונאות שמושפעים מהוצאה משימוש של קובצי cookie של צד שלישי.
אחזור שילוב השילוב של fetch הוא מסובך ולא הכרחי. יש יתרונות וחסרונות לשימוש ב-fetch, ואנחנו רוצים להמשיך לפתח את התקינה בסביבת האינטרנט, אבל לדעתנו עדיין מוקדם מדי לבצע את השינוי הזה עד שנקבל תמונה ברורה יותר לגבי אופן העבודה של התקן. אם סטנדרט כזה יופיע, אנחנו גם מתחייבים להעביר את מפתחי האתרים לסטנדרט הזה באופן אחראי.
מיקום האחסון הגדרות המפתחות של Private State Tokens צריכות להיות מאוחסנות באותו מיקום שבו מאוחסן פרוטוקול PrivacyPass. במהלך הבדיקה במהלך תקופת הניסיון למקורות, המפתחים ציינו שהם מעדיפים את הגמישות של אחסון המפתחות שלהם בכתובות URL כלליות במקום בספרייה ‎ .well-known. פורמט ההתחייבות למפתחות ב-PrivacyPass לא מתאים במיוחד לגרסה שבה קבוצות המפתחות נועדו לאפשר ערך 'מטא-נתונים ציבוריים' מרומז. אם גרסה כלשהי של PrivacyPass תאושר כתקן עם מטא-נתונים ציבוריים (כ-POPRF, כעיוורון RSA חלקי או כקבוצות מפתחות), יכול להיות שנעבור לגרסה עתידית של PST כדי לתמוך בכך.
הטמעת ה-API בכותרת שאלות לגבי הטמעת הכותרת של ה-API ככל שה-API יתבסס כתקן והשימוש בו בסביבה העסקית יתפתח, נוכל לתמוך גם בגרסה הרגילה ללא כותרות של ה-API הזה, וגם להוציא משימוש את הגרסה עם הכותרות אם השימוש בה יהיה נמוך מספיק, או אם יהיה מספיק כלים או תמיכה למפתחים לדרכים רגילות ליצירת מתאם בין בקשות להנפקה או למשיכה לנתונים אחרים. אנחנו מדברים על הבעיה כאן.
הרשמה האם כדאי לחייב את המנפיקים להירשם אצל ספקי הדפדפנים? עדכנו את המפרט כדי לתאר את תהליך הרישום של מנפיקים של אסימוני מצב פרטי. התהליך הזה כולל תהליך משלו, אבל הוא דומה לתוכניות ההרשמה לשאר העבודות של ארגז החול לפרטיות, שבהן אנחנו מבקשים מהמנפיקים לפרסם הצהרה ציבורית על האופן שבו הם מתכוונים להשתמש ב-PSTs, ולאשר את ההגבלות הטכניות שמגינות על פרטיות המשתמשים.