דוח רבעוני לרבעון 2 של שנת 2022, שמסכם את המשובים שקיבלנו על הסביבה העסקית לגבי הצעות במסגרת ארגז החול לפרטיות והתגובה של Chrome.
כחלק מהמחויבויות שלה ל-CMA, Google הסכימה לספק באופן ציבורי דוחות רבעוניים על תהליך המעורבות של בעלי עניין להצעות של ארגז החול לפרטיות (ראו סעיפים 12 ו-17(c)(ii) במחויבויות). דוחות סיכום המשוב של ארגז החול לפרטיות נוצרים על ידי צבירת משובים ש-Chrome מקבל מהמקורות השונים, כפי שמפורט בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין ב-privacysandbox.com, פגישות עם בעלי עניין בתחום ופורומים של תקני אינטרנט. ב-Chrome מקבלים בברכה את המשוב שמתקבל מהסביבה העסקית, ובוחנים באופן פעיל דרכים לשלב את התובנות שנלמדו בקבלת החלטות לגבי תכנון.
נושאי המשוב מדורגים לפי מידת השכיחות לכל API. כדי לעשות את זה, מתבצעת צבירה של כמות המשוב שצוות Chrome קיבל לגבי עיצוב נתון, תוך ארגון בסדר יורד של כמות. כדי לזהות את הנושאים הנפוצים במשוב, עיינתי בדיונים שנשאלו בפגישות ציבוריות (W3C, PatCG, IETF), משוב ישיר, GitHub ושאלות נפוצות שהעלו הצוותים הפנימיים והטפסים הציבוריים של Google.
באופן ספציפי, נבדקו פרוטוקולים של פגישות עם גופים סטנדרטיים באינטרנט, וכדי לקבל משוב ישיר, נלקחו בחשבון הרשומות של Google לגבי פגישות אישיות עם בעלי עניין, אימיילים שהתקבלו מהמהנדסים, רשימת הדיוור של ה-API וטופס המשוב הציבורי. לאחר מכן, Google תאמה בין הצוותים שלקחו חלק בפעילויות ההפצה השונות כדי לקבוע את השכיחות היחסית של הנושאים שעלו ביחס לכל ממשק API.
ההסברים של Chrome למשוב פותחו על סמך שאלות נפוצות שפורסמו, תשובות בפועל לבעיות שהועלו על ידי בעלי עניין וקביעת מיקום באופן ספציפי למטרת תרגיל זה של דיווח ציבורי. עדכון בנושא הנוכחי, של הפיתוח והבדיקות, של השאלות והמשוב שקיבלנו באופן ספציפי על ממשקי ה-API של Topics, Flidge ו-Attribution.
יכול להיות שמשוב שהתקבל אחרי סיום תקופת הדיווח הנוכחית עוד לא נחשב כתגובה מ-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 |
| לוחות זמנים ברורים יותר | לוחות זמנים ברורים ומפורטים יותר לגרסאות של הטכנולוגיות של ארגז החול לפרטיות. | אנחנו מגדירים את התוכניות הנוכחיות שלנו לפריסה בכתובת privacysandbox.com ומעדכנים אותו מדי חודש. השיקולים האלה לוקחים בחשבון את זמן הפיתוח של מפתחי Chrome ושל מפתחי האתרים, וכן את המשוב שקיבלנו מהסביבה העסקית הרחבה יותר בזמן שנדרש כדי לבדוק את הטכנולוגיות החדשות ולאמץ אותן. כל טכנולוגיה עוברת כמה שלבים, מהבדיקה ועד ההשקה (השקה) והתזמון של כל שלב נקבע על סמך מה שלמדנו וגילינו בשלב הקודם. בשלב זה אין לנו מחויבות לגרסאות חדשות, אבל אנחנו נקפיד לעדכן את ציר הזמן הציבורי שלנו בכתובת privacysandbox.com. |
| שימושיות לסוגים שונים של בעלי עניין | חשש שהטכנולוגיות של ארגז החול לפרטיות מעדיפים מפתחים גדולים יותר, ושאתרים נישתיים (קטנים יותר) תורמים יותר מאשר אתרים גנריים (גדולים יותר). | אנחנו מבינים שלחלק מהמפתחים יש חששות לגבי ההשפעה של הטכנולוגיות של ארגז החול לפרטיות. Google התחייבה ש-CMA לא יתכנן או יטמיע את ההצעות של ארגז החול לפרטיות באופן שמעוות את התחרות על ידי העדפה עצמית של העסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי התוכן הדיגיטלי והמפרסמים, וכן על ההשפעות על תוצאות הפרטיות וחוויית המשתמש. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שעבודתנו עומדת בהתחייבויות האלה.
עם התקדמות הבדיקה של ארגז החול לפרטיות, אחת מהשאלות המרכזיות שנשאל אותה היא את הביצועים של הטכנולוגיות החדשות עבור סוגים שונים של בעלי עניין. משוב הוא קריטי מהבחינה הזו, במיוחד משוב ספציפי ומעשי שיכול לעזור לנו לשפר את העיצובים הטכניים. |
| לוחות הזמנים להוצאה משימוש של קובצי cookie של צד שלישי | בקשות למניעת עיכובים נוספים בהוצאה משימוש של קובצי cookie של צד שלישי | קיבלנו משוב מכמה בעלי עניין שרוצים להמשיך בהוצאה משימוש של קובצי cookie של צד שלישי ללא דיחוי, ושמענו ממשתמשים אחרים שנדרשים עוד זמן לבדיקת הטכנולוגיות של ארגז החול לפרטיות ולאמץ אותן. אנחנו מחויבים להמשך טיפול באופן אחראי עקב המורכבות של הטכנולוגיות והחשיבות של הסביבה העסקית של ביצוע דברים בצורה נכונה. לקבלת משוב מהתעשייה ומהרגולטורים, היה קריטי לתהליך הזה. |
| לוחות הזמנים להוצאה משימוש של קובצי cookie של צד שלישי | בקשות לעיכוב ההוצאה משימוש של קובצי cookie של צד שלישי, ולהארכת זמן לבדיקת ממשקי ה-API. | קיבלנו משוב מכמה בעלי עניין שרוצים להמשיך בהוצאה משימוש של קובצי cookie של צד שלישי ללא דיחוי, ושמענו ממשתמשים אחרים שנדרשים עוד זמן לבדיקת הטכנולוגיות של ארגז החול לפרטיות ולאמץ אותן. אנחנו מחויבים להמשך טיפול באופן אחראי עקב המורכבות של הטכנולוגיות והחשיבות של הסביבה העסקית של ביצוע דברים בצורה נכונה. לקבלת משוב מהתעשייה ומהרגולטורים, היה קריטי לתהליך הזה. |
| בקשות לתיעוד | בקשות למשאבים נוספים שמפרטים איך לנהל את הבדיקה, הניתוח וההטמעה. | אנחנו מעריכים את העובדה שהחומר העדכני שלנו מועיל למפתחים, ואנחנו מחויבים לספק עוד חומרים, כולל שעות העבודה של המפתחים ומסמכים טכניים במהלך השבועות והחודשים הקרובים, כדי שהמפתחים יוכלו להמשיך להבין איך הטכנולוגיות החדשות יכולות לעבוד בשבילם.
בנוסף, קיימנו סשנים ציבוריים של שעות העבודה למפתחים חיצוניים כדי לשתף שיטות מומלצות והדגמות ומפגשי שאלות ותשובות עם מומחי מוצר והנדסה, כדי לאפשר דיון בזמן אמת או העלאת שאלות. |
| מומחיות בתחום | לצוות של Chrome שעוסק בגופים תקנים אין מומחיות בסביבה העסקית של המודעות, שדרושה כדי לאזן כראוי בין פרטיות לבין תועלת. | אנחנו מבינים שיש לנו אחריות גדולה, ואנחנו מסתמכים על משוב ספציפי כדי לעשות את זה כמו שצריך. אנחנו גם מתייחסים לפרטיות ולאפקטיביות כקריטריונים קריטיים והכרחיים לתכנון התכנון. בכל חברי הצוות שעובדים על ארגז החול לפרטיות באינטרנט, חלפו מאות שנים של עבודה בתחום המודעות. |
הצגת תוכן ומודעות רלוונטיים
נושאים
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| שימושיות לסוגים שונים של בעלי עניין | הועלו חששות בנוגע לערך שנוצר ולהפצתו באתרים, בהתאם לרמת התנועה באתרים או למידת המיוחדות של התוכן שלהם. | נבדוק את התועלת של ממשק ה-API באמצעות בדיקות. ב-Chrome אנחנו מצפים שהטקסונומיה ופרמטרים אחרים ישתנו על סמך תוצאות הבדיקה. ייתכן שהתפתחות הטקסונומיה או הפרמטרים לא תדרוש שינויים שאינם תואמים לאחור. בנוסף, Chrome מצפה לקבל משובים ימשיכו להשפיע על ההתפתחות של Topics API אחרי ההוצאה משימוש של קובצי cookie של צד שלישי. |
| טקסונומיה | בעלי עניין בענף מעוניינים שיהיה להם קל להשפיע על הטקסונומיה. | Chrome נשאר פתוח להזנת קלט בטקסונומיה. אנחנו ב-Chrome מעוניינים מאוד לקבל משוב על מודל הפיקוח לשינוי הטקסונומיה, ולדון באופן שבו גופים אחרים בתחום יכולים למלא תפקיד פעיל יותר בפיתוח ובשמירה על הטקסונומיה בטווח הארוך. |
| אין מספיק היסטוריית גלישה | הצעה להצגת נושאים שהמתקשר ראה בשבועות קודמים אם אין למשתמש מספיק היסטוריית גלישה כדי ליצור 5 נושאים בשבוע האחרון | העיצוב הנוכחי שלנו נבחר באופן אקראי. אנחנו נבדוק את המתאם לנושאים מהעבר ונשקול אם יש אפשרות לשלב את זה. עם זאת, מתאמים עשויים להיות שיקולים שליליים בנוגע לפרטיות שיש להביא בחשבון. |
| קריאה ל-Topics מטעם בעל אתר | האם ספק שירות של צד שלישי יכול לשתף Topics עם בעל אתר? | כן, זו הדרך שבה אנחנו מצפים שייעשה שימוש ב-Topics. |
| וקטור תקיפה אפשריים | זיהוי הנושאים עם הרעש | על סמך משוב של גורמים רבים בסביבה העסקית, Chrome בחר לסנן נושאים ולהוסיף רעש. ההחלטות האלה התקבלו תוך התחשבות בפרטיות המשתמשים - במטרה להגביל את הגישה למידע של גורמים שלא הייתה להם גישה למידע כזה, וכן להציג הכחשה אפשרית למשתמשים, בהתאמה. אנחנו מבינים שלהחלטות האלה יש חסרונות, למשל וקטור ההתקפה המפורט כאן. עם זאת, ההערכה שלנו היא שיתרונות הפרטיות גדולים יותר מהסיכונים הפוטנציאליים. אנחנו מקבלים בברכה דיון ציבורי לגבי ההחלטה הזו. |
| הזכאות לתקופת ניסיון מקורית | האם יש דרך לזהות אם משתמש עומד בדרישות לגרסת ניסיון מקורית? | יכול להיות שהתכונה של גרסת המקור לניסיון לא תהיה זמינה למשתמש בגלל הגדרות הדפדפן או גורמים אחרים, גם אם המשתמש נכנס לדף אינטרנט שמספק אסימון חוקי של גרסת ניסיון, והדפדפן שלו נכלל בקבוצה שבה מופעלת תקופת הניסיון.
לכן, תמיד צריך להשתמש בזיהוי תכונות כדי לבדוק אם תכונה בגרסת המקור לניסיון זמינה, לפני שמנסים להשתמש בה. |
| השפעות על הביצועים | בעיות בתקורה ובזמן אחזור ב-Topics | אנחנו מבקשים משוב לגבי גישות למניעת מסגרות iframe יקרות ואיטיות במקור x, ולגבי ההצעה לנתק את ה-Topics API כך שקבלת נושאים לא תשנה את מצב הגלישה. |
| הפונקציונליות של Split Topics API | מתן שליטה רבה יותר בשלושת ההיבטים השונים של ה-API | הבנו את התרחיש לדוגמה והצענו דרך אפשרית לפתור את הבעיה ב-GitHub. אנחנו ממתינים כרגע לקבלת משוב נוסף מהסביבה העסקית כדי להחליט אם לפתח את הפונקציונליות הזו. כאן אפשר לראות את הדיון המתמשך. |
| ציר הזמן והתיעוד של המסווג | מפתחים ביקשו מידע נוסף על המסווג. | כאן סיפקנו באופן ציבורי מידע נוסף על המסווג.
וגם כאן וכאן |
| בקרות ובטיחות של המשתמשים | נושאים מסוימים עשויים להיות שרתי proxy בקבוצות רגישות, והמשתמשים זקוקים לאמצעי בקרה נוספים כדי למנוע תוצאות שליליות. | הנושאים מייצגים צעד משמעותי קדימה לשיפור השליטה והשקיפות של המשתמשים. המשתמשים יוכלו לבטל את ההסכמה לנושאים, לבדוק את הנושאים שהוקצו להם, להסיר נושאים ולהבין אילו חברות נמצאות באינטראקציה עם הנושאים שלהן בדף נתון. בנוסף, משתמשים יכולים להשפיע על הנושאים שלהם על ידי מחיקה של היסטוריית הגלישה שלהם. אנחנו מקבלים בברכה דיון מתמשך לגבי אמצעי בקרה מתקדמים יותר למשתמשים, כמו אלה שהוצעו על ידי המפתחים. עם זאת, אנחנו חייבים לוודא שהסיכונים הכרוכים בבאג הזה אכן יוסרו מהסיכונים (למשל, הסרת הנושא רק את הנושא 'מחקר שפות זרות' ולא של האתרים שיצרו את הנושא מהיסטוריית הגלישה לא מגינה על המשתמש באופן מלא). |
| שימוש בנושאים באתרים עם prebid.js | האם אפשר להשתמש ב-Topics API באתרים עם prebid.js? | התשובה הקצרה היא כן. מידע נוסף פורסם כאן. |
| שימוש ב-Topics API בווידג'ט המלצות | האם אפשר להשתמש ב-Topics API בווידג'ט המומלץ (למשל, Outbrain) | אנחנו לא מגבילים את התרחיש לדוגמה של נושאים שאוחזרו לאחר הקריאה ל-API (תלוי במדיניות הנתונים של כל מפתח). |
| פרטיות / מדיניות | שאלות לגבי המטרה של סינון תשובות לפי מתקשר אם צדדים שלישיים מסוימים ישתפו את הנושאים שלהם עם כל מי שמתקשר. | על סמך משוב שקיבלנו ממשתמשים רבים בתחום, Chrome בחר בעיצוב הזה להגביל את הגישה למידע של אנשים שאחרת לא הייתה להם גישה למידע כזה. כמובן שבעלי תוכן דיגיטלי וצדדים שלישיים שמקבלים את Topics יכולים להחליט בעצמם איזה מידע הם ישתפו עם צדדים באתר שלהם. אם הם מבצעים שיתוף כזה, מומלץ ב-Chrome לפעול בשקיפות מול המשתמשים לגבי שיתוף כזה, ולהציע להם אמצעי בקרה. |
| אותות רועשים | הצגת נושא אקראי ב-5% מהזמן עלולה ליצור יותר מדי רעש או אות כוזב. | רעש הוא שיטה חשובה להגנה על פרטיות המשתמשים. בנוסף, נבדוק את רמות ה"רעש" לעומת מידת השימושיות של הנושאים במסגרת הבדיקות. |
FLEDGE
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| תיאום בדיקות | בדיקת ההשפעה על הביצועים וההכנסות | בפגישות הציבוריות של WICG אנחנו מדברים באופן פעיל על ביצועי FLEDGE, ואיך אנחנו יכולים לתמוך בבדיקות של הסביבה העסקית בצורה הטובה ביותר במהלך ניסויי המקור ובזמינות לכלל המשתמשים. |
| שרת מהימן עבור FLEDGE | מתי השרת המהימן יהיה זמין לבדיקה? | אנחנו מעריכים את המשוב הזה ועובדים בפועל על תוכנית מפורטת יותר שנוכל לשתף לשימוש בשרתים מהימנים ב-FLEDGE. |
| סטנדרטיזציה של פרוטוקול | האם יהיה פרוטוקול משותף להעברת נתונים בין SSP ו-DSP, כמו תוויות נפוצות לקבוצות של אינטרסים? | נשמח לקבל משוב מפלטפורמות DSP, פלטפורמות SSP ומהסביבה העסקית הרחבה יותר של מודעות לגבי האחדה פוטנציאלית של המפרט. למטרות בדיקה ראשונית בשלב זה, מומלץ לעבוד ישירות עם שותפי הבדיקה שלך, כי הם נמצאים בתהליך של ניסוי גישות שונות. אנחנו גם מעודדים ארגוני סחר במודעות, ומתכננים להמשיך לעבוד איתם, כדי לנסות ליצור סטנדרטיזציה במקרים שבהם הדבר שימושי לחברות החברות בהם. |
| מכסת תדירות | בקרות תדירות לכל משתמש בקמפיין ובקבוצת מודעות. | FLEDGE יתמוך במכסת תדירות גם במכרזים במכשיר ובקמפיינים לפי הקשר / מיתוג. ניתן להשתמש באחסון משותף ובמכסות ספציפיות לאתר גם לבקרות נוספות של מכסת התדירות. |
| ההשפעה של FLEDGE על הביצועים | מגישי הצעות מחיר אינטנסיביים מאוד במכירה הפומבית של FLEDGE | Chrome מנהל דיונים פעילים עם מפתחים לגבי ההשפעה הפוטנציאלית על ביצועי האתר. ב-Chrome מוצגת הזדמנות לקבל מידע נוסף במהלך הבדיקה. |
| בדיקה של FLEDGE עם תכונות אחרות | איך הדוחות ברמת האירוע מ-Attribution Reporting API ומה-FLEDGE מתאימים זה לזה? | הנושא הזה נכתב בשיחה שבוצעה לאחרונה באמצעות WICG/conversion-measurement-api, עם קישור לדקות המפורטות כאן.
בסיכום הפגישה, לפי העיצוב הנוכחי של דיווח על מודעות ב-Fenced Frames ניתן לשייך מזהה שנוצר בתוך Fenced Frame למידע הקשרי. לכן, דוחות ברמת האירוע שנוצרו בתוך Fenced Frame יהיו ניתנים לצירוף לאותו מידע הקשרי בשרת (באמצעות שני איחודים בצד השרת במקום 1). |
| ספירת חשיפות | באיזו מתודולוגיה לספירת חשיפות אפשר להשתמש בין קונים למוכרים, או שאפשר להשתמש בה | ב-FLEDGE API כבר יש תמיכה במתודולוגיה בין המוכר לקונה במהלך המכרז. קיבלנו הצעות בנוגע להטמעות חלופיות ללא משוב על הסיבה לכך שהעיצוב הנוכחי שלנו לא מתאים לסביבה העסקית. |
| הצגת מודעות מרובות | אם יחידה אחת יכולה להציג מספר מודעות במכרז אחד ב-Fenced Frame נתונה | בשלב זה הדבר אפשרי באמצעות מודעות רכיבים (בניגוד למכירות פומביות של רכיבים). כדי לעשות זאת, כל המודעות חייבות להיות באותה קבוצה של תחומי עניין. |
| מפרט 'קהלים בהגדרת מפיץ (SDA)' ו-FLEDGE | האם FLEDGE יכול להפוך למנגנון שימנע מקונים לבנות פרופילים מ-SSDA בבקשות להצגת מודעות? | FLEDGE נועד למנוע דליפת מידע שאינו רלוונטי כאשר בעל התוכן הדיגיטלי כבר יודע באילו פעילויות SDA נמצאים המבקרים והטירגוט הוא באותו אתר. אם חשוב לתמוך בקנייה ב-SSD מתוך כל ההגנות שמובנות ב-FLEDGE, המוכר יכול להעביר תוויות SDA למכירה הפומבית במכשיר, ופתרון פרסום של מודעה בצד הקונה יוצר קבוצת תחומי עניין משלו שלוגיקת הבידינג שלו היא "אני רוצה לקנות קהל X". |
| תמיכה במטבעות שאינם דולר ארה"ב | תמיכה בבדיקת FLEDGE עם מטבעות מעבר לדולר ארה"ב | אנחנו מעריכים את ההסבר הזה והוספנו תמיכה במטבעות אחרים בתוך העיכוב של הבקשות להוספת תכונות. אנחנו מקווים שהתכונה הזו תהיה זמינה בקרוב. |
| תמיכה בטירגוט שלילי לקבוצת תחומי עניין | ממשק API התומך בטירגוט שלילי של IG: הצגת מודעות רק אם המשתמש לא שייך ל-IG. | דיון מתמשך, כולל כמה הצעות לתמיכה בבעיה ב-github. |
| כמה SSP ב-FLEDGE | הסיכון להעדיף את Google בהטמעה של מכרזים רב-שלביים ב-FLEDGE | נוספה תמיכה במספר פלטפורמות SSP ב-FLEDGE כדי שהמשחק ימשיך להיות הוגן ושוויוני. במסגרת ההתחייבויות, Google התחייבה לא לתכנן, לפתח או ליישם את ההצעות של ארגז החול לפרטיות באופן שיעוות את התחרות על ידי מתן עדיפות למוצרים ולשירותים שלה במסגרת המחויבות. Google מתייחסת לנושא ברצינות, ופתוחה מאוד לדון בחששות של בעלי עניין בנוגע להיבטים ספציפיים של הטכנולוגיה. למידע נוסף, מערכת Chrome תיעדה באופן ציבורי את מנגנון המכרז של רכיבים כאן. |
מדידת מודעות דיגיטליות
דוחות שיוך (Attribution) (וממשקי API אחרים)
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| ייחוס לכמה נקודות מגע | בעלי תוכן דיגיטלי שמבקשים תמיכה בשיוך לכמה נקודות מגע | השיטות הנוכחיות של שיוך לכמה נקודות מגע מחייבות קישור דטרמיניסטי בין חשיפות המשתמש (ולכן גם הזהות שלו) באתרים שונים. כתוצאה מכך, הפונקציונליות הזו במתכונתה הנוכחית לא תואמת ליעדים של ארגז החול לפרטיות, שמטרתו לתמוך בתרחישי שימוש מרכזיים במודעות ללא מעקב באתרים שונים. במקרים מסוימים, ניתן לקבל הערכה להקצאת הקרדיט (למשל, באמצעות סדרי עדיפויות משוקללים ואקראיים) ללא מעקב אחר משתמשים ספציפיים. |
| יצירת רעש | שאלות לגבי רמות ה"רעש" בדוחות | הניסוי הראשוני שלנו מאפשר למפתחים להגדיר ערך אפסילון משלהם כדי לחוות כיצד הדוחות משתנים על סמך רמת הרעש. נכון לעכשיו, המפתחים יכולים לבחור בערך אפסילון עד epsilon=64. יצרנו את האפשרות הזאת במיוחד כדי להקל על מפתחים לבדוק את ממשקי ה-API ולספק לנו משוב לגבי ערכים מתאימים של אפסילון.
בנוסף, שלחנו בקשה ציבורית למשוב כזה. |
| תיאום בדיקות | האם אפשר להשתמש בכלי הבדיקה המקומי ל-OT? | כן, אפשר להשתמש בכלי הבדיקה המקומי במהלך תקופת ה-OT. אפשר להשתמש בכלי הבדיקה המקומי עם דוחות לניפוי באגים, כל עוד יש קובצי cookie זמינים של צד שלישי. |
| ארגונומית שאילתות | הפעלת שאילתות על צבירה של מפתחות | אנחנו מסכימים שהדבר משפר את הארגונומיה של ממשקי ה-API עם עלות פרטיות מינימלית, אם בכלל. אנחנו נציע הצעה ונבדוק אם קיימת הסכמה רחבה לגבי הצורך לתמוך. |
| נתונים פחות מדויקים לאתרים קטנים | אתרים או קמפיינים קטנים יותר עשויים לקבל נתונים מדויקים פחות. | ב-Chrome מבינים שלאמצעי הגנה על פרטיות המבוססים על רעש יש השפעה גדולה יותר על פלחי נתונים קטנים יותר. עם זאת, ייתכן ששיטות כמו צבירת נתונים על פני תקופות זמן ארוכות יותר יפתרו את הבעיה הזו. לא ברור גם אם למסקנות המבוססות על פלחי נתונים קטנים מאוד (כמו רכישה אחת או שתיים) יש משמעות למפרסמים. במהלך גרסת המקור לניסיון, Chrome מעודד את הבודקים לנצל את האפשרות להתנסות במגוון רחב של פרמטרים של פרטיות ורעש כדי שיוכלו לספק משוב ספציפי יותר לגבי הבעיה הזו. |
הגבילו מעקב סמוי
הפחתת מידע בסוכן משתמש
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| הגנה על בוטים | ההשפעה של UA-R על ההגנה על בוטים | אנחנו מעריכים את המשוב הזה ונמצאים בתהליך של איסוף מידע על גישות להגנה על בוטים כדי לשפר את התוכניות שלנו בעתיד. |
| תלות של הפרויקט בפריסה | התייחסות ליחסי תלות של הפריסה של סוכן המשתמש (SUA) | השקנו את "שלב 4", כלומר צמצום של הגרסה המשנית ל-100% ממשתמשי Chrome בגרסאות 101 ואילך. כדאי לעיין בעדכון כאן. |
רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| מספור של כל הרמזים הנתמכים | עניין בדרך פרוגרמטית להכיר את כל הרמזים הנתמכים לדפדפן. | אנחנו מעריכים את המשוב הזה ואנחנו בודקים את הבקשה להוספת תכונה. נשמח לדעת אם זה תרחיש נפוץ. |
| הגמישות של הכותרת UA-CH לעומת הכותרת של סוכן המשתמש | השימוש ב-UA-CH כללי מדי בהשוואה לגמישות שכותרת סוכן המשתמש מציעה, כפי שהוגדר על ידי rfc7231. | מבחינת Chrome, האופי המנהלי של כותרות UA-CH הוא שיפור חשוב על הגמישות של מחרוזת ה-UA, גם מנקודת המבט של יכולת פעולה הדדית בסופו של דבר בין דפדפנים וגם הגנה על פרטיות המשתמשים (על ידי מניעת הוספה שרירותית של מזהים עם אנטרופיה גבוהה).
הבעיה עדיין פתוחה למקרה שגם אחרים שיתפו את הבעיה וירצו לספק משוב. |
| UA-CH: חששות בנוגע למניעת הונאה או להתנהלות פוגעת | תכונות מסוימות שעלולות ללכת לאיבוד באמצעות UA-CH: מעקב אחר הפניות מחדש של קליקים וקליקים שמקורם בתרמית. | הצוות בוחן את הבעיות הפוטנציאליות האלה עם בעלי עניין בתחום מניעת הונאה ומדידה. |
| ביצועים | יש חששות לגבי זמן האחזור של קבלת רמזים דרך קריטי-CH (בטעינת הדף הראשונה). | Chrome בודק דרכים לשיפור הביצועים. |
Gnatcatcher (WIP)
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| חששות לגבי זמן האחזור | הוספת צעדים נוספים עשויה להשפיע על זמן האחזור | אנחנו שוקלים להשתמש בשרת proxy דו-שלבי ובוחנים דרכים למצוא את האיזון הנכון בין פרטיות המשתמשים לזמן האחזור. אנחנו פתוחים לקבלת משוב, ונשמח להמשיך בדיון בפורומים של W3C. |
| הגנה מפני בוטים והונאות | ההשפעה על הונאות והגנה על בוטים, כולל במדינות פחות מפותחות | בטיחות היא דרישה מהותית, כי אנחנו מחפשים דרכים לשיפור פרטיות המשתמשים בדרכים משמעותיות, כמו העברה של כתובות IP לשרת proxy. שיתוף פעולה עם שרת Proxy דו-שלבי עם חברות מהימנות מספק פרטיות משתמשים ניתנת לאימות. בנוסף, אנחנו "מטמיעים" רעיונות לאותות חדשים שיעזרו לכם לחזק את האמון של המשתמשים. |
| ציות לחוקי הפרטיות המקומיים | דיווח על נתונים גיאוגרפיים ברמת המדינה מקשה על ציות לתקנות מקומיות מפורטות יותר | פרסמנו באופן ציבורי את העקרונות שלנו, הכוללים גישות אפשריות שיאפשרו לאתרים לעמוד בדרישות המקומיות. |
חיזוק גבולות הפרטיות בין אתרים
דומיינים של צד ראשון
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| שימושיות לסוגים שונים של בעלי עניין | ההשפעה של FPS על בעלי תוכן דיגיטלי קטנים לעומת בעלי תוכן דיגיטלי גדולים | המטרה העיקרית של ארגז החול לפרטיות היא לשפר את פרטיות המשתמשים על ידי החלפת השיטות הקיימות בפתרונות שלא מסתמכים על מנגנוני מעקב באתרים שונים. אנחנו רוצים שהפתרונות האלה יהיו שימושיים ככל האפשר לסוגים שונים ולגדלים שונים של בעלי עניין. נשמח לקבל מידע ספציפי ומעשי שמפרט איך אפשר לשפר את הפתרונות האלה, ואנחנו מצפים שהם ימשיכו להתפתח בדיונים ובבדיקות של הקהילה. |
| שיפור הפרטיות | אתרים רבים מדי באותה קבוצה עלולים להוביל לתוצאות הדומות לקובצי Cookie של צד שלישי | אנחנו מעריכים את המשוב הזה ובוחנים אם המגבלות הנכונות חלות או מהן, ויחד עם זאת מנסים לספק גם למשתמשים וגם למפתחים טיפול או סימנים שיוכלו להבין במקרה של חריגה מהתקרה הזו. אין לנו עדיין הצעה ספציפית לשתף, אבל אנחנו מקווים לשתף אותך בקרוב. |
| תמיכה ב-FPS במערכת האקולוגית | איסוף תמיכה וחששות בנוגע להמשך פיתוח ה-FPS מחוץ לתוכנית הפרטיות CG | אנחנו מעדיפים שההצעה של הדומיינים של הצד הראשון תישאר במסגרת מדיניות הפרטיות CG, אבל אנחנו מצפים להמשיך לקדם את ההצעה ב-WICG. נוסף לכך, קיבלנו אינספור הצהרות תמיכה בנושא הזה עוד ועוד בדיון בנושא דומיינים של צד ראשון ותרחישים לדוגמה שבהם אנחנו מתכוונים לטפל. Google ממשיכה להיות מחויבת למציאת פתרונות שיאפשרו לאינטרנט להמשיך לצמוח ולשגשג באופן שמגן על פרטיות המשתמשים ומכבד אותה. |
| יכולת פעולה הדדית בדפדפן | הטמעה על ידי דפדפנים אחרים | אנחנו מכירים בחשיבות של יכולת הפעולה ההדדית בדפדפן למפתחים ונמשיך לשתף פעולה עם דפדפנים אחרים כדי ליצור תקן ל-FPS. |
| דרישות נפוצות של מדיניות פרטיות | לא ניתן לשמור על מדיניות פרטיות משותפת לכל המוצרים, וסמכויות שיפוט שצריכות להיות חלק מאותה קבוצה. | Chrome עדיין מגדיר את דרישות המדיניות שלנו, והוא יזכור את המשוב הזה. |
ממשק API של Fenced Frames
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| בקשת תיעוד | הבדלים בין מסגרות iframe שבארגז חול (sandbox) | תודה על המשוב וההצעה. מתקיים דיון על כך ב-GitHub כרגע, ואנחנו מקווים שנוכל להבין טוב יותר את מהות הבקשה כדי שנוכל להעריך אותה במלואה. הדיון הציבורי זמין כאן. |
| יכולות שמקושרות ל-API | תמיכת ברירת מחדל בדוחות שיוך (Attribution) ב-Fenced Frames | אנחנו מבקשים משוב לגבי הצעה לאפשר את Attribution Reporting API ב'מצב מודעות אטומות' של מסגרות עם גבולות כברירת מחדל. אנחנו מעודדים מפתחים שעשויים להפיק תועלת מדיון זה. |
ממשק API לאחסון משותף
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| מגבלות נתונים | האם תהיה הגבלה על כמות הנתונים שאפשר לאחסן בכל מחיצה? | כן, יהיו הגבלות. לפרטים נוספים, אפשר לעיין בבעיה ב-github. נזדקק למכסות האחסון. בשלב זה ההצעה שלנו היא לקבוע מגבלת גודל של 4KB לכל רשומה, המפתחות והערכים יוגבלו ל-1,024 תווי char16_t בכל פיסה, ומכסת כניסה של 10,000 ערכים לכל מקור עם מנגנון המונע התחייבות של רשומות נוספות כאשר מקורות המקורות מלאים. אנחנו רוצים לקבל ממך משוב על המגבלות הספציפיות שמוצעות כאן. |
| שקיפות למשתמשים | שקיפות למשתמשים לגבי מקורות נתונים לעומת שימוש בנתונים | אנחנו מעריכים את המשוב הזה, ולדעתנו זו גישה מבטיחה שכדאי לחקור. בפרט, אנחנו בוחנים אם ניתן לעשות זאת באופן שיאפשר שקיפות מספקת למשתמשים. |
צ'יפים
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| מכשולים שקשורים לאימוץ | האם CHIPS צריך להיות קשור לשם מארח? (הדרישה ללא דומיין) | אנחנו מסירים את הדרישה הזו מ-OT על סמך משוב ממשתתפי OT על כך שהדרישה הזו מוסיפה מורכבות, ומשמשת כמכשול לשימוש ב-CHIPS.
כאן נדון בדרישה הזו בקבוצת קהילת הפרטיות, כחלק מהטמעת הסטנדרטים. |
| תרחישים לדוגמה של מודעות עבור CHIPS | האם אפשר להשתמש ב-CHIPS בתרחישים לדוגמה של Google Ads באתר אחד? | מותר להשתמש במעקב אחר משתמשים באתר אחד. עדכנו את המאמר שלנו למפתחים כדי להדגיש את התרחיש לדוגמה הזה. |
| הטמעות מאומתות | האם מצב הכניסה נשמר עם CHIPS? | מצב הכניסה לחשבון לא נשמר כרגע, אבל זה לא התרחיש לדוגמה הנדרש עבור CHIPS. אנחנו מודעים לתרחיש לדוגמה של הטמעות מאומתות, ואנחנו פועלים לבדיקת פתרונות. |
| תיאום בדיקות | האם יש צורך בפעולות נוספות מצד המשתמש כדי לבדוק את החלוקה למחיצות? | כל עוד אסימון ה-OT תקין ומוצג בכותרות של הדפים שבהם אנשים מבקרים, התכונה צריכה להיות זמינה למשתמשים ללא צורך בפעולות נוספות מצד המשתמש |
| תאימות דפדפן | אני רוצה להבין איך דפדפנים אחרים טיפלו במאפיינים של קובצי cookie שמחולק למחיצות. | Chrome ממשיך לפעול במסגרת קבוצות תקנים ציבוריים, כמו W3C, כדי לזהות עיצובים והטמעות שיכולים לעבוד בדפדפנים שונים. |
FedCM
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| וקטור תקיפה אפשריים | וקטורי תקיפה פוטנציאליים באמצעות עיטור קישורים והתקפות תזמון | אנחנו אוספים באופן פעיל דיווחים מהציבור ובוחנים דרכים אפשריות לטיפול בבעיה הזו. |
| חוויית משתמש כדי לאפשר מספר זהויות (IdPs) מרובות | אפשר להציג רק IdP אחד בכל פעם | אנחנו מאמינים בתמיכה במספר ספקי זהות (IdPs) ומפתחים גישות לתמיכה |
| אקספרסיביות | הם חוששים שמכיוון שהדפדפן הופך חלק מזרימת הזהות המאוחדת, קשה לתעד את כל הניואנסים שה-IdP מעוניינים להציג למשתמשים שלהם. | Chrome בודק את עצמו, כולל התאמות אישיות של מיתוג (למשל סמלי לוגו, צבעים) והתאמה אישית של מחרוזות (למשל 'גישה למאמר זה' במקום 'התחברות באמצעות').
Chrome מזהה את הפשרה וימשיך לעבוד עם המערכת האקולוגית כדי לכסות כמה שיותר שטח וליצור אותה בצורה מפורטת ככל האפשר. |
| שעליהם חל המבצע ויכולת פעולה הדדית | חשש שדפדפנים אחרים לא יאמצו או מטמיעים את FedCM. | Chrome עובד גם עם ספקי דפדפנים אחרים כדי למצוא פתרונות נפוצים לאיחוד בקבוצת קהילת FedID. |
| הצעה להסיר את הדרישות לגבי מידע אישי בתהליך ההרשמה | (1) חוויית משתמש שמציינת למשתמש איזה IdP הוא בוחר, בלי לציין שכתובת האימייל, התמונה והשם שלו ישותפו, תהיה ידידותית יותר לפרטיות.
(2) ההרשמה לתרחישי שימוש היא מועטה בחוויית המשתמש ובבחירת ההצהרות מה-IdP |
אנחנו מסכימים, ואנחנו בוחנים איך להטמיע את המשוב באופן ידידותי יותר למשתמש, תוך שמירה על פרטיות. |
| אינטראקציית משתמשים עם IdP | צורך באינטראקציה ישירה בין המשתמש ל-IdP במקרה של חריגה מסף הסיכון | אנחנו בודקים את המשוב הזה. |
חלוקה למחיצות של מצב הרשת
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| ביצועים | חלוקה למחיצות של מצב הרשת עלולה להוביל לעלייה במספר החיבורים שצורכים משאבים רבים ל-CDN | אנחנו עדיין בודקים את מאפייני הביצועים של חלוקה למחיצות במצב הרשת, כולל מדידה של סכמות אפשריות שונות של יצירת מפתחות. עדיין לא קיבלנו החלטה לגבי הפשרות של הביצועים, האבטחה והפרטיות ועלינו לאסוף נתונים נוספים. |
נלחמים בספאם ובהונאות
API ל-Trust Tokens
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| משוב רגולטורי | חששות לגבי השקעת זמן ומשאבים באסימוני Trust ללא אות ברור מרגולטורים לגבי כדאיות לטווח הארוך | המטרה שלנו היא לפתח טכנולוגיה שפועלת לטובת הסביבה העסקית, ולספק משוב חיוני מהתעשייה ומהרגולטורים. נמשיך להתייעץ עם סוכנויות רגולטוריות ברחבי העולם בזמן שאנחנו מפתחים את ארגז החול לפרטיות ונפעיל את ההצעות האלה למפתחים, כולל Trust Tokens. כמו בכל הטכנולוגיות החדשות, חברות צריכות לקבל החלטות על סמך ההערכה שלהן ביחס לדרישות הרגולטוריות. |
| תזמון ההשקה | מתי יושקו אסימוני האימות ב-Google Analytics? | אנחנו מספקים את ההערכות הנוכחיות שלנו לגבי המסירה בציר הזמן הציבורי שלנו בכתובת privacysandbox.com. ברגע שנקבל החלטה סופית לגבי מועד המסירה ב-Google Analytics, נפרסם אותה באופן גלוי לכולם דרך תהליכי ההפצה של Chrome ונעדכן את לוח הזמנים באתר. |
| אסימוני Trust לעומת אחרים | מה התפקיד של אסימוני Trust Tokens אחרים שעוברים תהליך תקינה, כמו אסימוני גישה פרטית | אנחנו מעורבים בדיונים על יצירת תקן והמטרה שלנו היא להתאים ככל האפשר למאמצים אחרים, תוך מתן אפשרות להשתמש בתרחישים שונים בהתאם לכל טכנולוגיה. לדוגמה, אסימוני Trust Tokens וגם אסימוני גישה פרטית מסתמכים על הפרוטוקול Privacy Pass. |
| מגבלות נתונים | עד 2 מנפיקים למימוש אסימונים בכל דף, שעשויים להגביל את האפשרות | אנחנו מחפשים אפשרויות לטווח ארוך שיאפשרו לחברות לממש אסימונים באופן בטוח בלי לסכן עוד יותר את אנטרופיה של המשתמשים, אולי על ידי חלוקה למחיצות של הגישה למימוש אסימונים. |
| הגבלות גישה | רק מקורות מאושרים (ומאומתים/לא מזויפים) יכולים לאמת נוכחות של אסימון ולממש אותו | אנחנו בוחנים גישות לגבי מי יכול לראות ולממש אסימונים. |
| תמיכה במכשיר | השימוש במגבלות יחסיות של זמן ריצה ב-JavaScript במכשירים מסוימים מוגבל. האם ניתן להרחיב את תמיכת TT כך שתפעל במכשירים מסוגים אחרים? | אנחנו יכולים לקחת את זה בחשבון בפיתוח עתידי. נשמח לקבל משוב נוסף ממפתחים בפורומים של W3C. יש לנו גם בעיה פתוחה לדיון בדיון בכותרת HTTP שהפעילה מימוש אסימון, ואנחנו מזמינים אותך לקרוא עליו משוב. |
| תרחישים לדוגמה | לא ברור מהם התרחישים לדוגמה המתאימים לאסימוני Trust. אין בהירות לגבי השימושים המתוכננים. | המטרה שלנו היא לקדם חדשנות בתחום נגד הונאה, ולהבין שכל חברה עשויה להשתמש בטכניקות קנייניות עם אסימוני מהימנות, ולכן לא היינו חד-משמעיים לגבי השימושים הייעודיים. עם זאת, סביר להניח שנרחיב את התיעוד כדי לכלול דוגמאות נוספות כנקודות התחלה לשותפים ששוקלים לבצע ניסויים או לאמץ. |
| כיסוי אסימון מהימנות | הסרת המדיניות בנושא התכונה 'מימוש אסימון אמון' אמורה להגדיל באופן משמעותי את הכיסוי של אסימון המהימנות. | אנחנו לוקחים את זה בחשבון כשאנחנו אוספים משוב מ-OT ומקבלים החלטות לגבי השלבים הבאים. |
| מהימנות המנפיק | למה כדאי לנו לתת אמון באתרים שהנפיקו אסימוני מהימנות? | אין הנחיות לגבי הפיכה למנפיק – כל אחד יכול לעשות זאת. הציפייה שבעלי התוכן הדיגיטלי יעבדו רק עם מנפיקים שהם סומכים עליהם. בנוסף, גורמים לגיטימיים אחרים בסביבת הפרסום בסופו של דבר יפחיתו (או יפסיקו לקנות) תנועה שקשורה למנפיקים חשודים או ממקורות לא ידועים. |
| שירותים מוטמעים של צד שלישי | האם שירותים מוטמעים של צד שלישי יכולים לממש ו/או לבקש אסימוני מהימנות? | כן, שירות מוטמע של צד שלישי יכול להפיק ולממש אסימוני Trust. |
| המערכת האקולוגית של המנפיקים | אפשר להפיק תועלת רבה יותר אם אפשר לשתף אותות מהימנות עם חברות אחרות | אסימוני Trust Tokens נועדו להיות פשוטים ברמה נמוכה, וניתן להשתמש בהם על ידי מנפיקים/מגדלי שיתוף פעולה כדי לשתף אותות של אמון/מוניטין. |
| תקורה של תחזוקה | ההטמעה הקריפטוגרפית שעליה מתבססים פעולות של Trust Token מתבצעת ב-BoringSSL; ו-Google היא המחזיקה היחידה בתחזוקה שלה. איך תנוהל התחזוקה של הספרייה? | אסימוני Trust Tokens מבוססים על פעולות קריפטוגרפיות סטנדרטיות (ראו פרוטוקול Privacy Pass), שאפשר להטמיע גם בספריות אחרות. אנחנו ממליצים למפתחים לבקש, לפתח או לשמור על תמיכה בפעולות האלה בספריות שהם בוחרים. |
| תקורה של תחזוקה | לא ברור במשך כמה זמן תהיה תמיכה בגרסאות פרוטוקול | אנחנו בוחנים פיתוח ותיעוד של פרטים ספציפיים יותר לגבי מסגרות הזמן הצפויות לתמיכה בגרסאות פרוטוקול. |
| מגבלות המנפיק | אם המיקום שלך בשרשרת, יכול להיות שלא תיווצר הזדמנות שלך להוציא לפועל אסימוני Trust | ככל שיותר ארגונים מתחילים להשתמש באסימוני מהימנות, אנחנו יכולים לראות יותר ויותר דינמיקות תזמון כאלה במהלך המשחק, ואנחנו בודקים פתרונות אפשריים. כפי שתואר קודם, אנחנו מחפשים אפשרויות לטווח ארוך שבהן נוכל לאפשר לחברות לממש באופן בטוח אסימונים בלי להסתכן באנטרופיה נוספת של המשתמשים, מה שיפחית את החשיבות של מיקום בדף או בהזמנת טעינה. |
פתרונות חדשים למניעת הונאות
| נושא המשוב
(דירוג לפי השכיחות) |
סיכום שאלות וחששות | תגובה של Chrome |
| אותות של אימות תקינות של מכשיר | תמיכה רחבה באופן כללי בביצוע אותות תקינות של מכשירים, שאומתו על ידי פלטפורמות ויהיו זמינים לאינטרנט | אנחנו נמשיך לאסוף משוב ולהגשים את ההצעה באמצעות תכנון ציבורי ואיטרציה. |
| אותות של אימות תקינות של מכשיר | שאלות על מידת ההשפעה של האנטרופיה על המשתמשים באמצעות אותות חדשים, והאם תרחישי שימוש מסוימים (כמו התחברות של משתמש לחשבון הבנק) יכולים להצדיק אותות גבוהים יותר של אנטרופיה. | אנחנו משתדלים לספק אותות חשובים עם אנטרופיה קטנה ככל האפשר של המשתמשים, כדי לשמור על פרטיות המשתמשים. |
| אותות של אימות תקינות של מכשיר | האם האות הזה יגביל את הגישה למכשירים ישנים יותר או לפלטפורמות קוד פתוח/פלטפורמות שעברו שינוי? | לגבי אותות חדשים, יש להתייחס לגישה אוניברסלית כעקרון מפתח בפיתוח, ואלה שאלות חשובות שיש להתייחס אליהן מראש בזמן שנמשיך את תקופת הדגירה. |
| אותות של אימות תקינות של מכשיר | היה חשש שאותות חדשים גורמים לחברות אבטחה ומניעת הונאה להסתמך יותר מדי על הדפדפן והפלטפורמות
|
יש להתייחס לכל אות חדש כנתונים משלימים ולא כאינדיקציה ל "מהימנות" מהדפדפן. אנחנו מצפים לגמרי שחברות אבטחה ימשיכו להסתמך על הנתונים, המודלים ומנועי ההחלטות שבבעלותן, עם אימות (attestation) של מכשירים כקלט נוסף. אני מקווה שאות חדש ישפר את מאמצי הזיהוי בסביבה העסקית ויקשה יותר על ביצוע הונאות. |
| אות גיל של קובץ Cookie | רעיון מעניין, אך סביר להניח שדורש חקירה לעומק של תרחישים לדוגמה. | בהתאם לרמות העניין, Chrome עשוי לערוך רעיונות נוספים לגבי המושג הזה, ולהכין אותו בתור הסבר למשוב על הסביבה העסקית בעתיד. |
| שרתים מהימנים למניעת הונאות | רעיון מעניין, אך סביר להניח שדורש חקירה לעומק של תרחישים לדוגמה. | בהתאם לרמות העניין, Chrome עשוי לערוך רעיונות נוספים לגבי המושג הזה, ולהכין אותו בתור הסבר למשוב על הסביבה העסקית בעתיד. |