Často kladené otázky

Proč je tento web špatně přeložen? ⎃

Litujeme, ale současní autoři mluví pouze anglicky. Potřebujeme pomoc s překladem tohoto projektu do jiných jazyků. Jako jednoduchý a levný způsob zpřístupnění této služby lidem, kteří nemluví anglicky, využíváme strojový překlad. Výsledky jsou obvykle přijatelné, ale mohou mít za následek podivné formulace nebo dokonce zcela nepřesné informace. Můžete nám pomoci zlepšit prostředí pro každého - odešlete správný překlad .

Jak bezpečná je tato služba?

Podnikli jsme mnoho kroků, abychom tuto službu zajistili pro zamýšlené použití . Než projdeme tyto kroky, je důležité pochopit následující:

Naším cílem je nabízet tuto službu způsobem, který nabízí možnosti, jak zlepšit vaše soukromí a bezpečnost. Zde jsou některé kroky, které jsme podnikli k ochraně vašich údajů:

Proč jsem sem dostal odkaz s možností dešifrovat zprávu?

Omlouváme se, pokud jsou v tomto překladu chyby . Tato služba jednoduše předá zašifrovanou zprávu z jednoho bodu do druhého a vy jste příjemcem. Zpráva bude brzy smazána. Provozovatelé této služby nemají žádný způsob, jak číst obsah zprávy. Obvykle někdo tuto službu používá, když nechce, aby obsah zprávy zůstal uvnitř různých databází / zařízení / služeb / souborů / atd. jak je typické při odesílání e-mailu / okamžité zprávy / textu / atd. Pokud se rozhodnete dešifrovat, mějte na paměti následující:

Smažete vše odeslané na tento web?

Věrni našemu logu koše ... vše bude smazáno krátce po obdržení. Odstranění všeho je automatizované - zapisuje se to na server. Přemýšlejte o tom takto - předkládají se dvě třídy informací:

V případě zpráv můžete určit, kdy je odstraníme, zadáním: Ve výchozím nastavení je vše o zprávě odstraněno poté, co je načteno jednou nebo je staré 1 týden - podle toho, co nastane dříve. Pokud jde o smazání všech ostatních informací souvisejících s odesíláním čehokoli na web (tj. Vaše IP adresa atd.), Nedáme vám žádnou kontrolu nad tím, kdy a jak je smazáno - všechny smažeme každých 24 hodin .

Proč používat tuto službu?

Tato služba je nástroj, který pomáhá snižovat trvalost odesílaných a přijímaných zpráv. Většina toho, co komunikujete na internetu (chaty, texty, e-maily atd.), Je uložena a zřídka smazána. Často, když něco smažete, ve skutečnosti to není smazáno, ale spíše označeno jako smazané a již se vám nezobrazuje. Vaše souhrnná komunikace se rok co rok hromadí v databázích a na zařízeních, nad kterými nemáte žádnou kontrolu. Nevyhnutelně je jedna nebo více organizací / osob / zařízení, které ukládají vaši komunikaci, napadeno a vaše informace jsou unikly. Tento problém je tak všudypřítomný, že nyní existuje mnoho webových stránek, které sledují organizace, které byly kompromitovány a unikly z nich uživatelská data. End-to-end šifrované dočasné zprávy jsou jednoduchým řešením, díky kterému je část vaší komunikace méně trvalá. Každá zpráva odeslaná na tento web má dobu životnosti v rozmezí od 1 minuty do 2 týdnů - po uplynutí této doby je zpráva odstraněna. Výchozí nastavení je dále odstranit jakoukoli zprávu, jakmile ji příjemce načte. Kromě toho jsou všechny zprávy šifrovány z vašeho zařízení až do zařízení příjemce. Hlavním cílem při používání šifrování typu end-to-end je odstranit naši schopnost číst všechny odeslané zprávy, čímž odstraníme část požadavku na důvěryhodnost. Konečným výsledkem je, že je nyní snadné odeslat šifrovanou zprávu pomocí jednoduchého odkazu. Tato zpráva je odstraněna buď krátce po odeslání, nebo po načtení. Nemusíte instalovat / konfigurovat speciální software. Nemusíte si vytvářet účet ani poskytovat žádné osobní údaje. Příjemce nemusí být ve vašich kontaktech nebo o této službě ani vědět - jediný požadavek, aby mohl kliknout na odkaz.

