Pogosto zastavljena vprašanja

Zakaj je to spletno mesto slabo prevedeno? ⎃

Oprostite, vendar sedanji avtorji govorijo samo angleško. Potrebujemo pomoč pri prevajanju tega projekta v druge jezike. Kot preprosto in poceni sredstvo, ki omogoča, da je ta storitev na voljo ljudem, ki ne govorijo angleško, uporabljamo strojno prevajanje. Rezultati so običajno sprejemljivi, lahko pa povzročijo čudno besedilo ali celo popolnoma netočne podatke. Lahko nam pomagate izboljšati izkušnjo za vse - prosimo, predložite pravilen prevod .

Kako varna je ta storitev?

Sprejeli smo veliko korakov, da bi bila ta storitev varna za predvideno uporabo . Preden nadaljujemo s temi koraki, je pomembno razumeti naslednje:

Naš cilj je ponuditi to storitev na način, ki ponuja možnosti za izboljšanje vaše zasebnosti in varnosti. Tukaj je nekaj korakov, ki smo jih sprejeli za varno varovanje vaših podatkov:

Zakaj sem tukaj dobil povezavo z možnostjo dešifriranja sporočila?

Opravičujemo se, če je pri prevodu prišlo do napak. Ta storitev preprosto posreduje šifrirano sporočilo od ene točke do druge in vi ste prejemnik. Sporočilo bo kmalu izbrisano. Upravljavci te storitve ne morejo prebrati vsebine sporočila. Običajno nekdo uporablja to storitev, če ne želi, da vsebina sporočila ostane v različnih bazah podatkov/napravah/storitvah/datotekah/itd. kot je običajno pri pošiljanju e-pošte/takojšnjega sporočila/besedila/itd. Če se odločite za dešifriranje, upoštevajte naslednje:

Ali ste izbrisali vse, poslano na to spletno mesto?

V skladu z logotipom koša za smeti ... vse se izbriše kmalu po prejemu. Izbris vsega je avtomatiziran - zapisan je v strežnik. Pomislite na ta način - predloženi sta dve vrsti informacij:

V primeru sporočil lahko določite, kdaj jih izbrišemo, tako da določite: Privzeto se vse, kar je povezano s sporočilom, izbriše, ko je enkrat naloženo ali je staro 1 teden - kar se zgodi prej. Ko gre za brisanje vseh drugih podatkov, povezanih s pošiljanjem kar koli v spletu (npr. Vašega naslova IP itd.), Vam ne dajemo nobenega nadzora nad tem, kdaj in kako se izbrišejo - vse jih izbrišemo vsakih 24 ur. .

Zakaj uporabljati to storitev?

Ta storitev je orodje, ki pomaga zmanjšati trajnost sporočil, ki jih pošiljate/prejemate. Večina tega, kar komunicirate v internetu (klepeti, besedila, e -poštna sporočila itd.), Je shranjenih in redko izbrisanih. Pogosto, ko nekaj izbrišete, se dejansko ne izbriše, temveč označi kot izbrisano in se vam ne prikaže več. Vaše zbirne komunikacije se iz leta v leto kopičijo v zbirkah podatkov in na napravah, na katere nimate nadzora. Neizogibno je ena ali več organizacij/ljudi/naprav, ki hranijo vašo komunikacijo, vdrto in vaši podatki uhajajo. Ta problem je tako razširjen, da zdaj obstaja veliko spletnih mest, ki sledijo organizacijam, ki so bile ogrožene in so puščale uporabniške podatke. Šifrirana začasna sporočila od konca do konca so preprosta rešitev, ki pomaga zmanjšati trajnost nekaterih komunikacij. Vsako sporočilo, poslano na to spletno mesto, ima čas za življenje od 1 minute do 2 tednov-po preteku tega časa se sporočilo izbriše. Poleg tega je privzeta nastavitev izbrisati katero koli sporočilo, ko ga prejemnik pridobi. Poleg tega so vsa sporočila šifrirana od vaše naprave do naprave prejemnika. Glavni cilj uporabe šifriranja od konca do konca je odstraniti našo sposobnost branja poslanih sporočil in s tem odstraniti nekatere zahteve po zaupanju. Končni rezultat je, da je zdaj preprosto poslati šifrirano sporočilo prek preproste povezave. To sporočilo se izbriše kmalu po pošiljanju ali po prenosu. Ni vam treba namestiti/konfigurirati posebne programske opreme. Ni vam treba ustvariti računa ali posredovati osebnih podatkov. Prejemniku ni treba biti v vaših stikih ali sploh vedeti za to storitev - edina zahteva, da lahko klikne povezavo.

