Pyetjet e bëra më shpesh

Pse është përkthyer dobët kjo faqe? ⎃

Na vjen keq, por autorët aktual flasin vetëm anglisht. Na duhet ndihmë për përkthimin e këtij projekti në gjuhë të tjera. Si një mjet i thjeshtë dhe i lirë për ta bërë këtë shërbim të disponueshëm për njerëzit që nuk flasin anglisht, ne përdorim përkthimin makinerik. Rezultatet janë zakonisht të pranueshme, por mund të rezultojnë në formulim të çuditshëm ose edhe në informacion plotësisht të pasaktë. Ju mund të na ndihmoni të përmirësojmë përvojën për të gjithë - dorëzoni përkthimin e saktë .

Sa i sigurt është ky shërbim?

Ne kemi ndërmarrë shumë hapa për ta bërë këtë shërbim të sigurt për përdorimin e tij të synuar . Para se të kalojmë ato hapa, është e rëndësishme të kuptojmë sa vijon:

Qëllimi ynë është të ofrojmë këtë shërbim në një mënyrë që ofron mundësi për të rritur privatësinë dhe sigurinë tuaj. Këtu janë disa hapa që kemi ndërmarrë për të ruajtur sigurinë e informacionit tuaj:

Pse mora një lidhje këtu me një mundësi për të deshifruar një mesazh?

Ju kërkojmë ndjesë nëse ka gabime në këtë përkthim . Ky shërbim thjesht kalon një mesazh të koduar nga një pikë në tjetrën dhe ju jeni marrësi. Mesazhi së shpejti do të fshihet. Operatorët e këtij shërbimi nuk kanë asnjë mënyrë për të lexuar përmbajtjen e mesazhit. Zakonisht dikush e përdor këtë shërbim kur nuk dëshiron që përmbajtja e një mesazhi të mbetet brenda bazave të të dhënave të ndryshme / pajisjeve / shërbimeve / skedarëve / etj. siç është tipike kur dërgoni një email / mesazh të menjëhershëm / tekst / etj. Nëse vendosni të deshifroni, mbani në mend sa vijon:

Ju fshini gjithçka të paraqitur në këtë sit?

E vërtetë për logon tonë të koshit të plehrave ... gjithçka fshihet menjëherë pasi e ka marrë. Fshirja e gjithçkaje është e automatizuar - e shkruar në server. Mendojeni në këtë mënyrë - ka dy klasa informacioni të paraqitura:

Në rastin e mesazheve, ju mund të kontrolloni kur t'i fshijmë ato duke specifikuar: Si parazgjedhje, gjithçka në lidhje me një mesazh fshihet pasi të merret një herë ose është 1 javë e vjetër - cilado që të ndodhë e para. Kur bëhet fjalë për fshirjen e të gjithë informacionit tjetër të qenësishëm në paraqitjen e ndonjë gjëje në internet (p.sh. adresën tuaj IP, etj.), Ne nuk ju japim asnjë kontroll se kur ose si fshihet - ne thjesht i fshijmë të gjitha çdo 24 orë .

Pse të përdoret ky shërbim?

