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

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

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

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

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

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

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

מתי כדאי להשתמש ב-Storage Access API במקום בממשקי API אחרים

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

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

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

  • קובצי Cookie שיש להם מצב נפרד של מחיצות (CHIPS) מאפשר למפתחים להביע הסכמה לשימוש בקובץ Cookie לאחסון 'מחיצות', עם מאגר נפרד של קובצי Cookie לכל אתר ברמה עליונה. לדוגמה, ווידג'ט של צ'אט באינטרנט של צד שלישי עשוי להסתמך על הגדרת קובץ Cookie לשמירת פרטי סשנים. פרטי ההפעלה נשמרים לכל אתר בנפרד, כך שאין צורך לגשת לקובץ ה-cookie שהוגדר על ידי הווידג'ט באתרים אחרים שבהם גם הוא מוטמע. Storage Access API שימושי כאשר ווידג'ט מוטמע של צד שלישי תלוי בשיתוף אותו מידע בין מקורות שונים (לדוגמה, עבור העדפות או פרטי סשנים מחוברים).
  • קבוצות של אתרים קשורים (RWS) הן כלי שמאפשר לארגון להצהיר על קשרים בין אתרים, כדי שדפדפנים יאפשרו גישה מוגבלת לקובצי cookie של צד שלישי למטרות ספציפיות. אתרים עדיין צריכים לבקש גישה באמצעות Storage Access API, אבל לאתרים בקבוצה הזאת ניתן להעניק גישה ללא צורך בהודעות מהמשתמשים.
  • ניהול פרטי כניסה מאוחדים (FedCM) הוא גישה ששומרת על הפרטיות בשירותי זהות מאוחדים. Storage Access API מטפל בגישה לקובצי Cookie לאחר ההתחברות. בתרחישי שימוש מסוימים, FedCM מספק פתרון חלופי ל-Storage Access API, והוא עשוי להיות עדיף כי הוא כולל הנחיית דפדפן יותר מוכוונת התחברות. עם זאת, כדי להשתמש ב-FedCM בדרך כלל נדרשים שינויים נוספים בקוד, למשל, כדי לתמוך בנקודות הקצה ב-HTTP שלו.
  • יש גם ממשקי API למניעת הונאה, לגבי מודעות ומדידה, ו-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);

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

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

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

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

  • אם נעשה שימוש בדף וב-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 בארגז חול

כשמשתמשים ב-Storage Access API במסגרות iframe שבארגז חול, נדרשות ההרשאות הבאות ב-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

תמיכה בדפדפן

  • 119
  • 119
  • 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

משאבים