Je to storitev sporočanja?

Ne. Ta storitev je zasnovana tako, da dopolnjuje obstoječe storitve sporočanja, kot so takojšnje sporočanje/e-pošta/besedilo/itd. z dodajanjem zmožnosti za dolgotrajno shranjevanje poslanih sporočil. Ustvarjene povezave ne dostavimo prejemniku .

Kakšni so predvideni primeri uporabe?

Kakšni so torej scenariji, v katerih je primerno uporabljati to storitev? Medtem ko ima vsak glede zasebnosti in varnosti različne potrebe in zahteve, sem osebno ugotovil, da so primerni primeri naslednji scenariji:

Za kaj te storitve ne bi smeli uporabljati?

Te storitve ne bi smeli uporabljati za zelo občutljive podatke iz vseh razlogov, razloženih v tem pogostih vprašanjih. Spodaj je nekaj primerov, česa ne storiti:

Zakaj preprosto ne uporabite PGP/Signal/OMEMO/Matrix/itd.?

Če poznate osebo, ki ji želite poslati varna začasna sporočila, jih pogosto pošiljajte, pričakujte vmesnik, podoben klepetu, in/ali lahko pričakujete, da bo prejemnik imel potrebno programsko opremo in ve, kako jo uporabljati, to spletno mesto verjetno ni najboljša rešitev. Obstajajo odlične možnosti, ki so odprtokodne, podpirajo E2EE, ne pa spletne in celo nekatere, kot je Signal, ki podpirajo tudi začasna sporočila. Osebno uporabljam zasebni strežnik XMMP in OMEMO za klepet z bližnjimi prijatelji in družino. Uporaba tega spletnega mesta je lahko optimalna le, če ne veste, katero programsko opremo uporablja prejemnik, ne poznate njegove telefonske številke/ročaja za stik, ne poznate njihove tehnične usposobljenosti (vendar predpostavite, da lahko kliknejo povezavo), ali pa raje obdržite sporočilo, ki ga pošljete, zunaj osnovnega komunikacijskega prometa.

Kakšne zahteve obstajajo?

Potreben je sodoben in posodobljen spletni brskalnik, ki ustrezno izvaja standarde, vključno z API-jem Web Crypto. Primeri vključujejo: Chrome, Firefox, Edge in Safari (okoli leta 2020 ali pozneje).

Ali lahko prejemnik kopira sporočilo?

Da. Čeprav se lahko sporočilo ob prenosu izbriše, si ga lahko prejemnik še vedno ogleda. Kadar koli si lahko prejemnik v celoti ogleda sporočilo, lahko naredite kopijo - to velja za vse komunikacije. Obstaja možnost, da prejemnik oteži izdelavo kopije. V tem primeru se izvajajo tri ovire pri kopiranju:

Vendar so te zaščite pred kopiranjem šibke, ker jih je mogoče zaobiti. Prejemnik lahko vedno posname tudi posnetek zaslona ali fotografijo sporočila.

Ali se zbirajo kakšni osebni podatki?

Ne podpiramo uporabniških računov (tj. Uporabniškega imena/gesla). Ne zbiramo podatkov, ki bi vas lahko identificirali (tj. Ime/naslov/e -poštni naslov/telefon). Možno je, da so v sporočilu, ki ga pošiljate, nekateri osebni podatki, vendar so ti šifrirani in jih ne moremo prebrati. Za podrobnosti preberite naš pravilnik o zasebnosti.

Kateri podatki se beležijo?

Naš spletni strežnik hrani do 24 ur skupne oblike dnevnika za vso spletno dejavnost. To vključuje beleženje celotnega naslova IP odjemalcev HTTP. Po 24 urah se ti zabeleženi podatki samodejno izbrišejo. Vse zahteve, poslane na /api, so OBJAVLJENE, kar pomeni, da spletni strežnik nikoli ne zabeleži nobenih podatkov, specifičnih za sporočila. Poleg tega se vsi podatki, shranjeni v bazi podatkov, učinkovito beležijo. Vsi vnosi v zbirki podatkov, vključno z anonimiziranimi in zgoščenimi naslovi IP, imajo čas poteka (TTL), po katerem se samodejno izbrišejo. Časi poteka TTL se gibljejo med 1 minuto in 2 tednoma.

