Gyakran Ismételt Kérdések

Miért van rosszul lefordítva ez az oldal? ⎃

Sajnáljuk, de a jelenlegi szerzők csak angolul beszélnek. Segítségre van szükségünk a projekt más nyelvekre történő lefordításához. Gépi fordítást alkalmazunk egyszerű és olcsó eszközként, hogy ezt a szolgáltatást elérhetővé tegyük az angolul nem beszélő emberek számára. Az eredmények általában elfogadhatóak, de furcsa megfogalmazást vagy akár teljesen pontatlan információkat is eredményezhetnek. Segíthet javítani a felhasználói élményt mindenki számára - kérjük, küldje el a helyes fordítást .

Mennyire biztonságos ez a szolgáltatás?

Sok lépést megtettünk annak érdekében, hogy ez a szolgáltatás biztonságos legyen a rendeltetésszerű használat szempontjából . Mielőtt átmennénk ezeken a lépéseken, fontos megértenünk a következőket:

Célunk, hogy ezt a szolgáltatást olyan módon kínáljuk fel, amely lehetőséget kínál a magánélet és a biztonság fokozására. Íme néhány lépés, amelyet megtettünk az Ön adatainak védelme érdekében:

Miért kaptam itt egy linket az üzenet visszafejtésének lehetőségével?

Elnézést kérünk, ha hibák vannak ebben a fordításban . Ez a szolgáltatás egyszerűen továbbít egy titkosított üzenetet egyik pontról a másikra, és Ön a címzett. Az üzenetet hamarosan töröljük. A szolgáltatás üzemeltetői nem tudják elolvasni az üzenet tartalmát. Általában valaki akkor használja ezt a szolgáltatást, ha nem akarja, hogy az üzenet tartalma különféle adatbázisokban / eszközökben / szolgáltatásokban / fájlokban / stb. Maradjon. mint az e-mail / azonnali üzenet / szöveg / stb. küldésénél jellemző. Ha a visszafejtés mellett dönt, kérjük, vegye figyelembe a következőket:

Törölsz mindent, amit erre a webhelyre küldtek?

A kuka logónkhoz híven ... minden hamarosan törlődik, miután megkapta. Minden törlése automatizált - a szerverre írva. Gondoljon erre így - a benyújtott információknak két osztálya van:

Üzenetek esetén az alábbiak megadásával szabályozhatja, hogy mikor töröljük őket: Alapértelmezés szerint minden üzenet törlődik, miután egyszer letöltötte vagy 1 hetes - amelyik előbb bekövetkezik. Amikor törölni kell az összes egyéb információt, ami a weben történő bármelyik beküldésben rejlik (pl. Az IP-címed stb.), Nem adunk semmilyen ellenőrzést arról, hogy mikor vagy hogyan törölhető - csak 24 óránként töröljük az összeset. .

Miért használja ezt a szolgáltatást?

Ez a szolgáltatás egy olyan eszköz, amely segít az elküldött / fogadott üzenetek állandóbbá tételében. A legtöbb, amit az interneten kommunikál (csevegések, szövegek, e-mailek stb.), Tárolódik és ritkán törlődik. Gyakran, amikor valamit töröl, az valójában nem törlődik, hanem töröltként van megjelölve, és már nem jelenik meg Önnek. Az összesített kommunikáció évről évre felhalmozódik az adatbázisokban és azokon az eszközökön, amelyek felett Ön nem rendelkezik irányítással. Óhatatlanul feltörik egy vagy több szervezetet / embert / eszközt, amelyek tárolják a kommunikációt, és az Ön információi kiszivárognak. Ez a probléma annyira elterjedt, hogy ma már sok olyan webhely található, amelyek nyomon követik a sértett és kiszivárogtatott szervezeteket. A végponttól végpontig titkosított ideiglenes üzenetek egyszerű megoldást kínálnak arra, hogy néhány kommunikációja kevésbé állandó legyen. Minden, a webhelyre beküldött üzenet élettartama 1 perc és 2 hét között mozog - ha ez az idő letelt, az üzenetet törlik. Ezenkívül az alapértelmezett beállítás minden üzenet törlése, amint a címzett letölti azt. Ezenkívül az összes üzenet titkosítva van a készülékről egészen a címzett eszközéig. A végpontok közötti titkosítás használatának fő célja, hogy megszüntessük a beküldött üzenetek elolvasásának képességét, ezáltal megszüntetve a bizalom követelményét. A végeredmény az, hogy ma már egyszerű egy linken keresztül titkosított üzenetet elküldeni. Ezt az üzenetet nem sokkal a küldés után, vagy visszakereséskor törlik. Nem kell speciális szoftvert telepítenie / konfigurálnia. Nem kell fiókot létrehoznia vagy személyes adatokat megadnia. A címzettnek nem kell szerepelnie az ismerőseiben, vagy akár tudnia kell erről a szolgáltatásról - az egyetlen követelmény, hogy rákattinthasson egy linkre.

