سوالات متداول

چرا این سایت ضعیف ترجمه شده است؟ ⎃

با عرض پوزش ، اما نویسندگان فعلی فقط انگلیسی صحبت می کنند. ما برای ترجمه این پروژه به زبانهای دیگر به کمک نیاز داریم. به عنوان یک روش ساده و ارزان برای در دسترس قرار دادن این سرویس در اختیار افرادی که انگلیسی صحبت نمی کنند ، ما از ترجمه ماشینی استفاده می کنیم. نتایج معمولاً قابل قبول است ، اما می تواند منجر به عباراتی عجیب یا حتی کاملاً نادرست شود. شما می توانید به ما در بهبود تجربه برای همه کمک کنید - لطفا ترجمه صحیح را ارائه دهید .

امنیت این سرویس چقدر است؟

ما اقدامات بسیاری را برای ایمن سازی این سرویس برای استفاده مورد نظر انجام داده ایم . قبل از انجام این مراحل ، درک موارد زیر مهم است:

هدف ما ارائه این سرویس به روشی است که گزینه هایی برای افزایش حریم خصوصی و امنیت شما را ارائه دهد. در اینجا برخی از اقدامات ما برای حفاظت از اطلاعات شما انجام شده است:

چرا در اینجا پیوندی با گزینه رمزگشایی پیام دریافت کردم؟

در صورت وجود اشتباه در این ترجمه عذرخواهی می کنیم. این سرویس به سادگی یک پیام رمزگذاری شده را از یک نقطه به نقطه دیگر منتقل می کند و شما گیرنده آن هستید. پیام به زودی حذف خواهد شد اپراتورهای این سرویس راهی برای خواندن مطالب پیام ندارند. معمولاً کسی از این سرویس استفاده می کند که نمی خواهد محتوای پیام در پایگاه داده های مختلف / دستگاه ها / خدمات / پرونده ها و غیره باقی بماند. همانطور که هنگام ارسال ایمیل / پیام فوری / متن / و غیره معمول است. اگر تصمیم به رمزگشایی دارید ، لطفا موارد زیر را بخاطر بسپارید:

همه موارد ارسالی به این سایت را حذف می کنید؟

به لوگوی سطل زباله ما صادق است ... همه چیز اندکی پس از دریافت حذف می شود. حذف همه موارد به صورت خودکار است - در سرور نوشته شده است. به این روش فکر کنید - دو دسته اطلاعات ارسال شده است:

در مورد پیام ها ، می توانید با تعیین موارد زیر ، زمان حذف آنها را کنترل کنید. به طور پیش فرض ، همه چیز درباره یک پیام پس از یک بار بازیابی یا 1 هفته ای شدن ، حذف می شود - هر کدام که برای اولین بار اتفاق بیفتد. وقتی نوبت به حذف سایر اطلاعات ذاتی ارسال هر چیزی در وب (یعنی آدرس IP شما و غیره) می رسد ، ما به شما هیچ کنترلی درباره زمان یا نحوه حذف آن نمی دهیم - ما فقط همه آنها را هر 24 ساعت حذف می کنیم .

چرا از این سرویس استفاده می کنیم؟

