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

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

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

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

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

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

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

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

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

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

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

אלה כמה מהתרחישים לדוגמה לשימוש בקבוצות של אתרים קשורים:

  • התאמה אישית לפי מדינה. ניצול אתרים מותאמים לשוק המקומי תוך שימוש בתשתית משותפת (example.co.il יכול להסתמך על שירות שמתארח ב-example.ca).
  • שילוב של דומיין שירות. שימוש בדומיינים של שירותים שהמשתמשים אף פעם לא יוצרים איתם אינטראקציה ישירה, אבל מספקים שירותים באתרים של אותו ארגון (example-cdn.com).
  • הפרדה בין תוכן של משתמשים. גישה לנתונים בדומיינים שונים שמפרידים בין תוכן שהמשתמשים העלו לתוכן אחר באתר מסיבות אבטחה, תוך מתן גישה לדומיין ב-sandbox לקובצי cookie של אימות (וקובצי cookie אחרים). אם אתם מציגים תוכן לא פעיל שהמשתמשים העלו, יכול להיות שתוכלו לארח אותו באותו דומיין בצורה בטוחה אם תפעלו לפי השיטות המומלצות.
  • תוכן מוטמע מאומת. תוכן מוטמע תומך מנכסים שונים שמשויכים לאתר (סרטונים, מסמכים או משאבים שמוגבלים למשתמש שמחובר באתר ברמה העליונה).
  • כניסה. תמיכה בכניסה לחשבון בנכסים שמשויכים לחשבון. FedCM API יכול להתאים גם לתרחישי שימוש מסוימים.
  • Analytics. פריסה של ניתוח נתונים ומדידה של תהליכי השימוש של המשתמשים בנכסים מקושרים, כדי לשפר את איכות השירותים.

Storage Access API

Browser Support

  • Chrome: 119.
  • Edge: 85.
  • Firefox: 65.
  • Safari: 11.1.

Source

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

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

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

בדיקה ובקשה של גישה לאחסון

כדי לבדוק אם יש להם גישה לאחסון כרגע, אתרים מוטמעים יכולים להשתמש בשיטה Document.hasStorageAccess().

השיטה מחזירה הבטחה (promise) שמתקבל ממנה ערך בוליאני שמציין אם למסמך כבר יש גישה לקובצי ה-cookie שלו או לא. ההבטחה מחזירה את הערך true גם אם ה-iframe הוא מאותו מקור כמו הפריים העליון.

כדי לבקש גישה לקובצי cookie בהקשר של אתרים שונים, אתרים מוטמעים יכולים להשתמש ב-Document.requestStorageAccess() (rSA).

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

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

requestStorageAccessFor ב-Chrome

Browser Support

  • Chrome: 119.
  • Edge: 119.
  • Firefox: not supported.
  • Safari: not supported.

Source

‏Storage Access API מאפשר לאתרים מוטמעים לבקש גישה לאחסון רק מתוך רכיבי <iframe> שקיבלו אינטראקציה של משתמש.

הבעיה הזו יוצרת אתגרים בהטמעת Storage Access API באתרים ברמה העליונה שמשתמשים בתמונות חוצות-אתרים או בתגי סקריפט שדורשים קובצי Cookie.

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

 document.requestStorageAccessFor('https://target.site')

הקריאה ל-API של requestStorageAccessFor() אמורה להתבצע על ידי מסמך ברמה העליונה. בנוסף, המסמך הזה חייב לקבל אינטראקציה של משתמש. אבל בניגוד ל-requestStorageAccess(), Chrome לא בודק אם הייתה אינטראקציה במסמך ברמה העליונה ב-30 הימים האחרונים, כי המשתמש כבר נמצא בדף.

בדיקת הרשאות הגישה לאחסון

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

אפשר לשלוח שאילתה לגבי סטטוס ההרשאה באמצעות navigator.permissions.query().

כדי לבדוק את הרשאת הגישה לאחסון בהקשר הנוכחי, צריך להעביר את המחרוזת 'storage-access':

navigator.permissions.query({name: 'storage-access'})

כדי לבדוק את הרשאת הגישה לאחסון למקור מסוים, צריך להעביר את המחרוזת 'top-level-storage-access':

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

חשוב לזכור: כדי להגן על תקינות המקור המוטמע, הבדיקה הזו בודקת רק הרשאות שהוקצו על ידי המסמך ברמה העליונה באמצעות document.requestStorageAccessFor.

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

מודל לפי מסגרת

הקצאות rSA חלות לכל פריים. הקצאות rSA ו-rSAFor נחשבות להרשאות נפרדות.

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

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

קובצי cookie חייבים לציין גם את המאפיינים SameSite=None וגם את המאפיינים Secure, כי rSA מספק גישה רק לקובצי cookie שכבר מסומנים לשימוש בהקשרים שבין כמה אתרים.

קובצי cookie עם המאפיין SameSite=Lax,‏ SameSite=Strict או ללא המאפיין SameSite מיועדים לשימוש של צד ראשון בלבד, והם אף פעם לא ישותפו בהקשר של כמה אתרים, ללא קשר ל-rSA.