Ez egy üzenetküldő szolgáltatás?

Nem. Ezt a szolgáltatást úgy tervezték, hogy kiegészítse a meglévő üzenetküldési szolgáltatásokat, mint például az azonnali üzenetküldés / e-mail / szöveg / stb. hozzáadva az elküldött üzenetek hosszú ideig történő tárolásának megakadályozását. A generált linket nem juttatjuk el a címzetthez .

Melyek a tervezett felhasználási esetek?

Tehát milyen esetekben érdemes használni ezt a szolgáltatást? Bár mindenkinek más igényei és követelményei vannak a magánélet és a biztonság szempontjából, én személy szerint a következő forgatókönyveket találtam megfelelő felhasználási eseteknek:

Mire ne használja ezt a szolgáltatást?

Ezt a szolgáltatást nem szabad nagyon érzékeny információkhoz használni a GYIK-ben ismertetett összes ok miatt. Az alábbiakban bemutatunk néhány példát arra, hogy mit ne tegyünk:

Miért nem csak a PGP / Signal / OMEMO / Matrix / stb.

Ha ismeri azt a személyt, akinek biztonságos ideiglenes üzeneteket szeretne küldeni, gyakran küldi el, elvár egy csevegésszerű felületet, és / vagy elvárhatja, hogy a címzett rendelkezzen a szükséges szoftverrel és tudja, hogyan kell használni, akkor valószínűleg ez a webhely nem az legjobb megoldás. Vannak olyan nagyszerű lehetőségek, amelyek nyílt forráskódúak, támogatják az E2EE-t, nem webalapúak, sőt vannak olyanok is, mint a Signal, amelyek támogatják az ideiglenes üzeneteket is. Személyesen használok egy privát XMMP szervert és az OMEMO-t, hogy csevegjek közeli barátaimmal és családtagjaimmal. Ennek a webhelynek a használata csak akkor lehet optimális, ha nem tudja, hogy a címzett milyen szoftvert futtat, nem ismeri a telefonszámát / kapcsolattartóját, nem ismeri a technikai hozzáértését (de feltételezzük, hogy rákattinthatnak egy linkre), vagy inkább csak az elküldött üzenetet szeretné az alapul szolgáló kommunikációs szállításon kívül tartani.

Milyen követelmények vannak?

Egy modern és naprakész böngészőre van szükség, amely megfelelően végrehajtja a szabványokat, beleértve a Web Crypto API-t is. Példák: Chrome, Firefox, Edge és Safari (2020 körül vagy később).

Készíthet másolatot a címzett az üzenetről?

Igen. Annak ellenére, hogy az üzenet visszakereséskor törölheti magát, a címzett továbbra is megtekintheti az üzenetet. Bármikor a vevő teljesen megtekintheti az üzenetet, másolat készíthető - ez minden kommunikációra vonatkozik. Van egy lehetőség, hogy megnehezítse a címzett számára a másolat készítését. Ebben az esetben a másolás három akadálya valósul meg:

Ezek a másolásvédelem azonban gyenge, mert megkerülhetők. Ezenkívül a címzett mindig csak képet készíthet vagy fényképet készíthet az üzenetről.

Gyűjtenek személyes adatokat?

