קבוצות של אתרים קשורים (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.uk יסתמכו על שירות שמתארח על ידי example.ca).
- שילוב דומיין שירות. ניצול הדומיינים של שירותים שהמשתמשים אף פעם לא יוצרים איתם אינטראקציה ישירה, אבל מספק שירותים באתרים של אותו ארגון (example-cdn.com).
- הפרדה בין תוכן משתמשים. גישה לנתונים בדומיינים שונים שמפרידים תוכן שהועלה על ידי משתמשים מתוכן אחר באתר מטעמי אבטחה, תוך מתן הרשאת גישה לדומיין הערוך בארגז חול לקובצי cookie של אימות (ואחרים). אם אתם מציגים תוכן לא פעיל שהועלה על ידי משתמשים, יכול להיות שתוכלו גם לארח אותו בבטחה באותו דומיין בעזרת השיטות המומלצות.
- תוכן מאומת מוטמע. תמיכה בתוכן מוטמע מכל הנכסים של שותף עצמאי (סרטונים, מסמכים או משאבים שמוגבלים למשתמשים שמחוברים לחשבון ברמה העליונה).
- כניסה. תמיכה בכניסה בכל הנכסים הקשורים. גם FedCM API עשוי להתאים לתרחישי שימוש מסוימים.
- Google Analytics. פריסה של ניתוח נתונים ומדידה של התהליכים שעוברים המשתמשים בנכסים משויכים כדי לשפר את איכות השירותים.
פרטי השילוב של 'קבוצות של אתרים קשורים'
Storage Access API
Storage Access API (SAA) מאפשר לתוכן מוטמע ממקורות שונים לגשת לאחסון שבדרך כלל הייתה לו גישה אליו רק בהקשר של צד ראשון.
משאבים מוטמעים יכולים להשתמש בשיטות SAA כדי לבדוק אם יש להם כרגע גישה לאחסון, ולבקש גישה מסוכן המשתמש.
כשקובצי cookie של צד שלישי חסומים אבל האפשרות 'קבוצות של אתרים קשורים' (RWS) מופעלת, Chrome יעניק הרשאה באופן אוטומטי בהקשרים של צד שלישי, ואם לא, תוצג למשתמש בקשה. ('הקשר intra-RWS' הוא הקשר, כמו iframe, שהאתר המוטמע והאתר ברמה העליונה שלו נמצאים באותו RWS.)
בדיקה ובקשת גישה לאחסון
כדי לבדוק אם יש להם כרגע גישה לאחסון, אתרים מוטמעים יכולים להשתמש בשיטה Document.hasStorageAccess().
השיטה מחזירה ערך פרוגרמטי עם ערך בוליאני שמציין אם למסמך כבר יש גישה לקובצי ה-cookie שלו. ההבטחה גם מחזירה TRUE אם ה-iframe הוא אותו מקור כמו המסגרת העליונה.
כדי לבקש גישה לקובצי cookie באתרים מוטמעים בהקשר של מספר אתרים, אפשר להשתמש ב-Document.requestStorageAccess() (rSA).
הקריאה ל-API requestStorageAccess() אמורה להתבצע מתוך iframe. ה-iframe הזה צריך רק לקבל אינטראקציה מצד המשתמש (תנועת משתמש, הנדרשת על ידי כל הדפדפנים), אבל Chrome דורש בנוסף שבשלב מסוים ב-30 הימים האחרונים, המשתמש ביקר באתר שהוא הבעלים של ה-iframe הזה, ויצר איתו אינטראקציה ספציפית – כמסמך ברמה עליונה, ולא במסגרת iframe.
requestStorageAccess() מחזירה הבטחה שתיקבע אם הגישה לאחסון ניתנה. ההבטחה נדחית ומצטטת את הסיבה, אם הגישה נדחתה מסיבה כלשהי.
requestStorageAccessFor ב-Chrome
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
בקובצי cookie חייבים לציין את המאפיין SameSite=None וגם את המאפיין Secure, כי rSA בלבד מספק גישה לקובצי cookie שכבר סומנו לשימוש בהקשרים שבין כמה אתרים.
קובצי cookie עם SameSite=Lax, SameSite=Strict או ללא המאפיין SameSite מיועדים לשימוש של צד ראשון בלבד ולעולם לא ישותפו בהקשר של אתרים שונים, ללא קשר ל-rSA.
אבטחה
עבור rSAFor, בקשות למשאבי משנה מחייבות כותרות של שיתוף משאבים בין מקורות (CORS) או את המאפיין crossorigin במשאבים, כדי להבטיח הסכמה מפורשת.
דוגמאות להטמעה
בקשת גישה לאחסון מ-iframe מוטמע ממקורות שונים
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() מחזירה קובצי cookie אמיתיים ומאתרים שונים מאותה קבוצת אתרים קשורים יישלחו בעקבות הבקשות האלה ללא קריאות JavaScript נוספות.
אתרים ברמה העליונה שמבקשים גישה לקובצי cookie מטעם אתרים ממקורות שונים
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 או את המאפיין 'מקורות שונים', כך שאתרים מסוימים כדאי להמתין לפני שמפעילים בקשה.
הבקשות צריכות לכלול את האפשרות 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 ואילך שמופעל משורת הפקודה ולהפעיל את test-third-party-cookie-phaseout הדגל של Chrome.
הפעלת הדגל של Chrome
כדי להפעיל את הדגל הנדרש של Chrome, יש לנווט אל chrome://flags#test-third-party-cookie-phaseout מסרגל הכתובות ולשנות את הדגל ל-Enabled. חשוב להפעיל מחדש את הדפדפן אחרי שינוי הסימונים.
הפעלת Chrome עם קבוצה מקומית של אתרים קשורים
כדי להפעיל את 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 באתרים שונים.
תהליך השליחה של 'קבוצות של אתרים קשורים'
כדי להצהיר על הקשר בין דומיינים ולציין את קבוצת המשנה שהם חלק ממנה, צריך לבצע את השלבים הבאים:
- מזהים את הדומיינים הרלוונטיים, כולל הדומיין הראשי והנכסים שהוגדרו, שיהיו חלק מקבוצת האתרים הקשורים. צריך לזהות גם לאיזה סוג קבוצת משנה שייך כל איבר בקבוצה.
- מקפידים להגדיר את דרישות היצירה ואת הגדרת דרישות האימות.
- מצהירים על קבוצת האתרים הקשורים בפורמט JSON הנכון.
- שולחים את קבוצת האתרים הקשורים באמצעות יצירת בקשת משיכה (PR) אל
related_website_sets.JSON, שבו Chrome יארח את הרשימה הקנונית של קבוצות האתרים הקשורים. (כדי ליצור יחסי ציבור צריך חשבון GitHub, ועליך לחתום על הסכם רישיון של 'תורמים' (CLA) כדי להוסיף תוכן לרשימה.)
לאחר יצירת ה-PR, תתבצע סדרה של בדיקות כדי לאמת שהדרישות משלב 2 מתקיימים.
אם הפעולה בוצעה בהצלחה, ה-PR יציין שעברתם את הבדיקות. יחסי ציבור שאושרו ימוזגו באופן ידני באצוות עם הרשימה הקנונית של קבוצות אתרים קשורים פעם בשבוע (ימי שלישי בשעה 12:00 לפי שעון החוף המזרחי).
אם אחת מהבדיקות נכשלת, מגיש הבקשה יקבל הודעה על כשל יחסי ציבור ב-GitHub. מגיש הבקשה יכול לתקן את השגיאות ולעדכן את ה-PR, חשוב לזכור את הפרטים הבאים:
- כאשר יחסי הציבור נכשלים, הודעת שגיאה תספק מידע נוסף על הסיבות לכך שהשליחה נכשלה (דוגמה).
- כל הבדיקות הטכניות המפקחות על שליחת קבוצות מתבצעות ב-GitHub, וכתוצאה מכך כל כשלי השליחה שנובעים מבדיקות טכניות יהיו גלויים ב-GitHub.
מדיניות ארגונית
כדי לתת מענה לצרכים של משתמשים ארגוניים, ב-Chrome יש כמה כללי מדיניות ארגוניים:
- מערכות שייתכן שלא יוכלו להשתלב עם קבוצות של אתרים קשורים יכולות להשבית את התכונה 'קבוצות של אתרים קשורים' בכל המופעים הארגוניים של Chrome באמצעות המדיניות
RelatedWebsiteSetsEnabled. - למערכות ארגוניות מסוימות יש אתרים פנימיים בלבד (כמו רשת אינטראנט) עם דומיינים שניתן לרשום השונים מהדומיינים בקבוצת האתרים הקשורים שלהן. אם הלקוחות צריכים להתייחס לאתרים האלה כחלק מקבוצת האתרים הקשורים שלהם בלי לחשוף אותם באופן ציבורי (מאחר שהדומיינים עשויים להיות סודיים), הם יכולים להרחיב או לבטל את הרשימה הציבורית של קבוצות האתרים הקשורים שלהם בהתאם למדיניות
RelatedWebsiteSetsOverrides.
פתרון בעיות עם 'קבוצות של אתרים קשורים'
'הודעה למשתמש' ו'תנועת משתמש'
'הודעת משתמש' ו'תנועת משתמש' הן שני דברים שונים. Chrome לא יציג למשתמשים בקשת הרשאה לאתרים שנמצאים באותה קבוצת אתרים קשורים, אבל ב-Chrome עדיין נדרשת אינטראקציה של המשתמש עם הדף. לפני שמעניקים הרשאה, ב-Chrome נדרשת תנועת משתמש, שנקראת גם 'אינטראקציה של משתמש' או 'הפעלת משתמש'. הסיבה לכך היא שהשימוש ב-Storage Access API מחוץ להקשר של קבוצת אתרים קשורים (כלומר
requestStorageAccess()) מחייב גם פעולת משתמש בגלל
עקרונות התכנון של פלטפורמת האינטרנט.
גישה לאחסון או לקובצי Cookie של אתרים אחרים
התכונה 'קבוצות של אתרים קשורים' לא ממזגת אחסון לאתרים שונים, אלא רק מאפשרת שיחות requestStorageAccess() קלות יותר (בחינם). הגדרות של אתרים קשורים
רק מצמצמות את הקשיים של השימוש ב-Storage Access API, אבל לא
מכתיבות מה לעשות לאחר שחזור הגישה. אם א' וב' הם אתרים שונים
באותה קבוצת אתרים קשורים, וגם א' מטמיעה את ב', ב' יכולים להתקשר אל requestStorageAccess() ולקבל גישה לאחסון מהדומיין הנוכחי בלי לבקש מהמשתמש אישור לכך. קבוצות של אתרים קשורים לא מבצעות תקשורת בין אתרים. לדוגמה, הגדרה של קבוצת אתרים קשורים לא תגרום לקובצי cookie ששייכים
ל-B להתחיל להישלח אל A. אם אתם רוצים לשתף את הנתונים האלה, תצטרכו לשתף אותם בעצמכם, לדוגמה על ידי שליחת window.postMessage מ-iframe מסוג B למסגרת.
גישה ללא חלוקה למחיצות כברירת מחדל
קבוצות של אתרים קשורים לא מאפשרות גישה משתמעת לקובצי cookie שאינם מחולקים למחיצות,
בלי להפעיל API כלשהו. קובצי cookie מאתרים שונים לא זמינים כברירת מחדל בתוך הקבוצה. קבוצות אתרים קשורים רק מאפשרות לאתרים בתוך הקבוצה לדלג על בקשת ההרשאה של Storage Access API.
iframe חייב לקרוא ל-document.requestStorageAccess() אם הוא רוצה לגשת לקובצי ה-cookie שלו, או שהדף ברמה העליונה יכול לקרוא ל-document.requestStorageAccessFor().
מתן משוב
שליחת קבוצה ב-GitHub ועבודה עם Storage Access API ועם requestStorageAccessFor API הן הזדמנויות לשתף את החוויה שלך עם התהליך וכל בעיה שבה נתקלת.
כדי להצטרף לדיונים על קבוצות של אתרים קשורים:
- הצטרף לרשימת הדיוור הציבורית של 'קבוצות אתרים קשורים'.
- העלו בעיות והמשיכו את הדיון בנושא מאגר GitHub של אתרים קשורים.