هل من الآمن إرسال الملفات عبر الإنترنت؟

آخر تحديث: 2026-08-06

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

لا يتطلّب أيٌّ من هذا خلفية تقنية. وبحلول النهاية، ستعرف ما الأسئلة التي ينبغي طرحها — على أي طريقة نقل، بما فيها هذه الطريقة.

أين تتعرّض الملفات للخطر فعلًا: المخاطر اليومية

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

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

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

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

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

ما الذي يعنيه فعلًا «التشفير من الطرف إلى الطرف» و«المعرفة الصفرية»

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

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

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

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

ما الذي ينبغي التحقق منه فعلًا قبل الوثوق بأداة نقل

ما تحتاجه لتنفيذ قائمة الفحص هذه

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

لغة التسويق على أي موقع أقل قيمة من بضعة أسئلة ملموسة:

ابحث عن جواب المزوّد نفسه عن سؤال «هل تستطيعون قراءة ملفاتي؟» داخل شفرته المصدرية، لا في صفحة الأسعار. وإن لم تكن هناك شفرة مصدرية فذلك في حد ذاته جواب.
```
https://github.com/relayium/relayium
```
تحقّق من الرخصة، ومن أن المستودع يقابل ما هو منشور فعلًا. فالادّعاء الذي يمكنك فحصه نوع مختلف عن الادّعاء الذي يُطلب منك قبوله.
في نقل حيّ، قارن رمز التحقّق على الشاشتين. فهذه هي الخطوة التي تحوّل «التشفير من الطرف إلى الطرف» من جملة إلى شيء يُطبَّق فعلًا بين هذين الطرفين تحديدًا.
```
https://relayium.com/
```
وأثناء ذلك النقل، افتح أدوات المطوّر في متصفّحك وراقب لوحة الشبكة. وابحث عن محتوى ملفك داخل ما يجري رفعه. فألّا تجده هو المقصود، وأن تجده هو النتيجة.
تحقّق مما يبقى بعد ذلك: هل ينتهي الرابط من تلقاء نفسه، وهل تستطيع الخدمة إخراج الملف مرة أخرى لاحقًا لو طُلب منها ذلك.

ماذا يخبرك اجتياز هذه القائمة فعلًا

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

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

هل تقول «مشفّر» (قد تعني مجرد TLS) أم تقول تحديدًا «التشفير من الطرف إلى الطرف» (المُرسِل والمُستقبِل وحدهما يملكان المفتاح)؟
هل هناك طريقة للتحقق من أن الاتصال لم يُعبَث به — رمز تقارنه، لا مجرد أيقونة قفل عليك أن تثق بها؟
هل يُتحقَّق من سلامة الملف، بحيث لا يصل ملف تالف أو مُعدَّل خاطئًا بصمت؟
هل الشيفرة مفتوحة المصدر وقابلة للتدقيق، أم أن الادّعاءات مجرد تسويق عليك تصديقه على عِلّاته؟
هل يتطلّب الإرسال أو الاستقبال تسليم هوية أكثر مما تحتاجه عملية النقل فعلًا؟
إذا خُزِّن أي شيء، فهل له عمر واضح ومحدود — انتهاء صلاحية أو حذف بعد التنزيل — بدلًا من بقائه هناك إلى أجل غير مسمّى؟

كيف يجيب Relayium عن كلٍّ من هذه

في النقل الفوري، مع وجود الطرفين متصلَين في آن واحد، يولّد Relayium زوج مفاتيح X25519 جديدًا على كل جهاز ويشتقّ مفتاح AES-256-GCM مشتركًا موجودًا فقط داخل المتصفحَين — ولا يُرسَل أبدًا إلى خوادم Relayium نفسها. ويتيح رمز تحقق قصير اختياري (SAS) — يظهر عند تفعيل «التحقّق المتقدّم» المعطَّل افتراضيًا — للطرفين تأكيد أن المفاتيح لم تُستبدَل من قِبَل خادم غير نزيه في المنتصف، وتُفحَص تجزئة SHA-256 لكل ملف من الطرف إلى الطرف حتى لا يصل نقل تالف وهو يبدو سليمًا. أما تفاصيل كيفية عمل ذلك بالضبط فتُشرَح بعمق أكبر في «كيف يُشفِّر Relayium ملفاتك من الطرف إلى الطرف»، إن أردت التعمّق أكثر من هذه الصفحة.

