CrispLoginتبديل الحسابات في Chrome
العربية
أضف إلى Chrome أضف إلى Edge

الوكيل على مستوى الحاوية في الإضافة مقابل متصفح مقاوم للبصمة: مساران لعزل الحسابات المتعددة

1752 كلمة آخر تحديث

عزل الحسابات المتعددةالوكيل على مستوى الحاويةمتصفح مقاوم للبصمة

عزل الحسابات المتعددة يسلك أحد مسارين: متصفح مقاوم للبصمة يوهم ببيئة منفصلة على مستوى النواة، وإضافة ذات وكيل على مستوى الحاوية تقسم متصفحًا واحدًا على مستوى الجلسة. الأول يشتري عمق العزل، والثاني يشتري التوازي.

ما الذي يعزله عزل الحسابات المتعددة فعلاً؟ ثلاث طبقات

العزل ليس مفتاحًا، بل ثلاث قدرات لا تحلّ إحداها محل الأخرى — والطبقة الناقصة هي بالضبط التي تظهر في فحص المخاطر الخاطئ.

عزل الجلسة
ملفات تعريف الارتباط وlocalStorage وحالة تسجيل الدخول غير مرئية لبعضها. وهو ما يحدّد ما إذا كانت الحسابات تتسرّب إلى بعضها.
عزل الشبكة
كل حساب يخرج عبر عنوان IP الخاص به، وتبديل مساحة العمل لا ينقل حركة A إلى جلسة B. وهو ما يحدّد ما إذا كانت المنصّة ترى أصلاً واحدًا أم عدة أصول.
عزل البصمة
وكيل المستخدم والمنطقة الزمنية واللغة وCanvas / WebGL / Audio وتعداد الخطوط — السطح المجموع سلبيًا يبقى مستقرًا ومتمايزًا لكل حساب. وهو ما يحدّد عدد الأجهزة التي يُحسب عليها أصل واحد.

هذه الثلاث ليست متساوية في الأهمية: طبقة الجلسة هي الأرضية، وطبقة الشبكة هي حدّ النجاح، وطبقة البصمة هي الخط الفاصل. وللحكم على كفاية مسار ما، اسأل: أي الطبقات ينفّذها داخل حدوده هو — لا هل «يدعم حسابات متعددة».

المسار الأول: المتصفح المقاوم للبصمة يبني العزل داخل النواة

المتصفح المقاوم للبصمة عميل منفصل: كل بيئة تحصل على ملفها التعريفي ومخزن ملفات الارتباط الخاص بها ووكيلها الخاص وبصمة معاد كتابتها. الطبقات الثلاث كلها داخل حدوده، ما يجعله المسار الأعمق بين الاثنين.

التكلفة تأتي من المكان نفسه: كل بيئة هي نسخة متصفح تعمل فعلاً، لذا تنمو الذاكرة خطيًا مع عدد البيئات؛ والترخيص يُحسب عادةً لكل بيئة متزامنة أو لكل مقعد؛ وبعد عدد معيّن تتحوّل تحديثات النواة ومجموعات الوكلاء واتساق قوالب البصمة إلى عمل تشغيلي. وهو يوفّر عادةً واجهة أتمتة أيضًا، لأن عشرات الحسابات لا يمكن تسجيل دخولها ونشرها يدويًا. وما يغطّيه منتج بعينه يعتمد على تنفيذه — راجع وثائقه لا مقال مقارنة.

يجدر الفصل: ملفات التعريف المتعددة المدمجة في Chrome تعزل الجلسات، لكن لا توجد نقطة إدخال وكيل لكل ملف تعريف ولا لقطة لحالة تسجيل الدخول؛ والتبديل يكلّفك نافذة. انظر رابط داخلي: ملفات تعريف Chrome مقابل الحاويات.

المسار الثاني: وكيل على مستوى الحاوية في إضافة — عزل الحسابات المتعددة دون متصفح مقاوم للبصمة

ينتمي CrispLogin إلى هذا المسار: إنه إضافة لـ Chrome / Edge، لا متصفح منفصل. يعمل داخل المتصفح الذي تستخدمه أصلاً، ويستخدم واجهات API المتاحة للإضافة لتقسيم ذلك المتصفح الواحد إلى عدة مساحات عمل معزولة — لكل منها رؤيتها الخاصة لملفات الارتباط وتخزين الموقع، ووكيل خروجها الخاص، ولقطات حالة تسجيل الدخول الخاصة بها.

