ממשק API לגישה לאחסון

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

סטטוס הטמעה

תמיכה בדפדפן

  • 119
  • 85
  • 65
  • 11.1

מקור

Storage Access API זמין בכל הדפדפנים העיקריים אבל יש הבדלים קלים בהטמעה בין הדפדפנים. ההבדלים האלה הודגשו בקטעים הרלוונטיים בפוסט הזה.

אנחנו ממשיכים לעבוד כדי לפתור את כל בעיות החסימה שנותרו לפני ביצוע סטנדרטיזציה של ה-API.

מה זה Storage Access API?

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

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

Storage Access API מאפשר גישה לאחסון ולקובצי cookie ספציפיים ללא מחיצות (Partitions) לגישה לאחסון ולקובצי Cookie מסוימים שלא מחולקים למחיצות

תרחישים לדוגמה

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

התרחישים לדוגמה כוללים:

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

רבים מהתרחישים האלה כוללים גישה מתמשכת להתחברות במסגרות iframe מוטמעות.

מתי להשתמש ב-Storage Access API על פני ממשקי API אחרים

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

  • המשתמש יקיים אינטראקציה עם התוכן המוטמע – כלומר, זה לא iframe סביל או iframe מוסתר.
  • המשתמש ביקר במקור המוטמע בהקשר ברמה העליונה – כלומר, כשהמקור הזה לא מוטמע באתר אחר.

יש ממשקי API חלופיים למגוון רחב של תרחישים לדוגמה:

  • קובצי Cookie עם חלוקה עצמאית למחיצות (CHIPS) (CHIPS) מאפשרים למפתחים להביע הסכמה של קובץ Cookie לאחסון "מחולק למחיצות", עם צנצנת קובצי Cookie נפרדת לכל אתר ברמה העליונה. לדוגמה, ווידג'ט של צד שלישי של צ'אט באינטרנט עשוי להסתמך על הגדרה של קובץ cookie כדי לשמור פרטי סשן. פרטי הסשן נשמרים לכל אתר בנפרד, כך שאין צורך לגשת לקובץ ה-cookie שהוגדר על ידי הווידג'ט באתרים אחרים שבהם הוא גם מוטמע. Storage Access API שימושי במקרים שבהם ווידג'ט מוטמע של צד שלישי תלוי בשיתוף אותו מידע בין מקורות שונים (לדוגמה, במקרה של העדפות או פרטי סשן שמחוברים לחשבון).
  • חלוקה למחיצות (partitioning) באחסון מאפשרת למסגרות iframe חוצות-אתרים להשתמש במנגנוני אחסון קיימים של JavaScript תוך חלוקת האחסון הבסיסי לכל אתר. ההגדרה הזו מונעת גישה של אותה הטמעה באתרים אחרים לאחסון המוטמע באתר אחד.
  • קבוצות אתרים קשורים (RWS) הן דרך שבה ארגונים יכולים להצהיר על קשרים בין אתרים, כדי שדפדפנים יאפשרו גישה מוגבלת לאחסון ולקובצי cookie ללא חלוקת נתונים למטרות ספציפיות. אתרים עדיין צריכים לבקש גישה באמצעות Storage Access API, אבל אתרים שכלולים בקבוצה יכולים לקבל גישה ללא בקשות משתמשים.
  • ניהול פרטי כניסה מאוחדים (FedCM) הוא גישה ששומרת על הפרטיות בשירותי זהות מאוחדים. Storage Access API מטפל בגישה לאחסון ולקובצי cookie ללא מחיצות אחרי ההתחברות. בחלק מהמקרים, FedCM מספק פתרון חלופי ל-Storage Access API, ויכול להיות שהוא עדיף כי הוא כולל הנחיית דפדפן ממוקדת יותר בהתחברות. עם זאת, בדרך כלל כדי להשתמש ב-FedCM צריך לבצע שינויים נוספים בקוד, למשל כדי לתמוך בנקודות הקצה של HTTP.
  • גם ממשקי ה-API של Ati-fraud, מודעות ומדידה שקיימים, Storage Access API לא נועדו לטפל בבעיות האלה.

שימוש ב-Storage Access API

ל-Storage Access API יש שתי שיטות מבוססות-מובטחות:

הוא גם משתלב עם Permissions API. כך ניתן לבדוק את הסטטוס של הרשאת הגישה לאחסון בהקשר של צד שלישי. הסטטוס הזה מציין אם קריאה ל-document.requestStorageAccess() תוענק באופן אוטומטי:

באמצעות השיטה hasStorageAccess()

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

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted via the Storage Access API.
    // Note on page load this will always be false initially so we could be
    // skipped in this example, but including for completeness for when this
    // is not so obvious.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

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

באמצעות השיטה requestStorageAccess()

אם ל-iframe אין גישה, ייתכן שיהיה צורך לבקש גישה באמצעות השיטה requestStorageAccess():

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

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

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

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if above did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

אם אתם צריכים להשתמש באחסון מקומי במקום בקובצי cookie, תוכלו לבצע את הפעולות הבאות:

let handle = null;