Kaj počnete za zaščito strežnikov?

Varnost strežnika je očitna skrb. Za ohranitev varnosti se osredotočamo na dve glavni področji:

Kakšna varnostna tveganja so prisotna pri uporabi tega spletnega mesta?

Preden se konkretno lotimo nekaterih od teh tveganj, menim, da bi lahko na pol kratka analogija pomagala povzeti tveganja pri uporabi katere koli internetne komunikacije. Predstavljajte si, da je kateri koli sistem varen le kot je najšibkejši člen v verigi. Zdaj pa si zamislite scenarij, ko sta v zaprti sobi dve osebi, ki nimata možnosti videti, slišati ali posneti ničesar, kar počneta. Eden bo poslal sporočilo drugemu, ki ga bo ob branju zapisal. Če želi nekdo zunaj te sobe prejeti že poslano sporočilo, bo to težko. Katera je najšibkejša povezava do sporočila? Na izbiro ni toliko povezav - precej kratka veriga. Zdaj pa si predstavljajte, da ko pošljete sporočilo po internetu, da je v verigi vsaj milijon povezav - od katerih so mnoge šibke - mnoge od njih popolnoma zunaj vašega nadzora - in to je resničnost.

Uporaba šifriranja lahko v veliki meri pomaga pri zgoraj omenjeni težavi povezave z milijonom, zato ga je enostavno privabiti v razmišljanje, da dobro zasnovani sistemi E2EE ponujajo rešitev za vse. Vendar pa vam lahko to razmišljanje povzroči težave, saj bo napadalec običajno šel za šibkejšimi povezavami v sistemu. Na primer, verjetno je veliko lažje prevzeti telefon ali računalnik in nastaviti vnosni zapisovalnik, ki bo samo prebral vse, kar vnesete, kot pa razbijanje šifriranih sporočil po žici. Bistvo je, da če bi imel nalogo sporočiti skrivnost vitalnega/kritičnega pomena, bi elektronsko komunikacijo uporabil le kot zadnjo možnost.

Torej pri uporabi vseh komunikacij obstajajo varnostna tveganja, vendar še vedno uporabljate spletni brskalnik za bančništvo, nakup stvari, e -pošto itd. To je sprejeto tveganje za velike pridobljene ugodnosti. Resnično vprašanje je ... katera varnostna tveganja so za to spletno mesto delno specifična? Na misel mi pride nekaj:

Kaj počnete glede napadov človek v sredini (MITM)?

Vsi uporabniki spletnih mest so lahko potencialno žrtev napada MITM - to mesto se v tem pogledu ne razlikuje od vseh drugih na spletu. Napad MITM je, ko lahko napadalec prestreže in spremeni komunikacijo med brskalnikom uporabnika in spletnim strežnikom spletnega mesta. To omogoča napadalcu, da spremeni katero koli kodo/vsebino spletnega mesta, hkrati pa se končnemu uporabniku še vedno zdi, da je spletno mesto, na katerega so navajeni. Sprejemamo nekaj ukrepov za oteževanje napada MITM:

Vendar pa je napad MITM še vedno možen - še posebej, če napadalec nadzoruje omrežno/infrastrukturo javnega ključa, kot bi to veljalo za velike/močne organizacije ali vlade. Ponujamo razširitve brskalnika, ki lahko pomagajo ublažiti nekatera tveganja MITM.

Kakšne prednosti ponujajo razširitve brskalnika?

Razširitve brskalnika nudimo kot sredstvo za dodatno udobje in dodatno varnost. Preprosto povedano ... Razširitve omogočajo hitrejše in lažje pošiljanje začasnih sporočil. Nekaj varnosti je pridobljeno tudi zato, ker je vsa koda, ki se uporablja za šifriranje in pripravo sporočila, lokalno shranjena v razširitvi. Ker je koda shranjena lokalno, to pošiljatelju ponuja nekaj zaščite pred napadi MITM . Vendar je treba poudariti, da čeprav razširitve ponujajo večjo zaščito pred napadom MITM, ki ogroža vsebino sporočila, je lahko napad MITM še vedno učinkovit (tj. Za določitev naslova pošiljatelja IP, če ne uporablja TOR/VPN/itd.).