Ky shërbim është një mjet për t'ju ndihmuar që mesazhet që dërgoni / merrni më pak të përhershme. Pjesa më e madhe e asaj që ju komunikoni në Internet (biseda, tekste, email, etj.) Ruhet dhe fshihet rrallë. Shpesh, kur fshini diçka, ajo në të vërtetë nuk fshihet, por përkundrazi shënohet si e fshirë dhe nuk ju shfaqet më. Komunikimet tuaja totale grumbullohen vit pas viti në bazat e të dhënave dhe në pajisjet mbi të cilat nuk keni kontroll. Në mënyrë të pashmangshme, një ose më shumë nga organizatat / njerëzit / pajisjet që ruajnë komunikimet tuaja janë hackuar dhe informacioni juaj ka rrjedhur. Ky problem është kaq i përhapur, saqë tani ka shumë faqe në internet që përcjellin organizatat që janë komprometuar dhe kanë zbuluar të dhëna të përdoruesit. Mesazhet e përkohshme të koduara nga një skaj në tjetrin janë një zgjidhje e thjeshtë për t'ju ndihmuar të bëni disa nga komunikimet tuaja më pak të përhershme. Çdo mesazh i dërguar në këtë sit ka një kohë për të jetuar që varion nga 1 minutë deri në 2 javë - pasi të ketë kaluar ajo kohë, mesazhi është fshirë. Për më tepër, cilësimi i paracaktuar është të fshini çdo mesazh pasi marrësi ta ketë marrë atë. Për më tepër, të gjitha mesazhet janë të koduara nga pajisja juaj deri në pajisjen e marrësit. Qëllimi kryesor në përdorimin e enkriptimit nga fundi në fund është të heqim aftësinë tonë për të lexuar çdo mesazh të paraqitur duke hequr kështu disa nga kërkesat e besimit. Rezultati përfundimtar është se tani është e lehtë të dërgosh një mesazh të koduar përmes një lidhjeje të thjeshtë. Ky mesazh fshihet ose menjëherë pas dërgimit ose pas rikuperimit. Ju nuk keni nevojë të instaloni / konfiguroni softuer të veçantë. Ju nuk keni nevojë të krijoni një llogari ose të jepni ndonjë informacion personal. Marrësi nuk duhet të jetë në kontaktet tuaja ose madje të dijë për këtë shërbim - kërkesa e vetme që ata të mund të klikojnë në një lidhje.

A është ky një shërbim mesazhesh?

Jo. Ky shërbim është krijuar për të plotësuar shërbimet ekzistuese të mesazheve si mesazhet e çastit / email / tekst / etj. duke shtuar aftësinë për të parandaluar që mesazhet e dërguara të mos ruhen për një kohë të gjatë. Ne nuk ia dorëzojmë marrësit lidhjen e gjeneruar .

Cilat janë rastet e përdorimit të synuar?

Pra cilat janë disa skenarë ku është e përshtatshme të përdoret ky shërbim? Ndërsa të gjithë kanë nevoja dhe kërkesa të ndryshme kur bëhet fjalë për privatësinë dhe sigurinë e tyre, unë personalisht kam gjetur skenarët e mëposhtëm si raste të përshtatshme të përdorimit:

Për çfarë nuk duhet të përdoret ky shërbim?

Ky shërbim nuk duhet të përdoret për informacion shumë të ndjeshëm për të gjitha arsyet e shpjeguara në këtë FAQ. Më poshtë janë disa shembuj se çfarë nuk duhet të bëni:

Pse të mos përdorim vetëm PGP / Sinjal / OMEMO / Matricë / etj?

Nëse e njihni personin që dëshironi të dërgoni mesazhe të sigurta të përkohshme, dërgojini shpesh, prisni një ndërfaqe të ngjashme me bisedën dhe / ose mund të prisni që marrësi të ketë softuerin e kërkuar dhe të dijë ta përdorë atë, kjo faqe në internet nuk është ndoshta zgjidhja me e mire. Ka mundësi të shkëlqyera atje që janë me burim të hapur, mbështesin E2EE, jo të bazuara në internet, dhe madje disa si Signal që gjithashtu mbështesin mesazhe të përkohshme. Unë personalisht përdor një server privat XMMP dhe OMEMO për të biseduar me miqtë dhe familjen e ngushtë. Përdorimi i kësaj faqe mund të jetë optimale vetëm nëse nuk e dini se çfarë programi po përdor marrësi, nuk e dini numrin e telefonit / dorezën e kontaktit, nuk e dini aftësinë e tyre teknike (por supozoni se ata mund të klikojnë në një lidhje), ose thjesht preferoni ta mbani mesazhin që dërgoni jashtë transportit themelor të komunikimit.

Cilat kërkesa ekzistojnë?