async function doClick() {
  if (!handle) {
    try {
      handle = await document.requestStorageAccess({localStorage: true});
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  // Use handle to access unpartitioned local storage.
  handle.localStorage.setItem('foo', 'bar');
}

document.querySelector('#my-button').addEventListener('click', doClick);

בקשות להרשאות

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

צילום מסך של בקשת ההרשאה ל-Chrome Storage Access API
בקשה להרשאה של Storage Access API ב-Chrome

הדפדפן עשוי לדלג על הבקשה ולקבל הרשאה אוטומטית בנסיבות מסוימות:

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

לחלופין, ייתכן שהשיטה תידחה באופן אוטומטי בלי שההצעה תוצג בנסיבות מסוימות:

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

המשתמשים יתבקשו לעשות זאת במהלך השימוש הראשוני, אבל בביקורים הבאים אפשר לפתור את הבעיה requestStorageAccess() ללא בקשה להנחיה ובלי צורך באינטראקציה של המשתמש ב-Chrome וב-Firefox. הערה: ב-Safari תמיד נדרשת אינטראקציה של המשתמש.

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

שימוש בשאילתת ההרשאה storage-access

כדי לבדוק אם אפשר להעניק גישה ללא אינטראקציה של המשתמש, אפשר לבדוק את סטטוס ההרשאה storage-access ולבצע את הקריאה ל-requestStoreAccess() בשלב מוקדם אם לא נדרשת פעולה מצד המשתמש. במקום זאת, היא תיכשל כשנדרשת אינטראקציה.

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

הקוד הבא מוסיף את בדיקת ההרשאות storage-access לדוגמה הקודמת:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and older versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Currently not used. See:
      // https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by one of above.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

iframes בארגז חול (Sandbox)

כשמשתמשים ב-Storage Access API במסגרות iframe בארגז חול (sandbox), נדרשות ההרשאות הבאות ב-Sandbox:

  • נדרש allow-storage-access-by-user-activation כדי לאפשר גישה ל-Storage Access API.
  • הרכיב allow-scripts נדרש כדי לאפשר שימוש ב-JavaScript כדי לקרוא ל-API.
  • נדרשת allow-same-origin כדי לאפשר גישה לקובצי cookie ממקור זהה ולאמצעי אחסון אחרים.

למשל:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

כדי שאפשר יהיה לגשת אליהם באמצעות Storage Access API ב-Chrome, צריך להגדיר קובצי Cookie של אתרים שונים עם שני המאפיינים הבאים:

  • SameSite=None – שנדרש כדי לסמן את קובץ ה-cookie ככזה שמופיע באתרים שונים
  • Secure – מבטיח שניתן לגשת רק לקובצי Cookie שהוגדרו על ידי אתרי HTTPS.

ב-Firefox וב-Safari, קובצי ה-cookie מוגדרים כברירת מחדל ל-SameSite=None. הם לא מגבילים את SSA לקובצי cookie של Secure, כך שהמאפיינים האלה לא נדרשים. מומלץ לציין באופן מפורש את המאפיין SameSite ולהשתמש תמיד בקובצי cookie של Secure.

גישה לדף ברמה העליונה

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

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

השיטה requestStorageAccessFor()

תמיכה בדפדפן

  • 119
  • 119
  • x
  • x

מקור

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

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

השאילתה של ההרשאה top-level-storage-access

תמיכה בדפדפן

  • x
  • x
  • x
  • x

בדומה להרשאה storage-access, יש הרשאת top-level-storage-access כדי לבדוק אם אפשר להעניק גישה בשביל requestStorageAccessFor().

מה ההבדל ב-Storage Access API כשמשתמשים ב-RWS?

כשמשתמשים בקבוצות של אתרים קשורים עם Storage Access API, אפשר להשתמש ביכולות נוספות מסוימות, לפי הפירוט בטבלה הבאה:

ללא RWS עם RWS
נדרשת תנועת משתמש כדי להפעיל את בקשת הגישה לאחסון
המשתמש נדרש לבקר במקור האחסון המבוקש בהקשר ברמה העליונה לפני הענקת גישה
אפשר לדלג על הודעה למשתמשים בפעם הראשונה
אין צורך לקרוא לאפליקציית requestStorageAccess אם כבר ניתנה גישה בעבר
מעניק גישה אוטומטית לדומיינים אחרים באתר אתר קשור
יש תמיכה במאפיין requestStorageAccessFor בגישה לדף ברמה העליונה
ההבדלים בין שימוש ב-Storage Access API בלי קבוצות של אתרים קשורים

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

ההדגמה הבאה מראה איך קובץ cookie שהגדרתם בעצמכם במסך הראשון של ההדגמה ניתן לגשת במסגרת מוטמעת באתר השני של ההדגמה:

storage-access-api-demo.glitch.me

לצורך ההדגמה יש צורך בדפדפן שבו קובצי cookie של צד שלישי מושבתים:

  • Chrome בגרסה 118 ואילך, עם הדגל chrome://flags/#test-third-party-cookie-phaseout והדפדפן הופעל מחדש.
  • Firefox
  • Safari

הדגמה: הגדרה של אחסון מקומי

ההדגמה הבאה מראה איך לגשת לערוצי שידור ללא חלוקה למחיצות מ-iframe של צד שלישי באמצעות Storage Access API:

https://saa-beyond-cookies.glitch.me/

לצורך ההדגמה, נדרש דפדפן Chrome בגרסה 125 ומעלה והסימון test-third-party-cookie-phaseout מופעל.

מקורות מידע