لتعزيز خصوصية المستخدمين ومكافحة التتبُّع على جميع القنوات على مواقع إلكترونية متعددة، يعزِّل Chrome الآن معظم واجهات برمجة التطبيقات للتخزين والمراسلات في سياقات تابعة لجهات خارجية من خلال عملية تُعرف باسم "تقسيم مساحة التخزين".
حالة التنفيذ
تم تفعيل الميزة لجميع المستخدمين الذين يستخدمون الإصدار 115 من Chrome والإصدارات الأحدث. يتم أيضًا تنفيذ جهود مماثلة لتقسيم مساحة التخزين أو التخطيط لها في المتصفّحات الرئيسية الأخرى، مثل Firefox وSafari. إنّ اقتراح تقسيم مساحة التخزين على GitHub متاح للمناقشة.
ما هو تقسيم مساحة التخزين؟
لمنع أنواع معيّنة من التتبّع على جميع القنوات على مواقع إلكترونية متعددة، يقسّم Chrome واجهات برمجة التطبيقات للتخزين والمراسلات في سياقات تابعة لجهات خارجية.
بدون تقسيم مساحة التخزين، يمكن لموقع إلكتروني دمج البيانات من مواقع إلكترونية مختلفة لتتبُّع المستخدم على الإنترنت. ويسمح أيضًا للموقع الإلكتروني المضمّن باستنتاج حالات معيّنة عن المستخدم في الموقع الإلكتروني من المستوى الأعلى باستخدام تقنيات القناة الجانبية، مثل هجمات التوقيت و XS-Leaks و COSI.
في السابق، كان يتم تصنيف مساحة التخزين حسب المصدر فقط. وهذا يعني أنّه إذا تم تضمين ملف div مضمّن من example.com
في a.com
وb.com
، يمكنه التعرّف على عادات التصفّح في هذين الموقعَين الإلكترونيَين من خلال تخزين معرّف واسترداده بنجاح من مساحة التخزين. عند تفعيل تقسيم مساحة التخزين التابعة لجهات خارجية،
تتوفر مساحة التخزين لتطبيق example.com
في قسمَين مختلفَين، أحدهما لتطبيق a.com
والآخر لتطبيق b.com
.
بشكل عام، يعني التقسيم أنّ البيانات التي تكتبها واجهات برمجة تطبيقات مساحة التخزين، مثل Local Storage وIndexedDB ضمن إطار iframe، لن يعود بإمكان جميع السياقات التي تشترك في المصدر نفسه الوصول إليها. بدلاً من ذلك، أصبحت هذه البيانات الآن معزولة ولا تتوفّر إلا للسياقات التي تتشارك المصدر نفسه والموقع الإلكتروني نفسه من المستوى الأعلى.
تقسيم مساحة التخزين في إطارات iframe المتسلسلة
تزداد تعقيدات تقسيم مساحة التخزين بشكل كبير عند تداخل إطارات iframe، خاصةً عندما يظهر المصدر نفسه عدة مرات ضمن السلسلة.
على سبيل المثال، تحتوي A1 على إطار iframe لصفحة B التي تحتوي على إطار iframe لصفحة A2، ويقع كلا الموقعَين الإلكترونيَين A1 وA2 على الموقع الإلكتروني نفسه. إذا كان التقسيم لا يأخذ في الاعتبار سوى الموقع الإلكتروني من المستوى الأعلى ومصدر الإطار الحالي، قد يتم التعامل مع إطار iframe A2 عن طريق الخطأ على أنّه "طرف أول" لأنّه يشترك في موقع إلكتروني مع المستوى الأعلى (A1)، على الرغم من إطار iframe B المتعدّد المواقع الإلكترونية بين الاثنين. وقد يؤدي ذلك إلى تعريض A2 لمخاطر أمنية، مثل التصيُّد الاحتيالي بالنقر، إذا كان بإمكان A2 الوصول إلى مساحة تخزين غير مُقسَّمة تلقائيًا.
لحلّ هذه المشكلة، يضيف Chrome "بتًا لسلفه" إلى مفتاح قسم التخزين. يتم ضبط هذا العنصر إذا كان أي مستند بين إطار iframe الحالي والموقع الإلكتروني من المستوى الأعلى مصدره مختلفًا (من عدة مواقع إلكترونية). في هذه الحالة، الموقع الإلكتروني "ب" على مستوى الموقع الإلكتروني، لذا سيتم ضبط الإعداد على A2 وسيتم تقسيم مساحة التخزين الخاصة به من A1.
عندما تتألف سلسلة إطار iframe من سياقات الموقع نفسه فقط (على سبيل المثال، الموقع الإلكتروني A1 الذي يحتوي على A2، والذي يحتوي بدوره على A3)، لن تؤدي القطعة الخاصة بالعنصر الرئيسي إلى تقسيم مساحة التخزين بشكل أكبر. وفي هذه الحالات، تظل مساحة التخزين مشتركة، ويتم تحديدها حسب المصدر المشترك والموقع الإلكتروني ذي المستوى الأعلى.
بالنسبة إلى المواقع الإلكترونية التي تحتاج إلى إذن وصول غير مقسّم على مستوى إطارات iframe المتسلسلة، يجري Chrome تجربة على توسيع نطاق واجهة برمجة التطبيقات Storage Access API لتفعيل حالة الاستخدام هذه. بما أنّ واجهة برمجة التطبيقات Storage Access API تتطلّب من الموقع الإلكتروني المُدرَج في إطار أن يستدعي واجهة برمجة التطبيقات صراحةً، فإنّ ذلك يقلل من خطر التصيُّد بالنقر.
تغييرات في واجهة برمجة التطبيقات بسبب التقسيم
يمكن تقسيم واجهات برمجة التطبيقات المتأثرة بالقسمة إلى المجموعات التالية:
واجهات برمجة تطبيقات التخزين
- نظام الحصص
- يُستخدَم نظام الحصص لتحديد مقدار مساحة القرص التي يتم تخصيصها للتخزين. يدير نظام الحصة كل قسم كمجموعة منفصلة لتحديد المساحة المسموح بها ووقت إخلائها.
- تقدّم طريقة
navigator.storage.estimate()
الآن معلومات خاصة بقسم التخزين. تم إيقاف واجهات برمجة التطبيقات المخصّصة لمتصفّح Chrome فقط، مثلwindow.webkitStorageInfo
وnavigator.webkitTemporaryStorage
، نهائيًا.
يستخدم كلّ من - IndexedDB ومساحة تخزين ذاكرة التخزين المؤقت نظام الحصة المقسّمة.
- Web Storage API
- توفّر Web Storage API آليات يمكن للمتصفّحات من خلالها تخزين أزواج المفاتيح والقيم. هناك آليتان: مساحة التخزين المحلية و مساحة تخزين الجلسة. ولا يتم إدارتها من خلال الحصة، ولكن لا يزال يتم تقسيمها.
- نظام الملفات الخاص في Origin
- تسمح واجهة File System Access API للموقع الإلكتروني بقراءة أو حفظ التغييرات مباشرةً في الملفات والمجلدات على الجهاز بعد أن يمنح المستخدم الإذن بالوصول. يتيح نظام الملفات الخاص بمصدر المحتوى تخزين المحتوى الخاص مباشرةً على القرص. وسيظل هذا المحتوى متاحًا للمستخدمين، ولكن تم تقسيمه الآن.
- Storage Bucket API
- يتم تطوير Storage Bucket API لـ Storage Standard الذي يدمج مختلف واجهات برمجة تطبيقات التخزين، مثل IndexedDB وlocalStorage، باستخدام مفهوم جديد يُعرف باسم الحِزم. يتم تقسيم البيانات المخزّنة في الحِزم والبيانات الوصفية المرتبطة بالحِزم.
- عنوان Clear-Site-Data
- يسمح تضمين عنوان
Clear-Site-Data
في الاستجابة للخدمة بطلب محو البيانات المخزّنة في متصفّح المستخدم. يمكن محو ذاكرة التخزين المؤقت وملفات تعريف الارتباط ومساحة التخزين في DOM. يؤدي استخدام العنوان فقط إلى تنظيف مساحة التخزين ضمن قسم واحد.
- متجر عناوين URL للكائنات الثنائية الكبيرة (BLOB)
- يوفر عنوان URL الخاص بملف ثنائي كبير إمكانية الوصول إلى ملف ثنائي كبير، وهو
كائن يحتوي على بيانات أولية. في حال عدم تقسيم مساحة التخزين، يمكن استخدام عنوان 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 لوحدات التخزين المركّبة على مستوى أقسام متعددة معfetch()
أو كقيمة سمةsrc
لعناصر HTML المختلفة. لن يتم حظر عمليات التنقّل على المستوى الأعلى، مثل الاتصال بالرقمwindow.open()
أو النقر على رابط يحتوي علىtarget='_blank'
، إلى عناوين URL الخاصة بالكائنات الثنائية الكبيرة (BLOB) إذا كانت من عدة أقسام، ولكن سيتم فرضnoopener
إذا كان الموقع الإلكتروني لعنوان URL الخاص بالكائنات الثنائية الكبيرة (BLOB) من عدة مواقع إلكترونية بالإضافة إلى الموقع الإلكتروني من المستوى الأعلى للصفحة التي تبدأ التنقّل. يعني فرضnoopener
أنّه سيتم منع المستند الذي يبدأ عملية التنقّل من الحصول على معرّف نافذة لمستند ملفnoopener
عنوان URL الذي فتحه. في المثال السابق، سيؤدي التقسيم إلى منع إطار iframe علىb.com
من جلب محتوى عنوان URL الخاص بالملفّ، ولكن سيظل بإمكانهwindow.open()
ه.
واجهات برمجة تطبيقات التواصل
بالإضافة إلى واجهات برمجة التطبيقات للتخزين، يتم أيضًا تقسيم واجهات برمجة التطبيقات للتواصل التي تسمح لسياق واحد بالتواصل على مستوى حدود المصدر. تؤثر التغييرات بشكل أساسي في واجهات برمجة التطبيقات التي تسمح باكتشاف السياقات الأخرى باستخدام البث أو الربط بنقطة الاتصال ذات المصدر نفسه.
بسبب التقسيم، تمنع واجهات برمجة التطبيقات التالية للمراسلات إطارات iframe التابعة لجهات خارجية من تبادل البيانات مع سياقات المصدر نفسه:
- قناة البث
- تتيح واجهة برمجة التطبيقات Broadcast Channel API التواصل بين سياقات التصفّح (النوافذ أو علامات التبويب أو إطارات iframe) والموظفين من المصدر نفسه.
- لا يُقترَح تغيير سلوك
postMessage()
إطار iframe على مستوى الموقع الإلكتروني، لأنّ العلاقة بين هذه السياقات محدّدة بوضوح.
- SharedWorker
- توفّر واجهة برمجة التطبيقات SharedWorker Worker عنصرًا يمكن الوصول إليه في سياقات التصفّح ذات المصدر نفسه.
- قفل الويب
- تسمح واجهة برمجة التطبيقات Web Locks API للرمز البرمجي الذي يتم تشغيله في علامة تبويب واحدة أو عملية واحدة من النطاق نفسه بالحصول على قفل لمورد مشترَك أثناء تنفيذ بعض المهام.
واجهة برمجة تطبيقات Service Worker
تسمح Service Worker API للمواقع الإلكترونية بتنفيذ المهام في الخلفية. تسجِّل المواقع الإلكترونية مهام الخدمة التي تنشئ سياقات عامل جديدة للردّ على الأحداث. في العادة، كان بإمكان هؤلاء العمال التواصل مع أي سياق من المصدر نفسه. ومع ذلك، بما أنّ مهام الخدمة يمكنها تغيير توقيت طلبات التنقّل، فإنّها تشكل خطرًا بتسريب المعلومات على مستوى الموقع الإلكتروني، مثل التنقّل في السجلّ.
لهذا السبب، تم تقسيم مشغّلات الخدمات المسجّلة من سياق تابع لجهة خارجية.
واجهات برمجة التطبيقات الخاصة بالإضافات
الإضافات هي برامج تسمح للمستخدمين بتعديل تجربة التصفّح.
يمكن تضمين صفحات الإضافات (الصفحات التي تتضمّن مخطّط chrome-extension://
) في
المواقع الإلكترونية على الإنترنت. في هذا السيناريو، يظل بإمكان صفحات الإضافة الوصول إلى
القسم من المستوى الأعلى.
يمكن أيضًا للإضافات تضمين مواقع إلكترونية أخرى، وعند إجراء ذلك، ستتمكّن هذه المواقع الإلكترونية المضمّنة من الوصول إلى القسم من المستوى الأعلى، شرط أن تمتلك الإضافة أذونات المضيف لها.
لمزيد من المعلومات، يُرجى الاطّلاع على مستندات الإضافات.
عرض توضيحي: اختبار تقسيم مساحة التخزين
الموقع الإلكتروني التجريبي: https://storage-partitioning-demo-site-a.glitch.me/