Je to služba zasílání zpráv?

Ne. Tato služba je navržena k doplnění stávajících služeb zasílání zpráv, jako jsou zasílání rychlých zpráv / e-mail / text / atd. přidáním možnosti zabránit dlouhodobému ukládání odeslaných zpráv. Generovaný odkaz nedoručíme příjemci .

Jaké jsou zamýšlené případy použití?

Jaké jsou tedy scénáře, kdy je vhodné tuto službu využívat? Zatímco každý má jiné potřeby a požadavky, pokud jde o jeho soukromí a zabezpečení, osobně jsem jako vhodné případy použití našel následující scénáře:

K čemu by tato služba neměla být využívána?

Tato služba by neměla být používána pro velmi citlivé informace ze všech důvodů vysvětlených v tomto FAQ. Níže uvádíme několik příkladů, co nedělat:

Proč nepoužívat pouze PGP / Signal / OMEMO / Matrix / atd.?

Pokud znáte osobu, které chcete posílat zabezpečené dočasné zprávy, posílejte je často, očekávejte rozhraní podobné chatu nebo můžete očekávat, že příjemce bude mít požadovaný software a bude vědět, jak jej používat, pravděpodobně tento web není nejlepší řešení. Existují skvělé možnosti, které jsou otevřený zdroj, podporují E2EE, ne webové, a dokonce i některé jako Signal, které také podporují dočasné zprávy. Osobně používám soukromý server XMMP a OMEMO k chatování s blízkými přáteli a rodinou. Používání tohoto webu může být optimální pouze v případě, že nevíte, jaký software příjemce používá, neznáte jeho telefonní číslo / kontaktní osobu, neznáte jeho technické znalosti (ale předpokládejte, že může kliknout na odkaz), nebo si raději ponecháte zprávu, kterou posíláte, mimo základní komunikační přenos.

Jaké požadavky existují?

Je vyžadován moderní a aktuální webový prohlížeč, který správně implementuje standardy včetně Web Crypto API. Mezi příklady patří: Chrome, Firefox, Edge a Safari (kolem roku 2020 nebo později).

Může příjemce vytvořit kopii zprávy?

Ano. Přestože se zpráva může po načtení sama smazat, může si ji příjemce zobrazit. Kdykoli může příjemce úplně zobrazit zprávu, lze vytvořit kopii - to platí pro veškerou komunikaci. Existuje možnost, jak příjemci ztížit vytvoření kopie. V tomto případě jsou implementovány tři překážky kopírování:

Tyto ochrany proti kopírování jsou však slabé, protože je lze obejít. Příjemce si také může vždy pořídit snímek obrazovky nebo fotografii zprávy.

Shromažďují se nějaké osobní údaje?

Nepodporujeme uživatelské účty (tj. Uživatelské jméno / heslo). Neshromažďujeme žádné informace, které by vás mohly identifikovat (tj. Jméno / adresa / e-mail / telefon). Je možné, že ve zprávě, kterou odesíláte, mohou být některé osobní údaje, ale jsou šifrované a my je nemáme možnost přečíst. Úplné podrobnosti najdete v našich zásadách ochrany osobních údajů.

Jaké informace se zaznamenávají?

Náš webový server uchovává až 24 hodin běžného formátu protokolu o všech webových aktivitách. To zahrnuje protokolování úplné adresy IP klientů HTTP. Po 24 hodinách se tyto zaznamenané informace automaticky smažou. Všechny požadavky odeslané do / api jsou POSTed, což znamená, že webový server nikdy nezaznamenává žádné konkrétní informace o zprávě. Kromě toho jsou všechny informace uložené v databázi účinně protokolovány. Všechny položky v databázi, včetně anonymizovaných a hašovaných adres IP, mají dobu vypršení platnosti (TTL), po které jsou automaticky odstraněny. Doby vypršení platnosti TTL se pohybují mezi 1 minutou a 2 týdny.

Co děláte pro zabezpečení serverů?

