التشفير من جهة العميل لمشاركة الأسرار

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

يشرح هذا الدليل ما يضمنه التشفير في المتصفح، وأين ينهار دون أن يلاحظ أحد، وكيف يقارن بالنموذج الذي يشفّر على الخادم، وكيف يجمع LinkPilot بين الاثنين منذ 29 سبتمبر 2026، حين انتقل مولّد الروابط السرية لمرة واحدة إلى التشفير في المتصفح.

أُعيدت كتابته في 19 أكتوبر 2026. كانت النسخة الأصلية من هذا المقال تصف نموذج LinkPilot الذي كان قائمًا آنذاك على التشفير في الخادم، وسجلت ملاحظة أُضيفت في 29 سبتمبر 2026 هذا التحول. أما هذه النسخة فتصف النموذج الحالي من أولها إلى آخرها. ولم يتغير التحليل لما يحميه كل نموذج وما لا يحميه.

ما الذي يحميه التشفير من جهة العميل فعلًا؟

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

1. يولّد المتصفح مفتاحًا متماثلًا، وهو عادة مفتاح AES-GCM بطول 256 بت يُنشأ عبر Web Crypto API (crypto.subtle.generateKey).
2. يُشفَّر المحتوى في المتصفح بهذا المفتاح.
3. لا يُرسل إلى الخادم إلا النص المشفر، فيخزنه الخادم تحت معرّف عشوائي.
4. يُلحق المفتاح برابط المشاركة في الجزء الذي يلي علامة # في الرابط (#…). وبحسب RFC 3986، القسم 3.5 لا ترسل المتصفحات هذا الجزء أبدًا في طلبات HTTP، فلا يعبر المفتاح الشبكة إلى الخادم.
5. يقرأ متصفح المستلم هذا الجزء، ويجلب النص المشفر، ويفك تشفيره محليًا.

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

بنية رابط سري مشفر من طرف إلى طرف

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

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

ما الذي لا يحمي منه التشفير من جهة العميل؟

من شيفرة JavaScript الخبيثة أو المخترقة، ومن إضافات المتصفح، ومن تسريب الرابط، لأن المفتاح موجود في الرابط.

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

مشكلة تسليم الشيفرة بالتفصيل

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

لذلك فالقراءة الصادقة لعبارة «لا نستطيع قراءة أسرارك» هي «لا نستطيع قراءة أسرارك بطريقة سلبية». وتحويل القدرة السلبية إلى هجوم نشط يرسل شيفرة معدّلة تصعيد حقيقي (فالهجمات النشطة أخطر على مرتكبها وموجّهة وقد تُكتشف)، لكنها لا تعني «مستحيل». وهذا ينطبق على ادعاء LinkPilot كما ينطبق على ادعاء أي جهة أخرى.

البديل: التشفير في الخادم

التصميم الشائع الآخر، وهو الذي استخدمه LinkPilot حتى سبتمبر 2026، يشفّر البيانات المخزنة على الخادم ويحمي الإظهار بعبارة مرور مجزّأة:

• TLS أثناء النقل، والمحتوى مخزن في جدول مخصص في قاعدة بيانات مشفرة على مستوى القرص.
• تُجزّأ عبارات المرور في المتصفح قبل إرسالها وتُقارن بالتجزئة، فلا تصل عبارة المرور الأصلية إلى قاعدة البيانات أبدًا.
• حذف نهائي يُتلف البيانات: عند أول إظهار أو انتهاء الصلاحية أو الإبطال يُكتب فوق المحتوى المخزن، وتتلقى المحاولات اللاحقة HTTP 410.
• عدد محاولات عبارة المرور محدود، وكل محاولة تُسجَّل.

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

ما يفعله LinkPilot الآن

منذ 29 سبتمبر 2026 يستخدم LinkPilot التشفير من جهة العميل، ويحتفظ بضوابط الخادم التي لا تحتاج إلى المحتوى. من صفحة بنية الأمان:

