Soalan Lazim

Mengapa laman web ini tidak diterjemahkan dengan baik? ⎃

Maaf, tetapi pengarang semasa hanya berbahasa Inggeris. Kami memerlukan bantuan untuk menerjemahkan projek ini ke dalam bahasa lain. Sebagai kaedah yang mudah dan murah untuk menyediakan perkhidmatan ini kepada orang-orang yang tidak berbahasa Inggeris, kami menggunakan terjemahan mesin. Hasilnya biasanya dapat diterima, tetapi boleh menghasilkan kata-kata pelik atau bahkan maklumat yang tidak tepat. Anda boleh membantu kami meningkatkan pengalaman untuk semua orang - sila hantar terjemahan yang betul .

Sejauh manakah perkhidmatan ini selamat?

Kami telah mengambil banyak langkah untuk menjadikan perkhidmatan ini selamat untuk penggunaannya . Sebelum kita melalui langkah-langkah tersebut, penting untuk memahami perkara berikut:

Tujuan kami adalah untuk menawarkan perkhidmatan ini dengan cara yang menawarkan pilihan untuk meningkatkan privasi dan keselamatan anda. Berikut adalah beberapa langkah yang telah kami ambil untuk melindungi maklumat anda dengan selamat:

Mengapa saya menerima pautan di sini dengan pilihan untuk menyahsulitkan mesej?

Kami meminta maaf sekiranya terdapat kesilapan dalam terjemahan ini . Perkhidmatan ini hanya menyampaikan mesej yang disulitkan dari satu titik ke titik yang lain dan anda adalah penerima. Mesej akan segera dipadamkan. Pengendali perkhidmatan ini tidak mempunyai cara untuk membaca kandungan mesej. Biasanya seseorang menggunakan perkhidmatan ini apabila mereka tidak mahu kandungan mesej berada di dalam pelbagai pangkalan data / peranti / perkhidmatan / fail / dll. seperti biasa semasa menghantar e-mel / pesanan segera / teks / dll. Sekiranya anda memutuskan untuk menyahsulitkan, ingatlah perkara berikut:

Anda memadam semua yang dihantar ke laman web ini?

Sesuai dengan logo tong sampah kami ... semuanya akan dihapus sejurus selepas menerimanya. Penghapusan semuanya automatik - ditulis ke pelayan. Fikirkan dengan cara ini - terdapat dua kelas maklumat yang dihantar:

Sekiranya terdapat mesej, anda dapat mengawal kapan kami menghapusnya dengan menentukan: Secara lalai, segala-galanya mengenai mesej akan dipadamkan setelah ia dihantar sekali atau berumur 1 minggu - mana yang berlaku terlebih dahulu Ketika hendak menghapus semua maklumat lain yang ada dalam mengirimkan apa-apa di web (iaitu alamat IP anda, dll.), Kami tidak memberi anda kawalan mengenai kapan atau bagaimana ia dihapus - kami hanya memadamkan semuanya setiap 24 jam .

Mengapa menggunakan perkhidmatan ini?

Perkhidmatan ini adalah alat untuk membantu menjadikan mesej yang anda hantar / terima kurang kekal. Sebahagian besar dari apa yang anda sampaikan di Internet (sembang, teks, e-mel, dll.) Disimpan dan jarang dihapuskan. Sering kali, apabila anda menghapus sesuatu, ia sebenarnya tidak dipadamkan tetapi ditandai sebagai dihapus dan tidak lagi dipaparkan kepada anda. Komunikasi agregat anda terkumpul tahun demi tahun dalam pangkalan data dan pada peranti yang tidak anda kendalikan. Tidak dapat tidak, satu atau lebih organisasi / orang / peranti yang menyimpan komunikasi anda digodam dan maklumat anda dibocorkan. Masalah ini begitu meresap sehingga sekarang ada banyak laman web yang melacak organisasi yang telah dikompromikan dan membocorkan data pengguna. Mesej sementara yang disulitkan dari hujung ke hujung adalah penyelesaian mudah untuk membantu menjadikan beberapa komunikasi anda tidak kekal. Setiap mesej yang dihantar ke laman web ini mempunyai waktu untuk hidup antara 1 minit hingga 2 minggu - setelah masa itu berlalu, mesej akan dihapus. Tambahan pula, tetapan lalai adalah untuk menghapus sebarang mesej setelah penerima mengambilnya. Selain itu, semua mesej dienkripsi dari peranti anda hingga ke peranti penerima. Tujuan utama dalam menggunakan enkripsi end-to-end adalah untuk menghilangkan kemampuan kita untuk membaca sebarang mesej yang dihantar sehingga menghilangkan beberapa syarat kepercayaan. Hasil akhirnya ialah sekarang mudah untuk menghantar mesej yang dienkripsi melalui pautan sederhana. Mesej itu dipadamkan sama ada selepas menghantar atau setelah diambil. Anda tidak perlu memasang / mengkonfigurasi perisian khas. Anda tidak perlu membuat akaun atau memberikan maklumat peribadi. Penerima tidak semestinya ada di kenalan anda atau mengetahui tentang perkhidmatan ini - satu-satunya syarat bahawa mereka boleh mengklik pautan.