Zabezpečení serveru je zjevným problémem. Abychom ji udrželi v bezpečí, zaměřujeme se na dvě hlavní oblasti:

Jaká bezpečnostní rizika existují při používání tohoto webu?

Než se konkrétně zabývám některými z těchto rizik, domnívám se, že polostruktivní analogie může pomoci shrnout rizika při používání jakékoli internetové komunikace. Představte si, že jakýkoli systém je bezpečný pouze jako nejslabší článek v řetězci. Nyní si představte scénář, kdy jsou v zapečetěné místnosti dva lidé bez možnosti vidět, slyšet nebo zaznamenat vše, co dělají. Jeden předá zprávu druhému, kterého po přečtení vypálí. Pokud si někdo mimo tuto místnost přeje získat zprávu, která již byla předána, bude to těžké. Jaký je nejslabší odkaz k získání zprávy? Není tolik odkazů na výběr - je to docela krátký řetězec. Nyní si představte, že když pošlete zprávu na internet, že v řetězci je nejméně milion odkazů - mnoho z nich slabých - mnoho z nich zcela mimo vaši kontrolu - a to je realita.

Použití šifrování může výrazně pomoci s výše uvedeným problémem s miliony odkazů a jeho snadné nalákání k myšlence, že dobře navržené systémy E2EE nabízejí řešení pro všechny. Toto myšlení vás však může dostat do potíží, protože útočník obvykle jde jen za slabšími odkazy v systému. Například je pravděpodobně mnohem snazší převzít kontrolu nad telefonem nebo počítačem a nastavit záznamník vstupů, který bude číst vše, co napíšete, než rozbíjení šifrovaných zpráv po kabelu. Závěrem je, že kdybych měl za úkol sdělit tajemství zásadního / kritického významu, používal bych elektronickou komunikaci pouze jako poslední možnost.

Existují tedy bezpečnostní rizika při jakékoli komunikaci, ale stále používáte webový prohlížeč pro bankovnictví, nákup věcí, e-mailů atd. Je to přijatelné riziko pro získané obrovské vymoženosti. Skutečná otázka zní ... jaká bezpečnostní rizika jsou pro tento web částečně specifická? Několik přijde na mysl:

Co děláte s útoky typu man-in-the-middle (MITM)?

Všichni uživatelé webových stránek se mohou potenciálně stát obětí útoku MITM - tato stránka se v tomto ohledu neliší od všech ostatních na webu. Útok MITM je, když je útočník schopen zachytit a upravit komunikaci mezi prohlížečem uživatele a webovým serverem webu. To umožňuje útočníkovi upravit libovolný kód / obsah webu, zatímco koncovému uživateli se stále zdá být webem, na který je zvyklý. Přijmeme některá opatření, abychom útok MITM ztížili:

Útok MITM je však stále vždy možný - zvláště pokud útočník ovládá infrastrukturu sítě / veřejného klíče, jak by tomu bylo v případě velkých / výkonných organizací nebo vlád. Nabízíme rozšíření prohlížeče, která mohou pomoci zmírnit některá rizika MITM.

Jaké výhody nabízejí rozšíření prohlížeče?

Nabízíme rozšíření prohlížeče jako prostředek k zajištění většího pohodlí a dalšího zabezpečení. Jednoduše řečeno ... Díky rozšíření je odesílání dočasných zpráv rychlejší a jednodušší. Určité zabezpečení je také získáno, protože veškerý kód používaný k šifrování a přípravě zprávy je uložen lokálně v rámci rozšíření. Protože je kód uložen lokálně, nabízí to odesílateli určitou ochranu před útoky MITM . Je však třeba zdůraznit, že zatímco rozšíření nabízejí větší ochranu před útokem MITM, který ohrožuje obsah zprávy, útok MITM může být stále účinný (tj. Určit IP adresu odesílatele, pokud nepoužívá TOR / VPN / atd.).

Jak mohu s jistotou vědět, že je vše odeslané šifrováno end-to-end?

Na rozdíl od mnoha jiných populárních klientských chatů typu end-to-end šifrovaných (E2EE) je poměrně snadné přesně zjistit, co se nám při odeslání zprávy pošle. Níže uvedený videonávod ukazuje, jak potvrdit, že nemáme způsob, jak dešifrovat zprávy odeslané na server.