Nem támogatjuk a felhasználói fiókokat (azaz felhasználónév / jelszó). Nem gyűjtünk olyan információkat, amelyek azonosíthatnák Önt (például név / cím / e-mail cím / telefonszám). Lehetséges, hogy néhány személyes adat lehet az Ön által küldött üzenetben, de ez titkosítva van, és nincs módunk elolvasni. A részletekért olvassa el adatvédelmi irányelveinket .

Milyen információkat naplóznak?

Webszerverünk akár 24 órányi közös naplóformátumot is tárol minden webes tevékenységen. Ez magában foglalja a HTTP kliensek teljes IP-címének naplózását. 24 óra elteltével ez a naplózott információ automatikusan törlődik. Az / api-nak küldött összes kérés POST-el van jelölve, ami azt jelenti, hogy a webszerver soha nem naplóz üzenetre vonatkozó információkat. Ezenkívül minden, az adatbázisba mentett információt hatékonyan naplózunk. Az adatbázis minden bejegyzésének, beleértve az anonimizált és kivonatolt IP-címeket is, lejárati ideje (TTL) van, amely után automatikusan törli őket. A TTL lejárati ideje 1 perc és 2 hét között változik.

Mit tesz a szerverek biztonsága érdekében?

A szerver biztonsága nyilvánvaló aggodalomra ad okot. Két fő területre koncentrálunk a biztonság megőrzése érdekében:

Milyen biztonsági kockázatok vannak jelen webhely használatakor?

Mielőtt konkrétan foglalkoznék e kockázatok némelyikével, úgy gondolom, hogy egy félig rövid analógia segíthet összefoglalni az internetes kommunikáció használatával kapcsolatos kockázatokat. Képzelje el, hogy bármely rendszer csak annyira biztonságos, mint a lánc leggyengébb láncszeme. Most képzeljen el egy olyan forgatókönyvet, amikor egy zárt szobában két ember van, és semmilyen eszköz nincs arra, hogy bármit is láthassanak, halljanak vagy rögzítsenek. Az egyik továbbít egy üzenetet a másiknak, akit az üzenet elolvasása után megéget. Ha valaki azon a szobán kívül szeretné megszerezni a már átadott üzenetet, az nehéz lesz. Mi a leggyengébb láncszem az üzenet megszerzéséhez? Nincs olyan sok link, amelyek közül választhatna - ez elég rövid lánc. Most képzelje el, hogy amikor az interneten üzenetet küld arról, hogy legalább egymillió link van a láncban - sok közülük gyenge - sokan teljesen kívül esnek az ön irányításában, és ez a valóság.

A titkosítás használata nagyban hozzájárulhat a fenti egymillió linkprobléma megoldásához, és könnyű elgondolkodtatni abban, hogy a jól megtervezett E2EE rendszerek kínálják a végső megoldást. Ez a gondolkodás azonban bajba sodorhatja, mert a támadó általában csak a rendszer gyengébb láncszemeit követi. Például valószínűleg sokkal könnyebb átvenni a telefont vagy a számítógépet, és beállítani egy bemeneti naplózót, hogy csak elolvassa mindazt, amit beír, mint a titkosított üzenetek feltörése a vezetéken. A lényeg az, hogy ha egy létfontosságú / kritikus fontosságú titok közlését kapnám feladatomra, akkor az elektronikus kommunikációt csak végső megoldásként használnám.

Tehát bármilyen kommunikáció esetén vannak biztonsági kockázatok, de továbbra is webböngészőt használ banki szolgáltatásokhoz, dolgok vásárlásához, e-mailekhez stb. Ez a megszerzett hatalmas kényelem miatt elfogadott kockázat. Valóban a kérdés ... milyen biztonsági kockázatok vannak félig specifikusak ezen a webhelyen? Néhányan eszembe jutnak:

Mit csinál az ember a közepén (MITM) támadásokkal kapcsolatban?