این سرویس ابزاری است برای کمک به ماندگاری پیام های ارسالی / دریافتی شما. بیشتر آنچه در اینترنت برقرار می کنید (چت ، متن ، ایمیل و غیره) ذخیره می شود و بندرت حذف می شود. اغلب اوقات ، وقتی چیزی را حذف می کنید ، در حقیقت حذف نمی شود بلکه به عنوان حذف شده علامت گذاری می شود و دیگر برای شما نمایش داده نمی شود. کل ارتباطات شما سال به سال در پایگاه داده ها و دستگاه هایی جمع می شود که هیچ کنترلی بر آنها ندارید. به ناچار ، یک یا چند سازمان / افراد / دستگاههایی که ارتباطات شما را ذخیره می کنند هک شده و اطلاعات شما درز می کند. این مشکل به حدی فراگیر است که هم اکنون وب سایت های بسیاری وجود دارند که سازمان هایی را که در معرض خطر قرار گرفته اند و اطلاعات کاربر را فاش کرده اند ردیابی می کنند. پیام های موقت رمزگذاری شده از انتها به انتها یک راه حل ساده برای کمک به ماندگاری برخی از ارتباطات شما هستند. هر پیامی که به این سایت ارسال می شود ، زمان پخش آن از 1 دقیقه تا 2 هفته است - با گذشت زمان پیام ، پیام حذف می شود. بعلاوه ، تنظیمات پیش فرض حذف هر پیامی است که گیرنده پیام را بازیابی کرد. علاوه بر این ، تمام پیام ها از دستگاه شما رمزگذاری می شوند ، تا آنجا که به دستگاه گیرنده منتقل می شوند. هدف اصلی در استفاده از رمزگذاری end-to-end حذف توانایی ما برای خواندن پیام های ارسالی در نتیجه حذف برخی از نیازهای اعتماد است. نتیجه نهایی این است که ارسال پیام رمزگذاری شده از طریق یک لینک ساده اکنون آسان است. این پیام یا اندکی پس از ارسال یا پس از بازیابی حذف می شود. نیازی به نصب / پیکربندی نرم افزار خاص نیست. نیازی به ایجاد یک حساب کاربری یا ارائه اطلاعات شخصی نیست. گیرنده مجبور نیست در تماس شما باشد یا حتی از این سرویس اطلاع داشته باشد - تنها شرطی که وی می تواند روی پیوند کلیک کند.

آیا این سرویس پیام رسانی است؟

خیر. این سرویس برای تکمیل خدمات پیام رسانی موجود مانند پیام رسانی فوری / ایمیل / متن / و غیره طراحی شده است. با افزودن توانایی جلوگیری از ذخیره شدن پیامهای ارسالی به مدت طولانی. ما پیوند ایجاد شده را به گیرنده تحویل نمی دهیم .

موارد استفاده در نظر گرفته شده چیست؟

بنابراین چه سناریوهایی وجود دارد که استفاده از این سرویس مناسب باشد؟ در حالی که هر کس در مورد حریم خصوصی و امنیت خود نیازها و الزامات متفاوتی دارد ، من شخصاً سناریوهای زیر را به عنوان موارد استفاده مناسب پیدا کرده ام:

برای چه کارهایی نباید از این سرویس استفاده کرد؟

به دلایلی که در این س FAالات متداول توضیح داده شده است نباید از این سرویس برای اطلاعات بسیار حساس استفاده شود. در زیر چند نمونه از مواردی که نباید انجام شود وجود دارد:

چرا فقط از PGP / سیگنال / OMEMO / ماتریس / و غیره استفاده نمی کنید؟

اگر شخصی را که می خواهید پیام های موقت ایمن برای شما ارسال شود ، می شناسید ، مرتباً برای آنها ارسال کنید ، انتظار یک رابط گپ مانند را دارید و یا می توانید از گیرنده نرم افزار مورد نیاز را داشته باشید و نحوه استفاده از آن را بدانید ، این وب سایت احتمالاً بهترین راه حل. گزینه های بسیار خوبی وجود دارد که متن باز هستند ، از E2EE پشتیبانی می کنند ، تحت وب نیستند و حتی برخی مانند Signal نیز از پیام های موقتی پشتیبانی می کنند. من شخصاً از یک سرور خصوصی XMMP و OMEMO برای گپ زدن با دوستان و خانواده نزدیک استفاده می کنم. استفاده از این سایت فقط در صورت مطلوب است اگر شما نمی دانید که گیرنده چه نرم افزاری را اجرا می کند ، شماره تلفن / تماس با وی را نمی دانید ، مهارت فنی وی را نمی دانید (اما فرض کنید آنها می توانند روی پیوند کلیک کنند) ، یا فقط ترجیح می دهید پیامی را که می فرستید خارج از حمل و نقل اصلی ارتباط داشته باشید.

چه الزاماتی وجود دارد؟

