כדי לשפר את פרטיות המשתמשים ולמנוע מעקב באתרים שונים בערוצים צדדיים, Chrome מבודד עכשיו את רוב ממשקי ה-API של האחסון והתקשורת בהקשרים של צד שלישי באמצעות תהליך שנקרא חלוקה למחיצות (partitioning) באחסון.
סטטוס ההטמעה
התכונה הופעל לכל המשתמשים ב-Chrome מגרסה 115 ואילך. מאמצי חלוקה דומים של נפח האחסון מתבצעים או מתוכננים גם בדפדפנים גדולים אחרים, כמו Firefox ו-Safari. הצעה לחלוקה למחיצות (partitioning) באחסון ב-GitHub פתוחה לדיון נוסף.
מהי חלוקה למחיצות (partitioning) באחסון?
כדי למנוע סוגים מסוימים של מעקב באתרים שונים בערוצים צדדיים, Chrome מחלק את ממשקי ה-API של האחסון והתקשורת בהקשרים של צד שלישי.
בלי חלוקת אחסון, אתר יכול לצרף נתונים מאתרים שונים כדי לעקוב אחרי המשתמש באינטרנט. בנוסף, הוא מאפשר לאתר המוטמע להסיק מצבים ספציפיים לגבי המשתמש באתר ברמה העליונה באמצעות שיטות של ערוץ צדדי, כמו התקפות תזמון, XS-Leaks ו-COSI.
בעבר, המפתחות של האחסון היו מבוססים רק על המקור. כלומר, אם תוטמע ב-a.com וב-b.com תצוגת iframe מ-example.com, היא תוכל ללמוד על הרגלי הגלישה שלכם בשני האתרים האלה על ידי שמירת מזהה באחסון ואחזור מוצלח שלו מהאחסון. כשהחלוקה למחיצות (partitioning) באחסון של צד שלישי מופעלת, האחסון של example.com נמצא בשתי מחיצות שונות, אחת ל-a.com והשנייה ל-b.com.
באופן כללי, חלוקה למחיצות מאפשרת לממשקי API לאחסון, כמו Local Storage ו-IndexedDB, לכתוב נתונים בתוך iframe, אבל לא ניתן יותר לגשת לנתונים האלה מכל ההקשרים שיש להם את אותו מקור. במקום זאת, הנתונים האלה מבודדים עכשיו וזמינים רק להקשרים שיש להם את אותו מקור ואת אותו אתר ברמה העליונה.
לפני
אחרי
חלוקת האחסון למחיצות במסגרות 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, באמצעות מושג חדש שנקרא קטגוריות. הנתונים שמאוחסנים בקטגוריות והמטא-נתונים שמשויכים לקטגוריות מחולקים למחיצות.
- כותרת 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/
הדגמה כוללת שני אתרים: אתר א' ואתר ב'.
- כשאתם מבקרים באתר א' בהקשר ברמת העליונה, המערכת מגדירה נתונים באמצעות שיטות אחסון שונות.
- אתר ב' מוטמע בו דף מאתר א', וההטמעה הזו מנסה לקרוא את אפשרויות האחסון שהוגדרו קודם.
- כשאתר א' מוטמע באתר ב', אין לו גישה לנתונים האלה כשהאחסון מחולק למחיצות, ולכן הקריאות נכשלות.
- הדגמה משתמשת בהצלחה או בכישלון של כל קריאה כדי להראות אם הנתונים מחולקים למחיצות.
בשלב הזה, אפשר להשבית את חלוקת האחסון ב-Chrome באמצעות האפשרות בשורת הפקודה --disable-features=ThirdPartyStoragePartitioning. הערה: המתג הזה בשורת הפקודה מיועד למטרות פיתוח ובדיקה, ויכול להיות שהוא יוסר או ישתנה בגרסאות עתידיות של Chrome.
אפשר גם לבדוק דפדפנים אחרים באותו אופן כדי לראות את סטטוס המחיצות שלהם.
שיתוף משוב ויצירת אינטראקציה
- GitHub: קוראים את ההצעה המקורית, שואלים שאלות ומשתתפים בדיון.
- תמיכה למפתחים: אפשר לשאול שאלות ולהצטרף לדיוני המאגר של תמיכת המפתחים של ארגז החול לפרטיות.
- דיווח על באגים: אם לדעתכם משהו לא פועל כמצופה, תוכלו לדווח על באג בכלי המעקב של Chromium.