Sıkça Sorulan Sorular

Bu site neden kötü çevrilmiş? ⎃

Üzgünüz, ancak şu anki yazarlar yalnızca İngilizce konuşuyor. Bu projeyi diğer dillere çevirmek için yardıma ihtiyacımız var. Bu hizmeti İngilizce bilmeyen kişilere sunmak için basit ve ucuz bir yol olarak, makine çevirisini kullanıyoruz. Sonuçlar genellikle kabul edilebilir ancak garip ifadelere ve hatta tamamen yanlış bilgilere neden olabilir. Herkes için deneyimi iyileştirmemize yardımcı olabilirsiniz - lütfen doğru çeviriyi gönderin .

Bu hizmet ne kadar güvenli?

Bu hizmeti amaçlanan kullanım için güvenli hale getirmek için birçok adım attık. Bu adımları gözden geçirmeden önce, aşağıdakileri anlamak önemlidir:

Amacımız, bu hizmeti gizliliğinizi ve güvenliğinizi artıracak seçenekler sunan bir şekilde sunmaktır. Bilgilerinizi korumak için attığımız bazı adımlar şunlardır:

Neden burada bir mesajın şifresini çözme seçeneği olan bir bağlantı aldım?

Bu çeviride hatalar varsa özür dileriz. Bu hizmet, şifrelenmiş bir mesajı bir noktadan diğerine iletir ve alıcı sizsiniz. Mesaj yakında silinecek. Bu hizmetin operatörlerinin mesaj içeriğini okuma yolu yoktur. Genellikle birileri bu hizmeti, bir mesajın içeriğinin çeşitli veritabanları/cihazlar/hizmetler/dosyalar/vb. içinde kalmasını istemediğinde kullanır. bir e-posta/anlık mesaj/metin/vb. gönderirken olduğu gibi. Şifreyi çözmeye karar verirseniz, lütfen aşağıdakileri aklınızda bulundurun:

Bu siteye gönderilen her şeyi sildiniz mi?

Çöp kutusu logomuza uygun olarak... her şey alındıktan kısa bir süre sonra silinir. Her şeyin silinmesi otomatiktir - sunucuya yazılır. Bunu şu şekilde düşünün - gönderilen iki bilgi sınıfı vardır:

Mesajlar söz konusu olduğunda, bunları ne zaman sileceğimizi aşağıdakileri belirterek kontrol edebilirsiniz: Varsayılan olarak, bir mesajla ilgili her şey, bir kez alındıktan veya 1 haftalık olduktan sonra (hangisi önce gerçekleşirse) silinir. Web'de herhangi bir şey göndermenin doğasında bulunan diğer tüm bilgilerin (ör. IP adresiniz, vb.) silinmesi söz konusu olduğunda, bunların ne zaman veya nasıl silineceği konusunda size herhangi bir kontrol vermiyoruz - hepsini 24 saatte bir sileriz. .

Neden bu hizmeti kullanıyorsunuz?

Bu hizmet, gönderdiğiniz/aldığınız mesajların daha az kalıcı olmasına yardımcı olan bir araçtır. İnternette iletişim kurduğunuz şeylerin çoğu (sohbetler, metinler, e-postalar vb.) saklanır ve nadiren silinir. Çoğu zaman, bir şeyi sildiğinizde, aslında silinmez, bunun yerine silindi olarak işaretlenir ve artık size gösterilmez. Toplu iletişimleriniz her yıl veritabanlarında ve üzerinde kontrolünüz olmayan cihazlarda birikir. Kaçınılmaz olarak, iletişimlerinizi depolayan bir veya daha fazla kuruluş/kişi/cihaz hacklenir ve bilgileriniz sızdırılır. Bu sorun o kadar yaygın ki, artık güvenliği ihlal edilmiş ve kullanıcı verilerini sızdıran kuruluşları izleyen birçok web sitesi var. Uçtan uca şifrelenmiş geçici mesajlar, bazı iletişimlerinizin daha az kalıcı olmasına yardımcı olacak basit bir çözümdür. Bu siteye gönderilen her mesajın 1 dakika ile 2 hafta arasında değişen bir yaşam süresi vardır - bu süre geçtikten sonra mesaj silinir. Ayrıca, varsayılan ayar, alıcı mesajı aldıktan sonra herhangi bir mesajı silmektir. Ek olarak, tüm mesajlar cihazınızdan alıcının cihazına kadar şifrelenir. Uçtan uca şifrelemeyi kullanmanın temel amacı, gönderilen mesajları okuma yeteneğimizi ortadan kaldırarak güven gereksiniminin bir kısmını ortadan kaldırmaktır. Sonuç olarak, basit bir bağlantı aracılığıyla şifreli bir mesaj göndermek artık çok kolay. Bu mesaj, gönderildikten kısa bir süre sonra veya alındıktan sonra silinir. Özel yazılım yüklemeniz/yapılandırmanız gerekmez. Bir hesap oluşturmanız veya herhangi bir kişisel bilgi vermeniz gerekmez. Alıcının rehberinizde olması veya hatta bu hizmetten haberdar olması gerekmez - bir bağlantıyı tıklayabilmeleri için tek gereklilik.