Kako lahko zagotovo vem, da je vse predloženo šifrirano od konca do konca?

V nasprotju s številnimi drugimi priljubljenimi odjemalci klepeta od konca do konca (E2EE) je precej preprosto videti, kaj nam pošljete, ko pošljete sporočilo. Spodnja video vadnica prikazuje, kako potrditi, da nimamo možnosti dešifriranja sporočil, poslanih na strežnik.

Tudi če pomislite, dokler nismo neka tajna agencija, ki poskuša zbirati občutljiva sporočila, nam ne bo koristilo dešifriranja sporočil, saj nam ta sposobnost samo povzroča težave. Sploh ne želimo shranjevati sporočil - vseeno je nujno zlo, da jih dostavimo.

Kako deluje šifriranje od konca do konca na tem spletnem mestu?

Trenutno uporabljamo simetrično šifriranje (AES-GCM 256bit) s ključi, pridobljenimi iz gesel (najmanj 200.000 ponovitev PBKDF2 + SHA-256). Asimetrično šifriranje se ne uporablja, ker obstajajo zahteve za 1) pošiljatelja, ki začne komunikacijo, 2) pošiljatelj in prejemnik nista hkrati na spletu in 3) ni podatkov o prejemniku in 4) poskušamo stvari ohraniti preproste in upravljanje s ključi je zapleteno. Standardni spletni kripto API se uporablja za vse kriptografske funkcije, vključno z RNG. V bistvu se zgodi naslednje:

  1. Končni uporabnik vnese besedilno sporočilo in lahko določi več možnosti, vključno z geslom.
  2. Za pridobitev ključa se ustvari varno geslo. Če je uporabnik določil geslo, ga združi z ustvarjenim geslom.
  3. Klic API-ja se izvede, da se pridobi število potrebnih ponovitev PBKDF2 + SHA-256 ( ta korak je potreben za nadzor neželene pošte )
  4. Nastane 32 -bajtna sol
  5. Ključ izhaja iz soli in gesla
  6. Ustvari se 12 -bajtni inicializacijski vektor (IV)
  7. Sporočilo je šifrirano s ključem in IV.
  8. Število ponovitev, sol, IV in šifrirani tekst se pošljejo na strežnik (skupaj z nekaterimi drugimi informacijami, kot so TTL, RTL itd.)
  9. Strežnik vrne naključni ID, ki se nanaša na sporočilo
  10. Brskalnik končnemu uporabniku nato predstavi povezavo, ki jo lahko nato da v skupno rabo s prejemnikom. Vsi podatki o sporočilu se hranijo v razpršeni komponenti URL -ja in se zato ne pošljejo strežniku med standardno zahtevo GET.
  11. Povezava je v skupni rabi s prejemnikom.
  12. Prejemnik bo pozvan, če želi dešifrirati in si ogledati sporočilo.
  13. Ko se prejemnik odloči za ogled sporočila, brskalnik poda zahtevo, v kateri navede ID sporočila.
  14. Če pošiljatelj zahteva dokončanje CAPTCHA, je prejemnik preusmerjen na drug URL, da dokaže, da je človek (ko ga posredujejo, se usmeri nazaj).
  15. Strežnik pošlje šifrirano sporočilo in bo privzeto izbrisal sporočilo, če je branje v živo (RTL).
  16. Prejemnik bo dešifriral sporočilo in po potrebi pozval geslo.
Ta nastavitev je izjemno preprosta in ponuja šifriranje sporočil od pošiljateljeve naprave do prejemnikove naprave, seveda pa nima nekaterih garancij, ki jih asimetrično šifriranje lahko ponudi. Vsakdo s povezavo lahko odpre sporočilo v privzetem scenariju - to poudarja pomen uporabe ustreznega prevoza za povezavo (tj. E -pošte/klepeta/besedila/itd.) - odločitev je prepuščena pošiljatelju.

Ključ za dešifriranje je lahko v URL -ju?

Da. Če geslo ni uporabljeno, lahko sporočilo prebere vsak s povezavo. To očitno vpliva na varnost, ker če je mogoče prestreči način, uporabljen za pošiljanje povezave, je mogoče prestreči sporočilo. Vse rešitve za odpravo te težave uvajajo dodatne korake in zapletenost, ki vplivajo na uporabniško izkušnjo (tj. Pred pošiljanjem sporočila je treba stvari nastaviti na obeh koncih). Konec koncev, če si bosta obe strani pogosto pošiljali sporočila, obstajajo boljše rešitve, ob predpostavki, da bosta obe strani z njimi lahko ravnali.