حين لا يكون المُستقبِل متصلًا بعد، يستخدم رابط التنزيل المُخزَّن تصميمًا مختلفًا فعلًا بمعرفة صفرية: يولّد متصفحك مفتاح AES-256-GCM عشوائيًا ويشفّر به الملفات قبل رفع أي شيء. لا يُرسَل هذا المفتاح إلى الخادم أبدًا — بل يوجد فقط في جزء عنوان الرابط (URL fragment)، وهو الجزء الذي يلي #، والذي لا ترسله المتصفحات أبدًا. ينتهي الأمر بالخادم حاملًا نصًا مُشفَّرًا لا سبيل له إلى فك تشفيره، إضافة إلى مدة انتهاء صلاحية تختارها أنت: ساعة واحدة، أو يوم واحد، أو 3 أيام، أو 7 أيام، أو حتى 14 يومًا حسب باقتك، أو الحذف بعد أول تنزيل مكتمل.

عبر الشبكات يستخدم تطبيق Relayium في المتصفح TURN حسب التصميم: ينقل المُرحِّل نصًا مشفّرًا من الطرف إلى الطرف، لكنه لا يتلقى المفتاح أبدًا ولا يستطيع قراءة الملف أو فك تشفيره.

لا يطلب أيٌّ من هذا أن تصدّق ادّعاءً على عِلّاته: شيفرة عميل Relayium وخادمه مفتوحة المصدر بموجب رخصة AGPL-3.0، فيمكن قراءتها وتدقيقها بدلًا من تصديقها على عِلّاته.

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

التشفير ليس القصة كلها — لا تزال بعض العادات مهمة

يحمي التشفير القوي الملف أثناء نقله وأثناء تخزينه، لكنه لا يمنعك من إرسال رابط إلى العنوان الخطأ — تعامل مع رابط المشاركة كأنه الملف نفسه، ولا تنشره في مكان عام.

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

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

حين لا يعطيك الفحص جوابًا واضحًا

ثلاثة مواضع يتعثّر الناس عندها. وفي كل حالة منها يكون الغموض نفسه ذا دلالة.

ما تصادفه، وما تفحصه، وماذا يعني

تُظهر لوحة الشبكة رفعًا كبيرًا ولا تستطيع معرفة ما بداخله.

https://relayium.com/   # developer tools, Network panel, during a transfer

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

لا يوجد رمز تحقّق، فلا يمكن تنفيذ البند الثالث.

https://relayium.com/   # a stored link has no second live endpoint to compare against

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

الشفرة مفتوحة لكنك لا تقرأ اللغة المكتوبة بها.

https://github.com/relayium/relayium   # is the claim falsifiable at all

لست مضطرًا. فالسؤال الذي يجيب عنه هذا الفحص هو: هل الادّعاء قابل للدحض أصلًا؟ هل هناك مستودع، وهل يقابل ما هو منشور، وهل يستطيع من يقرأ تلك اللغة أن يناقضه. والادّعاء الذي لا أحد في موضع يتيح له فحصه هو نفسه النتيجة.

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

هل من الآمن إرسال ملف حسّاس بالبريد الإلكتروني؟

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

ما الذي تعنيه «المعرفة الصفرية» فعلًا؟

تعني أن الطرف الذي يخزّن بياناتك لم يُعطَ قط المفتاح اللازم لقراءتها. يحدث التشفير على جهازك قبل رفع أي شيء، ويوجد المفتاح فقط في مكان لا يراه الخادم أبدًا — مثل جزء عنوان الرابط (URL fragment) — فيكون ما يقبع على الخادم نصًا مُشفَّرًا لا يستطيع فك تشفيره بنيويًا، لا مجرد بيانات يَعِد بألّا ينظر إليها.

هل يكفي ملف مضغوط محميّ بكلمة مرور؟

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

هل يحتفظ Relayium بنسخة من ملفاتي؟

في الوضع الفوري لا يحتفظ Relayium بنسخة على الخادم أو بسجل للنقل: داخل شبكة LAN نفسها يتصل WebRTC مباشرةً، أما جلسات المتصفح عبر الشبكات فتستخدم TURN حسب التصميم لنقل نص مشفّر من الطرف إلى الطرف لا يستطيع المُرحِّل قراءته أو فك تشفيره. أما بالنسبة لرابط مُخزَّن، فيحتفظ الخادم فقط بنص مُشفَّر لا يستطيع قراءته، إلى أن تنتهي صلاحية الرابط أو يُنزَّل مرة واحدة إذا اخترت الحذف بعد القراءة.

هل أحتاج إلى حساب لإرسال ملف أو استقباله؟

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

أتتساءل إن كانت أداة ما تحمي فعلًا ما تدّعي حمايته؟ ابدأ عملية نقل، وفعِّل التحقّق المتقدّم، وشاهد رمز التحقق ورابط المعرفة الصفرية بنفسك.

جرّب Relayium الآن