אבטחה

ב-rSAFor, בקשות למשאבי משנה מחייבות כותרות של שיתוף משאבים בין מקורות (CORS) או את המאפיין crossorigin במשאבים, כדי להבטיח הסכמה מפורשת.

דוגמאות להטמעה

שליחת בקשה לגישה לאחסון מ-iframe מוטמע חוצה-מקורות

תרשים שבו מוצג אתר מוטמע באתר ברמה העליונה.site
שימוש ב-requestStorageAccess() בהטמעה באתר אחר

איך בודקים אם יש לכם גישה לאחסון

כדי לבדוק אם כבר יש לכם גישה לאחסון, השתמשו ב-document.hasStorageAccess().

אם ההחלטה של ההבטחה היא true, תוכלו לגשת לאחסון בהקשר של האתרים השונים. אם הערך הוא false, צריך לבקש גישה לאחסון.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

שליחת בקשה לגישה לאחסון

אם אתם צריכים לבקש גישה לאחסון, קודם עליכם לבדוק את הרשאת הגישה לאחסון navigator.permissions.query({name: 'storage-access'}) כדי לראות אם נדרשת תנועת משתמש או שהיא יכולה להינתן באופן אוטומטי.

אם ההרשאה היא granted, אפשר להפעיל את document.requestStorageAccess() והיא אמורה להצליח בלי תנועת משתמש.

אם סטטוס ההרשאה הוא prompt, צריך להתחיל את הקריאה ל-document.requestStorageAccess() אחרי תנועת משתמש, כמו לחיצה על לחצן.

דוגמה:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

לבקשות הבאות מתוך המסגרת, הניווטים או המשאבים המשניים תהיה הרשאה אוטומטית לגשת לקובצי cookie בכמה אתרים. הפונקציה hasStorageAccess() מחזירה את הערך true, וקובצי cookie מאתרים שונים מאותה קבוצת אתרים קשורים יישלחו בבקשות האלה ללא קריאות JavaScript נוספות.

תרשים שבו מוצגת הקריאה requestStorageAccessFor()‎ באתר ברמה העליונה ולא בתוך הטמעה
שימוש ב-requestStorageAccessFor() באתר ברמה העליונה למקור אחר

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

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

כדי לבדוק אם תופיע בקשה למשתמש או אם כבר ניתנה גישה לאחסון למקור שצוין, צריך לבצע קריאה ל-navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}).

אם ההרשאה היא granted, אפשר לבצע קריאה ל-document.requestStorageAccessFor('https://target.site'). הפעולה אמורה להתבצע ללא פעולת משתמש.

אם ההרשאה היא prompt, תצטרכו לקשר את הקריאה ל-document.requestStorageAccessFor('https://target.site') מאחורי תנועת המשתמש, כמו לחיצה על לחצן.

דוגמה:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

אחרי קריאה מוצלחת ל-requestStorageAccessFor(), בקשות בין אתרים יכללו קובצי Cookie אם הן כוללות CORS או את המאפיין crossorigin, לכן כדאי לאתרים להמתין לפני שהם מפעילים בקשה.

בבקשות צריך להשתמש באפשרות credentials: 'include' והמשאבים צריכים לכלול את המאפיין crossorigin="use-credentials".

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

איך בודקים באופן מקומי

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

כדי לבדוק קבוצות של אתרים קשורים באופן מקומי, צריך להשתמש ב-Chrome מגרסה 119 ואילך שפועל משורת הפקודה ולהפעיל את הדגל של Chrome test-third-party-cookie-phaseout.

הפעלת הדגל ב-Chrome

כדי להפעיל את הדגל הנדרש של Chrome, עוברים לכתובת chrome://flags#test-third-party-cookie-phaseout מסרגל הכתובות ומשנים את הדגל ל-Enabled. חשוב להפעיל מחדש את הדפדפן אחרי שינוי הדגלים.

כדי להפעיל את Chrome עם קבוצת אתרים קשורים שהוגדרה באופן מקומי, יוצרים אובייקט JSON שמכיל כתובות URL שהן חברות בקבוצה ומעבירים אותו אל --use-related-website-set.

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

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

דוגמה

כדי להפעיל קבוצות של אתרים קשורים באופן מקומי, צריך להפעיל את הדגל test-third-party-cookie-phaseout בקובץ chrome://flags ולהפעיל את Chrome משורת הפקודה עם הדגל --use-related-website-set, יחד עם אובייקט ה-JSON שמכיל את כתובות ה-URL ששייכות לקבוצה.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

מוודאים שיש לכם גישה לקובצי cookie בכמה אתרים

קוראים לממשקי ה-API (rSA או rSAFor) מהאתרים שנבדקים ומאמתים את הגישה לקובצי ה-cookie בכמה אתרים.

כדי להצהיר על הקשר בין הדומיינים ולציין לאיזו קבוצת משנה הם שייכים, פועלים לפי השלבים הבאים:

1. זיהוי ה-RWS

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

2. יצירת בקשה להצטרפות ל-RWS

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

3. מוודאים שה-RWS עומד בדרישות הטכניות

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

