مراجعة كاملة لحادثة ترتيب إشارات Chrome المرجعية: لماذا ضاعت هذه المرة حالة تسجيل الدخول وحالة الإضافات معًا

[coco]

هذا توثيق كامل للحادثة أتركه لنفسي للأرشفة.

الخلفية

وقعت هذه الحادثة بعد أن طلبت من Codex مساعدتي في ترتيب إشارات Chrome المرجعية. في البداية كان حدسي: هل بدّلت الـ profile بالخطأ، أو استبدلت مجلد إعدادات Chrome بالكامل بشكل خاطئ؟ لاحقًا قارنت ميتاداتا الـ profile على الجهاز، وملفات قواعد البيانات الأساسية، ولقطة الحادثة، وكذلك سجل جلسة Codex سطرًا بسطر، والنتيجة يمكن الجزم بها.

الخلاصة المباشرة

ليس تبديلًا خاطئًا للـ profile، ولا كان الانتقال إلى profile جديد وفارغ.

سبب المشكلة الحقيقي هو: أنني جعلت Codex يعدّل مباشرة ملف الإشارات المرجعية الخاص بالـ Default وهو قيد الاستخدام (live)، ثم واصلت إعادة التنظيم/الاستعادة على نفس الـ profile الحي، فدخل هذا الـ profile القديم في حالة Crashed. ملفات تعريف الارتباط (cookie) الخاصة بتسجيل الدخول، وحالات تسجيل الدخول للمواقع، وحالة تشغيل الإضافات—كلها تعطّلت خلال هذه العملية.

نسخة بجملة واحدة: ليست “محتويات الإشارات المرجعية غطّت على الـ cookie”، بل “الكتابة في مكانها داخل Chrome profile وهو يعمل + إغلاق غير طبيعي/استعادة بعد انهيار، دمّر قواعد بيانات الحالة المحلية لنفس الـ profile القديم”.

الأدلة الأساسية

1. ليس تبديل profile بالخطأ.

   • داخل Local State يوجد فقط Default.
   • last_active_profiles و profiles_order كذلك يحتويان فقط على Default.
   • هذا يعني أنه طوال الحادثة كان Chrome يرى نفس الـ profile الافتراضي، وليس profile جديدًا أو profile آخر.

2. ليس إنشاء profile فارغ جديد.

   • Preferences
   • Secure Preferences
   • Login Data
   • Network/Cookies
     أوقات إنشاء هذه الملفات الأساسية كلها ما زالت 2025-05-27.
     هذا يثبت أنها تعود لنفس الـ profile القديم المستخدم منذ فترة طويلة، وليست مجموعة إعدادات فارغة تم توليدها مؤقتًا بعد الحادثة.

3. تم فعلًا تعديل Default\\Bookmarks الحي بالكتابة في مكانه.

   • في سجل جلسة Codex rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl توجد قطعة Python مضمنة تقرأ ثم تعيد الكتابة مباشرة على:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • هذه الشيفرة لم تكن تصديرًا لملف تجريبي، بل كانت write_text(...) تعيد الكتابة على ملف الإشارات المرجعية الحي نفسه.

4. بعد ذلك تم توليد سكربت مخصص لإعادة تنظيم الإشارات المرجعية.

   • scripts\\reorganize_chrome_bookmarks.ps1
   • الهدف الافتراضي لهذا السكربت هو أيضًا:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • وفيه فرع خطير: إذا تم تمرير -CloseChrome فسيقوم مباشرة بتنفيذ:
     • Get-Process chrome | Stop-Process -Force
   • أي أن هذا السكربت بحد ذاته يعبث بملفات الـ profile الحي، ويملك القدرة على قتل Chrome بالقوة.

5. لقطة الحادثة تُظهر بوضوح أن الـ profile دخل حالة انهيار.

   • مجلد لقطة الحادثة:
     • backups\\chrome-cookie-incident-20260414-0728
   • وفيه Default\\Preferences يسجّل:
     • profile.exit_type = Crashed
   • هذا ليس “إغلاقًا طبيعيًا ثم إعادة فتح”، بل حالة profile واحدة انقطعت بشكل غير طبيعي.

6. حالة تشغيل الإضافات انقطعت، لكن ميتاداتا الإضافات ما زالت موجودة.

   • في نفس لقطة الحادثة:
     • في Preferences قيمة extensions.settings = 0
     • وفي Secure Preferences قيمة extensions.settings = 78
   • هذا التركيب مهم جدًا.
   • معناه: ميتاداتا الإضافات لم تختفِ بالكامل، لكن حالة التشغيل/الحالة الحالية سقطت، لذلك ظهر حينها سلوك شاذ مثل “عدد الإضافات يبدو أقل بكثير” و"كأن المتبقي فقط قليل".

