דף זה תורגם על ידי Cloud Translation API.

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

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

Sam Dutton

סיכום

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

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

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

צילום מסך שבו מוצג אסימוני Trust בכרטיסייה 'רשת כלי הפיתוח' ל-Chrome. — Trust Tokens בכרטיסייה **Network** (רשת) של כלי הפיתוח ל-Chrome.

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

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

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

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

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

מה יש בהצעה של האסימונים להרשאות שיתוף?

האינטרנט מסתמכים על אותות של אמון כדי לזהות הונאות והפצת ספאם. דרך אחת לעשות זאת היא לעקוב אחרי הגלישה באמצעות מזהים גלובליים מאתרים שונים לכל משתמש. הפעולות האלה לא מקובלות ב-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(...)

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

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

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

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

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

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

איך אתרים יכולים לקבוע אם לסמוך עליכם?

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

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

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

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

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

יוצרים קבוצה של מספרים פסאודו-אקראיים שנקראים צפנים.
מסוננים את ההצפנה של הצפנים חד-פעמיים (מקודדים אותם כדי שהמנפיק לא יוכל לראות את התוכן שלהם) ומצרפים אותם לבקשה בכותרת Sec-Trust-Token.
שולחים בקשת 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 כדי לאפשר מימוש אסימונים במקביל לטעינת הדף.

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

פרטים נוספים

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

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