الكوكيز والجلسات: كيف يتذكّرك الموقع

في مقال «HTTP وHTTPS» تركتُ سؤالا معلّقا: إن كان HTTP «عديم الحالة»، أي لا يربط طلبا بسابقه ولا يتذكّر شيئا، فكيف يبقى تسجيل دخولك قائما وأنت تتنقّل بين عشرات الصفحات؟ وكيف تتذكّر سلّة التسوّق ما وضعتَه فيها؟ الجواب ليس في HTTP نفسه، بل في حيلة ذكية تُبنى فوقه: الكوكيز.

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

المشكلة: بروتوكول بذاكرة سمكة

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

الحلّ: الكوكي، بطاقة صغيرة تحملها معك

الكوكي (Cookie) قطعة صغيرة من النصّ يضعها الخادم في متصفّحك ليتذكّرك بها. الآلية بسيطة في ثلاث خطوات: يرسل الخادم في ردّه ترويسة Set-Cookie فيها قيمة، فيخزّنها متصفّحك، ثمّ يعيدها تلقائيا في ترويسة Cookie مع كل طلب تال إلى الموقع نفسه.^[1] هكذا يصل كل طلب ومعه «بطاقة تعريف» تقول للخادم: هذا أنا.

// ردّ الخادم: ضع هذا الكوكي
Set-Cookie: session=a3f9x2; HttpOnly; Secure; SameSite=Lax

// كل طلب تال من المتصفّح يحمله
Cookie: session=a3f9x2

ولاحظ فرقا بين السطرين لا يُنبَّه إليه عادةً: الخصائص تذهب ولا تعود. فترويسة Set-Cookie تحمل التعليمات كلّها إلى المتصفّح، أمّا ما يعيده المتصفّح في كلّ طلب تال فليس إلّا الاسم والقيمة. لا يعرف الخادم من الطلب العائد أنّ الكوكي كان HttpOnly، ولا ما تاريخ انتهائه.^[7] والسبب أنّ الخصائص أوامرُ للمتصفّح لا بيانات للخادم: هو الذي كتبها، فلا حاجة إلى إعادتها إليه. ومن هذا يتبيّن لك موضع تنفيذ هذه الحماية: في متصفّحك، لا على الخادم.

شكل 1

والاسم نفسه طريف: ابتكر الكوكي مهندس في Netscape اسمه لو مونتولي (Lou Montulli) سنة 1994 ليحلّ هذه المشكلة بالذات، واستعار التسمية من «الكوكي السحريّ» (Magic Cookie)، وهو مصطلح قديم في البرمجة لقطعة بيانات يحملها برنامج ويعيدها كما هي. ومنذ ذلك الحين، صار هذا النصّ الصغير عماد الذاكرة على الويب.

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

الجلسات: لماذا لا يحمل الكوكي بياناتك مباشرةً

لاحظ أن الكوكي في المثال لا يحمل اسمك ولا كلمة مرورك، بل رمزا غامضا (a3f9x2). هذا مقصود. فالأسلوب الشائع هو «الجلسة» (Session): حين تسجّل دخولك، يُنشئ الخادم سجلّا عنده يحوي بياناتك، ويعطيك في الكوكي معرّفا عشوائيا لهذا السجلّ فقط. فأنت تحمل المفتاح، والبيانات الحسّاسة تبقى عند الخادم. لو حُشِرت بياناتك نفسها في الكوكي، لسافرت مع كل طلب ولأمكن لأحد أن يقرأها أو يزوّرها. أما الرمز العشوائيّ فلا معنى له خارج خادم الموقع.

وأين يقيم هذا السجلّ؟ في ذاكرة الخادم، أو في قاعدة بيانات سريعة (مثل Redis)، أو في خادم مخصّص للجلسات؛ ولكلّ جلسة مدّةُ صلاحية تنتهي بها بعد خمول طويل، فتُطلَب منك إعادة الدخول. ولنتتبّع الخطوات كاملة: تُرسِل اسمك وكلمة مرورك مرّة واحدة عبر طلب POST آمن؛ يتحقّق الخادم منها، ويُنشئ جلسة، ويردّ بترويسة Set-Cookie فيها معرّفها؛ فمع كل صفحة تفتحها بعد ذلك، يرسل متصفّحك الكوكي تلقائيا، فيقرأ الخادم المعرّف، ويجد جلستك، ويعرف أنك أنت، دون أن تكتب كلمة مرورك ثانية.

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

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

تشريح الكوكي: خصائصه تحدّد عمره وأمنه ونطاقه