سلسلة السبب مباشرة. ولأن الحاوية خريطة انتماء تديرها الإضافة بنفسها — تبويب ← حاوية — تُكتب ملفات الارتباط وتخزين الموقع لكل حاوية: الموقع الذي سجّلت الدخول إليه في المساحة A يظهر مسجَّل الخروج عندما تفتحه المساحة B، ومخزنا localStorage لا يرى أحدهما الآخر. ولأن الوكيل مرتبط بالحاوية لا بالمتصفح كله، فإن تبديل المساحة يبدّل عنوان IP الخارج، وهوية الشبكة الخاصة بـ A لا تدخل أبدًا في جلسة B. وهذا أقصى ما يمكن لطبقة الجلسة تقديمه في «عدة حسابات معًا في متصفح واحد».

كيف يستقر وكيل الحاوية فعليًا في Chrome

بدقة: إعدادات الوكيل في Chrome تخصّ ملف تعريف المتصفح لا التبويب، ونص PAC لا يتلقى tabId أبدًا. لذلك يُنفَّذ وكيل الحاوية بإعادة كتابة ذلك الإعداد العام للملف التعريفي عند تغيّر التبويب النشط، بحيث يتساوى خروج التبويب في المقدمة مع خروج حاويته. ما يضمنه هو «أي مساحة تنظر إليها، خروجها فعّال» — لا «عشر مساحات تمرّ كلٌّ منها بنفقه الخاص في الوقت نفسه»، وهو ما يحتاج مكدس شبكة مستقلًا ولا يقدر عليه إلا عميل. الحاويات الأخرى تُحجب بقواعد عند مغادرتها، فلا يختلط خروجان في اللحظة نفسها؛ وتغطية طلبات service worker وWebRTC محدودة وتعتمد على التنفيذ. الإعداد والتشخيص: رابط داخلي: إعداد وكلاء الحاويات وتشخيصها.

لقطات الموقع: تبديل الحساب لم يبقَ يعني تسجيل الدخول من جديد

اللقطة تحفظ حالة تسجيل الدخول لموقع واحد — ملفات الارتباط مضافًا إليها تخزين ذلك الموقع — وتنتمي إلى حاوية. ولأن حالة تسجيل الدخول يمكن حفظها وحدها كلقطة، فإن تبديل الحساب يكلّف اختيارًا واحدًا بدل تسجيل خروج ثم دخول جديد، ولا يحتاج أحد إلى حفظ كلمات المرور في تطبيق ملاحظات. هذا هو الجزء الأكثر عملية في مسار الإضافة في الأعمال متوسطة المخاطر: إنه يخفّض «حسابات متعددة» من «متصفحات متعددة» إلى «مساحات عمل متعددة». الاستخدام: رابط داخلي: حفظ لقطات الموقع واستعادتها.

ما تستطيع الإضافة فعله وما لا تستطيع في طبقة البصمة

في Manifest V3، ما تستطيع الإضافة تغييره هو ترويسات الطلب: يمكن إعادة كتابة وكيل المستخدم وعائلة sec-ch-ua من Client Hints لكل حاوية (declarativeNetRequest modifyHeaders). وما تحت ذلك يتوقف: Canvas وWebGL وAudioContext وتعداد الخطوط تحدث في المُصيّر وفي النواة، ولا تملك الإضافة API لها — تستطيع فقط ترقيع JavaScript الصفحة، وهذا ليس إعادة كتابة على مستوى النواة، وهو قابل للكشف ومرتبط ارتباطًا وثيقًا بإصدار المتصفح. إذن ما تقدّمه الإضافة في طبقة البصمة هو الاتساق — الحاوية نفسها تبدو متطابقة في كل مرة — لا التمويه، حيث تبدو حاويات مختلفة كأجهزة مختلفة. هذا هو الخط الفاصل بين المسارين، ولا ينبغي تعميقه.

المتصفح المقاوم للبصمة مقابل الإضافة: ثمانية أبعاد جنبًا إلى جنب

التحليل أعلاه، مضغوطًا في جدول واحد. كل صف يجيب عن سؤال واحد، والخلاصة في الخلية — بلا «يعتمد على الحالة».