Adakah ini perkhidmatan pesanan?

Tidak. Perkhidmatan ini dirancang untuk melengkapkan perkhidmatan pesanan yang ada seperti pesanan segera / e-mel / teks / dll. dengan menambahkan keupayaan untuk mengelakkan mesej yang dihantar disimpan dalam jangka masa yang lama. Kami tidak memberikan pautan yang dihasilkan kepada penerima .

Apakah kes penggunaan yang dimaksudkan?

Jadi apa senario di mana sesuai untuk menggunakan perkhidmatan ini? Walaupun setiap orang mempunyai keperluan dan keperluan yang berbeza dalam hal privasi dan keselamatan mereka, saya secara peribadi telah menemukan senario berikut sebagai kes penggunaan yang sesuai:

Untuk apa perkhidmatan ini tidak boleh digunakan?

Perkhidmatan ini tidak boleh digunakan untuk maklumat yang sangat sensitif untuk semua alasan yang dijelaskan dalam Soalan Lazim ini. Berikut adalah beberapa contoh perkara yang tidak boleh dilakukan:

Mengapa tidak hanya menggunakan PGP / Signal / OMEMO / Matrix / etc?

Sekiranya anda mengenali orang yang anda ingin kirimkan pesanan sementara yang selamat, hantarkannya dengan kerap, mengharapkan antara muka seperti sembang, dan / atau boleh mengharapkan penerima mempunyai perisian yang diperlukan dan tahu menggunakannya, laman web ini mungkin bukan penyelesaian terbaik. Terdapat banyak pilihan di luar sana iaitu sumber terbuka, menyokong E2EE, bukan berasaskan web, dan bahkan beberapa seperti Isyarat yang juga menyokong mesej sementara. Saya secara peribadi menggunakan pelayan XMMP peribadi dan OMEMO untuk berbual dengan rakan dan keluarga terdekat. Menggunakan laman web ini mungkin hanya optimum jika anda tidak mengetahui perisian apa yang dijalankan oleh penerima, tidak mengetahui nombor telefon / pemegang kenalan mereka, tidak mengetahui kecekapan teknikal mereka (tetapi anggap mereka dapat mengklik pautan), atau anda lebih suka menyimpan mesej yang anda hantar di luar pengangkutan komunikasi yang mendasari.

Keperluan apa yang ada?

Diperlukan penyemak imbas web moden dan terkini yang melaksanakan standard termasuk API Crypto Web dengan betul. Contohnya termasuk: Chrome, Firefox, Edge, dan Safari (sekitar tahun 2020 atau sesudahnya).

Bolehkah penerima membuat salinan mesej?

Ya. Walaupun mesej itu dapat menghapuskan dirinya sendiri semasa pengambilan, penerima masih dapat melihat mesej tersebut. Bila-bila masa penerima dapat melihat sepenuhnya mesej, salinan dapat dibuat - ini berlaku untuk semua komunikasi. Terdapat pilihan untuk menyukarkan penerima membuat salinan. Dalam hal ini tiga halangan penyalinan dilaksanakan:

Walau bagaimanapun, perlindungan salinan ini lemah kerana dapat dilewati. Juga, penerima sentiasa boleh mengambil tangkapan skrin atau foto mesej.

Adakah maklumat peribadi dikumpulkan?

