أسئلة مكررة

لماذا هذا الموقع مترجم بشكل سيئ؟

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

ما مدى أمان هذه الخدمة؟

لقد اتخذنا العديد من الخطوات لجعل هذه الخدمة آمنة للاستخدام المقصود منها . قبل أن نتجاوز هذه الخطوات ، من المهم أن نفهم ما يلي:

هدفنا هو تقديم هذه الخدمة بطريقة توفر خيارات لتعزيز خصوصيتك وأمانك. فيما يلي بعض الخطوات التي اتخذناها لحماية معلوماتك:

لماذا تلقيت رابطًا هنا مع خيار فك تشفير رسالة؟

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

قمت بحذف كل شيء مقدم لهذا الموقع؟

صحيح لشعار سلة المهملات الخاص بنا ... يتم حذف كل شيء بعد وقت قصير من استلامه. يتم حذف كل شيء تلقائيًا - يتم كتابته في الخادم. فكر في الأمر بهذه الطريقة - هناك فئتان من المعلومات المقدمة:

في حالة الرسائل ، يمكنك التحكم في وقت حذفها من خلال تحديد: بشكل افتراضي ، يتم حذف كل شيء يتعلق برسالة ما بعد استرجاعها مرة واحدة أو بعد مرور أسبوع على حدوثها - أيهما يحدث أولاً. عندما يتعلق الأمر بحذف جميع المعلومات الأخرى الكامنة في إرسال أي شيء على الويب (مثل عنوان IP الخاص بك ، وما إلى ذلك) ، فإننا لا نمنحك أي تحكم في وقت أو كيفية حذفه - نحن فقط نحذفها كلها كل 24 ساعة .

لماذا استخدام هذه الخدمة؟

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

هل هذه خدمة مراسلة؟

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

ما هي حالات الاستخدام المقصودة؟

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

ما الذي يجب عدم استخدام هذه الخدمة؟

لا ينبغي استخدام هذه الخدمة للحصول على معلومات حساسة للغاية لجميع الأسباب الموضحة في هذه الأسئلة الشائعة. فيما يلي بعض الأمثلة لما لا يجب فعله:

لماذا لا تستخدم فقط PGP / Signal / OMEMO / Matrix / إلخ؟

إذا كنت تعرف الشخص الذي تريد إرسال رسائل مؤقتة آمنة ، وإرسالها كثيرًا ، وتوقع واجهة تشبه الدردشة ، و / أو تتوقع أن يكون لدى المستلم البرنامج المطلوب ويعرف كيفية استخدامه ، فمن المحتمل ألا يكون موقع الويب هذا هو أفضل حل. هناك خيارات رائعة مفتوحة المصدر ، تدعم E2EE ، وليست قائمة على الويب ، وحتى بعضها مثل Signal الذي يدعم أيضًا الرسائل المؤقتة. أنا شخصياً أستخدم خادم XMMP خاص و OMEMO للدردشة مع الأصدقاء المقربين والعائلة. قد يكون استخدام هذا الموقع هو الأمثل فقط إذا كنت لا تعرف البرنامج الذي يقوم المستلم بتشغيله ، أو لا تعرف رقم هاتفه / جهة الاتصال الخاصة به ، أو لا تعرف كفاءته الفنية (ولكن افترض أنه يمكنه النقر فوق ارتباط) ، أو تفضل فقط الاحتفاظ بالرسالة التي ترسلها خارج نقل الاتصال الأساسي.

ما هي المتطلبات الموجودة؟

مطلوب مستعرض ويب حديث وحديث ينفذ المعايير بشكل صحيح بما في ذلك Web Crypto API. تتضمن الأمثلة: Chrome و Firefox و Edge و Safari (حوالي 2020 أو بعد ذلك).

هل يمكن للمتلقي عمل نسخة من الرسالة؟

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

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

هل تم جمع أي معلومات شخصية؟

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

ما هي المعلومات التي يتم تسجيلها؟