یک مرورگر وب مدرن و به روز که استانداردهایی از جمله Web Crypto API را به درستی پیاده سازی می کند ، مورد نیاز است. به عنوان مثال می توان به موارد زیر اشاره کرد: Chrome ، Firefox ، Edge و Safari (حدود سال 2020 یا بعد از آن).

آیا گیرنده می تواند کپی از پیام را تهیه کند؟

آره. حتی اگر پیام هنگام بازیابی ممکن است خودش را پاک کند ، گیرنده همچنان می تواند پیام را مشاهده کند. هر زمان گیرنده می تواند پیام را کاملاً مشاهده کند ، می توان کپی کرد - این مربوط به همه ارتباطات است. گزینه ای وجود دارد که تهیه نسخه را برای گیرنده دشوارتر کند. در این حالت سه مانع برای کپی برداری اعمال می شود:

با این حال ، این محافظت از کپی ضعیف است زیرا می توان از آن عبور کرد. همچنین ، گیرنده می تواند همیشه فقط از صفحه عکس یا عکس بگیرد.

آیا اطلاعات شخصی جمع آوری شده است؟

ما از حساب های کاربری (یعنی نام کاربری / گذرواژه) پشتیبانی نمی کنیم. ما هیچ اطلاعاتی را که بتواند شما را شناسایی کند جمع نمی کنیم (یعنی نام / آدرس / ایمیل / تلفن). ممکن است برخی از اطلاعات شخصی در پیامی که ارسال می کنید وجود داشته باشد ، اما این رمزگذاری شده است و ما راهی برای خواندن آن نداریم. لطفاً برای جزئیات کامل سیاست حفظ حریم خصوصی ما را مرور کنید.

چه اطلاعاتی ثبت می شود؟

وب سرور ما حداکثر تا 24 ساعت قالب مشترک گزارش را روی کلیه فعالیتهای وب نگه می دارد. این شامل ورود به سیستم آدرس IP کامل سرویس گیرندگان HTTP است. پس از 24 ساعت ، این اطلاعات ثبت شده به طور خودکار حذف می شود. تمام درخواست های ارسال شده به / api ارسال شده به این معنی است که هیچ اطلاعات خاصی از پیام توسط سرور وب ثبت نمی شود. علاوه بر این ، هر اطلاعاتی که در پایگاه داده ذخیره می شود به طور موثر ثبت می شود. تمام ورودی های پایگاه داده ، از جمله آدرس های IP ناشناس و هش دار ، دارای مدت انقضا (TTL) هستند و پس از آن به طور خودکار حذف می شوند. زمان انقضا T TTL بین 1 دقیقه تا 2 هفته متفاوت است.

برای امنیت سرورها چه کاری انجام می دهید؟

امنیت سرور یک نگرانی آشکار است. برای ایمن نگه داشتن آن دو زمینه اصلی وجود دارد:

هنگام استفاده از این سایت چه خطرات امنیتی وجود دارد؟

قبل از پرداختن به طور خاص به برخی از این خطرات ، من فکر می کنم یک تشبیه نیمه کوتاه ممکن است به جمع بندی خطرات استفاده از هرگونه ارتباطات اینترنتی کمک کند. تجسم کنید که هر سیستم فقط به اندازه ضعیف ترین حلقه زنجیره ای ایمن است. حال سناریویی را تصور کنید که دو نفر در یک اتاق مهر و موم شده باشند و هیچ وسیله ای برای دیدن ، شنیدن یا ضبط هر کاری که انجام می دهند وجود ندارد. یکی پیام را به دیگری منتقل می کند که با خواندن پیام آن را می سوزاند. اگر کسی در خارج از آن اتاق بخواهد پیامی را که قبلاً منتقل شده دریافت کند ، سخت خواهد بود. ضعیف ترین پیوند برای به دست آوردن پیام چیست؟ تعداد زیادی پیوند برای انتخاب وجود ندارد - این یک زنجیره بسیار کوتاه است. حال تصور کنید وقتی در اینترنت پیام می دهید حداقل یک میلیون لینک در این زنجیره وجود دارد - بسیاری از آنها ضعیف هستند - بسیاری از آنها کاملا خارج از کنترل شما هستند - و این واقعیت است.