Kami tidak menyokong akaun pengguna (iaitu nama pengguna / kata laluan). Kami tidak mengumpulkan maklumat yang dapat mengenal pasti anda (iaitu nama / alamat / e-mel / telefon). Ada kemungkinan beberapa maklumat peribadi ada dalam mesej yang anda kirimkan, tetapi itu dienkripsi dan kami tidak dapat membacanya. Sila semak dasar privasi kami untuk maklumat lengkap.

Maklumat apa yang dicatat?

Pelayan web kami menyimpan sehingga 24 jam format log biasa pada semua aktiviti web. Ini termasuk mencatat alamat IP penuh klien HTTP. Selepas 24 jam, maklumat yang dicatat ini akan dihapuskan secara automatik. Semua permintaan yang dikirim ke / api POSTED bermaksud tidak ada maklumat khusus mesej yang pernah dicatat oleh pelayan web. Selain itu, setiap maklumat yang disimpan ke pangkalan data dicatat dengan berkesan. Semua entri dalam pangkalan data, termasuk alamat IP tanpa nama dan hash, mempunyai masa tamat (TTL) setelah itu secara automatik dihapus. Waktu tamat TTL berbeza antara 1 minit dan 2 minggu.

Apa yang anda lakukan untuk melindungi pelayan?

Keselamatan pelayan adalah kebimbangan yang jelas. Terdapat dua bidang utama yang kami fokuskan untuk memastikannya selamat:

Apa risiko keselamatan yang terdapat semasa menggunakan laman web ini?

Sebelum menangani secara khusus beberapa risiko ini, saya rasa analogi separa ringkas mungkin dapat membantu merangkum risiko dalam menggunakan komunikasi Internet. Bayangkan bahawa mana-mana sistem hanya sekuat pautan paling lemah dalam rantai. Sekarang bayangkan senario di mana terdapat dua orang di dalam bilik tertutup tanpa cara untuk melihat, mendengar, atau merakam apa sahaja yang mereka lakukan. Seseorang akan menyampaikan mesej kepada orang lain yang apabila membaca mesej itu akan membakarnya. Sekiranya seseorang di luar ruangan itu ingin mendapatkan mesej yang sudah disampaikan, itu akan menjadi sukar. Apakah pautan paling lemah untuk mendapatkan mesej? Tidak banyak pautan yang boleh dipilih - rangkaian yang cukup pendek. Sekarang bayangkan bahawa semasa anda menghantar mesej di Internet bahawa terdapat sekurang-kurangnya satu juta pautan dalam rantai - banyak dari mereka lemah - banyak dari mereka benar-benar di luar kawalan anda - dan itulah kenyataan.

Menggunakan enkripsi dapat membantu mengatasi masalah jutaan pautan di atas dan mudah terpikat dengan pemikiran bahawa sistem E2EE yang direka dengan baik menawarkan penyelesaian akhir. Namun, pemikiran itu dapat membuat anda dalam masalah, kerana penyerang biasanya hanya akan mengejar tautan yang lebih lemah dalam sistem. Sebagai contoh, mungkin lebih mudah untuk mengambil alih telefon atau komputer anda dan menyediakan logger input untuk membaca semua yang anda taip daripada memecahkan mesej yang disulitkan melalui wayar. Intinya ialah jika saya ditugaskan untuk menyampaikan rahsia yang sangat penting / penting, saya hanya akan menggunakan komunikasi elektronik sebagai kaedah terakhir.

Jadi ada risiko keselamatan menggunakan komunikasi apa pun, tetapi anda masih menggunakan penyemak imbas web untuk perbankan, membeli barang, e-mel, dll. Ini merupakan risiko yang diterima untuk kemudahan besar yang diperoleh. Benarkah persoalannya ... apakah risiko keselamatan separa spesifik untuk laman web ini? Beberapa yang terlintas di fikiran:

Apa yang anda lakukan mengenai serangan man-in-the-middle (MITM)?

Semua pengguna laman web berpotensi menjadi mangsa serangan MITM - laman web ini tidak berbeza dengan yang lain di web dalam hal ini. Serangan MITM adalah ketika penyerang dapat memintas dan mengubah komunikasi antara penyemak imbas pengguna dan pelayan web laman web tersebut. Ini memungkinkan penyerang untuk mengubah mana-mana kod / kandungan laman web sementara masih kelihatan kepada pengguna akhir sebagai laman web yang biasa mereka gunakan. Kami mengambil beberapa langkah untuk menjadikan serangan MITM lebih sukar:

