أسئلة مكررة
- لماذا هذا الموقع مترجم بشكل سيئ؟ ⎃
- ما مدى أمان هذه الخدمة؟
- لماذا تلقيت رابطًا هنا مع خيار فك تشفير رسالة؟
- قمت بحذف كل شيء مقدم لهذا الموقع؟
- لماذا استخدام هذه الخدمة؟
- هل هذه خدمة مراسلة؟
- ما هي حالات الاستخدام المقصودة؟
- ما الذي يجب عدم استخدام هذه الخدمة؟
- لماذا لا تستخدم فقط PGP / Signal / OMEMO / Matrix / إلخ؟
- ما هي المتطلبات الموجودة؟
- هل يمكن للمتلقي عمل نسخة من الرسالة؟
- هل تم جمع أي معلومات شخصية؟
- ما هي المعلومات التي يتم تسجيلها؟
- ماذا تفعل لتأمين الخوادم؟
- ما هي مخاطر الأمان الموجودة عند استخدام هذا الموقع؟
- ماذا تفعل حيال هجمات man-in-the-middle (MITM)؟
- ما هي المزايا التي تقدمها امتدادات المتصفح؟
- كيف يمكنني التأكد من أن أي شيء يتم إرساله مشفر من طرف إلى طرف؟
- كيف يعمل التشفير من طرف إلى طرف على هذا الموقع؟
- يمكن أن تكون كلمة مرور فك التشفير في URL؟
- لكن كلمة مرور فك التشفير لا يجب أن تكون في URL؟
- هذه الخدمة لا توصل الرابط للمتلقي؟
- كيف يمكنني حماية خصوصيتي قدر الإمكان أثناء استخدام هذه الخدمة؟
- ماذا لو كنت لا أثق في الولايات المتحدة؟
- ماذا تفعل لمنع البريد العشوائي؟
- لماذا يوجد خيار لمطالبة المستلم بإكمال اختبار CAPTCHA؟
- من يقوم بتشغيل هذه الخدمة ولماذا هي مجانية؟
- كيف يمكنني الوثوق في إجابات الأسئلة أعلاه؟
لماذا هذا الموقع مترجم بشكل سيئ؟ ⎃
آسف ، لكن المؤلفين الحاليين يتحدثون الإنجليزية فقط. نحن بحاجة للمساعدة في ترجمة هذا المشروع إلى لغات أخرى. كوسيلة بسيطة وغير مكلفة لجعل هذه الخدمة متاحة للأشخاص الذين لا يتحدثون الإنجليزية ، فإننا نستخدم الترجمة الآلية. عادةً ما تكون النتائج مقبولة ، ولكنها قد تؤدي إلى صياغة غريبة أو حتى معلومات غير دقيقة تمامًا. يمكنك مساعدتنا في تحسين التجربة للجميع - يرجى تقديم الترجمة الصحيحة .
ما مدى أمان هذه الخدمة؟
لقد اتخذنا العديد من الخطوات لجعل هذه الخدمة آمنة للاستخدام المقصود منها . قبل أن نتجاوز هذه الخطوات ، من المهم أن نفهم ما يلي:
- في حين أننا غير قادرين على قراءة رسالتك بسبب التشفير من طرف إلى طرف ، فإن الارتباط الافتراضي الذي تم إنشاؤه يحتوي على كلمة مرور / مفتاح فك التشفير ؛ وبالتالي ، يمكن لأي شخص لديه الرابط قراءة رسالتك - بما في ذلك أي شخص قادر على اعتراضها.
- هذه الخدمة هي مجرد أداة للسماح بإرسال اتصالات أقل ديمومة (مثل الرسائل المشفرة التي يتم حذفها عند الاسترجاع) عبر وسائل النقل التقليدية الأكثر ديمومة (مثل البريد الإلكتروني / الرسائل النصية / الرسائل الفورية / موقع الويب / إلخ). وهذا يعني أن أية مشكلات تتعلق بالأمان / الخصوصية متأصلة في النقل المختار (مثل البريد الإلكتروني) يتم توارثها عند استخدام هذه الأداة .
- هناك حلول أخرى متوفرة توفر أمانًا أفضل وفقًا لاحتياجاتك وبيئتك. الميزة الرئيسية التي تقدمها هذه الخدمة مقارنة بالآخرين ، هي متطلبات أقل بكثير للمستلم (أي أنهم يحتاجون فقط إلى متصفح ويب والقدرة على النقر فوق ارتباط).
- بينما يكون الإعداد الافتراضي هو حذف الرسائل عند الاسترداد ، فلا يوجد ما يمنع المستلم من عمل نسخة . ضع في اعتبارك أن هذا ينطبق على جميع حلول الرسائل المؤقتة - إذا تمكن المستلم من رؤية الرسالة ، فيمكن نسخها.
- يمكن لجميع اتصالات الإنترنت أن تعرض خصوصيتك للخطر - فأنت تتاجر ببعض الأمان من أجل الراحة.
- يعد الويب بيئة مليئة بالتحديات عندما يتعلق الأمر بالأمان بسبب بعض المشكلات الأساسية - وهذا ينطبق على جميع مواقع الويب. ومع ذلك ، فإن الاعتماد على الويب يجعل التحقق من مطالبتنا بأنه لا يمكننا قراءة رسالتك بشكل أسهل .
- هذا الموقع وقاعدة البيانات الخاصة به مستضافة في الولايات المتحدة. نحن نستخدم Cloudflare ، وهي شركة مقرها في الولايات المتحدة ، كشبكة توصيل المحتوى الخاصة بنا (كل حركة مرور الويب تعبر هذه الشبكة).
- لا يتطلب استخدام الخدمة أي معلومات شخصية (مثل الاسم / البريد الإلكتروني / الهاتف / إلخ). لا يوجد نظام حساب (مثل تسجيل الدخول / كلمة المرور / إلخ) ؛ لذلك ، لا يمكن لأي خرق للبيانات تسريب هذه المعلومات.
- جميع محتويات الرسائل مشفرة من طرف إلى طرف . بمعنى آخر ، لا يتم إرسال مفتاح فك التشفير / كلمة المرور إلينا مطلقًا. لذلك ، لا نملك نحن ، أو أي شخص آخر يمتلك قاعدة البيانات ، أي وسيلة لفك تشفير محتوى الرسائل وعرضه.
- كل إدخال في قاعدة البيانات الخاصة بنا له فترة زمنية تتراوح من دقيقة واحدة إلى أسبوعين (الافتراضي هو أسبوع واحد). بمجرد مرور هذا الوقت ، يتم حذف السجل تلقائيًا. لذلك ، سيتم حذف أي معلومات في قاعدة البيانات الخاصة بنا بعد وقت قصير من إنشائها .
- نحن نحتفظ فقط بآخر 24 ساعة من سجلات خادم الويب . يتم تجزئة أي معلومات IP مخزنة في قاعدة البيانات بشكل آمن مما يجعل من المستحيل استخراج عنوان IP الأصلي.
- جميع الكودات التي تدعم هذه الخدمة مفتوحة المصدر ومتاحة للمراجعة. يمكنك بسهولة رؤية الكود الذي يقوم بتشغيل التشفير - والذي يكون قصيرًا ومختصرًا ومعلقًا عن قصد.
- يتم اتخاذ عدد من الاحتياطات الفنية للمساعدة في تعزيز الأمن - وبعضها يشمل:
- موقع الويب هذا بالكامل بخلاف / api ثابت ولا يدعم كود الخادم في الصفحات (مثل PHP / JSP / ASP / إلخ.)
- يتم استخدام Web Crypto API ، وهو جزء من المتصفح ، لتشفير كل محتوى الرسائل.
- يتم استخدام TLS لتشفير الاتصالات بين متصفحك وخوادمنا. يساعد في ضمان عدم اعتراض الكود أو تعديله أثناء النقل. TLS 1.3 مدعوم ، لكننا ندعم أيضًا TLS 1.2 للأجهزة الأقدم. تم تعطيل الإصدارات القديمة من TLS لأنها ليست آمنة.
- تتم مراقبة سجلات شهادة الشفافية بحثًا عن أخطاء في الشهادة. بالإضافة إلى ذلك ، ننشر سياسة ترخيص المرجع المصدق (CAA) لتقليل مخاطر إساءة استخدام الشهادات غير المقصودة أو الضارة.
- نحن نستخدم HTTP Strict Transport Security (HSTS) لضمان اتصال المتصفحات دائمًا بخوادمنا باستخدام بروتوكول TLS. بالإضافة إلى ذلك ، نقوم بتضمين نطاقاتنا في قوائم التحميل المسبق .
- يتم فرض سياسة أمان المحتوى الصارمة لمنع هجمات البرمجة النصية عبر الموقع (XSS) .
- من خلال استخدام سياسة الموارد المشتركة ، وسياسة التضمين عبر الأصول ، وسياسة الفتح عبر الأصل ، فإننا نمنع كود المصدر المتقاطع من أجل المساعدة في التخفيف من هجمات القنوات الجانبية التخمينية مثل Specter و Meltdown. يوفر هذا أيضًا الحماية ضد الطلبات التي يحتمل أن تكون ضارة من مصادر أخرى عن طريق عزل سياق الاستعراض حصريًا إلى المستندات ذات الأصل نفسه.
- نحن نستخدم سياسة أذونات لمنع المتصفح من تحميل الموارد التي قد تعرض خصوصيتك للخطر مثل موقعك وكاميرا الويب والميكروفون وما إلى ذلك.
- يتم استخدام DNSSEC في جميع المجالات الخاصة بنا للمساعدة في التخفيف من هجمات MITM المستندة إلى DNS.
- نتخذ عددًا من الاحتياطات لتأمين الخادم.
- لم يتم تحميل أي رمز تابع لجهة خارجية (مثل jQuery) ويتم تحميل عدد قليل جدًا من الموارد (المضي قدمًا وافتح علامة التبويب Network في Dev Tools للتحقق) - وهذا يقلل الجهد المطلوب للتدقيق. الاستثناء الوحيد هو إذا كان اختبار CAPTCHA مطلوبًا - يتم تحميل رمز جهة خارجية من hCaptcha . ومع ذلك ، يتم تحميل كود hCaptcha على عنوان URL الخاص به داخل قواعد CSP الخاصة به وليس لديه في أي وقت أي وصول إلى أي شيء له علاقة برسالة.
- كوسيلة للمساعدة في الحماية ضد هجمات MITM ، تتوفر ملحقات المستعرض .
لماذا تلقيت رابطًا هنا مع خيار فك تشفير رسالة؟
نعتذر إذا كانت هناك أخطاء في هذه الترجمة . تقوم هذه الخدمة ببساطة بتمرير رسالة مشفرة من نقطة إلى أخرى وأنت المستلم. سيتم حذف الرسالة قريبا. مشغلي هذه الخدمة ليس لديهم طريقة لقراءة محتويات الرسالة. عادةً ما يستخدم شخص ما هذه الخدمة عندما لا يريد أن تظل محتويات الرسالة داخل قواعد بيانات / أجهزة / خدمات / ملفات / إلخ. كما هو معتاد عند إرسال بريد إلكتروني / رسالة فورية / نص / إلخ. إذا قررت فك التشفير ، فيرجى مراعاة ما يلي:
- من المحتمل أن يتم حذف الرسالة فور إرسالها إلى جهازك لفك تشفيرها. هذا يعني أنه بعد النقر فوق الزر لفك تشفير الرسالة ، لم يعد لدينا نسخة لإرسالها إليك مرة أخرى لاحقًا.
- نحن نحذف بشكل منهجي جميع المعلومات الواردة. سيتم حذف الرسائل في أي مكان ما بين دقيقة إلى أسبوعين بعد إنشائها - بغض النظر عما إذا تم فك تشفير الرسالة أم لا. بمعنى آخر ، إذا كنت بحاجة إلى قراءة الرسالة ، فلا تنتظر وقتًا طويلاً لفك تشفيرها.
- يعتقد المرسل على الأرجح أنه يجب التعامل مع محتويات الرسالة بعناية. ربما أشاروا إلى أنهم لا يريدون عمل نسخ. يرجى احترام رغباتهم.
- إذا طُلب منك كلمة مرور لفك تشفير رسالة ، فلا تغلق نافذة / علامة تبويب المتصفح. حسب النقطة الأولى في هذه القائمة ، من المحتمل ألا نتمكن من إرسال نسخة أخرى لاحقًا. ما عليك سوى ترك نافذة / علامة تبويب المتصفح مفتوحة حتى تتمكن من إدخال كلمة المرور. إذا أدخلت كلمة مرور غير صحيحة ، فسيُطلب منك مرة أخرى. يجب إدخال كلمة المرور بدقة. ضع في اعتبارك أنه من أجل تلبية متطلبات اللغات وكلمات المرور المختلفة ، فإننا نقبل العديد من الأحرف المختلفة في كلمات المرور.
قمت بحذف كل شيء مقدم لهذا الموقع؟
صحيح لشعار سلة المهملات الخاص بنا ... يتم حذف كل شيء بعد وقت قصير من استلامه. يتم حذف كل شيء تلقائيًا - يتم كتابته في الخادم. فكر في الأمر بهذه الطريقة - هناك فئتان من المعلومات المقدمة:
- الرسائل المشفرة التي ليس لدينا وسيلة لفك تشفير محتوياتها
- معلومات أخرى متأصلة في إرسال أي شيء على الويب (مثل عنوان IP الخاص بك ، وما إلى ذلك)
- كم من الوقت يجب أن نحتفظ بالرسالة إذا لم يسترجعها أحد (تتراوح من دقيقة واحدة إلى أسبوعين - الافتراضي إلى أسبوع واحد).
- كم مرة يتم استرداد الرسالة (تتراوح من 1 إلى 100 مرة - الإعدادات الافتراضية لمرة واحدة)
لماذا استخدام هذه الخدمة؟
هذه الخدمة هي أداة للمساعدة في جعل الرسائل التي ترسلها / تستقبلها أقل ديمومة. يتم تخزين معظم ما تتواصل معه على الإنترنت (الدردشات والنصوص ورسائل البريد الإلكتروني وما إلى ذلك) ونادرًا ما يتم حذفه. في كثير من الأحيان ، عندما تقوم بحذف شيء ما ، فإنه لا يتم حذفه فعليًا ولكن يتم تمييزه على أنه محذوف ولم يعد معروضًا لك. تتراكم اتصالاتك الإجمالية عامًا بعد عام في قواعد البيانات وعلى الأجهزة التي لا يمكنك التحكم فيها. حتمًا ، يتم اختراق واحدة أو أكثر من المنظمات / الأشخاص / الأجهزة التي تخزن اتصالاتك ويتم تسريب معلوماتك. هذه المشكلة منتشرة للغاية لدرجة أن هناك الآن العديد من مواقع الويب التي تتعقب المؤسسات التي تم اختراقها وتسريب بيانات المستخدم. تعد الرسائل المؤقتة المشفرة من طرف إلى طرف حلاً بسيطًا للمساعدة في جعل بعض اتصالاتك أقل ديمومة. كل رسالة يتم إرسالها إلى هذا الموقع لها فترة زمنية تتراوح من دقيقة واحدة إلى أسبوعين - بمجرد مرور هذا الوقت ، يتم حذف الرسالة. علاوة على ذلك ، فإن الإعداد الافتراضي هو حذف أي رسالة بمجرد أن يستردها المستلم. بالإضافة إلى ذلك ، يتم تشفير جميع الرسائل من جهازك وصولاً إلى جهاز المستلم. الهدف الرئيسي من استخدام التشفير من طرف إلى طرف هو إزالة قدرتنا على قراءة أي رسائل مرسلة وبالتالي إزالة بعض متطلبات الثقة. والنتيجة النهائية هي أنه أصبح من السهل الآن إرسال رسالة مشفرة عبر رابط بسيط. يتم حذف هذه الرسالة إما بعد وقت قصير من إرسالها أو عند الاسترداد. لا تحتاج إلى تثبيت / تكوين برنامج خاص. ليس عليك إنشاء حساب أو تقديم أي معلومات شخصية. ليس من الضروري أن يكون المستلم في جهات الاتصال الخاصة بك أو حتى يعرف عن هذه الخدمة - وهو المطلب الوحيد الذي يمكنه من النقر فوق ارتباط.
هل هذه خدمة مراسلة؟
لا ، هذه الخدمة مصممة لتكمل خدمات المراسلة الحالية مثل الرسائل الفورية / البريد الإلكتروني / الرسائل النصية / إلخ. من خلال إضافة إمكانية منع تخزين الرسائل المرسلة لفترة طويلة. لا نقوم بتسليم الرابط الذي تم إنشاؤه إلى المستلم .
ما هي حالات الاستخدام المقصودة؟
إذن ما هي بعض السيناريوهات التي يكون من المناسب فيها استخدام هذه الخدمة؟ في حين أن لكل شخص احتياجات ومتطلبات مختلفة عندما يتعلق الأمر بالخصوصية والأمان ، فقد وجدت شخصيًا السيناريوهات التالية كحالات استخدام مناسبة:
- لقد كنت تتواصل عبر منتدى ويب محلي حول مسارات ركوب الدراجات الجبلية في المنطقة وأحيانًا تلتقي بأشخاص في المنتدى للتحقق من مسارات جديدة معًا. يريد شخص ما من المنتدى اصطحابك من مكانك إلى مرافقي السيارات إلى درب في نهاية هذا الأسبوع. لا تريد أن يظل عنوان منزلك موجودًا في قاعدة بيانات منتدى موقع الويب هذا إلى الأبد. ما عليك سوى إرسال العنوان عبر هذه الخدمة - الرابط هو الموجود في قاعدة بيانات منتدى موقع الويب ، ولكن بمجرد قراءته من قبل المستلم ، يتم حذف الرسالة / العنوان.
- تحتاج إلى إرسال تسجيل دخولك إلى Netflix لأخيك لأن ابنة أختك تدفعه إلى الجنون بسبب إغلاق COVID ولا يزال ليس لديه حساب خاص به. أنت لا تهتم كثيرًا بتسجيل الدخول هذا ، ولكن أخوك سيئ بشكل خاص فيما سأطلق عليه للتو "النظافة الرقمية" وقد أجرى العديد من التجارب مع عمليات تسجيل الدخول والبرامج الضارة المخترقة. فشلت المحاولات اللاحقة لحمله على تنظيف أفعاله وحتى تثبيت رسائل آمنة له. ربما يكون إرساله عبر رسالة نصية هو الخيار الأفضل على الأرجح (للأسف) ، لكنك غير مرتاح لوجود تسجيل الدخول هذا في سجل الرسائل الخاص به بسبب التجربة السابقة. يرضي استخدام هذه الخدمة لإرسال تسجيل الدخول عبر رابط في رسالة نصية عدم السماح بتسجيل الدخول إلى الأبد في سجل الدردشة.
- أنت تعمل أحيانًا في مكتب به العديد من المستأجرين المشتركين الذين يأتون ويذهبون في جميع الأوقات. تتوفر شبكة WiFi للاستخدام ، ولكن يتم تغيير كلمة المرور كل أسبوع نظرًا لوجود مشكلات في إساءة الاستخدام. يسأل العديد من المستأجرين عبر البريد الإلكتروني / الرسائل النصية عن كلمة مرور WiFi على الرغم من وجودها في مكتب الاستقبال لأن معظمهم لا يدخلون عبر المدخل الرئيسي الأمامي. باستخدام هذه الخدمة ، يمكن لمدير المكتب إرسال كلمة مرور WiFi عبر رابط في رسالة بريد إلكتروني / رد نصي يرضي عدم ترك كلمة المرور باقية ، ويسمح أيضًا للمستلم بنسخ كلمة المرور على الفور عبر زر نسخ وهو أقل إزعاجًا على الأجهزة المحمولة.
- يسألك أحد مزودي الاستضافة عن تفاصيل حول خادم أبلغت عنه أنه يظهر علامات على وجود محرك أقراص ثابت يبدو أنه معطوب. بعض المعلومات التي يحتاجونها حساسة بعض الشيء - فأنت لا تريد أن تبقى إلى الأبد في نظام تذاكر الطرف الثالث الذي يستخدمونه. باستخدام هذه الخدمة ، يمكنك إرسال المعلومات إلى فنيي الدعم دون أن تكون مقيمًا في نظام التذاكر. نظرًا لأن العديد من الفنيين قد يحتاجون إلى الإشارة إلى المعلومات عدة مرات ، فقم بتعيين عدد مرات القراءة للعيش أكبر من 1 (أي ربما 20) بحيث لا يتم حذف الرسالة عند الاسترداد الأول.
- تحتاج إلى إرسال رسالة خاصة إلى مستخدم آخر على Reddit لإخباره برقم هاتفك حتى يتمكن من الاتصال بك. لقد قام Reddit ، مثل العديد من مقدمي الخدمات الآخرين ، بتسريب معلومات المستخدم في الماضي ولا تريد أن يكون رقم هاتفك موجودًا في قاعدة بيانات Reddit لسنوات حتى التسريب التالي. ببساطة أرسل رقم هاتفك عبر هذه الخدمة.
- تقوم زوجتك بإرسال رسائل إليك أثناء وجودك في العمل تريد تسجيل الدخول إلى الأداة المساعدة لأن صديقتها جربت للتو برنامجًا جديدًا وفر مالها على فاتورة الكهرباء الخاصة بها وتريد التحقق من ذلك. هناك مدير كلمات مرور عائلية مشترك قمت بتذكيرها به ، لكنها تريد منك فقط إرسال معلومات تسجيل الدخول. يتم استخدام OMEMO للمراسلة الفورية مع زوجتك ، وبالتالي تشعر بالثقة في أن نقل الرسائل آمن ؛ ومع ذلك ، يتم تخزين محفوظات الدردشة نفسها غير مشفرة. لا يتوخى زوجك / زوجتك الحذر دائمًا بشأن التنزيلات ورسائل البريد الإلكتروني وما إلى ذلك ، وتعد فواتير الخدمات حساسة بعض الشيء حيث يمكن استخدامها لسرقة الهوية لإثبات الإقامة. يمكنك إرسال تفاصيل تسجيل الدخول إليها باستخدام هذه الخدمة لتجنب تخزين نسخة على جهاز الكمبيوتر الخاص بها.
ما الذي يجب عدم استخدام هذه الخدمة؟
لا ينبغي استخدام هذه الخدمة للحصول على معلومات حساسة للغاية لجميع الأسباب الموضحة في هذه الأسئلة الشائعة. فيما يلي بعض الأمثلة لما لا يجب فعله:
- لا تستخدم هذه الخدمة لجعل نقل الرسائل غير اللائق "أكثر أمانًا". نظرًا لأن الإعداد الافتراضي هو تضمين كلمة المرور في عنوان URL الذي يمكنه قراءة الرسالة ، يمكن لأي شخص لديه الرابط قراءة الرسالة. كما ذكر أعلاه ، فإن أية مشكلات تتعلق بالأمان / الخصوصية ملازمة للنقل المختار (أي نص) يتم توارثها عند استخدام هذه الأداة. لذلك ، على سبيل المثال ، إذا كنت لا تفكر مطلقًا في استخدام البريد الإلكتروني لإرسال معلومات محددة نظرًا لطبيعته الحساسة ، فيجب ألا تستخدم هذه الخدمة "لتأمين" هذا الجزء من البريد الإلكتروني.
- لا تستخدم هذه الخدمة لضمان عدم عمل نسخة من الرسالة. لمجرد أننا نحذف نسختنا من الرسالة المشفرة فور استرجاعها ونزيد من صعوبة نسخها ، لا يعني ذلك أنه لا يمكن نسخ الرسالة. ماذا لو التقط المستلم صورة لشاشتهم؟ ماذا لو كتبوا الرسالة؟ في النهاية ، إذا كان المستلم يمكنه قراءة الرسالة - فيمكن عمل نسخة.
- لا تستخدم هذه الخدمة لضمان عدم إمكانية تتبع الرسالة إليك. تعتمد هذه الخدمة على مزود آخر لنقل الرسائل (مثل البريد الإلكتروني ، والدردشة ، وما إلى ذلك) لتوصيل الرسالة من نقطة إلى أخرى. يمكن أن يؤدي نقل الرسائل المستخدم إلى تتبع الرسالة إليك بشكل جيد.
- لا تستخدم هذه الخدمة لإرسال أي شيء ترغب في رفض إرساله. لا يعني مجرد حذف الرسالة نفسها أن الرابط الذي يشير إلى الرسالة المحذوفة قد تم حذفه. إذا قمت بإرسال بريد إلكتروني إلى صديقك وكان جزء من هذا البريد الإلكتروني يحتوي على رابط لرسالة من هذه الخدمة ، فسيعرف القارئ العادي أن هناك شيئًا آخر في الرسالة. حتى إذا كانت الرسالة المشار إليها بالرابط قد اختفت منذ فترة طويلة - فمن الواضح أن شيئًا آخر قد تم إرساله وأنك أرسلته إلى صديقك.
لماذا لا تستخدم فقط PGP / Signal / OMEMO / Matrix / إلخ؟
إذا كنت تعرف الشخص الذي تريد إرسال رسائل مؤقتة آمنة ، وإرسالها كثيرًا ، وتوقع واجهة تشبه الدردشة ، و / أو تتوقع أن يكون لدى المستلم البرنامج المطلوب ويعرف كيفية استخدامه ، فمن المحتمل ألا يكون موقع الويب هذا هو أفضل حل. هناك خيارات رائعة مفتوحة المصدر ، تدعم E2EE ، وليست قائمة على الويب ، وحتى بعضها مثل Signal الذي يدعم أيضًا الرسائل المؤقتة. أنا شخصياً أستخدم خادم XMMP خاص و OMEMO للدردشة مع الأصدقاء المقربين والعائلة. قد يكون استخدام هذا الموقع هو الأمثل فقط إذا كنت لا تعرف البرنامج الذي يقوم المستلم بتشغيله ، أو لا تعرف رقم هاتفه / جهة الاتصال الخاصة به ، أو لا تعرف كفاءته الفنية (ولكن افترض أنه يمكنه النقر فوق ارتباط) ، أو تفضل فقط الاحتفاظ بالرسالة التي ترسلها خارج نقل الاتصال الأساسي.
ما هي المتطلبات الموجودة؟
مطلوب مستعرض ويب حديث وحديث ينفذ المعايير بشكل صحيح بما في ذلك Web Crypto API. تتضمن الأمثلة: Chrome و Firefox و Edge و Safari (حوالي 2020 أو بعد ذلك).
هل يمكن للمتلقي عمل نسخة من الرسالة؟
نعم. على الرغم من أن الرسالة قد تحذف نفسها عند الاسترداد ، لا يزال بإمكان المستلم عرض الرسالة. في أي وقت يمكن للمستقبل عرض الرسالة بالكامل ، يمكن عمل نسخة - وهذا ينطبق على جميع الاتصالات. هناك خيار يجعل الأمر أكثر صعوبة على المستلم لعمل نسخة. في هذه الحالة ، يتم تنفيذ ثلاثة معوقات للنسخ:
- تتم إزالة الزر "نسخ". يتم تعيين هذا الزر افتراضيًا للسماح للمستلم بنسخ الرسالة بأكملها في حافظته.
- تمت إزالة زر التنزيل. يتم تعيين هذا الزر افتراضيًا للسماح للمستلم بتنزيل الرسالة كملف نصي.
- تمت إزالة القدرة على تحديد النص داخل مربع نص الرسالة.
هل تم جمع أي معلومات شخصية؟
لا ندعم حسابات المستخدمين (مثل اسم المستخدم / كلمة المرور). نحن لا نجمع أي معلومات يمكن أن تحدد هويتك (مثل الاسم / العنوان / البريد الإلكتروني / الهاتف). من المحتمل أن تكون بعض المعلومات الشخصية موجودة في الرسالة التي ترسلها ، لكن ذلك مشفر وليس لدينا طريقة لقراءته يرجى مراجعة سياسة الخصوصية لدينا للحصول على التفاصيل الكاملة.
ما هي المعلومات التي يتم تسجيلها؟
يحتفظ خادم الويب الخاص بنا بما يصل إلى 24 ساعة من تنسيق السجل المشترك في جميع أنشطة الويب. يتضمن ذلك تسجيل عنوان IP الكامل لعملاء HTTP. بعد 24 ساعة ، يتم حذف هذه المعلومات المسجلة تلقائيًا. يتم نشر جميع الطلبات المرسلة إلى / api مما يعني أنه لا يتم تسجيل أي معلومات محددة للرسالة من قبل خادم الويب. بالإضافة إلى ذلك ، يتم تسجيل أي معلومات محفوظة في قاعدة البيانات بشكل فعال. جميع الإدخالات في قاعدة البيانات ، بما في ذلك عناوين IP مجهولة المصدر والمجزأة ، لها وقت انتهاء الصلاحية (TTL) وبعد ذلك يتم حذفها تلقائيًا. تختلف أوقات انتهاء صلاحية TTL بين دقيقة واحدة وأسبوعين.
ماذا تفعل لتأمين الخوادم؟
أمن الخادم هو مصدر قلق واضح. هناك مجالان رئيسيان نركز عليهما للحفاظ على أمانه:
- أولاً ، نقوم بتخزين أقل قدر ممكن لأقل قدر ممكن من الوقت بحيث إذا تم اختراق الخادم ، فإن أي تسرب للمعلومات لن يضر مستخدمينا. يتم تشفير جميع الرسائل المخزنة في قاعدة البيانات دون أي وسيلة لفك تشفيرها. لا يوجد أي شيء مخزن يربط أي رسالة بأي من مستخدمينا لأننا لا نجمع أي معلومات شخصية من مستخدمينا. جميع السجلات في قاعدة البيانات لها فترة انتهاء صلاحية (TTL) تتراوح من دقيقة واحدة إلى أسبوعين - بعد مرور هذا الوقت ، يتم حذف السجل تلقائيًا. لذلك ، تم حذف الغالبية العظمى من المعلومات التي كانت موجودة في قاعدة البيانات منذ وقت طويل.
- نتخذ عددًا من الإجراءات لمنع الاختراق واحتواء أي حل وسط قد يحدث:
- يتم تشغيل خادم الويب ، nginx ، في حاوية معزولة كمستخدم لا يتمتع بامتيازات دون حق الوصول للكتابة إلى أي شيء بخلاف السجلات. تعمل الحاوية ضمن سياق SELinux الخاص بها مما يمنع أي تغييرات في نظام الملفات أو سهولة الهروب من الحاوية. لا يوجد دعم لـ PHP / ASP / JSP / إلخ. - مجرد خدمة موارد ثابتة.
- تمت كتابة الكود قيد التشغيل / api في Go مما يجعله مرنًا إلى حد ما لمواجهة نقاط الضعف في تجاوز سعة المخزن المؤقت (ناقل هجوم شائع). يتم تشغيل عملية Go أيضًا في حاوية معزولة كمستخدم غير مفوض دون حق الوصول للكتابة إلى أي شيء آخر غير قاعدة البيانات. تعمل الحاوية ضمن سياق SELinux الخاص بها مما يمنع أي تغييرات في نظام الملفات أو سهولة الهروب من الحاوية. قاعدة البيانات ، badgerdb ، هي جزء من عملية Go (لا تبعية / عملية قاعدة بيانات خارجية).
- يتمثل الخطر الرئيسي لاختراق الخادم في أن المهاجم يمكنه تعديل الملفات بطريقة من شأنها أن تعرض خصوصية / أمان مستخدمينا للخطر. هناك عملية مخصصة تراقب جميع ملفات موقع الويب بحثًا عن أي تغييرات وتنبهنا على الفور في حالة حدوث أي تغيير.
- كل الوصول الإداري محمي ومقتصر على الشبكات المصرح بها.
ما هي مخاطر الأمان الموجودة عند استخدام هذا الموقع؟
قبل معالجة بعض هذه المخاطر على وجه التحديد ، أعتقد أن تشبيهًا شبه موجز قد يساعد في تلخيص المخاطر في استخدام أي اتصالات عبر الإنترنت. تخيل أن أي نظام آمن فقط مثل أضعف حلقة في سلسلة. تخيل الآن سيناريو حيث يوجد شخصان في غرفة مغلقة بدون أي وسيلة لرؤية أو سماع أو تسجيل أي شيء يفعلونه. سوف يقوم أحدهم بإرسال رسالة إلى الآخر الذي سيحرقها عند قراءة الرسالة. إذا رغب شخص ما خارج تلك الغرفة في الحصول على الرسالة التي تم تمريرها بالفعل ، فسيكون ذلك صعبًا. ما هو أضعف رابط للحصول على الرسالة؟ لا يوجد الكثير من الروابط للاختيار من بينها - إنها سلسلة قصيرة جدًا. تخيل الآن أنه عندما ترسل رسالة على الإنترنت مفادها أن هناك ما لا يقل عن مليون رابط في السلسلة - العديد منها ضعيف - والعديد منها خارج عن سيطرتك تمامًا - وهذا هو الواقع.
يمكن أن يساعد استخدام التشفير بشكل كبير في حل مشكلة الارتباط المليون المذكورة أعلاه ومن السهل إغراء التفكير في أن أنظمة E2EE المصممة جيدًا تقدم الحل النهائي. ومع ذلك ، فإن هذا التفكير قد يوقعك في مشكلة ، لأن المهاجم عادة ما يلاحق الروابط الأضعف في النظام. على سبيل المثال ، ربما يكون من الأسهل بكثير الاستيلاء على هاتفك أو جهاز الكمبيوتر وإعداد مسجل إدخال لقراءة كل شيء تكتبه فقط بدلاً من تكسير الرسائل المشفرة عبر السلك. خلاصة القول هي أنه إذا تم تكليفي بإيصال سر ذي أهمية حيوية / حاسمة ، فسأستخدم الاتصالات الإلكترونية فقط كطريقة الملاذ الأخير.
لذلك هناك مخاطر أمنية عند استخدام أي اتصالات ، لكنك ما زلت تستخدم متصفح الويب للخدمات المصرفية ، وشراء الأشياء ، والبريد الإلكتروني ، وما إلى ذلك. إنها مخاطرة مقبولة بالنسبة للراحة الضخمة المكتسبة. السؤال الحقيقي هو ... ما هي المخاطر الأمنية شبه الخاصة بهذا الموقع؟ يتبادر إلى الذهن عدد قليل:
- ربما يكون الخطر الأكبر والأكثر تميزًا لهذه الخدمة هو أن مستخدمينا لن يستخدموا الحكم الجيد عند التمييز بين ما هو مناسب للإرسال وما هو غير مناسب للإرسال . أحيانًا يكون التمييز بين "أنا مرتاح لإرسال هذه المعلومات عبر البريد الإلكتروني - أتمنى فقط حذف البريد الإلكتروني بعد القراءة" و "لست مرتاحًا لإرسال هذه المعلومات عبر البريد الإلكتروني - البريد الإلكتروني وسيلة نقل غير مناسبة" قد يكون دقيقًا جدًا.
- هناك دائمًا خطر يتمثل في أن مشغلي هذا الموقع هم في الواقع جهات فاعلة سيئة تجذب الأشخاص لاستخدام الخدمة للحصول على هدف نهائي مظلم. لقد صادفنا أمرًا موثوقًا به - اجعل كل شيء سهلًا ومجانيًا - احصل على الكثير من الأشخاص الذين يستخدمون الخدمة - طوال الوقت بقصد شرير. بوهاهاهاها! كيف يمكن أن تثق بنا؟
- هناك احتمال أن يحتوي الكود الخاص بنا على أخطاء تؤثر على الأمان أو أننا لم نفكر في الأمور جيدًا وأن أوجه القصور لدينا تعرض مستخدمينا الآن لخطر غير ضروري. نحن بالتأكيد لا نأمل - لكن لا يمكننا استبعاد ذلك.
- على عكس عمالقة التكنولوجيا (مثل Google / Facebook / Whatsapp) الذين لديهم تيرابايت من البيانات المشفرة التي تتدفق باستمرار داخل وخارج شبكاتهم الهائلة ، حيث يسهل دمج الاتصالات الخاصة مع حركة المرور الأخرى ، والخدمات المركزية المستقلة (مثل Signal ، Telegram ، ونحن) تبرز. من السهل على مشغل الشبكة أو حتى مؤسسة / حكومة كبيرة أن ترى أن عنوان IP xxxx يستخدم خدمة XYZ.
- على الرغم من عدم تحديد هذا الموقع حقًا ، نظرًا لأنه يمكن استخدامه ضد أي موقع ويب ، فإن هجمات man-in-the-middle (MITM) تعد مصدر قلق صحيح .
ماذا تفعل حيال هجمات man-in-the-middle (MITM)؟
من المحتمل أن يكون جميع مستخدمي مواقع الويب ضحية لهجوم MITM - لا يختلف هذا الموقع عن الآخرين على الويب في هذا الصدد. هجوم MITM هو عندما يكون المهاجم قادرًا على اعتراض وتعديل الاتصالات بين متصفح المستخدم وخادم الويب الخاص بالموقع. يسمح هذا للمهاجم بتعديل أي كود / محتوى للموقع مع استمرار الظهور للمستخدم النهائي على أنه الموقع الذي اعتادوا عليه. نتخذ بعض الإجراءات لجعل هجوم MITM أكثر صعوبة:
- يتم استخدام HSTS لإجبار المتصفحات على الاتصال عبر TLS فقط. تم تكوين خادمنا لتجاهل الاتصالات بخلاف TLS بخلاف إعادة التوجيه. يتم دعم TLS 1.2 أو أعلى فقط.
- يتم استخدام DNSSEC للتوقيع على منطقة المجال الخاص بنا. قد يوقف هذا انتحال DNS هجمات MITM المطبقة إذا كان المستخدم يستخدم محلل تكراري مدرك لـ DNSSEC.
- نحن نستخدم خدمة لمراقبة هيئات إصدار الشهادات التي تصدر أي شهادات TLS غير مصرح بها تشير إلى مجالنا.
- لقد نشرنا ملحقات المتصفح لدعم تشفير الرسائل باستخدام الرمز المخزن على جهاز المستخدم النهائي.
ما هي المزايا التي تقدمها امتدادات المتصفح؟
نحن نقدم ملحقات المتصفح كوسيلة لتوفير راحة إضافية وأمان إضافي. ببساطة ... تجعل الإضافات إرسال الرسائل المؤقتة أسرع وأسهل. يتم أيضًا اكتساب بعض الأمان لأن جميع التعليمات البرمجية المستخدمة لتشفير وتحضير رسالة مخزنة محليًا داخل الامتداد. نظرًا لأنه يتم تخزين الرمز محليًا ، فإن هذا يوفر للمرسل بعض الحماية ضد هجمات MITM . ومع ذلك ، تجدر الإشارة إلى أنه في حين أن الامتدادات توفر مزيدًا من الحماية ضد هجوم MITM الذي يضر بمحتويات الرسالة ، إلا أن هجوم MITM يمكن أن يظل فعالاً (أي لتحديد عنوان IP الخاص بالمرسل في حالة عدم استخدام TOR / VPN / إلخ.).
كيف يمكنني التأكد من أن أي شيء يتم إرساله مشفر من طرف إلى طرف؟
على عكس العديد من عملاء الدردشة المشفرين من طرف إلى طرف (E2EE) المشهورين ، من السهل جدًا رؤية ما يتم إرساله إلينا بالضبط عند إرسال رسالة. يوضح الفيديو التعليمي أدناه كيفية التأكد من عدم وجود طريقة لفك تشفير الرسائل المرسلة إلى الخادم.
أيضًا ، إذا فكرت في الأمر ، طالما أننا لسنا وكالة سرية تحاول جمع الرسائل الحساسة ، فلا فائدة لنا من قدرتنا على فك تشفير الرسائل لأن امتلاك هذه القدرة يخلق مشاكل لنا فقط. نحن لا نريد حتى تخزين الرسائل - لكن تسليمها يعد شرًا ضروريًا.كيف يعمل التشفير من طرف إلى طرف على هذا الموقع؟
في الوقت الحالي ، نستخدم التشفير المتماثل (AES-GCM 256bit) مع المفاتيح المشتقة من كلمات المرور (بحد أدنى 150000 تكرار من PBKDF2 / SHA-256). لا يتم استخدام التشفير غير المتماثل نظرًا لوجود متطلبات لـ 1) بدء المرسل الاتصال 2) عدم اتصال المرسل والمتلقي بالإنترنت في نفس الوقت و 3) عدم وجود معلومات عن المستلم و 4) نحاول الحفاظ على الأشياء بسيطة جدًا وإدارة المفاتيح هي معقد. يتم استخدام واجهة برمجة تطبيقات تشفير الويب القياسية لجميع وظائف التشفير بما في ذلك RNG. في الأساس ، هذا ما يحدث:
- يختار المستخدم كلمة مرور أو يتم إنشاء واحدة تلقائيًا
- يتم إجراء استدعاء API للحصول على عدد التكرارات المطلوبة PBKDF2 / SHA-256 ( هذه الخطوة مطلوبة للتحكم في البريد العشوائي )
- يتم إنشاء ملح 32 بايت
- مفتاح مشتق من الملح وكلمة المرور
- يتم إنشاء متجه تهيئة 12 بايت (IV)
- يتم تشفير الرسالة باستخدام المفتاح + IV
- يتم إرسال عدد التكرار والملح والرابع والنص المشفر إلى الخادم (مع بعض المعلومات الأخرى مثل TTL و RTL وما إلى ذلك)
- يقوم الخادم بإرجاع معرف عشوائي يشير إلى الرسالة
- ثم يقدم المتصفح للمستخدم النهائي رابطًا يحتوي على المعرف وكلمة المرور اللذين تم إرجاعهما أو رابطًا بدون كلمة المرور (في هذه الحالة ، يجب على المستلم معرفة كلمة المرور وإدخالها)
- إذا كانت كلمة المرور جزءًا من الارتباط ، فهي موجودة في تجزئة عنوان URL ، وبالتالي لا يتم إرسالها أبدًا إلى الخادم عندما يقوم المستلم بتقديم طلب GET
- يُطلب من المستلم ما إذا كان يرغب في فك تشفير الرسالة وعرضها
- يقدم المتصفح طلبًا يحدد معرف الرسالة
- إذا طلب المرسل إكمال اختبار CAPTCHA ، فسيتم توجيه المستلم إلى عنوان URL آخر لإثبات أنه بشر (بمجرد اجتيازه ، يتم توجيهه مرة أخرى)
- يرسل الخادم الرسالة المشفرة وسيقوم افتراضيًا بحذف الرسالة في هذه المرحلة إذا كانت القراءة للعيش (RTL) واحدة
- سيقوم المستلم بفك تشفير الرسالة بكلمة المرور (وسيُطلب منك إدخال كلمة المرور إذا لم تكن موجودة في عنوان URL)
يمكن أن تكون كلمة مرور فك التشفير في URL؟
نعم. من الواضح أن هذا يؤثر على الأمان لأنه إذا كانت الطريقة المستخدمة لإرسال الرابط غير آمنة ، فإن الرسالة غير آمنة من خلال الارتباط. تقدم جميع الحلول للتخلص من هذه المشكلة خطوات وتعقيدات إضافية تؤثر على تجربة المستخدم (على سبيل المثال ، يجب إعداد الأشياء على كلا الطرفين قبل إرسال الرسالة). مخطط غير متماثل يبدأ بموجبه المستلم طلبًا لرسالة ويرسل رابط الطلب هذا يمكن أن يعمل مع مطلبنا الأساسي "كل شيء سريع الزوال" - يمكن تنفيذ ذلك. في النهاية ، إذا كان هناك طرفان سيرسلان رسائل إلى بعضهما البعض بشكل متكرر ، توجد حلول أفضل على افتراض أن كلا الطرفين يمكنه التعامل مع هذه الحلول.
لكن كلمة مرور فك التشفير لا يجب أن تكون في URL؟
صيح. إذا لم يتم تضمين كلمة مرور فك التشفير في الرابط ، فسيُطلب من المستلم كلمة المرور. إذا تم إرسال كلمة المرور بشكل آمن إلى المستلم (أو كان يعرفها بالفعل) ، فإن هذا يوفر الحماية ضد الاعتراض. ومع ذلك ، فإن العيب هو أن المستلم يجب أن يعرف كلمة المرور ويدخلها بشكل صحيح. إليك طريقة واحدة لإرسال كلمة المرور إلى المستلم والتي توفر بعض الحماية ضد الاعتراض:
- قم بتشفير كلمة المرور في رسالة بالإعدادات الافتراضية وإرسال هذا الارتباط إلى المستلم.
- عندما ينقر المستلم على الرابط ويفك تشفير الرسالة ، فإنهم يعلمون أنه لم يحصل أي شخص آخر على كلمة المرور من قبلهم لأن الرسالة التي تحتوي على كلمة المرور يتم حذفها عند الاسترداد. ومع ذلك ، إذا كان هناك هجوم MITM نشط أو إذا تم اختراق جهازك أو جهاز المستلم ، فلا يزال من الممكن لطرف آخر الحصول على كلمة المرور.
- تأكد مع المستلم من حصوله على كلمة المرور بنجاح. على سبيل المثال ، إذا أبلغك المستلم أنه عندما ذهب لاسترداد كلمة المرور ، تم حذف الرسالة بالفعل ، فأنت تعلم أن شخصًا آخر قد حصل على كلمة المرور قبل المستلم وبالتالي تم اختراق كلمة المرور ويجب عدم استخدامها.
- باستخدام كلمة المرور التي أكد المستلم أنها تمتلكها ، يمكنك الآن إرسال رسالة باستخدام نفس كلمة المرور للتشفير - ما عليك سوى مشاركة إصدار الرابط الذي لا يحتوي على كلمة المرور.
هذه الخدمة لا توصل الرابط للمتلقي؟
هذا صحيح - نحن ننشئ الرابط ونتركه للمرسل أفضل طريقة لتسليمه إلى المستلم. الهدف من هذه الخدمة هو توفير خيار يقدم استمرارية أقل في عمليات نقل الرسائل الحالية مثل البريد الإلكتروني / الدردشة / النص / إلخ. لذلك ، فإن التوقع هو أن الرابط الذي ننشئه والذي يشير إلى الرسالة المؤقتة يتم إرساله عبر نقل رسالة موجود. هذا له آثار أمنية يجب على المستخدمين فهمها. لنأخذ رسالة نصية SMS كمثال لأن هذه طريقة اتصال غير آمنة إلى حد كبير. عند استخدام هذه الخدمة لإرسال رابط رسالة مؤقتة عبر رسالة نصية ، إذا كنت تستخدم الوضع الافتراضي حيث يتم تضمين كلمة المرور في الرابط ، يمكن لأي شخص لديه الرابط قراءة الرسالة ولا يتم توفير الحماية ضد الاعتراض. لا تزال هذه الخدمة توفر اتصالاً مؤقتًا يمكن أن يعزز الخصوصية والأمان. بالإضافة إلى ذلك ، يمكنك اختيار إرسال الرابط بدون كلمة المرور وسيوفر ذلك الحماية ضد الاعتراض.
كيف يمكنني حماية خصوصيتي قدر الإمكان أثناء استخدام هذه الخدمة؟
كما تمت مناقشته في مكان آخر في هذه الأسئلة الشائعة ، على الرغم من أننا فعلنا الكثير بالفعل لحماية خصوصيتك وعلى الرغم من أننا لا نجمع أي معلومات شخصية ، يتم إرسال بعض المعلومات المتعلقة بالسجل وجمعها من قبلنا والآخرين بحكم استخدامك لمتصفح الويب. ومع ذلك ، هناك طرق متعددة لحماية خصوصيتك بشكل أكبر. إحدى الطرق المجانية للاستخدام ، استنادًا إلى البرامج مفتوحة المصدر ، والتي تعمل بشكل جيد هي استخدام متصفح Tor . تم تصميم هذا المتصفح لحماية خصوصيتك على مستويات متعددة - بما في ذلك استخدام شبكة Tor . يمكن الوصول إلى موقعنا بالفعل عبر شبكة Tor onion مما يعني أن الوصول إلى موقعنا عبر Tor لا يتطلب استخدام عقدة خروج ، مما ينفي التنصت على حركة مرور عقدة الخروج . ومع ذلك ، ضع في اعتبارك أنه حتى في هذا السيناريو ، يمكن لمزود خدمة الإنترنت الخاص بك أن يرى أنك تستخدم Tor - ولكن ليس الغرض منه. يمكنك حتى الاتصال بشبكة VPN ثم تشغيل متصفح Tor لطبقتين من إخفاء الهوية ؛ ومع ذلك ، ضع في اعتبارك أن مزود خدمة الإنترنت الخاص بك لا يزال بإمكانه رؤية أنك تستخدم VPN في هذا السيناريو - ولكن ليس الغرض منه. إذا كنت لا تريد أن يعرف مزود خدمة الإنترنت الخاص بك البروتوكولات التي تستخدمها ، فيمكنك الاتصال بشبكة WiFi عامة كبيرة مثل مكتبة ، ومدرسة ، وما إلى ذلك ، ثم استخدام متصفح Tor.
ماذا لو كنت لا أثق في الولايات المتحدة؟
تقع خوادمنا في الولايات المتحدة. بالإضافة إلى ذلك ، فإن مزود CDN الخاص بنا ، Cloudflare ، هو شركة مقرها في الولايات المتحدة. لقد حاولنا إزالة الحاجة إلى الوثوق بنا أو بالبلد الذي توجد فيه خوادمنا لمجرد أننا لا نجمع معلومات شخصية ، ولا يمكننا فك تشفير أي رسائل ، ويتم حذف كل شيء بعد وقت قصير من استلامه. ومع ذلك ، يمكننا أن نتفهم بعض عدم الثقة نظرًا لأنه قائم على الويب وخاصة إذا كنت تعيش في بلدان معينة. لدينا بعض الخطط لتقديم خيارات في أيسلندا وسويسرا للأشخاص الذين يجدون صعوبة في الوثوق بالولايات المتحدة. يرجى إخبارنا إذا كان هذا ينطبق عليك ، حيث لن يكون لدينا الدافع لتقديم بدائل ما لم يكن هناك طلب حقيقي.
ماذا تفعل لمنع البريد العشوائي؟
في أي وقت تسمح فيه لشخص ما بنشر رسالة يمكن ترحيلها عبر رابط ، فإنك تدعو مرسلي البريد العشوائي. إن كبح هذه المشكلة ليس بالأمر السهل تمامًا. لا نريد تحميل كابتشا طرف ثالث كجزء من عملية إرسال الرسائل لعدة أسباب:
- نحن نكره اختبارات CAPTCHA - فهي تستغرق وقتًا وهي مزعجة
- يمكن أن يكون تحميل جافا سكريبت من جهة خارجية أمرًا جائرًا للخصوصية والأمان
- تشغيل اختبار CAPTCHA الخاص بنا يعني أننا نشترك في لعبة لا تنتهي أبدًا من whack-a-mole
- في النهاية ، قد يرغب الأشخاص في التفاعل مع هذه الخدمة عبر واجهة برمجة التطبيقات
- زيادة عدد مرات تكرار PBKDF2 / SHA-256 المطلوبة
لا يمكن استرداد جميع الرسائل إلا لعدد قليل من المرات - وهي سمة غير جذابة لمرسلي البريد العشوائي نظرًا لأنهم يعتمدون على إرسال الكثير من الرسائل. نظرًا لأن مرسلي البريد العشوائي سيتعين عليهم إنشاء الكثير من الرسائل لأي حملة بريد عشوائي معينة - فقد اخترنا جعل هذه المهمة باهظة التكلفة من الناحية الحسابية بحيث نجعل إساءة استخدام هذه الخدمة للبريد العشوائي محاولة غير جذابة. يتم تحقيق ذلك من خلال تتبع رسائل نشر الشبكات - مقاسة من حيث إجمالي عمليات الاسترجاع الممكنة. يتم تجزئة معلومات الشبكة نفسها بشكل آمن بحيث لا يمكننا استنتاج الشبكة الحقيقية من التجزئة. نظرًا لأن شبكة معينة تنشر المزيد من الرسائل ، فإننا نرفع عدد التكرارات PBKDF2 / SHA-256 المطلوبة لنشر الرسالة التالية. ينتج عن هذا بسرعة كبيرة الكثير من وقت وحدة المعالجة المركزية المطلوب لمجرد نشر رسالة واحدة. نأمل أن تكون هذه الطريقة مناسبة للحد من إساءة استخدام البريد العشوائي وفي نفس الوقت لا تؤثر على المستخدمين الحقيقيين. - اجمع تقارير البريد العشوائي من المستخدمين عندما يستردون رسالة
يوجد زر "الإبلاغ عن الرسائل غير المرغوب فيها" أسفل الرسالة مباشرة عندما يسترد المستخدم رسالة. إذا كانت الرسالة غير مرغوب فيها ، فمن المأمول أن يستغرق البعض الثواني الثلاث المطلوبة للنقر فوق هذا الزر. عندما نتلقى تقريرًا عن رسائل غير مرغوب فيها ، فإنه ينبهنا ويؤثر أيضًا على التكرارات المطلوبة لشبكة معينة.
لماذا يوجد خيار لمطالبة المستلم بإكمال اختبار CAPTCHA؟
في حين أنه من الصحيح أننا لا نحب الكابتشا ، إلا أننا ندرك أنها تخدم غرضًا ولها وقت ومكان (على الأقل في الوقت الحالي). هذه طريقة بسيطة للمرسل للحصول على بعض التأكيد على أن المستلم إنسان وأن العمليات الآلية لا تصل إلى الرسالة.
من يقوم بتشغيل هذه الخدمة ولماذا هي مجانية؟
نحن مجرد شخصين واجهنا أحيانًا مأزق عدم وجود خيارات جيدة للمساعدة في حماية خصوصيتنا. في كثير من الأحيان كان هذا ناتجًا عن التواصل مع الأصدقاء وأفراد الأسرة الذين لم يكونوا حريصين جدًا على كيفية تعاملهم مع أجهزتهم ومعلوماتهم. حدث هذا في بعض الأحيان عند استخدام المنتديات القائمة على الويب مثل Reddit أو استخدام أنظمة الدعم المستندة إلى الويب. لقد وجدنا بعض حلول الرسائل المؤقتة المستندة إلى الويب ، ولكن لم يقدم أي منها E2EE مما يعني أننا لا نستطيع الوثوق بها. لذلك قمنا للتو ببناء الحل الخاص بنا وقررنا التخلي عنه حتى يتمكن الآخرون من الاستفادة منه.
كيف يمكنني الوثوق في إجابات الأسئلة أعلاه؟
حقًا لا يجب أن تثق في أي موقع ويب لمجرد أنه يقول أشياء معينة - من الجيد عادةً التحقق من أي ادعاءات. لقد حاولنا إزالة شرط الوثوق بنا قدر الإمكان من خلال استخدام التشفير من طرف إلى طرف. على سبيل المثال ، من السهل جدًا تدقيق أنه لا يمكننا قراءة أي رسائل نظرًا لأنها مشفرة . لقد أبقينا أيضًا شفرة جافا سكريبت لتشغيل هذا الموقع بسيطة جدًا بحيث يسهل قراءتها وفهمها. إن جعل كل الكود مفتوح المصدر يسمح للأشخاص بالتحقق مما يتم تشغيله ؛ ومع ذلك ، ضع في اعتبارك أنه لا توجد طريقة للتحقق حقًا من تشغيل الخادم. في حين أنه من الصحيح أن الكثير من متطلبات الثقة تتم إزالتها من خلال التشفير من طرف إلى طرف ، إلا أنه لا يزال عاملًا يثقله مستخدمينا كثيرًا عند اتخاذ قرار باستخدام هذه الخدمة أم لا.