קבוצות של אתרים קשורים (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 לאימות (וגם לקובצי cookie אחרים). אם מוצג תוכן לא פעיל שהועלה על ידי משתמשים, יכול להיות שתהיה לך אפשרות גם לארח באופן בטוח אותו באותו דומיין אם תפעל לפי השיטות המומלצות.
- תוכן מאומת מוטמע. תמיכה בתוכן מוטמע מכמה נכסים משויכים (סרטונים, מסמכים או משאבים שמוגבלים למשתמש שמחובר לאתר ברמה העליונה).
- כניסה לחשבון. תמיכה בכניסה באמצעות נכסים משויכים. גם FedCM API עשוי להתאים לתרחישים מסוימים.
- Analytics. פריסת ניתוח נתונים ומדידת התהליכים שעוברים המשתמשים בנכסים שמשויכים לשותפים כדי לשפר את איכות השירותים.
פרטי השילוב של 'קבוצות של אתרים קשורים'
Storage Access API
Storage Access API (SAA) מספק דרך לתוכן מוטמע ממקורות שונים לגשת לאחסון שבדרך כלל יש לו גישה אליו רק בהקשר של צד ראשון.
משאבים מוטמעים יכולים להשתמש בשיטות של SAA כדי לבדוק אם יש להם כרגע גישה לאחסון, וכדי לבקש גישה מסוכן המשתמש.
אם קובצי Cookie של צד שלישי חסומים אבל 'קבוצות של אתרים קשורים (RWS)' מופעלת, Chrome יעניק הרשאה באופן אוטומטי בהקשרים בתוך RWS. במקרים אחרים הוא יציג הודעה למשתמש. ('הקשר בתוך 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().
אם תוקף ההבטחה יתקיים, תוכלו לגשת לאחסון בהקשר של כמה אתרים. אם הבעיה נמשכת, צריך לבקש גישה לאחסון.
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 מסוג true וקובצי 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 או את המאפיין 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 ואילך שהופעלה משורת הפקודה ולהפעיל את הדגל 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 יארח את הרשימה הקנונית של קבוצות האתרים הקשורים. (כדי ליצור PR, נדרש חשבון GitHub, ותצטרכו לחתום על הסכם רישיון של תורם (CLA) כדי לתרום לרשימה.)
לאחר יצירת ה-PR, תתבצע סדרה של בדיקות כדי לאמת שהדרישות משלב 2 מתקיים.
אם התהליך יסתיים בהצלחה, ה-PR יציין שהבדיקות עברו בהצלחה. מסמכי PR שאושרו ימוזגו באופן ידני בקבוצות אל הרשימה של קבוצות האתרים הקשורים הקנוניים פעם בשבוע (ימי שלישי בשעה 12:00 לפי שעון החוף המזרחי).
אם אחת מהבדיקות נכשלה, השולח יקבל הודעה על כך שנכשלה ב-GitHub. מגיש הבקשה יכול לתקן את השגיאות ולעדכן את ה-PR. כמו כן, חשוב לזכור:
- אם יחס הציבור נכשל, הודעת שגיאה תספק מידע נוסף על הסיבה לכך שהשליחה נכשלה (דוגמה).
- כל הבדיקות הטכניות שקשורות לשליחות של קבוצות מתבצעות ב-GitHub, וכתוצאה מכך תוכלו לראות את כל הכשלים בשליחה כתוצאה מבדיקות טכניות ב-GitHub.
מדיניות ארגונית
ב-Chrome קיימים שני כללי מדיניות שנועדו לתת מענה לצרכים של משתמשים בגרסה הארגונית:
- מערכות שאולי לא יכולות להשתלב עם קבוצות של אתרים קשורים יכולות להשבית את התכונה 'קבוצות של אתרים קשורים' בכל המופעים של Chrome בארגון, בעזרת המדיניות
RelatedWebsiteSetsEnabled. - לחלק מהמערכות הארגוניות יש אתרים פנימיים בלבד (כמו אינטראנט) עם דומיינים שניתן לרשום ושונים מהדומיינים בקבוצת האתרים הקשורים שלהן. אם הלקוחות צריכים לטפל באתרים האלה כחלק מקבוצת האתרים הקשורים שלהם בלי לחשוף אותם באופן ציבורי (מכיוון שהדומיינים עשויים להיות סודיים), הם יכולים להרחיב או לבטל את הרשימה הציבורית של קבוצות האתרים הקשורים שלהם באמצעות המדיניות
RelatedWebsiteSetsOverrides.
Chrome פותר כל הצטלבות של קבוצות ציבוריות ו-Enterprise באחת מתוך שתי קבוצות
בדרכים הבאות, בהתאם לפירוט replacemements או additions.
לדוגמה, עבור הקבוצה הציבורית {primary: A, associated: [B, C]}:
replacements: |
{primary: C, associated: [D, E]} |
| קבוצת Enterprise משלבת את האתר המשותף ויוצרת קבוצה חדשה. | |
| הקבוצות המתקבלות: | {primary: A, associated: [B]}{primary: C, associated: [D, E]} |
additions: |
{primary: C, associated: [D, E]} |
| מתבצע שילוב של קבוצות ציבוריות ו-Enterprise. | |
| התוצאה שמתקבלת: | {primary: C, associated: [A, B, D, E]} |
פתרון בעיות בקבוצות של אתרים קשורים
"הנחיה למשתמש" ו'תנועת משתמש'
'הנחיה למשתמש' ו'תנועת משתמש' הם דברים שונים. Chrome לא יציג
בקשת הרשאה
למשתמשים באתרים ששייכים לאותה קבוצת אתרים קשורים, אבל Chrome עדיין
נדרשת אינטראקציה של המשתמש עם הדף. לפני שאתם נותנים הרשאה,
ב-Chrome נדרש
תנועת משתמש,
נקראת גם "אינטראקציה מצד המשתמש" או "הפעלת משתמש". הסיבה לכך היא שהשימוש ב-
Storage Access API מחוץ להקשר של קבוצת אתרים קשורים (כלומר
requestStorageAccess()) נדרשת גם תנועת משתמש, בגלל
עקרונות לעיצוב פלטפורמות באינטרנט.
גישה לאתרים אחרים קובצי Cookie או אחסון
התכונה 'קבוצות של אתרים קשורים' לא ממזגת את נפח האחסון של אתרים שונים: היא רק מאפשרת
שיחות requestStorageAccess() (ללא בקשות) קל יותר. אתר קשור
ההגדרה רק מפחיתה את רמת החיכוך של המשתמשים ב-Storage Access API, אבל לא
קובעים מה לעשות אחרי שהגישה תשוחזר. אם א' ו-ב' הם אתרים שונים
באותה קבוצת אתרים קשורים, והטמעות א' ב' יכולות לקרוא
requestStorageAccess() ולקבל גישה לאחסון של צד ראשון בלי להציג בקשה
למשתמש. 'קבוצות של אתרים קשורים' לא מבצעות תקשורת בין אתרים. עבור
לדוגמה, הגדרה של קבוצת אתרים קשורים לא תגרום לקובצי ה-cookie השייכים
כדי להתחיל להישלח אל ב'. אם
אם תרצו לשתף את הנתונים האלה, תצטרכו לשתף אותם בעצמכם. לדוגמה,
שליחת window.postMessage מ-B iframe
מסגרת.
כברירת מחדל, גישה לקובצי cookie ללא שיוך למחיצות
התכונה 'קבוצות של אתרים קשורים' לא מאפשרת גישה מרומזת לקובצי cookie ללא שיוך למחיצות
בלי להפעיל אף API. קובצי Cookie מאתרים שונים לא זמינים
על ידי default בתוך הקבוצה; ההגדרה 'קבוצות של אתרים קשורים' מאפשרת רק לאתרים שנמצאים
מדלגים על בקשת ההרשאה Storage Access API.
ה-iframe חייב לקרוא ל-document.requestStorageAccess() אם הוא רוצה לגשת
קובצי Cookie, או שהדף ברמה העליונה יכול לקרוא ל-document.requestStorageAccessFor().
מתן משוב
שליחת קבוצה ב-GitHub ועבודה עם Storage Access API וה-API של requestStorageAccessFor הן הזדמנויות לשתף את החוויה שלכם עם התהליך וכל בעיה שבה נתקלתם.
כדי להצטרף לדיונים על קבוצות של אתרים קשורים:
- מצטרפים לרשימת התפוצה הציבורית של 'קבוצות אתרים קשורים'.
- מעלים בעיות ועוקבים אחרי הדיון במאגר GitHub של קבוצות אתרים קשורים.