מדריך למפתחים בנושא אסימוני מצב פרטי

בעבר, קובצי cookie של צד שלישי שימשו לאחסון ולמסירה של מידע על המצב של המשתמש, כמו סטטוס ההתחברות שלו, מידע על המכשיר שבו הוא משתמש או אם הוא ידוע ואמין. לדוגמה, אם המשתמש התחבר באמצעות SSO, אם יש למשתמש מכשיר תואם מסוג מסוים או אם המשתמש ידוע ואמין. מאחר שהתמיכה בקובצי Cookie של צד שלישי הוצאה משימוש, רבים מתרחישי לדוגמה האלה יצטרכו לקבל תמיכה באמצעים אחרים.

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

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

במסמך הזה מפורטים הפרטים הטכניים להטמעת אסימוני מצב פרטי (PST). סקירה כללית על PST

איך פועלים טוקנים של מצב פרטי?

הקשר המרכזי שחשוב להבין ב-PST הוא בין המנפיקים לבין המממשים. המנפיקים והממירים יכולים להיות באותה חברה.

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

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

האם טוקנים של מצב פרטי מתאימים לי?

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

הנפקה ומימוש של אסימונים

תהליך ההטמעה של PST מתבצע בשלושה שלבים:

1. הנפקת אסימונים
2. מימוש אסימונים
3. העברת רשומות של מימוש שוברים

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

הגדרת אסטרטגיית האסימונים

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

אסימונים ורשומות מימוש: מה הקשר ביניהם?

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

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

1. נוצרים אסימונים חדשים (עד 500 לכל מנפיק, אתר ומכשיר).
2. כל הטוקנים מאוחסנים במאגר הטוקנים במכשיר (בדומה למאגר קובצי cookie).
3. אם לא נמצא RR פעיל, אפשר ליצור RR חדשים אחרי ההנפקה (עד 2 בכל 48 שעות).
4. רשומות RR נחשבות לפעילות עד לתאריך התפוגה שלהן, והן ישמשו כמטמון מקומי.
5. קריאות חדשות למימוש ייכנסו למטמון המקומי (לא נוצרים RR חדשים).

אחרי שמגדירים את תרחיש לדוגמה, צריך להגדיר בקפידה את משך החיים של ה-RR, כי הוא יקבע כמה פעמים תוכלו להשתמש בו בתרחיש.

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

תרחישים לדוגמה

תרחיש מס' 1: משך החיים של ה-RR הוא פחות מ-24 שעות (t=t) והמימוש מתבצע מספר פעמים במהלך חלון הזמנים של 48 השעות.

תרחיש 2: משך החיים של קוד ההמרה הוא 24 שעות והוא מנוצל כמה פעמים במהלך חלון הזמנים של 48 השעות.

תרחיש 3: משך החיים של שובר ההמרה הוא 48 שעות וההמרה מתבצעת כמה פעמים במהלך חלון הזמנים של 48 השעות.

הרצת ההדגמה

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

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

שיקולים טכניים

כדי שהדגמה תפעל בצורה הטובה ביותר, מומלץ לבצע את השלבים הבאים:

• חשוב לוודא שכל המופעים של Chrome מופסקים לפני שמפעילים את Chrome עם דגלים.
• אם אתם משתמשים במחשב עם Windows, כדאי לעיין במדריך הזה בנושא העברת פרמטרים לקובץ ההפעלה הבינארי של Chrome.
• פותחים את כלי הפיתוח ל-Chrome בקטע Applications (אפליקציות) > Storage (אחסון) > Private State (אסימונים של מצב פרטי) בזמן השימוש באפליקציית הדגמה כדי לראות את האסימונים שהונפקו או שומשו על ידי מנפיק הדגמה.

הגדרה לצורך אימוץ

איך הופכים למנפיקים

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

כדי להגיש בקשה להצטרפות כמנפיק, המפעיל של אתר המנפיק צריך לפתוח בעיה חדשה במאגר GitHub באמצעות התבנית 'New PST Issuer'. פועלים לפי ההוראות במאגר כדי למלא את הבעיה. אחרי שנקבע שהנקודה הקצה מאומתת, היא תצורף למאגר הזה ותשתית Chrome בצד השרת תתחיל לאחזר את המפתחות האלה.

שרתי מנפיקים

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

פריסה של הסביבה: שרתי מנפיקים

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

רכיב המנפיק מורכב משני מודולים עיקריים: (1) שרת המנפיק ו-(2) מנפיק האסימונים.

כמו בכל האפליקציות שמוצגות באינטרנט, מומלץ להוסיף שכבת הגנה לשרת המנפיק.

1. שרת המנפיק: בהטמעה לדוגמה שלנו, שרת המנפיק הוא שרת Node.js שמשתמש במסגרת Express כדי לארח את נקודות הקצה מסוג HTTP של המנפיק. אפשר לבדוק את קוד לדוגמה ב-GitHub.

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

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

