תחילת השימוש באסימוני מהימנות

Trust Tokens הוא ממשק API חדש שמאפשר לאתר להעביר כמות מוגבלת של מידע מהקשר גלישה אחד לאחר (לדוגמה, באתרים שונים) כדי לסייע במאבק בהונאות, ללא מעקב פסיבי.

Sam Dutton



סיכום

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

ה-Trust Token API מאפשר להעביר את האמון במשתמש בהקשר אחד להקשר אחר בלי לזהות אותו או לקשר בין שתי הזהויות.

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

צילום מסך שבו מוצגים אסימוני Trust בכרטיסייה 'רשת כלי הפיתוח' ב-Chrome.
Trust Tokens בכרטיסייה Network של כלי הפיתוח ל-Chrome.
צילום מסך שבו מוצגים אסימוני Trust בכרטיסייה 'אפליקציה של כלי פיתוח' ל-Chrome.
Trust Tokens בכרטיסייה Application ב-Chrome DevTools.

למה אנחנו צריכים אסימוני Trust?

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

לצערנו, הרבה מנגנונים קיימים למדידה ולהפצת האמינות – כדי לבדוק אם אינטראקציה עם אתר היא בן אדם אמיתי, למשל – מנצלים שיטות שאפשר להשתמש בהן גם ליצירה של טביעת אצבע דיגיטלית (fingerprinting).

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

מה כלול בהצעה לאסימוני Trust?

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

בהסבר של ההצעה:

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

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

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

דוגמה לשימוש ב-API

הקטע הבא מבוסס על קוד לדוגמה בהסבר על ה-API.

נניח שמשתמש מבקר באתר חדשות (publisher.example) שמטמיע פרסום מרשת מודעות של צד שלישי (foo.example). המשתמש השתמש בעבר באתר של רשת חברתית שמנפיקה אסימוני מהימנות (issuer.example).

לפי הסדר הבא אנחנו מסבירים איך אסימוני מהימנות פועלים.

1.המשתמש מבקר בכתובת issuer.example ומבצע פעולות שגורמות לאתר להאמין שהוא אדם אמיתי, למשל פעילות בחשבון או העברה של אתגר CAPTCHA.

2.issuer.example מאמתת שהמשתמש הוא אדם ומריצים את ה-JavaScript הבא כדי ליצור אסימון מהימנות לדפדפן של המשתמש:

fetch('https://issuer.example/trust-token', {
  trustToken: {
    type: 'token-request',
    issuer: 'https://issuer.example'
  }
}).then(...)

3.הדפדפן של המשתמש שומר את אסימון האמון, ומשייך אותו ל-issuer.example.

4.זמן מה לאחר מכן, המשתמש מבקר באתר publisher.example.

5.publisher.example רוצה לדעת אם המשתמש הוא בן אדם אמיתי. publisher.example סומכת על issuer.example, ולכן היא בודקת אם לדפדפן של המשתמש יש אסימונים תקפים מהמקור הזה:

document.hasTrustToken('https://issuer.example');

6.אם הפעולה מחזירה התחייבות שמובילה ל-true, סימן שלמשתמש יש אסימונים מ-issuer.example, כך ש-publisher.example יכול לנסות לממש אסימון:

fetch('https://issuer.example/trust-token', {
trustToken: {
  type: 'token-redemption',
  issuer: 'https://issuer.example',
  refreshPolicy: {none, refresh}
}
}).then(...)

באמצעות הקוד הזה:

  1. המממש publisher.example מבקש לממש את המבצע.

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

    7.אחרי סיום ההבטחה שהוחזרה על ידי fetch(), תוכלו להשתמש ברשומת המימוש בבקשות הבאות למשאבים:

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

באמצעות הקוד הזה:

  1. רשומות מימוש נכללות ככותרת בקשה Sec-Redemption-Record.
  2. foo.example מקבל את רשומת המימוש ויכול לנתח את הרשומה כדי לקבוע אם issuer.example חשב שהמשתמש הזה הוא בן אדם.
  3. foo.example מגיבה בהתאם.
איך אתר יכול לקבוע אם אפשר לסמוך עליכם?

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

הנפקת אסימון מהימנות

אם מנפיק של אסימון מהימנות כמו issuer.example קבע שהמשתמש מהימן, המנפיק יכול לאחזר אסימוני מהימנות עבור המשתמש על ידי שליחת בקשת fetch() עם הפרמטר trustToken:

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

כך מופעלת הארכה של פרוטוקול הפקת הכרטיס הפרטי באמצעות פרימיטיב קריפטוגרפי חדש:

  1. יוצרים קבוצה של מספרים פסאודו אקראיים שנקראים nonces.

  2. מעוורים את החלקים החד-פעמיים (מקודדים אותם כך שהמנפיק לא יוכל להציג את התוכן שלהם) ומצרפים אותם לבקשה בכותרת Sec-Trust-Token.

  3. שולחים בקשת POST לנקודת הקצה שצוינה.

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

מימוש אסימון אמון

אתר של בעל תוכן דיגיטלי (למשל publisher.example בדוגמה שלמעלה) יכול לבדוק אם יש אסימוני מהימנות זמינים למשתמש:

const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');

אם יש אסימונים זמינים, האתר של בעל התוכן הדיגיטלי יכול לממש אותם כדי לקבל רשומת מימוש:

fetch('issuer.example/trust-token', {
  ...
  trustToken: {
    type: 'token-redemption',
    refreshPolicy: 'none'
  }
  ...
}).then(...)

המוציא לאור יכול לכלול רשומות מימוש בבקשות שנדרש בהן אסימון מהימנות (כמו פרסום תגובה, לייק לדף או הצבעה בסקר) באמצעות קריאה ל-fetch() כמו בדוגמה הבאה:

fetch('https://foo.example/post-comment', {
  ...
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['issuer.example/trust-token', ...]
  }
  ...
}).then(...);

רשומות מימוש נכללות ככותרת בקשה מסוג Sec-Redemption-Record.

שיקולי פרטיות

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

שיקולי אבטחה

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

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

מנגנוני בקשות

ייתכן שתוכלו לאפשר שליחה של רשומות מימוש מחוץ ל-fetch(), למשל באמצעות בקשות לניווט. יכול להיות שאתרים יוכלו גם לכלול נתוני מנפיק בכותרות של תגובת HTTP, כדי לאפשר מימוש אסימון במקביל לטעינת הדף.

אני רוצה להדגיש שוב: להצעה הזו נדרשת משוב! אם יש לכם הערות, תוכלו ליצור בעיה במאגר להסברים של אסימון Trust.

למידע נוסף

תודה לכל מי שעזר לכתוב את הפוסט הזה ולסקור אותו.

תמונה מאת ZSun Fu ב-UnFlood.