דוח רבעוני לרבעון השני של שנת 2022 שמסכם את המשוב שקיבלנו מהסביבה העסקית לגבי ההצעות של ארגז החול לפרטיות ואת התגובה של 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, FLEDGE 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 |
| צירי זמן ברורים יותר | לוחות זמנים ברורים ומפורטים יותר להשקות של הטכנולוגיות של ארגז החול לפרטיות. | אנחנו מפרסמים את התוכניות הנוכחיות שלנו לגבי לוח הזמנים לפריסה בכתובת privacysandbox.com, ומעדכנים אותו מדי חודש. הזמנים האלה מבוססים על זמן הפיתוח של מפתחי Chrome ומפתחי האינטרנט, וגם על משוב שקיבלנו מהסביבה העסקית הרחבה יותר לגבי הזמן הנדרש לבדיקה ולהטמעה של הטכנולוגיות החדשות. כל טכנולוגיה עוברת כמה שלבים מהבדיקה ועד לשחרור (השקה), והתזמון של כל שלב נקבע על סמך מה שאנחנו לומדים ומגלים בשלב הקודם. בשלב זה אין לנו התחייבויות להשקות, אבל כשיהיו לנו, נעדכן את ציר הזמן הציבורי שלנו בכתובת privacysandbox.com. |
| התועלת לבעלי עניין מסוגים שונים | חששות שהטכנולוגיות של ארגז החול לפרטיות נותנות עדיפות למפתחים גדולים יותר, ושאתרים קטנים יותר בתחום ספציפי תורמים יותר מאתרים כלליים גדולים יותר. | אנחנו מבינים שלחלק מהמפתחים יש חששות לגבי ההשפעה של טכנולוגיות ארגז החול לפרטיות. Google התחייבה בפני CMA לא לתכנן או להטמיע את ההצעות של ארגז החול לפרטיות באופן שגורם לעיוות התחרות על ידי מתן עדיפות לעסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום דיגיטלי ועל בעלי תוכן דיגיטלי ומפרסמים, וגם את ההשפעה על תוצאות הפרטיות ועל חוויית המשתמש. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם CMA כדי לוודא שהעבודה שלנו עומדת בהתחייבויות האלה.
במהלך הבדיקה של ארגז החול לפרטיות, אחד מהשאלות המרכזיות שנבדוק הוא איך הטכנולוגיות החדשות פועלות אצל סוגים שונים של בעלי עניין. המשוב שלכם חשוב מאוד בנושא הזה, במיוחד משוב ספציפי שאפשר ליישם אותו ויעזור לנו לשפר את התכנונים הטכניים. |
| לוחות זמנים להוצאה משימוש של קובצי Cookie של צד שלישי | בקשות למניעת עיכוב נוסף בהוצאה משימוש של קובצי cookie של צד שלישי | קיבלנו משוב מגורמים שונים שרוצים ש-Chrome ימשיך בהוצאה משימוש של קובצי Cookie של צד שלישי ללא עיכוב, וקיבלנו משוב מגורמים אחרים שלדעתם נדרש עוד זמן כדי לבדוק את הטכנולוגיות של ארגז החול לפרטיות ולהתחיל להשתמש בהן. אנחנו מחויבים לפעול באחריות, בהתחשב במורכבות של הטכנולוגיות ובחשיבות של ביצוע הדברים בצורה נכונה לסביבה העסקית. המשוב מהתעשייה ומרשויות הרגולציה היה קריטי לתהליך הזה. |
| לוחות זמנים להוצאה משימוש של קובצי Cookie של צד שלישי | בקשות לדחיית ההוצאה משימוש של קובצי cookie של צד שלישי, ולמתן זמן נוסף לבדוק את ממשקי ה-API. | קיבלנו משוב מגורמים שונים שרוצים ש-Chrome ימשיך בהוצאה משימוש של קובצי Cookie של צד שלישי ללא עיכוב, וקיבלנו משוב מגורמים אחרים שלדעתם נדרש עוד זמן כדי לבדוק את הטכנולוגיות של ארגז החול לפרטיות ולהתחיל להשתמש בהן. אנחנו מחויבים לפעול באחריות, בהתחשב במורכבות של הטכנולוגיות ובחשיבות של ביצוע הדברים בצורה נכונה לסביבה העסקית. המשוב מהתעשייה ומרשויות הרגולציה היה קריטי לתהליך הזה. |
| בקשות למסמכים | בקשות למקורות מידע נוספים עם מידע על ניהול הבדיקות, הניתוח וההטמעה. | אנחנו שמחים שהחומר הנוכחי שלנו עזר למפתחים, ואנחנו מחויבים לספק חומר נוסף, כולל שעות פעילות למפתחים ומסמכים טכניים, בשבועות ובחודשים הקרובים כדי שהמפתחים יוכלו להמשיך להבין איך הטכנולוגיות החדשות יכולות לעזור להם.
בנוסף, קיבלנו מפתחים חיצוניים לשיחות פתוחות כדי לשתף איתם שיטות מומלצות והדגמות, וגם קיבלנו מובילים של מוצרים ומהנדסים לשיחות פתוחות עם שאלות ותשובות, כדי לאפשר דיון או שאלות בזמן אמת. |
| מומחיות בתחום | לצוות Chrome שמתכתב עם גופים סטנדרטיים אין את המומחיות הנדרשת בסביבת הפרסום כדי לשמור על איזון בין פרטיות לבין תועלת. | אנחנו מבינים שיש לנו אחריות גדולה, ואנחנו תלויים במשוב ספציפי כדי לעשות את זה כמו שצריך. בנוסף, אנחנו מחשיבים את הפרטיות ואת היעילות כקריטריונים חיוניים וקריטיים לתכנון. סך כל שנות העבודה של הצוות שעובד על ארגז החול לפרטיות באינטרנט בסביבת הפרסום עולה על מאות שנים. |
הצגת מודעות ותוכן רלוונטיים
נושאים
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| התועלת לבעלי עניין מסוגים שונים | הועלתה דאגה לגבי הערך שנוצר וההפצה של הערך הזה לאתרים, בהתאם לרמת התנועה או לרמת המומחיות של התוכן שלהם. | נבדוק את השימושיות של ה-API באמצעות בדיקות. הצוות של Chrome מצפה שהטקסונומיה והפרמטרים האחרים יתפתחו על סמך תוצאות הבדיקה. יכול להיות שהתפתחות הטקסונומיה או הפרמטרים לא תחייב שינויים שלא יהיו תואמים לאחור. בנוסף, הצוות של Chrome מצפה שהמשוב ימשיך להשפיע על התפתחות Topics API אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. |
| טקסונומיה | בעלי עניין בתעשייה רוצים להשפיע על הטקסונומיה. | אנחנו ממשיכים לקבל משוב על הטקסונומיה של Chrome. אנחנו ב-Chrome מאוד מעוניינים לקבל משוב על מודל הניהול של שינוי הטקסונומיה, ולדון בדרכים שבהן גופים אחרים בתעשייה יכולים למלא תפקיד פעיל יותר בפיתוח ובתחזוקה של הטקסונומיה לטווח הארוך. |
| היסטוריית הגלישה לא מספיקה | הצעה להציג נושאים שהמבצע התקשרות צפה בהם בשבועות הקודמים, אם למשתמש אין מספיק היסטוריית גלישה כדי ליצור 5 נושאים לשבוע האחרון | בתכנון הנוכחי שלנו, הם נבחרים באופן אקראי. אנחנו נבדוק את הקורלציה לנושאים קודמים ונשקול אם יש אפשרות לשלב אותם. עם זאת, יכול להיות שקורלציות כאלה יגרמו לבעיות פרטיות שצריך להביא בחשבון. |
| קריאה ל-Topics בשם בעל אפליקציה | האם ספק שירותים של צד שלישי יכול לשתף את Topics עם בעל תוכן דיגיטלי? | כן, זו אחת הדרכים שבהן אנחנו מצפים שאנשים ישתמשו ב-Topics. |
| וקטורי תקיפה פוטנציאליים | זיהוי הנושאים הרועשיים | על סמך משוב מגורמים רבים בסביבה העסקית, ב-Chrome בחרו לסנן נושאים ולהוסיף רעשי רקע. ההחלטות האלה התקבלו מתוך מחשבה על פרטיות – כדי להגביל את הגישה למידע לאנשים שלא הייתה להם גישה למידע כזה אחרת, ולהציע למשתמשים אפשרות להכחיש בצורה סבירה. אנחנו מבינים שלהחלטות האלה יש חסרונות, כמו וקטור ההתקפה שמתואר כאן. עם זאת, ההערכה שלנו היא שהיתרונות של הפרטיות עולים על הסיכונים הפוטנציאליים. נשמח לדיון ציבורי בנושא ההחלטה הזו. |
| דרישות הסף לקבלת גרסת מקור לניסיון | האם יש דרך לזהות אם משתמש עומד בדרישות לתוכנית Origin Trial? | יכול להיות שתכונה של גרסת טרום-השקה לא תהיה זמינה למשתמש בגלל הגדרות הדפדפן או גורמים אחרים, גם אם הוא נכנס לדף אינטרנט שמספק אסימון תקף לגרסת טרום-השקה והדפדפן שלו נכלל בקבוצה שבה הגרסת הטרום-השקה מופעלת.
לכן, תמיד צריך להשתמש בזיהוי תכונות כדי לבדוק אם תכונה של גרסת טרום-השקה זמינה, לפני שמנסים להשתמש בה. |
| השפעה על הביצועים | בעיות של זמן אחזור ועלות ריצה ב-Topics | אנחנו מבקשים מכם משוב לגבי גישות להימנעות מ-iframes של מקור זר (x-origin) יקרים ואיטיים, ולגבי ההצעה שלנו לפרק את Topics API כך שהאחזור של נושאים לא ישנה את מצב הגלישה. |
| חלוקת הפונקציונליות של Topics API | שליטה רבה יותר בשלושת ההיבטים השונים של ה-API | אנחנו מבינים את התרחיש לדוגמה והצענו דרך אפשרית לפתרון הבעיה ב-GitHub. אנחנו ממתינים כרגע למשוב נוסף מהסביבה העסקית כדי להחליט אם לפתח את הפונקציונליות הזו. כאן אפשר לעיין בדיון המתמשך. |
| ציר הזמן והמסמכים של מסווגים | מפתחים ביקשו מידע נוסף על הסיווג. | מידע נוסף על הסיווג זמין כאן.
וגם כאן וגם כאן. |
| אמצעי בקרה ובטיחות למשתמש | נושאים מסוימים עשויים לשמש כסמל לקבוצות רגישות, ולמשתמשים נדרשים אמצעי בקרה נוספים כדי למנוע תוצאות שליליות. | התכונה 'נושאים' היא צעד משמעותי קדימה לשיפור השקיפות והשליטה של המשתמשים. המשתמשים יוכלו לבטל את ההסכמה לשימוש בנושאים, לבדוק את הנושאים שהוקצו להם, להסיר נושאים ולהבין אילו חברות מקיימות אינטראקציה עם הנושאים שלהם בדף נתון. בנוסף, המשתמשים יכולים להשפיע על הנושאים שלהם על ידי מחיקה של היסטוריית הגלישה. אנחנו מברכים על המשך הדיון לגבי אמצעי בקרה מתקדמים יותר של המשתמשים, כמו אלה שהציעו המפתחים. עם זאת, אנחנו צריכים לוודא שהם אכן מסירים את הסיכונים שצוינו בבאג הזה (לדוגמה, הסרת הנושא 'לימוד שפה זרה' בלבד, אבל לא את האתרים שיצרו את הנושא מהיסטוריית הגלישה, לא מגינה על המשתמש באופן מלא). |
| שימוש בנושאים באתרים עם prebid.js | האם אפשר להשתמש ב-Topics API באתרים עם prebid.js? | התשובה הקצרה היא כן. מידע נוסף פורסם כאן. |
| שימוש ב-Topics API בווידג'ט המלצות | האם אפשר להשתמש ב-Topics API בווידג'ט 'המלצות' (למשל, Outbrain) | אנחנו לא מגבילים את התרחיש לדוגמה של Topics שאוחזרו אחרי הקריאה ל-API (הוא יהיה תלוי במדיניות הנתונים של כל מפתח). |
| פרטיות / מדיניות | שאלות לגבי מטרת הסינון של התשובות לפי מבצע הקריאה, אם צדדים שלישיים מסוימים ישתפו את הנושאים שלהם עם כל מי שמתקשר. | על סמך משוב מגורמים רבים בסביבה העסקית, ב-Chrome בחרו בתכנון הזה כדי להגביל את הגישה למידע לאנשים שלא הייתה להם גישה למידע כזה אחרת. כמובן, בעלי תוכן דיגיטלי וצדדים שלישיים שמקבלים את התכונה 'נושאים' יכולים להחליט בעצמם איזה מידע הם ישתפו עם גורמים באתר שלהם. אם הם מבצעים שיתוף כזה, אנחנו ממליצים להם לפעול בשקיפות מול המשתמשים לגבי שיתוף כזה, ולהציע להם אמצעי בקרה. |
| אותות רועשים | הצגת נושא אקראי ב-5% מהמקרים עלולה ליצור יותר מדי רעש או אותות שגויים. | רעש הוא שיטה חשובה להגנה על פרטיות המשתמשים, ונבדוק את רמות הרעש לעומת התועלת של הנושאים באמצעות בדיקות. |
FLEDGE
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| תיאום בדיקות | בדיקה של ההשפעה על הביצועים וההכנסות | אנחנו דנים באופן פעיל בביצועים של FLEDGE ובדרכים שבהן נוכל לתמוך בצורה הטובה ביותר בבדיקות של הסביבה העסקית במהלך תקופת הניסיון במקור וגם לאחר ההשקה לכלל המשתמשים, בפגישות הציבוריות של WICG. |
| שרת מהימן ל-FLEDGE | מתי השרת המהימן יהיה זמין לבדיקה? | אנחנו מעריכים את המשוב הזה ואנחנו פועלים כדי להכין תוכנית מפורטת יותר שאפשר יהיה לשתף לגבי השימוש בשרתי FLEDGE מהימנים. |
| סטנדרטיזציה של פרוטוקולים | האם יהיה פרוטוקול משותף להעברת נתונים בין פלטפורמות SSP לבין פלטפורמות DSP, כמו תוויות משותפות לקבוצות של תחומי עניין? | אנחנו מקבלים בברכה משוב מ-DSP, מ-SSP ומסביבת המודעות הרחבה יותר לגבי סטנדרטיזציה פוטנציאלית של המפרט. לצורך בדיקה ראשונית בשלב זה, מומלץ לעבוד ישירות עם שותפי הבדיקה שלכם, כי הם נמצאים בתהליך ניסוי עם גישות שונות. אנחנו גם מעודדים ארגוני מודעות מסחריות להביע את דעתם בנושא, ואנחנו מתכננים להמשיך לעבוד איתם כדי ליצור סטנדרטיזציה במקרה שהיא תהיה שימושית לחברות החברות בהם. |
| מכסת תדירות | אמצעי בקרה על התדירות לכל משתמש בקמפיין ובקבוצת מודעות. | FLEDGE תתמוך גם במכסות תדירות במכרזים במכשיר ובקמפיינים לפי הקשר או לקידום מותג. אפשר גם להשתמש באחסון משותף ובמכסות ספציפיות לאתר כדי להגדיר אמצעי בקרה נוספים למכסות התדירות. |
| ההשפעה של FLEDGE על הביצועים | מגישים של הצעות מחיר עם עומס מחשוב גבוה במכרז FLEDGE | אנחנו ב-Chrome מנהלים דיונים פעילים עם מפתחים לגבי ההשפעה הפוטנציאלית על ביצועי האתרים. אנחנו ב-Chrome שמחים לקבל מידע נוסף במהלך הבדיקה. |
| בדיקת FLEDGE עם תכונות אחרות | איך הדוחות ברמת האירוע מ-Attribution Reporting API ומ-FLEDGE יתחברו זה לזה? | הנושא הזה נדון בשיחת WICG/conversion-measurement-api שנערכה לאחרונה, וכאן אפשר למצוא קישור לדוח המפורט של פרוטוקול השיחה.
סיכום הפגישה: העיצוב הנוכחי של דיווח על מודעות בפריימים מגודר מאפשר לשייך מזהה שנוצר בתוך הפריים המגודר למידע לפי הקשר. לכן, דוחות ברמת האירוע שנוצרים בתוך המסגרת המגודרת יהיו ניתנים למיזוג לאותו מידע לפי הקשר בשרת (באמצעות 2 מיזוגים בצד השרת במקום אחד). |
| ספירת חשיפות | איזו מתודולוגיה של ספירת חשיפות צריך או אפשר להשתמש בה בין קונים למוכרים | ממשק FLEDGE API כבר תומך בהתאמה של המתודולוגיה בין המוכר לקונה במהלך המכרז. קיבלנו הצעות להטמעות חלופיות, אבל לא קיבלנו משוב לגבי הסיבה לכך שהעיצוב הנוכחי שלנו לא יכול להתאים לסביבה העסקית. |
| הצגת כמה מודעות | האם אפשר להציג כמה מודעות במכרז אחד במסגרת מוגבלת נתונה | בשלב הזה אפשר לעשות זאת באמצעות מודעות רכיבים (לא להתבלבל עם מכרזים של רכיבים). לשם כך, כל המודעות צריכות להיות באותה קבוצת תחומי עניין. |
| המפרט 'קהלים שהוגדרו על ידי מוכרים (SDA)' ו-FLEDGE | האם FLEDGE יכול להפוך למנגנון שימנע מגורמים מצד שלישי ליצור פרופילים מבקשות להצגת מודעות? | FLEDGE נועד למנוע זליגת מידע לא רלוונטי כשהבעלים של האתר כבר יודע אילו קבוצות של משתמשים בעלי תחומי עניין דומים (SDA) נמצאים באתר שלו, והטירגוט הוא באותו אתר. אם חשוב לכם לתמוך ברכישה של מודעות SDA במסגרת כל ההגנות המובנות ב-FLEDGE, פתרון אחד יכול להיות שהמוכר יעביר תוויות של מודעות SDA למכרז במכשיר, וחברת טכנולוגיית הפרסום בצד הקונה תיצור קבוצת תחומי עניין משלה, שתכלול את הלוגיקה הבאה לבידינג: "אני רוצה לקנות את קהל X". |
| תמיכה במטבעות שאינם דולר ארה"ב | תמיכה בבדיקת FLEDGE עם מטבעות שאינם דולר ארה"ב | אנחנו מעריכים את ההערה שלך והוספנו תמיכה במטבעות נוספים לרשימת הבקשות שלנו להוספת תכונות. אנחנו מקווים שהתכונה הזו תהיה זמינה בקרוב. |
| תמיכה בטירגוט שלילי לפי קבוצות אינטרס | ממשק API לתמיכה בטירגוט של IG שלילי: הצגת מודעות רק אם המשתמש לא שייך ל-IG. | דיון מתמשך, כולל כמה הצעות לאפשרויות תמיכה, זמין בבעיה ב-GitHub. |
| מספר ספקי SSP ב-FLEDGE | סיכון להעדפת Google כשמפעילים מכרזים מרובים ברמות שונות ב-FLEDGE | הוספנו תמיכה במספר ספקי SSP ב-FLEDGE כדי לספק סביבה הוגנת ושוויונית. במסגרת ההתחייבויות, Google התחייבה לא לתכנן, לפתח או להטמיע את ההצעות של ארגז החול לפרטיות בדרכים שעשויות לפגוע בתחרות על ידי מתן עדיפות למוצרים ולשירותים הפרסומיים שלה. Google מתייחסת לנושא הזה ברצינות רבה, ומוכנה מאוד לדון בכל חשש של בעלי עניין לגבי היבטים ספציפיים של הטכנולוגיה. כאן מפורט המנגנון של מכרז הרכיבים ב-Chrome. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| ייחוס לכמה נקודות מגע | בעלי תוכן דיגיטלי שמבקשים תמיכה בשיוך לכמה נקודות מגע | השיטות הקיימות של שיוך (Attribution) בכמה נקודות מגע מחייבות לקשר באופן דטרמיניסטי בין החשיפות של משתמש (ולכן הזהות שלו) באתרים שונים. כתוצאה מכך, הפונקציונליות הזו בצורתה הנוכחית לא תואמת ליעדים של ארגז החול לפרטיות, שמטרתו לתמוך בתרחישים לדוגמה בעלי חשיבות גבוהה בתחום הפרסום בלי מעקב בכמה אתרים. במקרים מסוימים, אפשר לבצע הערכה של הקצאת הקרדיט (למשל, באמצעות שימוש בעדיפויות משוקלות ואקראיות) בלי לעקוב אחרי משתמשים ספציפיים. |
| יצירת רעש | שאלות לגבי רמות הרעש בדוחות | הניסוי הראשוני שלנו מאפשר למפתחים להגדיר ערך epsilon משלהם כדי שיוכלו לראות איך הדוחות משתנים בהתאם לרמת הרעש. נכון לעכשיו, מפתחים יכולים לבחור ערך epsilon עד epsilon=64. עשינו זאת במיוחד כדי שיהיה קל יותר למפתחים לבדוק את ממשקי ה-API ולספק לנו משוב על ערכי האפסילון המתאימים.
פרסמנו גם בקשה ציבורית למשוב כזה. |
| תיאום בדיקות | האם אפשר להשתמש בכלי הבדיקה המקומי ל-OT? | כן, אפשר להשתמש בכלי הבדיקה המקומי למשך כל תקופת ה-OT. אפשר להשתמש בכלי הבדיקה המקומי עם דוחות ניפוי באגים כל עוד קובצי ה-cookie של הצד השלישי זמינים. |
| ארגונומיה של שאילתות | הפעלת שאילתות על צבירה של מפתחות | אנחנו מסכימים שזה נראה כמו שיפור בארגונומיה של ה-API, עם עלות נמוכה או אפסית לכאורה לפרטיות. נציע הצעה ונבדוק אם יש הסכמה רחבה לגבי הצורך לתמוך בה. |
| נתונים פחות מדויקים לאתרים קטנים | יכול להיות שבאתרים או בקמפיינים קטנים יותר יתקבלו נתונים פחות מדויקים. | ב-Chrome אנחנו מבינים שלאמצעי הגנה על הפרטיות שמבוססים על רעש יש השפעה רבה יותר על פלחים קטנים יותר של נתונים. עם זאת, יכול להיות ששיטות כמו צבירת נתונים על פני תקופות זמן ארוכות יותר יפתרו את הבעיה הזו. כמו כן, לא ברור אם המסקנות שמבוססות על פלחי נתונים קטנים מאוד (כמו רכישה אחת או שתיים) משמעותיות למפרסמים. במהלך תקופת הניסיון במקור, אנחנו מעודדים את הבודקים לנצל את היכולת להתנסות במגוון רחב של פרמטרים של פרטיות ורעשי רקע, כדי שיוכלו לספק משוב ספציפי יותר לגבי הבעיה הזו. |
הגבלת מעקב סמוי
הפחתת מידע בסוכן משתמש
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| הגנה מפני בוטים | ההשפעה של UA-R על ההגנה מפני בוטים | אנחנו מעריכים את המשוב הזה, ואנחנו בתהליך איסוף מידע על גישות להגנה מפני בוטים כדי להשתמש בו בתכנונים העתידיים שלנו. |
| יחסי תלות בפריסה | טיפול ביחסי התלות בפריסה של סוכן משתמש מובנה (SUA) | השקנו את 'שלב 4', כלומר צמצום הגרסה המשנית, ל-100% ממשתמשי Chrome בגרסאות 101 ואילך. כאן מפורט העדכון. |
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| ציון כל ההנחיות הנתמכות | עניין בדרך פרוגרמטית לדעת אילו טיפים נתמכים בדפדפן. | תודה על המשוב. אנחנו בתהליך הערכה של בקשת התכונה. אנחנו רוצים להבין אם זהו תרחיש לדוגמה נפוץ. |
| הגמישות של כותרת UA-CH לעומת כותרת User-Agent | UA-CH הוא סטנדרטי מדי בהשוואה לגמישות שמציעה הכותרת User-Agent, כפי שמוגדרת ב-rfc7231. | ב-Chrome, הטבע המפרט של כותרות UA-CH נחשב לשיפור חשוב על פני הגמישות של מחרוזת UA, גם מבחינת יכולת הפעולה ההדדית העתידית בין דפדפנים וגם מבחינת ההגנה על פרטיות המשתמשים (על ידי מניעת הוספות שרירותיות של מזהים עם אנטרופיה גבוהה).
הבעיה נשארת פתוחה למקרה שאנשים אחרים יהיו מודאגים ממנה וירצו לשלוח משוב. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | תכונות מסוימות שעשויות ללכת לאיבוד דרך UA-CH: מעקב אחר הפניות אוטומטיות של קליקים וקליקים שמקורם בתרמית. | הצוות בודק את הבעיות האפשריות האלה עם בעלי עניין בתחום המניעה של הונאות ובתחום המדידה. |
| ביצועים | יש חששות לגבי זמן האחזור של קבלת הטיפים דרך Critical-CH (בטעינת הדף הראשונה). | אנחנו ב-Chrome בודקים דרכים לשיפור הביצועים. |
Gnatcatcher (WIP)
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| בעיות שקשורות לזמן אחזור | הוספת קפיצות נוספות עשויה להשפיע על זמן האחזור | אנחנו שוקלים להשתמש בשרת proxy עם שני קפיצות, ומחפשים דרכים למצוא את האיזון הנכון בין פרטיות המשתמשים לבין זמן האחזור. אנחנו פתוחים למשוב ונשמח לדון בנושאים האלה בפורומים של W3C. |
| הגנה מפני הונאות ובוטים | ההשפעה על ההגנה מפני הונאות ובוטים, כולל במדינות פחות מפותחות | הבטיחות היא דרישה מרכזית כשאנחנו מחפשים דרכים לשפר את פרטיות המשתמשים בדרכים משמעותיות, כמו שימוש בשרת proxy לכתובות IP. שרת proxy עם שני קפיצות בשיתוף עם חברות מהימנות מספק פרטיות משתמשים מאומתת. אנחנו גם מפתחים רעיונות לאותות חדשים שיעזרו לנו להעביר את האמון של המשתמשים. |
| תאימות לחוקי הפרטיות המקומיים | דיווח על נתונים גיאוגרפיים ברמת המדינה מקשה על עמידה בדרישות של משטרים מקומיים מפורטים יותר | פרסמנו את העקרונות המוצעים שלנו באופן ציבורי, והם כוללים גישות פוטנציאליות שיאפשרו לאתרים להמשיך לעמוד בדרישות המקומיות. |
חיזוק גבולות הפרטיות באתרים שונים
קבוצות מאינטראקציה ישירה (First-Party Sets)
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| התועלת לבעלי עניין מסוגים שונים | ההשפעה של FPS על בעלי תוכן דיגיטלי קטנים לעומת בעלי תוכן דיגיטלי גדולים | המטרה העיקרית של ארגז החול לפרטיות היא לשפר את פרטיות המשתמשים על ידי החלפת השיטות הנוכחיות בפתרונות שלא מסתמכים על מנגנוני מעקב באתרים שונים. אנחנו רוצים שהפתרונות האלה יהיו שימושיים ככל האפשר לגורמים שונים בעלי אינטרס, בגדלים שונים. נשמח לקבל מכם משוב ספציפי שאפשר ליישם כדי לשפר את הפתרונות האלה, ואנחנו צופים שהם ימשיכו להתפתח בעקבות דיונים ובדיקות בקהילה. |
| שיפור הפרטיות | אם תכללו יותר מדי אתרים באותה קבוצה, יכול להיות שתקבלו תוצאות דומות לאלה של קובצי Cookie של צד שלישי. | אנחנו מעריכים את המשוב הזה, ובודקים אם יש מגבלות מתאימות או מהן המגבלות המתאימות, תוך כדי ניסיון לספק למשתמשים ולמפתחים טיפול או אותות שיאפשרו להם להבין מתי הם מגיעים למגבלה כזו. עדיין אין לנו הצעה ספציפית לשתף, אבל אנחנו מקווים שנוכל לעשות זאת בקרוב מאוד. |
| תמיכה בסביבה העסקית של FPS | אוסף של תמיכה וחששות לגבי המשך הפיתוח של FPS מחוץ ל-Privacy CG | אמנם היינו מעדיפים שההצעה בנושא קבוצות של נתונים מאינטראקציה ישירה (First-Party) תישאר ב-PrivacyCG, אבל אנחנו מצפים להמשיך לקדם את ההצעה ב-WICG. קיבלנו גם הרבה הצהרות תמיכה בהחלטה שלנו להמשיך את הדיון בנושא קבוצות נתונים מאינטראקציה ישירה (First-Party) ובתרחישים לדוגמה שהן אמורות לטפל בהם. Google ממשיכה להיות מחויבת למצוא פתרונות שיאפשרו לאינטרנט להמשיך לגדול ולשגשג באופן שמגן על פרטיות המשתמשים ומכבד אותה. |
| יכולת פעולה הדדית בין דפדפנים | הטמעה בדפדפנים אחרים | אנחנו מבינים את החשיבות של יכולת הפעולה ההדדית בין הדפדפנים למפתחים, ונמשיך לשתף פעולה עם דפדפנים אחרים כדי לקדם את התקינה של FPS. |
| דרישות נפוצות לגבי מדיניות פרטיות | לא ניתן לנהל מדיניות פרטיות משותפת לכל המוצרים ולתחומי השיפוט שצריכים להיות חלק מאותה קבוצה. | אנחנו עדיין מגדירים את דרישות המדיניות של Chrome, ונביא בחשבון את המשוב הזה. |
Fenced Frames API
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| בקשה למסמכים | הבדלים ביחס למסגרות iframe בארגז חול (sandbox) | תודה על המשוב וההצעה. יש כרגע דיון בנושא הזה ב-GitHub, ואנחנו מקווים לקבל הבהרה סופית לגבי הבקשה כדי שנוכל להעריך אותה באופן מלא. הדיון הציבורי זמין כאן. |
| יכולות בכמה ממשקי API | תמיכת ברירת מחדל בדיווח על שיוך בפריימים מגודר | אנחנו מבקשים מכם משוב לגבי הצעה לאפשר ל-Attribution Reporting API לפעול במצב 'מודעות אטומות' של מסגרות מגודרות כברירת מחדל. אנחנו מעודדים מפתחים שיכול להיות שהתכונה הזו תהיה מועילה להם להביע את דעתם בדיון. |
Shared Storage API
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| מגבלות נתונים | האם תהיה הגבלה על כמות הנתונים שאפשר לאחסן בכל מחיצה? | כן, יהיו מגבלות. פרטים נוספים זמינים בבעיה ב-GitHub. נצטרך מכסות אחסון. ההצעה הנוכחית שלנו היא להגביל את הגודל של כל רשומה ל-4KB, המפתחות והערכים יהיו מוגבלים ל-1024 תווים מסוג char16_t כל אחד, והמגבלה על מספר הרשומות לכל מקור תהיה 10,000 רשומות, עם מנגנון שמונע ביצוע התחייבות לרשומות נוספות כשהקיבולת של המקור מלאה. אנחנו מבקשים מכם לשלוח משוב על המגבלות הספציפיות שהצענו כאן. |
| שקיפות למשתמשים | שקיפות למשתמשים לגבי מקורות הנתונים לעומת השימוש בנתונים | אנחנו מודים לך על המשוב, ואנחנו חושבים שזו גישה מבטיחה ששווה לבדוק. באופן ספציפי, אנחנו בודקים אם ניתן לעשות זאת באופן שמציע למשתמשים שקיפות מספקת. |
CHIPS
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| חסמים לאימוץ | האם CHIPS צריך להיות קשור לשם המארח? (הדרישה ללא דומיין) | אנחנו מסירים את הדרישה הזו מה-OT על סמך משוב ממשתתפי ה-OT, שלפיו הדרישה הזו הוסיפה מורכבות נוספת ושהיא מהווה מכשול לאימוץ CHIPS.
נדבר על הדרישה הזו בקבוצת Privacy Community Group כחלק מתהליך פיתוח התקנים כאן. |
| תרחישים לדוגמה לשימוש ב-CHIPS ב-Google Ads | האם אפשר להשתמש ב-CHIPS בתרחישי שימוש ב-Google Ads באתר אחד? | מעקב אחר משתמשים באתר אחד הוא תרחיש שימוש מותר. עדכנו את המאמר למפתחים כדי להדגיש את תרחיש השימוש הזה. |
| הטמעות מאומתות | האם מצב הכניסה נשמר באמצעות CHIPS? | המצב של כניסה לחשבון לא נשמר כרגע, אבל זה לא התרחיש לדוגמה המיועד ל-CHIPS. אנחנו מודעים לתרחיש לדוגמה של הטמעות מאומתות ואנחנו בודקים פתרונות. |
| תיאום בדיקות | האם נדרשות פעולות נוספות מצד המשתמש כדי לבדוק את חלוקת המחיצות? | כל עוד אסימון ה-OT תקף ומופיע בכותרות של הדפים שבהם המשתמש ביקר, התכונה אמורה להיות זמינה למשתמשים, בלי שהם יצטרכו לבצע פעולות נוספות. |
| תאימות דפדפן | עניין בהבנת האופן שבו דפדפנים אחרים מטפלים במאפייני קובצי cookie מחולקים. | אנחנו ב-Chrome ממשיכים לעבוד עם קבוצות סטנדרטים ציבוריות כמו W3C כדי לזהות עיצובים והטמעות שיכולים לפעול בדפדפנים שונים. |
FedCM
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| וקטורי תקיפה פוטנציאליים | כיווני התקפה פוטנציאליים באמצעות קישוטים של קישורים והתקפות תזמון | אנחנו אוספים משוב מהציבור ובודקים דרכים אפשריות לטיפול בבעיה הזו. |
| ממשק משתמש שמאפשר להשתמש במספר ספקי IDP | אפשר להציג רק IDP אחד בכל פעם | אנחנו מאמינים בתמיכה במספר ספקי IDP, ואנחנו פועלים באופן פעיל כדי לתמוך |
| יכולת הבעה | חשש מכך שחלק מתהליך איחוד הזהויות מתבצע בדפדפן, ולכן קשה לתעד את כל הניואנסים שספקי ה-IdP רוצים להציג למשתמשים שלהם. | אנחנו בוחנים ב-Chrome אפשרויות להוספת התאמות אישיות של מיתוג (למשל, סמלי לוגו, צבעים) והתאמה אישית של מחרוזות (למשל, 'גישה למאמר הזה' במקום 'כניסה באמצעות').
אנחנו ב-Chrome מבינים את הפשרה ונמשיך לעבוד עם הסביבה העסקית כדי לכסות כמה שיותר תחומים ולשפר את היכולת שלכם להביע את עצמכם. |
| תחולה ויכולת פעולה הדדית | חשש שדפדפנים אחרים לא יאמץ או יטמיעו את FedCM. | צוות Chrome עבד גם עם ספקי דפדפנים אחרים כדי למצוא פתרונות משותפים לאיחוד בקבוצת הקהילה FedID. |
| הצעה להסרת הדרישות למידע אישי בתהליך ההרשמה | (1) חוויית משתמש שמציינת למשתמש איזה IdP הוא בוחר, בלי לציין ששם האימייל, התמונה והשם שלו ישותפו, תהיה ידידותית יותר לפרטיות
(2) תרחישי שימוש – ההרשמה דלילה בחוויית המשתמש ובבחירת ההצהרות מה-IdP |
אנחנו מסכימים על כך, ואנחנו בודקים איך להטמיע את המשוב בצורה ידידותית יותר למשתמש ולפרטיות. |
| אינטראקציה של משתמשים עם IdP | צורך באינטראקציה ישירה בין המשתמש ל-IdP אם חרגתם מסף סיכון | אנחנו בודקים את המשוב הזה. |
חלוקת משאבי רשת למחיצות
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| ביצועים | חלוקת המצב של הרשת למחיצות עלולה להוביל לעלייה במספר החיבורים ל-CDNs שצורכים הרבה משאבים | אנחנו עדיין בודקים את מאפייני הביצועים של חלוקת המצב של הרשת למחיצות, כולל מדידה של שיטות מפתחות אפשריות שונות. עדיין לא קיבלנו החלטה לגבי האיזון בין הביצועים, האבטחה והפרטיות, ואנחנו צריכים לאסוף עוד נתונים. |
נלחמים בספאם ובהונאות
Trust Tokens API
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| משוב בנושא רגולציה | חששות לגבי השקעה של זמן ומשאבים בטוקנים שמורים לאימות ללא איתות ברור מהרגולטורים לגבי הכדאיות לטווח ארוך | המטרה שלנו היא ליצור טכנולוגיה שמתאימה לסביבה העסקית, ולכן המשוב מהתעשייה ומרשויות הרגולציה הוא קריטי בתהליך. אנחנו נמשיך להתייעץ עם רשויות רגולטוריות ברחבי העולם במהלך הפיתוח של ארגז החול לפרטיות, ונציע את ההצעות למפתחים, כולל אסימוני אמון. כמו בכל הטכנולוגיות החדשות, חברות צריכות לקבל החלטות על סמך ההערכה שלהן לגבי הדרישות הרגולטוריות. |
| תזמון ההשקה | מתי טוקנים שמורים לאימות יושקעו ב-GA? | אנחנו מספקים את האומדנים הנוכחיים שלנו למועד ההשקה בלוח הזמנים הציבורי שלנו בכתובת privacysandbox.com. ברגע שנקבל החלטה סופית לגבי תאריך ההשקה ב-GA, נפרסמם אותו באופן ציבורי באמצעות תהליכי ההשקה של Chrome ונעדכן את לוח הזמנים באתר. |
| Trust Tokens לעומת אחרים | מה התפקיד של אסימוני Trust בהתחשב באסימונים האחרים שעוברים סטנדרטיזציה, כמו אסימוני גישה פרטיים | אנחנו מעורבים בדיונים בנושא סטנדרטיזציה, והמטרה שלנו היא להתאים את עצמנו למאמצים אחרים ככל האפשר, תוך מתן אפשרות לשימוש בתרחישי השימוש השונים של כל טכנולוגיה. לדוגמה, גם אסימוני אמון וגם אסימוני גישה פרטיים מסתמכים על פרוטוקול Privacy Pass. |
| מגבלות נתונים | עד 2 מנפיקים למימוש אסימונים בכל דף, דבר שעלול להגביל | אנחנו מחפשים אפשרויות לטווח ארוך שבהן נוכל לאפשר לחברות לממש טוקנים בבטחה בלי להסתכן בהגדלת האנטרופיה של המשתמשים, אולי על ידי חלוקת הגישה לממשק למשיכת הטוקנים. |
| הגבלות גישה | רק מקורות שאושרו (ומקורות מפנים מאומתים או לא מזויפים) אמורים להיות מסוגלים לאמת את נוכחות האסימון ולממש אותו | אנחנו בודקים גישות לגבי מי יוכל לראות את הטוקנים ולממש אותם. |
| תמיכה במכשיר | יחסי התלות בסביבת זמן הריצה של JavaScript מגבילים את השימוש במכשירים מסוימים. האם אפשר להרחיב את התמיכה ב-TT כך שתעבוד במכשירים מסוגים אחרים? | זוהי אפשרות שאנחנו יכולים לשקול בפיתוח עתידי, ונושא שאנחנו נשמח לקבל עליו משוב נוסף ממפתחים בפורומים של W3C. יש לנו גם בעיה פתוחה בנושא מימוש אסימונים שמופעל על ידי כותרת HTTP, ואנחנו מזמינים אתכם לשלוח משוב עליה. |
| תרחישים לדוגמה | לא ברור מהם התרחישים המתאימים לשימוש בטוקנים לאימות. חוסר בהירות לגבי השימושים המיועדים. | המטרה שלנו היא לעודד חדשנות בתחום מניעת הונאות, ואנחנו מבינים שכל חברה עשויה להשתמש בשיטות קנייניות עם אסימוני אמון. לכן, לא פירטנו את השימושים המיועדים. עם זאת, סביר להניח שנרחיב את המסמכים שלנו כך שיכללו דוגמאות נוספות, שיהיו נקודות התחלה לשותפים שרוצים להתנסות ב-Google Analytics 4 או לאמץ אותו. |
| כיסוי של Trust Token | הסרת מדיניות התכונה 'trust-token-redemption' אמורה להגדיל באופן משמעותי את הכיסוי של אסימוני האמון. | אנחנו מביאים את הנושא הזה בחשבון כשאנחנו אוספים משוב מה-OT ומקבלים החלטות לגבי השלבים הבאים. |
| אמון במנפיק | למה כדאי לסמוך על אתרים שהנפיקו אסימוני אימות? | אין הנחיות לקבלת רישיון להנפקה – כל אחד יכול לעשות זאת. בעלי האפליקציות צפויים לעבוד רק עם מנפיקים שהם סומכים עליהם. בנוסף, גורמים חוקיים אחרים בסביבה העסקית של המודעות יפחיתו את הערך של תנועה שמשויכת למנפיקים חשודים או לא ידועים (או יפסיקו לקנות אותה) בסופו של דבר. |
| שירותים מוטמעים של צד שלישי | האם שירותים מוטמעים של צד שלישי יכולים לממש או לבקש אסימוני אמון? | כן, שירות מוטמע של צד שלישי יכול להנפיק ולפדות אסימוני Trust. |
| הסביבה העסקית של המנפיקים | אפשר להפיק תועלת רבה יותר אם אפשר לשתף אותות אמון עם חברות אחרות | מטרת Trust Tokens היא לשמש כרכיב פרימיטיבי ברמה נמוכה, וגורמים שתומכים בהם יכולים להשתמש בו כדי לשתף אותות של אמון או מוניטין. |
| תקורה של תחזוקה | ההטמעה הקריפטוגרפית שעומדת בבסיס הפעולות של Trust Token נמצאת ב-BoringSSL, ש-Google היא המנהלת הבלעדית שלו. איך יתבצע ניהול התחזוקה של הספרייה? | אסימוני האמון מסתמכים על פעולות קריפטוגרפיות סטנדרטיות (ראו פרוטוקול Privacy Pass) שאפשר להטמיע גם בספריות אחרות. אנחנו ממליצים למפתחים לבקש תמיכה בפעולות האלה בספריות שבוחרים, לפתח תמיכה כזו או לתחזק אותה. |
| תקורה של תחזוקה | לא ברור כמה זמן תהיה תמיכה בגרסאות הפרוטוקול | אנחנו בודקים אפשרויות ליצירת מסמך עם פרטים ספציפיים יותר לגבי מסגרות הזמן הצפויות לתמיכה בגרסאות הפרוטוקול. |
| מגבלות על מנפיקים | אם אתם נמצאים בחלק מרוחק יותר בשרשרת, יכול להיות שלא תהיה לכם הזדמנות להפעיל אסימוני אמון | ככל שיותר ארגונים יתחילו להשתמש באסימוני אמון, נוכל לראות יותר ויותר את סוגי הדינמיקה האלה של תזמון, ואנחנו בודקים פתרונות פוטנציאליים. כפי שמתואר למעלה, אנחנו מחפשים אפשרויות לטווח ארוך שבהן נוכל לאפשר לחברות לממש אסימונים בצורה בטוחה בלי להסתכן בהגדלת האנטרופיה של המשתמשים, וכך לצמצם את החשיבות של המיקום בדף או סדר הטעינה. |
פתרונות חדשים למניעת הונאות בשלבי פיתוח
| נושא המשוב
(דירוג לפי שכיחות) |
סיכום השאלות והחששות | תגובה מ-Chrome |
| אותות לאימות תקינות המכשיר | תמיכה חזקה באופן כללי בשימוש באותות של תקינות המכשיר שמאומתים על ידי פלטפורמות וזמינים באינטרנט | נמשיך לאסוף משוב ולקדם את ההצעה באמצעות תהליך עיצוב וחזרה על תהליך העבודה (iteration) שיהיו גלויים לכולם. |
| אותות אימות לתקינות המכשיר | שאלות לגבי כמות האנטרופיה של המשתמש שאפשר להעביר באמצעות אותות חדשים, והאם תרחישים לדוגמה מסוימים (כמו משתמש שנכנס לחשבון הבנק שלו) יכולים להצדיק אותות עם אנטרופיה גבוהה יותר. | כדי לשמור על פרטיות המשתמשים, אנחנו מעדיפים לספק אותות בעלי ערך גבוה עם אנטרופיה של משתמשים נמוכה ככל האפשר. |
| אותות אימות לתקינות המכשיר | האם האות הזה יגביל את הגישה למכשירים ישנים יותר או לפלטפורמות קוד פתוח/פלטפורמות ששונו? | בכל אות חדשה, צריך להתייחס לגישה אוניברסלית כעקרון מפתח בפיתוח. אלה שאלות חשובות שצריך לטפל בהן מראש, בזמן שאנחנו ממשיכים בתהליך ההשקה. |
| אותות אימות לתקינות המכשיר | הייתה דאגה מסוימת לגבי האפשרות שאותות חדשים יגרמו לחברות אבטחה וחברות למניעת הונאות להסתמך יותר מדי על הדפדפן והפלטפורמות
|
צריך להתייחס לכל אות חדש כנתון משלים, ולא כסימן ל'אמון' מהדפדפן. אנחנו צופים שספקי אבטחה ימשיכו להסתמך על הנתונים, המודלים ומנועי ההחלטות הקנייניים שלהם, עם אימות המכשיר כקלט נוסף. אנחנו מקווים שכל אות חדש ישפר את מאמצי הזיהוי בסביבה העסקית ויקשיח את ביצוע ההונאות. |
| אות לגבי גיל קובץ ה-Cookie | רעיון מעניין, אבל סביר להניח שצריך לבדוק לעומק את תרחישי השימוש הרלוונטיים. | בהתאם לרמת העניין, יכול להיות שצוות Chrome ימשיך לפתח את הרעיון הזה ויהפוך אותו להסבר למשוב עתידי על הסביבה העסקית. |
| שרתי אמון למניעת הונאות | רעיון מעניין, אבל סביר להניח שצריך לבדוק לעומק את תרחישי השימוש הרלוונטיים. | בהתאם לרמת העניין, יכול להיות שצוות Chrome ימשיך לפתח את הרעיון הזה ויהפוך אותו להסבר למשוב עתידי על הסביבה העסקית. |