Namun, serangan MITM masih selalu dapat dilakukan - terutama jika penyerang mengendalikan infrastruktur rangkaian / kunci awam seperti yang akan berlaku untuk organisasi atau pemerintah yang besar / berkuasa. Kami menawarkan pelanjutan penyemak imbas yang dapat membantu mengurangkan beberapa risiko MITM.

Apa kelebihan yang ditawarkan oleh pelanjutan penyemak imbas?

Kami menawarkan pelanjutan penyemak imbas sebagai kaedah untuk memberikan kemudahan tambahan dan keselamatan tambahan. Ringkasnya ... Sambungan menjadikan penghantaran mesej sementara lebih cepat dan mudah. Beberapa keselamatan juga diperoleh kerana semua kod yang digunakan untuk menyulitkan dan menyiapkan mesej disimpan secara tempatan dalam peluasan. Kerana kod tersebut disimpan di dalam negara, ini memberikan perlindungan kepada pengirim terhadap serangan MITM . Walau bagaimanapun, perlu diperhatikan bahawa sementara pelanjutan menawarkan lebih banyak perlindungan terhadap serangan MITM yang membahayakan kandungan mesej, serangan MITM masih tetap berkesan (iaitu untuk menentukan alamat IP pengirim jika tidak menggunakan TOR / VPN / dll.).

Bagaimana saya dapat mengetahui dengan pasti bahawa apa-apa yang dihantar disulitkan dari hujung ke hujung?

Tidak seperti banyak pelanggan sembang enkripsi end-to-end (E2EE) yang popular, cukup mudah untuk melihat dengan tepat apa yang dihantar kepada kami semasa anda menghantar mesej. Tutorial video di bawah menunjukkan cara mengesahkan bahawa kita tidak mempunyai cara untuk menyahsulitkan mesej yang dihantar ke pelayan.

Sekiranya anda memikirkannya, selagi kita bukan agensi rahsia yang berusaha mengumpulkan mesej sensitif, tidak ada faedahnya kita dapat menyahsulitkan mesej kerana kemampuan itu hanya menimbulkan masalah kepada kita. Kami bahkan tidak mahu menyimpan mesej - ini adalah kejahatan yang diperlukan untuk menyampaikannya.

Bagaimana enkripsi end-to-end berfungsi di laman web ini?

Pada masa ini, kami menggunakan enkripsi simetri (AES-GCM 256bit) dengan kunci yang berasal dari kata laluan (minimum 150,000 lelaran PBKDF2 / SHA-256). Penyulitan asimetri tidak digunakan kerana keperluan ada untuk 1) pengirim memulakan komunikasi 2) pengirim dan penerima tidak berada dalam talian pada masa yang sama dan 3) tidak ada maklumat mengenai penerima dan 4) kami berusaha untuk memastikan perkara itu tetap sederhana dan pengurusan utama adalah rumit. API Crypto Web standard digunakan untuk semua fungsi kriptografi termasuk RNG. Pada dasarnya, inilah yang berlaku:

  1. Pengguna akhir memilih kata laluan atau satu dihasilkan secara automatik
  2. Panggilan API dibuat untuk mendapatkan bilangan lelaran PBKDF2 / SHA-256 yang diperlukan (langkah ini diperlukan untuk kawalan spam )
  3. Garam 32 bait dihasilkan
  4. Kunci diambil dari garam dan kata laluan
  5. Vektor inisialisasi 12 bait (IV) dihasilkan
  6. Mesej disulitkan menggunakan kunci + IV
  7. Kiraan lelaran, garam, IV, dan ciphertext dihantar ke pelayan (bersama dengan beberapa maklumat lain seperti TTL, RTL, dll.)
  8. Pelayan mengembalikan ID rawak yang merujuk kepada mesej
  9. Penyemak imbas kemudian memberikan pautan kepada pengguna akhir yang mengandungi ID dan kata laluan yang dikembalikan atau pautan tanpa kata laluan (dalam hal ini penerima mesti mengetahui dan memasukkan kata laluan)
  10. Sekiranya kata laluan adalah sebahagian daripada pautan, kata kunci tersebut terdapat dalam hash URL , dan oleh itu tidak pernah dihantar ke pelayan semasa penerima membuat permintaan GET
  11. Penerima diminta jika mereka ingin menyahsulit dan melihat mesej tersebut
  12. Penyemak imbas membuat permintaan yang menentukan ID mesej
  13. Sekiranya pengirim memerlukan CAPTCHA dilengkapkan, penerima diarahkan ke URL lain untuk membuktikan bahawa mereka adalah manusia (setelah mereka dihantar, mereka diarahkan kembali)
  14. Pelayan menghantar mesej yang dienkripsi dan secara lalai akan menghapus mesej pada ketika ini jika read-to-live (RTL) adalah salah satu
  15. Penerima akan menyahsulitkan mesej dengan kata laluan (dan akan diminta kata laluan jika tidak ada di URL)