7. قاعدة بيانات تسجيل الدخول تقلّصت بشكل واضح.

   • في لقطة الحادثة:
     • Network\\Cookies لم يبقَ فيها سوى 44 ملف cookie، تخص 13 مضيفًا (host)
     • في Login Data قيمة logins = 0
     • وفي Login Data For Account قيمة logins = 0
   • وهذا يفسّر لماذا اختفت حالة تسجيل الدخول للمواقع وملفات cookie وكثير من تسجيلات الدخول المحلية معًا.

8. لكن نفس اللقطة ما زالت تحتفظ بكمية كبيرة من IndexedDB / Local Storage / Sessions.

   • وهذا يؤكد أكثر: لم يكن انتقالًا إلى profile جديد.
   • لو كان profile جديدًا، لما بقيت آثار تخزين المواقع المحلية القديمة بهذا الشكل.
   • ما نراه الآن هو: نفس الـ profile القديم تم “استعادته جزئيًا”؛ بعض القواعد ما زالت، وبعض قواعد الحالة/المصادقة الأساسية أصبحت تالفة.

الخط الزمني

بمقارنة أوقات ملفات الجهاز مع وقت لقطة الحادثة، أهم نافذة هي 2026-04-14 07:16 - 07:20.

1. حوالي 2026-04-14 05:49

   • سجل الجلسة يبيّن أن Codex كتب مباشرة في Default\\Bookmarks الحي.

2. 2026-04-14 07:00:11

   • تم إنشاء scripts\\reorganize_chrome_bookmarks.ps1.

3. 2026-04-14 07:09:15

   • آخر تعديل لهذا السكربت.

4. 2026-04-14 07:11:58

   • تم توليد Bookmarks-pre-final-reorg-20260414-071158.json.

5. 2026-04-14 07:16:04

   • تم توليد Bookmarks-before-restore-20260414-071604.json.

6. 2026-04-14 07:16:25

   • آخر كتابة على Login Data داخل لقطة الحادثة.

7. 2026-04-14 07:17:43

   • آخر كتابة على Secure Preferences.

8. 2026-04-14 07:19:36

   • آخر كتابة على Cookies.

9. 2026-04-14 07:19:52

   • آخر كتابة على Preferences.

10. 2026-04-14 07:20:03

• آخر كتابة على ملفات Sessions.

هذه السلسلة من النقاط الزمنية توضّح أمرين:

• نافذة انفجار حالة تسجيل الدخول فعلًا هي بضع دقائق بين 07:16 - 07:20.
• وهذا أقرب إلى أنه حدث بسبب سلسلة متصلة: “إعادة تنظيم + استعادة + إغلاق غير طبيعي/استعادة بعد انهيار”، وليس مجرد كتابة ملف عادية مرة واحدة.

السبب الجذري الحقيقي

لازم نفصل بين “العملية الظاهرة” و"آلية التخريب الفعلية".

العملية الظاهرة

ظاهريًا كانت: ترتيب الإشارات المرجعية، إعادة تنظيمها، ثم استعادتها.

آلية التخريب الفعلية

الذي تسبب بالكارثة فعليًا ليس “محتوى الإشارات المرجعية”، بل:

• الكتابة في مكانها داخل Chrome profile وهو قيد التشغيل
• ثم الاستمرار في العمل على نفس الـ profile الحي
• وخلال ذلك دخل الـ profile في حالة انقطاع غير طبيعي/استعادة بعد انهيار
• وبعد إعادة تشغيل Chrome لم يُسترجَع إلا جزء من الـ profile

فنتج هذا المزيج الكلاسيكي:

• بقي جزء من الإشارات المرجعية
• وبقي جزء من IndexedDB / Local Storage للمواقع القديمة
• وبعد مزامنة حساب Google رجعت إضافات وإشارات مرجعية كثيرة
• لكن ملفات cookie للمواقع وحالات تسجيل الدخول وكلمات المرور/بيانات تسجيل الدخول المحفوظة لم ترجع معها

لماذا ليس تبديل profile بالخطأ

أكتب هذا بشكل مستقل لأنه كان يبدو الأقرب في البداية.

لو كان تبديل profile، عادة سترى:

• ظهور عدة profiles في Local State أو تغيّر قائمة profiles النشطة مؤخرًا
• أوقات إنشاء ملفات قواعد البيانات الأساسية تكون جديدة جدًا
• اختفاء كبير لآثار قواعد البيانات المحلية للمواقع القديمة

