Pertanyaan yang Sering Diajukan

Mengapa situs ini diterjemahkan dengan buruk? ⎃

Maaf, tetapi penulis saat ini hanya berbicara bahasa Inggris. Kami membutuhkan bantuan untuk menerjemahkan proyek ini ke dalam bahasa lain. Sebagai cara sederhana dan murah untuk membuat layanan ini tersedia bagi orang yang tidak bisa berbahasa Inggris, kami menggunakan terjemahan mesin. Hasilnya biasanya dapat diterima, tetapi dapat menghasilkan kata-kata yang aneh atau bahkan informasi yang sama sekali tidak akurat. Anda dapat membantu kami meningkatkan pengalaman untuk semua orang - harap kirimkan terjemahan yang benar .

Seberapa amankah layanan ini?

Kami telah mengambil banyak langkah untuk membuat layanan ini aman untuk penggunaan yang dimaksudkan . Sebelum kita membahas langkah-langkah itu, penting untuk memahami hal-hal berikut:

Tujuan kami adalah menawarkan layanan ini dengan cara yang menawarkan opsi untuk meningkatkan privasi dan keamanan Anda. Berikut adalah beberapa langkah yang telah kami ambil untuk mengamankan informasi Anda:

Mengapa saya menerima tautan di sini dengan opsi untuk mendekripsi pesan?

Kami mohon maaf jika ada kesalahan dalam terjemahan ini . Layanan ini hanya meneruskan pesan terenkripsi dari satu titik ke titik lain dan Anda adalah penerimanya. Pesan akan segera dihapus. Operator layanan ini tidak memiliki cara untuk membaca isi pesan. Biasanya seseorang menggunakan layanan ini ketika mereka tidak ingin isi pesan tetap berada di dalam berbagai database/perangkat/layanan/file/dll. seperti biasanya saat mengirim email/pesan instan/teks/dll. Jika Anda memutuskan untuk mendekripsi, harap perhatikan hal berikut:

Anda menghapus semua yang dikirimkan ke situs ini?

Sesuai dengan logo tempat sampah kami... semuanya akan dihapus segera setelah menerimanya. Penghapusan semuanya otomatis - itu ditulis ke server. Pikirkan seperti ini - ada dua kelas informasi yang dikirimkan:

Dalam hal pesan, Anda dapat mengontrol kapan kami menghapusnya dengan menentukan: Secara default, segala sesuatu tentang pesan dihapus setelah diambil sekali atau berumur 1 minggu - mana yang lebih dulu. Ketika datang untuk menghapus semua informasi lain yang melekat dalam mengirimkan apa pun di web (yaitu alamat IP Anda, dll.), kami tidak memberi Anda kendali apa pun atas kapan atau bagaimana informasi itu dihapus - kami hanya menghapus semuanya setiap 24 jam .

Mengapa menggunakan layanan ini?

Layanan ini adalah alat untuk membantu membuat pesan yang Anda kirim/terima menjadi tidak permanen. Sebagian besar dari apa yang Anda komunikasikan di Internet (obrolan, teks, email, dll.) disimpan dan jarang dihapus. Seringkali, ketika Anda menghapus sesuatu, itu tidak benar-benar dihapus melainkan ditandai sebagai dihapus dan tidak lagi ditampilkan kepada Anda. Komunikasi agregat Anda terakumulasi dari tahun ke tahun di database dan di perangkat yang tidak dapat Anda kendalikan. Tak pelak lagi, satu atau lebih organisasi/orang/perangkat yang menyimpan komunikasi Anda diretas dan informasi Anda bocor. Masalah ini begitu meluas sehingga sekarang ada banyak situs web yang melacak organisasi yang telah disusupi dan membocorkan data pengguna. Pesan sementara terenkripsi ujung ke ujung adalah solusi sederhana untuk membantu membuat beberapa komunikasi Anda tidak terlalu permanen. Setiap pesan yang dikirimkan ke situs ini memiliki waktu tayang mulai dari 1 menit hingga 2 minggu - setelah waktu tersebut berlalu, pesan akan dihapus. Selanjutnya, pengaturan default adalah menghapus pesan apa pun setelah penerima mengambilnya. Selain itu, semua pesan dienkripsi dari perangkat Anda sampai ke perangkat penerima. Tujuan utama dalam memanfaatkan enkripsi ujung-ke-ujung adalah untuk menghilangkan kemampuan kami untuk membaca pesan yang dikirimkan sehingga menghilangkan beberapa persyaratan kepercayaan. Hasil akhirnya adalah sekarang mudah untuk mengirim pesan terenkripsi melalui tautan sederhana. Pesan itu dihapus baik segera setelah dikirim atau setelah diambil. Anda tidak perlu menginstal/mengonfigurasi perangkat lunak khusus. Anda tidak perlu membuat akun atau memberikan informasi pribadi apa pun. Penerima tidak harus ada di kontak Anda atau bahkan tahu tentang layanan ini - satu-satunya persyaratan bahwa mereka dapat mengklik tautan.

