הוראות לבדיקה של דומיינים של צד ראשון

הגרסה האחרונה של הדומיינים של הצד הראשון מוכנה לבדיקת התכונה 'סימון תכונות' למפתחים ב-Chrome 108. אנחנו עובדים במרץ על דומיינים של צד ראשון במטרה לעבור לשלב המשלוח, ולכן נשקול את המשוב על השלב הזה של בדיקת המפתחים עד להשקת Chrome 111 בתחילת מרץ (7 במרץ 2023).

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

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

סקירה כללית של דומיינים של צד ראשון

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

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

כדי לאפשר לדפדפן לטפל בכל קבוצת משנה בהתאם להשלכות על הפרטיות של כל קבוצת משנה, אנחנו מציעים להשתמש ב-Storage Access API (SAA) וב-requestStorageAccessForOrigin כדי לאפשר גישה לקובצי cookie בתוך FPS.

בעזרת ה-SAA, אתרים יכולים לבקש באופן פעיל גישה לקובצי cookie באתרים שונים. Chrome יאשר את הבקשה באופן אוטומטי אם האתר שממנו נשלחה הבקשה והאתר ברמה העליונה נמצאים באותו FPS. בתיעוד של Storage Access API (SAA) מפורט מידע על האופן שבו דפדפנים אחרים מעבדים קריאות ל-SAA.

לפי דרישת ה-SAA, המסמך דורש הפעלה של המשתמש לפני הפעלת השיטות של ה-API.

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

הגדרת השליחה

רשימת ה-FPS הקנונית תהיה רשימה גלויה לכולם בפורמט קובץ JSON שנמצאת במאגר FPS חדש ב-GitHub, ותשמש כמקור האמת לכל הקבוצות. Chrome ישתמש בקובץ הזה כדי להחיל את ההתנהגות שלו.

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

מכיוון שתהליך שליחת הקבוצות עדיין נמצא בפיתוח פעיל, עבור בדיקה מקומית ניתן רק ליצור קבוצות בשורת הפקודה ולהעביר אותן ישירות לדפדפן. בבדיקות מקומיות, אין צורך לשלוח קבוצה למאגר GitHub כדי לבצע בדיקה באמצעות feature flags.

איך לבצע בדיקה באופן מקומי

דרישות מוקדמות

כדי לבדוק FPS באופן מקומי, צריך להשתמש ב-Chrome מגרסה 108 ואילך שמופעל דרך שורת הפקודה.

כדי לקבל תצוגה מקדימה של תכונות Chrome שיושקו בקרוב לפני השקתן, יש להוריד את גרסת בטא או Canary של Chrome.

דוגמה

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

מידע נוסף על הפעלת Chromium עם דגלים

רשימת השלבים

כדי להפעיל FPS באופן מקומי, עליך להשתמש באפשרות --enable-features של Chrome עם רשימת דגלים המופרדים בפסיקים, המוסברים בקטע הזה. בנוסף, עליך להצהיר על קבוצת אתרים קשורים כאובייקט JSON שיועבר אל --use-first-party-set.

הפעלת FPS

FirstPartySets מפעיל FPS ב-Chrome.

FirstPartySets

הפעלת Storage Access API

StorageAccessAPI

ההגדרה מפעילה את Storage Access API (SAA) ב-Chrome שמאפשר למסגרות iframe מוטמעות להשתמש ב-requestStorageAccess() כדי לבקש גישה לקובצי cookie בהקשר של אתרים שונים, גם כשקובצי cookie של צד שלישי חסומים על ידי הדפדפן.

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

StorageAccessAPIForOriginExtension

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

הצהרה על קבוצה באופן מקומי

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

יוצרים אובייקט JSON שמכיל כתובות URL שחברות בקבוצה ומעבירים אותו אל --use-first-party-set.

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

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

דוגמה:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

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

הפעלת ממשק המשתמש של FPS

PageInfoCookiesSubpage

מאפשר הצגת FPS בקטע PageInfo שאפשר לגשת אליו מסרגל כתובת ה-URL.

PrivacySandboxFirstPartySetsUI

מפעילה את האפשרות 'אישור לאתרים קשורים לראות את הפעילות שלך בקבוצה' בממשק המשתמש של FPS בהגדרות Chrome, בקטע 'פרטיות ואבטחה' ← קובצי cookie ונתונים נוספים מאתרים (chrome://settings/cookies).

לוודא שקובצי cookie של צד שלישי חסומים

  1. בהגדרות Chrome, עוברים אל 'פרטיות ואבטחה' ← 'קובצי cookie ונתונים נוספים' מאתרים או chrome://settings/cookies.
  2. בקטע 'הגדרות כלליות', מוודאים שהאפשרות 'חסימת קובצי cookie של צד שלישי' מופעלת.
  3. מוודאים שגם אפשרות המשנה 'אישור לאתרים קשורים לראות את הפעילות שלך בקבוצה' מופעלת.

שיקולי אבטחה

Storage Access API מאפשר לאתרים לקבל שוב גישה לקובצי cookie של צד שלישי במקרים נבחרים, ולכן אפליקציות אינטרנט חשופות למתקפות בין אתרים ולדליפות מידע. אתרים שמסתמכים על קובצי cookie בהקשרים שבין כמה אתרים צריכים להיות מודעים לסיכונים של CSRF ולהתקפות אחרות.

שיפורים מתוכננים

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

כאן מפורטת רשימת השיפורים המתוכננים בהטמעה של ה-SAA ב-Chrome.

חשוב לזכור ש-Chrome שולח קובצי cookie שמסומנים כ-SameSite=None בהקשרים מוטמעים בין אתרים, שבהם ה-Storage Access API רלוונטי. עם זאת, עד שכל הדפדפנים ייצאו משימוש את גישת ברירת המחדל לקובצי cookie אלה, לא ניתן יהיה להניח לגבי המיקום שבו ניתן להשתמש בקובצי ה-cookie. לא בטוח להניח שהגישה מותרת רק במסגרת FPS, ואתרים צריכים להמשיך לפעול לפי שיטות האבטחה המומלצות הרגילות.

יצירת מעורבות ושיתוף משוב

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