Také, pokud se nad tím zamyslíte, pokud nejsme tajnou agenturou, která se snaží sbírat citlivé zprávy, není pro nás výhodou, že budeme moci dešifrovat zprávy, protože mít tuto schopnost nám jen vytváří problémy. Nechceme ani ukládat zprávy - je to však nutné zlo, abychom je doručili.

Jak na tomto webu funguje šifrování typu end-to-end?

V tuto chvíli používáme symetrické šifrování (AES-GCM 256bit) s klíči odvozenými z hesel (minimálně 150 000 iterací PBKDF2 / SHA-256). Asymetrické šifrování se nepoužívá, protože existují požadavky na 1) odesílatele, který iniciuje komunikaci 2) odesílatele a příjemce není současně online a 3) žádné informace o příjemci a 4) snažíme se, aby věci byly skutečně jednoduché a správa klíčů je složitý. Standardní Web Crypto API se používá pro všechny kryptografické funkce včetně RNG. V zásadě se děje toto:

  1. Koncový uživatel zvolí heslo nebo se heslo vygeneruje automaticky
  2. Je provedeno volání API k získání počtu požadovaných iterací PBKDF2 / SHA-256 ( tento krok je vyžadován pro kontrolu spamu )
  3. Vygeneruje se 32 bajtová sůl
  4. Klíč je odvozen od soli a hesla
  5. Je vygenerován 12bajtový inicializační vektor (IV)
  6. Zpráva je šifrována pomocí klíče + IV
  7. Počet iterací, sůl, IV a ciphertext se odesílají na server (spolu s dalšími informacemi, jako jsou TTL, RTL atd.)
  8. Server vrací náhodné ID odkazující na zprávu
  9. Prohlížeč poté předá koncovému uživateli odkaz, který obsahuje vrácené ID a heslo nebo odkaz bez hesla (v takovém případě musí příjemce znát a zadat heslo)
  10. Pokud je heslo součástí odkazu, je v hash adresy URL , a proto se nikdy neposílá na server, když příjemce zadá požadavek GET
  11. Příjemce se zobrazí výzva, pokud chce zprávu dešifrovat a zobrazit
  12. Prohlížeč zadá požadavek s uvedením ID zprávy
  13. Pokud odesílatel vyžaduje vyplnění CAPTCHA, je příjemce přesměrován na jinou adresu URL, aby prokázal, že je člověk (jakmile projde, bude přesměrován zpět)
  14. Server odešle zašifrovanou zprávu a ve výchozím nastavení tuto zprávu odstraní, pokud je read-to-live (RTL) jedna
  15. Příjemce dešifruje zprávu pomocí hesla (a pokud není v adrese URL, bude vyzván k zadání hesla)
Toto nastavení je extrémně jednoduché a nabízí šifrování zpráv ze zařízení odesílatele do zařízení příjemce, ale samozřejmě postrádá záruku, kterou asymetrické šifrování může nabídnout, pokud bude vědět, že zprávu může dešifrovat pouze někdo, kdo vlastní soukromý klíč příjemce. Kdokoli s odkazem může otevřít zprávu ve výchozím scénáři, kdy je heslo součástí adresy URL - to podtrhuje důležitost použití vhodného přenosu pro odkaz (tj. E-mail / chat / text / atd.) - rozhodnutí ponecháno na odesílatel. Můžeme v případě zájmu také zavést podporu pro velmi základní asymetrické schéma, kdy příjemce iniciuje požadavek na zprávu a odešle odkaz na požadavek odesílateli zprávy. Toto nastavení by eliminovalo potřebu mít heslo v adrese URL, ale také vylučuje možnost odesílatele iniciovat.

Dešifrovací heslo může být v URL?

Ano. To samozřejmě ovlivňuje zabezpečení, protože pokud je metoda použitá k odeslání odkazu nezabezpečená, zpráva je nezabezpečená přidružením. Všechna řešení k odstranění tohoto problému zavádějí další kroky a složitosti, které mají vliv na uživatelskou zkušenost (tj. Před odesláním zprávy je třeba na obou koncích nastavit věci). Asymetrické schéma, kterým příjemce iniciuje požadavek na zprávu a odešle odkaz na požadavek, může fungovat s naším klíčovým požadavkem „vše je pomíjivé“ - toto může být implementováno. Nakonec, pokud si dvě strany budou navzájem posílat zprávy často, existují lepší řešení za předpokladu, že obě strany zvládnou používat tato řešení.