Penyediaan ini sangat mudah, dan menawarkan enkripsi mesej dari peranti pengirim ke peranti penerima, tetapi tentu saja tidak mempunyai jaminan yang dapat ditawarkan oleh enkripsi asimetri dengan mengetahui hanya seseorang yang memiliki kunci peribadi penerima yang dapat menyahsulitkan mesej tersebut. Sesiapa sahaja yang mempunyai pautan dapat membuka mesej dalam senario lalai di mana kata laluan adalah sebahagian daripada URL - ini menggarisbawahi pentingnya menggunakan pengangkutan yang sesuai untuk pautan (iaitu e-mel / sembang / teks / dll.) - keputusan yang diserahkan kepada penghantar. Kami mungkin, jika ada minat, juga memberikan dukungan untuk skema asimetri yang sangat asas di mana penerima memulakan permintaan untuk mesej dan mengirimkan pautan permintaan itu kepada pengirim mesej. Penyediaan ini akan menghilangkan keperluan untuk memiliki kata sandi dalam URL, tetapi juga menghilangkan kemampuan pengirim untuk memulai.

Kata laluan penyahsulitan boleh terdapat di URL?

Ya. Ini jelas memberi kesan kepada keselamatan kerana jika kaedah yang digunakan untuk menghantar pautan tidak selamat, mesejnya tidak selamat oleh pergaulan. Semua jalan keluar untuk menghilangkan masalah ini memperkenalkan langkah dan kerumitan tambahan yang mempengaruhi pengalaman pengguna (iaitu perkara harus disiapkan di kedua-dua hujung sebelum menghantar mesej). Skema asimetri di mana penerima memulakan permintaan untuk mesej dan menghantar pautan permintaan itu dapat berfungsi dengan syarat utama "semuanya tidak lama" - ini mungkin dilaksanakan. Pada akhirnya, jika dua pihak sering mengirim pesan kepada satu sama lain, ada jalan penyelesaian yang lebih baik dengan andaian kedua-dua pihak dapat menangani penggunaan penyelesaian tersebut.

Tetapi kata laluan penyahsulitan tidak perlu ada di URL?

Betul. Sekiranya kata laluan penyahsulitan tidak disertakan dalam pautan, maka penerima akan diminta memasukkan kata laluan. Sekiranya kata laluan disampaikan dengan selamat kepada penerima (atau mereka sudah mengetahuinya), ini memberikan perlindungan daripada memintas. Walau bagaimanapun, kelemahannya ialah penerima mesti mengetahui dan memasukkan kata laluan dengan betul. Berikut adalah salah satu cara untuk menghantar kata laluan kepada penerima yang menawarkan beberapa perlindungan daripada memintas:

  1. Enkripsi kata laluan dalam mesej dengan tetapan lalai dan hantarkan pautan ini kepada penerima.
  2. Apabila penerima mengklik pautan dan menyahsulitkan mesej, mereka tahu tidak ada orang lain yang memperoleh kata laluan sebelum mereka kerana mesej yang mengandungi kata laluan dihapuskan semasa pengambilan. Namun, jika terdapat serangan MITM yang aktif atau jika peranti anda atau peranti penerima telah disusupi, maka masih mungkin pihak lain dapat memperoleh kata laluan.
  3. Sahkan dengan penerima bahawa mereka berjaya memperoleh kata laluan. Sebagai contoh, jika penerima memberitahu anda bahawa ketika mereka pergi untuk mendapatkan kata laluan, bahawa mesej itu telah dihapus, maka anda tahu orang lain memperoleh kata laluan sebelum penerima dan oleh itu kata laluan tersebut telah dikompromikan dan tidak boleh digunakan.
  4. Dengan menggunakan kata laluan yang disahkan oleh penerima, anda kini boleh menghantar mesej menggunakan kata laluan yang sama untuk penyulitan - hanya kongsi versi pautan yang tidak mengandungi kata laluan.