Apakah ini layanan pesan?

Tidak. Layanan ini dirancang untuk melengkapi layanan pesan yang sudah ada seperti pesan instan/email/teks/dll. dengan menambahkan kemampuan untuk mencegah pesan terkirim disimpan dalam waktu lama. Kami tidak mengirimkan tautan yang dihasilkan ke penerima .

Apa kasus penggunaan yang dimaksudkan?

Jadi apa saja skenario yang tepat untuk menggunakan layanan ini? Sementara setiap orang memiliki kebutuhan dan persyaratan yang berbeda dalam hal privasi dan keamanan mereka, saya pribadi telah menemukan skenario berikut sebagai kasus penggunaan yang sesuai:

Layanan ini tidak boleh digunakan untuk apa?

Layanan ini tidak boleh digunakan untuk informasi yang sangat sensitif karena semua alasan yang dijelaskan dalam FAQ ini. Di bawah ini adalah beberapa contoh yang tidak boleh dilakukan:

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

Jika Anda mengenal orang yang ingin Anda kirimi pesan sementara yang aman, sering mengirimnya, mengharapkan antarmuka seperti obrolan, dan/atau dapat mengharapkan penerima memiliki perangkat lunak yang diperlukan dan mengetahui cara menggunakannya, situs web ini mungkin bukan solusi terbaik. Ada pilihan bagus di luar sana yang open source, mendukung E2EE, bukan berbasis web, dan bahkan beberapa seperti Signal yang juga mendukung pesan sementara. Saya pribadi menggunakan server XMMP pribadi dan OMEMO untuk mengobrol dengan teman dekat dan keluarga. Menggunakan situs ini mungkin hanya optimal jika Anda tidak tahu perangkat lunak apa yang dijalankan penerima, tidak tahu nomor telepon/pegangan kontak mereka, tidak tahu kemampuan teknis mereka (tetapi anggap mereka bisa mengklik tautan), atau Anda lebih suka menyimpan pesan yang Anda kirim di luar transportasi komunikasi yang mendasarinya.

Persyaratan apa yang ada?

Diperlukan browser web modern dan terkini yang menerapkan standar dengan benar termasuk Web Crypto API. Contohnya meliputi: Chrome, Firefox, Edge, dan Safari (sekitar tahun 2020 atau setelahnya).

Dapatkah penerima membuat salinan pesan?

Iya. Meskipun pesan dapat dihapus dengan sendirinya setelah diambil, penerima masih dapat melihat pesan tersebut. Kapan pun penerima dapat melihat pesan sepenuhnya, salinan dapat dibuat - ini berlaku untuk semua komunikasi. Ada opsi untuk mempersulit penerima membuat salinan. Dalam hal ini, tiga hambatan penyalinan diterapkan:

Namun, perlindungan salinan ini lemah karena dapat dilewati. Selain itu, penerima selalu dapat mengambil tangkapan layar atau foto dari pesan tersebut.

Apakah ada informasi pribadi yang dikumpulkan?