• التشفير في المتصفح. يُشفَّر المحتوى باستخدام AES-GCM-256 بمفتاح طوله 256 بت يُولَّد في متصفح المرسل. يخزن الخادم النص المشفر ولا شيء غيره، وينتقل المفتاح في الجزء الذي يلي علامة # في رابط المشاركة.
• عبارة المرور جزء من المفتاح (Pro). تُقوّى عبارة المرور باستخدام PBKDF2-SHA256 (210,000 تكرار) وتُدمج مع مفتاح الرابط عبر HKDF-SHA256، فلا يكفي الرابط وحده ولا عبارة المرور وحدها لفك تشفير السر. ويقتصر عدد المحاولات على 5 لكل عنوان IP في الدقيقة لكل سر، عبر محدِّد في الذاكرة ونافذة زمنية متحركة في قاعدة البيانات.
• الحذف بعد القراءة على النص المشفر. تُسجَّل المشاهدة في خطوة واحدة لا تتجزأ عبر دالة في قاعدة البيانات، فلا يمكن لمحاولات إظهار متزامنة أن تُسرّب السر مرتين، ويُكتب فوق النص المشفر المخزن بالقيمة [REDACTED]، وتعيد المحاولات اللاحقة HTTP 410.
• الإبطال. يمكن إبطال السر من لوحة التحكم في أي وقت، والأسرار المُبطلة ترفض الإظهار وتعيد 410.
• إظهار لا تُطلقه المعاينة. أدوات معاينة الروابط وأدوات فحص البريد الإلكتروني ترسل طلبات GET، وهذه لا تعيد إلا بيانات وصفية (الحالة، وهل يلزم إدخال عبارة مرور). ولا تُسجَّل المشاهدة إلا عند إظهار صريح من متصفح.
• سجل التدقيق (Pro). الإنشاء والمشاهدة ومحاولة عبارة مرور خاطئة والحذف النهائي وانتهاء الصلاحية والإبطال، ولكل حدث وقته، والبلد والمدينة كما تبلّغ عنهما الشبكة الطرفية، وسلسلة تعريف المتصفح، وتجزئة للعنوان بقيمة ملح يومية. يسجل السجل الوصول، ولا يسجل المحتوى أبدًا.
• الملفات. تُشفَّر المرفقات في المتصفح أيضًا، بمفتاح مشتق من مفتاح الرابط. ويبقى اسم الملف وحجمه ونوعه ظاهرة أمام LinkPilot بوصفها بيانات وصفية.

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

ملخص المقايضات

لا يوجد نموذج «أكثر أمانًا» في المطلق. فكل نموذج يدافع ضد تهديدات مختلفة بتكلفة مختلفة، والجمع بينها يقلل ما تتنازل عنه ولا يلغيه.

مطابقة النموذج مع التهديد: ثلاثة سيناريوهات

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

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

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

كيف تختار

اختر التشفير من جهة العميل عندما:

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

اختر التشفير في الخادم عندما:

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

ابحث عن الاثنين معًا عندما:

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

هل أداة التشفير عبر الإنترنت هي الخيار الصحيح؟

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

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

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

متى لا تستخدم أيًّا منهما

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

التحقق من الادعاء

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

• هل المفتاح في الجزء الذي يلي علامة #؟ افحص بنية الرابط، فالمفتاح يجب أن يأتي بعد #.
• هل يعيد طلب عادي للرابط السر نفسه؟ يجب ألا يعيده.
• ماذا تفعل عبارة المرور: هل تتحكم في الإظهار، أم تشكل جزءًا من المفتاح؟
• ما الذي يُسجَّل، وهل يذكر المشغّل ذلك كتابةً؟

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

قراءات ذات صلة

• كيف تعمل الروابط السرية لمرة واحدة
• هل OneTimeSecret آمن؟
• LinkPilot مقابل PrivateBin
• الروابط السرية مقابل مديري كلمات المرور
• لماذا تُسرّب عناوين URL معلومات حساسة
• أدوات فحص الروابط والأسرار لمرة واحدة

المراجع

• W3C، Web Cryptography API.
• NIST، SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF، RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation، SecureDrop.