חלוקה למחיצות (partitioning) באחסון

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

סטטוס ההטמעה

התכונה הזו מופעלת לכל המשתמשים ב-Chrome מגרסה 115 ואילך. מאמצי חלוקה דומים של נפח האחסון מתבצעים או מתוכננים גם בדפדפנים גדולים אחרים, כמו Firefox ו-Safari. הצעה לחלוקה למחיצות (partitioning) באחסון ב-GitHub פתוחה לדיון נוסף.

מהי חלוקה למחיצות (partitioning) באחסון?

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

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

בעבר, המפתחות של האחסון היו מבוססים רק על המקור. כלומר, אם iframe מ-example.com מוטמע ב-a.com וב-b.com, הוא יכול ללמוד על הרגלי הגלישה שלכם בשני האתרים האלה על ידי שמירת מזהה באחסון ואחזור מוצלח שלו מהאחסון. כשהחלוקה למחיצות (partitioning) באחסון של צד שלישי מופעלת, האחסון של example.com נמצא בשתי מחיצות שונות, אחת ל-a.com והשנייה ל-b.com.

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

לפני

ממשקי API לאחסון ללא חלוקה למחיצות.
לפני חלוקת האחסון, example.com יכול לכתוב נתונים כשהם מוטמעים ב-a.com, ואז לקרוא אותם כשהם מוטמעים ב-b.com.

אחרי

ממשקי API לאחסון עם חלוקה למחיצות.
אחרי חלוקת האחסון, לדומיין example.com, שמוטמע ב-b.com, אין גישה לאחסון של example.com כשהוא מוטמע ב-a.com.

חלוקת האחסון למחיצות במסגרות iframe מקושרות

המורכבות של חלוקת האחסון גדלה באופן משמעותי כשיש עץ של iframes, במיוחד כשאותו מקור מופיע כמה פעמים ברשת.

לדוגמה, הדף A1 מכיל iframe של הדף B, שמכיל iframe של הדף A2, ושני הדפים A1 ו-A2 נמצאים באותו אתר. אם במסגרת חלוקת המשנה נלקחים בחשבון רק האתר ברמה העליונה והמקור של המסגרת הנוכחית, יכול להיות ש-iframe A2 יסווג בטעות כ'צד ראשון' כי הוא משתף אתר עם האתר ברמה העליונה (A1), למרות iframe B ברמת האתר שביניהם. אם ל-A2 תהיה גישה לאחסון ללא מחיצות כברירת מחדל, זה עלול לחשוף את A2 לסיכוני אבטחה כמו clickjacking.

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

כששרשרת iframe מורכבת רק מהקשרים באותו אתר (לדוגמה, אתר A1 שמכיל את A2, שמכיל את A3), הביט של האב לא יחלק את האחסון שלהם לקטעים נוספים. במקרים כאלה, האחסון שלהם יישאר משותף, לפי המפתח של המקור המשותף והאתר ברמה העליונה.

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

שינויים ב-API עקב חלוקה למחיצות