Bu bir mesajlaşma servisi mi?

Hayır. Bu hizmet, anlık mesajlaşma/e-posta/metin/vb. gibi mevcut mesajlaşma hizmetlerini tamamlamak üzere tasarlanmıştır. gönderilen mesajların uzun süre saklanmasını önleme yeteneği ekleyerek. Oluşturulan bağlantıyı alıcıya teslim etmiyoruz .

Amaçlanan kullanım durumları nelerdir?

Peki bu hizmeti kullanmanın uygun olduğu bazı senaryolar nelerdir? Gizlilik ve güvenlik söz konusu olduğunda herkesin farklı ihtiyaçları ve gereksinimleri olsa da, kişisel olarak aşağıdaki senaryoları uygun kullanım durumları olarak buldum:

Bu hizmet ne için kullanılmamalıdır?

Bu hizmet, bu SSS'de açıklanan tüm nedenlerle çok hassas bilgiler için kullanılmamalıdır. Aşağıda ne yapılmaması gerektiğine dair bazı örnekler verilmiştir:

Neden sadece PGP/Signal/OMEMO/Matrix/vb. kullanmıyorsunuz?

Güvenli geçici mesajlar göndermek istediğiniz kişiyi tanıyorsanız, sık sık gönderin, sohbet benzeri bir arayüz bekliyorsanız ve/veya alıcının gerekli yazılıma sahip olmasını ve nasıl kullanılacağını bilmesini bekliyorsanız, bu web sitesi muhtemelen bu web sitesi değildir. en iyi çözüm. Açık kaynak kodlu, web tabanlı değil E2EE'yi destekleyen ve hatta geçici mesajları da destekleyen Signal gibi bazı harika seçenekler var. Yakın arkadaşlarım ve ailemle sohbet etmek için kişisel olarak özel bir XMMP sunucusu ve OMEMO kullanıyorum. Bu siteyi kullanmak, yalnızca alıcının hangi yazılımı çalıştırdığını bilmiyorsanız, telefon numarasını/iletişim adresini bilmiyorsanız, teknik yeterliliklerini bilmiyorsanız (ancak bir bağlantıya tıklayabileceklerini varsayalım) en uygun olabilir. veya gönderdiğiniz mesajı temel iletişim aktarımının dışında tutmayı tercih edersiniz.

Hangi gereksinimler var?

Web Crypto API dahil olmak üzere standartları düzgün şekilde uygulayan modern ve güncel bir web tarayıcısı gereklidir. Örnekler şunları içerir: Chrome, Firefox, Edge ve Safari (yaklaşık 2020 veya sonrası).

Alıcı mesajın bir kopyasını alabilir mi?

Evet. Mesaj alındıktan sonra kendini silebilse bile, alıcı mesajı görüntüleyebilir. Alıcı mesajı tamamen görüntüleyebildiği zaman, bir kopyası alınabilir - bu tüm iletişimler için geçerlidir. Alıcının bir kopya oluşturmasını zorlaştırma seçeneği vardır. Bu durumda kopyalama için üç engel uygulanır:

Ancak, bu kopya korumaları, atlanabildiklerinden zayıftır. Ayrıca, alıcı her zaman mesajın ekran görüntüsünü veya fotoğrafını çekebilir.

Herhangi bir kişisel bilgi toplanıyor mu?