للكوكي مع قيمته خصائص (Attributes) تضبط سلوكه، ومعرفتها فرق بين موقع آمن وآخر مكشوف:^[1]

• Expires وMax-Age: تحدّدان عمر الكوكي. بدونهما يكون «كوكي جلسة» يزول بإغلاق المتصفّح؛ ومعهما يصير «دائمًا» إلى موعد محدّد.
• Secure: يمنع إرسال الكوكي إلا عبر اتصال HTTPS مشفّر، فلا يُلتقَط على شبكة مكشوفة.
• HttpOnly: يمنع شيفرة JavaScript في الصفحة من قراءة الكوكي، وهو درع أساسيّ ضدّ سرقته عبر هجمات حقن النصوص (XSS).
• SameSite: يحدّد هل يُرسَل الكوكي حين يأتي الطلب من موقع آخر. قيمته Strict (لا يُرسَل إلا من الموقع نفسه)، أو Lax (الافتراضيّ)، أو None (يُرسَل دوما، ويشترط Secure). وهو خطّ الدفاع الأول ضدّ هجمات تزوير الطلب عبر المواقع (CSRF).
• Domain وPath: يحدّدان نطاق الكوكي: أيّ النطاقات الفرعية وأيّ المسارات تتلقّاه، فلا يُرسَل إلا حيث يلزم.

وللكوكي حدود ماديّة تُفسِّر تصميم الجلسات: حجمه صغير (نحو أربعة كيلوبايت)، وعددُه لكل نطاق محدود. فهو يصلح لحمل معرّف صغير، لا لتخزين بيانات كثيرة، وهذا سبب آخر لإبقاء البيانات عند الخادم والاكتفاء بمفتاح في الكوكي.

أمن الكوكيز: لماذا تهمّ هذه الخصائص

لأن كوكي الجلسة هو مفتاح هويتك، فمن يسرقه ينتحلك دون أن يعرف كلمة مرورك أصلًا، وهو ما يُسمّى «اختطاف الجلسة» (Session Hijacking). من هنا تأتي أهمية الخصائص: Secure يمنع التقاطه على الشبكة، وHttpOnly يمنع سرقته بشيفرة خبيثة حُقِنت في الصفحة. أما SameSite فيعالج خطرا أدقّ: «تزوير الطلب عبر المواقع» (CSRF)، حين يخدعك موقع خبيث لتنقر رابطا يرسل طلبا إلى بنكك مستغلّا جلستك المفتوحة؛ فبجعل الكوكي لا يُرسَل مع الطلبات الآتية من مواقع أخرى، يسقط الهجوم.

ثمّ إنّ الاتّكال على الإعداد الافتراضيّ موضعُ خطأ شائع في الأدلّة. فالمتصفّحات التي تعامل الكوكي بلا SameSite معاملة Lax لا تطبّق Lax التي تكتبها بيدك، وإنّما صورة أرخى منها: يُرسَل الكوكي مع طلب POST عابر للمواقع ما لم يمضِ على إنشائه أكثر من دقيقتين.^[5] نافذة قصيرة يتساهل فيها المتصفّح، وُضعت كي لا تنكسر تدفّقات تسجيل دخول قديمة. والفرق عمليّ: إن اتّكلت على الافتراضيّ ظنّا أنّه يسدّ CSRF، فأنت محميّ في أكثر الحالات لا كلّها. فاكتب SameSite صريحة ولا تدع المتصفّح يختار عنك.

ولزيادة الإحكام، ثمّة «بادئات» تُضاف إلى اسم الكوكي تفرض عليه قواعد أمان لا يقبلها المتصفّح إلا بها: بادئة __Secure- تشترط أن يكون الكوكي عبر HTTPS، و__Host- تشترط فوق ذلك أن يكون محصورا في النطاق نفسه دون فروعه. وأُضيفت إليهما حديثًا بادئة ثالثة أشدّ منهما: __Host-Http- تشترط، فوق شروط __Host-، أن يكون الكوكي HttpOnly، فلا يقبل المتصفّح كوكيا يحملها إن كانت JavaScript هي التي كتبته. مكّنتها Chrome في إصدارها 140 وFirefox في 143، ولا تعرفها Safari حتى صيف 2026.^[8] هذه السطور القصيرة هي ما يفصل تطبيقا محصّنا عن آخر سهل الاختراق، ولهذا يجب أن يحمل كل كوكي جلسة خصائصه الأمنية كاملة.

ما لا يشمله نطاق الكوكي: المنفذ والنطاقات الشقيقة

عرفتَ أنّ Domain وPath يحدّدان أين يُرسَل الكوكي. والأنفع أن تعرف ما لا يدخل في هذا النطاق أصلًا، وثمّة ثغرتان يسمّيهما المعيار بأسمائهما.