Toda ključ za dešifriranje ni nujno v URL -ju?

Pravilno. Avtor sporočila lahko določi geslo za zaščito sporočila. To geslo se uporablja za pridobivanje skrivnega ključa, ki ni del URL -ja . Če uporabljate varno geslo in ga prejemnik varno sporoči (ali ga že pozna), to zagotavlja zaščito pred prestrezanjem. Slabost pa je, da mora prejemnik vedeti in pravilno vnesti geslo. Tu je en način za pošiljanje gesla prejemniku, ki ponuja nekaj zaščite pred prestrezanjem:

  1. Geslo šifrirajte v sporočilu s privzetimi nastavitvami in pošljite to povezavo prejemniku.
  2. Ko prejemnik klikne povezavo in dešifrira sporočilo, ve, da nihče drug pred njim ni dobil gesla, ker se sporočilo, ki vsebuje geslo, po prenosu izbriše. Če pa je aktiven napad MITM ali če je bila vaša naprava ali naprava prejemnika ogrožena, je še vedno mogoče, da geslo pridobi druga stranka.
  3. Prejemnika potrdite, da je geslo uspešno pridobil. Na primer, če vas prejemnik obvesti, da je geslo, ko je šel iskat geslo, že izbrisano, veste, da je nekdo drug prejel geslo pred prejemnikom in da je geslo zato ogroženo in ga ne bi smeli uporabljati.
  4. Z geslom, ki ga je prejemnik potrdil, lahko zdaj pošljete sporočilo z istim geslom za šifriranje.

To je pravilno - povezavo ustvarimo in pošiljatelju prepustimo, kako jo najbolje dostaviti prejemniku. Cilj te storitve je zagotoviti možnost, ki ponuja manj trajnosti pri obstoječih prenosih sporočil, kot so e -pošta/klepet/besedilo/itd. Zato se pričakuje, da bo povezava, ki jo ustvarimo, ki kaže na začasno sporočilo, poslana prek obstoječega transporta sporočila. To ima varnostne posledice, ki bi jih morali uporabniki razumeti. Kot primer vzemimo besedilno sporočilo SMS, saj je to precej negotov način komunikacije. Ko uporabljate to storitev za pošiljanje začasnega sporočila s privzetimi nastavitvami, lahko kdor koli s povezavo prebere sporočilo in zaščita pred prestrezanjem ni na voljo. Ta storitev še vedno zagotavlja bolj začasno komunikacijo, ki lahko izboljša zasebnost in varnost. Poleg tega se lahko za zaščito pred prestrezanjem uporabi geslo.

Kako lahko med uporabo te storitve čim bolj zaščitim svojo zasebnost?

Kot je razloženo drugje v tem pogostem vprašanju, čeprav že veliko naredimo za zaščito vaše zasebnosti in čeprav ne zbiramo nobenih osebnih podatkov, nekatere podatke, povezane z dnevniki , posredujemo in zbiramo mi in drugi z vami prek spletnega brskalnika. Vendar pa obstaja več načinov za dodatno zaščito vaše zasebnosti. Eden od načinov, ki je prost, ki temelji na odprtokodni programski opremi in deluje zelo dobro, je uporaba brskalnika Tor . Ta brskalnik je zasnovan za zaščito vaše zasebnosti na več ravneh - vključno z uporabo omrežja Tor . Naše spletno mesto je že dostopno prek čebulnega omrežja Tor, kar pomeni, da za dostop do našega spletnega mesta prek Tor ni potrebna uporaba izstopnega vozlišča, ki negira nekoga, ki prisluškuje prometu izhodnega vozlišča . Vendar ne pozabite, da lahko tudi v tem scenariju vaš ponudnik internetnih storitev vidi, da uporabljate Tor - čeprav ne za kaj. Lahko se celo povežete z VPN in nato zaženete brskalnik Tor za dve plasti anonimnosti; vendar ne pozabite, da lahko vaš ponudnik internetnih storitev v tem scenariju še vedno vidi, da uporabljate VPN - čeprav ne za kaj. Če ne želite, da vaš ponudnik internetnih storitev ve, katere protokole uporabljate, se lahko povežete z velikim javnim omrežjem WiFi, kot so knjižnica, šola itd., In nato uporabite brskalnik Tor.