Kërkohet një shfletues modern dhe i azhurnuar i internetit që zbaton siç duhet standardet, përfshirë Web Crypto API. Shembujt përfshijnë: Chrome, Firefox, Edge dhe Safari (rreth vitit 2020 ose më pas).

A mund të bëjë marrësi një kopje të mesazhit?

Po. Edhe pse mesazhi mund të fshihet vetvetiu pas marrjes, marrësi përsëri mund ta shikojë mesazhin. Në çdo kohë, marrësi mund ta shikojë plotësisht mesazhin, mund të bëhet një kopje - kjo vlen për të gjitha komunikimet. Ekziston një mundësi për ta bërë më të vështirë për marrësin të bëjë një kopje. Në këtë rast zbatohen tre pengesa për kopjim:

Sidoqoftë, këto mbrojtje nga kopjimi janë të dobëta sepse mund të anashkalohen. Gjithashtu, marrësi gjithmonë mund të marrë vetëm një screenshot ose një foto të mesazhit.

A është mbledhur ndonjë informacion personal?

Ne nuk mbështesim llogaritë e përdoruesve (p.sh. emrin e përdoruesit / fjalëkalimin). Ne nuk mbledhim ndonjë informacion që mund t'ju identifikojë (p.sh. emri / adresa / emaili / telefoni). Possibleshtë e mundur që disa informacione personale mund të jenë në mesazhin që po dërgoni, por që është i koduar dhe nuk kemi asnjë mënyrë për ta lexuar atë. Ju lutemi rishikoni politikën tonë të privatësisë për detaje të plota.

Çfarë informacioni regjistrohet?

Web serveri ynë mban deri në 24 orë format të përbashkët regjistri në të gjithë aktivitetin e uebit. Kjo përfshin regjistrimin e adresës IP të plotë të klientëve HTTP. Pas 24 orësh, ky informacion i regjistruar fshihet automatikisht. Të gjitha kërkesat e dërguara në / api janë të postuara, që do të thotë se asnjë informacion specifik i mesazhit nuk regjistrohet kurrë nga serveri i internetit. Për më tepër, çdo informacion i ruajtur në bazën e të dhënave regjistrohet në mënyrë efektive. Të gjitha shënimet në bazën e të dhënave, duke përfshirë adresat IP anonime dhe të hasheduara, kanë një kohë skadence (TTL) pas së cilës ato fshihen automatikisht. Koha e skadimit të TTL ndryshon ndërmjet 1 minutë dhe 2 javë.

Çfarë po bëni për të siguruar serverat?

Siguria e serverit është një shqetësim i dukshëm. Ekzistojnë dy fusha kryesore në të cilat përqendrohemi për ta mbajtur atë të sigurt:

Cilat rreziqe të sigurisë janë të pranishme kur përdorni këtë sit?

Përpara adresimit specifik të disa prej këtyre rreziqeve, mendoj se një analogji gjysmë e shkurtër mund të ndihmojë për të përmbledhur rreziqet në përdorimin e çdo komunikimi në Internet. Vizualizoni që çdo sistem është po aq i sigurt sa hallka më e dobët në një zinxhir. Tani imagjinoni një skenar ku janë dy njerëz në një dhomë të mbyllur pa asnjë mjet për të parë, dëgjuar ose regjistruar ndonjë gjë që bëjnë. Njëri do t'i kalojë një mesazh tjetrit, i cili me leximin e mesazhit do ta djegë atë. Nëse dikush jashtë asaj dhome dëshiron të marrë mesazhin i cili ishte kaluar tashmë, ai do të jetë i vështirë. Cila është lidhja më e dobët për të marrë mesazhin? Nuk ka aq shumë lidhje për të zgjedhur - është një zinxhir mjaft i shkurtër. Tani imagjinoni që kur të dërgoni një mesazh në Internet se ka të paktën një milion lidhje në zinxhir - shumë prej tyre të dobët - shumë prej tyre plotësisht jashtë kontrollit tuaj - dhe ky është realiteti.