الأولى أنّ الكوكيز لا تُفصَل بالمنفذ. فما يضعه خادم على منفذ يقرؤه خادم آخر على منفذ ثان من المضيف نفسه.^[7] فإن شغّلتَ تطبيق تجربة على المنفذ 8080 وتطبيقك الحقيقيّ على 443 من العنوان نفسه، فهما يتقاسمان الكوكيز شئتَ أم لم تشأ. والدرس عمليّ: لا تعامل منفذا مختلفا على المضيف نفسه كأنّه بيئة منفصلة.

والثانية أدقّ: نطاق فرعيّ يستطيع أن يكتب كوكيا باسم النطاق الأمّ، فيصل إلى النطاقات الشقيقة كلّها ويستطيع أن يطمس كوكيا موجودا.^[7] فلو استُضيف على blog.example.com شيء لا تتحكّم فيه تمامًا، أمكنه أن يضع كوكيا لـexample.com يبلغ shop.example.com. ولهذا وُضعت البادئة __Host- التي مرّت بك: كوكي يحملها لا يُقبَل إلّا إذا كان مقصورا على المضيف الواحد بلا خاصيّة Domain، فيمتنع هذا الطمس من أصله. وحدَّ هذه الثغرة من فوقها قائمة لا سطر في المعيار: «قائمة اللواحق العامّة» (Public Suffix List)، وهي مبادرة يتشارك فيها منتجو المتصفّحات، يتعهّدها متطوّعو موزيلا والسجلّات. بها يعرف متصفّحك أين تنتهي حدود الجهة الواحدة، فيمنع كتابة كوكيّ على لاحقة عامّة مثل co.uk أو على نطاق يمنح فروعه لجهات مختلفة. ولهذا تضع المنصّات محتوى مستخدميها على نطاق مستقلّ عن نطاقها الرئيس.^[9]

الكوكيز مقابل الرموز: كيف تتعامل التطبيقات الحديثة

الكوكي أنسب للمواقع التقليدية التي يعرضها متصفّح. لكنّ التطبيقات الحديثة، من تطبيقات الجوّال إلى واجهات الصفحة الواحدة (SPA) التي تخاطب واجهة برمجية (API)، تميل غالبًا إلى أسلوب آخر: «الرموز» (Tokens)، وأشهرها JWT. الرمز قطعة موقّعة تثبت هويتك، يحملها التطبيق ويرسلها صراحة في ترويسة Authorization مع كل طلب، بدل أن يعتمد على إرسال الكوكي التلقائيّ.^[3]

والفرق عمليّ: الكوكي يُرسَل تلقائيا (وهذا ما يفتح باب CSRF)، بينما الرمز يُرسَل عمدًا فلا يقع في الفخّ نفسه، لكنّه يحتاج مكانا آمنا لتخزينه على الجهاز، وإن خُزّن في موضع تقرؤه JavaScript صار عرضة للسرقة. لكلّ موضعه: جلسةُ كوكيّ بخصائصها الأمنية لموقع يعرضه متصفّح، ورمز لواجهة برمجية يخاطبها تطبيق.

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

الطرف الأول مقابل الطرف الثالث: أصل التتبّع

هنا يدخل التمييز الأهمّ في جدل الخصوصية. كوكي الطرف الأول يضعه الموقع الذي تزوره فعلًا، وهو ما يجعل تسجيل دخولك وسلّتك تعمل، ولا غنى عنه. أما كوكي الطرف الثالث فيضعه طرف آخر مضمَّن في الصفحة، كإعلان أو أداة تحليل تُحمَّل من نطاق مختلف.^[1]

والفرق ليس تقنيًا فحسب. لأن المعلن نفسه (مثل شبكة إعلانات كبرى) مضمَّن في آلاف المواقع، يستطيع كوكيه أن يتعرّف عليك عبرها كلّها، فيبني صورة عمّا تزوره وتقرؤه وتشتريه عبر الويب بأكمله. هذا هو محرّك «الإعلانات الموجّهة»، وهو في الوقت نفسه أكبر مخاوف الخصوصية على الويب.

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

والمفارقة أن التقنية نفسها التي تُسهّل حياتك (تُبقي دخولك وسلّتك وتفضيلاتك) هي التي تُستعمَل لتتبّعك. فالكوكي أداة محايدة، والفرق كلّه في مَن يضعها ولأيّ غرض. ولهذا ليس الحلّ إلغاء الكوكيز جملة، فذلك يكسر الويب، بل التمييز بين ضروريّها وتطفّليّها، وهو جوهر كل ما يدور اليوم حول خصوصية الويب.

