דוח רבעוני לרבעון 3 של שנת 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 API, 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 |
|---|---|---|
| מוּכנוּת המערכת האקולוגית | מערכות SSP הדגישו את הבעיה של בעלי התוכן הדיגיטלי שאינם מוכנים לבצע את פעולת הפריסה הנדרשת. | ארגז החול לפרטיות מתמקד בחינוך בעלי תוכן דיגיטלי, והוא כולל וובינרים ייעודיים ופגישות עם בעלי תוכן דיגיטלי ומערכות SSP קיימות במטרה לעודד את המשתמשים לבצע את הפריסה. |
| הוצאה משימוש של קובצי cookie של צד שלישי | החששות בנוגע להוצאה משימוש של קובצי cookie של צד שלישי (3PCD) גברו ברבעון הרביעי של שנת 2023, עקב הפסקת חשמל בתחום הטכנולוגיה. | הצוות של CMA שוחח על לוח הזמנים של ארגז החול לפרטיות, והרצף הוביל למוכנות למחצית השנייה של שנת 2024. 'ארגז החול לפרטיות' יפרסם מידע מפורט יותר על הרצף של הגדלת החשיפה ל-3PCD. בכפוף להתחייבויות, 3PCD כפוף לחששות של ה-CMA בנוגע לתחרויות. |
| Google Ad Manager | Google Ad Manager מסרב לחשוף את פלטפורמת ה-API שמקשה על הבדיקה. | התשובה סופקה על ידי Google Ad Manager: מהסיבות שמוסברות בתגובה הזו על ידי Google Ad Manager, התוכניות של Google Ad Manager לשילוב Protected Audience API לא כוללות תמיכה בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי שליטה במכרז ברמה העליונה. |
| Google Ad Manager | ל-Google Ad Manager יש מחיר מינימום סודי שחשוף רק לפלטפורמות SSP של AdX או Open Bidding. | במסמכים הציבוריים של Google Ad Manager, צוין שהזוכה במכרז לפי הקשר מועבר ללוגיקת הדירוג ברמה העליונה ולא לשום מכרז של רכיבים, כולל AdX או Open Bidding. בנוסף, במסמכים האלה מתואר לוגיקת הציון ברמה העליונה: "מערכת Ad Manager תשווה את הצעת המחיר הזוכה בכל מכרז של רכיבים, כולל המכירה הפומבית של רכיבים ב-Ad Manager עבור הצעות מחיר לקבוצות של תחומי עניין אצל הקונים שלה, וגם המודעה לפי ההקשר הטובה ביותר (שנבחרת באמצעות הקצאה דינמית) – ותציג את המודעה עם הצעת המחיר הגבוהה ביותר". |
| Google Ad Manager | מוצרי Google Ads צריכים להיות כפופים לאותם כללים שחלים על מוצרי מודעות של צד שלישי. | מוצרי Google Ads כבר כפופים לאותם כללים שחלים עליהם צדדים שלישיים. |
| בדיקה בסיוע Chrome | הוספת תוויות לדפדפנים שלא נמצאים ב-A או ב-B. | אנחנו לא שוקלים לעשות זאת בשלב זה, מאחר מהחקירה שלנו עולה כי הוספת תוויות שאינן ניסויים עלולה לסבך את חששות הפרטיות בנוגע לתנועה במצב פרטי. |
| סוכנות פרסום | האם סוכנויות וחברות שאין להם JavaScript באתרים יכולים להשתמש בממשקי ה-API של ארגז החול לפרטיות? | כל אחד יכול לקרוא לממשקי ה-API של ארגז החול לפרטיות. אם סוכנות או כל גורם אחר רוצים לפתח טכנולוגיות ישירות בממשקי ה-API. ממשקי API בצד הלקוח דורשים שילוב עם הלקוח, בדיוק כמו קובצי cookie. לרבים מממשקי ה-API, כמו קובצי cookie, יש גם ממשק של כותרת HTTP. כבר ראינו מסגרת אחת בתעשיית המודעות שנקראת Prebid, והיא מפתחת שילובים בצד הלקוח באמצעות ממשקי ה-API. אפשר לעשות זאת גם בארגונים אחרים. |
| פתרונות בצד הלקוח | למה Google מאמצת פתרונות בצד הלקוח בארגז החול לפרטיות, כאשר מהנדס התבטא בעבר בנושא יכולת ההתאמה של פתרונות כאלה בשנת 2012? | הטכנולוגיה לשיפור הפרטיות (PET) כתחום מחקר התפתחה באופן משמעותי מאז 2012, ויחד איתה גם יישומים שניתן להשתמש בהם מבחינה מסחרית. בליבה של ארגז החול לפרטיות נמצאים שילובים של מומחי מוצרים ושירותים שלא היו ניתנים לביצוע לפני יותר מעשור. בנוסף, כוח המחשוב האישי גדל, וכך גם ציפיות הצרכנים מהדפדפנים והציפיות הרגולטוריות לפרטיות. |
| למידת מכונה | מהו השימוש המתוכנן של Google בארגז החול לפרטיות למטרות למידת מכונה? | רוב הסביבה העסקית של טכנולוגיות הפרסום משתמשת כיום בלמידת מכונה, ואנחנו לא צופים שזה ישתנה. ארגז החול לפרטיות לא מונע מחברות פרסום דיגיטלי או מכל אחד אחר להמשיך להשתמש בלמידת מכונה. כמו כן, ארגז החול לפרטיות לא מחייב חברות שמבצעות שילוב עם ממשקי ה-API שלו משתמשות בלמידת מכונה. סביר להניח שחברות ימשיכו לפתח מוצרים ושירותים בדרכים שעונות על הצרכים של הלקוחות שלהן, גם אם זה לא כולל למידת מכונה. כל למידת מכונה שמשתלבים של ארגז החול לפרטיות כן תכיר להם, ולא תוסתר מעיניהם. |
| אימות נתונים | איך חברות יכולות לאמת שהנתונים שהן מקבלות באמצעות ארגז החול לפרטיות מדויקים, והאם Google מוכנה להיבדק דרך ישות כמו המועצה לדירוג מדיה (MRC)? | ממשקי ה-API של ארגז החול לפרטיות נוצרים בתוך פלטפורמת הקוד הפתוח שמופעלת על ידי Chrome. החלקים של ממשקי ה-API שמיועדים לפעול בסביבות הפעלה מהימנות גם הם בקוד פתוח וניתנים לביקורת. כל מי שרוצה לבדוק את הקוד יכול, כולל MRC. |
| (דיווח גם ברבעונים הקודמים) תמיכה בסביבת ייצור | איך Chrome תומך בבעיות טכניות ובהעברות לטיפול ברמה גבוהה יותר בארגז החול לפרטיות שמשפיעות על הסביבה העסקית? | Google מציעה מגוון ערוצים כדי לאפשר לטכנולוגיות הפרסום לדווח על בעיות טכניות, ולאפשר את כל הפעולות הדרושות לטיפול ברמה גבוהה יותר כדי לפתור בעיות כאלה. בנוסף, ב-Chrome אנחנו מצפים לפיתוח ולהתאמה לעומס (scaling) של תהליך כדי לפתור בעיות טכניות והעברות שמשפיעות על התקינות של הסביבה העסקית. אנחנו ב-Chrome מחויבים להבטיח את המשאבים הנחוצים למאמץ הזה. בפוסט למפתחים יש מידע נוסף על הפורומים הציבוריים והפרטיים לקבלת משוב וטיפול ברמה גבוהה יותר. |
| מצבי בדיקה בסיוע Chrome | מידע נוסף על לוחות הזמנים ועל ההטמעות המדויקות של מצבי הבדיקה בסיוע Chrome. | שיתפנו פוסט בבלוג על מצבי בדיקה, ואנחנו פועלים לשיתוף מידע נוסף בקרוב. נשמח לקבל ממך הצעות לגבי גודל התוויות של מצב הבדיקה. |
| שילוב עם תקנים אחרים בתחום | האם ממשקי ה-API של ארגז החול לפרטיות מתחברים ל-TCF גרסה 2.* ולסטטוס ההסכמה או לשניהם? | אנחנו לא מתכננים לשלב ממשקי API של ארגז החול לפרטיות ישירות עם TCF גרסה 2 או סטטוס הסכמה. עם זאת, חברות וקבוצות סחר בתחום מוזמנים להתאים את המוצרים ואת המסגרות שלהן כך שיפעלו בשילוב עם ממשקי API של ארגז החול לפרטיות. לדוגמה, במסגרות כמו TCF, כל משתתף צריך לקבוע את הגישה שלו לגבי תאימות על סמך האות של ה-TCF שהוא מקבל והמדיניות המשויכת ל-TCF. אנחנו מצפים שחברות יחליטו מתי ואיך להשתמש בפונקציות השונות שמציעות אבני הבניין של ארגז החול לפרטיות. |
הרשמה ואימות
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| הגבלה | תהליך ההרשמה מאפשר ל-Google להחליט לאיזו חברה בסביבה העסקית מותר להשתמש בממשקי ה-API של ארגז החול לפרטיות. | תהליך ההרשמה והאימות כולל בעיקרון אימות של הישות (לדוגמה, לישות יש מספר DUNs, היא יכולה לספק קישור למדיניות פרטיות וכן הלאה) והופך את האימות הציבורי לקריאה לממשקי ה-API. ישויות שיכולות לעמוד בדרישות ההרשמה יאומתו. לחברות שאין להן DUNs, אנחנו מספקים ב-Dun & Bradstreet תהליך משלים מזורז כדי לרכוש חשבון DUN. המטרה היא לשפר את אמצעי ההגנה על הפרטיות בממשקי ה-API (באמצעות האמצעים שצוינו) וגם להוסיף שכבה של שקיפות לממשקי ה-API של ארגז החול לפרטיות, כדי שהגורמים שמתעניינים יוכלו להבין טוב יותר מי משתמש בכל ממשק API ואילו אימותים הם מבצעים. נשמח לקבל משובים נוספים בתחום, שכבר שימשו אותנו לעיצוב התהליך. |
| תקורה של הרשמה מחדש | התוקף של קובץ האימות פג כל 12 חודשים, וצריך להירשם מחדש לאתרים. | קיבלנו משוב מהסביבה העסקית ושינינו את הגישה שלנו בהתאם. המשמעות היא שהתוקף של הקבצים לא יפוג אחרי 12 חודשים או אחרי כל פרק זמן מוגדר. אנחנו מעדכנים את המדריך למפתחים בנושא רישום עם הקשר נוסף. |
| קובץ אימות (attestation) | איך משתמשים בקובץ האימות (attestation)? | כל החברות שקוראות לממשקי API של רלוונטיות ומדידה יידרשו עד לתאריך היעד לאכיפה להעלות את קובץ האימות לאתר שלהן ולהשאיר אותו גלוי לכולם כל עוד אתם מתכוונים להמשיך לקרוא לממשקי ה-API. אתרים יכולים לצפות לבקשה אחת לשעה בערך מארגז החול לפרטיות, וגם ישויות פוטנציאליות אחרות עשויות לשלוח שאילתות. התהליך יתבצע דרך המנגנון של מערכת הרישום כדי לשלוח שאילתות לשרתים של ישויות רשומות ולוודא שקובץ האימות תקין. ההצהרות ייכללו בדוחות השקיפות והציבור הרחב יוכל לראות אותן. אנחנו מצפים שחברות יפעלו בהתאם לאימותים שצוינו, כמו גם שאר הסביבה העסקית והגופים הרגולטוריים הרלוונטיים. |
| צירוף | האם ההרשמה היא לפי אתר או לפי מקור? | הרישום מתבצע ברמת האתר. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| ביצועים | חששות בביצועים לגבי ההשפעה של שיעור ההצטרפות ל-Topics באזור הכלכלי האירופי. | אנחנו מציעים לבעלי עניין רלוונטיים לפנות לרשות הרלוונטית להגנה על מידע לגבי הנושא הזה. הדרך הטובה ביותר לטפל בסוגיות כאלה היא לטפל בסוגיות כאלה ולהשפיע על מידת התמריץ של השימוש בטכנולוגיות לשיפור הפרטיות, בין אם על פי חוק או על טיפול כמו מעקב, אלא אם יש צורך באותן גישות לקבלת הסכמה. כתוצאה מכך, יכול להיות שממשקי API כמו אלה שבארגז החול לפרטיות לא יהיו זמינים באותה תדירות. |
| צירוף | האם מגישי הצעות מחיר במורד הזרם צריכים להירשם ל-Topics API כדי להשתמש באותות של Topics מפלטפורמות SSP במעלה? | אין צורך לרשום את המקלטים ב-downstream של נושאים מעבר לקורא הראשוני של Topics API, אבל סביר להניח שרבים מהם רשומים לשימוש אחר ב-API. רשימה של נרשמים לארגז החול לפרטיות תסופק באופן פרוגרמטי, כחלק ממאמצי השקיפות של התוכנית, כך שגורם שמתעניין ב-Topics API יכול לבדוק אם הנמען שאליו הם שולחים נושא רשום אם המתקשר רוצה לעשות זאת. |
| סינון נושאים | לבקש להחיל סינון של מתקשר אחר על הנושאים שהם מאחזרים בדף, כדי לשתף רק את מה שהקונים זכאים לאחזר. | אנחנו שוקלים את הבקשה ומבקשים משוב נוסף מהסביבה העסקית. |
| אי-הכללת אתרים | למנוע מאתרים לתרום לנושאים של המשתמש. | כברירת מחדל, המערכת לא מפעילה את הנושאים. חשוב לציין שתוכן הדף לא נלקח בחשבון בעת בחירת הנושאים, וכל הנושאים נבחרים כדי לוודא שהם אינם רגישים. בנוסף, אתרים יכולים להגביל את הכללת האתר שלהם בחישוב הנושאים באמצעות הכותרת הבאה של מדיניות ההרשאות: Permissions-Policy:
browsing-topics=() |
| תצפית על נושאים | בעלי אתרים יכולים לתת ל-Chrome הרשאות לסווג נושאים לפי תוכן הדף (לדוגמה, ראש או גוף). | בעבר שקלנו להציע פונקציונליות לסיווג אתרים לפי נושאים על סמך תוכן הדפים, והחלטנו לא להתקדם מסיבות אחרות, משיקולי פרטיות ואבטחה. הצעה זו עשויה לצמצם חלק מהחששות האלו, אך לא ברור עד כמה. בגלל תקופת הניסוי הקרובה של CMA, אנחנו לא צופים שהשינוי הזה יתרחש לפני המעבר ל-3PCD. נשמח לקבל ממך משוב נוסף כאן. |
| תצפית על נושאים | לספק לבעלי תוכן דיגיטלי כללי מדיניות מפורטים יותר למתן הרשאות. | יצירת מדיניות הרשאות מפורטת יותר לבעלי תוכן דיגיטלי תאפשר לאתרים של בעלי תוכן דיגיטלי להשפיע באופן שלילי על התועלת של Topics API לסביבה העסקית כולה, מבלי שתהיה לכך השפעה שלילית על יכולת השימוש ב-Topics API באתר עצמו. לדיון מפורט יותר בנושא, אפשר לעיין במדיניות העדכון של ההרשאות לתמיכה בהרשאות נפרדות לאחזור ולתצפית ב-GitHub. |
| נושאים רפואיים ובריאותי | למה טקסונומיית Topics לא כוללת נושאים בקטגוריות 'רפואה' או 'בריאות'? | קטגוריות רפואיות ובריאותיות נחשבות לנושאים רגישים, והן לא נכללות בטקסונומיית Topics. |
| אחזור נושאים | דרך מהירה יותר לפלטפורמות DSP לקבל Topics בלי לאחזר באמצעות כותרות. | שיטות הכותרת מניבות ביצועים טובים יותר ועלותן נמוכה יותר מאשר יצירה של iframe ממקורות שונים וביצוע קריאה ל-document.browsingTopics() ממנו. (צריך להשתמש ב-iframe ממקורות שונים לצורך הקריאה, כי
ההקשר ברמה העליונה לצפייה בנושא חייב להתאים להקשר שממנו מתבצעת הגישה). נדון כאן בהרחבה. |
| אחזור נושאים | בקשות לתמיכה בהעברת Topics דרך כותרות בבקשות לתגי סקריפטים ממקורות שונים. | מנקודת מבט של אבטחה, לא ניתן לעשות זאת. כל מסמך וסביבת הביצוע שלו משויכים למקור יחיד – של המסמך. משאבי משנה של צד שלישי שנטענים ומופעלים באותה סביבה נחשבים בבעלות המקור של המסמך. המטרה היא למנוע דליפה של נתונים ממקור אחד למקור אחר של משתמש שלא הביע הסכמה. לחלופין, אפשר לספק את המאפיין browsingTopics בתגי <script>. מבחינת האבטחה, זה צריך להיות נקי, ולא להאריך את זמן האחזור. אנחנו פתוחים לקבלת
משוב מגורמים שמביעים עניין. |
| מוּדעוּת | לשפר את המוּדעוּת הציבורית ל-Topics API ולאופן השימוש ב-API. | פנינו לבעלי העניין שסיפקו את המשוב, והבעיה נפתרה ב-GitHub.
בהמשך נמשיך לתמוך בהבנה של ה-API בסביבה העסקית, ונשמח לשמוע את הדעות של בעלי העניין. בינתיים, אנחנו מציעים לבעלי עניין שירצו לקבל מידע נוסף על Topics API כדי להכיר את המסמכים שמופיעים במדריך למפתחים של Chrome. |
| התראה | התראה לשליחת התראה למשתמש כשאתר כלשהו בודק את הנושאים שלו. | טיפלנו במשוב הזה ב-GitHub. מידע נוסף על אמצעי הבקרה של 'נושאים' זמין במרכז העזרה של Chrome. |
| למידת מכונה | איך אפשר להשתמש בלמידת מכונה כדי להסיק את הנושאים של המשתמשים? | אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף. |
| שימושיות לסוגים שונים של בעלי עניין | יכול להיות שחברות פרסום קטנות יותר לא יוכלו לראות את Topics API בגלל האופן שבו הדפדפנים מחשבים אותם. | הנושא יוקצה רק למומחי הפרסום הדיגיטלי של Google שזיהו שהמשתמש נכנס לדף הקשור לנושא המדובר בשלושת השבועות האחרונים. אם מומחי המודעות לא הפעילו קריאה ל-API במהלך שלושת השבועות האחרונים למשתמש הזה באתר שעוסק בנושא הזה, הערך שיוחזר יהיה ריק. התכונה הזו מאפשרת לטכנולוגיות פרסום שמספר גדול של בעלי אתרים משתמשים בשירותים שלהן, ולכן יש להם יותר הזדמנויות לתצפית על ביקור באתר של משתמש מסוים, עשויים לקבל יותר נושאים מאשר טכנולוגיות אחרות של מודעות. התכונה הזו חיונית כדי להגן על הפרטיות של ה-API, כי היא מגבילה את הזמינות של המידע על המשתמשים רק לצדדים שכבר יכולים לצפות באותו מידע בסיסי (כרגע באמצעות קובצי cookie של צד שלישי). |
| בקשת XHR | מתי נוציא משימוש את Topics API בבקשות XMLHttpRequest (XHR)? |
כפי שהודענו באוגוסט 2023, התחלנו להפסיק את התמיכה ב-Chrome ב-XHR מגרסת המקור לניסיון ל'זמינות לכלל המשתמשים'. עם ההתקדמות בהתפתחות של Topics API, התמיכה ב-XHR כללה רק למשתמשים שתכונות ה-OT היו פעילות ויצאו משימוש באופן מלא אחרי מיזוג הקבוצות הנפרדות של OT. אם השתמשת ב-Topics עם XHR, האתרים שלך לא יפסיקו לפעול. הנושאים פשוט לא יתווספו לכותרות של בקשות ה-XHR. מומלץ לעבור ל- fetch עבור הבקשה, להשתמש במאפיין
iframe או להשתמש ב-JavaScript API כדי לאחזר נושאים. האחזור נתמך בכל הדפדפנים המודרניים, אבל לא ב-Internet Explorer או ב-Opera Mini. |
| תהליך עדכון הטקסונומיה והסיווג | מידע נוסף על הטקסונומיה של Topics ועל קצב ההפצה של המסווגים, ועל האופן שבו חברות יכולות להתכונן לקראת העדכונים האלה | התשובה שלנו לא תשתנה מהרבעון השני: כפי שפירטנו בפוסט האחרון בבלוג, אנחנו מצפים שהטקסונומיה תשתנה עם הזמן, וכדי שהפיקוח על הטקסונומיה יעבור בסופו של דבר לגורם חיצוני שמייצג בעלי עניין מהענף. שיתפנו את תוכנית הגדלת הנפח גם בקבוצת topics-announce. |
| התנהלות פוגעת | מתקפה פוטנציאלית דרך שרשרת הפניה. | אנחנו בודקים את הבעיה ונשמח לקבל משוב נוסף. |
| סוגים של מלאי שטחי פרסום של בעלי תוכן דיגיטלי | אילו סוגים של מלאי שטחי פרסום של בעלי אתרים תומכים בבדיקות של Protected Audience ו-Topics API? | מבחינת Protected Audience (קהל) או Topics API, לא קיימת הגבלה מהותית לגבי סוגי המלאי של שטחי הפרסום שבהם ניתן להשתמש בהם. |
| זמן הגדלת נפח החשיפה | מומלץ לא להגיע ל-100% בזמן לצבירת נתונים בטקסונומיות חדשות. | בהמשך לבקשת המשוב מהסביבה העסקית ומהדיון במהלך הפגישות של PATCG, הודענו על התוכנית שלנו להשקת הטקסונומיה החדשה. |
Protected Audience API (לשעבר FLEDGE)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| מכירות פומביות ברמה העליונה | יכולת להשתמש בשרת המודעות של Google לבעלי תוכן דיגיטלי, בלי לתת ל-Google Ad Manager שליטה במכרז ברמה העליונה של Protected Audience API. | התשובה סופקה על ידי Google Ad Manager: התוכניות של Google Ad Manager ל-Protected Audience API לא כוללות תמיכה בשרת המודעות של Google לבעלי תוכן דיגיטלי ללא שליטה במכרז של Protected Audience API, מהסיבות הבאות. כדי שנוכל להציג ללקוחות שלנו בצורה נכונה את השוק להצגת מודעות של בעלי תוכן דיגיטלי, שרת המודעות של Google לבעלי תוכן דיגיטלי צריך לשמר את השליטה במכרז ברמה העליונה של Protected Audience API. כשרת מודעות של בעלי תוכן דיגיטלי, התפקיד שלנו הוא לספק לבעלי תוכן דיגיטלי תחזיות כדי שיוכלו לנהל משא ומתן לגבי קמפיינים במכירה ישירה בלי להזמין יתר, ולהקצב את ההזמנות הישירות שלהם בצורה אופטימלית. כדי לעשות זאת, צריך להפעיל את המכרז הסופי כדי להשוות בין כל הביקוש הישיר והעקיף שעומדים בקריטריונים. תחזיות וקצב ניצול התקציב הם הפונקציות המרכזיות שבעלי אפליקציות מצפים לקבל משרת מודעות. ללא חיזוי מדויק, בעלי אתרים עלולים לבצע מכירת יתר של המלאי שלהם, והדבר עלול לסכן את המוניטין העסקי שלהם. גם קצב הפרסום של המודעות הוא קריטי, כי אי-עמידה בחוזי הזמנות עם מפרסמים עלולה גם לגרום נזק ליחסים הישירים בין בעל התוכן הדיגיטלי לבין המפרסם, מה שעלול להוביל להשפעה משמעותית על הפעילות העסקית של בעלי התוכן הדיגיטלי. לכן, אנחנו לא רואים את הפעילות של שרת המודעות של בעל תוכן דיגיטלי בהפעלת המכרז ברמה העליונה של Protected Audience API, בנפרד מהפעילויות האחרות של שרת המודעות של בעלי תוכן דיגיטלי. |
directFrom |
directFromמאפשר ל-Google Ad Manager למנוע לבעל האתר לראות את המחיר של המכרז לפי ההקשר. |
תגובה מ-Chrome: לא ידוע שמידע שמועבר אל runAdAuction() מגיע מהמוכר, אלא אם המוכר מתקשר ל-runAdAuction() מ-iframe משלו. במכרז עם כמה אתרי מכירה, לא יכול להיות שכל אתרי המכירה ייצרו את המסגרת שקוראת ל-runAdAuction(). directFromSellerSignals
טיפל בבעיה הזו על ידי טעינת תוכן מחבילה של משאבי משנה
שנטענה ממקור של בית העסק. כך אפשר להבטיח שלא ניתן יהיה לשנות את האותנטיות ותקינות המידע שמועבר במכרזים של אתרי המכירה הפומבית. אם בעלי התוכן הדיגיטלי רוצים להשתמש ב-Protected Audience API כדי להבין את המידע שספקי הטכנולוגיה שלהם מעבירים למכרזים של Protected Audience API, הם יכולים לבקש מספקי הטכנולוגיה האלה להשתמש בפונקציונליות הזו.התשובה ניתנת מ-Google Ad Manager: שמרנו במשך שנים על דגש על הוגנות במכרזים, כולל ההבטחה שלנו ששום מחיר ממקורות פרסום לא מובטחים של בעל תוכן דיגיטלי, כולל מחירי פריטים לא מובטחים, לא ישותף עם קונה אחר לפני שהוא מגיש הצעת מחיר במכרז. לאחר מכן הודענו על ההתחייבויות לתחרות שלנו ברשות התחרות. במכרזים עם Protected Audience API, אנחנו מתכוונים למנף את directFromSellerSignals, ואנחנו לא משתפים את הצעת המחיר של אף משתתף במכרז עם אף משתתף אחר במכרז, לפני שהוא מסיים את המכרז במכרזים עם כמה אתרי מכירה. חשוב להבהיר, אנחנו לא משתפים את המחיר של המכרז לפי הקשר עם המכרז של הרכיבים שלנו, כפי שמוסבר בעדכון של פרטים נוספים לגבי הדינמיקה של המכרז ברמה העליונה. |
| חשיפת מידע | הדפדפן עשוי לחשוף לוגיקה עסקית רגישה ופרטים חוזיים | אדם שמשתמש בדפדפן אינטרנט יכול לראות את כל מה שקורה בדפדפן. כאשר מכרז של מודעות מתרחש בתוך הדפדפן, ברור שהאדם שבדפדפן שלו יכול לצפות במכירה הפומבית הזו מתרחש, כולל לראות כמה גורמים שונים בוחרים להגיש הצעות מחיר. מכיוון שהדפדפן הוא הסוכן של המשתמש, איננו חושבים שאפשר או רצוי לשנות זאת. עם זאת, רק לאדם שמשתמש בדפדפן יש הרשאות גישה לפעולות האלה. לא ניתן לצפות במכרזים של משתמשים במכשיר באמצעות Protected Audience API, כולל השרת של Google. |
PerBuyerExperiment |
טווח הערכים הנוכחי של PerBuyerExperimentיכול לאפשר לקונים לקשר בין נתוני ההקשר לבין הבקשה של השרת המהימן. |
השימוש ב-Protected Audience API בדרך הזו לא תואם לאימות החובה של ארגז החול לפרטיות, שלפיו משתמשי ה-API לא ינסו לעקוף את ההגנות של ארגז החול לפרטיות. בעתיד, באמצעות הדרישה ששרתי מפתח/ערך יפעלו בסביבות ביצוע מהימנות (TEE) תספק הגנה טכנית מפני המתקפה הזו. |
| מדיניות מקור זהה | יש להשבית את מדיניות המקור הזהה כדי לאפשר שימוש בתת-דומיינים. | אנחנו שוקלים את הבקשה, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
| ניהול גרסאות API | בקשה לניהול גרסאות ולנתוני גרסה לגבי שינויים ב-Protected Audience API. | אנחנו שוקלים את הבקשה, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
| מכירות פומביות מרובה SSP | מתן הרשאה לאותות מכרז ברמה העליונה לבצע מיזוגי JSON עם אות הרכיב auctionSignals. |
אנחנו שוקלים את הבקשה, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
| הגבלה של הצעת המחיר | להגדיל את המגבלה על מספר רכיבי המודעה שמזינים את הצעת המחיר מ-20 ל-40. | אנחנו שוקלים את הבקשה ורוצים לקבל משוב נוסף מהסביבה העסקית כדי להסביר למה זה יכול להועיל. |
| (מדווח גם ברבעונים הקודמים) ביצועים במכרזים של 'קהל מוגן' |
קבלת דוח מבודקים שלמכרזים של Protected Audience יש זמן אחזור ארוך. | בשאלות של זמן אחזור, Protected Audience API פועל בדרך כלל בהתאם לפרדיגמה הרגילה הנוכחית של יצירת אמצעי בקרה, שמאפשרת למוכרים להחליט כמה זמן ומשאבים מגישי הצעות המחיר יכולים לצרוך, וליצור כלים שמאפשרים לקונים להחליט איך להשתמש בצורה הטובה ביותר במשאבים שזמינים להם. באופן כללי, אמצעי הבקרה והכלים האלה זמינים כיום, אבל הקונים והמוכרים יוכלו לממש את מלוא היתרונות שלהם רק אחרי ההטמעה שלהם. בנוסף, Chrome ממשיך לעבוד על מגוון שיפורים בתשתית של מהירות המכרזים (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). אנחנו מזמינים אותך לתת משוב על שני תחומים של זמן האחזור הזה: כלים חדשים שקונים ומוכרים יכולים להועיל להם, ודוחות על צווארי בקבוק שזוהו שהמהנדסים של Chrome צריכים לחקור. |
| סינון בצד הקונה | הוספת תמיכה בסינון בצד הקונה על סמך קבוצות של תחומי עניין. | הצענו כמה דרכים שפלטפורמות SSP ו-DSP יוכלו לשנות את העיצובים שלהם כדי להתמודד עם התופעה הזו:
|
| שליטה על קבוצת תחומי עניין של בעל אתר | תמיכה בבעלי תוכן דיגיטלי שרוצים להאציל את השימוש בקבוצות אינטרס שנוצרו על ידי מוציאים לאור. | ערכנו דיונים עם גורמים רבים לגבי הבקשה. אנחנו מאמינים שכל התרחישים לדוגמה שמעורבים ב "האצלת" של קבוצות האינטרס שנוצרו על ידי בעלי האתרים מתאימים כבר עכשיו, ובנוסף לכך שעלינו לפתח תמיכה נוספת כדי לאפשר שימוש חלק יותר בתרחישי שימוש מסוימים בעתיד. |
| (מדווח גם ברבעון השני) סביבות ביצוע מהימנות | תמיכה בסביבות ביצוע מהימנות (TEE) בסביבות של ענן שאינו ציבורי. | התשובה שלנו דומה לרבעונים הקודמים: אנחנו ממשיכים לבדוק את התמיכה באפשרויות מעבר לפתרונות הציבוריים מבוססי-הענן, אבל כרגע אין לנו תוכניות לתמוך בטכנולוגיות TEE מקומיות. נכון לעכשיו, בגלל דרישות האבטחה של ארגז החול לפרטיות והאתגרים המשמעותיים שנובעים מפריסות מקומיות, אנחנו מאמינים שהמשך התרחבות ושיפור של הפריסות מבוססות-הענן (למשל תמיכה ב-Google Cloud בנוסף ל-AWS) הוא התועלת הרבה ביותר לסביבה העסקית. עם זאת, נשמח לקבל משוב נוסף על הסיבות לכך שדרישה כזו היא הכרחית ואפשרית בהתחשב במגבלות הפרטיות והאבטחה. |
| סביבת ביצוע מהימנה | רכיבים בנתיב ההצגה בסביבת TEE, כמו מאזן העומסים, יכולים לצפות בכל תעבורת הנתונים ולקבל מידע על כתובת ה-IP של כל בקשה. | נכון לעכשיו, כתובות IP מועברות כמטא-נתונים בכותרות של בקשות לשירות המודעות של בית העסק המהימן, במקרה של מכרזים ומכרזים, וגם במכרזים של קהלים מוגנים במכשיר. למידע נוסף כדאי לעיין במאמר העברת מטא-נתונים. בטווח הארוך, אנחנו מתכננים להשתמש בשרת proxy לטכנולוגיות מעקב ולעקוב אחרי תעבורת הנתונים באמצעות שרת proxy ל-IP, מה שימנע מרכיבים להבחין בכל התעבורה בנתיב ההצגה. |
| אורך חיים (TTL) | האם משך החיים (TTL) לפני השירותים יהיה צורך לבקש מפתחות חדשים, או האם הוא אמור להיות גמיש (או דינמי)? | ה-TTL הוא בדרך כלל סטטי. נכון לעכשיו, ה-TTL של הציבור הוא 8 ימים והסבב מתבצע כל 7 ימים. ה-TTL זהה גם למפתחות פרטיים כשמדובר בשירות הצבירה. במקרה של שירותי בידינג ומכרז, המפתחות הפרטיים והציבוריים מאוחזרים בכל N שעות בנתיב ללא בקשה, ונשמרים בזיכרון, כך שלא יהיה יותר מ-N שעות בין הסיבוב של המפתחות לבין השרתים קולטים את המפתחות האלה. בין רוטציית המפתחות לבין התפוגה של המפתחות יש מרווח של יום אחד, כדי לוודא שגם אם יצירת המפתחות תיכשל, השירותים יוכלו להמשיך לפעול. אנחנו שוקלים להאריך את ה-TTL כדי להגן טוב יותר מפני הפסקות זמניות בשירות. במקרה של דליפת מפתח, אנחנו מתכננים לאלץ יצירת מפתחות באופן ידני ולשלול את התוקף של המפתחות מוקדם יותר. שימו לב שהמפתחות הציבוריים נשמרים במטמון של הלקוחות, בשלב הזה למשך 24 שעות, שוב כדי לוודא שבמקרה של הפסקה זמנית בשירות המתאם, השירותים עדיין יוכלו לפעול. |
| עיצוב התנועה | תמיכה בנושא עיצוב תנועה בשירותי בידינג ומכרזים. | הקונים יכולים לציין, על סמך נתונים מאינטראקציה ישירה (First-Party) של בעל התוכן הדיגיטלי או נתונים לפי הקשר, את הביקוש למכרזים של 'קהל מוגן'. המפיצים יכולים לקבוע קביעות דומות גם בשרת המודעות או בשרת Ad Exchange של המפיץ. אפשר לאמן את המודלים לפי נתונים מאינטראקציה ישירה (First-Party) ועל כל הדוחות הנצברים ממכרזים של Protected Audience API. המפיצים יכולים להשתמש במידע הזה כדי למנוע שליחת בקשות לשרתים של בידינג ומכרזים, כשאין ביקוש למכרזים של 'קהל מוגן'. אנחנו מאמינים שזאת יכולה להיות דרך יעילה לעצב את תנועת הגולשים. |
| מכירה פומבית של רכיבים | אילו אתרים ברמה העליונה של מכירה פומבית משותפים עם אתרי מכירה שמשתמשים רכיבים? | קונים במכרזים של רכיבים מקבלים רק אותות מהמוכר של הרכיבים. אנחנו רוצים לשתף בקרוב תיעוד לגבי ההשלכות הכוללות של מכרז משולב עם בידינג ב-header ו-Protected Audience API. |
| רינדור וידאו | תמיכה בעיבוד וידאו באמצעות Protected Audience ו-Fenced Frame. | Protected Audience API תומך בעיבוד וידאו באמצעות מנגנון שמבוסס על מסגרות iframe. עם זאת, עדיין לא פיתחנו פתרון שתואם ל-Fenced Frames, וזו אחת הסיבות לכך שהחלטנו לדחות את האכיפה של Fenced Frames לשנת 2026. כלומר, אם שותף יחליט לאכוף עכשיו את Fenced Frame, התמיכה בסרטון תהיה חסרה. |
| מכסת תדירות | (מדווח גם ברבעונים הקודמים) בקרות תדירות לכל משתמש בקמפיין ובקבוצת מודעות. |
התגובה שלנו לא השתנתה ביחס לדוחות הקודמים: Protected Audience יתמוך במכסת תדירות במכירות פומביות במכשיר, בקמפיינים מבוססי-הקשר ובקמפיינים של מיתוג. אפשר להשתמש גם באחסון משותף ובמכסות ספציפיות לאתר כדי לקבוע אמצעי בקרה נוספים למכסת התדירות. |
| העדפות מודעות | האם Protected Audience מספקת דרך לבטל את ההסכמה לכך או להוסיף לרשימת החסימה דרך אתרים של מפרסמים, או דרך לעזוב את כל הקבוצות של האינטרס מאותו בעלים? | יש כמה דרכים שבהן משתמשים יכולים לחסום את הגישה ל-Protected Audience API ולתכונות אחרות של ארגז החול לפרטיות. |
| מדיניות מקור זהה לגבי כתובת URL של מקור של סקריפטים של בידינג ומכרזים | צריך להסיר את הדרישה שכל השדות שמציינים כתובות URL לטעינת סקריפטים או JSON יהיו מאותו מקור אצל הבעלים. | אנחנו שוקלים כעת את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית. |
forDebuggingOnly |
יש סיכוי שייעשה שימוש לרעה ב-forDebuggingOnly אם הוא יישאר אחרי 3PCD. |
בשנים האחרונות קיבלנו משוב מהמערכת האקולוגית בנוגע לפערים בפונקציונליות של Protected Audience API לאחר ההוצאה משימוש של קובצי cookie של צד שלישי. לאחר מכן, אנחנו עובדים על ניסוח תוכנית לתמיכה ב-3PCD בלי להתפשר על היעדים של ארגז החול לפרטיות. נשמח לקבל הצעות נוספות ומשוב לגבי הפונקציונליות החסרה שהסביבה העסקית רוצה לראות. |
| קבוצות עם תחומי עניין מרובים | שימוש בכמה קבוצות של תחומי עניין באותה הצעת מחיר. | האפשרות הזו לא נתמכת כיום ב-Protected Audience API, כי כתוצאה מכך יחול שינוי במודל הפרטיות הבסיסי. נשמח לדיון נוסף כאן. |
| מכירות פומביות במכשיר | האם Chrome ב-Android יתמוך במכירות פומביות של Protected Audience במכשיר? | כן, מכרזים במכשיר יתמכו ב-Chrome ב-Android. |
| (דווחו ברבעון השני של 2023) נתונים שקשורים לקליקים | הוספת נתונים שקשורים לקליקים ל-browserSignals. | אנחנו ממשיכים לבדוק את הבקשה לתכונה הזו, ונשמח לקבל משוב נוסף לגבי הסיבה שבגללה צריך לתת לה עדיפות. |
| ספקים מהימנים של סביבת ביצוע | האם יש הבדלים מהותיים בין ההיצע של סביבת הביצוע המהימנה של ספקים שונים של שירותי ענן? | לא ידוע לנו על הבדלים משמעותיים, אבל מומלץ לסביבה העסקית לבדוק את מדריכי הפריסה הציבוריים כדי למצוא את הפתרון שהכי מתאים לצרכים שלהם. Google Cloud. AWS |
| (דווח ברבעונים הקודמים) תמיכה בטירגוט של קבוצות לפי תחומי עניין שליליים |
ממשק API שתומך בטירגוט לפי קבוצות של תחומי עניין שליליים: הצגת מודעות רק אם משתמש לא משתייך לקבוצת תחומי עניין. | אנחנו בוחנים את ההטמעה של התכונה הזו ודנים בבקשה. |
| הפרה שקשורה לתוכן | תכונות תמיכה שמאפשרות למשתמשים לדווח על מודעות בעייתיות שהוצגו על ידי Protected Audience API ב-Fenced Frames. | אנחנו סבורים ש מנגנון הדיווח הקיים על מודעות Fenced Frame מציע אפשרויות מתאימות לטכנולוגיות של מודעות שרוצות בתהליך הדיווח של 'מודעות גרועות' שנוצר על ידי משתמשים. כך דיווח על מודעות בעייתיות כמעט שיהיה שונה מהמקובל בתחום כיום. נשמח לשלוח בקשות להוספת תכונות נוספות אם עדיין יש פערים, כולל בפרק הזמן שחלף אחרי ההסרה של קובצי cookie של צד שלישי ולפני שהעיבוד של Fenced Frame הופך לנפוץ. |
| דוחות API לצבירה פרטית | איך אפשר לחשב את הזמן שהמשתמש הקדיש לקבוצת תחומי העניין הזו? | ב-Chrome מגרסה M116 ואילך, אמורה להיות לכם אפשרות להשתמש בעדכניות, כפי שמוגדר ב-pull/639. |
| שרת אנונימי של K | מידע נוסף על שרת אנונימי של K. | שיתפנו מידע נוסף על שרתי K-Anonymity כאן ונשמח לקבל משוב נוסף. |
| כתובות URL של קריאייטיב דינמי | תמיכה בכתובות URL של קריאייטיב ללא הצהרה מראש, תוך שמירה על האנונימיות k. | אנחנו מדברים על הבקשה הזו להוספת התכונה, ושמחים לקבל משוב נוסף שמסביר למה צריך לתת לה עדיפות. |
| דרישה לאנונימיות K | האם נחדש את הדרישה לאנונימיות k בעדכונים של קבוצות תחומי עניין? | אנחנו לא צופים שינויים במיקום שצוין בפוסט הזה ב-GitHub. כפי שהודענו בפוסט הזה, החלטנו להסיר את הדרישה ל-k-anonymity בעדכונים לגבי קבוצות תחומי עניין של Protected Audience API. אין לכך השפעה משמעותית על אמצעי ההגנה על הפרטיות הכוללים של ה-API. לכן, אנחנו מתכננים לשקול את האפשרות להשתמש באמצעי הגנה ישירים יותר (כמו פרטיות של כתובות IP או שרת עדכונים מהימן) במועד מאוחר יותר, אחרי שהטכנולוגיות הקשורות יפותחו, ייפרסו ויאומץ. |
| בדיקות בטא של שירותי בידינג ומכרזים | מתי יתחילו בדיקות הבטא של שירותי הבידינג והמכרזים? | כפי שצוין בציר הזמן ובמפת הדרכים, השלב הראשון של הבדיקה של שירותי הבידינג ושירותי המכרזים מתחיל בנובמבר 2023. |
| שילוב | בקשה לתמיכה בתיאום קריאייטיב ברשתות מודעות (SSP ו-DSP) נמצאים באותה חברה או באותו נכס. | אנחנו מעריכים את המשוב לגבי התרחיש לדוגמה ומעוניינים להבין אם טכנולוגיות פרסום נוספות מעוניינים לראות את האפשרות הזו. נשמח לקבל משוב נוסף. |
| פרסום מותאם | תמיכה ב-Fenced Frame בפרסום מותאם. | אנחנו שוקלים לתמוך בתרחיש לדוגמה ובוחנים פתרונות ופתרונות אפשריים. |
| אנונימיות K | איך אפשר למקסם את המודעות מקבוצות של תחומי עניין שעומדות בערכי הסף האלה? | שיתפנו כמה הנחיות טקטיות בנושא הזה. |
| תמיכה ב-POST | תמיכה בשליחת נתוני מכרזים באמצעות בקשות POST. | אנחנו בודקים את הבקשה להוספת התכונה ומקבלים שליחת בקשות נוספות לגבי בעיות ב-GitHub כדי להסביר למה צריך לתת לה עדיפות. |
| רזולוציית הדיווח | מהי רמת הפירוט של הדיווח בדיווח על מודעות Fenced Frame עם מודעות שמורכבות מכמה חלקים? | העיצוב הנוכחי לא מאפשר לתעד את מזהה המוצר או את המיקום שלו, כי זה עלול לפגוע בפרטיות המשתמשים. אפשר להפעיל רק את
reserved.top_navigation, שיישלח כשיש הפעלה של משתמש
(למשל קליק) בפריים המסווג של רכיב המודעה, וכתוצאה מכך
מתבצע ניווט ברמה העליונה. |
| מכירה פומבית של מודעות | האם SSP שמשתתפים במכרז של רכיבים יכולים להפעיל בעצמו מכרז רכיבים אחר? | componentSeller לא יכול לכלול גם את componentAuctions.המכרז עם כמה אתרי מכירה כולל רק שתי רמות: 1. המכרזים של הרכיבים במקביל. 2. המכירה הפומבית ברמה העליונה (שבה מתחרה המודעה הזוכה מכל componentAuction). |
| הזמינות של שירותי בידינג ומכרזים | האם הבידינג והמכרז יהיו זמינים בשלב הבדיקות של Chrome? | 'שרתי בידינג ומכרזים' לא יהיו זמינים במהלך שלב הבדיקה בסיוע Chrome. |
| אותות של בידינג | דפדפנים יכולים לבקש ולמחוק אותות לבידינג. | אנחנו דנים בבקשה הזו ונשמח לקבל משוב נוסף שמסביר למה צריך לתעדף את הבקשה הזו. |
generateBid() |
יכולת לעדכן את userBiddingSignals של תחום עניין עד updateURL. |
אנחנו שוקלים את ההצעה ונשמח לקבל משוב נוסף ודיון נוסף. |
| סוגים של מלאי שטחי פרסום של בעלי תוכן דיגיטלי | אילו סוגים של מלאי בעלי אתרים ייתמכו על ידי Protected Audience API ו-TOPICS? | מבחינת Protected Audience (קהל) או Topics API, לא קיימת הגבלה מהותית לגבי סוגי המלאי של שטחי הפרסום שבהם ניתן להשתמש בהם. |
| שילוב שרת-אל-שרת | האם יש צורך בשילוב ישיר בין ה-SSP וה-DSP עבור 'קהל מוגן'? | אין צורך בשילוב ישיר בין ה-SSP לבין ה-DSP אם ה-DSP לא צריך לעבד אותות לפי הקשר בשרת שלו, כדי להעביר את המידע המעובד לפונקציית הבידינג במכשיר. |
שדה bid_currency בנכס פרטי |
תמיכה בשדה bid_currency בשירותי בידינג ומכרזים. |
בתי הארחה לא תומכים עדיין בbid_currency, למרות שאנחנו מתכננים לעשות זאת עד סוף ינואר 2024. ציר הזמן מופיע כאן. |
perBuyerSignals |
האם יש מגבלת גודל עבור perBuyerSignals? |
אין הגבלה על מספר האותות לכל קונה, אבל שליחה של יותר מדי נתונים עלולה לפגוע בביצועים של הדפדפן. |
| תרחישים לדוגמה בכמה אתרים | האם אפשר להשתמש בקבוצות אינטרס של Protected Audience API בכמה אתרים? | Protected Audience לא מיועד לתרחישים כאלה, כפי שמוסבר ב-turtledove/issues/282. |
| בקשות HTTP לקבוצות של תחומי עניין | הכללת ה-blob של קבוצת תחומי עניין בכותרות ה-HTTP. | אנחנו שוקלים את הבקשה ונשמח לקבל משוב נוסף לגבי הבקשה. |
| בקרת איכות של מודעות | אובדן של בקרת איכות מודעות שקשורה למידע מאתרים שונים. | אנחנו שוקלים את המשוב הזה ונשמח לקבל משוב נוסף. |
| כלי פיתוח ל-Chrome | בקשות הרשת היוצאות של Protected Audience צריכות להיות מוצגות בכרטיסייה 'רשת של כלים למפתחים ב-Chrome'. | אנחנו פועלים להפעלת הפונקציונליות הזו בכרטיסיית הרשת ונשמח לקבל משוב נוסף שמסביר למה צריך לתת לה עדיפות. |
| סביבת ביצוע מהימנה | מתי יתווספו להסבר על המדדים שמשפיעים על הפרטיות (והתואר שלהם) את הפרטים לגבי המדדים שמשפיעים על הפרטיות? | אנחנו מעדכנים את המידע הזה בהסבר. ההסבר המעודכן יהיה זמין החל מנובמבר 2023. |
directFrom |
למה החבילה directFrom לא ארוזה כחבילת אינטרנט? |
שיתפנו כאן את הנימוק להחלטה הזו. |
| הענקת גישה לחשיפות | האם יש דרך מעשית לבצע האצלת חשיפות כאשר התוצאה של קבוצת עניין שנבחרה היא פעולת מיקוד נוספת? | מכרזים מרובים בתצוגת עץ לא תואמים ליעדי הפרטיות שלנו, משתי סיבות. ראשית, כשהזוכה במכרז מוצג ב-Fenced Frame, יעדי הפרטיות שלנו עבור Protected Audience כוללים את העיבוד היצירתי שמתקבל ללא ידיעת ההקשר: כתובת ה-URL של הדף שמסביב או קובץ cookie מהדומיין הנוכחי מפרים את הפרטיות. בסביבה הזו לא ניתן להשתמש במכרז בתצוגת עץ. שנית, לפי המודל Protected Audience API, הזוכה בכל מכרז צריך להתבסס על נתונים מאתר אחד נוסף בלבד. מכירות פומביות מקננות הן דרך הרכבה, וכתוצאה מכך מאפשרת לבחור מודעות על סמך פרופיל של אתרים רבים. |
| קריטריון בנושא נתונים במנוחה | הסבר מפורט יותר על הקריטריון 'נתונים במנוחה' במודל המהימנות של מפתח/ערך. | הנתונים ב-Key Value Service נטענים בזיכרון ומוגשים משם, במקום לבצע שמירה של קריאה במטמון. |
| אות נתוני הקונה | האם יש מגבלת גודל מוגדרת לאותות buyer_data שמתקבלים מפלטפורמות DSP? |
כרגע לא חלות מגבלות בדפדפן על אותות buyer_data שהתקבלו מפלטפורמות DSP. |
מדידת הביצועים של מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| במכשירים שונים | לתכנן תמיכה במכשירים שונים ב-Attribution Reporting API. | בנוסף ל-3PC, אתגרים חדשים לשמירה על פרטיות במכשירים שונים מציבים גם דרישות של הפצת טכנולוגיה, בהתאם למגוון המכשירים והפלטפורמות שבהם המשתמש עשוי להשתמש. אנחנו בודקים פתרונות פוטנציאליים, אבל אנחנו מתמקדים בתרחישים הקריטיים שנתמכים כרגע על ידי דוחות השיוך (Attribution), ואנחנו לא מתכננים להוסיף תמיכה במכשירים שונים לפני ההסרה של קובצי cookie של צד שלישי. |
| (מדווח גם ברבעונים הקודמים) גודל נתוני הטריגר |
למה גודל הנתונים של הטריגר מוגבל ל-3 ביט? | הגודל מוגבל ל-3 ביט ול-8 ערכים נפרדים כדי להבטיח שכמות המידע לגבי המשתמש באתרים שונים ובהקשרים שונים תהיה מוגבלת. אנחנו מזמינים שחקנים אחרים בסביבה העסקית לשלוח משוב ולבדוק אם הפרמטר הנוכחי לצורכי דיווח ברמת האירוע מספיק. |
| משפך המרות | דיווח על מספר דומיינים שנעשה בהם שימוש בהמרה. | התרחיש הזה אפשרי מפני שהוספתם כמה יעדים. נשמח לקבל משוב נוסף. |
| דומיין זהה עם תמיכה במדינות שונות | האם דוחות השיוך (Attribution) פועלים עם אתרים שיש להם דומיין זהה אבל כמה דומיינים ברמה העליונה (TLD)? | הבעיה הזו נדונה וטופלה עם בעלי העניין שעוררו את השאלה. אם טכנולוגיות פרסום צריכות להשתמש בכמה דומיינים ברמה העליונה, צריכות להיות להן כמה הרשמות, אחת לכל דומיין ברמה העליונה (TLD). |
| דוחות שיוך (Attribution) וקהלים מוגנים | האם טכנולוגיות של מודעות יכולות לגשת להמרות בעקבות צפייה במכרזים של 'קהל מוגן' וגם להמרות לאחר קליק בדוחות שיוך? | כן, ארגז החול לפרטיות אמור לתמוך בהמרות בעקבות צפייה וגם בהמרות בעקבות צפייה ב-Protected Audience. |
| עיכובים בדיווח שניתן לצבור | לצמצם עוד יותר את העיכובים המצטברים בדוחות. | קיבלנו משוב לאחרונה בנושא ושיתפנו כאן רעיונות. נשמח לקבל משוב נוסף מהסביבה העסקית. |
| עיכובים בדיווח שניתן לצבור | צמצום עיכובים באמצעות הכנסת תהליך בחירת הרשת (Mediation) בשרת. | אנחנו שוקלים את ההצעה ונשמח לקבל משוב נוסף . |
| עיכובים בדיווח ברמת האירוע | הפחתת עיכובים בדיווח ברמת האירוע. | ההצעה הגמישה המלאה ברמת האירוע, שמתוארת בהגדרות גמישות ברמת האירוע, יכולה לצמצם את העיכובים בדיווח ברמת האירוע לפרק זמן של עד שעה, עם החלפת רעש. |
| מקור דיווח על מקור לכל מקור | ההגבלה על המקורות המקסימליים של דיווח על מקורות לכל אתר לדיווח על מקור מונעת מטכנולוגיות פרסום לרשום מקורות ממקורות דיווח שונים עבור מקור יחיד של בעל אתר. | דיברנו על כך עם בעלי העניין שגרמו לבעיה, ובשלב הבא נבדק פתרון אפשרי לשימוש במקור דיווח אחד לכל אתר לדיווח מקור, לפני שמנסים פתרונות פוטנציאליים אחרים עם הפניות אוטומטיות. נשמח גם לקבל כל משוב נוסף על הסביבה העסקית בנוגע למגבלה הזו. |
| דיווח על בעיות | איך אפשר לדווח ל-Chrome על שגיאות או בעיות ב-Attribution Reporting API? | נכון לעכשיו, אנחנו ממליצים שטכנולוגיות פרסום ידווחו על כל שגיאה ב-Attribution Reporting API שהיא עשויה להיתקל בהן כבעיה ב-GitHub. אם הם נתקלים בבעיה שקשורה ל-Chrome, אנחנו ממליצים ליצור באג ב-Chromium. במאמר מעורבות ושיתוף משוב תוכלו למצוא קישורים שמסבירים איך ואיפה לדווח על בעיות. |
| ביטול כפילויות | איך אפשר לבטל כפילויות של המרות בצינורות עיבוד נתונים ובמכשירים שונים? | ביטול כפילויות בין מכשירים ובצינורות עיבוד נתונים הוא אתגר ידוע ונוכחי, שגם טכנולוגיות הפרסום מתמודדות איתו כיום ב-3PC. באמצעות Attribution Reporting API, הטכנולוגיות של מודעות יכולות להחליט מתי לרשום המרות ספציפיות ולהוסיף מטא-נתונים ספציפיים כדי לציין באילו צינורות עיבוד הנתונים השתמשו כדי לעקוב אחר ההמרות (כלומר, חלק ממפתח הצבירה). ניתן להשוות אותם לצינורות עיבוד נתונים אחרים למדידה. נשמח לקבל כל משוב נוסף לגבי הסביבה העסקית בנושא. |
| ביטול כפילויות ועדיפות | מבקשים לקבל עדיפות לפני ביטול כפילויות. | אנחנו שוקלים את הבקשה ונשמח לקבל משוב נוסף. |
| נגד הונאה | סיכון שמשתמשים זדוניים יפגעו בנתונים ברמת האירוע. | אימות הדוח לא עובד בדיווח ברמת האירוע לסיבות שמתוארות במאמר למה האפשרות הזו לא תומכת בדוחות ברמת האירוע?. |
| סוג ההמרה | איך אפשר להבחין בין צפייה דרך צפייה לבין ניווט בדוחות שיוך? | קיימת אפשרות הסינון המובנית הבאה: source_type.
פרטים נוספים זמינים כאן. |
שירות צבירה
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| שחזור תקציב | חלק טכנולוגיות הפרסום ביקשו עיבוד מחדש של דוחות במקרים שבהם הדוחות שלהן היו כשלים, שגיאות או מחיקות. | הצוות מחפש דרכים לטפל בנושא באופן ששומר על הפרטיות. |
| הרשמה לאתר | מספר טכנולוגיות של מודעות ביקשו תמיכה בעיבוד של כמה מקורות באותו החשבון, בתרחישים לדוגמה, כמו פיצול נתונים לפי מיקום גיאוגרפי או מפרסם מסוים. טכנולוגיות הפרסום צפויות לפעול כך גם אם ההרשמה ל-API של הלקוח מבוססת עכשיו על האתר (ולא על המקור). המעבר מרישום המקור להרשמה לאתר מייעל את תהליך ההצטרפות לטכנולוגיית המודעות באמצעות עקביות בתהליך ההרשמה של הלקוחות. | בקרוב נתחיל את תהליך ההעברה מרישום המקור להרשמה של אתרים לשירות הצבירה (Aggregation) לשירות, ולקבל משוב מהסביבה העסקית. |
| תוכנית להוצאה והוצאה משימוש | לוח זמנים להשקה ולירידה בנתונים של תכונות ותיקונים של שירות הצבירה. מטרת התוכנית היא לאפשר לטכנולוגיות הפרסום לראות את מדיניות ההפצה שלנו, כדי לאפשר ללקוחות להתכונן לגרסאות ולהוצאה משימוש עתידיות, ולוודא שגרסאות השירותים יציבות ומאובטחות. | לאחרונה פרסמנו הצעה לתוכנית הפרסום וההוצאה משימוש של שירות הצבירה, ונשמח לקבל משוב נוסף. |
| מתאמים | מה יקרה אם המתאמים יפסיקו להשתמש בשירות הצבירה? | שני המתאמים צריכים להיות זמינים באופן מלא כדי שהמערכת תפעל בצורה תקינה. אי-זמינות קצרה תטופל על ידי ניסיונות חוזרים בספריות הלקוח שלנו. אי-זמינות ארוכה יותר של אחד משני המתאמים תגרום למשימות צבירה. אפשר להריץ מחדש משימות אם התקציב לשמירה על פרטיות עדיין לא נוצל. במקרים שבהם כשל בשירות גרם לצריכת התקציב בלי דוח סיכום שנכתב באחסון של טכנולוגיות הפרסום, בשלב הזה מומלץ להשתמש בדוחות ניפוי באגים כדי לאחזר את התוצאות באמצעות כלי הבדיקה המקומי. אנחנו גם עובדים על תכונות שיאפשרו ניצול התקציב במקרה של כשלים, כדי שטכנולוגיות הפרסום יוכלו להריץ מחדש את המשימות שלהן. |
API לצבירה פרטית
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| כתובת URL של blob | בקשה לתמיכה בכתובת URL ב-Blob בנפח אחסון משותף. | תמיכה ב-Blob URL נוספה ל-Chrome בגרסה M116. |
הגבילו מעקב סמוי
הפחתת מידע בסוכן משתמש ורמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| ממשק API של JavaScript | הזמינות של User Agent Client Hints API JavaScript. | אנחנו לא מתכננים להסיר את הפונקציונליות הזו, כי היא הפתרון העיקרי שלנו לשותפים שרוצים לקבל באופן פעיל גישה פעילה לנתוני האנטרופיה, מעבר לנתונים שזמינים כברירת מחדל ב-UA הקפואים או המצומצמים. |
| מידע על המכשיר וגורם הצורה | היכולת של אתרים להבין קלט, פלט ומידע נוסף שתומך במכשיר שמבקר באתר. | הוספנו תמיכה לבקשה הזו בעקבות המשוב שקיבלנו מהסביבה העסקית. |
הגנה על IP (לשעבר Gnatcatcher)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| תנועה כשירה מצד שלישי | למה מתייחסת 'תנועה כשירה של צד שלישי' בהסבר? | אנחנו מבינים את החשיבות של השאלה הזו, ואנחנו פועלים כדי לזהות אילו תנועה מצד שלישי תהיה כשירה ואילו לא. נשמח לקבל משוב בנושא הזה. |
| בדיקות של תנועת הגולשים ברשת | תמיכה בארגונים לביצוע ביקורות על תעבורת הנתונים ברשת עבור הרשתות שלהם. | זו תהיה השפעה רק על תנועה של צד שלישי המוטמעת באתרים של צד ראשון, ולכן היא אמורה להגביל את כמות התנועה שדורשת סינון. בנוסף, אנחנו מתכננים לתת למשתמשים את האפשרות אם להשתמש בהגנה IP או לא. ב-Chrome בשליטת הארגון תהיה מדיניות ארגונית שתאפשר להשבית את ההגנה על IP. לבסוף, אנחנו בודקים אילו אמצעי בקרה (אם בכלל) יסופקו למפעילי הרשת כדי להשבית את ההגנה על ה-IP. נשמח לקבל משוב על הנושא הזה. |
| בקרת גישה | ההגנה על ה-IP עשויה להשפיע על שירותי אינטרנט שמשתמשים בכתובות IP לבקרת גישה. | אנחנו מבינים את החשיבות של תרחישים לדוגמה למניעת הונאה ואת ההשפעה האפשרית על התרחישים האלה. אנחנו מחפשים משוב על הסביבה העסקית שבה מוסבר איך נוכל לספק תמיכה טובה יותר בתרחישים לדוגמה למניעת הונאה שבדרך כלל הסתמכו על כתובות IP. |
| התקשורת בין שרתי ה-proxy של 2-הופ | כיצד לוודא שאין מידע בין שרתי proxy. | אנחנו נמצאים בתהליך של תכנון האינטראקציות עם שרת ה-proxy. המטרה שלנו היא לצמצם את הסיכויים לשיתוף מידע מהסוג הזה באמצעים עסקיים, תהליכים וטכניים. |
| אימותים שאינם של Google | תמיכה באימות שאינו של Google. | אנחנו מתכננים לפרסם בעתיד פרטים נוספים על אימות החשבון, אם כי שיתפנו כאן כמה שיקולים ראשוניים. |
| סיווג של מכשיר מעקב | איך ההגנה על ה-IP תקבע מה מוגדר מעקב ומה הווריאנטים שלו? | אנחנו מבינים את החשיבות של השאלה הזו, ואנחנו פועלים כדי לזהות אילו תנועה מצד שלישי תהיה כשירה ואילו לא. נשמח לקבל משוב בנושא הזה. |
| ניתוח נתונים | ההגנה על כתובות IP עשויה להשפיע על הדיוק של שירותי ניתוח הנתונים. | אנחנו רוצים להבין טוב יותר את ההשפעה של ההגנה על ה-IP, ונשמח לקבל משוב ודוגמאות נוספים מהסביבה העסקית. |
| שרת Proxy | אם משתמש משתמש בשרת proxy או הגדיר שרת proxy באופן ידני, איך פועלת מסכת ה-IP במקרה הזה? | אנחנו רוצים להבין את ההשפעה שעשויה להיות להגנה מפני קניין רוחני על שרתי proxy אחרים. אין לנו כרגע תוכניות לשתף. נשמח לקבל משוב בנושא הזה. |
| מבצע פרימיום | האם ההגנה על IP תהיה תכונה בתשלום? | ההגנה על כתובות IP תהיה זמינה למשתמשי Chrome כחלק מחוויית הליבה של הדפדפן. התכונה לא תהיה בתשלום. |
| שרת Proxy | האם ייעשה שימוש באותם שרתי proxy במהלך סשנים של משתמשים? | בחיבור HTTP/S ייעשה שימוש בזוג יחיד של שרתי proxy, ומייצג כתובת IP אחת עם אנונימיזציה של המקור. מעבר לכך, אין מגבלות מחמירות על חיבורי HTTP/S שונים שצריכים להשתמש באותם שרתים. |
| תמיכה בפלטפורמות | באיזו פלטפורמה תהיה תמיכה בהגנה על IP? | ההגנה על ה-IP תהיה זמינה בהתחלה ב-Chrome ל-Android ולמחשב. אנחנו ממשיכים לבחון איך להרחיב את ההגנה לפלטפורמות נוספות. |
| ביטול הצטרפות | האם המשתמשים יוכלו להשבית את ההגנה על כתובות IP? | אנחנו מתכננים לאפשר למשתמשים לבחור אם להשתמש בהגנת IP או לא. |
| אנונימיזציה | אילו סוגי בקשות יעברו אנונימיזציה במסגרת ההגנה על כתובות IP? | בקשות HTTP/S ו-DNS לדומיינים כשירים של צד שלישי עוברות אנונימיזציה באמצעות שרתי ה-proxy של הפרטיות. בהמשך נספק פרטים נוספים לגבי האופן שבו ניתן לקבוע אילו דומיינים ייכללו. שאר תעבורת הנתונים (לדוגמה, שאר בקשות ה-DNS או תעבורת HTTP/S אחרת) לא מושפעת. |
| חשיפת הנתונים | ניתן לגשת לכתובות של רשתות במהלך הצעד הראשון בהגנה על IP. | במודל ה-Proxy הדו-שלבי, בצעד הראשון (שנשלט על ידי Google) מוצגים רק כתובת ה-IP של לקוח המקור ובקשת התחברות לצעד השני, וצעד השני (שנשלט על ידי CDN חיצוני) מזהה רק tuple בצעד הראשון (כתובת ה-IP של שרת ה-Proxy + יציאה) ובכתובת ה-IP של היעד. בתגובה בחזרה מהמקור, בצעד השני אפשר להעביר את התגובה ליציאת proxy+ של הצעד הראשון שמשויך לבקשה, בלי ללמוד דבר על כתובת ה-IP המקורית של הלקוח (ובצעד הראשון פשוט מחזירים את התגובה ללקוח, בלי ללמוד כל על כתובת ה-IP של היעד). כך, בצעד הראשון לומדים רק את כתובת ה-IP של הלקוח ואת הצעד השני, וצעד השני לומד רק את כתובת ה-IP של היעד. |
| WebView | האם ההגנה על IP תהיה זמינה ל-Android WebView בעתיד? | בשלב זה אין לנו כל כוונה לשתף, אבל החזון שלנו הוא לספק את ההגנה הרחבה ככל האפשר. |
הקלות במעקב אחר עזיבה מהדף הראשון
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| מעקב אחר אינטראקציות | איך מתבצע מעקב אחר אינטראקציות של משתמשים? | הקלות במעקב אחר עזיבה מהדף הראשון עוקבות אחרי שני סוגים של אינטראקציות
משתמשים:
האינטראקציות האלה משויכות לאתר ברמה העליונה בדפים שבהם הן מתרחשות. לדוגמה, אם משתמש לוחץ על iframe מוטמע, האינטראקציה משויכת לאתר ברמה העליונה ולא לאתר המוטמע. האינטראקציות נשמרות במסד נתונים שמכיל את הפרמטר etld+1 ללא סכמה ואת מועד האינטראקציה. אינטראקציות מגינות על הדומיין המשויך מפני מחיקה של מצב המעקב אחר עזיבה מהדף הראשון למשך 45 ימים. |
| פטורים ברשימת ההיתרים | האם אפשר לקבל פטור מדומיינים? | אנחנו שוקלים את הבקשה ומקבלים משוב נוסף מהסביבה העסקית. |
תקציב פרטיות
לא התקבל משוב ברבעון הזה.
חיזוק גבולות הפרטיות בין אתרים
קבוצות של אתרים קשורים (לשעבר 'קבוצות של צד ראשון')
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| גישה מרכזית | חשש בנוגע לגישה המרוכזת לניהול קבוצות של אתרים קשורים. | מאגר ציבורי נגיש הוא המפתח לעיצוב של RWS, מכיוון שהוא מספק אחריות על ההגשות. הפונקציונליות של קובצי cookie של צד שלישי מסופקת בסופו של דבר על ידי השימוש ב-Storage Access API או ב-rSAFor API, כאשר חברות ב-RWS מעניקה גישה באופן אוטומטי (בניגוד להנחיות דרך Storage Access API). אנחנו סבורים שגישה, כמו תהליך השליחה של RWS, היא דרישה מתאימה לקבלת גישה אוטומטית לקובצי cookie של צד שלישי. |
| שינוי השם של קובץ JSON | בעקבות השינוי בשם ה-API, האם צריך לשנות את השם של קובץ ה-JSON המתארח? | כן, הנחיות השליחה השתנו וצריך להציג קובץ JSON בדומיין הראשי ב-/.well-known/related-website-set.json. אין צורך לשנות קבוצות קיימות ברשימת ה-RWS, אבל אם שולחים שינויים בקבוצות קיימות, צריך לשנות את קובץ ה-JSON. |
| (דווח גם ברבעונים הקודמים) מגבלת דומיין | בקשה להרחבת מספר הדומיינים המשויכים | כפי שהודענו בפוסט ב-31 באוגוסט, הגדלנו את מגבלת הדומיינים המשויכים לחמישה דומיינים בעקבות המשוב שקיבלנו מהסביבה העסקית. החלטנו להגדיל את מגבלת הדומיינים המשויכים לחמישה דומיינים (ודומיין ראשי אחד), שמתאימים בצורה הטובה ביותר להטמעה הכי דומה שמוצעת על ידי דפדפן ראשי אחר. |
| קובצי cookie של צד שלישי | האם 'קבוצות של אתרים קשורים' יפעלו רק עם קובצי cookie של צד שלישי? | קבוצות של אתרים קשורים יפעלו גם אם משתמש לא חסם קובצי cookie של צד שלישי, אבל לא תהיה השפעה גלויה כי קובצי ה-cookie הרלוונטיים זמינים ללא צורך בהגדרות של אתרים קשורים וב-Storage Access API. |
| עריכות חוקיות | איך המאגר 'קבוצות של אתרים קשורים' מונע ממשתמשים שאינם בעלים לשנות קבוצות? | בהתאם למדריכי השליחה, כל אחד יכול להגיש PR ב-GitHub כדי לערוך את הקובץ first_party_sets.JSON. עם זאת, אם איש הקשר יאושר (עובר אימותים טכניים וכו'), הוא ימוזג באופן ידני עם כמה קבוצות לרשימת ה-FPS הקנונית פעם בשבוע (שלישי בשעה 12:00 לפי שעון החוף המזרחי) על ידי Google.אם גורם זדוני מנסה לשנות קבוצה שלא נמצאת בבעלותו, לא אמורה להיות בעיה כי הוא לא יוכל לשנות את קובצי .well-known,
ולכן האימותים ייכשלו. |
| פריצת דומיין | פריצת דומיין עלולה לחשוף נתונים קשורים מהדומיין לצדדים לא מורשים. | לא ניתן לעשות זאת, כפי שמתואר בבעיה הזו ב-GitHub של Protected Audience. |
ממשק API של Fenced Frames
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| הפרה שקשורה לתוכן | המשתמשים יכולים לדווח על מודעות חשודות. | Fenced Frames לא מונעת דיווח חשוד על מודעות. המשתמשים עדיין יכולים לקיים אינטראקציה עם המודעה ולדווח על מודעות חשודות לטכנולוגיית המודעות בדרך הרגילה. |
| אינטראקציה עם האתרים שמסביב | אפשרו אינטראקציה עם האתר שמסביב או ברמה העליונה. | אנחנו רוצים להבין למה הבקשה הזו נחוצה, ונשמח לקבל משוב נוסף מהסביבה העסקית. |
| פרסום מותאם | תמיכה ב-Fenced Frame בפרסום מותאם. | אנחנו שוקלים לתמוך בתרחיש לדוגמה ובוחנים פתרונות ופתרונות אפשריים. |
ממשק API לאחסון משותף
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| בכמה דומיינים | אפשר תקשורת בין דומיינים לאחסון מקומי. | התרחיש לדוגמה הזה לא תואם כרגע את שערי הפלט של האחסון המשותף תוך שמירה על הפרטיות, אבל אנחנו מקבלים בברכה הקשר נוסף כשאנחנו מפתחים הצעות לאחסון ללא מחיצות. |
| כתובת URL של blob | בקשה לתמיכה בכתובת URL ב-Blob בנפח אחסון משותף. | תמיכה ב-Blob URL נוספה ל-Chrome בגרסה M116. |
צ'יפים
לא התקבל משוב ברבעון הזה.
FedCM
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| קובצי cookie של צד שלישי | האם FedCM מושבת כרגע אם המשתמשים מפעילים את האפשרות 'חסימת קובצי cookie של צד שלישי' בהגדרות Chrome? | כן, FedCM מושבת כרגע. לצורך בדיקה, מומלץ גם להפעיל את chrome://flags/#fedcm-.אנחנו מתכננים לתמוך ב-FedCM ללא קובצי cookie של צד שלישי בעתיד. |
נלחמים בספאם ובהונאות
Private State Token API (וממשקי API אחרים)
| נושא המשוב | סיכום | תגובה של Chrome |
|---|---|---|
| תפוגת האסימון | האם האסימון יאבד או יישמר במטמון אחרי הסרת Google Chrome? | האסימון יאבד אם המשתמש יסיר את Google Chrome. |
| פרטי האסימון | איך מנפיקים יכולים לשמור את המידע שהונפק באסימון המצב הפרטי כפרטי? | המידע תמיד נשאר פרטי באסימון ולא ניתן להצפין אותו על ידי גורמים חיצוניים שאין להם את המפתחות. |
| שגיאה בהדגמה | אירעה שגיאה במהלך הניסיון להריץ את ההדגמה של אסימון המצב הפרטי. | עדכנו את ההדגמה והיא אמורה לפעול באופן תקין עכשיו. |