حدود القدرات: وكيل الحاوية في الإضافة مقابل المتصفح المقاوم للبصمة (حتى نوفمبر 2026)
البُعدالمتصفح المقاوم للبصمة (عميل منفصل)وكيل الحاوية في الإضافة (CrispLogin وما شابهها)
طبقة العزلالنواة: نسخة متصفح منفصلة وملف تعريف منفصلالجلسة: ملفات ارتباط وتخزين مرتبطة بالحاوية داخل متصفح واحد
التحكم في البصمةعالٍ: وكيل المستخدم والمنطقة الزمنية واللغة وCanvas / WebGL / Audio والخطوط قابلة للتهيئة كمجموعةمحدود: ترويسات الطلب ووكيل المستخدم قابلة للتغيير؛ أما البصمة على مستوى النواة فلا
دقّة الوكيلوكيل واحد لكل بيئة؛ يمكن تشغيل عدة مخارج معًامرتبط بالحاوية؛ مخرج واحد للمساحة في المقدمة
التوازيعملاء متعددون ونوافذ متعددة؛ البيئات لا تؤثر في بعضهانافذة واحدة وتبويبات كثيرة؛ المساحات تتبدّل فورًا
استهلاك المواردمجموعة عمليات متصفح لكل بيئة؛ الذاكرة تنمو خطيًايعيد استخدام المتصفح المضيف؛ حمل شبه معدوم، وتبويبات أكثر بقليل
التكلفةلكل بيئة متزامنة أو لكل مقعد، مع مجموعة وكلاء وعمل تشغيلياشتراك الإضافة؛ بلا عميل إضافي وبلا تشغيل بيئات
مستوى المخاطر المناسبعالٍ: المنصّة تتحقق من اتساق البصمة بعمقمتوسط: تحكّم بالمخاطر قائم على الجلسة والسلوك وعنوان IP الخارج
الاستخدام النمطيمصفوفات اجتماعية كبيرة، متاجر متعددة عابرة للحدود، أتمتة بالجملةحفنة من الحسابات، تبديل يومي للمساحات، تسجيل متعدد للإعلانات والدعم

حدّ القرار: متى تكفي الإضافة ومتى يلزم عميل

ثلاثة معايير يمكنك تعليمها واحدًا واحدًا. «يعتمد على الحالة» ليس أحدها.

  1. عدد الحسابات والتزامن.نحو عشرة، تُبدَّل عشرات المرات يوميًا: الإضافة كافية. أكثر من ثلاثين وكلها متصلة في الوقت نفسه: تحتاج عميلًا — فتوازي الإضافة تبديل لا تزامن، ولا يوجد إلا مخرج واحد في المقدمة في كل مرة.
  2. ما تعاقب عليه المنصّة فعلاً.إذا ذكرت أسباب الإيقاف بصمات أجهزة مكرّرة أو شذوذات Canvas، فالمنصّة تتحقق من اتساق البصمة، وزوج الجلسة مع المخرج من الإضافة لن يغطّيك. وإذا كانت الإيقافات تتبع عنوان IP وتكرار تسجيل الدخول والسلوك، فالإضافة تغطّي ذلك بالفعل.
  3. هل تحتاج تشغيلًا بلا إشراف.تسجيل الدخول بالجملة والنشر بالجملة والمهام المجدولة تحتاج عميلًا، لأنها تحتاج واجهة أتمتة مستقرة. والإضافات لا تملكها؛ وإن ادّعى منتج ذلك فهو يغطّي طبقة التفاعل فقط.

والاتجاه الآخر مهم أيضًا: ثلاثة حسابات وخمسة تبديلات يوميًا، وتريد فقط فصل لوحة المتجر ووحدة الإعلانات في نافذة واحدة — شراء عميل لكل بيئة من أجل ذلك يقايض تكلفة تشغيلية بعمق عزل لن تستخدمه أبدًا. رابط داخلي: أين يتوقف كفاية المسار الخفيف

ثلاثة مفاهيم خاطئة شائعة

المفهوم الأول: العزل يعني تغيير عنوان IP