Ale dešifrovací heslo nemusí být v URL?

Opravit. Není -li v odkazu zahrnuto dešifrovací heslo, bude příjemce vyzván k zadání hesla. Pokud je heslo bezpečně sděleno příjemci (nebo ho již zná), poskytuje to ochranu proti zachycení. Nevýhodou však je, že příjemce musí znát a správně zadat heslo. Zde je jeden ze způsobů, jak odeslat heslo příjemci, který nabízí určitou ochranu proti zachycení:

  1. Zašifrujte heslo do zprávy s výchozím nastavením a odešlete tento odkaz příjemci.
  2. Když příjemce klikne na odkaz a dešifruje zprávu, ví, že nikdo jiný před ním nezískal heslo, protože zpráva obsahující heslo je po načtení odstraněna. Pokud však došlo k aktivnímu útoku MITM nebo došlo k ohrožení vašeho zařízení nebo zařízení příjemce, je stále možné, aby heslo získala jiná strana.
  3. Potvrďte s příjemcem, že úspěšně získal heslo. Pokud vás příjemce například informuje, že když šel získat heslo, že zpráva již byla odstraněna, pak víte, že někdo jiný získal heslo před příjemcem a že heslo je proto prolomeno a nemělo by se používat.
  4. Pomocí hesla, které příjemce potvrdil, že vlastní, můžete nyní odeslat zprávu pomocí stejného hesla pro šifrování - stačí sdílet verzi odkazu, který heslo neobsahuje.

To je pravda - vygenerujeme odkaz a necháme na odesílateli, jak nejlépe jej doručit příjemci. Cílem této služby je poskytnout možnost nabízející menší stálost ve stávajících přenosech zpráv, jako je e-mail / chat / text / atd. Očekává se tedy, že odkaz, který generujeme a který odkazuje na dočasnou zprávu, je odeslán prostřednictvím existujícího přenosu zprávy. To má bezpečnostní důsledky, kterým by uživatelé měli rozumět. Vezměme si jako příklad textovou zprávu SMS, protože se jedná o docela nejistou metodu komunikace. Když použijete tuto službu k odeslání dočasného odkazu na zprávu prostřednictvím textové zprávy, použijete-li výchozí režim, kdy je do odkazu zahrnuto heslo, zprávu může číst kdokoli, kdo má odkaz, a není zajištěna ochrana proti odposlechu. Tato služba stále poskytuje dočasnější komunikaci, která může zlepšit soukromí a zabezpečení. Dále se můžete rozhodnout odeslat odkaz bez hesla, což zajistí ochranu proti zachycení.

Jak mohu při používání této služby chránit co nejvíce své soukromí?

Jak je diskutováno jinde v tomto FAQ, i když již děláme hodně pro ochranu vašeho soukromí a přestože neshromažďujeme žádné osobní údaje, některé informace související s protokoly odesíláme a shromažďujeme my a ostatní na základě toho, že používáte webový prohlížeč. Existuje však několik způsobů, jak ještě více chránit vaše soukromí. Jedním ze způsobů, které jsou zdarma k použití na základě softwaru s otevřeným zdrojovým kódem a fungují docela dobře, je použití prohlížeče Tor . Tento prohlížeč je navržen tak, aby chránil vaše soukromí na několika úrovních - včetně používání sítě Tor . Náš web je již přístupný přes síť Tor cib, což znamená, že přístup na náš web přes Tor nevyžaduje použití výstupního uzlu, což vylučuje, aby někdo odposlouchával provoz výstupního uzlu . Mějte však na paměti, že i v tomto scénáři může váš ISP vidět, že používáte Tor - i když ne k čemu. Můžete se dokonce připojit k VPN a poté spustit prohlížeč Tor pro dvě vrstvy anonymity; Mějte však na paměti, že váš ISP stále vidí, že v tomto scénáři používáte VPN - i když ne k čemu. Pokud nechcete, aby váš ISP věděl, jaké protokoly používáte, můžete se připojit k velké veřejné síti WiFi, jako je knihovna, škola atd., A poté použít prohlížeč Tor.