Itu betul - kami menghasilkan pautan dan menyerahkannya kepada pengirim cara terbaik untuk menyampaikannya kepada penerima. Tujuan perkhidmatan ini adalah untuk memberikan pilihan yang menawarkan lebih sedikit kekekalan dalam pengangkutan mesej yang ada seperti e-mel / sembang / teks / dll. Oleh itu, jangkaan adalah bahawa pautan yang kita hasilkan yang menunjukkan mesej sementara dihantar melalui pengangkutan mesej yang ada. Ini mempunyai implikasi keselamatan yang harus difahami oleh pengguna. Mari kita ambil pesanan teks SMS sebagai contoh kerana ini adalah kaedah komunikasi yang tidak selamat. Apabila anda menggunakan perkhidmatan ini untuk mengirim pautan pesan sementara melalui pesanan teks, jika anda menggunakan mod lalai di mana kata laluan disertakan dalam pautan, siapa pun yang mempunyai pautan dapat membaca mesej dan tidak ada perlindungan terhadap pemintasan yang ditawarkan. Perkhidmatan ini masih memberikan komunikasi yang lebih sementara yang dapat meningkatkan privasi dan keselamatan. Selain itu, anda boleh memilih untuk menghantar pautan tanpa kata laluan dan ini akan memberikan perlindungan daripada memintas.

Bagaimana saya dapat melindungi privasi saya sebanyak mungkin semasa menggunakan perkhidmatan ini?

Seperti yang dibincangkan di tempat lain dalam Soalan Lazim ini, walaupun kami sudah melakukan banyak hal untuk melindungi privasi anda dan walaupun kami tidak mengumpulkan maklumat peribadi, beberapa maklumat berkaitan log diserahkan dan dikumpulkan oleh kami dan orang lain berdasarkan anda menggunakan penyemak imbas web. Walau bagaimanapun, terdapat lebih banyak cara untuk melindungi privasi anda. Salah satu cara yang bebas digunakan, berdasarkan perisian sumber terbuka, dan berfungsi dengan baik adalah dengan menggunakan Penyemak Imbas Tor . Penyemak imbas ini direka untuk melindungi privasi anda di pelbagai peringkat - termasuk menggunakan rangkaian Tor . Laman web kami sudah dapat diakses melalui rangkaian bawang Tor yang bermaksud mengakses laman web kami melalui Tor tidak memerlukan penggunaan simpul keluar, yang menafikan seseorang yang mengupas lalu lintas simpul keluar . Walau bagaimanapun, ingat bahawa walaupun dalam senario ini, ISP anda dapat melihat bahawa anda menggunakan Tor - walaupun bukan untuk apa. Anda bahkan boleh menyambung ke VPN dan kemudian melancarkan Tor Browser untuk dua lapisan tanpa nama; namun, perlu diingat bahawa ISP anda masih dapat melihat anda menggunakan VPN dalam senario ini - walaupun tidak untuk apa. Sekiranya anda tidak mahu ISP anda mengetahui protokol apa yang anda gunakan, anda boleh menyambung ke rangkaian WiFi awam yang besar seperti perpustakaan, sekolah, dll. Dan kemudian menggunakan penyemak imbas Tor.

Bagaimana jika saya tidak mempercayai Amerika Syarikat?

