ב-Chrome 115 הוספנו שינויים לאחסון, לשירותי העבודה ולממשקי ה-API של התקשורת באמצעות חלוקה למחיצות בהקשרים של צד שלישי. בנוסף לבידוד שלהם על ידי מדיניות המקור הזהה, ממשקי ה-API המושפעים שמשמשים בהקשרים של צדדים שלישיים מבודדים גם על ידי האתר של ההקשר ברמה העליונה.
באתרים שלא היה להם זמן להטמיע תמיכה בחלוקה למחיצות באחסון של צד שלישי, אפשר להשתתף בתקופת ניסיון להוצאה משימוש כדי לבטל את החלוקה למחיצות באופן זמני (להמשיך בבידוד לפי מדיניות של מקור זהה, אבל להסיר את הבידוד לפי אתר ברמה העליונה) ולשחזר את ההתנהגות הקודמת של האחסון, של שירותי העבודה (service workers) ושל ממשקי ה-API לתקשורת, בתוכן שמוטמע באתר. התוקף של תקופת הניסיון להוצאה משימוש יפוג עם השקת Chrome 127 ב-3 בספטמבר 2024. חשוב לזכור שהבדיקה הזו היא בנפרד מהבדיקה בתקופת ההוצאה משימוש לגישה לקובצי Cookie של צד שלישי: היא מיועדת רק לגישה לאחסון.
כפתרון לטווח ארוך לטיפול בתרחישים מסוימים של שימוש שנפגעו כתוצאה מהחלוקה למחיצות של אחסון של צד שלישי שאינו קובץ cookie, אנחנו ב-Chrome מציעים לאפשר לצדדים שלישיים לבקש גישה לאחסון או לתקשורת (גם קובצי cookie וגם לא קובצי cookie) דרך Storage Access API (מופעל החל מגרסה 117 של Chrome), שכבר מאפשר לצדדים שלישיים לבקש גישה לקובצי cookie.
החל מגרסה 120 של 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.
משך
גרסת המקור לניסיון תהיה זמינה מגרסה 120 של Chrome ועד גרסה 125 של Chrome (או אחרי 6 באוגוסט 2024 בכל שלב משמעותי).
היקף
רק DOM Storage (אחסון סשן ואחסון מקומי), Indexed DB ומנעולים לאינטרנט זמינים ב-Chrome 120.
מאגרי מטמון, מערכת קבצים פרטית של מקור, מכסה, אחסון Blob וערוץ שידור נוספו ב-Chrome 121.
Shared Workers ושליטה על הכללת קובצי 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 ל-origin ולקבל אסימון לדומיינים שלכם. להוראות מפורטות יותר, אפשר לעיין במאמר תחילת העבודה עם ניסויים במקור. במדריך לפתרון בעיות בגרסת הטרום-השקה של Chrome לאתרים מופיעה רשימת משימות מלאה שתעזור לכם לוודא שהאסימון מוגדר בצורה נכונה.
- מטמיעים את אסימון הניסיון של המקור ב-iframe שבו צריך להשתמש במזהה של Storage Access API, באמצעות כותרת HTTP, תג מטא של HTML או באופן פרוגרמטי. חשוב לזכור שכל פריים שרוצים להשתמש ב-API הזה צריך להטמיע את האסימון. הטמעה שלו בפריים ההורה לא תפעיל את ה-API בפריימים הצאצאים.
- קוראים ל-
document.requestStorageAccess(...)
כדי לקבל את ה-handle של Storage Access API ב-iframe באתרים שונים. במסמכי העזרה של Storage Access API מפורטות הדרישות להצלחת הקריאה הזו. - אם ה-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.