A weboldalak minden felhasználója potenciálisan MITM-támadás áldozata lehet - ez a webhely ebben a tekintetben nem különbözik a weben található összes többi személytől. A MITM támadás az, amikor a támadó képes elfogni és módosítani a felhasználó böngészője és a webhely webszervere közötti kommunikációt. Ez lehetővé teszi a támadó számára, hogy módosítsa a webhely bármelyik kódját / tartalmát, miközben a végfelhasználó számára továbbra is a megszokottnak tűnik. Néhány intézkedést megteszünk a MITM-támadás megnehezítése érdekében:

A MITM-támadás azonban továbbra is lehetséges - különösen, ha a támadó ellenőrzi a hálózati / nyilvános kulcsú infrastruktúrát, ahogyan ez a nagy / hatalmas szervezetek vagy kormányok esetében lenne. Böngészőbővítményeket kínálunk, amelyek segíthetnek egyes MITM-kockázatok enyhítésében.

Milyen előnyöket kínálnak a böngészőbővítmények?

Böngészőbővítményeket kínálunk , amelyek extra kényelmet és biztonságot nyújtanak. Egyszerűen fogalmazva ... A bővítmények megkönnyítik az ideiglenes üzenetek küldését. Némi biztonságot azért is szerez, mert az üzenet titkosításához és előkészítéséhez használt összes kódot helyileg tárolják a kiterjesztésben. Mivel a kódot helyileg tárolják, ez némi védelmet nyújt a feladónak a MITM támadásokkal szemben . Érdemes azonban felhívni a figyelmet arra, hogy bár a bővítmények nagyobb védelmet nyújtanak az üzenet tartalmát veszélyeztető MITM-támadással szemben, a MITM-támadás mégis hatékony lehet (azaz meghatározhatja a feladó IP-címét, ha nem használ TOR / VPN / stb.).

Honnan tudhatom biztosan, hogy bármi beküldött tartalom titkosítva van?

Sok más népszerű end-to-end titkosított (E2EE) csevegő klienstől eltérően meglehetősen egyszerű pontosan megnézni, hogy mit küld nekünk, amikor üzenetet küld. Az alábbi videó bemutató bemutatja, hogyan lehet megerősíteni, hogy nincs lehetőségünk a szerverre küldött üzenetek visszafejtésére.

Továbbá, ha belegondolunk, mindaddig, amíg nem vagyunk titkos ügynökségek, akik érzékeny üzeneteket próbálnak gyűjteni, nincs előnyünk, ha visszafejtjük az üzeneteket, mivel ez a képesség csak problémákat okoz számunkra. Nem is akarunk üzeneteket tárolni - ez azonban egy szükségszerű rossz, hogy eljusson hozzájuk.

Hogyan működik a végpontok közötti titkosítás ezen a webhelyen?

Jelenleg szimmetrikus titkosítást (AES-GCM 256bit) használunk jelszavakból levezetett kulcsokkal (legalább 150 000 PBKDF2 / SHA-256 ismétlés). Az aszimmetrikus titkosítást nem használják, mert követelmények vonatkoznak arra, hogy 1) a kommunikációt kezdeményező küldő 2) a küldő és a címzett ne legyen online egyszerre, és 3) nincs információ a címzettről, és 4) megpróbáljuk a dolgokat egyszerűvé tenni és a kulcskezelés bonyolult. A szokásos Web Crypto API-t minden kriptográfiai funkcióhoz használják, beleértve az RNG-t is. Alapvetően a következő történik:

  1. A végfelhasználó választ egy jelszót, vagy automatikusan generál egyet
  2. API-hívás történik a szükséges PBKDF2 / SHA-256 iterációk számának megszerzéséhez ( erre a lépésre van szükség a levélszemét-vezérléshez )
  3. 32 bájtos só keletkezik
  4. A kulcs a sóból és a jelszóból származik
  5. Egy 12 bájtos inicializáló vektor (IV) jön létre
  6. Az üzenet a + IV billentyűvel van titkosítva
  7. Az iterációszám, a só, az IV és a titkosított szöveg elküldésre kerül a szerverre (néhány egyéb információval együtt, pl. TTL, RTL stb.)
  8. A szerver véletlenszerű azonosítót ad vissza az üzenetre hivatkozva
  9. Ezután a böngésző egy linket mutat be a végfelhasználó számára, amely tartalmazza a visszaküldött azonosítót és jelszót, vagy egy jelszó nélküli linket (ebben az esetben a címzettnek tudnia kell és meg kell adnia a jelszót)
  10. Ha a jelszó a link része, akkor az URL kivonatban van , ezért soha nem küldi el a szervernek, amikor a címzett GET kérést küld
  11. A címzett megkérdezi, hogy kívánja-e visszafejteni és megtekinteni az üzenetet
  12. A böngésző kérést küld az üzenet azonosítójának megadásával
  13. Ha a feladó megköveteli egy CAPTCHA kitöltését, a címzettet egy másik URL-re irányítják, hogy igazolja, hogy ember (ha átadta őket, visszairányítják).
  14. A szerver elküldi a titkosított üzenetet, és alapértelmezés szerint ezen a ponton törli az üzenetet, ha az azonnali olvasás (RTL) egy
  15. A címzett visszafejti az üzenetet jelszóval (és a rendszer kéri a jelszó megadását, ha nem szerepel az URL-ben)