يحتفظ خادم الويب الخاص بنا بما يصل إلى 24 ساعة من تنسيق السجل المشترك في جميع أنشطة الويب. يتضمن ذلك تسجيل عنوان IP الكامل لعملاء HTTP. بعد 24 ساعة ، يتم حذف هذه المعلومات المسجلة تلقائيًا. يتم نشر جميع الطلبات المرسلة إلى / api مما يعني أنه لا يتم تسجيل أي معلومات محددة للرسالة من قبل خادم الويب. بالإضافة إلى ذلك ، يتم تسجيل أي معلومات محفوظة في قاعدة البيانات بشكل فعال. جميع الإدخالات في قاعدة البيانات ، بما في ذلك عناوين IP مجهولة المصدر والمجزأة ، لها وقت انتهاء الصلاحية (TTL) وبعد ذلك يتم حذفها تلقائيًا. تختلف أوقات انتهاء صلاحية TTL بين دقيقة واحدة وأسبوعين.

ماذا تفعل لتأمين الخوادم؟

أمن الخادم هو مصدر قلق واضح. هناك مجالان رئيسيان نركز عليهما للحفاظ على أمانه:

ما هي مخاطر الأمان الموجودة عند استخدام هذا الموقع؟

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

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

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

ماذا تفعل حيال هجمات man-in-the-middle (MITM)؟

من المحتمل أن يكون جميع مستخدمي مواقع الويب ضحية لهجوم MITM - لا يختلف هذا الموقع عن الآخرين على الويب في هذا الصدد. هجوم MITM هو عندما يكون المهاجم قادرًا على اعتراض وتعديل الاتصالات بين متصفح المستخدم وخادم الويب الخاص بالموقع. يسمح هذا للمهاجم بتعديل أي كود / محتوى للموقع مع استمرار الظهور للمستخدم النهائي على أنه الموقع الذي اعتادوا عليه. نتخذ بعض الإجراءات لجعل هجوم MITM أكثر صعوبة:

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

ما هي المزايا التي تقدمها امتدادات المتصفح؟

نحن نقدم ملحقات المتصفح كوسيلة لتوفير راحة إضافية وأمان إضافي. ببساطة ... تجعل الإضافات إرسال الرسائل المؤقتة أسرع وأسهل. يتم أيضًا اكتساب بعض الأمان لأن جميع التعليمات البرمجية المستخدمة لتشفير وتحضير رسالة مخزنة محليًا داخل الامتداد. نظرًا لأنه يتم تخزين الرمز محليًا ، فإن هذا يوفر للمرسل بعض الحماية ضد هجمات MITM . ومع ذلك ، تجدر الإشارة إلى أنه في حين أن الامتدادات توفر مزيدًا من الحماية ضد هجوم MITM الذي يضر بمحتويات الرسالة ، إلا أن هجوم MITM يمكن أن يظل فعالاً (أي لتحديد عنوان IP الخاص بالمرسل في حالة عدم استخدام TOR / VPN / إلخ.).

كيف يمكنني التأكد من أن أي شيء يتم إرساله مشفر من طرف إلى طرف؟

على عكس العديد من عملاء الدردشة المشفرين من طرف إلى طرف (E2EE) المشهورين ، من السهل جدًا رؤية ما يتم إرساله إلينا بالضبط عند إرسال رسالة. يوضح الفيديو التعليمي أدناه كيفية التأكد من عدم وجود طريقة لفك تشفير الرسائل المرسلة إلى الخادم.

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

كيف يعمل التشفير من طرف إلى طرف على هذا الموقع؟