Përdorimi i kriptimit mund të ndihmojë shumë me problemin e mësipërm të lidhjeve dhe është e lehtë të joshesh duke menduar se sistemet E2EE të dizajnuara mirë ofrojnë zgjidhjen përfundimtare. Sidoqoftë, ky mendim mund t'ju sjellë në telashe, sepse një sulmues zakonisht thjesht shkon pas lidhjeve më të dobëta në sistem. Për shembull, ndoshta është shumë më e lehtë të marrësh telefonin ose kompjuterin tënd dhe të vendosësh një regjistrues hyrje për të lexuar gjithçka që shkruan, se sa të thyesh mesazhe të koduara përmes telit. Përfundimi është se nëse do të kisha për detyrë të komunikoja një sekret me rëndësi jetike / kritike, unë do të përdorja vetëm komunikimet elektronike si një metodë e mundësisë së fundit.

Pra, ekzistojnë rreziqe të sigurisë duke përdorur çdo komunikim, por ju prapë përdorni një shfletues uebi për bankat, blerjen e gjërave, email, etj. It'sshtë një rrezik i pranuar për lehtësitë e mëdha të fituara. Në të vërtetë pyetja është ... cilat rreziqe sigurie janë gjysmë specifike për këtë sit? Disa vijnë në mendje:

Çfarë po bëni për sulmet njeri-në-mes (MITM)?

Të gjithë përdoruesit e faqeve të internetit mund të jenë potencialisht viktima të një sulmi MITM - kjo faqe nuk ndryshon nga të gjithë të tjerët në internet në këtë drejtim. Një sulm MITM është kur një sulmues është në gjendje të përgjojë dhe modifikojë komunikimet midis shfletuesit të përdoruesit dhe serverit të faqes. Kjo i lejon sulmuesit të modifikojë cilindo nga kodet / përmbajtjet e faqes ndërsa i shfaqet përdoruesit përfundimtar të jetë faqja në të cilën janë mësuar. Ne marrim disa masa për ta bërë një sulm MITM më të vështirë:

Sidoqoftë, një sulm i MITM është gjithnjë i mundur - veçanërisht nëse sulmuesi kontrollon rrjetin / infrastrukturën me çelës publik siç do të ishte rasti për organizata ose qeveri të mëdha / të fuqishme. Ne ofrojmë shtesa të shfletuesit të cilat mund të ndihmojnë në zbutjen e disa rreziqeve të MITM.

Çfarë avantazhesh ofrojnë shtesat e shfletuesit?

Ne ofrojmë shtesa të shfletuesit si një mjet për të ofruar komoditet shtesë dhe siguri shtesë. Ta themi thjesht ... Shtesat e bëjnë dërgimin e mesazheve të përkohshme më të shpejtë dhe më të lehtë. Disa siguri fitohen gjithashtu sepse i gjithë kodi i përdorur për të kriptuar dhe përgatitur një mesazh ruhet lokalisht brenda shtesës. Për shkak se kodi është ruajtur lokalisht, kjo i ofron dërguesit një mbrojtje nga sulmet MITM . Sidoqoftë, vlen të theksohet se ndërsa zgjerimet ofrojnë më shumë mbrojtje ndaj një sulmi MITM që komprometon përmbajtjen e mesazhit, një sulm MITM mund të jetë akoma efektiv (dmth. Për të përcaktuar adresën IP të dërguesit nëse nuk përdorni TOR / VPN / etj.).

Si mund ta di me siguri që çdo gjë e paraqitur është e koduar nga një skaj i skajshëm?

Ndryshe nga shumë klientë të tjerë të popullarizuar të bisedave të koduara nga fundi në fund (E2EE), është mjaft e thjeshtë për të parë saktësisht se çfarë na dërgohet kur dorëzoni një mesazh. Udhëzuesi video më poshtë demonstron se si të konfirmojmë se nuk kemi asnjë mënyrë për të deshifruar mesazhet e dërguara në server.