אפשר לחלק את ממשקי ה-API שמושפעים מהחלוקה לקבוצות הבאות:

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

  • מערכת המכסות
    מערכת המכסות משמשת לקביעת נפח האחסון שיוקצה בדיסק. מערכת המכסות מנהלת כל מחיצה בתור קטגוריה נפרדת כדי לקבוע את נפח האחסון המותאם וכדי לנקות את האחסון כשהנפח מגיע למכסה.
    השיטה navigator.storage.estimate() מספקת עכשיו מידע ספציפי למחיצה של האחסון. ממשקי API ל-Chrome בלבד, כמו window.webkitStorageInfo ו-navigator.webkitTemporaryStorage, הוצאו משימוש.
    IndexedDB ו-Cache storage משתמשים במערכת המכסות המחולקת.
  • Web Storage API
    Web Storage API מספק מנגנונים שבאמצעותם דפדפנים יכולים לאחסן צמדי מפתח/ערך. יש שני מנגנונים: אחסון מקומי ואחסון סשן. הן לא מנוהלות לפי מכסות, אבל עדיין מחולקות למחיצות.
  • Origin Private File System
    File System Access API מאפשר לאתר לקרוא או לשמור שינויים ישירות בקבצים ובתיקיות במכשיר אחרי שהמשתמש מעניק גישה. מערכת הקבצים הפרטית של המקור מאפשרת למקור לאחסן תוכן פרטי ישירות בדיסק. המשתמשים עדיין יכולים לגשת לתוכן הזה, אבל הוא מחולק עכשיו למחיצות.
  • Storage Bucket API
    ה-Storage Bucket API מפותח עבור Storage Standard, שמאגד מספר ממשקי API לאחסון, כמו IndexedDB ו-localStorage, באמצעות מושג חדש שנקרא קטגוריות (buckets). הנתונים שמאוחסנים בקטגוריות והמטא-נתונים שמשויכים לקטגוריות מחולקים למחיצות.
  • כותרת Clear-Site-Data
    הכללת הכותרת Clear-Site-Data בתגובה מאפשרת לשרת לבקש לנקות את הנתונים ששמורים בדפדפן של המשתמש. אפשר לנקות את המטמון, קובצי ה-cookie ואת האחסון של DOM. השימוש בכותרת מנקה רק את האחסון במחיצה אחת.
  • מאגר של כתובות URL של blob
    כתובת URL של Blob מספקת גישה לblob, אובייקט שמכיל נתונים גולמיים. בלי חלוקה למחיצות באחסון, אפשר להשתמש בכתובת URL של blob שנוצרה ב-iframe של צד שלישי באתר אחד ב-iframe מאותו מקור שמוטמע באתר אחר. לדוגמה, אם תגי iframe של example.com מוטמעים גם ב-a.com וגם ב-b.com, אפשר להעביר כתובת URL של blob שנוצרה בתג ה-iframe שמוטמע ב-a.com לתג ה-iframe שמוטמע ב-b.com, ואז להשתמש בה בלי הגבלות. החל מגרסת Chrome 137 (שפורסמה ב-27 במאי 2025), כתובות URL של Blob מחולקות לכל השימושים, מלבד ניווטים ברמה העליונה. מקרים שייחסמו מעכשיו כוללים שימוש בכתובות URL של Blob במחיצות שונות עם fetch() או כערך של המאפיין src לרכיבי HTML שונים. ניווטים ברמה העליונה, כמו קריאה ל-window.open() או לחיצה על קישור עם target='_blank', לכתובות URL של Blob לא ייחסמו אם הם מתבצעים במחיצות שונות, אבל noopener יופעל אם האתר של כתובת ה-URL של ה-blob הוא מאתר אחר, ולא מהאתר ברמה העליונה של הדף שהפעיל את הניווט. אם noopener נאכף, לא ניתן יהיה לקבל ידן של חלון עבור מסמך ה-URL של ה-blob שנפתח במסמך שהתחיל את הניווט. בדוגמה הקודמת, חלוקה למחיצות תמנע מה-iframe ב-b.com לאחזר את התוכן של כתובת ה-URL של ה-blob, אבל הוא עדיין יוכל window.open() אותה.

ממשקי API לתקשורת

בנוסף לממשקי API לאחסון, מתבצעת חלוקה למחיצות גם של ממשקי API לתקשורת שמאפשרים להקשר אחד לתקשר מעבר לגבולות המקור. השינויים משפיעים בעיקר על ממשקי API שמאפשרים לזהות הקשרים אחרים באמצעות שידור או מפגש באותו מקור (rendezvous).

בגלל החלוקה למחיצות, ממשקי ה-API הבאים של התקשורת מונעים מ-iframes של צד שלישי להחליף נתונים עם ההקשרים שלהם מאותו מקור:

  • ערוץ שידור
    Broadcast Channel API מאפשר תקשורת בין הקשרי הגלישה (חלונות, כרטיסיות או מסגרות iframe) לבין עובדים מאותו מקור.
    לא מוצע לשנות את ההתנהגות של iframe postMessage() באתרים שונים, כי הקשר בין ההקשרים האלה כבר מוגדר בבירור.
  • SharedWorker
    SharedWorker API מספק עובד שאפשר לגשת אליו בהקשרים שונים של גלישה מאותו מקור.
  • נעילות אינטרנט
    Web Locks API מאפשר לקוד שפועל בכרטיסייה אחת או במכונה עובדת אחת באותו מקור לקבל נעילת משאב משותף בזמן ביצוע עבודה מסוימת.

Service Worker API

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

לכן, קובצי שירות (service workers) שנרשמו מהקשר של צד שלישי מחולקים עכשיו למחיצות.

ממשקי API של תוספים

תוספים הם תוכנות שמאפשרות למשתמשים להתאים אישית את חוויית הגלישה שלהם.

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

מידע נוסף זמין במסמכי העזרה של התוסף.

הדגמה: בדיקת חלוקה למחיצות באחסון

אתר הדגמה: https://storage-partitioning-demo-site-a.glitch.me/

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

הדגמה כוללת שני אתרים: אתר א' ואתר ב'.

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

בשלב הזה, אפשר להשבית את חלוקת האחסון ב-Chrome באמצעות האפשרות בשורת הפקודה --disable-features=ThirdPartyStoragePartitioning. הערה: המתג הזה בשורת הפקודה מיועד למטרות פיתוח ובדיקה, ויכול להיות שהוא יוסר או ישתנה בגרסאות עתידיות של Chrome.

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

בקשה לזמן נוסף להעברה

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

מידע נוסף זמין במאמר חידוש תקופת הניסיון של חלוקה למחיצות (partitioning) באחסון לפני ההוצאה משימוש.

שיתוף משוב ויצירת אינטראקציה