مصير كوكيز التتبّع: ما تغيّر حتى 2026

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

• سفاري وفايرفوكس يحجبان كوكيز الطرف الثالث افتراضيا منذ سنوات (سفاري منذ 2020).
• كروم كان قد وعد بإلغائها، لكنّه تراجع سنة 2024: أبقاها كما هي ولم يفرض حتى شاشة اختيار للمستخدم.^[4] فهي ما زالت تعمل في كروم، وإن تراجعت موثوقيّتها مع تشديد المستخدمين إعداداتِ الخصوصية.
• مشروع «صندوق الخصوصية» (Privacy Sandbox) الذي قُدّم بديلا، جرى طيّ معظمه أواخر 2025 لضعف الإقبال عليه.^[4]

فالخلاصة الدقيقة: كوكيز الطرف الثالث لم تَمُت، لكنها تضعف؛ نصف المتصفّحات تحجبها، وكروم أبقاها على مضض. ومع ضعفها، لم يختفِ التتبّع بل تحوّل: تتّجه الشركات إلى «بيانات الطرف الأول» التي تجمعها بنفسها (كأن تربط نشاطك ببريدك حين تسجّل دخولك)، وإلى التتبّع من جانب الخادم بدل المتصفّح. بل إن بعض المتعقّبين، حين تُحجَب الكوكيز، يلجؤون إلى «بصمة المتصفّح» (Fingerprinting): جمع تفاصيل دقيقة عن جهازك (نظامه، خطوطه، دقّة شاشته، إعداداته) تكوّن معا بصمة شبه فريدة تتعرّف عليك دون كوكيّ أصلًا. أي إن موت كوكيز التتبّع لا يعني نهاية التتبّع، بل تغيّر أدواته.

لافتات الموافقة: لماذا تستقبلك في كل موقع

بصرف النظر عن المتصفّح، فرضت قوانين الخصوصية (مثل GDPR الأوروبيّ وCCPA في كاليفورنيا) أن يُستأذَن المستخدم قبل وضع الكوكيز غير الضرورية. ومن هنا جاءت لافتات «الموافقة». والتمييز جوهريّ: الكوكيز «الضرورية» (كالتي تُبقي جلستك أو سلّتك) لا تحتاج إذنا لأن الموقع لا يعمل بدونها؛ أما كوكيز التحليل والإعلان فتحتاج موافقتك الصريحة، ويجب أن يبقى الموقع صالحا للاستعمال حتى لو رفضتَها. فحين ترى اللافتة، أنت أمام هذا التمييز بعينه: ما يلزم لتشغيل الموقع، وما يُجمَع عنك لغايات أخرى.

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

بدائل الكوكيز: تخزين الويب

ليست الكوكيز الوسيلة الوحيدة لتخزين شيء في المتصفّح. فثمّة «تخزين الويب» (Web Storage) بنوعيه: localStorage الذي يبقى بعد إغلاق المتصفّح، وsessionStorage الذي يزول بإغلاق التبويب. ولأحجام البيانات الكبيرة هناك قاعدة بيانات في المتصفّح اسمها IndexedDB.^[2]

والفرق الجوهريّ عن الكوكيز ثلاثة: هذا التخزين لا يُرسَل إلى الخادم تلقائيا مع كل طلب (فلا يثقل الشبكة)، ويتّسع لبيانات أكبر بكثير (ميغابايتات لا كيلوبايتات)، وتقرؤه شيفرة JavaScript مباشرةً. لذا يُفضَّل لتخزين تفضيلات على جانب المتصفّح (كوضع العرض الليليّ) أو بيانات تطبيق مؤقّتة. أما ما يحتاج الخادمُ معرفته في كل طلب، كهويّة جلستك، فالكوكي أنسب لأنه يُرسَل تلقائيا. وكون JavaScript تقرأ تخزين الويب يعني أنه ليس مكانا آمنا لرمز جلسة حسّاس: فلو خُزّن رمز الدخول في localStorage، كفت ثغرة XSS واحدة لسرقته. لهذا تبقى رموز الجلسة الحسّاسة في كوكي HttpOnly بعيدا عن متناول الشيفرة، ويُترَك تخزين الويب لما لا ضرر في كشفه.

شاهد كوكيزك وتحكّم بها