Gjithashtu, nëse e mendoni, për sa kohë që ne nuk jemi ndonjë agjensi sekrete që përpiqemi të mbledhim mesazhe të ndjeshme, nuk ka asnjë përfitim që të jemi në gjendje të deshifrojmë mesazhe pasi që të kemi atë aftësi vetëm na krijon probleme. Ne as nuk duam të ruajmë mesazhe - megjithatë është një e keqe e domosdoshme t'i dërgosh ato.

Si funksionon kriptimi fund në fund në këtë sit?

Në këtë kohë, ne jemi duke përdorur kriptimin simetrik (AES-GCM 256bit) me çelësat që rrjedhin nga fjalëkalimet (minimumi 150,000 përsëritje të PBKDF2 / SHA-256). Enkriptimi asimetrik nuk përdoret sepse ekzistojnë kërkesa për 1) dërguesin që fillon komunikimin 2) dërguesin dhe marrësin që nuk janë në internet në të njëjtën kohë dhe 3) asnjë informacion mbi marrësin dhe 4) po përpiqemi t'i mbajmë gjërat realisht të thjeshta dhe menaxhimi i çelësave është e komplikuar API standard i Crypto në Ueb përdoret për të gjithë funksionalitetet kriptografike përfshirë RNG. Në thelb, këtu është ajo që ndodh:

  1. Përdoruesi përfundimtar zgjedh një fjalëkalim ose një gjenerohet automatikisht
  2. Bëhet një thirrje API për të marrë numrin e përsëritjeve të kërkuara PBKDF2 / SHA-256 ( ky hap kërkohet për kontrollin e postës së bezdisshme )
  3. Gjenerohet një kripë 32 bajtëshe
  4. Një çelës rrjedh nga kripa dhe fjalëkalimi
  5. Gjenerohet një vektor inicializimi 12 bajtësh (IV)
  6. Mesazhi është i koduar duke përdorur tastin + IV
  7. Numërimi i përsëritjes, kripa, IV dhe teksti i koduar dërgohen në server (së bashku me disa informacione të tjera si TTL, RTL, etj.)
  8. Serveri kthen një ID të rastësishme duke iu referuar mesazhit
  9. Shfletuesi më pas i paraqet përdoruesit përfundimtar një lidhje e cila përmban ID-në dhe fjalëkalimin e kthyer ose një lidhje pa fjalëkalimin (në këtë rast marrësi duhet ta dijë dhe të vendosë fjalëkalimin)
  10. Nëse fjalëkalimi është pjesë e lidhjes, ajo është në hash URL , dhe për këtë arsye nuk është dërguar kurrë në server kur marrësi bën kërkesën GET
  11. Marrësi nxirret nëse dëshiron të deshifroj dhe shikojë mesazhin
  12. Shfletuesi bën një kërkesë duke specifikuar ID-në e mesazhit
  13. Nëse dërguesi kërkon që të kompletohet një CAPTCHA, marrësi drejtohet në një URL tjetër për të provuar se janë njerëzore (sapo të kalojnë drejtohen përsëri)
  14. Serveri dërgon mesazhin e koduar dhe do të fshijë në mënyrë të paracaktuar mesazhin në këtë pikë nëse leximi në jetë (RTL) është një
  15. Marrësi do të deshifrojë mesazhin me fjalëkalimin (dhe do të kërkohet për fjalëkalimin nëse nuk është në URL)
Ky konfigurim është jashtëzakonisht i thjeshtë dhe ofron enkriptimin e mesazhit nga pajisja e dërguesit te pajisja e marrësit, por natyrisht që nuk ka garanci se kriptimi asimetrik mund të ofrojë në kuptimin e njohjes vetëm të dikujt që posedon çelësin privat të marrësit mund ta deshifrojë mesazhin. Kushdo që ka lidhjen mund ta hapë mesazhin në skenarin e paracaktuar ku fjalëkalimi është pjesë e URL - kjo nënvizon rëndësinë e përdorimit të një transporti të përshtatshëm për lidhjen (p.sh. email / bisedë / tekst / etj.) - një vendim që i mbetet dërguesi. Ne, nëse ka interes, ne gjithashtu mund të mbështesim një skemë asimetrike shumë themelore përmes së cilës marrësi fillon një kërkesë për një mesazh dhe dërgon atë lidhje kërkese te dërguesi i mesazhit. Kjo konfigurim do të eleminonte nevojën për të pasur fjalëkalimin në URL, por gjithashtu eliminon aftësinë që dërguesi të fillojë.