في الوقت الحالي ، نستخدم التشفير المتماثل (AES-GCM 256bit) مع المفاتيح المشتقة من كلمات المرور (بحد أدنى 150000 تكرار من PBKDF2 / SHA-256). لا يتم استخدام التشفير غير المتماثل نظرًا لوجود متطلبات لـ 1) بدء المرسل الاتصال 2) عدم اتصال المرسل والمتلقي بالإنترنت في نفس الوقت و 3) عدم وجود معلومات عن المستلم و 4) نحاول الحفاظ على الأشياء بسيطة جدًا وإدارة المفاتيح هي معقد. يتم استخدام واجهة برمجة تطبيقات تشفير الويب القياسية لجميع وظائف التشفير بما في ذلك RNG. في الأساس ، هذا ما يحدث:

  1. يختار المستخدم كلمة مرور أو يتم إنشاء واحدة تلقائيًا
  2. يتم إجراء استدعاء API للحصول على عدد التكرارات المطلوبة PBKDF2 / SHA-256 ( هذه الخطوة مطلوبة للتحكم في البريد العشوائي )
  3. يتم إنشاء ملح 32 بايت
  4. مفتاح مشتق من الملح وكلمة المرور
  5. يتم إنشاء متجه تهيئة 12 بايت (IV)
  6. يتم تشفير الرسالة باستخدام المفتاح + IV
  7. يتم إرسال عدد التكرار والملح والرابع والنص المشفر إلى الخادم (مع بعض المعلومات الأخرى مثل TTL و RTL وما إلى ذلك)
  8. يقوم الخادم بإرجاع معرف عشوائي يشير إلى الرسالة
  9. ثم يقدم المتصفح للمستخدم النهائي رابطًا يحتوي على المعرف وكلمة المرور اللذين تم إرجاعهما أو رابطًا بدون كلمة المرور (في هذه الحالة ، يجب على المستلم معرفة كلمة المرور وإدخالها)
  10. إذا كانت كلمة المرور جزءًا من الارتباط ، فهي موجودة في تجزئة عنوان URL ، وبالتالي لا يتم إرسالها أبدًا إلى الخادم عندما يقوم المستلم بتقديم طلب GET
  11. يُطلب من المستلم ما إذا كان يرغب في فك تشفير الرسالة وعرضها
  12. يقدم المتصفح طلبًا يحدد معرف الرسالة
  13. إذا طلب المرسل إكمال اختبار CAPTCHA ، فسيتم توجيه المستلم إلى عنوان URL آخر لإثبات أنه بشر (بمجرد اجتيازه ، يتم توجيهه مرة أخرى)
  14. يرسل الخادم الرسالة المشفرة وسيقوم افتراضيًا بحذف الرسالة في هذه المرحلة إذا كانت القراءة للعيش (RTL) واحدة
  15. سيقوم المستلم بفك تشفير الرسالة بكلمة المرور (وسيُطلب منك إدخال كلمة المرور إذا لم تكن موجودة في عنوان URL)
هذا الإعداد بسيط للغاية ، ويوفر تشفير الرسائل من جهاز المرسل إلى جهاز المستلم ، لكنه بالطبع يفتقر إلى الضمان الذي يمكن أن يقدمه التشفير غير المتماثل من حيث معرفة أن شخصًا ما يمتلك المفتاح الخاص للمستلم فقط يمكنه فك تشفير الرسالة. يمكن لأي شخص لديه الرابط فتح الرسالة في السيناريو الافتراضي حيث تكون كلمة المرور جزءًا من عنوان URL - وهذا يؤكد أهمية استخدام وسيلة نقل مناسبة للرابط (مثل البريد الإلكتروني / الدردشة / النص / إلخ.) - قرار متروك لـ مرسل. يجوز لنا أيضًا ، إذا كان هناك اهتمام ، تقديم دعم لمخطط أساسي غير متماثل للغاية حيث يبدأ المستلم طلبًا لرسالة ويرسل رابط الطلب هذا إلى مرسل الرسالة. سيؤدي هذا الإعداد إلى التخلص من الحاجة إلى وجود كلمة المرور في عنوان URL ، ولكنه يلغي أيضًا قدرة المرسل على البدء.

يمكن أن تكون كلمة مرور فك التشفير في URL؟

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

