عدة مساحات عمل معزولة داخل نافذة Chrome واحدة: كيف يعمل ذلك تقنيًا
العزل داخل نافذة واحدة هو ثلاث طبقات متراكبة: الجلسة والتخزين، وتوجيه الشبكة، وإدارة دورة الحياة. ليس محاكاة افتراضية للنواة، ولا يغيّر البصمة.
لماذا لا يعني فتح نوافذ إضافية وجود عدة حسابات مسجّلة في الوقت نفسه
لنبدأ بتفكيك حدس شائع: النافذة ليست وحدة عزل. عشر نوافذ داخل الملف الشخصي نفسه تتشارك مخزن كوكيز واحدًا وlocalStorage واحدًا وذاكرة HTTP واحدة، والموقع يرى جلسة واحدة. وضع التصفح المتخفي يمتلك مخزنًا مستقلًا فعلًا، لكنه واحد فقط وينتهي بإغلاق النافذة، فلا يكفي لعشرة حسابات. الوحدة الحقيقية هي حاوية الجلسة: مجموعة كوكيز مستقلة، ومساحة أسماء تخزين مستقلة، وخريطة انتماء ثابتة. لا يملك Chrome واجهة برمجة للحاويات — الاستثناء هو contextualIdentities في Firefox — لذلك يبنيها الامتداد بنفسه على مستوى الجلسة: يسجّل أي علامة تبويب تنتمي إلى أي حاوية، ثم يوزّع الطلبات وتخزين الصفحة وفق تلك الخريطة. يعمل CrispLogin بهذه الطريقة: الحاوية سجل انتماء يحتفظ به الامتداد، وليست عنصرًا أصليًا في Chrome. وحدة العزل هي الجلسة لا العملية.
الطبقة الأولى: لماذا لا تختلط ملفات تعريف الارتباط
تبقى الحسابات منفصلة بفضل جرة كوكيز افتراضية وإعادة كتابة ترويسة الطلب على مستوى علامة التبويب. يحتفظ كل حاوية داخل الامتداد بسجلات الكوكيز الخاصة بها. قبل خروج الطلب، تطابق قاعدة session rule في declarativeNetRequest علامة التبويب عبر condition.tabIds وتضبط ترويسة cookie بالكامل على قيمة تلك الحاوية؛ وعند وصول الاستجابة يراقب webRequest الترويسة Set-Cookie ويكتبها في الجرة المطابقة. وعلى الجرة أن ترتّب الكوكيز حسب طول المسار ثم وقت الإنشاء قبل التسلسل، وإلا لن تطابق الترويسة ما كان المتصفح سيرسله بنفسه.
ما يغيب عن الانتباه عادة هو العمر: tabIds يعمل فقط في قواعد session، وهذه القواعد تُمسح عند إغلاق المتصفح وعند تحديث الامتداد. لذلك يجب إعادة تثبيت القواعد عند كل تشغيل؛ وإغفال ذلك يظهر كعَرَض «بعد إعادة التشغيل كل مساحات العمل صارت الحساب نفسه». تخزين الصفحة وجه آخر: document.cookie يقرأ مخزن الكوكيز الحقيقي، وlocalStorage له مساحة أسماء واحدة، لذا يحتاج سكربت في MAIN world إلى توسيط القراءة والكتابة لكل حاوية. هذا عزل على مستوى التطبيق: يفصل حسابين على الموقع نفسه، لكنه لا يمس بصمة النواة.
الطبقة الثانية: كيف يتبع الوكيل مساحة العمل
لا يملك Chrome واجهة برمجة لتعيين وكيل لكل علامة تبويب. نطاق chrome.proxy.settings هو الملف الشخصي بأكمله، ودالة FindProxyForURL(url, host) في سكربت PAC لا تستقبل tabId أبدًا؛ وdeclarativeNetRequest يستطيع إعادة كتابة الترويسات وإعادة التوجيه، لكن ليست لديه عملية «اختيار وكيل أعلى». ما يستطيعه الامتداد هو الاحتفاظ بخريطة مساحة العمل ← منفذ الخروج، وإعادة كتابة هذا الإعداد العام عند تغيّر علامة التبويب في المقدمة.
يستطيع PAC الفصل حسب النطاق، لكن مدخله هو الرابط لا علامة التبويب: الموقع نفسه المفتوح في مساحتين يحصل على إجابة واحدة من PAC. لذلك فإن «عشر مساحات عمل كل واحدة في نفقها الخاص» غير قائم في الامتداد؛ المضمون هو «أي مساحة عمل في المقدمة فمنفذ الخروج منفذها». ومن هنا أيضًا إعادة الاتصال التي تُرى عند تبديل مساحة العمل: بتغيّر إعداد الوكيل تُعاد الاتصالات القائمة. الحد: هذه الطبقة تستبدل عنوان IP الخارجي ومسار الطلب، لا بصمة TCP/TLS (JA3/JA4)؛ ويمكن تقييد WebRTC عبر chrome.privacy.network.webRTCIPHandlingPolicy لإسقاط UDP غير المار عبر الوكيل، لكن ذلك سياسة للمتصفح كله لا لكل مساحة عمل.
الطبقة الثالثة: هل يصمد الارتباط بعد إغلاق التبويب أو إعادة التشغيل
خلفية MV3 هي service worker: ثلاثون ثانية بلا حدث ويُنهى، حاملًا معه متغيرات الوحدة وأي Map داخل إغلاق. لذلك لا يمكن أن يقيم «أي تبويب ينتمي إلى أي مساحة عمل» في الذاكرة، بل يذهب إلى chrome.storage.session، وهي تبقى في الذاكرة ما دام الامتداد محمّلًا وتصمد عند إعادة تدوير العامل، لكنها تُمسح عند إعادة تشغيل المتصفح. وانتبه: هي غير متاحة لسكربتات المحتوى افتراضيًا؛ فإن احتاج جانب الصفحة قراءة الارتباط وجب استدعاء setAccessLevel صراحةً.
بهذا تنقسم البيانات إلى نوعين: ارتباطات وقت التشغيل في session، وكل ما يجب أن يعبر إعادة التشغيل — قائمة المساحات، وإعداد الوكيل، وفهرس اللقطات — في storage.local. سلسلة السبب مباشرة: لأن الارتباط في session لا في متغيّر، يعرف الامتداد بعد استيقاظ العامل انتماء كل تبويب، ولا يسكب كوكيز مساحة عمل في صفحة أخرى. أما لو بقي في الذاكرة وحدها، فلحظة نوم العامل لا يجد الطلب التالي مالكًا يسأله، ويظهر ذلك كمجموعات مكررة ولقطات تُستعاد في الحاوية الخطأ.
الطبقة الرابعة: ماذا تحفظ لقطة الموقع وماذا تستعيد
تجيب اللقطة عن سؤال آخر: قابلية نقل حالة تسجيل الدخول، لا العزل أثناء التشغيل. وهي الرابعة في القائمة لكنها ليست جزءًا من العزل نفسه. تُسلسل كوكيز موقع واحد داخل حاوية واحدة مع تخزين ذلك الموقع، وعند الاستعادة تسكبها في مساحة أسماء تلك الحاوية. والاثنان متعامدان: العزل يمنع مساحتين من إزعاج إحداهما الأخرى ما دامتا موجودتين، واللقطة تُغني عن تسجيل الدخول من جديد. والوحدة هي الموقع لا المتصفح: موقعان في حاوية واحدة سجلان لا علاقة بينهما.
لذلك يجب أن تنتمي اللقطة إلى حاوية — سكب حالة A في B يدمج حسابين في حساب واحد. ولا يقل أهمية أن نقول ما لا تفعله: تستعيد حالة الجلسة على مستوى التطبيق، لا بصمة على مستوى النواة، ولا تَعِد بتجاوز ضوابط المخاطر أو التحقق من الجهاز لدى منصة ما. الاستخدام: رابط داخلي: الاستخدام العملي للقطات المواقع.
ما الفرق بين هذا وبين فتح عدة ملفات شخصية
تعدد الملفات الشخصية في Chrome قطع مادي على مستوى الدليل الجذري للتخزين: لكل ملف مخزن كوكيز وتخزين وامتدادات وذاكرة تخزين مؤقت خاصة به، فالعزل كامل. وتظهر التكلفة على أربعة محاور: الذاكرة، لأن لكل ملف سياق شبكة وعمليات عرض خاصة، فثلاثة ملفات تعني نحو ثلاثة أضعاف الكلفة الدائمة؛ والعمليات، لأن أشجار العمليات منفصلة؛ والنوافذ، لأن الملف الواحد نافذة واحدة والتبديل يعني تبديل نافذة؛ والبصمة، لأن الملفات تتشارك النواة والجهاز نفسه، فـ UA وCanvas والخطوط متطابقة افتراضيًا. وهناك كلفة أهدأ: الإشارات والامتدادات والسجل لا تُشارك، فبعد الملف الثالث يبدأ كل ملف بالانحراف.
طريق الامتداد يعكس ذلك: ملف شخصي واحد، نافذة واحدة، عمليات ونواة مشتركة، مقابل التوازي في نافذة واحدة بكلفة إضافية تقارب الصفر — والثمن هو عدم الوصول إلى طبقة بصمة النواة. ليسا درجتين من الشيء نفسه، بل طريقتين مختلفتين لقطع دقة العزل. والمقارنة التفصيلية في رابط داخلي: ملفات Chrome الشخصية مقابل عزل الامتداد.
حدود القدرة: أي طبقات يغطيها الامتداد وأيها لا
الحدود السابقة مضغوطة في جدول واحد. تُقرأ بسؤال «ما الذي تفحصه المنصة»: للجلسة ومنفذ الخروج العمود الأوسط، ولتناسق البصمة العمود الأيمن. ويجدر التكرار: الامتداد يقوم بعزل على مستوى الجلسة، وليس بالدرجة نفسها التي يقدمها متصفح البصمة؛ واعتباره «متصفح بصمة أخف» قراءة خاطئة للمخاطر.
| الطبقة | ما يغطيه الامتداد | ما لا يُدرك، أو الثمن |
|---|---|---|
| الكوكيز وحالة الدخول | مفصولة لكل حاوية، وقابلة للتسلسل في لقطة | النواة لا تعرف الحاويات؛ الترويسات تُعاد كتابتها، وفقدان القواعد يعني اختلاط الحسابات |
| تخزين الصفحة | يمكن إضافة بادئة لـ localStorage وIndexedDB أو توسيطها لكل حاوية | service worker وSharedWorker والسياقات المنفصلة الأخرى تحتاج تغطية خاصة |
| عنوان IP الخارجي | مرتبط بمساحة العمل؛ تغيير المقدمة يغيّر منفذ الخروج | منفذ خروج واحد في المقدمة في كل لحظة؛ لا أنفاق متوازية |
| WebRTC | يمكن إسقاط UDP غير المار عبر الوكيل (سياسة للمتصفح كله) | ليست لكل مساحة عمل؛ وقد تتجاوز مسارات الوسائط الوكيل |
| بصمة TLS | لا شيء | JA3/JA4 تحددهما النواة ومكدس الشبكة |
| Canvas / WebGL / Audio | لا شيء | العرض يحدث في النواة؛ ولا واجهة لإعادة كتابته |
| تعداد الخطوط | لا شيء | تصحيح JavaScript في الصفحة فقط، وهو قابل للكشف |
| ذاكرة HTTP المؤقتة | لا شيء | الذاكرة على مستوى الملف الشخصي ومشتركة بين الحاويات |
يبين الجدول أيضًا موضع السقف: ما يستبدله الامتداد هو دافع شراء عميل لمجرد تسجيل الدخول منفصلًا، لا العميل نفسه. وأي الطريقين تختار سؤال آخر، مقارن بندًا بندًا في رابط داخلي: الامتداد مقابل متصفح البصمة.
الأسئلة الشائعة
هل عزل الكوكيز الذي يقوم به الامتداد هو نفسه Partitioned Cookie في Chrome؟
لا. تُفتح Partitioned Cookie على الموقع الأعلى مستوى، فيكون للموقع جرة واحدة لكل صفحة عليا؛ وpartitionKey في واجهة cookies ليس إلا المفتاح لقراءة هذه الكوكيز وكتابتها، ومكوّنه الوحيد topLevelSite، ولا يمكن به اختراع أقسام جديدة. جرة مساحة العمل مفصولة لكل حاوية، وللموقع الواحد أي عدد منها، والامتداد هو من يمسك الدفاتر. الأول تقسيم خصوصية في المتصفح، والثاني تجريد جلسة على مستوى الامتداد.
هل تبقى حالة مساحة العمل بعد إغلاق علامة التبويب؟
ثلاث حالات. اختفت علامة التبويب فذهب الارتباط معها. تعريفات مساحة العمل — الاسم والوكيل وفهرس اللقطات — بيانات يجب أن تعبر إعادة التشغيل وتوضع عادة في storage.local. أما حالة الدخول فلا تُستعاد إلا إذا حفظت لقطة، وإلا فعليك تسجيل الدخول من جديد. وما في storage.session يُمسح عند إغلاق المتصفح، فلا تعامله كطبقة دائمة.
هل يؤثر أسلوب النافذة الواحدة على أداء المتصفح؟
الزيادة تأتي من علامات التبويب لا من العزل. لا يُشغَّل متصفح ثانٍ ولا تُنسخ النواة؛ والكلفة هي مطابقة القواعد وإعادة كتابة الترويسات، وهي مقدار ثابت لكل طلب. الكلفة الحقيقية في عدد التبويبات وفي الصفحات نفسها: مع عشرين مساحة عمل يتعثر العرض لا طبقة العزل.
هل يمكن لمساحتي عمل استخدام عنوانَي IP خارجيين مختلفين في الوقت نفسه؟
لا. إعداد الوكيل على مستوى الملف الشخصي، ولا يستطيع الامتداد إعادة كتابته إلا عند تبديل علامة التبويب، لذا في أي لحظة لا تستخدم منفذ خروجها إلا مساحة العمل في المقدمة؛ أما الخلفية فتُحجب بالقواعد أو تخرج مباشرة. الأنفاق المتوازية الحقيقية تحتاج عميلًا يملك مكدس شبكة مستقلًا.
المصادر وآخر تحديث
حيثما تطرق المقال إلى سلوك واجهات البرمجة فالحكم للوثائق الرسمية. وحدود قدرات الامتداد تتغيّر مع إصدارات Chrome، فراجعها قبل التبني.
- Chrome for Developers، chrome.declarativeNetRequest — عمر قواعد session، ونطاق condition.tabIds، وmodifyHeaders على ترويسة cookie: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers، chrome.storage — منطقة session تقيم في الذاكرة، وتُمسح عند إعادة تشغيل المتصفح، وغير متاحة لسكربتات المحتوى افتراضيًا: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers، chrome.cookies — partitionKey ودلالة المفتاح في Partitioned Cookie (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers، chrome.proxy — إعدادات الوكيل تنطبق على الملف الشخصي كله، وPAC لا يستقبل إلا الرابط والمضيف: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers، The extension service worker lifecycle — الإنهاء بعد ثلاثين ثانية خمول، وضياع المتغيرات العامة مع العامل: developer.chrome.com/…/service-workers/lifecycle
آخر تحديث: 11 نوفمبر 2026. ما ورد هنا هو المسار العام للتنفيذ في هذه الفئة من الامتدادات؛ وقد تختلف واجهات البرمجة وموضع تخزين البيانات من منتج لآخر، وداخليات أي منتج تحكمها وثائقه الخاصة.