Ez a beállítás rendkívül egyszerű, és az üzenet titkosítását kínálja a feladó eszközéről a címzett eszközére, de természetesen nincs garancia arra, hogy az aszimmetrikus titkosítás abban rejlik, hogy csak azt ismerjük, hogy csak a címzett privát kulcsának birtokosa tudja visszafejteni az üzenetet. A link birtokában bárki megnyithatja az üzenetet az alapértelmezett forgatókönyv szerint, amikor a jelszó az URL része - ez aláhúzza annak fontosságát, hogy megfelelő linket használjon a linkhez (pl. E-mail / csevegés / szöveg / stb.). feladó. Ha van érdeklődés, támogatást nyújthatunk egy nagyon egyszerű aszimmetrikus sémához is, amelynek során a címzett kezdeményez egy üzenet iránti kérelmet, és elküldi ezt a kérési linket az üzenet feladójának. Ez a beállítás kiküszöböli annak szükségességét, hogy a jelszó legyen az URL-ben, ugyanakkor a feladó nem tudja kezdeményezni.

A visszafejtési jelszó lehet az URL-ben?

Igen. Ez nyilvánvalóan befolyásolja a biztonságot, mert ha a link elküldésére használt módszer nem biztonságos, az üzenet társítással nem biztonságos. A probléma kiküszöbölésére szolgáló összes megoldás további lépéseket és összetettségeket vezet be, amelyek befolyásolják a felhasználói élményt (azaz a dolgokat mindkét oldalon be kell állítani az üzenet elküldése előtt). Egy aszimmetrikus séma, amelynek során a címzett kezdeményez egy üzenet iránti kérelmet és elküldi azt a kérési linket, működhet a "minden mulandó" kulcsfontosságú követelményünkkel - ez megvalósítható. Végül, ha két fél gyakran üzen egymásnak, jobb megoldások léteznek, feltéve, hogy mindkét fél képes kezelni ezeket a megoldásokat.

De a visszafejtési jelszónak nem kell szerepelnie az URL -ben?

Helyes. Ha a visszafejtési jelszó nem szerepel a hivatkozásban, akkor a címzett kéri a jelszót. Ha a jelszót biztonságosan közlik a címzettel (vagy már tudják), ez védelmet nyújt az elfogás ellen. A hátrány azonban az, hogy a címzettnek tudnia kell és helyesen kell megadnia a jelszót. Íme egy módja annak, hogy elküldje a jelszót a címzettnek, amely némi védelmet nyújt a lehallgatás ellen:

  1. Titkosítsa a jelszót egy üzenetben az alapértelmezett beállításokkal, és küldje el ezt a linket a címzettnek.
  2. Amikor a címzett rákattint a linkre és visszafejti az üzenetet, tudja, hogy senki más nem kapta meg a jelszót előttük, mert a jelszót tartalmazó üzenet törlődik a visszakereséskor. Ha azonban aktív MITM támadás történik, vagy ha az Ön eszköze vagy a címzett eszköze veszélybe került, akkor is lehetséges, hogy egy másik fél megszerezheti a jelszót.
  3. Erősítse meg a címzettel, hogy sikeresen megszerezte a jelszót. Például, ha a címzett arról tájékoztatja Önt, hogy amikor elment a jelszó lekérésére, és hogy az üzenetet már törölték, akkor tudja, hogy valaki más szerezte meg a jelszót a címzett előtt, és ezért a jelszó sérült, és nem szabad használni.
  4. A címzett által megerősített jelszó használatával most küldhet üzenetet ugyanazzal a jelszóval a titkosításhoz - csak ossza meg a link azon verzióját, amely nem tartalmazza a jelszót.

