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

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

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

בהצעה המעודכנת נעשה שימוש בשני ממשקי 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, כרגע המסמך נדרש להפעיל הפעלה של המשתמש לפני קריאה ל-methods של ה-API.

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

הגדרת השליחה

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

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

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

איך מבצעים בדיקה מקומית

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

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

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

PageInfoCookiesSubpage

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

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

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