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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

משתנה / התנהגות	תיאור	שימוש פוטנציאלי
מטא-נתונים של מפתח האסימון	ניתן להנפיק כל אסימון באמצעות מפתח קריפטוגרפי אחד בלבד, ב-PST יש מגבלה של שישה מפתחות לכל מנפיק.	אחת הדרכים הפוטנציאליות להשתמש במשתנה הזה היא הגדרת טווח של אמון על סמך המפתחות הקריפטוגרפיים שלכם (לדוגמה, key 1 =). אמון רב בזמן שמקש 6 = חוסר אמון).
תאריך התפוגה של האסימון	תאריך התפוגה של האסימון זהה לתאריך התפוגה של המפתח.	ניתן לבצע רוטציית מפתחות כל 60 יום לפחות, ואת כל האסימונים שהונפקו באמצעות מפתחות לא חוקיים נחשבים גם הם לא חוקיים.
מגבלת שיעור מימוש של אסימונים	יש מגבלה של שני מימושי אסימונים לכל מכשיר ומנפיק בכל 48 שעות.	תלוי במספר המשוער של מימושים שנדרשים על ידי השימוש שלך כל 48 שעות.
המספר המקסימלי של מנפיקים לכל מקור ברמה העליונה	המספר המקסימלי של מנפיקים לכל מקור ברמה העליונה הוא כרגע שניים.	יש להגדיר בקפידה את המנפיקים של כל דף.
אסימונים לכל מנפיק במכשיר	המספר המקסימלי של אסימונים לכל מנפיק במכשיר ספציפי הוא כרגע השגיאה:	חשוב להקפיד שמספר האסימונים יהיה קטן מ-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 > (אפליקציות >) אחסון > מצב פרטי אסימונים בזמן השימוש באפליקציית ההדגמה כדי לראות את האסימונים שהונפקו או מומשו ממנפיק ההדגמה.

הגדרת אימוץ

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

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

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

השרתים של המנפיקים

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

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

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

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

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

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

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

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

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

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

• התחייבות למפתחות (לדוגמה, /.well-known/private-state-token/key-commitment): נקודת הקצה (endpoint) הזו היא המקום שבו הפרטים של המפתח הציבורי להצפנה יהיו זמינים לאימות הדפדפנים. שהשרת שלכם חוקי.
  • קוד לדוגמה
• הפקת אסימונים (לדוגמה, /.well-known/private-state-token/issuance): נקודת הקצה (endpoint) של האסימון, שבה יטופלו כל הבקשות לאסימונים. הזה נקודת הקצה תהיה נקודת השילוב של הרכיב של מנפיק האסימון.
  • קוד לדוגמה

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

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

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

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

שליחת שיחה לשרת של מבצע המימוש

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

    // 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>]
      }
    });

ראו דוגמת קוד.

פריסת ההטמעה

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

פריסה בעולם האמיתי

מומלץ לבחור אתרי יעד שהם חלק מהשימוש הספציפי שלך מקרה:

• מספר קטן של ביקורים חודשיים (כ-<1 מיליון ביקורים בחודש): צריך להתחיל בפריסת ה-API לקהל קטן
• אתה הבעלים שלו ושולט בו: במקרה הצורך אפשר להשבית במהירות את ללא אישורים מורכבים
• לא יותר ממנפיק אחד: כדי להגביל את כמות האסימונים כדי מפשטים את הבדיקה.
• לא יותר משני מנויים: צריך לפשט את פתרון הבעיות במקרה של בעיות.

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

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

הפעולה לבקשת אסימון נשלטת על ידי ההוראה private-state-token-issuance. הפעולות token-redemption ו-send-redemption-record נשלטות באמצעות ההוראה private-state-token-redemption. כברירת מחדל, רשימת ההיתרים של ההוראות האלה מוגדרת עצמית. המשמעות היא שהתכונה זמינה רק לדף ברמה העליונה (ולרכיבי 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.

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

בכרטיסייה 'יישום':

מידע נוסף בנושא שילוב של כלי פיתוח.

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

אם הפונקציות הקריטיות באתר תלויות במנפיקי אסימונים מסוימים, צריך לתת להם עדיפות. צריך לקרוא לפונקציה 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