Kullanıcı hesaplarını desteklemiyoruz (yani kullanıcı adı/şifre). Sizi tanımlayabilecek herhangi bir bilgi (yani ad/adres/e-posta/telefon) toplamıyoruz. Gönderdiğiniz mesajda bazı kişisel bilgilerin olması mümkündür, ancak bu şifrelidir ve okumamız mümkün değildir. Tüm ayrıntılar için lütfen gizlilik politikamızı inceleyin.

Hangi bilgiler günlüğe kaydedilir?

Web sunucumuz, tüm web etkinliklerinde 24 saate kadar ortak günlük formatı tutar. Bu, HTTP istemcilerinin tam IP adresinin günlüğe kaydedilmesini içerir. 24 saat sonra günlüğe kaydedilen bu bilgiler otomatik olarak silinir. /api'ye gönderilen tüm istekler POST edilir, yani web sunucusu tarafından mesaja özel hiçbir bilgi günlüğe kaydedilmez. Ayrıca, veritabanına kaydedilen tüm bilgiler etkin bir şekilde günlüğe kaydedilir. Anonimleştirilmiş ve karma IP adresleri de dahil olmak üzere veritabanındaki tüm girişlerin bir sona erme süresi (TTL) vardır ve ardından bunlar otomatik olarak silinir. TTL sona erme süreleri 1 dakika ile 2 hafta arasında değişir.

Sunucuların güvenliğini sağlamak için ne yapıyorsunuz?

Sunucu güvenliği bariz bir endişe kaynağıdır. Güvenliği sağlamak için odaklandığımız iki ana alan var:

Bu siteyi kullanırken hangi güvenlik riskleri mevcuttur?

Bu risklerden bazılarına özellikle değinmeden önce, herhangi bir İnternet iletişimini kullanmanın risklerini özetlemek için yarı kısa bir analojinin yardımcı olabileceğini düşünüyorum. Herhangi bir sistemin yalnızca bir zincirin en zayıf halkası kadar güvenli olduğunu gözünüzde canlandırın. Şimdi, mühürlü bir odada, yaptıkları hiçbir şeyi görme, duyma veya kaydetme olanağı olmayan iki kişinin olduğu bir senaryo hayal edin. Biri diğerine bir mesaj iletecek, mesajı okuduktan sonra onu yakacak. Eğer o odanın dışından biri geçmiş olan mesajı almak isterse, bu zor olacak. Mesajı almak için en zayıf halka nedir? Aralarından seçim yapabileceğiniz çok fazla bağlantı yok - oldukça kısa bir zincir. Şimdi, İnternet'te zincirde en az bir milyon bağlantı olduğunu - çoğu zayıf - birçoğunun tamamen kontrolünüz dışında olduğunu - bir mesaj gönderdiğinizi hayal edin ve bu gerçek.

Şifrelemeyi kullanmak, yukarıdaki milyon bağlantı sorununa büyük ölçüde yardımcı olabilir ve iyi tasarlanmış E2EE sistemlerinin her şeyin sonunda çözüm sunduğu düşüncesine kapılmak kolaydır. Ancak bu düşünce başınızı belaya sokabilir çünkü bir saldırgan genellikle sistemdeki zayıf halkaların peşine düşer. Örneğin, telefonunuzu veya bilgisayarınızı ele geçirmek ve yazdığınız her şeyi okumak için bir giriş kaydedici kurmak, kablo üzerinden şifreli mesajları kırmaktan muhtemelen çok daha kolaydır. Sonuç olarak, hayati/kritik öneme sahip bir sırrı iletmekle görevlendirilseydim, elektronik iletişimi yalnızca son çare olarak kullanırdım.

Bu nedenle, herhangi bir iletişimi kullanırken güvenlik riskleri vardır, ancak yine de bankacılık, bir şeyler satın alma, e-posta vb. için bir web tarayıcısı kullanıyorsunuz. Kazanılan büyük kolaylıklar için kabul edilen bir risk. Asıl soru şu ki... bu siteye yarı özel hangi güvenlik riskleri var? Birkaçı aklıma geliyor:

Ortadaki adam (MITM) saldırıları hakkında ne yapıyorsunuz?