Kami tidak mendukung akun pengguna (yaitu nama pengguna/kata sandi). Kami tidak mengumpulkan informasi apa pun yang dapat mengidentifikasi Anda (yaitu nama/alamat/email/telepon). Mungkin saja beberapa informasi pribadi ada dalam pesan yang Anda kirim, tetapi itu dienkripsi dan kami tidak dapat membacanya. Harap tinjau kebijakan privasi kami untuk detail lengkap.

Informasi apa yang dicatat?

Server web kami menyimpan hingga 24 jam format log umum pada semua aktivitas web. Ini termasuk mencatat alamat IP lengkap klien HTTP. Setelah 24 jam, informasi yang dicatat ini akan dihapus secara otomatis. Semua permintaan yang dikirim ke /api POSTed artinya tidak ada informasi spesifik pesan yang pernah dicatat oleh server web. Selain itu, informasi apa pun yang disimpan ke database dicatat secara efektif. Semua entri dalam database, termasuk alamat IP anonim dan hash, memiliki waktu kedaluwarsa (TTL) setelah itu akan dihapus secara otomatis. Waktu kedaluwarsa TTL bervariasi antara 1 menit dan 2 minggu.

Apa yang Anda lakukan untuk mengamankan server?

Keamanan server merupakan perhatian yang jelas. Ada dua area utama yang kami fokuskan untuk menjaganya tetap aman:

Risiko keamanan apa yang ada saat menggunakan situs ini?

Sebelum secara khusus membahas beberapa risiko ini, saya pikir analogi semi-singkat mungkin membantu untuk meringkas risiko dalam menggunakan komunikasi Internet apa pun. Visualisasikan bahwa sistem apa pun hanya seaman mata rantai terlemah dalam sebuah rantai. Sekarang bayangkan sebuah skenario di mana ada dua orang di ruangan tertutup tanpa sarana untuk melihat, mendengar, atau merekam apa pun yang mereka lakukan. Satu akan menyampaikan pesan kepada yang lain yang setelah membaca pesan akan membakarnya. Jika seseorang di luar ruangan itu ingin mendapatkan pesan yang sudah disampaikan, itu akan sulit. Apa tautan terlemah untuk mendapatkan pesan? Tidak banyak tautan untuk dipilih - ini adalah rantai yang cukup pendek. Sekarang bayangkan bahwa ketika Anda mengirim pesan di Internet bahwa setidaknya ada satu juta tautan dalam rantai - banyak di antaranya lemah - banyak di antaranya benar-benar di luar kendali Anda - dan itu adalah kenyataan.

Menggunakan enkripsi dapat sangat membantu dengan masalah jutaan tautan di atas dan mudah terpikat untuk berpikir bahwa sistem E2EE yang dirancang dengan baik menawarkan solusi akhir segalanya. Namun, pemikiran itu dapat membuat Anda dalam masalah, karena penyerang biasanya hanya akan mengejar tautan yang lebih lemah dalam sistem. Misalnya, mungkin jauh lebih mudah untuk mengambil alih ponsel atau komputer Anda dan mengatur pencatat input untuk hanya membaca semua yang Anda ketik daripada memecahkan pesan terenkripsi melalui kabel. Intinya adalah jika saya ditugaskan untuk mengomunikasikan rahasia yang sangat penting/penting, saya hanya akan menggunakan komunikasi elektronik sebagai metode pilihan terakhir.

Jadi ada risiko keamanan menggunakan komunikasi apa pun, tetapi Anda masih menggunakan browser web untuk perbankan, membeli barang, email, dll. Ini adalah risiko yang diterima untuk kemudahan besar yang diperoleh. Sungguh pertanyaannya adalah... apa risiko keamanan semi-spesifik untuk situs ini? Beberapa datang ke pikiran:

Apa yang Anda lakukan tentang serangan man-in-the-middle (MITM)?

Semua pengguna situs web berpotensi menjadi korban serangan MITM - situs ini tidak berbeda dengan situs web lainnya dalam hal ini. Serangan MITM adalah ketika penyerang mampu mencegat dan memodifikasi komunikasi antara browser pengguna dan server web situs. Hal ini memungkinkan penyerang untuk mengubah kode/konten situs mana pun sambil tetap terlihat oleh pengguna akhir sebagai situs yang biasa mereka kunjungi. Kami mengambil beberapa langkah untuk membuat serangan MITM lebih sulit:

Namun, serangan MITM masih selalu memungkinkan - terutama jika penyerang mengontrol infrastruktur jaringan/kunci publik seperti yang terjadi pada organisasi atau pemerintah besar/kuat. Kami menawarkan ekstensi browser yang dapat membantu mengurangi beberapa risiko MITM.

Apa keuntungan yang ditawarkan ekstensi browser?

Kami menawarkan ekstensi browser sebagai sarana untuk memberikan kenyamanan ekstra dan keamanan tambahan. Sederhananya... Ekstensi membuat pengiriman pesan sementara lebih cepat dan lebih mudah. Beberapa keamanan juga diperoleh karena semua kode yang digunakan untuk mengenkripsi dan menyiapkan pesan disimpan secara lokal di dalam ekstensi. Karena kode disimpan secara lokal, ini menawarkan perlindungan kepada pengirim terhadap serangan MITM . Namun, perlu ditunjukkan bahwa sementara ekstensi menawarkan lebih banyak perlindungan terhadap serangan MITM yang membahayakan isi pesan, serangan MITM masih bisa efektif (yaitu untuk menentukan alamat IP pengirim jika tidak menggunakan TOR/VPN/dll.).

Bagaimana saya bisa tahu dengan pasti bahwa apa pun yang dikirimkan dienkripsi ujung-ke-ujung?

Tidak seperti banyak klien obrolan terenkripsi ujung-ke-ujung (E2EE) populer lainnya, cukup mudah untuk melihat dengan tepat apa yang dikirimkan kepada kami saat Anda mengirimkan pesan. Tutorial video di bawah ini menunjukkan cara mengonfirmasi bahwa kami tidak memiliki cara untuk mendekripsi pesan yang dikirim ke server.

Juga, jika Anda memikirkannya, selama kami bukan agen rahasia yang mencoba mengumpulkan pesan sensitif, tidak ada gunanya kami mendekripsi pesan karena memiliki kemampuan itu hanya akan menimbulkan masalah bagi kami. Kami bahkan tidak ingin menyimpan pesan - itu adalah kejahatan yang diperlukan untuk mengirimkannya.

Bagaimana cara kerja enkripsi ujung ke ujung di situs ini?

Saat ini, kami menggunakan enkripsi simetris (AES-GCM 256bit) dengan kunci yang berasal dari kata sandi (minimal 150.000 iterasi PBKDF2/SHA-256). Enkripsi asimetris tidak digunakan karena ada persyaratan untuk 1) pengirim memulai komunikasi 2) pengirim dan penerima tidak online pada saat yang sama dan 3) tidak ada informasi tentang penerima dan 4) kami mencoba untuk menjaga semuanya tetap sederhana dan manajemen kuncinya rumit. Web Crypto API standar digunakan untuk semua fungsi kriptografi termasuk RNG. Pada dasarnya, inilah yang terjadi:

  1. Pengguna akhir memilih kata sandi atau kata sandi dibuat secara otomatis
  2. Panggilan API dilakukan untuk mendapatkan jumlah iterasi PBKDF2/SHA-256 yang diperlukan ( langkah ini diperlukan untuk kontrol spam )
  3. Garam 32 byte dihasilkan
  4. Kunci berasal dari garam dan kata sandi
  5. Vektor inisialisasi 12 byte (IV) dihasilkan
  6. Pesan dienkripsi menggunakan kunci + IV
  7. Hitungan iterasi, garam, IV, dan ciphertext dikirim ke server (bersama dengan beberapa informasi lain seperti TTL, RTL, dll.)
  8. Server mengembalikan ID acak yang mengacu pada pesan
  9. Browser kemudian menyajikan kepada pengguna akhir tautan yang berisi ID dan kata sandi yang dikembalikan atau tautan tanpa kata sandi (dalam hal ini penerima harus mengetahui dan memasukkan kata sandi)
  10. Jika kata sandi adalah bagian dari tautan, itu ada di hash URL , dan karena itu tidak pernah dikirim ke server ketika penerima membuat permintaan GET
  11. Penerima akan diminta jika mereka ingin mendekripsi dan melihat pesan
  12. Browser membuat permintaan yang menentukan ID pesan
  13. Jika pengirim membutuhkan CAPTCHA untuk diselesaikan, penerima diarahkan ke URL lain untuk membuktikan bahwa mereka adalah manusia (setelah mereka lulus, mereka akan diarahkan kembali)
  14. Server mengirimkan pesan terenkripsi dan secara default akan menghapus pesan pada saat ini jika reads-to-live (RTL) adalah salah satu
  15. Penerima akan mendekripsi pesan dengan kata sandi (dan dimintai kata sandi jika tidak ada di URL)