Fjalëkalimi i deshifrimit mund të jetë në URL?

Po. Kjo padyshim që ndikon në sigurinë sepse nëse metoda e përdorur për të dërguar lidhjen është e pasigurt, mesazhi është i pasigurt nga shoqata. Të gjitha zgjidhjet për të eleminuar këtë çështje paraqesin hapa dhe komplekse shtesë që ndikojnë në përvojën e përdoruesit (dmth. Gjërat duhet të konfigurohen në të dy skajet para se të dërgoni mesazhin). Një skemë asimetrike përmes së cilës marrësi fillon një kërkesë për një mesazh dhe dërgon atë lidhje kërkese mund të funksionojë me kërkesën tonë kryesore "gjithçka është e parakohshme" - kjo mund të zbatohet. Në fund të fundit, nëse dy palë do t'i dërgojnë mesazhe njëra-tjetrës shpesh, ekzistojnë zgjidhje më të mira duke supozuar se të dy palët mund të trajtojnë duke përdorur ato zgjidhje.

Por fjalëkalimi i deshifrimit nuk duhet të jetë në URL?

Korrekt. Nëse fjalëkalimi i deshifrimit nuk përfshihet në lidhje, atëherë marrësit do t'i kërkohet fjalëkalimi. Nëse fjalëkalimi i komunikohet në mënyrë të sigurt marrësit (ose ata tashmë e dinë atë), kjo siguron mbrojtje kundër përgjimit. Sidoqoftë, disavantazhi është se marrësi duhet të dijë dhe të futë saktë fjalëkalimin. Këtu është një mënyrë për t'i dërguar fjalëkalimin marrësit i cili ofron një mbrojtje kundër përgjimit:

  1. Kriptoni fjalëkalimin në një mesazh me cilësimet e paracaktuara dhe dërgojeni këtë lidhje marrësit.
  2. Kur marrësi klikon lidhjen dhe deshifron mesazhin, ata e dinë që askush tjetër nuk e ka marrë fjalëkalimin para tyre sepse mesazhi që përmban fjalëkalimin fshihet pas marrjes. Sidoqoftë, nëse ka një sulm aktiv MITM ose nëse pajisja juaj ose pajisja e marrësit është komprometuar, atëherë është ende e mundur që një palë tjetër të marrë fjalëkalimin.
  3. Konfirmoni me marrësin se ata e kanë marrë me sukses fjalëkalimin. Për shembull, nëse marrësi ju informon se kur shkuan për të marrë fjalëkalimin, se mesazhi tashmë ishte fshirë, atëherë e dini që dikush tjetër e ka marrë fjalëkalimin para marrësit dhe se fjalëkalimi është i komprometuar dhe nuk duhet të përdoret.
  4. Duke përdorur fjalëkalimin që marrësi konfirmoi se e posedojnë, tani mund të dërgoni një mesazh duke përdorur të njëjtin fjalëkalim për kriptim - thjesht ndani versionin e lidhjes që nuk përmban fjalëkalimin.