Ez helyes - mi generáljuk a linket, és a feladóra bízzuk, hogyan lehet a legjobban eljuttatni a címzetthez. Ennek a szolgáltatásnak az a célja, hogy olyan opciót nyújtson, amely kevesebb állandóságot kínál a meglévő üzenetszállításokban, például e-mail / chat / text / stb. Ezért elvárás, hogy az általunk generált link, amely az ideiglenes üzenetre mutat, egy meglévő üzenetszállításon keresztül kerüljön elküldésre. Ennek vannak biztonsági vonatkozásai, amelyeket a felhasználóknak meg kell érteniük. Vegyünk példaként egy SMS-t, mivel ez egy elég bizonytalan kommunikációs módszer. Ha ezt a szolgáltatást ideiglenes üzenet-link küldésére használja szöveges üzenetben, akkor az alapértelmezett módot használja, amelynél a jelszó szerepel a linkben, bárki, aki rendelkezik linkkel, elolvashatja az üzenetet, és nem nyújt védelmet lehallgatás ellen. Ez a szolgáltatás továbbra is ideiglenesebb kommunikációt biztosít, amely javíthatja az adatvédelmet és biztonságot. Ezenkívül dönthet úgy, hogy jelszó nélkül küldi a linket, és ez védelmet nyújt az elfogás ellen.

Hogyan védhetem meg a magánéletemet a lehető legnagyobb mértékben a szolgáltatás használata közben?

Ahogy a jelen GYIK-ben máshol is tárgyaltuk, annak ellenére, hogy már most sokat teszünk az Ön személyes adatainak védelme érdekében, és bár nem gyűjtünk személyes adatokat, a naplóval kapcsolatos információkat mi és mások küldünk be és gyűjtünk Ön által, egy webböngésző segítségével. Azonban még többféle módon védheti magánéletét. A szabadon használható, nyílt forráskódú szoftvereken alapuló és nagyon jól használható módszer a Tor böngésző használata . Ezt a böngészőt úgy alakítottuk ki, hogy több szinten megvédje magánéletét - beleértve a Tor hálózat használatát is . Webhelyünk már elérhető a Tor hagymahálózaton keresztül, ami azt jelenti, hogy a Toron keresztül történő eléréshez nem szükséges kilépési csomópont használata, ami tagadja, hogy valaki lehallgassa a kilépési csomópont forgalmát . Ne feledje azonban, hogy még ebben a forgatókönyvben is az internetszolgáltatója láthatja, hogy Tor-t használ - bár nem mire. Akár csatlakozhat egy VPN-hez, majd elindíthatja a Tor böngészőt a névtelenség két rétegéhez; ne feledje azonban, hogy az internetszolgáltatója továbbra is láthatja, hogy VPN-t használ ebben a forgatókönyvben - bár nem mire. Ha nem szeretné, hogy internetszolgáltatója tudja, milyen protokollokat használ, csatlakozhat egy nagy nyilvános WiFi hálózathoz, például könyvtárhoz, iskolához stb., Majd használhatja a Tor böngészőt.

Mi van, ha nem bízom az Egyesült Államokban?

Szervereink az Egyesült Államokban találhatók. Ezen felül CDN szolgáltatónk, a Cloudflare, az Egyesült Államokban székhellyel rendelkező vállalat. Megpróbáltuk elhárítani annak szükségességét, hogy bízzunk bennünk vagy abban az országban, ahol szervereink laknak, pusztán azért, mert nem gyűjtünk személyes adatokat, nem tudunk visszafejteni egyetlen üzenetet sem, és mindent röviddel azután megkapunk, hogy megkapjuk. Megérthetünk azonban bizonyos bizalmatlanságokat, mivel webalapúak, és különösen, ha bizonyos országokban élsz. Tervezünk Izlandon és Svájcban olyan lehetőségeket kínálni, akik nehezen bíznak az USA-ban. Kérjük, ossza meg velünk, ha ez vonatkozik Önre, mivel nem leszünk motiváltak alternatívákat kínálni, hacsak nincs igazi igény.