Kaj pa, če ne zaupam ZDA?

Naši strežniki se nahajajo v ZDA. Poleg tega je naš ponudnik CDN, Cloudflare, podjetje s sedežem v Združenih državah. Poskušali smo odpraviti potrebo po zaupanju nam ali državi, v kateri prebivajo naši strežniki, preprosto zato, ker ne zbiramo osebnih podatkov, ne moremo dešifrirati nobenega sporočila in vse se izbriše kmalu po prejemu. Nekaj nezaupanja pa lahko razumemo, saj je spletno in še posebej, če živite v določenih državah. Imamo načrte, da na Islandiji in v Švici ponudimo možnosti za ljudi, ki težko zaupajo ZDA. Sporočite nam, če to velja za vas, saj ne bomo motivirani, da ponudimo druge možnosti, razen če obstaja resnično povpraševanje.

Kaj počnete, da preprečite neželeno pošto?

Kadar koli dovolite nekomu, da objavi sporočilo, ki ga je mogoče poslati prek povezave, povabite pošiljatelje neželene pošte. Odpravljanje te težave ni povsem preprosto. Ne želimo naložiti CAPTCHA tretje osebe kot del postopka pošiljanja sporočila iz nekaj razlogov:

Težavo z API -jem bi lahko rešili z uporabo sistema ključev API -ja, potem pa moramo zbrati podatke o uporabnikih, česar nočemo. Kaj pa preprečuje pošiljateljem neželene pošte, da dobijo veliko ključev API? Sporočila ne moremo preučiti, da bi sklepali na njihovo nezaželenost (kar je v najboljšem primeru zelo problematično), saj imamo poleg šifriranja sporočil pravilnik o vsebini sporočil. Glede na te zahteve uporabljamo dve metodi za preprečevanje neželene pošte: Če veste, da pošiljatelji neželene pošte zlorabljajo to storitev, vložite prijavo zlorabe .

Zakaj obstaja možnost, da od prejemnika zahtevate, da izpolni CAPTCHA?

Res je, da nam CAPTCHA ni všeč, vendar se zavedamo, da služijo svojemu namenu in imajo čas in kraj (vsaj za zdaj). To je preprost način, da pošiljatelj pridobi nekaj zagotovila, da je prejemnik človek in da avtomatizirani procesi ne dostopajo do sporočila.

Kdo upravlja to storitev in zakaj je brezplačna?

Smo le par fantov, ki smo se včasih soočili s težavo, da nimamo dobrih možnosti za zaščito naše zasebnosti. Pogosto je to posledica komunikacije s prijatelji in družinskimi člani, ki niso bili zelo previdni pri ravnanju s svojimi napravami in informacijami. Včasih se je to zgodilo pri uporabi spletnih forumov, kot je Reddit, ali pri uporabi spletnih podpornih sistemov. Našli smo nekaj spletnih začasnih rešitev za sporočila, vendar nobena ni ponudila E2EE, kar pomeni, da jim ne moremo zaupati. Zato smo zgradili svojo lastno rešitev in se odločili, da jo podarimo, da bodo imeli drugi koristi od nje.

Kako lahko zaupam odgovorom na zgornja vprašanja?

Pravzaprav ne bi smeli zaupati nobenemu spletnemu mestu samo zato, ker na njem piše nekaj - običajno je dobra ideja preveriti vse trditve. Zahtevo, da nam čim bolj zaupate, smo poskušali odstraniti z uporabo šifriranja od konca do konca. Na primer, zelo enostavno je preveriti, da ne moremo prebrati nobenega sporočila, ker je šifrirano . Tudi kodo javascript, na kateri je to spletno mesto, je zelo preprosta, tako da je enostavna za branje in razumevanje. Odprtokodna koda omogoča ljudem, da preverijo, kaj se izvaja; vendar ne pozabite, da ni mogoče resnično preveriti, kaj strežnik izvaja. Čeprav je res, da se večina zahtev po zaupanju odstrani s šifriranjem od konca do konca, je to še vedno dejavnik, ki ga naši uporabniki veliko tehtajo, ko se odločajo za uporabo te storitve ali ne.