Kjo është e saktë - ne gjenerojmë lidhjen dhe ia lëmë dërguesit se sa më mirë t'ia dorëzojmë marrësit. Qëllimi i këtij shërbimi është të ofrojë një mundësi që ofron më pak qëndrueshmëri në transportin ekzistues të mesazheve si email / bisedë / tekst / etj. Prandaj, pritja është që lidhja që ne krijojmë e cila tregon për mesazhin e përkohshëm të dërgohet përmes një transporti ekzistues të mesazhit. Kjo ka implikime të sigurisë që përdoruesit duhet të kuptojnë. Le të marrim një mesazh me tekst SMS si një shembull pasi kjo është një metodë mjaft e pasigurt e komunikimit. Kur përdorni këtë shërbim për të dërguar një lidhje të përkohshme të mesazhit përmes një mesazhi me tekst, nëse përdorni mënyrën e paracaktuar me të cilën fjalëkalimi përfshihet në lidhje, kushdo që ka lidhjen mund ta lexojë mesazhin dhe nuk ofrohet mbrojtje nga përgjimi. Ky shërbim ende ofron një komunikim më të përkohshëm i cili mund të rrisë privatësinë dhe sigurinë. Për më tepër, ju mund të zgjidhni të dërgoni lidhjen pa fjalëkalim dhe kjo do të sigurojë mbrojtje ndaj përgjimit.

Si mund ta mbroj privatësinë time sa më shumë që të jetë e mundur gjatë përdorimit të këtij shërbimi?

Siç është diskutuar diku tjetër në këtë FAQ, edhe pse ne tashmë bëjmë shumë për të mbrojtur privatësinë tuaj dhe edhe pse nuk mbledhim ndonjë informacion personal, disa informacione të lidhura me regjistrin dorëzohen dhe mblidhen nga ne dhe të tjerët për shkak të jush duke përdorur një shfletues uebi. Sidoqoftë, ka mënyra të shumta për të mbrojtur privatësinë tuaj edhe më shumë. Një mënyrë e cila është falas për t'u përdorur, bazuar në softuer me burim të hapur, dhe funksionon mjaft mirë është të përdorni Tor Browser . Ky shfletues është krijuar për të mbrojtur privatësinë tuaj në nivele të shumëfishta - përfshirë përdorimin e rrjetit Tor . Faqja jonë është tashmë e arritshme përmes rrjetit të qepëve Tor që do të thotë që hyrja në faqen tonë përmes Tor nuk kërkon përdorimin e një nyje daljeje, e cila mohon dikë që përgjon trafikun e nyjeve dalëse . Sidoqoftë, mbani në mend se edhe në këtë skenar, ISP-ja juaj mund të shohë se jeni duke përdorur Tor - megjithëse jo për çfarë. Ju madje mund të lidheni me një VPN dhe pastaj të hapni Shfletuesin Tor për dy shtresa anonimiteti; megjithatë, mbani në mend se ISP-ja juaj ende mund të shohë se po përdorni një VPN në këtë skenar - megjithëse jo për çfarë. Nëse nuk doni që ISP-ja juaj të dijë se çfarë protokolli po përdorni, mund të lidheni me një rrjet të madh publik WiFi siç është biblioteka, shkolla, etj. Dhe më pas të përdorni shfletuesin Tor.

Po nëse nuk u besoj Shteteve të Bashkuara?

Serverat tanë janë të vendosura në Shtetet e Bashkuara. Për më tepër, ofruesi ynë CDN, Cloudflare, është një kompani me bazë në Shtetet e Bashkuara. Ne jemi përpjekur të heqim nevojën për të na besuar ne ose vendin në të cilin banojnë serverat tanë thjesht sepse ne nuk mbledhim informacione personale, nuk mund të deshifrojmë asnjë mesazh dhe gjithçka fshihet menjëherë pasi të jetë marrë. Sidoqoftë, ne mund të kuptojmë disa mosbesim pasi është i bazuar në internet dhe veçanërisht nëse jetoni në vende të caktuara. Ne kemi disa plane për të ofruar mundësi në Islandë dhe Zvicër për njerëzit që e kanë të vështirë të besojnë në SHBA. Ju lutemi na tregoni nëse kjo vlen për ju, pasi ne nuk do të jemi të motivuar të ofrojmë alternativa nëse nuk ka kërkesë reale.

Çfarë po bëni për të parandaluar postën e bezdisshme?

