בעבר נעשה שימוש בקובצי Cookie של צד שלישי כדי לאחסן ולהעביר מידע על מצב המשתמש, כמו סטטוס הכניסה, מידע על המכשיר שבו הוא משתמש או אם הם מוכרים ואמינים. לדוגמה, האם המשתמש התחבר באמצעות SSO, האם יש למשתמש סוג מסוים של מכשיר תואם או אם המשתמש מוכר ומהימן. בעקבות ההוצאה משימוש של התמיכה בקובצי Cookie של צד שלישי, במקרים רבים יהיה צורך לתמוך באמצעים אחרים.
אסימוני מצב פרטי מאפשרים לשתף מידע באינטרנט, אבל תוך שמירה על הפרטיות באמצעות אמצעי בקרה על כמות הנתונים שאפשר לשתף בפועל.
אסימוני מצב פרטי (לשעבר Trust Tokens) מאפשרים להעביר את האמון באותנטיות של המשתמש מהקשר אחד להקשר אחר, ובמקביל עוזרים לאתרים להילחם בהונאות ולהבחין בין בוטים לבני אדם אמיתיים – בלי מעקב פסיבי.
במסמך הזה מפורטים הפרטים הטכניים להטמעת אסימוני מצב פרטי (PST). למתאר ברמה גבוהה יותר, ראו סקירה כללית של PST.
איך פועלים אסימוני מצב פרטי?
הקשר העיקרי שצריך להבין ב-PST הוא בין מנפיקים לבין מימושים. המנפיקים והמממשים יכולים להיות באותה חברה.
- מנפיקים – הישויות האלה כוללות אותות מסוימים לגבי משתמש (לדוגמה, אם המשתמש הוא בוט או לא) והן מטמיעות את האות הזה באסימון שמאוחסן במכשיר של המשתמש (פרטים נוספים מופיעים בקטעים הבאים).
- מימושים – יכול להיות שלישויות האלה אין אות לגבי המשתמש, אבל הם צריכים לדעת משהו לגביו (לדוגמה, אם המשתמש הוא בוט או לא) ולבקש לממש אסימון מהמנפיק כדי להבין את המהימנות של המשתמש.
לכל אינטראקציה ב-PST, מנפיקים ומממשים צריכים לעבוד יחד כדי לשתף אותות באינטרנט. האותות האלה הם ערכים משוערים שלא מפורטים מספיק כדי לזהות אנשים.
האם אסימוני מצב פרטי מתאימים לי?
חברות שמקבלות החלטות מהימנות ורוצות שהמידע יהיה זמין בכל הקשרים, עשויות להפיק תועלת מקובצי PST. למידע נוסף על תרחישים לדוגמה אפשריים של שאלות ותשובות, עיינו במסמכי התיעוד שלנו לגבי תרחישי שימוש ב-PST.
הנפקה ומימוש של אסימונים
ההטמעה של PST מתרחשת בשלושה שלבים:
- הנפקת אסימונים
- מימוש אסימונים
- העברה של רשומות מימוש
בשלב הראשון, אסימונים מונפקים לדפדפן (בדרך כלל אחרי סוג כלשהו של אימות). בשלב השני, ישות אחרת תגיש בקשה לממש את האסימון שהונפק כדי לקרוא את הערך של האסימון הזה. בשלב האחרון, הצד המממש מקבל רשומת מימוש (RR) עם הערך שנכלל באסימון. הצד המממש את התוכן יכול להשתמש ברשומה הזו כאימות של אותו משתמש למטרות שונות.
הגדרה של אסטרטגיית האסימונים
כדי להגדיר את אסטרטגיית האסימונים שלכם, צריך להבין מושגי מפתח של PST (אסימונים ורשומות מימוש), משתנים, התנהגויות ומגבלות, כדי שתוכלו לחשוב על השימוש הפוטנציאלי שלהם בתרחיש לדוגמה שלכם.
אסימונים ורשומות מימוש: מה הקשר ביניהם?
בכל מכשיר אפשר לאחסן עד 500 אסימונים לכל אתר ומנפיק ברמה העליונה. בנוסף, לכל אסימון יש מטא-נתונים שמבוססים על המפתח שהמנפיק השתמש בו כדי להנפיק אותו. באמצעות המידע הזה תוכלו להחליט אם לממש אסימון או לא להשתמש בו בתהליך המימוש. נתוני PST מאוחסנים באופן פנימי על ידי הדפדפן במכשיר של המשתמש, וניתן לגשת אליהם רק דרך PST API.
כשמממשים אסימון, רשומת המימוש (RR) נשמרת במכשיר. נפח האחסון הזה משמש כמטמון למימוש עתידי. יש מגבלה של מימוש שני אסימונים כל 48 שעות, לכל מכשיר, דף ומנפיק. בקריאות חדשות למימוש יש להשתמש בערכי RR שנשמרו במטמון כשזה אפשרי, במקום להפנות בקשה למנפיק.
- מנפיקים אסימונים חדשים (עד 500 לכל מנפיק, אתר ומכשיר).
- כל האסימונים מאוחסנים במכשיר של אסימונים (כמו מאגר קובצי cookie).
- אם לא נמצא RR פעיל, ניתן ליצור RR חדש אחרי ההנפקה (מקסימום 2 בכל 48 שעות).
- אובייקטים מסוג RR נחשבים פעילים עד לתאריך התפוגה שלהם, והם ישמשו כמטמון מקומי.
- קריאות חדשות למימוש מועברות למטמון המקומי (לא נוצרות RRs חדשים).
אחרי שמגדירים את התרחיש לדוגמה, עליכם להגדיר בקפידה את משך החיים של ה-RR, כי הוא יגדיר כמה פעמים תוכלו להשתמש בהם במקרה שלכם.
לפני שמגדירים את האסטרטגיה, חשוב להבין את ההתנהגויות והמשתנים הקריטיים הבאים:
| משתנה / התנהגות | תיאור | שימוש פוטנציאלי |
|---|---|---|
| מטא-נתונים של מפתח האסימון | אפשר להנפיק כל אסימון באמצעות מפתח קריפטוגרפי אחד בלבד, וב-PST יש מגבלה של שישה מפתחות לכל מנפיק. | אחת הדרכים הפוטנציאליות להשתמש במשתנה הזה היא הגדרת טווח של אמון לאסימונים על סמך המפתחות הקריפטוגרפיים (לדוגמה, מפתח 1 = מהימנות גבוהה ומפתח 6 = ללא אמון). |
| תאריך התפוגה של האסימון | תאריך התפוגה של האסימון זהה לתאריך התפוגה של המפתח. | ניתן לבצע רוטציית מפתחות לפחות כל 60 יום, וכל האסימונים שהונפקו עם מפתחות לא חוקיים נחשבים גם הם לא תקפים. |
| קצב המימוש של אסימון | יש מגבלה של שני מימושים של אסימונים לכל מכשיר ומנפיק בכל 48 שעות. | תלוי במספר המשוער של מימושים שנדרשים בתרחיש לדוגמה שלכם בכל 48 שעות. |
| מספר המנפיקים המקסימלי לכל מקור ברמה העליונה | נכון לעכשיו, מספר המנפיקים המקסימלי לכל מקור ברמה העליונה הוא שניים. | חשוב להגדיר בעיון את המנפיק של כל דף. |
| אסימונים לכל מנפיק במכשיר | נכון לעכשיו, מספר האסימונים המקסימלי לכל מנפיק במכשיר ספציפי הוא 500. | חשוב להקפיד שמספר האסימונים יהיה קטן מ-500 לכל מנפיק. חשוב לטפל בשגיאות בדף האינטרנט כשמנסים להנפיק אסימונים. |
| רוטציית התחייבויות עיקריות | כל מנפיק PST נדרש לחשוף נקודת קצה עם התחייבויות למפתחות שניתן לשנות כל 60 יום, וכל רוטציה מהירה יותר מזו שהמערכת מתעלמת ממנה. | אם תוקף המפתחות יפוג בעוד פחות מ-60 יום, חשוב לעדכן את ההתחייבויות העיקריות לפני התאריך הזה כדי למנוע שיבושים (לפרטים). |
| משך החיים של רשומת המימוש | ניתן להגדיר את משך החיים של RR על מנת לקבוע תאריך תפוגה. ה-RRs נשמרים במטמון כדי למנוע קריאות מימוש חדשות ומיותרות למנפיק, ולכן חשוב לוודא שיש להם מספיק אותות מימוש חדשים. | מכיוון שיש מגבלה על קצב המימוש של שני אסימונים בכל 48 שעות, חשוב להגדיר את משך החיים של ה-RR כדי שתהיה אפשרות לבצע קריאות מימוש בהצלחה לפחות בפרק הזמן הזה (צריך להגדיר בהתאם את משך החיים של ה-RR). מומלץ להגדיר את אורך החיים לפי סדר השבועות. |
תרחישים לדוגמה
תרחיש מס' 1: משך החיים של RR הוא פחות מ-24 שעות (t=t), והמימוש מתבצע כמה פעמים במהלך חלון 48 השעות.
תרחיש מס' 2: משך החיים של RR הוא 24 שעות והמימוש מתבצע מספר פעמים במהלך חלון של 48 שעות.
תרחיש מס' 3: משך החיים של RR הוא 48 שעות והמימוש מתבצע מספר פעמים במהלך חלון של 48 שעות.
הפעלת ההדגמה
לפני שמתחילים להשתמש ב-PST, מומלץ להגדיר קודם את ההדגמה. כדי לנסות את ההדגמה של PST , תצטרכו להריץ את Chrome עם דגלים כדי להפעיל את ההתחייבויות למפתח של מנפיק ההדגמה (פעלו לפי ההוראות בדף ההדגמה).
כשמפעילים את ההדגמה הזו, הדפדפן משתמש במנפיק ההדגמה ובשרתים של המימוש כדי לספק ולצרוך אסימונים.
שיקולים טכניים
ההדגמה (דמו) תפעל בצורה הטובה ביותר אם תבצעו את השלבים הבאים:
- חשוב להפסיק את כל המופעים של Chrome לפני שמפעילים את Chrome עם דגלים.
- אם אתם משתמשים במחשב עם Windows, כדאי לעיין במדריך הזה כדי ללמוד איך להעביר פרמטרים לקובץ הבינארי של קובץ ההפעלה של Chrome.
- כדי לראות את האסימונים שהנפיק מנפיק ההדגמה, פותחים את כלי הפיתוח ל-Chrome בקטע Applications > Storage > Private State Tokens.
הגדרת האפליקציה לאימוץ
איך להפוך למנפיק
למנפיקים יש תפקיד מרכזי ב-PST. הם מקצים ערכים לאסימונים כדי לקבוע אם המשתמש הוא בוט או לא. אם אתם רוצים להתחיל להשתמש ב-PST כמנפיק, תצטרכו להירשם על ידי השלמת תהליך הרישום של מנפיק.
על מנת להגיש בקשה להפוך למנפיק, המפעיל של האתר של המנפיק צריך לפתוח בעיה חדשה במאגר GitHub באמצעות התבנית New PSTr. פועלים לפי ההנחיות במאגר כדי למלא את הבעיה. אחרי שנקודת הקצה תאומת, היא תמוזג עם המאגר הזה והתשתית בצד השרת של Chrome תתחיל לאחזר את המפתחות האלה.
שרתים של מנפיק
המנפיקים והמימושים הם השחקנים המרכזיים ב-PST; שרתים ואסימונים הם הכלים העיקריים של PST. למרות שכבר סיפקנו כמה פרטים על אסימונים ובתיעוד של GitHub, רצינו להציע פרטים נוספים על שרתי PST. כדי להגדיר את המנפיק של PST, צריך קודם להגדיר שרת מנפיק.
פריסת הסביבה שלכם: שרתי מנפיקים
כדי להטמיע את השרת של מנפיק האסימון, תצטרכו ליצור אפליקציה משלכם בצד השרת שחושפת נקודות קצה של HTTP.
רכיב המנפיק מורכב משני מודולים ראשיים: (1) השרת של המנפיק ו-(2) מנפיק האסימון.
בדומה לכל האפליקציות שגלויות לאינטרנט, אנחנו ממליצים על שכבת הגנה נוספת לשרת של המנפיק.
שרת של מנפיק: בהטמעה לדוגמה שלנו, השרת המנפיק הוא שרת Node.js שמשתמש ב-Expresswork כדי לארח את נקודות הקצה של HTTP של המנפיק. קוד לדוגמה ב-GitHub
מנפיק האסימון: לרכיב הקריפטוגרפי של המנפיק אין צורך בשפה מסוימת, אבל עקב דרישות הביצועים של הרכיב הזה, אנחנו מספקים הטמעה של C כדוגמה, שמשתמשת בספריית Boring SSL כדי לנהל אסימונים. אפשר למצוא את הדוגמה של קוד המנפיק ומידע נוסף על ההתקנה ב-GitHub.
מפתחות: רכיב מנפיק האסימון משתמש במפתחות EC מותאמים אישית כדי להצפין אסימונים. יש להגן על המפתחות האלה ולאחסן אותם באחסון מאובטח.
דרישות טכניות לשרתי מנפיקים
בהתאם לפרוטוקול, צריך להטמיע לפחות שתי נקודות קצה של HTTP בשרת המנפיק:
- מחויבות למפתחות (למשל,
/.well-known/private-state-token/key-commitment): נקודת הקצה הזו היא המקום שבו הפרטים של מפתח ההצפנה הציבורי יהיו זמינים לדפדפנים כדי לוודא שהשרת שלכם חוקי. - הפקת האסימון (לדוגמה,
/.well-known/private-state-token/issuance): נקודת הקצה שהנפיקה את האסימון שבה יטופלו כל הבקשות לאסימונים. נקודת הקצה הזו תהיה נקודת השילוב של רכיב מנפיק האסימון.
כפי שצוין קודם, בגלל תעבורת הנתונים הגבוהה הצפויה שהשרת יטפל בה, מומלץ לפרוס אותו באמצעות תשתית ניתנת להרחבה (לדוגמה, בסביבת ענן) כדי שתוכלו להתאים את הקצה העורפי על סמך ביקוש משתנה.
שליחת שיחה לשרת של המנפיק
מטמיעים קריאה לאחזור אתר לערימת המנפיקים כדי להנפיק אסימונים חדשים.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
שרתים של מימוש
תצטרכו להטמיע את השירות למימוש האסימון על ידי יצירת אפליקציה משלכם בצד השרת. כך תוכלו לקרוא את האסימונים שהמנפיק שולח. בשלבים הבאים נסביר איך לממש אסימונים ואיך לקרוא את רשומות המימוש שמשויכות לאסימונים האלה.
אפשר לבחור להפעיל את המנפיק ואת המבצע באותו שרת (או קבוצת שרתים).
דרישות טכניות לשרתי מימוש
בהתאם לפרוטוקול, צריך להטמיע לפחות שתי נקודות קצה של HTTP בשרת המימוש:
/.well-known/private-state-token/redemption: נקודת הקצה שבה יטופל כל מימוש האסימונים. נקודת הקצה הזו תהיה המקום שבו ישולב רכיב מימוש האסימון
שליחת שיחה לשרת המימוש
כדי לממש אסימונים, צריך להטמיע בסטאק המימוש שלכם קריאה לאחזור אתרים כדי לממש אסימונים שהונפקו בעבר.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
ראו דוגמת קוד.
אחרי שמממשים אסימון, אפשר לשלוח את רשומת המימוש (RR) על ידי קריאה נוספת לאחזור:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
ראו דוגמת קוד.
פריסת ההטמעה
כדי לבדוק את ההטמעה, קודם נכנסים לדף האינטרנט שבו בוצעה הקריאה המנפיקה ומוודאים שהאסימונים נוצרים בהתאם ללוגיקה שלכם. מוודאים בקצה העורפי שהשיחות בוצעו בהתאם למפרט. לאחר מכן, נכנסים לדף האינטרנט שבו מתבצעת הקריאה ומוודאים שה-RRs נוצרים בהתאם ללוגיקה שלכם.
פריסה בעולם האמיתי
מומלץ לבחור אתרי יעד שהם חלק מתרחיש השימוש הספציפי שלכם:
- מספר קטן של ביקורים חודשיים (כ-1 מיליון ביקורים בחודש): תחילה עליכם לפרוס את ממשק ה-API לקהל קטן
- אתם הבעלים שלה ובשליטתכם: במקרה הצורך, תוכלו להשבית במהירות את ההטמעה ללא אישורים מורכבים
- לא יותר ממנפיק אחד: הגבלת כמות האסימונים כדי להקל על הבדיקה.
- לא יותר משני מימושים: אם יש בעיות, אתם צריכים לפשט את פתרון הבעיות.
פתרון בעיות
אפשר לבדוק קובצי PST בכרטיסיות 'רשת כלי הפיתוח' ו'אפליקציה' ב-Chrome.
בכרטיסייה 'רשת':
בכרטיסייה 'אפליקציות':
אפשר לקרוא מידע נוסף על השילוב הזה של כלי פיתוח.
שיטות מומלצות ופתרון בעיות לשרתים
כדי שהשרת של המנפיק והממשל יפעל ביעילות, מומלץ ליישם את השיטות המומלצות הבאות כדי לא להיתקל באתגרים שקשורים לגישה, לאבטחה, לרישום או לתעבורת נתונים ב-PST.
- נקודות הקצה צריכות להחיל הצפנה חזקה באמצעות TLS (אבטחת שכבת התעבורה) בגרסה 1.3 או 1.2.
- התשתית צריכה להיות מוכנה לטפל בנפחי תעבורת נתונים משתנים (כולל עליות חדות).
- ודאו שהמפתחות שלכם מוגנים ומאובטחים, ותואמים למדיניות של בקרת הגישה, לאסטרטגיית ניהול המפתחות ולתוכניות ההמשכיות העסקית.
- כדאי להוסיף מדדי ניראות (observability) לסטאק כדי לוודא שתהיה לכם חשיפה להבין את השימוש, צווארי הבקבוק ובעיות הביצועים אחרי המעבר לייצור.
מידע נוסף
- כדאי לעיין במסמכים למפתחים:
- בתור התחלה, כדאי לקרוא את הסקירה הכללית כדי להתעדכן ב-PST וביכולות שלו.
- כדאי לצפות בסרטון האינטרו של PST.
- כדאי לנסות את ההדגמה של PST.
- כדאי גם לקרוא את ההסבר של ה-API כדי לקבל פרטים נוספים לגביו.
- למידע נוסף על המפרט הנוכחי של ה-API.
- תוכלו לתרום לשיחה באמצעות בעיות ב-GitHub או שיחות W3C.
- כדי להבין טוב יותר את המונחים, מומלץ לעיין במילון המונחים של ארגז החול לפרטיות.
- למידע נוסף על המושגים של Chrome, כמו 'גרסת מקור לניסיון' או 'דגלים של Chrome', כדאי לעיין בסרטונים הקצרים ובמאמרים שזמינים בכתובת goo.gle/cc.