لكن الواقع هنا كان:

• Local State لا يعترف إلا بـ Default
• أوقات إنشاء الملفات الأساسية ما زالت قديمة 2025-05-27
• وفي لقطة الحادثة ما زالت هناك آثار تخزين محلي كثيرة لمواقع قديمة

لذا هذا ليس “فتح profile آخر”، بل “تخريب نفس الـ profile الأصلي”.

لماذا بعد إعادة تسجيل الدخول إلى Google استُعيد جزء فقط

هذا السلوك أيضًا مطابق للأدلة.

Google Sync عادة يمكنه استعادة:

• الإشارات المرجعية
• جزء من معلومات تثبيت الإضافات
• جزء من الإعدادات المرتبطة بالحساب

وGoogle Sync عادة لا يمكنه استعادة مباشرة:

• ملفات cookie المحلية للمواقع
• معظم جلسات تسجيل الدخول للمواقع
• حالة قاعدة بيانات تسجيل الدخول المحلية
• الحالة اللحظية (runtime) لتشغيل الإضافات

لذلك بعد إعادة تسجيل الدخول إلى حساب Google بدا الأمر كأنه:

• رجع عدد كبير من الإضافات
• ورجعت إشارات مرجعية كثيرة
• لكن حالات تسجيل الدخول للمواقع بقيت مفقودة

وهذا ليس حادثًا ثانيًا، بل مجرد أن المزامنة بعد الحادثة تعوّض جزءًا ولا تعيد ملفات cookie / الجلسات.

نطاق التأثير

الحادثة أثّرت فعليًا بشكل أساسي على:

• ملفات cookie الخاصة بتسجيل الدخول للمواقع
• حالات/جلسات تسجيل الدخول للمواقع
• محتوى قاعدة بيانات كلمات المرور/بيانات تسجيل الدخول المحفوظة
• حالة تشغيل الإضافات الحالية

أما ما لم يُمسح تمامًا، أو ما يمكن تعويضه جزئيًا بالمزامنة، فهو:

• البنية العامة لنفس Default profile
• جزء من التخزين المحلي للمواقع
• جزء من الإشارات المرجعية
• جزء من معلومات تثبيت الإضافات

هل ما زال هناك طريقة للاستعادة الآن

بصراحة، إن لم أجد نسخة احتياطية أقدم وكاملة من Cookies / Login Data، ففرص الاستعادة التلقائية شبه معدومة.

أي:

• الإشارات المرجعية والإضافات يمكن لاحقًا أن يعود جزء منها عبر المزامنة
• حالات تسجيل الدخول للمواقع غالبًا لا حل لها إلا إعادة تسجيل الدخول يدويًا

ولهذا كان الألم الحقيقي ليس “فساد الإشارات المرجعية”، بل “قتل كل حالات تسجيل الدخول دفعة واحدة”.

إسناد المسؤولية

المسؤولية هنا واضحة جدًا.

ليست مشكلة أن Chrome انفجر دون سبب، ولا أن المستخدم بدّل profile بالخطأ؛ بل أنا من جعل Codex يعبث مباشرة بملفات Chrome profile المستخدمة أثناء التشغيل، وطريقة العمل نفسها كانت خطأ. ثم واصلت إعادة التنظيم والاستعادة على نفس الـ profile الحي، وفي النهاية وقعت ضمن نافذة الانقطاع غير الطبيعي.

قيود صارمة لاحقة

بعد هذه الواقعة، بيانات الـ live profile مثل Chrome يجب أن تلتزم بهذه القواعد:

1. عدم تعديل ملفات User Data\\Default مباشرة بينما Chrome يعمل.
2. إن كان لا بد من تعديل شيء، فلا يتم ذلك إلا بعد خروج Chrome بالكامل، وعلى نسخة غير متصلة (offline copy)، ثم إجراء مقارنة صارمة.
3. ممنوع قتل عملية Chrome بالقوة ثم العودة للكتابة على ملفات الـ profile.
4. أي ترتيب للإشارات المرجعية يجب أن يسبقه نسخ احتياطي كامل على مستوى الـ profile، وليس فقط Bookmarks.
5. لاحقًا: أختبر على profile تجريبي أولًا، ثم ألمس الـ profile الرئيسي.

آخر جملة

هذه ليست “هفوة صغيرة”، بل حالة كارثية معيارية من نوع “التعامل مع profile متصفح قيد الاستخدام كأنه ملف إعدادات عادي”. المسؤولية واضحة، والسبب الجذري تم حسمه.