Co když nedůvěřuji Spojeným státům?

Naše servery jsou umístěny ve Spojených státech. Náš poskytovatel CDN, Cloudflare, je navíc společnost se sídlem ve Spojených státech. Pokusili jsme se odstranit potřebu důvěřovat nám nebo zemi, ve které naše servery sídlí, jednoduše proto, že neshromažďujeme osobní údaje, nemůžeme dešifrovat žádné zprávy a vše je smazáno krátce po jejich přijetí. Chápeme však určitou nedůvěru, protože je webová, zejména pokud žijete v určitých zemích. Máme několik plánů, jak nabídnout možnosti na Islandu a ve Švýcarsku pro lidi, kteří těžko důvěřují USA. Pokud se vás to týká, dejte nám prosím vědět , protože pokud nebude skutečná poptávka, nebudeme motivováni nabízet alternativy.

Co děláte, abyste zabránili spamu?

Kdykoli někomu povolíte zveřejnit zprávu, kterou lze předat prostřednictvím odkazu, pozvete spammery. Omezení tohoto problému není zcela jednoduché. Nechceme načíst CAPTCHA třetí strany jako součást procesu odesílání zprávy z několika důvodů:

Možná bychom mohli obejít problém s API pomocí nějakého klíčového systému API, ale pak musíme shromáždit informace o uživateli, které nechceme dělat. Co také má zabránit spammerům v získávání spousty klíčů API? Nemůžeme zkoumat zprávy, abychom odvodili jejich nevyžádanou poštu (což je přinejlepším velmi problematické), protože kromě šifrování zpráv máme zásadu předání obsahu zprávy. Vzhledem k těmto požadavkům používáme dvě metody prevence spamu: Pokud víte, že spammeři tuto službu zneužívají, podejte prosím zprávu o zneužití .

Proč existuje možnost požadovat, aby příjemce vyplnil CAPTCHA?

I když je pravda, že se nám nelíbí CAPTCHA, uvědomujeme si, že slouží účelu a mají čas a místo (alespoň prozatím). Toto je jednoduchý způsob, jak odesílatel získat jistotu, že příjemce je člověk a že automatizované procesy ke zprávě nepřistupují.

Kdo tuto službu provozuje a proč je zdarma?

Jsme jen pár lidí, kteří někdy čelili nesnázi, že nemají dobré možnosti, jak chránit naše soukromí. Často to bylo výsledkem komunikace s přáteli a členy rodiny, kteří nebyli příliš opatrní v tom, jak zacházejí se svými zařízeními a informacemi. Jindy k tomu došlo při používání webových fór, jako je Reddit, nebo při používání webových podpůrných systémů. Našli jsme nějaká webová řešení pro dočasné zprávy, ale žádná nenabídla E2EE, což znamenalo, že jsme jim nemohli věřit. Právě jsme tedy vytvořili vlastní řešení a rozhodli jsme se jej rozdat, aby z něj mohli těžit ostatní.

Jak mohu důvěřovat odpovědím na výše uvedené otázky?

Opravdu byste neměli důvěřovat žádné webové stránce jen proto, že říká určité věci - je obvykle dobrý nápad ověřit jakékoli tvrzení. Pokusili jsme se odstranit požadavek co nejvíce nám důvěřovat pomocí šifrování typu end-to-end. Například je docela snadné auditovat, že nemůžeme číst žádné zprávy, protože jsou šifrované . Rovněž jsme udrželi velmi snadný běh tohoto kódu JavaScriptu , aby byl snadno čitelný a srozumitelný. Vytvoření celého kódu jako open source umožňuje lidem ověřit, co běží; mějte však na paměti, že neexistuje způsob, jak skutečně ověřit, na čem server běží. I když je pravda, že velká část požadavku na důvěryhodnost je odstraněna pomocí šifrování typu end-to-end, stále jde o faktor, který naši uživatelé při rozhodování o použití této služby velmi váží.