لكن كلمة مرور فك التشفير لا يجب أن تكون في URL؟

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

  1. قم بتشفير كلمة المرور في رسالة بالإعدادات الافتراضية وإرسال هذا الارتباط إلى المستلم.
  2. عندما ينقر المستلم على الرابط ويفك تشفير الرسالة ، فإنهم يعلمون أنه لم يحصل أي شخص آخر على كلمة المرور من قبلهم لأن الرسالة التي تحتوي على كلمة المرور يتم حذفها عند الاسترداد. ومع ذلك ، إذا كان هناك هجوم MITM نشط أو إذا تم اختراق جهازك أو جهاز المستلم ، فلا يزال من الممكن لطرف آخر الحصول على كلمة المرور.
  3. تأكد مع المستلم من حصوله على كلمة المرور بنجاح. على سبيل المثال ، إذا أبلغك المستلم أنه عندما ذهب لاسترداد كلمة المرور ، تم حذف الرسالة بالفعل ، فأنت تعلم أن شخصًا آخر قد حصل على كلمة المرور قبل المستلم وبالتالي تم اختراق كلمة المرور ويجب عدم استخدامها.
  4. باستخدام كلمة المرور التي أكد المستلم أنها تمتلكها ، يمكنك الآن إرسال رسالة باستخدام نفس كلمة المرور للتشفير - ما عليك سوى مشاركة إصدار الرابط الذي لا يحتوي على كلمة المرور.

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

كيف يمكنني حماية خصوصيتي قدر الإمكان أثناء استخدام هذه الخدمة؟

كما تمت مناقشته في مكان آخر في هذه الأسئلة الشائعة ، على الرغم من أننا فعلنا الكثير بالفعل لحماية خصوصيتك وعلى الرغم من أننا لا نجمع أي معلومات شخصية ، يتم إرسال بعض المعلومات المتعلقة بالسجل وجمعها من قبلنا والآخرين بحكم استخدامك لمتصفح الويب. ومع ذلك ، هناك طرق متعددة لحماية خصوصيتك بشكل أكبر. إحدى الطرق المجانية للاستخدام ، استنادًا إلى البرامج مفتوحة المصدر ، والتي تعمل بشكل جيد هي استخدام متصفح Tor . تم تصميم هذا المتصفح لحماية خصوصيتك على مستويات متعددة - بما في ذلك استخدام شبكة Tor . يمكن الوصول إلى موقعنا بالفعل عبر شبكة Tor onion مما يعني أن الوصول إلى موقعنا عبر Tor لا يتطلب استخدام عقدة خروج ، مما ينفي التنصت على حركة مرور عقدة الخروج . ومع ذلك ، ضع في اعتبارك أنه حتى في هذا السيناريو ، يمكن لمزود خدمة الإنترنت الخاص بك أن يرى أنك تستخدم Tor - ولكن ليس الغرض منه. يمكنك حتى الاتصال بشبكة VPN ثم تشغيل متصفح Tor لطبقتين من إخفاء الهوية ؛ ومع ذلك ، ضع في اعتبارك أن مزود خدمة الإنترنت الخاص بك لا يزال بإمكانه رؤية أنك تستخدم VPN في هذا السيناريو - ولكن ليس الغرض منه. إذا كنت لا تريد أن يعرف مزود خدمة الإنترنت الخاص بك البروتوكولات التي تستخدمها ، فيمكنك الاتصال بشبكة WiFi عامة كبيرة مثل مكتبة ، ومدرسة ، وما إلى ذلك ، ثم استخدام متصفح Tor.

ماذا لو كنت لا أثق في الولايات المتحدة؟

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

ماذا تفعل لمنع البريد العشوائي؟

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

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

لماذا يوجد خيار لمطالبة المستلم بإكمال اختبار CAPTCHA؟

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

من يقوم بتشغيل هذه الخدمة ولماذا هي مجانية؟

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

كيف يمكنني الوثوق في إجابات الأسئلة أعلاه؟

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