عنوان IP هو طبقة الشبكة فقط. عندما لا تكون الجلسات معزولة، يتشارك حسابان ملفات الارتباط في المتصفح نفسه، ولا يمنع أي تدوير للمخرج تسرّبهما إلى بعضهما. افحص الجلسة أولًا، ثم عنوان IP.

المفهوم الثاني: الإضافة تحلّ محل المتصفح المقاوم للبصمة بالكامل

لا تفعل. الإضافة لا تصل إلى البصمة على مستوى النواة ولا توفّر مكدس شبكة مستقلًا؛ وهاتان الحقيقتان تحدّدان سقفها. ما تحلّ محله هو الدافع لشراء عميل فقط لتسجيل الدخول المنفصل — لا العميل نفسه.

المفهوم الثالث: المتصفح المقاوم للبصمة أكثر أمانًا تلقائيًا

إنه يمنح عزلًا أقوى للبيئات، لا أمانًا تشغيليًا أقوى. فكلما زادت البيئات وقلّ اتساق التهيئة، اتّسع سطح الخطأ: قالب بصمة يناقض الموقع الجغرافي للوكيل، أو منطقة زمنية تخالف منطقة عنوان IP، إشارات أعلى صوتًا من الانتظام.

الأسئلة الشائعة

هل تستطيع إضافة أن تحلّ محل متصفح مقاوم للبصمة بالكامل؟

لا. تستطيع الإضافة عزل ملفات الارتباط وتخزين الموقع، وتبديل المخرج لكل حاوية، واستعادة حالة تسجيل الدخول، لكنها لا تستطيع تغيير بصمات على مستوى النواة مثل Canvas أو WebGL، ولا تمرير عدة مساحات عبر أنفاق مختلفة في الوقت نفسه. وإذا كانت المنصّة تتحقق من اتساق البصمة بعمق، فما زلت تحتاج عميلًا. وبالعكس، لعزل الجلسة وعنوان IP فقط، يكون العميل مبالغة.

ما الفرق بين وكيل الحاوية والوكيل العام؟

يعود كله إلى أي شيء يتبع أي شيء. الوكيل العام يمنح المتصفح كله مخرجًا واحدًا تتشاركه كل التبويبات، لذا لا يغيّره تبديل الحساب. ووكيل الحاوية يربط المخرج بمساحة العمل، لذا يبدّل تبديل المساحة المخرج. الأول أبسط لكنه يجعل عدة حسابات تتشارك عنوان IP واحدًا؛ والثاني وحده يمنح كل مساحة أصلها الخاص.

إذا سجّلت الدخول إلى عدة حسابات معًا في متصفح واحد، هل يطرد بعضها بعضًا؟

يعتمد على ما إذا كانت الجلسات معزولة فعلاً. عندما تُفصل ملفات الارتباط وتخزين الموقع لكل حاوية ولا تتشارك الحاويات حالة تسجيل الدخول، يمكن لحسابات النطاق نفسه أن تتعايش. ومساحتان داخل الحاوية نفسها جلسة واحدة، لذا يطرد الدخول اللاحق السابق. والاختبار هو هل يحتفظ الطرفان بملفات ارتباط مستقلة.

دون متصفح مقاوم للبصمة، أين تكمن مخاطر الحسابات المتعددة فعلاً؟

في طبقة البصمة. على جهاز واحد ومتصفح واحد، وحتى مع عناوين IP منفصلة، يبقى السطح المجموع سلبيًا — Canvas والخطوط والمنطقة الزمنية — متطابقًا، والمنصّة التي تُدخل هذه الإشارات في قرارها ستَربط الحسابات. لذلك يناسب مسار الإضافة المنصّات التي يقود تحكّمها بالمخاطر الجلسةُ وعنوان IP، لا تلك التي تعدّ اتساق البصمة متطلبًا صارمًا.

المصادر وتاريخ آخر تحديث

حيثما تمسّ هذه المقالة سلوك واجهات API، فالوثائق الرسمية هي المرجع. حدود قدرات الإضافات تتغيّر مع إصدارات المتصفحات — أعد التحقق قبل أن تقرّر.

آخر تحديث: 8 نوفمبر 2026. أوصاف قدرات منتج بعينه تعكس الإصدار الحالي؛ وحيثما ورد أن شيئًا «يعتمد على التنفيذ»، فأكّده باختبار حقيقي قبل الاختيار.