يستخدم العرض التجريبي موقعَين إلكترونيَّين: الموقع "أ" والموقع "ب".
- عند زيارة الموقع الإلكتروني "أ" في سياق المستوى الأعلى، يتم ضبط البيانات باستخدام طرق تخزين مختلفة.
- يضمّن الموقع الإلكتروني "ب" صفحة من الموقع الإلكتروني "أ"، ويحاول هذا التضمين قراءة خيارات التخزين التي تم ضبطها سابقًا.
- عندما يكون الموقع الإلكتروني "أ" مضمّنًا في الموقع الإلكتروني "ب"، لا يمكنه الوصول إلى هذه البيانات عند تقسيم مساحة التخزين، وبالتالي يتعذّر إجراء عمليات القراءة.
- يستخدم العرض الترويجي نجاح أو تعذُّر كل عملية قراءة لعرض ما إذا كانت البيانات مقسّمة.
في الوقت الحالي، يمكنك إيقاف تقسيم مساحة التخزين في Chrome باستخدام --disable-features=ThirdPartyStoragePartitioning
مفتاح سطر الأوامر. ملاحظة: يُستخدَم مفتاح التبديل هذا في سطر الأوامر لأغراض التطوير والاختبار، وقد تتم إزالته أو تغييره في إصدارات Chrome المستقبلية.
يمكنك أيضًا اختبار متصفّحات أخرى بالطريقة نفسها لمعرفة حالة تقسيمها.
التفاعل مع الملاحظات ومشاركتها
- GitHub: يمكنك قراءة الاقتراح الأصلي، وطرح الأسئلة والمشاركة في المناقشة.
- دعم المطوّرين: يمكنك طرح الأسئلة والانضمام إلى المناقشات على مستودع دعم المطوّرين في "مبادرة حماية الخصوصية".
- إرسال تقارير عن الأخطاء: يمكنك إرسال تقرير عن خطأ في نظام تتبُّع Chromium إذا كنت تعتقد أنّ هناك مشكلة لا تعمل على النحو المتوقّع.