Pengaturan ini sangat sederhana, dan menawarkan enkripsi pesan dari perangkat pengirim ke perangkat penerima, tetapi tentu saja tidak memiliki jaminan bahwa enkripsi asimetris dapat menawarkan dalam hal mengetahui hanya seseorang yang memiliki kunci pribadi penerima yang dapat mendekripsi pesan. Siapa pun yang memiliki tautan dapat membuka pesan dalam skenario default di mana kata sandi adalah bagian dari URL - ini menggarisbawahi pentingnya menggunakan transportasi yang sesuai untuk tautan (yaitu email/obrolan/teks/dll.) - keputusan diserahkan kepada pengirim. Kami dapat, jika ada minat, juga meluncurkan dukungan untuk skema asimetris yang sangat mendasar di mana penerima memulai permintaan pesan dan mengirimkan tautan permintaan itu ke pengirim pesan. Pengaturan ini akan menghilangkan kebutuhan untuk memiliki kata sandi di URL, tetapi juga menghilangkan kemampuan pengirim untuk memulai.

Kata sandi dekripsi dapat di URL?

Iya. Ini jelas berdampak pada keamanan karena jika metode yang digunakan untuk mengirim tautan tidak aman, pesan tidak aman oleh asosiasi. Semua solusi untuk menghilangkan masalah ini memperkenalkan langkah-langkah tambahan dan kompleksitas yang berdampak pada pengalaman pengguna (yaitu hal-hal yang harus diatur di kedua ujungnya sebelum mengirim pesan). Skema asimetris di mana penerima memulai permintaan pesan dan mengirimkan tautan permintaan itu dapat bekerja dengan persyaratan kunci "semuanya fana" - ini dapat diterapkan. Pada akhirnya, jika dua pihak akan sering mengirim pesan satu sama lain, solusi yang lebih baik ada dengan asumsi kedua belah pihak dapat menangani menggunakan solusi tersebut.

Tetapi kata sandi dekripsi tidak harus ada di URL?

Benar. Jika kata sandi dekripsi tidak disertakan dalam tautan, maka penerima akan dimintai kata sandi. Jika kata sandi dikomunikasikan dengan aman ke penerima (atau mereka sudah mengetahuinya), ini memberikan perlindungan terhadap intersepsi. Namun kekurangannya adalah penerima harus mengetahui dan memasukkan password dengan benar. Berikut adalah salah satu cara untuk mengirim kata sandi ke penerima yang menawarkan perlindungan terhadap intersepsi:

  1. Enkripsi kata sandi dalam pesan dengan pengaturan default dan kirim tautan ini ke penerima.
  2. Ketika penerima mengklik tautan dan mendekripsi pesan, mereka tahu bahwa tidak ada orang lain yang mendapatkan kata sandi sebelumnya karena pesan yang berisi kata sandi dihapus saat diambil. Namun, jika ada serangan MITM aktif atau jika perangkat Anda atau perangkat penerima telah disusupi, maka masih ada kemungkinan pihak lain dapat memperoleh kata sandi.
  3. Konfirmasikan dengan penerima bahwa mereka telah berhasil memperoleh kata sandi. Misalnya, jika penerima memberi tahu Anda bahwa ketika mereka pergi untuk mengambil kata sandi, bahwa pesan telah dihapus, maka Anda tahu orang lain telah memperoleh kata sandi sebelum penerima dan bahwa kata sandi itu telah disusupi dan tidak boleh digunakan.
  4. Dengan menggunakan kata sandi yang dikonfirmasi penerima, Anda sekarang dapat mengirim pesan menggunakan kata sandi yang sama untuk enkripsi - cukup bagikan versi tautan yang tidak berisi kata sandi.

