ב-Chrome 115 הוספנו שינויים לאחסון, לשירותי העבודה ולממשקי ה-API של התקשורת באמצעות חלוקה למחיצות בהקשרים של צד שלישי. בנוסף לבידוד שלהם על ידי מדיניות המקור הזהה, ממשקי ה-API המושפעים שמשמשים בהקשרים של צדדים שלישיים מבודדים גם על ידי האתר של ההקשר ברמה העליונה.
באתרים שלא היה להם זמן להטמיע תמיכה בחלוקה למחיצות של אחסון של צד שלישי, אפשר להשתתף בתקופת ניסיון להוצאה משימוש כדי לבטל את החלוקה למחיצות באופן זמני (להמשיך בבידוד לפי מדיניות של מקור זהה, אבל להסיר את הבידוד לפי אתר ברמה העליונה) ולשחזר את ההתנהגות הקודמת של האחסון, של שירותי העבודה (service workers) ושל ממשקי ה-API לתקשורת, בתוכן שמוטמע באתר. התוקף של תקופת הניסיון להוצאה משימוש יפוג עם השקת Chrome 127 ב-3 בספטמבר 2024. חשוב לשים לב שההחלפה הזו לא קשורה לניסיון ההוצאה משימוש של גישה לקובצי Cookie של צד שלישי: רק לצורך גישה לאחסון.
כפתרון לטווח ארוך לטיפול בתרחישים מסוימים של שימוש שנפגעו כתוצאה מהחלוקה למחיצות של אחסון של צד שלישי שאינו קובץ cookie, אנחנו ב-Chrome מציעים לאפשר לצדדים שלישיים לבקש גישה לאחסון או לתקשורת (גם קובצי cookie וגם לא קובצי cookie) דרך Storage Access API (מופעל החל מגרסה 117 של Chrome), שכבר מאפשר לצדדים שלישיים לבקש גישה לקובצי cookie.
החל מגרסה 120 של Chrome, ההצעה הזו תהיה זמינה לניסוי באמצעות גרסת מקור לניסיון. המפתחים צריכים להשתתף בגרסת המקור לניסיון כדי להעריך איך הפתרון המוצע עונה על תרחישי השימוש שלהם, כדי לוודא שהם מוכנים לפני סיום תקופת הניסיון של ההוצאה משימוש.
פרטים על גרסת המקור לניסיון
החל מגרסת Chrome 120, Chrome יתמוך בגרסת מקור לניסיון, StorageAccessAPIBeyondCookies, כדי לאפשר את ההרחבה המוצעת של Storage Access API (תואמת לאחור) כדי לאפשר גישה לאחסון ללא מחיצות (קובצי cookie ולא קובצי cookie) בהקשר של צד שלישי.
מכניקה
אפשר להשתמש ב-API באופן הבא (JavaScript שפועל ב-iframe מוטמע):
// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);
אם אתם רוצים רק גישה ל-API ספציפי ולא גישה ל-all
, תוכלו להעביר את השמות של מזהי ה-API הנחוצים לכם בלבד. לדוגמה, אפשר להעביר את הערך {sessionStorage: true}
כדי לקבל גישה רק ל-Session Storage, או את הערך {indexedDB: true, locks:true}
כדי לקבל גישה ל-IndexedDB ולנעילות אינטרנט.
מעבר לקריאה לתוסף הנוסף הזה, הגישה לאחסון ללא קובצי cookie תתאים לדרישות הנוכחיות לגבי גישה לקובצי cookie דרך Storage Access API. לדוגמה, ב-Chrome לא מוצגת הודעה כשהמקורות נמצאים באותה קבוצת אתרים קשורים (RWS, השם החדש של 'דומיינים של צד ראשון'). מקורות שהם לא חלק מאותו RWS יהיו כפופים לדרישות השליחה של Storage Access API ב-Chrome.
משך
גרסת המקור לניסיון תהיה זמינה מ-Chrome 120 עד גרסה 125 של Chrome (או אחרי 6 באוגוסט 2024 בכל ציון דרך).
היקף
רק DOM Storage (אחסון סשן ואחסון מקומי), Indexed DB ומנעולים לאינטרנט זמינים ב-Chrome 120.
האחסון המטמון, מערכת הקבצים הפרטיים המקורית, מכסה, אחסון Blob וערוץ שידור נוספו ב-Chrome 121.
עובדים משותפים ושליטה על הכללת קובצי cookie נוספו ב-Chrome 123.
עובדים ייעודיים יורשים גישה לקובצי cookie שלא חולקו למחיצות אם requestStorageAccess
הופעל לפני יצירת העובד החל מגרסה 120 של Chrome (לא נדרש שימוש בכינוי של Storage Access API).
השתתף
- תעריכו את השימוש שלכם בקובצי Cookie ובאחסון שאינו קובצי Cookie בהקשר של צד שלישי. התרחישים לדוגמה יכולים לעזור לכם להבין אם ההצעה הזו מתאימה לצרכים שלכם.
- פותחים את Chrome בגרסה 120 (או גרסה מתקדמת יותר) ומוודאים שהדגל test-third-party-cookie-phaseout מופעל.
- אם רוצים לבדוק את התכונה באופן מקומי בלי להגדיר קודם אסימון ניסיון למקור, אפשר להפעיל את #enable-experimental-web-platform-features בדפדפן.
- אחרי שתסיימו את הבדיקה המקומית, תוכלו להירשם לתקופת הניסיון של StorageAccessAPIBeyondCookies במקור ולקבל אסימון לדומיינים שלכם. הוראות מפורטות יותר זמינות במאמר תחילת העבודה עם גרסאות מקור לניסיון. במדריך לפתרון בעיות בגרסת הטרום-השקה של Chrome לאתרים מופיעה רשימת משימות מלאה שתעזור לכם לוודא שהאסימון מוגדר בצורה נכונה.
- מטמיעים את אסימון הניסיון של המקור ב-iframe שבו צריך להשתמש במזהה של Storage Access API, באמצעות כותרת HTTP, תג מטא של HTML או באופן פרוגרמטי. הערה: האסימון צריך להיות מוטמע בכל מסגרת שבה רוצים להשתמש ב-API הזה. הטמעה שלו במסגרת ההורה לא תפעיל את ה-API במסגרות צאצא.
- קוראים ל-
document.requestStorageAccess(...)
כדי לקבל את ה-handle של Storage Access API ב-iframe באתרים שונים. במסמכי העזרה של Storage Access API מפורטות הדרישות להצלחת הקריאה הזו. - מעבירים את האחסון שקשור ל-iframe כדי להשתמש בכינוי Storage Access API אם הוא זמין. לדוגמה, קריאות ל-
window.sessionStorage.setItem(...)
הופכות ל-handle.sessionStorage.setItem(...)
. - פותחים את האתר ומוודאים שהמפתח לגישה לאחסון פועל כצפוי.
- כדי להפסיק את ההשתתפות בגרסת הניסיון המקורית, מסירים את האסימון שהוספתם בשלב 3.
- אתם יכולים לשלוח משוב או לדווח על בעיות במאגר GitHub של Storage Access API ללא אחסון קובצי Cookie.
הדגמה: שימוש ב-Storage Access API כדי לגשת לאחסון מקומי ללא מחיצות
בדמו הבא מוצג איך לגשת לערוצי שידור ללא חלוקה למחיצות מ-iframe של צד שלישי באמצעות Storage Access API:
https://saa-beyond-cookies.glitch.me/
כדי להפעיל את הדמו, צריך להשתמש ב-Chrome מגרסה 121 ואילך עם הדגל test-third-party-cookie-phaseout מופעל.