Mit tesz a spam megakadályozása érdekében?

Bármikor megengedi valakinek, hogy küldjön egy linken keresztül továbbítható üzenetet, meghívja a spammereket. Ennek a problémának a megfékezése nem teljesen egyértelmű. Néhány okból nem akarunk egy harmadik féltől származó CAPTCHA-t betölteni az üzenetküldési folyamat részeként:

Valamilyen API kulcsrendszer használatával megkerülhetnénk az API problémáját, de akkor gyűjtenünk kell a felhasználói információkat, amelyeket nem akarunk megtenni. Mi akadályozza meg a spammereket abban, hogy rengeteg API kulcsot kapjanak? Nem tudjuk megvizsgálni az üzeneteket, hogy kikövetkeztessük a spamelésüket (ami a legjobb esetben is nagyon problematikus), mivel az üzenetek titkosításán kívül gyakorlati irányelvünk van az üzenetek tartalmára. Ezen követelmények figyelembevételével két módszert alkalmazunk a spam megakadályozására: Ha tudja, hogy a spamküldők visszaélnek ezzel a szolgáltatással, kérjük, tegyen bejelentést a visszaélésekről .

Miért van lehetőség a CAPTCHA kitöltésére a címzetttől?

Bár igaz, hogy nem szeretjük a CAPTCHA-kat, elismerjük, hogy azok célt szolgálnak, és idejük és helyük van (legalábbis egyelőre). Ez egyszerű módja annak, hogy a feladó bizonyos fokú bizonyosságot szerezzen arról, hogy a címzett ember, és hogy az automatizált folyamatok nem férnek hozzá az üzenethez.

Ki üzemelteti ezt a szolgáltatást, és miért ingyenes?

Csak néhány srác vagyunk, akik néha szembesültek azzal a nehézséggel, hogy nincsenek jó lehetőségek a magánéletünk védelmében. Gyakran ez abból adódott, hogy kommunikáltunk olyan barátaikkal és családtagjaikkal, akik nem voltak túl óvatosak az eszközök és információk kezelésében. Máskor ez webalapú fórumok, például a Reddit vagy webalapú támogatási rendszerek használatakor következett be. Találtunk néhány webalapú ideiglenes üzenetmegoldást, de egyik sem kínált E2EE-t, ami azt jelentette, hogy nem bízhatunk bennük. Tehát csak megépítettük a saját megoldásunkat, és úgy döntöttünk, hogy odaadjuk, hogy mások is profitálhassanak belőle.

Hogyan bízhatok meg a fenti kérdésekre adott válaszokban?

Tényleg nem szabad megbízni egyetlen weboldalban sem, csak azért, mert bizonyos dolgokat mond - ez általában jó ötlet az állítások igazolására. A végpontok közötti titkosítás alkalmazásával a lehető legnagyobb mértékben megpróbáltuk eltávolítani a bennünk való bizalom követelményét. Például elég könnyen ellenőrizhető, hogy egyetlen üzenetet sem tudunk elolvasni, mivel azok titkosítva vannak . A webhelyet futtató javascript kódot is nagyon egyszerűvé tettük, hogy könnyen olvasható és érthető legyen. Az összes kód nyílt forráskódúvá tétele lehetővé teszi az emberek számára, hogy ellenőrizzék, mi fut; azonban ne feledje, hogy nincs mód arra, hogy valóban ellenőrizze, mi a szerver fut. Bár igaz, hogy a megbízhatósági követelmények nagy része végpontok közötti titkosítással megszűnik, a felhasználóink mégis súlyosan mérlegelik, amikor úgy döntenek, hogy igénybe veszik ezt a szolgáltatást.