استفاده از رمزنگاری می تواند تا حد زیادی به مشکل لینک فوق کمک کند و راحت می توان فکر کرد که سیستم های E2EE با طراحی خوب ، راه حل نهایی را ارائه می دهند. با این حال ، این تفکر می تواند شما را به دردسر بیندازد ، زیرا یک مهاجم معمولاً به دنبال پیوندهای ضعیف سیستم می رود. به عنوان مثال ، تصرف تلفن یا رایانه و راه اندازی یک logger ورودی برای خواندن هر آنچه را تایپ می کنید ، بسیار ساده تر از شکستن پیام های رمزگذاری شده از طریق سیم است. نتیجه نهایی این است که اگر وظیفه من بود که رازی از اهمیت حیاتی / حیاتی را اعلام کنم ، فقط از ارتباطات الکترونیکی به عنوان آخرین راه حل استفاده می کردم.

بنابراین استفاده از هرگونه ارتباطات خطرات امنیتی وجود دارد ، اما شما هنوز هم از یک مرورگر وب برای خدمات بانکی ، خرید موارد ، ایمیل و غیره استفاده می کنید. این یک خطر پذیرفته شده برای راحتی زیاد به دست آمده است. واقعاً س isال اینجاست ... چه خطرات امنیتی نیمه اختصاصی برای این سایت است؟ چند نفر به ذهن می آیند:

در مورد حملات مرد در میانه (MITM) چه می کنید؟

همه کاربران وب سایت ها به طور بالقوه می توانند قربانی حمله MITM شوند - این سایت از این نظر با سایر وب سایت ها تفاوتی ندارد. حمله MITM زمانی است که مهاجم قادر به رهگیری و اصلاح ارتباطات بین مرورگر کاربر و وب سرور سایت باشد. این به مهاجم این امکان را می دهد تا در حالی که هنوز برای کاربر نهایی به نظر می رسد سایتی باشد که به آن عادت کرده است ، کد / محتوای سایت را اصلاح کند. ما برای دشوارتر کردن حمله MITM اقداماتی انجام می دهیم:

با این حال ، حمله MITM هنوز همیشه ممکن است - به خصوص اگر مهاجم شبکه / زیرساخت کلید عمومی را کنترل کند ، همانطور که برای سازمان های بزرگ / قدرتمند یا دولت ها وجود دارد. ما برنامه های افزودنی مرورگر را ارائه می دهیم که می تواند به کاهش برخی از خطرات MITM کمک کند.

افزونه های مرورگر چه مزایایی را ارائه می دهند؟

ما برنامه های افزودنی مرورگر را به عنوان وسیله ای برای ایجاد راحتی بیشتر و امنیت بیشتر ارائه می دهیم. به زبان ساده ... برنامه های افزودنی ارسال پیام های موقتی را سریعتر و آسان تر می کنند. برخی از امنیت ها نیز بدست می آیند زیرا تمام کدی که برای رمزگذاری و آماده سازی پیام استفاده می شود به صورت محلی در پسوند ذخیره می شود. از آنجا که کد به صورت محلی ذخیره می شود ، این امر محافظی را در برابر حملات MITM به فرستنده ارائه می دهد. با این حال ، لازم به ذکر است که اگرچه پسوندها از حمله MITM که محتوای پیام را به خطر می اندازد ، محافظت بیشتری می کنند ، حمله MITM همچنان می تواند م beثر باشد (یعنی تعیین آدرس IP فرستنده در صورت عدم استفاده از TOR / VPN / و غیره).

چگونه می توانم به طور قطع بفهمم که هر چیزی که ارسال شده از آخر به آخر رمزگذاری شده است؟

برخلاف بسیاری دیگر از سرویس های گفتگوی محبوب رمزگذاری شده انتها به انتهای (E2EE) ، مشاهده دقیق آنچه که هنگام ارسال پیام برای ما ارسال می شود کاملاً ساده است. آموزش تصویری زیر نشان می دهد که چگونه تأیید کنیم که راهی برای رمزگشایی پیام های ارسالی به سرور نداریم.