لست متلقّيا سلبيّا لهذا كلّه؛ تستطيع رؤية الكوكيز التي يخزّنها كل موقع والتحكّم بها. افتح «أدوات المطوّر» في متصفّحك (بمفتاح F12)، واذهب إلى لسان «Application» ثمّ قسم «Cookies»، فترى قائمة بكل كوكيز خزّنها الموقع: اسمها، وقيمتها، ومتى تنتهي، وهل هي آمنة وموسومة بحماية من إرسالها لأطراف أخرى، وإلى جانبها ترى localStorage وsessionStorage. النظر إلى ما يُخزَّن عنك أصدق من أيّ شرح.

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

وقد تغيّرت الإعدادات الافتراضية نفسها لصالحك. فمنذ 2020 صار متصفّح كروم يعامل أيّ كوكي بلا خاصيّة SameSite صريحة معاملة Lax، فلا يُرسَل في الطلبات العابرة للمواقع إلا في أضيق الحدود، وهذا وحده جفّف كثيرًا من التتبّع الصامت. وفي 2024 عمّمت المتصفّحات «الكوكيز المجزّأة» (اسمها التقنيّ CHIPS): يُعزَل كوكي الطرف الثالث في حجرة منفصلة لكل موقع مضيف، فلا يبقى جسرا يربط تنقّلك بين المواقع.^[5] وعلى الجبهة القانونية ظهرت إشارة «التحكّم العامّ بالخصوصية» (Global Privacy Control) التي يبثّها متصفّحك تلقائيا ليطلب عدم بيع بياناتك، وتُلزِم قوانينُ ولايات مثل كاليفورنيا المواقعَ باحترامها.^[6] وهكذا ينتقل عبء الضبط شيئا فشيئا من كتفك وحدك إلى المتصفّح والقانون.

من تذكُّرك إلى ربط الصفحات

الكوكيز إذن حلّ أنيق لمشكلة خلقها تصميم HTTP: بطاقة صغيرة تحملها معك فتمنح الموقع «ذاكرة» للتعرّف عليك، بينما يبقى البروتوكول نفسه عديم الحالة وقابلا للتوسّع. ومن خصائصها القليلة (Secure وHttpOnly وSameSite) يُبنى أمن الجلسات كلّه؛ وفي التمييز بين طرفها الأول وطرفها الثالث يدور جدل الخصوصية الذي ما زال يعيد تشكيل الويب.

وبهذا تكتمل صورةُ الطبقة الأقرب إليك، طبقة الويب: كيف يجد الموقعُ عنوانه (URL وDNS)، وكيف يتكلّم (HTTP)، وكيف يأمن (SSL/TLS)، وكيف يتذكّرك (الكوكيز). لكنّ الويب ليس تطبيق الإنترنت الوحيد؛ فإلى جانبه يعمل أقدمُ تطبيقاته وأكثرها صمودا، على مسار مختلف تمامًا: البريد الإلكتروني. وهذا موضوع المقال التالي: «البريد الإلكتروني: كيف يُرسَل ويصل».

المصادر

1. MDN Web Docs: Using HTTP cookies. آلية Set-Cookie/Cookie، والخصائص (Secure، HttpOnly، SameSite، Domain، Path، Expires)، والبادئات، والطرف الأول مقابل الثالث.
2. MDN Web Docs: Web Storage API. localStorage وsessionStorage مقابل الكوكيز.
3. IETF: RFC 6265: HTTP State Management Mechanism. المواصفة الرسمية للكوكيز وترويسة Authorization.
4. Google: Privacy Sandbox. تراجع كروم سنة 2024 عن إلغاء كوكيز الطرف الثالث، وطيّ معظم المشروع أواخر 2025.
5. MDN Web Docs: Set-Cookie (موزيلا). خصائص الكوكي الحديثة: افتراض SameSite=Lax، والكوكيز المجزّأة (Partitioned / CHIPS).
6. Global Privacy Control: globalprivacycontrol.org. مواصفة إشارة GPC وسندها القانونيّ في ولايات أمريكيّة مثل كاليفورنيا وكولورادو.
7. IETF: RFC 6265: HTTP State Management Mechanism. الفصول §5.4 و§8.5 و§8.6: أنّ الترويسة العائدة تحمل الاسم والقيمة وحدهما دون الخصائص، وأنّ الكوكيز لا تُفصَل بالمنفذ، وأنّ نطاقا فرعيّا يستطيع الكتابة باسم نطاقه الأمّ والطمس عليه.
8. MDN Web Docs: Using HTTP cookies: Cookie prefixes. شروط البادئة __Host-Http-، وإصدارات المتصفّحات التي مكّنتها.
9. Public Suffix List: Learn more about the Public Suffix List. القائمة التي يعرف بها المتصفّح حدود الجهة الواحدة، فيمنع كتابة كوكيّ على لاحقة عامّة.