Pelayan kami terletak di Amerika Syarikat. Selain itu, penyedia CDN kami, Cloudflare, adalah syarikat yang berpusat di Amerika Syarikat. Kami telah berusaha untuk menghilangkan keperluan untuk mempercayai kami atau negara di mana pelayan kami berada hanya kerana kami tidak mengumpulkan maklumat peribadi, tidak dapat menyahsulitkan sebarang mesej, dan semuanya dihapus sejurus selepas diterima. Walau bagaimanapun, kami dapat memahami ketidakpercayaan kerana ia berasaskan web dan terutama jika anda tinggal di negara-negara tertentu. Kami mempunyai beberapa rancangan untuk menawarkan pilihan di Iceland dan Switzerland untuk orang yang sukar mempercayai AS. Beri tahu kami jika ini berlaku untuk anda, kerana kami tidak akan termotivasi untuk menawarkan alternatif kecuali ada permintaan yang nyata.

Apa yang anda lakukan untuk mengelakkan spam?

Bila-bila masa anda membenarkan seseorang menghantar mesej yang boleh disampaikan melalui pautan, anda menjemput spammer. Mengatasi masalah ini tidak boleh dilakukan secara langsung. Kami tidak mahu memuatkan CAPTCHA pihak ketiga sebagai sebahagian daripada proses penghantaran mesej kerana beberapa sebab:

Kita mungkin dapat mengatasi masalah API dengan menggunakan beberapa sistem kunci API, tetapi kemudian kita harus mengumpulkan maklumat pengguna yang tidak ingin kita lakukan. Juga, apa yang menghalang spammer daripada mendapatkan banyak kunci API? Kami tidak dapat memeriksa mesej untuk menyimpulkan kekaburannya (yang paling bermasalah) kerana, selain mengenkripsi mesej, kami memiliki kebijakan lepas tangan mengenai kandungan mesej. Memandangkan keperluan ini, kami menggunakan dua kaedah untuk mencegah spam: Sekiranya anda menyedari bahawa spammer menyalahgunakan perkhidmatan ini, sila buat laporan penyalahgunaan .

Mengapa ada pilihan untuk meminta penerima melengkapkan CAPTCHA?

Walaupun benar bahawa kita tidak menyukai CAPTCHA, kita menyedari bahawa mereka memenuhi tujuan dan mempunyai masa dan tempat (sekurang-kurangnya buat masa ini). Ini adalah cara mudah bagi pengirim untuk mendapatkan kepastian bahawa penerima adalah manusia dan proses automatik tidak mengakses mesej.

Siapa yang menjalankan perkhidmatan ini dan mengapa percuma?

Kami hanyalah beberapa lelaki yang kadang-kadang berhadapan dengan keadaan tidak mempunyai pilihan yang baik untuk melindungi privasi kami. Sering kali ini berlaku kerana berkomunikasi dengan rakan dan ahli keluarga yang tidak begitu berhati-hati dengan cara mereka mengendalikan peranti dan maklumat mereka. Waktu lain ini berlaku semasa menggunakan forum berasaskan web seperti Reddit atau menggunakan sistem sokongan berasaskan web. Kami menemui beberapa penyelesaian pesanan sementara berasaskan web, tetapi tidak ada yang menawarkan E2EE yang bermaksud kami tidak boleh mempercayainya. Oleh itu, kami hanya membuat penyelesaian sendiri dan memutuskan untuk memberikannya agar orang lain dapat memanfaatkannya.

Bagaimana saya boleh mempercayai jawapan untuk soalan di atas?

Sungguh anda tidak boleh mempercayai laman web apa pun hanya kerana mengatakan perkara tertentu - biasanya idea yang baik untuk mengesahkan sebarang tuntutan. Kami telah berusaha untuk menghilangkan syarat untuk mempercayai kami sebanyak mungkin dengan menggunakan enkripsi end-to-end. Sebagai contoh, sangat mudah untuk diaudit bahawa kita tidak dapat membaca sebarang mesej kerana ia disulitkan . Kami juga memastikan kod javascript menjalankan laman web ini dengan sangat mudah sehingga senang dibaca dan difahami. Membuat semua kod sebagai sumber terbuka membolehkan orang mengesahkan apa yang sedang berjalan; namun, ingat bahawa tidak ada cara untuk benar-benar mengesahkan apa yang dijalankan oleh pelayan. Walaupun benar bahawa sebahagian besar keperluan kepercayaan dihapuskan dengan enkripsi end-to-end, masih menjadi faktor yang ditimbang oleh pengguna kita ketika memutuskan untuk menggunakan perkhidmatan ini atau tidak.