همچنین ، اگر به آن فکر کنید ، تا زمانی که ما یک سازمان مخفی نیستیم که سعی در جمع آوری پیام های حساس نداریم ، هیچ فایده ای برای ما ندارد که بتوانیم پیام ها را رمزگشایی کنیم ، زیرا داشتن این توانایی فقط مشکلاتی برای ما ایجاد می کند. ما حتی نمی خواهیم پیام ها را ذخیره کنیم - اما ضروری است که آنها را ارائه دهیم.

رمزگذاری end-to-end در این سایت چگونه کار می کند؟

در این زمان ، ما از رمزگذاری متقارن (AES-GCM 256bit) با کلیدهای حاصل از گذرواژه (حداقل 150،000 تکرار PBKDF2 / SHA-256) استفاده می کنیم. رمزگذاری نامتقارن استفاده نمی شود زیرا الزامات لازم برای 1) فرستنده آغاز کننده ارتباطات 2) فرستنده و گیرنده در یک زمان آنلاین نیستند و 3) هیچ اطلاعاتی در مورد گیرنده و 4) ما در تلاش هستیم که همه چیز را ساده نگه داریم و مدیریت کلید بغرنج. API استاندارد Crypto Web برای همه قابلیت های رمزنگاری از جمله RNG استفاده می شود. در واقع ، آنچه اتفاق می افتد در اینجا است:

  1. کاربر نهایی رمز عبور را انتخاب می کند یا رمز ورود خودکار ایجاد می شود
  2. برای بدست آوردن تعداد تکرارهای مورد نیاز PBKDF2 / SHA-256 تماس API برقرار می شود ( این مرحله برای کنترل هرزنامه لازم است )
  3. نمک 32 بایت تولید می شود
  4. یک کلید از نمک و رمز عبور مشتق شده است
  5. بردار مقداردهی اولیه 12 بایت (IV) ایجاد می شود
  6. پیام با استفاده از کلید + IV رمزگذاری می شود
  7. تعداد تکرار ، نمک ، IV و متن رمز شده به سرور ارسال می شود (همراه با برخی اطلاعات دیگر مانند TTL ، RTL و غیره)
  8. سرور یک شناسه تصادفی را با اشاره به پیام برمی گرداند
  9. سپس مرورگر پیوندی را به کاربر نهایی ارائه می دهد كه شامل شناسه و رمز عبور برگشتی یا پیوندی بدون رمز عبور است (در این صورت گیرنده باید رمز عبور را بداند و وارد كند)
  10. اگر گذرواژه بخشی از پیوند باشد ، در URL hash است و بنابراین وقتی گیرنده درخواست GET را ارائه می دهد ، هرگز به سرور ارسال نمی شود
  11. در صورت تمایل به رمزگشایی و مشاهده پیام ، از گیرنده درخواست می شود
  12. مرورگر با تعیین شناسه پیام درخواست می کند
  13. اگر فرستنده نیاز به تکمیل CAPTCHA داشته باشد ، گیرنده به URL دیگری هدایت می شود تا اثبات کند که انسان است (پس از عبور مجدداً هدایت می شود)
  14. سرور پیام رمزگذاری شده را ارسال می کند و اگر خواندن به صورت زنده (RTL) یکی باشد به طور پیش فرض پیام را در این مرحله حذف می کند
  15. گیرنده پیام را با گذرواژه رمزگشایی خواهد کرد (و اگر در URL نباشد از او درخواست رمز عبور می شود)
این تنظیم بسیار ساده است و رمزگذاری پیام را از دستگاه فرستنده به دستگاه گیرنده ارائه می دهد ، اما البته این تضمین را ندارد که رمزگذاری نامتقارن از نظر دانستن تنها شخصی که دارای کلید خصوصی گیرنده است می تواند پیام را رمزگشایی کند. هر کسی که پیوند را دارد می تواند پیام را در سناریوی پیش فرض باز کند که به موجب آن رمز عبور بخشی از URL است - این اهمیت استفاده از یک حمل و نقل مناسب برای پیوند را تأکید می کند (به عنوان مثال ایمیل / چت / متن / و غیره) - تصمیمی که به فرستنده. در صورت تمایل ، ما می توانیم پشتیبانی از یک طرح نامتقارن بسیار اساسی را نیز ارائه دهیم که به موجب آن گیرنده درخواست پیامی را آغاز می کند و پیوند درخواست را به فرستنده پیام می فرستد. با این تنظیم نیاز به گذرواژه در URL از بین می رود ، اما همچنین توانایی ارسال برای ارسال کننده نیز از بین می رود.