4. בדיקת RWS באופן מקומי

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

5. שליחת ה-RWS

שולחים את קבוצת האתרים הקשורים על ידי יצירת בקשת תיקון (PR) לקובץ related_website_sets.JSON שבו Chrome מארח את הרשימה הקנונית של קבוצות האתרים הקשורים. (נדרש חשבון GitHub כדי ליצור בקשות תיקון, וצריך לחתום על הסכם רישיון של שותף (CLA) לפני שתוכלו לתרום לרשימת הספרים).

אחרי יצירת הבקשה, מתבצעת סדרה של בדיקות כדי לוודא שהבקשה עומדת בדרישות של שלב 3, למשל לוודא שחתמתם על ה-CLA ושקובץ .well-known תקין.

אם הבדיקה תעבור, ב-PR יופיע סימן וי. בקשות תיקון שאושררו ימוזגו באופן ידני בקבוצות לרשימת קבוצות האתרים הקשורים הקנונית פעם בשבוע (ביום שלישי בשעה 12:00 לפי שעון החוף המזרחי). אם אחת מהבדיקות נכשלת, השולח יקבל הודעה על כך דרך כשל ב-PR ב-GitHub. שולחי הבקשה יכולים לתקן את השגיאות ולעדכן את הבקשה. חשוב לזכור:

  • אם ה-PR נכשל, תוצג הודעת שגיאה עם מידע נוסף על הסיבה לכך. (דוגמה).
  • כל הבדיקות הטכניות שקשורות לשליחת ערכות מתבצעות ב-GitHub, ולכן כל הכישלונות בשליחה שנובעים מבדיקות טכניות יהיו גלויים ב-GitHub.

כללי מדיניות הארגון

ב-Chrome יש שתי מדיניות שמיועדות לענות על הצרכים של משתמשים ארגוניים:

  • אם יש מערכות שלא ניתן לשלב עם 'קבוצות של אתרים קשורים', אפשר להשבית את התכונה 'קבוצות של אתרים קשורים' בכל המכונות של Chrome בארגון באמצעות המדיניות RelatedWebsiteSetsEnabled.
  • במערכות ארגוניות מסוימות יש אתרים פנימיים בלבד (כמו אינטראנט) עם דומיינים שניתן לרשום, שונים מהדומיינים בקבוצת האתרים הקשורים שלהם. אם הם צריכים להתייחס לאתרים האלה כחלק מקבוצת האתרים הקשורים שלהם בלי לחשוף אותם באופן ציבורי (כי הדומיינים עשויים להיות סודיים), הם יכולים להוסיף לרשימה הציבורית של קבוצות האתרים הקשורים או לשנות אותה באמצעות המדיניות של RelatedWebsiteSetsOverrides.

Chrome פותר כל צומת של הקבוצות הציבוריות והארגוניות באחת משתי דרכים, בהתאם להגדרה של replacemements או additions.

לדוגמה, עבור הקבוצה הציבורית {primary: A, associated: [B, C]}:

replacements: {primary: C, associated: [D, E]}
האתר המשותף משולב בקבוצה הארגונית כדי ליצור קבוצה חדשה.
הקבוצות שמתקבלות: {primary: A, associated: [B]}
{primary: C, associated: [D, E]}
additions: {primary: C, associated: [D, E]}
הקבוצות 'ציבורי' ו'ארגוני' משולבות.
הקבוצה שמתקבלת: {primary: C, associated: [A, B, D, E]}

'הנחיה למשתמש' ו'מחווה של משתמש'

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

גישה לקובצי cookie או לאחסון של אתרים אחרים

קבוצות של אתרים קשורים לא ממזגות את האחסון של אתרים שונים: הן רק מאפשרות לבצע בקלות רבה יותר קריאות ל-requestStorageAccess() (ללא הנחיה). קבוצות האתרים הקשורות רק מפחיתות את החיכוך של המשתמשים בשימוש ב-Storage Access API, אבל לא קובעות מה לעשות אחרי שהגישה תוחזר. אם א' וב' הם אתרים שונים באותו קבוצת אתרים קשורים, וא' מוטמע ב-B, האתר B יכול לבצע קריאה ל-requestStorageAccess() ולקבל גישה לאחסון מאינטראקציה ישירה בלי להציג למשתמש בקשה. 'קבוצות של אתרים קשורים' לא מבצעת תקשורת בין אתרים. לדוגמה, הגדרת קבוצת אתרים קשורים לא תגרום לכך שקובצי ה-cookie ששייכים לאתר B יתחילו להישלח לאתר A. אם רוצים לשתף את הנתונים האלה, צריך לשתף אותם בעצמכם. לדוגמה, אפשר לשלוח window.postMessage מ-iframe של B למסגרת של A.

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

מתן משוב

שליחת קבוצה ב-GitHub ועבודה עם Storage Access API ו-requestStorageAccessFor API הן הזדמנויות לשתף את החוויה שלכם בתהליך ואת הבעיות שבהן נתקלת.

כדי להצטרף לדיוני 'קבוצות של אתרים קשורים':