הדרישות הטכניות לשרתים של מנפיקים

בהתאם לפרוטוקול, תצטרכו להטמיע לפחות שתי נקודות קצה (endpoint) של 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"
      }
    });

דוגמה לקוד

שרתי Redeemer

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

אפשר להפעיל את המנפיק ואת הממיר באותו שרת (או בקבוצה של שרתי).

הדרישות הטכניות לשרתים של הממירים

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

• /.well-known/private-state-token/redemption: נקודת קצה שבה יתבצע הטיפול בכל תהליך המימוש של האסימונים. נקודת הקצה הזו היא המקום שבו ישולב הרכיב של מימוש האסימון.
  • קוד לדוגמה

שליחת קריאה לשרת הממיר

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

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

מדיניות ההרשאות

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

הפעולה של בקשת האסימון נשלטת על ידי ההנחיה private-state-token-issuance. הפעולות token-redemption ו-send-redemption-record נשלטות על ידי ההנחיה private-state-token-redemption. ב-Chrome מגרסה 132 ואילך, רשימת ההיתרים להוראות האלה מוגדרת כברירת מחדל כ-* (כל המקורות). כלומר, התכונה זמינה לדף ברמה העליונה, למסגרות iframe מאותו מקור ולמסגרות iframe ממקורות שונים ללא הענקת גישה מפורשת.

כדי לבטל את ההנפקה או את המימוש של אסימוני PST בדפים ספציפיים באתר, צריך לכלול את הערכים private-state-token-issuance=() ו-private-state-token-redemption=() בכותרת Permissions-Policy של כל דף.

אפשר גם להשתמש בכותרת Permissions-Policy כדי לשלוט בגישה של צד שלישי ל-PST. כפרמטרים לרשימת מקורות הכותרות, משתמשים ב-self ובכל המקורות שרוצים לתת להם גישה ל-API. לדוגמה, כדי להשבית לחלוטין את השימוש ב-PST בכל הקשרי הגלישה, מלבד המקור שלכם ו-https://example.com, מגדירים את כותרות התגובה הבאות של HTTP:

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

כדי להפעיל את ה-API לכל המשאבים ממקורות שונים, מגדירים את רשימת המקור כ-*.

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

פתרון בעיות

אפשר לבדוק קובצי PST בכרטיסיות 'רשת' ו'אפליקציה' בכלי הפיתוח ל-Chrome.

בכרטיסייה 'רשת':

בכרטיסייה 'בקשה':

מידע נוסף על השילוב הזה עם DevTools

שיטות מומלצות ללקוחות

אם הפונקציות הקריטיות של האתר תלויות במנפיקים מסוימים של אסימונים, כדאי לתת להם עדיפות. צריך להפעיל את hasPrivateToken(issuer) למנפיקים המועדפים האלה לפני טעינת סקריפטים אחרים. זה חיוני כדי למנוע כשלים פוטנציאליים במימוש.

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

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

שיטות מומלצות לשימוש בשרתים ופתרון בעיות

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

• נקודות הקצה צריכות להשתמש בהצפנה חזקה באמצעות TLS 1.3 או 1.2.
• התשתית צריכה להיות מוכנה לטפל בנפח תנועה משתנה (כולל עליות חדות).
• חשוב לוודא שהמפתחות מוגנים ומאובטחים, בהתאם למדיניות בקרת הגישה, לאסטרטגיית ניהול המפתחות ולתוכניות ההמשכיות העסקית.
• מוסיפים מדדי יכולת תצפית (observability) לסטאק כדי לוודא שתהיה לכם שקיפות כדי להבין את השימוש, צווארי בקבוק ובעיות בביצועים אחרי ההעברה לייצור.

מידע נוסף

1. לעיין במסמכי הפיתוח:
   1. מומלץ להתחיל בקריאת הסקירה הכללית כדי להבין את היכולות של PST.
   2. מומלץ לצפות בסרטון ההסבר על PST.
   3. כדאי לנסות את ההדגמה של PST.
   4. מומלץ גם לקרוא את הסבר על ה-API כדי לקבל פרטים נוספים.
   5. מידע נוסף על המפרט הנוכחי של ה-API
2. אתם יכולים להשתתף בשיחה באמצעות דיווח על בעיות ב-GitHub או קריאות ל-W3C.
3. כדי להבין טוב יותר את המונחים, מומלץ לעיין במילון המונחים של ארגז החול לפרטיות.
4. כדי לקבל מידע נוסף על מושגים ב-Chrome, כמו 'גרסת מקור לניסיון' או 'דגלים של Chrome', אפשר לעיין בסרטונים ובמאמרים הקצרים שזמינים בכתובת goo.gle/cc.