رمز عبور رمزگشایی می تواند در URL باشد؟

آره. این امر به وضوح بر امنیت تأثیر می گذارد زیرا اگر روشی که برای ارسال پیوند استفاده می شود ناامن باشد ، از نظر ارتباط پیام ناامن است. تمام راه حل ها برای از بین بردن این مسئله ، مراحل و پیچیدگی های دیگری را ایجاد می کند که بر تجربه کاربر تأثیر می گذارد (یعنی قبل از ارسال پیام ، موارد باید در هر دو قسمت تنظیم شوند). یک طرح نامتقارن که به موجب آن گیرنده درخواست پیامی را آغاز می کند و پیوند درخواست را می فرستد می تواند با نیاز اصلی ما "همه چیز زودگذر است" کار کند - این ممکن است اجرا شود. در نهایت ، اگر قرار باشد دو طرف به طور مکرر برای یکدیگر پیام ارسال کنند ، با فرض اینکه هر دو طرف بتوانند از این راه حل ها استفاده کنند راه حل های بهتری وجود دارد.

اما لزوما رمز عبور رمزگذاری در URL نیست؟

درست. اگر رمز رمز در پیوند موجود نباشد ، از گیرنده رمز عبور خواسته می شود. اگر رمز عبور به طور ایمن به گیرنده ارسال شود (یا آنها قبلاً آن را می دانند) ، این امر در برابر رهگیری محافظت می کند. با این حال ، عیب این است که گیرنده باید رمز عبور را بداند و به درستی وارد کند. در اینجا یک راه برای ارسال رمز عبور به گیرنده وجود دارد که در برابر رهگیری محافظت می کند:

  1. رمز عبور را در یک پیام با تنظیمات پیش فرض رمزگذاری کرده و این پیوند را برای گیرنده ارسال کنید.
  2. هنگامی که گیرنده روی پیوند کلیک می کند و پیام را رمزگشایی می کند ، می داند که هیچ کس دیگری قبلاً رمز عبور را دریافت نکرده است زیرا پیام حاوی رمز عبور در هنگام بازیابی حذف می شود. با این حال ، اگر یک حمله MITM فعال وجود داشته باشد یا اگر دستگاه شما یا دستگاه گیرنده به خطر افتاده باشد ، ممکن است شخص دیگری بتواند رمز عبور را دریافت کند.
  3. با گیرنده تأیید کنید که رمز عبور را با موفقیت دریافت کرده است. به عنوان مثال ، اگر گیرنده به شما اطلاع دهد که هنگام بازیابی رمز عبور ، پیام قبلاً حذف شده است ، پس می دانید شخص دیگری قبل از گیرنده رمز عبور را دریافت کرده است و بنابراین رمز عبور به خطر می افتد و نباید استفاده شود.
  4. با استفاده از گذرواژه ای که گیرنده تأیید کرده است ، اکنون می توانید با استفاده از همان رمز عبور پیامی را برای رمزگذاری ارسال کنید - فقط نسخه پیوندی را که رمز عبور ندارد به اشتراک بگذارید.

