כדי לצמצם את המעקב באתרים שונים, Chrome מסיר בהדרגה את התמיכה בקובצי Cookie של צד שלישי ובאחסון למחיצות (partitioning). הדבר מהווה אתגר לאתרים ושירותים שמסתמכים על קובצי cookie ואחסון אחר בהקשרים מוטמעים, לצורך התהליכים שעוברים המשתמשים כמו אימות. Storage Access API (SAA) מאפשר לתרחישים לדוגמה האלה להמשיך לפעול, ולהגביל ככל האפשר את המעקב באתרים שונים.
סטטוס הטמעה
Storage Access API זמין בכל הדפדפנים העיקריים אבל יש הבדלים קלים בהטמעה בין הדפדפנים. ההבדלים האלה הודגשו בקטעים הרלוונטיים בפוסט הזה.
אנחנו ממשיכים לעבוד כדי לפתור את כל בעיות החסימה שנותרו לפני ביצוע סטנדרטיזציה של ה-API.
מה זה Storage Access API?
Storage Access API הוא ממשק API של JavaScript שמאפשר לרכיבי iframe לבקש הרשאות גישה לאחסון במקרים שבהם הגדרות הדפדפן סירבו לתת גישה. הטמעות עם תרחישים לדוגמה שתלויים בטעינת משאבים באתרים שונים יכולות להשתמש ב-API כדי לבקש הרשאת גישה מהמשתמש לפי הצורך.
אם בקשת האחסון תאושר, ל-iframe תהיה גישה לאחסון ולקובצי ה-cookie ללא מחיצות. הם יהיו זמינים גם כשמשתמשים ייכנסו לאתר ברמה העליונה.
Storage Access API מאפשר גישה לאחסון ולקובצי cookie ספציפיים ללא מחיצות (Partitions) לגישה לאחסון ולקובצי Cookie מסוימים שלא מחולקים למחיצות
תרחישים לדוגמה
בחלק מההטמעות של צדדים שלישיים נדרשת גישה לאחסון או לקובצי Cookie ללא חלוקה למחיצות כדי לספק למשתמשים חוויה טובה יותר. חלק מההטמעות לא יהיו זמינות כשקובצי Cookie של צד שלישי יוגבלו וחלוקה למחיצות (partitioning) באחסון מופעלת.
התרחישים לדוגמה כוללים:
- ווידג'טים מוטמעים של תגובות שמחייבים פרטים על סשן ההתחברות.
- סימון 'לייק' ברשתות החברתיות לחצנים שמחייבים את פרטי הפעילות באתר.
- מסמכים מוטמעים שמחייבים פרטי סשן התחברות.
- חוויית פרימיום בתשלום שניתנת להטמעת סרטון (לדוגמה, כדי לא להציג מודעות למשתמשים שמחוברים לחשבון, או כדי לדעת מהן העדפות המשתמש לגבי כתוביות או כדי להגביל סוגים מסוימים של סרטונים).
- מערכות תשלום מוטמעות.
רבים מהתרחישים האלה כוללים גישה מתמשכת להתחברות במסגרות iframe מוטמעות.
מתי להשתמש ב-Storage Access API על פני ממשקי API אחרים
Storage Access API הוא אחת החלופות לשימוש באחסון ובקובצי cookie לא מחולקים למחיצות, לכן חשוב להבין מתי להשתמש ב-API הזה בהשוואה לאחרים. היא מיועדת לתרחישים לדוגמה שבהם שני התנאים הבאים מתקיימים:
- המשתמש יקיים אינטראקציה עם התוכן המוטמע – כלומר, זה לא iframe פסיבי או iframe מוסתר.
- המשתמש ביקר במקור המוטמע בהקשר ברמה העליונה – כלומר, כשהמקור הזה לא מוטמע באתר אחר.
יש ממשקי API חלופיים למגוון רחב של תרחישים לדוגמה:
- קובצי Cookie לאחר חלוקה עצמאית למחיצות (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 נגד מניעת הונאות, קשורים למודעות ולמדידה, ו-Storage Access API לא נועד לטפל בבעיות האלה.
שימוש ב-Storage Access API
ל-Storage Access API יש שתי שיטות מבוססות-מובטחות:
Document.hasStorageAccess()
(זמין גם בשם החדשDocument.hasUnpartitionedCookieAccess()
החל מ-Chrome 125)Document.requestStorageAccess()
הוא גם משתלב עם 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 using 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 requestStorageAccess() 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](https://developers.google.com/static/privacy-sandbox/assets/images/storage-access-api-permission-prompt.png?hl=he)
הדפדפן עשוי לדלג על הבקשה ולקבל הרשאה אוטומטית בנסיבות מסוימות:
- אם הדף ו-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 earlier 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') {
// Not used: see https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by earlier tests.
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>
דרישות לגבי קובצי cookie
כדי שאפשר יהיה לגשת אליהם באמצעות Storage Access API ב-Chrome, צריך להגדיר קובצי Cookie של אתרים שונים עם שני המאפיינים הבאים:
SameSite=None
– הנדרש כדי לסמן את קובץ ה-cookie כדרך מספר אתריםSecure
– מבטיח שניתן לגשת רק לקובצי Cookie שהוגדרו על ידי אתרי HTTPS.
ב-Firefox וב-Safari, קובצי ה-cookie מוגדרים כברירת מחדל ל-SameSite=None
, והם לא מגבילים את SAA לקובצי cookie מסוג Secure
ולכן המאפיינים האלה לא נדרשים. מומלץ לציין באופן מפורש את המאפיין SameSite
ולהשתמש תמיד בקובצי cookie של Secure
.
גישה לדף ברמה העליונה
Storage Access API נועד לאפשר גישה לקובצי cookie של צד שלישי במסגרות iframe מוטמעות.
יש גם תרחישים נוספים לדוגמה שבהם הדף ברמה העליונה מחייב גישה לקובצי Cookie של צד שלישי. לדוגמה, תמונות או סקריפטים שמוגבלים על ידי קובצי Cookie, שייתכן שבעלי האתרים ירצו לכלול ישירות במסמך ברמה העליונה במקום ב-iframe. כדי לטפל בתרחיש לדוגמה הזה, Chrome הציע תוסף ל-Storage Access API שמוסיף שיטת requestStorageAccessFor()
.
השיטה requestStorageAccessFor()
השיטה requestStorageAccessFor()
פועלת באופן דומה ל-requestStorageAccess()
, אבל במשאבים ברמה העליונה. ניתן להשתמש בה רק באתרים שנכללים בקבוצת אתרים קשורים כדי למנוע הענקת גישה כללית לקובצי cookie של צד שלישי.
פרטים נוספים על אופן השימוש ב-requestStorageAccessFor()
זמינים בקבוצות של אתרים קשורים: המדריך למפתחים.
השאילתה של ההרשאה top-level-storage-access
תמיכה בדפדפן
בדומה להרשאה storage-access
, יש הרשאת top-level-storage-access
כדי לבדוק אם אפשר להעניק גישה בשביל requestStorageAccessFor()
.
מה ההבדל ב-Storage Access API כשמשתמשים ב-RWS?
כשמשתמשים בקבוצות של אתרים קשורים עם Storage Access API, אפשר להשתמש ביכולות נוספות מסוימות, לפי הפירוט בטבלה הבאה:
ללא RWS | עם RWS | |
---|---|---|
נדרשת תנועת משתמש כדי להפעיל את בקשת הגישה לאחסון | ||
המשתמש נדרש לבקר במקור האחסון המבוקש בהקשר ברמה העליונה לפני הענקת גישה | ||
אפשר לדלג על הודעה למשתמשים בפעם הראשונה | ||
אין צורך לקרוא לאפליקציית requestStorageAccess אם כבר ניתנה גישה בעבר |
||
מעניק גישה אוטומטית לדומיינים אחרים באתר אתר קשור | ||
יש תמיכה במאפיין requestStorageAccessFor בגישה לדף ברמה העליונה |
הדגמה: הגדרה של קובצי 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 מופעל.
משאבים
- כדאי לקרוא את המפרט שמספק גישה לקובצי cookie של צד שלישי, או לעקוב אחר בעיות ולהעלות אותן.
- כדאי לקרוא את המפרט שמספק גישה לאחסון ללא מחיצות, או לעקוב אחרי בעיות ולהעלות אותן.
- מסמכי תיעוד של ה-API ומדריך.
- מסמכי תיעוד של Chrome לגבי השימוש ב-Storage Access API בקבוצות של אתרים קשורים