Itu benar - kami membuat tautan dan menyerahkannya kepada pengirim cara terbaik untuk mengirimkannya ke penerima. Tujuan dari layanan ini adalah untuk memberikan opsi yang menawarkan lebih sedikit keabadian dalam pengiriman pesan yang ada seperti email/obrolan/teks/dll. Oleh karena itu, harapannya adalah bahwa tautan yang kami hasilkan yang mengarah ke pesan sementara dikirim melalui transportasi pesan yang ada. Ini memang memiliki implikasi keamanan yang harus dipahami pengguna. Mari kita ambil pesan teks SMS sebagai contoh karena ini adalah metode komunikasi yang cukup tidak aman. Saat Anda menggunakan layanan ini untuk mengirim tautan pesan sementara melalui pesan teks, jika Anda menggunakan mode default di mana kata sandi disertakan dalam tautan, siapa pun yang memiliki tautan dapat membaca pesan dan tidak ada perlindungan terhadap intersepsi yang ditawarkan. Layanan ini masih menyediakan komunikasi yang lebih sementara yang dapat meningkatkan privasi dan keamanan. Selain itu, Anda dapat memilih untuk mengirim tautan tanpa kata sandi dan ini akan memberikan perlindungan terhadap intersepsi.

Bagaimana saya bisa melindungi privasi saya sebanyak mungkin saat menggunakan layanan ini?

Seperti yang dibahas di bagian lain dalam FAQ ini, meskipun kami telah melakukan banyak hal untuk melindungi privasi Anda dan meskipun kami tidak mengumpulkan informasi pribadi apa pun, beberapa informasi terkait log dikirimkan dan dikumpulkan oleh kami dan lainnya berdasarkan Anda menggunakan browser web. Namun, ada beberapa cara untuk lebih melindungi privasi Anda. Salah satu cara yang gratis untuk digunakan, berdasarkan perangkat lunak open source, dan bekerja dengan cukup baik adalah dengan menggunakan Tor Browser . Browser ini dirancang untuk melindungi privasi Anda di berbagai tingkatan - termasuk menggunakan jaringan Tor . Situs kami sudah dapat diakses melalui jaringan bawang Tor yang berarti mengakses situs kami melalui Tor tidak memerlukan penggunaan simpul keluar, yang meniadakan seseorang yang menguping lalu lintas simpul keluar . Namun, perlu diingat bahwa bahkan dalam skenario ini, ISP Anda dapat melihat bahwa Anda menggunakan Tor - meskipun bukan untuk apa. Anda bahkan dapat terhubung ke VPN dan kemudian meluncurkan Tor Browser untuk dua lapisan anonimitas; namun, perlu diingat bahwa ISP Anda masih dapat melihat Anda menggunakan VPN dalam skenario ini - meskipun bukan untuk apa. Jika Anda tidak ingin ISP Anda mengetahui protokol apa yang Anda gunakan, Anda dapat terhubung ke jaringan WiFi publik yang besar seperti perpustakaan, sekolah, dll., lalu menggunakan browser Tor.

Bagaimana jika saya tidak mempercayai Amerika Serikat?

Server kami berlokasi di Amerika Serikat. Selain itu, penyedia CDN kami, Cloudflare, adalah perusahaan yang berbasis di Amerika Serikat. Kami telah mencoba menghilangkan kebutuhan untuk mempercayai kami atau negara tempat server kami berada hanya karena kami tidak mengumpulkan informasi pribadi, tidak dapat mendekripsi pesan apa pun, dan semuanya dihapus segera setelah diterima. Namun, kami dapat memahami beberapa ketidakpercayaan karena ini berbasis web dan terutama jika Anda tinggal di negara tertentu. Kami memiliki beberapa rencana untuk menawarkan opsi di Islandia dan Swiss bagi orang-orang yang sulit mempercayai AS. Harap beri tahu kami jika ini berlaku untuk Anda, karena kami tidak akan termotivasi untuk menawarkan alternatif kecuali ada permintaan nyata.