این درست است - ما پیوند را ایجاد می کنیم و نحوه ارسال آن به گیرنده را به ارسال کننده می سپاریم. هدف این سرویس ارائه گزینه ای است که ماندگاری کمتری در انتقال پیام های موجود مانند ایمیل / چت / متن / و غیره داشته باشد. بنابراین ، انتظار این است که پیوندی که ایجاد می کنیم و به پیام موقت اشاره دارد ، از طریق یک پیام موجود ارسال شود. این پیامدهای امنیتی دارد که کاربران باید درک کنند. بیایید یک پیام کوتاه را به عنوان مثال در نظر بگیریم ، زیرا این یک روش ارتباطی بسیار ناامن است. هنگامی که از این سرویس برای ارسال پیوند پیام موقت از طریق پیام متنی استفاده می کنید ، اگر از حالت پیش فرض استفاده می کنید که رمز عبور در آن پیوند داده می شود ، هر کسی پیوند را داشته باشد می تواند پیام را بخواند و هیچ گونه محافظت در برابر رهگیری ارائه نمی شود. این سرویس هنوز ارتباط موقت تری را فراهم می کند که می تواند حریم خصوصی و امنیت را افزایش دهد. علاوه بر این ، شما می توانید پیوند را بدون رمز عبور ارسال کنید و این باعث محافظت در برابر رهگیری می شود.

چگونه می توانم در حین استفاده از این سرویس تا حد امکان از حریم خصوصی خود محافظت کنم؟

همانطور که در جای دیگری در این سQالات متداول بحث شده است ، حتی اگر ما کارهای زیادی برای محافظت از حریم خصوصی شما انجام داده ایم و حتی اگر اطلاعات شخصی را جمع آوری نکنیم ، برخی از اطلاعات مربوط به گزارش توسط ما و دیگران به موجب شما با استفاده از مرورگر وب ارسال و جمع آوری می شود. با این حال ، چندین روش برای محافظت بیشتر از حریم خصوصی شما وجود دارد. روشی که استفاده از آن بر اساس نرم افزار منبع باز رایگان است و کاملاً مناسب است ، استفاده از مرورگر Tor است . این مرورگر برای محافظت از حریم خصوصی شما در چندین سطح - از جمله استفاده از شبکه Tor - طراحی شده است . سایت ما از قبل از طریق شبکه پیاز Tor قابل دسترسی است ، این بدان معناست که دسترسی به سایت ما از طریق Tor نیازی به استفاده از گره خروجی ندارد ، که کسی استراق سمع ترافیک گره خروجی را رد می کند . با این حال ، به یاد داشته باشید که حتی در این سناریو ، ISP شما می تواند ببیند که شما از Tor استفاده می کنید - البته نه برای چه. حتی می توانید به VPN متصل شوید و سپس مرورگر Tor را برای دو لایه ناشناس راه اندازی کنید. با این حال ، به یاد داشته باشید که ISP شما همچنان می تواند در این سناریو از VPN استفاده کند - البته نه برای چه. اگر نمی خواهید ISP شما از پروتکل های شما استفاده کند ، می توانید به یک شبکه WiFi عمومی بزرگ مانند کتابخانه ، مدرسه و غیره متصل شوید و سپس از مرورگر Tor استفاده کنید.

اگر به ایالات متحده اعتماد نکنم چه می کنم؟

سرورهای ما در ایالات متحده واقع شده اند. علاوه بر این ، ارائه دهنده CDN ما ، Cloudflare ، یک شرکت مستقر در ایالات متحده است. ما سعی کرده ایم نیاز به اعتماد به ما یا کشوری که سرورهای ما در آن اقامت دارند را برطرف کنیم زیرا ما اطلاعات شخصی را جمع آوری نمی کنیم ، نمی توانیم هیچ پیامی را رمزگشایی کنیم و بلافاصله پس از دریافت همه موارد حذف می شود. با این حال ، ما می توانیم برخی از بی اعتمادی ها را درک کنیم زیرا این امر مبتنی بر وب است و به خصوص اگر در کشورهای خاصی زندگی می کنید. ما در حال برنامه ریزی برای ارائه گزینه هایی در ایسلند و سوئیس برای افرادی هستیم که اعتماد به نفس سختی در ایالات متحده دارند. اگر این مورد به شما مربوط می شود ، لطفاً به ما اطلاع دهید ، زیرا تا زمانی که تقاضای واقعی وجود نداشته باشد ، انگیزه ای برای ارائه گزینه های دیگر نخواهیم داشت.

برای جلوگیری از هرزنامه چه کاری انجام می دهید؟