Web sitelerinin tüm kullanıcıları potansiyel olarak bir MITM saldırısının kurbanı olabilir - bu site bu açıdan web'deki diğerlerinden farklı değildir. Bir MITM saldırısı , bir saldırganın kullanıcının tarayıcısı ile sitenin web sunucusu arasındaki iletişimi engelleyebildiği ve değiştirebildiği zamandır. Bu, saldırganın, son kullanıcıya alışık oldukları site gibi görünmeye devam ederken sitenin herhangi bir kodunu/içeriğini değiştirmesine olanak tanır. Bir MITM saldırısını daha zor hale getirmek için bazı önlemler alıyoruz:

Bununla birlikte, bir MITM saldırısı hala her zaman mümkündür - özellikle saldırgan, büyük/güçlü kuruluşlar veya hükümetler için olduğu gibi ağ/ortak anahtar altyapısını kontrol ediyorsa. Bazı MITM risklerini azaltmaya yardımcı olabilecek tarayıcı uzantıları sunuyoruz.

Tarayıcı uzantıları ne gibi avantajlar sunar?

Ekstra kolaylık ve ek güvenlik sağlamanın bir yolu olarak tarayıcı uzantıları sunuyoruz. Basitçe söylemek gerekirse... Uzantılar, geçici mesajların daha hızlı ve daha kolay gönderilmesini sağlar. Bir mesajı şifrelemek ve hazırlamak için kullanılan tüm kodlar uzantı içinde yerel olarak depolandığından, bir miktar güvenlik de elde edilir. Kod yerel olarak depolandığından, bu göndericiye MITM saldırılarına karşı bir miktar koruma sağlar. Bununla birlikte, uzantılar mesaj içeriğini tehlikeye atan bir MITM saldırısına karşı daha fazla koruma sağlarken, bir MITM saldırısının yine de etkili olabileceğini belirtmekte fayda var (yani, TOR/VPN/vb kullanmıyorsa gönderenin IP adresini belirlemek için).

Gönderilen herhangi bir şeyin uçtan uca şifreli olduğundan nasıl emin olabilirim?

Diğer birçok popüler uçtan uca şifreli (E2EE) sohbet istemcisinin aksine, bir mesaj gönderdiğinizde bize tam olarak ne gönderildiğini görmek oldukça basittir. Aşağıdaki eğitim videosu, sunucuya gönderilen mesajların şifresini çözmenin hiçbir yolu olmadığını nasıl onaylayacağımızı gösterir.

Ayrıca, bunu düşünürseniz, hassas mesajları toplamaya çalışan bir gizli teşkilat olmadığımız sürece, mesajların şifresini çözebilmemizin hiçbir faydası yoktur, çünkü bu yeteneğe sahip olmak sadece bizim için sorun yaratır. Mesajları saklamak bile istemiyoruz - ancak onları iletmek için gerekli bir kötülük.

Bu sitede uçtan uca şifreleme nasıl çalışır?