Në çdo kohë ju lejoni që dikush të postojë një mesazh që mund të transmetohet përmes një lidhjeje, ju ftoni spammers. Frenimi i këtij problemi nuk është plotësisht i drejtpërdrejtë. Ne nuk duam të ngarkojmë një palë të tretë CAPTCHA si pjesë e procesit të dërgimit të mesazhit për disa arsye:

Ne ndoshta mund të kapërcejmë problemin API përmes përdorimit të një sistemi kyç API, por pastaj duhet të mbledhim informacionin e përdoruesit të cilin nuk duam ta bëjmë. Gjithashtu, çfarë është për të ndaluar spammers të marrin shumë çelësa API? Ne nuk mund t'i shqyrtojmë mesazhet për të konkluduar spaminess e tyre (e cila është shumë problematike në rastin më të mirë) pasi që, përveç kriptimit të mesazheve, ne kemi një politikë praktike për përmbajtjen e mesazheve. Duke pasur parasysh këto kërkesa, ne përdorim dy metoda për parandalimin e postës së bezdisshme: Nëse jeni të vetëdijshëm se spammers po abuzojnë me këtë shërbim, ju lutemi paraqisni një raport abuzimi .

Pse ekziston një mundësi për t'i kërkuar marrësit të plotësojë një CAPTCHA?

Ndërsa është e vërtetë që nuk na pëlqejnë CAPTCHA-të, ne e pranojmë që ato i shërbejnë një qëllimi dhe kanë një kohë dhe vend (të paktën tani për tani). Kjo është një mënyrë e thjeshtë që dërguesi të fitojë siguri se marrësi është njerëzor dhe se proceset e automatizuara nuk po hyjnë në mesazh.

Kush po e drejton këtë shërbim dhe pse është falas?

Ne jemi vetëm një çift djemsh të cilët ndonjëherë ishin ballafaquar me situatën e vështirë për të mos pasur mundësi të mira për të mbrojtur privatësinë tonë. Shpesh kjo rezultoi nga komunikimi me miqtë dhe anëtarët e familjes të cilët nuk ishin shumë të kujdesshëm se si i trajtonin pajisjet dhe informacionet e tyre. Në raste të tjera kjo ka ndodhur kur përdorni forume të bazuara në internet si Reddit ose duke përdorur sisteme mbështetëse të bazuara në internet. Gjetëm disa zgjidhje të përkohshme të mesazheve të bazuara në internet, por asnjë nuk ofroi E2EE që do të thoshte se nuk mund t'u besonim atyre. Kështu që ne vetëm ndërtuam zgjidhjen tonë dhe vendosëm ta jepnim atë në mënyrë që të tjerët të mund të përfitonin prej saj.

Si mund t’u besoj përgjigjeve të pyetjeve të mësipërme?

Në të vërtetë nuk duhet t'i besoni asnjë faqe në internet vetëm sepse thotë disa gjëra - zakonisht është një ide e mirë për të verifikuar pretendimet. Ne jemi përpjekur të heqim kërkesën për të na besuar sa më shumë që të jetë e mundur përmes përdorimit të enkriptimit nga një skaj i skajshëm. Për shembull, është shumë e lehtë për tu kontrolluar që nuk mund të lexojmë asnjë mesazh pasi ato janë të koduara . Ne gjithashtu e kemi mbajtur kodin javascript që drejton këtë faqe shumë të thjeshtë në mënyrë që të lexohet dhe kuptohet lehtë. Bërja e të gjithë kodit burim i hapur lejon njerëzit të verifikojnë se çfarë funksionon; megjithatë, mbani në mend se nuk ka asnjë mënyrë për të verifikuar me të vërtetë se çfarë po përdor serveri. Ndërsa është e vërtetë që shumë prej kërkesave të besimit hiqen me enkriptimin nga një skaj i skajit, ai është akoma një faktor që përdoruesit tanë e peshojnë shumë kur vendosin të përdorin këtë shërbim apo jo.