هر زمان به شما اجازه می دهد کسی پیامی را ارسال کند که می تواند از طریق پیوند ارسال شود ، از اسپمرها دعوت می کنید. مهار این مشکل کاملاً ساده نیست. به چند دلیل نمی خواهیم CAPTCHA شخص ثالث را به عنوان بخشی از روند ارسال پیام بارگیری کنیم:

ما می توانیم با استفاده از برخی از سیستم های کلید API مشکل API را برطرف کنیم ، اما پس از آن باید اطلاعات کاربری را که نمی خواهیم انجام دهیم جمع آوری کنیم. همچنین ، جلوگیری از دریافت تعداد زیادی کلید API توسط اسپم ها چیست؟ ما نمی توانیم پیام ها را برای استنباط هرزنامه بودن آنها بررسی کنیم (که در بهترین حالت بسیار مشکل ساز است) زیرا ، به غیر از رمزگذاری پیام ها ، ما یک سیاست عملی در مورد محتوای پیام داریم. با توجه به این شرایط ، ما از دو روش برای جلوگیری از هرزنامه استفاده می کنیم: اگر می دانید که هرزنامه نویسان از این سرویس سو استفاده می کنند ، لطفاً گزارش سواستفاده کنید .

چرا گزینه ای برای نیاز به گیرنده برای تکمیل CAPTCHA وجود دارد؟

اگرچه درست است که ما از CAPTCHA متنفر نیستیم ، اما تشخیص می دهیم که آنها برای یک هدف کار می کنند و دارای زمان و مکان هستند (حداقل فعلاً) این یک روش ساده برای فرستنده است تا اطمینان حاصل کند که گیرنده انسان است و فرایندهای خودکار به پیام دسترسی ندارند.

چه کسی این سرویس را اجرا می کند و چرا رایگان است؟

ما فقط یک زن و شوهر هستیم که بعضی اوقات با این مشکل روبرو می شویم که گزینه های خوبی برای محافظت از حریم خصوصی خود نداریم. این اوقات اغلب ناشی از برقراری ارتباط با دوستان و اعضای خانواده بود که خیلی مراقب نحوه برخورد با دستگاه ها و اطلاعات خود نبودند. در سایر موارد ، این امر هنگام استفاده از انجمن های تحت وب مانند Reddit یا استفاده از سیستم های پشتیبانی مبتنی بر وب اتفاق می افتاد. ما چند راه حل پیام موقت مبتنی بر وب پیدا کردیم ، اما هیچ یک از آنها E2EE را ارائه ندادند و این بدان معنا بود که نمی توانیم به آنها اعتماد کنیم. بنابراین ما فقط راه حل خودمان را ساختیم و تصمیم گرفتیم آن را ارائه دهیم تا دیگران بتوانند از آن بهره مند شوند.

چگونه می توانم به پاسخ س questionsالات بالا اعتماد کنم؟

واقعاً شما نباید به هر وب سایتی اعتماد داشته باشید فقط به این دلیل که برخی موارد را بیان می کند - به طور معمول ایده خوبی برای تأیید هر گونه ادعا است. ما سعی کرده ایم با استفاده از رمزنگاری end-to-end ، الزاما به اعتماد هرچه بیشتر ما برطرف کنیم. به عنوان مثال ، بررسی آن بسیار آسان است که ما نمی توانیم هیچ پیامی را بخاطر رمزگذاری شده بخوانیم. ما همچنین کد javascript را که در حال اجرای این سایت است بسیار ساده نگه داشته ایم تا خواندن و فهم آن آسان باشد. ساختن همه کد منبع باز به مردم اجازه می دهد تا بررسی کنند که چه چیزی اجرا می شود. با این حال ، بخاطر داشته باشید هیچ راهی برای تأیید واقعی کارکرد سرور وجود ندارد. اگرچه درست است که بسیاری از موارد مورد نیاز اعتماد با رمزگذاری پایان به انتها برداشته می شود ، اما هنوز عاملی است که کاربران ما هنگام تصمیم گیری برای استفاده از این سرویس یا عدم استفاده از آن بسیار سنگین می شوند.