Apa yang Anda lakukan untuk mencegah spam?

Setiap kali Anda mengizinkan seseorang untuk mengirim pesan yang dapat diteruskan melalui tautan, Anda mengundang spammer. Mengatasi masalah ini tidak sepenuhnya mudah. Kami tidak ingin memuat CAPTCHA pihak ketiga sebagai bagian dari proses pengiriman pesan karena beberapa alasan:

Kami mungkin dapat mengatasi masalah API dengan menggunakan beberapa sistem kunci API, tetapi kemudian kami harus mengumpulkan informasi pengguna yang tidak ingin kami lakukan. Juga, apa yang menghentikan spammer dari mendapatkan banyak kunci API? Kami tidak dapat memeriksa pesan untuk menyimpulkan spamnya (yang sangat bermasalah) karena, selain mengenkripsi pesan, kami memiliki kebijakan lepas tangan pada konten pesan. Mengingat persyaratan ini, kami menggunakan dua metode untuk mencegah spam: Jika Anda mengetahui bahwa spammer menyalahgunakan layanan ini, harap ajukan laporan penyalahgunaan .

Mengapa ada opsi untuk meminta penerima melengkapi CAPTCHA?

Meskipun benar bahwa kami tidak menyukai CAPTCHA, kami menyadari bahwa CAPTCHA memiliki tujuan dan memiliki waktu dan tempat (setidaknya untuk saat ini). Ini adalah cara sederhana bagi pengirim untuk mendapatkan jaminan bahwa penerima adalah manusia dan bahwa proses otomatis tidak mengakses pesan.

Siapa yang menjalankan layanan ini dan mengapa gratis?

Kami hanyalah pasangan yang terkadang dihadapkan pada kesulitan karena tidak memiliki pilihan yang baik untuk membantu melindungi privasi kami. Seringkali ini terjadi karena komunikasi dengan teman dan anggota keluarga yang tidak terlalu berhati-hati dengan cara mereka menangani perangkat dan informasi mereka. Lain kali ini terjadi ketika menggunakan forum berbasis web seperti Reddit atau menggunakan sistem dukungan berbasis web. Kami menemukan beberapa solusi pesan sementara berbasis web, tetapi tidak ada yang menawarkan E2EE yang berarti kami tidak dapat mempercayainya. Jadi kami baru saja membangun solusi kami sendiri dan memutuskan untuk memberikannya agar orang lain dapat mengambil manfaat darinya.

Bagaimana saya bisa mempercayai jawaban atas pertanyaan di atas?

Sungguh Anda tidak boleh mempercayai situs web mana pun hanya karena mengatakan hal-hal tertentu - biasanya merupakan ide bagus untuk memverifikasi klaim apa pun. Kami telah mencoba menghapus persyaratan untuk mempercayai kami sebanyak mungkin dengan menggunakan enkripsi ujung ke ujung. Misalnya, cukup mudah untuk mengaudit bahwa kami tidak dapat membaca pesan apa pun karena pesan tersebut dienkripsi . Kami juga menjaga agar kode javascript yang menjalankan situs ini sangat sederhana sehingga mudah dibaca dan dipahami. Membuat semua kode open source memungkinkan orang untuk memverifikasi apa yang sedang berjalan; namun, perlu diingat bahwa tidak ada cara untuk benar-benar memverifikasi apa yang dijalankan oleh server. Meskipun benar bahwa sebagian besar persyaratan kepercayaan dihapus dengan enkripsi ujung-ke-ujung, itu masih merupakan faktor yang banyak dipertimbangkan pengguna kami ketika memutuskan untuk menggunakan layanan ini atau tidak.