Şu anda, parolalardan türetilen anahtarlarla simetrik şifreleme (AES-GCM 256bit) kullanıyoruz (en az 150.000 PBKDF2/SHA-256 yinelemesi). 1) Göndericinin iletişimi başlatması 2) Gönderici ve alıcının aynı anda çevrimiçi olmaması ve 3) Alıcı hakkında hiçbir bilgi olmaması ve 4) İşleri gerçekten basit tutmaya çalıştığımız için asimetrik şifreleme kullanılmaz ve anahtar yönetimi karmaşık. Standart Web Crypto API, RNG dahil tüm şifreleme işlevleri için kullanılır. Temel olarak, burada ne olur:

  1. Son kullanıcı bir parola seçer veya bir parola otomatik olarak oluşturulur
  2. Gerekli PBKDF2/SHA-256 yineleme sayısını elde etmek için bir API çağrısı yapılır ( bu adım spam kontrolü için gereklidir )
  3. 32 baytlık bir tuz üretilir
  4. Tuz ve paroladan bir anahtar türetilir
  5. 12 baytlık bir başlatma vektörü (IV) oluşturulur
  6. Mesaj + IV anahtarı kullanılarak şifrelenir
  7. Yineleme sayısı, salt, IV ve şifreli metin sunucuya gönderilir (TTL, RTL vb. diğer bazı bilgilerle birlikte)
  8. Sunucu, mesaja atıfta bulunan rastgele bir kimlik döndürür
  9. Tarayıcı daha sonra son kullanıcıya döndürülen kimliği ve parolayı içeren bir bağlantı veya parolasız bir bağlantı sunar (bu durumda alıcının parolayı bilmesi ve girmesi gerekir)
  10. Parola bağlantının bir parçasıysa, hash URL'sindedir ve bu nedenle alıcı GET isteğinde bulunduğunda asla sunucuya gönderilmez.
  11. Alıcıya mesajın şifresini çözmek ve görüntülemek isteyip istemediği sorulur
  12. Tarayıcı, mesaj kimliğini belirten bir istekte bulunur
  13. Gönderici bir CAPTCHA'nın tamamlanmasını isterse, alıcı insan olduklarını kanıtlamak için başka bir URL'ye yönlendirilir (geçtiklerinde geri yönlendirilirler)
  14. Sunucu şifreli mesajı gönderir ve canlı okuma (RTL) bir ise bu noktada mesajı varsayılan olarak siler.
  15. Alıcı, mesajın şifresini şifre ile çözecektir (ve URL'de değilse şifre sorulacaktır)
Bu kurulum son derece basittir ve gönderenin cihazından alıcının cihazına mesaj şifrelemesi sunar, ancak elbette asimetrik şifrelemenin sunabileceği garantiden yoksundur, çünkü yalnızca alıcının özel anahtarına sahip olan birinin mesajın şifresini çözebileceğini bilmek açısından. Bağlantıya sahip olan herkes, parolanın URL'nin bir parçası olduğu varsayılan senaryoda mesajı açabilir - bu, bağlantı için uygun bir aktarım (örn. e-posta/sohbet/metin/vb.) kullanmanın önemini vurgular - bu karar kullanıcıya bırakılmıştır. gönderen. İlgi olması durumunda, alıcının bir mesaj talebi başlattığı ve bu istek bağlantısını mesajın göndericisine gönderdiği çok temel bir asimetrik şema için destek de sunabiliriz. Bu kurulum, URL'de parola bulunması ihtiyacını ortadan kaldırır, ancak aynı zamanda gönderenin başlatma yeteneğini de ortadan kaldırır.

Şifre çözme şifresi URL'de olabilir mi?

Evet. Bu açıkça güvenliği etkiler, çünkü bağlantıyı göndermek için kullanılan yöntem güvensizse, mesaj ilişkilendirmeden dolayı güvensizdir. Bu sorunu ortadan kaldırmaya yönelik tüm geçici çözümler, kullanıcı deneyimini etkileyen ek adımlar ve karmaşıklıklar getirir (yani, mesajı göndermeden önce işlerin her iki uçta da ayarlanması gerekir). Alıcının bir mesaj isteği başlattığı ve bu istek bağlantısını gönderdiği asimetrik bir şema "her şey geçicidir" anahtar gereksinimimizle çalışabilir - bu uygulanabilir. Sonuç olarak, iki taraf birbirine sık sık mesaj gönderecekse, her iki tarafın da bu çözümleri kullanarak başa çıkabileceğini varsayarak daha iyi çözümler vardır.

Ancak şifre çözme şifresinin URL'de olması gerekmez mi?

Doğru. Şifre çözme şifresi bağlantıda yer almıyorsa, alıcıdan şifre istenecektir. Parola alıcıya güvenli bir şekilde iletildiyse (veya zaten biliyorsa), bu, müdahaleye karşı koruma sağlar. Ancak dezavantajı, alıcının şifreyi bilmesi ve doğru girmesi gerektiğidir. Şifreyi, müdahaleye karşı bir miktar koruma sağlayan alıcıya göndermenin bir yolu:

  1. Varsayılan ayarlarla bir mesajdaki şifreyi şifreleyin ve bu bağlantıyı alıcıya gönderin.
  2. Alıcı bağlantıya tıkladığında ve mesajın şifresini çözdüğünde, şifreyi içeren mesaj alındıktan sonra silindiğinden başka kimsenin şifreyi kendilerinden önce almadığını bilirler. Ancak, etkin bir MITM saldırısı varsa veya cihazınız veya alıcının cihazının güvenliği ihlal edilmişse, başka bir tarafın şifreyi alması yine de olasıdır.
  3. Parolayı başarıyla aldıklarını alıcıyla onaylayın. Örneğin, alıcı şifreyi almaya gittiğinde mesajın zaten silindiğini size bildirirse, o zaman başka birinin şifreyi alıcıdan önce aldığını ve bu nedenle şifrenin ele geçirildiğini ve kullanılmaması gerektiğini bilirsiniz.
  4. Alıcının sahip olduğunu onayladığı şifreyi kullanarak, artık şifreleme için aynı şifreyi kullanarak bir mesaj gönderebilirsiniz - sadece bağlantının şifreyi içermeyen sürümünü paylaşın.

Bu doğru - bağlantıyı oluşturuyoruz ve alıcıya en iyi nasıl iletileceğini gönderene bırakıyoruz. Bu hizmetin amacı, e-posta/sohbet/metin/vb. gibi mevcut mesaj aktarımlarında daha az kalıcılık sunan bir seçenek sunmaktır. Bu nedenle, geçici mesaja işaret eden oluşturduğumuz bağlantının mevcut bir mesaj aktarımı yoluyla gönderilmesi beklenir. Bunun, kullanıcıların anlaması gereken güvenlik etkileri vardır. Oldukça güvensiz bir iletişim yöntemi olduğu için örnek olarak bir SMS metin mesajını ele alalım. Kısa mesaj yoluyla geçici mesaj bağlantısı göndermek için bu hizmeti kullandığınızda, parolanın bağlantıya dahil edildiği varsayılan modu kullanırsanız, bağlantıya sahip olan herkes mesajı okuyabilir ve müdahaleye karşı herhangi bir koruma sunulmaz. Bu hizmet, gizliliği ve güvenliği artırabilecek daha geçici bir iletişim sağlamaya devam eder. Ek olarak, bağlantıyı şifre olmadan göndermeyi seçebilirsiniz ve bu, müdahaleye karşı koruma sağlayacaktır.

Bu hizmeti kullanırken gizliliğimi mümkün olduğunca nasıl koruyabilirim?

Bu SSS'de başka bir yerde tartışıldığı gibi , gizliliğinizi korumak için zaten çok şey yapsak da ve herhangi bir kişisel bilgi toplamasak da, günlükle ilgili bazı bilgiler bizim tarafımızdan ve diğerleri tarafından bir web tarayıcısı kullanarak gönderilir ve toplanır. Ancak, gizliliğinizi daha da fazla korumanın birden fazla yolu vardır. Açık kaynaklı yazılıma dayalı, kullanımı ücretsiz ve oldukça iyi çalışan bir yol Tor Tarayıcı kullanmaktır. Bu tarayıcı, Tor ağını kullanmak da dahil olmak üzere, gizliliğinizi birden çok düzeyde korumak için tasarlanmıştır. Sitemize Tor soğan ağı üzerinden zaten erişilebilir, bu da sitemize Tor aracılığıyla erişmenin bir çıkış düğümü kullanımını gerektirmediği anlamına gelir, bu da birinin çıkış düğümü trafiğini dinlemesini engeller. Ancak, bu senaryoda bile, ISS'nizin Tor'u ne için kullanmasanız da kullandığınızı görebileceğini unutmayın. Hatta bir VPN'ye bağlanabilir ve ardından iki katman anonimlik için Tor Tarayıcı'yı başlatabilirsiniz; ancak, ISS'nizin bu senaryoda bir VPN kullandığınızı görebileceğini unutmayın - ne için olmasa da. ISS'nizin hangi protokolleri kullandığınızı bilmesini istemiyorsanız, kütüphane, okul vb. gibi büyük bir genel WiFi ağına bağlanabilir ve ardından Tor tarayıcısını kullanabilirsiniz.

Amerika Birleşik Devletleri'ne güvenmezsem ne olur?

Sunucularımız Amerika Birleşik Devletleri'nde bulunmaktadır. Ayrıca, CDN sağlayıcımız Cloudflare, Amerika Birleşik Devletleri merkezli bir şirkettir. Kişisel bilgileri toplamadığımız, herhangi bir mesajın şifresini çözemediğimiz ve alındıktan kısa bir süre sonra her şey silindiği için bize veya sunucularımızın bulunduğu ülkeye güvenme ihtiyacını ortadan kaldırmaya çalıştık. Ancak, web tabanlı olduğu için ve özellikle belirli ülkelerde yaşıyorsanız, bazı güvensizlikleri anlayabiliriz. ABD'ye güvenmekte zorlanan insanlara İzlanda ve İsviçre'de seçenekler sunmak için bazı planlarımız var. Lütfen bunun sizin için geçerli olup olmadığını bize bildirin , çünkü gerçek bir talep olmadıkça alternatifler sunmak için motive olmayacağız.

Spam'i önlemek için ne yapıyorsunuz?

Birinin bağlantı yoluyla iletilebilecek bir mesaj göndermesine her izin verdiğinizde, spam gönderenleri davet etmiş olursunuz. Bu sorunu engellemek tamamen kolay değil. Birkaç nedenden dolayı mesaj gönderme işleminin bir parçası olarak 3. taraf CAPTCHA yüklemek istemiyoruz:

Bazı API anahtar sistemlerini kullanarak API sorununu çözebiliriz, ancak daha sonra yapmak istemediğimiz kullanıcı bilgilerini toplamamız gerekir. Ayrıca, spam göndericilerin çok sayıda API anahtarı almasını engelleyen nedir? İletileri, spam olup olmadıklarını (en iyi ihtimalle çok sorunludur) anlamak için inceleyemiyoruz, çünkü iletileri şifrelemenin dışında, ileti içeriğiyle ilgili bir müdahale politikamız var. Bu gereksinimler göz önüne alındığında, spam'i önlemek için iki yöntem kullanıyoruz: Spam gönderenlerin bu hizmeti kötüye kullandığını biliyorsanız, lütfen bir kötüye kullanım raporu gönderin .

Alıcının bir CAPTCHA tamamlamasını zorunlu kılma seçeneği neden var?

CAPTCHA'ları sevmediğimiz doğru olsa da, bunların bir amaca hizmet ettiğinin ve bir zaman ve yere sahip olduklarının (en azından şimdilik) farkındayız. Bu, gönderenin, alıcının insan olduğuna ve otomatik süreçlerin mesaja erişmediğine dair bir güvence elde etmesinin basit bir yoludur.

Bu hizmeti kim çalıştırıyor ve neden ücretsiz?

Biz sadece gizliliğimizi korumaya yardımcı olacak iyi seçeneklere sahip olamama çıkmazıyla karşı karşıya kalan birkaç kişiyiz. Çoğu zaman bu, cihazlarını ve bilgilerini nasıl kullandıklarına çok dikkat etmeyen arkadaşlar ve aile üyeleriyle iletişim kurmaktan kaynaklandı. Bazen bu, Reddit gibi web tabanlı forumları kullanırken veya web tabanlı destek sistemlerini kullanırken ortaya çıktı. Bazı web tabanlı geçici mesaj çözümleri bulduk, ancak hiçbiri E2EE sunmadı, bu da onlara güvenemeyeceğimiz anlamına geliyordu. Bu yüzden sadece kendi çözümümüzü oluşturduk ve başkalarının faydalanabilmesi için onu vermeye karar verdik.

Yukarıdaki soruların cevaplarına nasıl güvenebilirim?

Gerçekten de herhangi bir web sitesine sırf belirli şeyler söylediği için güvenmemelisiniz - genellikle herhangi bir iddiayı doğrulamak iyi bir fikirdir. Bize güvenme zorunluluğunu uçtan uca şifreleme ile mümkün olduğunca ortadan kaldırmaya çalıştık. Örneğin, şifreli oldukları için hiçbir mesajı okuyamayacağımızı denetlemek oldukça kolaydır. Ayrıca, bu siteyi çalıştıran javascript kodunu , okunması ve anlaşılması kolay olacak şekilde çok basit tuttuk. Tüm kodu açık kaynak yapmak, insanların neyin çalıştığını doğrulamasını sağlar; ancak, sunucunun ne çalıştığını gerçekten doğrulamanın bir yolu olmadığını unutmayın. Güven gereksiniminin çoğunun uçtan uca şifreleme ile kaldırıldığı doğru olsa da, bu hizmeti kullanıp kullanmamaya karar verirken yine de kullanıcılarımızın üzerinde durduğu bir faktördür.