Pyetjet e bëra më shpesh
- Pse është përkthyer dobët kjo faqe? ⎃
- Sa i sigurt është ky shërbim?
- Pse mora një lidhje këtu me një mundësi për të deshifruar një mesazh?
- Ju fshini gjithçka të paraqitur në këtë sit?
- Pse të përdoret ky shërbim?
- A është ky një shërbim mesazhesh?
- Cilat janë rastet e përdorimit të synuar?
- Për çfarë nuk duhet të përdoret ky shërbim?
- Pse të mos përdorim vetëm PGP / Sinjal / OMEMO / Matricë / etj?
- Cilat kërkesa ekzistojnë?
- A mund të bëjë marrësi një kopje të mesazhit?
- A është mbledhur ndonjë informacion personal?
- Çfarë informacioni regjistrohet?
- Çfarë po bëni për të siguruar serverat?
- Cilat rreziqe të sigurisë janë të pranishme kur përdorni këtë sit?
- Çfarë po bëni për sulmet njeri-në-mes (MITM)?
- Çfarë avantazhesh ofrojnë shtesat e shfletuesit?
- Si mund ta di me siguri që çdo gjë e paraqitur është e koduar nga një skaj i skajshëm?
- Si funksionon kriptimi fund në fund në këtë sit?
- Fjalëkalimi i deshifrimit mund të jetë në URL?
- Por fjalëkalimi i deshifrimit nuk duhet të jetë në URL?
- Ky shërbim nuk e jep lidhjen te marrësi?
- Si mund ta mbroj privatësinë time sa më shumë që të jetë e mundur gjatë përdorimit të këtij shërbimi?
- Po nëse nuk u besoj Shteteve të Bashkuara?
- Çfarë po bëni për të parandaluar postën e bezdisshme?
- Pse ekziston një mundësi për t'i kërkuar marrësit të plotësojë një CAPTCHA?
- Kush po e drejton këtë shërbim dhe pse është falas?
- Si mund t’u besoj përgjigjeve të pyetjeve të mësipërme?
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:
- Ndërsa nuk jemi në gjendje ta lexojmë mesazhin tuaj për shkak të kriptimit nga një skaj i skajit , lidhja e paracaktuar e gjeneruar përmban fjalëkalimin / çelësin e dekriptimit ; dhe për këtë arsye, kushdo që ka lidhjen mund të lexojë mesazhin tuaj - përfshirë këdo që është në gjendje ta përgjojë atë.
- Ky shërbim është vetëm një mjet për të lejuar dërgimin e komunikimeve më pak të përhershme (dmth. Mesazhe të koduara që fshihen gjatë marrjes) përmes transportit tradicional që është më i përhershëm (p.sh. posta elektronike / teksti / mesazheve të menjëhershme / faqeve të internetit / etj.). Kjo do të thotë që çdo çështje e sigurisë / privatësisë e natyrshme e transportit të zgjedhur (dmth. Postës elektronike) trashëgohet kur përdorni këtë mjet .
- Ekzistojnë zgjidhje të tjera në dispozicion të cilat ofrojnë siguri më të mirë në varësi të nevojave dhe mjedisit tuaj. Avantazhi kryesor që ofron ky shërbim në krahasim me të tjerët, janë kërkesa shumë më të ulta për marrësin (dmth. Ata thjesht kanë nevojë për një shfletues uebi dhe aftësinë për të klikuar në një lidhje).
- Ndërsa cilësimi i paracaktuar është të fshini mesazhet pas rikuperimit, nuk ka asgjë për të ndaluar marrësin të bëjë një kopje . Mbani në mend se kjo vlen për të gjitha zgjidhjet e përkohshme të mesazheve - nëse marrësi mund ta shohë mesazhin, ai mund të kopjohet.
- Të gjitha komunikimet në Internet mund të rrezikojnë privatësinë tuaj - ju jeni duke tregtuar disa siguri për lehtësi.
- Rrjeti është një mjedis sfidues kur bëhet fjalë për sigurinë për shkak të disa çështjeve themelore - kjo vlen për të gjitha faqet e internetit. Sidoqoftë, të qenit i bazuar në internet e bën verifikimin e pohimit tonë se ne nuk mund ta lexojmë mesazhin tuaj shumë më të lehtë .
- Kjo faqe në internet dhe baza e të dhënave të saj janë pritur në Shtetet e Bashkuara. Ne përdorim Cloudflare, një kompani me qendër në Shtetet e Bashkuara, si rrjetin tonë të shpërndarjes së përmbajtjes (i gjithë trafiku i internetit përshkon këtë rrjet).
- Përdorimi i shërbimit nuk kërkon ndonjë informacion personal (p.sh. emri / emaili / telefoni / etj.). Nuk ka sistem llogarie (p.sh. hyrja / fjalëkalimi / etj.); prandaj, çdo shkelje e të dhënave nuk mund të nxjerrë këtë informacion.
- E gjithë përmbajtja e mesazhit është e koduar nga fundi në fund . Me fjalë të tjera, çelësi / fjalëkalimi i deshifrimit nuk na dërgohet kurrë. Prandaj, ne, ose dikush tjetër që posedon bazën e të dhënave, nuk kemi asnjë mënyrë për të deshifruar dhe parë përmbajtjen e mesazheve.
- Çdo hyrje në bazën tonë të të dhënave ka një kohë për të jetuar duke filluar nga 1 minutë deri në 2 javë (parazgjedhjet deri në 1 javë). Pasi të ketë kaluar kjo kohë, rekordi fshihet automatikisht. Prandaj, çdo informacion në bazën tonë të të dhënave do të fshihet menjëherë pas krijimit të tij .
- Ne mirëmbajmë vetëm 24 orët e fundit të regjistrave të serverave të internetit . Çdo informacion IP i ruajtur në bazën e të dhënave është shkëputur në mënyrë të sigurt duke e bërë të pamundur nxjerrjen e IP-së origjinale.
- I gjithë kodi që furnizon këtë shërbim është me burim të hapur dhe i disponueshëm për rishikim. Ju mund ta shihni me lehtësi kodin i cili ekzekuton kriptimin - i cili është qëllimisht i shkurtër, konciz dhe i komentuar.
- Një numër i masave paraprake teknike janë marrë për të ndihmuar në forcimin e sigurisë - disa prej të cilave përfshijnë:
- E gjithë kjo faqe në internet përveç / api është statike dhe nuk mbështet kodin e serverit në faqe (p.sh. PHP / JSP / ASP / etj.)
- Web Crypto API , e cila është pjesë e shfletuesit, përdoret për të kriptuar të gjithë përmbajtjen e mesazheve.
- TLS përdoret për të kriptuar komunikimet midis shfletuesit tuaj dhe serverave tanë. Ndihmon në sigurimin që kodi nuk mund të përgjohet ose modifikohet gjatë tranzitit. TLS 1.3 mbështetet, por ne gjithashtu mbështesim TLS 1.2 për pajisjet e vjetra. Versionet e vjetra të TLS janë çaktivizuar sepse nuk janë aq të sigurta.
- Regjistrat e Transparencës së Certifikatës monitorohen për keq-lëshim të certifikatës. Për më tepër, ne publikojmë një politikë të Autorizimit të Autoritetit të Certifikimit (AAC) për të zvogëluar rrezikun e keq-lëshimit të padëshiruar ose me qëllim të keq të certifikatës.
- Ne përdorim Sigurinë e Transportit Rreptë HTTP (HSTS) për të siguruar që shfletuesit gjithmonë të komunikojnë me serverat tanë duke përdorur protokollin TLS. Për më tepër, ne përfshijmë domenet tona në listat e para-ngarkimit.
- Një politikë e rreptë e sigurisë së përmbajtjes zbatohet për të parandaluar sulmet e kryqëzimit të faqeve (XSS) .
- Duke përdorur një Politikë të Burimeve Ndër-Origjinale , një Politikë Ndërvepruese të Ndërveprimit dhe Një Politikë Hapëse Ndër-Origjinale , ne ndalojmë kodin e origjinës së kryqëzuar për të ndihmuar në zbutjen e sulmeve spekulative të kanaleve anësore si Specter dhe Meltdown. Kjo gjithashtu ofron mbrojtje ndaj kërkesave potencialisht të dëmshme nga origjina të tjera duke izoluar kontekstin e shfletimit ekskluzivisht në dokumente me origjinë të njëjtë.
- Ne përdorim një Politikë të Lejeve për të parandaluar që shfletuesi të ngarkojë burime të cilat mund të rrezikojnë privatësinë tuaj, siç janë vendndodhja juaj, kamera në internet, mikrofoni, etj.
- DNSSEC është përdorur në të gjitha fushat tona për të ndihmuar në zbutjen e sulmeve MITM të bazuara në DNS.
- Ne marrim një numër masash paraprake për të siguruar serverin.
- Asnjë kod i palës së tretë nuk është i ngarkuar (dmth. JQuery) dhe shumë pak burime janë të ngarkuara (shkoni përpara dhe hapni skedën e Rrjetit në Mjetet e Zhvillimit për të kontrolluar) - kjo minimizon përpjekjen e kërkuar për të audituar. Një përjashtim është nëse kërkohet një CAPTCHA - që ngarkon kodin e palës së tretë nga hCaptcha . Sidoqoftë, kodi hCaptcha ngarkohet në URL-në e tij brenda rregullave të veta CSP dhe në asnjë moment nuk ka ndonjë qasje në asgjë që ka të bëjë me një mesazh.
- Si një mjet për të ndihmuar në mbrojtjen e sigurt kundër sulmeve MITM , shtesat e shfletuesit janë në dispozicion .
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:
- Likelyshtë e mundshme që mesazhi të fshihet menjëherë pasi të dërgohet në pajisjen tuaj për deshifrim. Kjo do të thotë që pasi të klikoni në butonin për të deshifruar mesazhin, nuk kemi më një kopje për t'ju dërguar përsëri më vonë.
- Ne fshijmë në mënyrë sistematike të gjithë informacionin e marrë. Mesazhet do të fshihen diku nga një minutë deri në dy javë pasi të jenë krijuar - pavarësisht nëse mesazhi është dekriptuar ndonjëherë. Me fjalë të tjera, nëse keni nevojë të lexoni mesazhin, mos prisni shumë për ta dekriptuar atë.
- Dërguesi ka të ngjarë të besojë se përmbajtja e mesazhit duhet të trajtohet me kujdes. Ata madje mund të kenë treguar se nuk duan të bëhen kopje. Ju lutemi respektoni dëshirat e tyre.
- Nëse ju kërkohet një fjalëkalim për të deshifruar një mesazh, mos e mbyllni dritaren / skedën e shfletuesit. Për pikën e parë të plumbit në këtë listë, ka të ngjarë që nuk mund të dërgojmë një kopje tjetër më vonë. Thjesht lini dritaren / skedën e shfletuesit hapur derisa të mund të futni fjalëkalimin. Nëse futni një fjalëkalim të pasaktë, do t'ju kërkohet përsëri. Fjalëkalimi duhet të futet saktësisht. Mbani në mend se për të akomoduar gjuhë të ndryshme dhe kërkesa për fjalëkalim, ne pranojmë shumë karaktere të ndryshme në fjalëkalime.
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:
- Mesazhe të koduara për të cilat nuk kemi asnjë mënyrë për të deshifruar përmbajtjen
- Informacione të tjera të qenësishme në paraqitjen e ndonjë gjëje në internet (p.sh. adresa juaj IP, etj.)
- Për sa kohë duhet ta mbajmë mesazhin nëse askush nuk e merr atë (duke filluar nga 1 minutë deri në 2 javë - si parazgjedhje deri në 1 javë).
- Sa herë është marrë mesazhi (duke filluar nga 1 në 100 herë - parazgjedhjet në 1 herë)
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:
- Ju keni qenë duke komunikuar përmes një forumi në internet në internet rreth shtigjeve të biçikletave malore në zonë dhe ndonjëherë takoheni me njerëz në forum për të parë së bashku shtigje të reja. Dikush nga forumi dëshiron t'ju marrë në fundjavën tuaj në vendin tuaj për të hipur në një shteg. Ju nuk doni që adresa juaj e shtëpisë të qëndrojë përgjithmonë në këtë bazë të dhënash të faqes në internet. Thjesht dërgoni adresën përmes këtij shërbimi - lidhja është ajo që gjendet në bazën e të dhënave të forumit të faqes në internet, por pasi lexohet nga marrësi, mesazhi / adresa fshihet.
- Ju duhet t'i dërgoni vëllait tuaj hyrjen tuaj në Netflix sepse mbesa juaj po e çmend atë për shkak të bllokimit të COVID dhe ai ende nuk ka llogarinë e tij. Ju nuk kujdeseni shumë për këtë hyrje, por vëllai juaj është veçanërisht i keq në atë që unë thjesht do ta quaj "higjiena dixhitale" dhe ka pasur shumë prova me hyrje të komprometuara dhe malware. Përpjekjet e mëvonshme për ta bërë atë të pastrojë veprimin e tij dhe madje edhe instalimin e mesazheve të sigurta për të kanë dështuar të qëndrojnë. Thjesht dërgimi i tij përmes një mesazhi me tekst është ndoshta opsioni më i mirë (fatkeqësisht), por nuk jeni të kënaqur që hyrja të hyjë në historinë e tij të mesazheve për shkak të përvojës së kaluar. Përdorimi i këtij shërbimi për të dërguar hyrjen përmes një lidhjeje në një mesazh me tekst kënaq që të mos lejoni që hyrja të rri përgjithmonë në historinë e bisedës së tij.
- Ju ndonjëherë punoni në një zyrë që ka shumë qiramarrës të përbashkët që vijnë dhe shkojnë në të gjitha orët. Ka WiFi në dispozicion për përdorim, por fjalëkalimi ndërrohet çdo javë pasi ka pasur probleme me abuzimin. Shumë qiramarrës dërgojnë me email / tekst duke kërkuar fjalëkalimin WiFi edhe pse është në tavolinën e përparme sepse shumica nuk hyjnë përmes hyrjes kryesore të përparme. Duke përdorur këtë shërbim, menaxheri i zyrës mund të dërgojë fjalëkalimin WiFi përmes një lidhjeje në një email / përgjigje me tekst nuk lejon që fjalëkalimi të vonojë, dhe gjithashtu lejon marrësin të kopjojë menjëherë fjalëkalimin përmes një butoni kopjimi që është më pak i ngathët në pajisjet mobile.
- Një nga ofruesit tuaj të pritjes po ju kërkon detaje në lidhje me një server që keni raportuar se po tregon shenja të një hard drive që duket se po shkon keq. Disa nga informacionet që u duhen janë paksa të ndjeshëm - ju nuk doni që ato të qëndrojnë përgjithmonë në sistemin e biletave të palëve të treta që ata përdorin. Duke përdorur këtë shërbim, ju mund t'ua dërgoni informacionin teknikëve mbështetës pa e vendosur atë në sistemin e biletave. Meqenëse teknikë të shumtë mund të kenë nevojë t'i referohen informacionit shumë herë, vendosni leximin për të jetuar më të madh se 1 (dmth. Ndoshta 20) në mënyrë që mesazhi të mos fshihet gjatë rikthimit të parë.
- Ju duhet të dërgoni mesazhe private një përdoruesi tjetër në Reddit për t'i njoftuar numrin tuaj të telefonit në mënyrë që të mund t'ju telefonojnë. Reddit, si shumë ofrues të tjerë, ka rrjedhur informacione mbi përdoruesit në të kaluarën dhe ju nuk doni që numri juaj i telefonit thjesht të qëndrojë në bazën e të dhënave të Reddit për vite me radhë deri në rrjedhjen e radhës. Thjesht dërgoni numrin tuaj të telefonit përmes këtij shërbimi.
- Bashkëshorti juaj ju dërgon mesazhe ndërsa jeni në punë duke dëshiruar hyrjen në shërbim sepse shoqja e saj sapo provoi një program të ri që i kurseu para në faturën e saj elektrike dhe ajo dëshiron ta kontrollojë atë. Isshtë një menaxher i përbashkët i fjalëkalimit të familjes për të cilin ju e kujtoni, por ajo thjesht dëshiron që ju të dërgoni identifikimin. OMEMO është i punësuar për mesazhe të menjëhershme me bashkëshortin tuaj dhe prandaj ndiheni shumë të sigurt se transporti i mesazheve është i sigurt; megjithatë, vetë historia e bisedës ruhet e paskriptuar. Bashkëshorti juaj nuk është gjithmonë i kujdesshëm në lidhje me shkarkimet, postat elektronike, etj. Dhe faturat e shërbimeve janë paksa të ndjeshme pasi ato mund të përdoren për vjedhje të identitetit për të provuar vendbanimin. Ju mund t'i dërgoni asaj hollësitë e hyrjes duke përdorur këtë shërbim për të shmangur ruajtjen e një kopje në kompjuterin e saj.
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:
- Mos e përdorni këtë shërbim për ta bërë një transport të papërshtatshëm të mesazheve "më të sigurt". Për shkak se cilësimi i paracaktuar është të përfshijë fjalëkalimin në URL që mund të lexojë mesazhin, kushdo që ka lidhjen mund ta lexojë mesazhin. Siç u përmend më lart, çdo çështje e sigurisë / privatësisë e natyrshme për transportin e zgjedhur (dmth. Një tekst) trashëgohet kur përdorni këtë mjet. Kështu, për shembull, nëse nuk do ta konsideronit kurrë përdorimin e postës elektronike për të dërguar informacion specifik për shkak të natyrës së tij të ndjeshme, atëherë nuk duhet ta përdorni këtë shërbim për të "siguruar" atë pjesë të postës elektronike.
- Mos e përdorni këtë shërbim për të siguruar që nuk bëhet asnjë kopje e mesazhit. Vetëm për shkak se ne e fshijmë kopjen tonë të mesazhit të koduar menjëherë pas marrjes dhe e bëjmë më të vështirë kopjimin, nuk do të thotë që mesazhi nuk mund të kopjohet. Po sikur marrësi të fotografojë ekranin e tij? Po sikur ta shkruajnë mesazhin? Në fund të fundit, nëse marrësi mund ta lexojë mesazhin - mund të bëhet një kopje.
- Mos e përdorni këtë shërbim për të siguruar që një mesazh nuk mund të gjurmohet tek ju. Ky shërbim varet nga një tjetër ofrues i transportit të mesazheve (p.sh. email, chat, etj.) Për ta marrë mesazhin nga një pikë në tjetrën. Transporti i mesazheve i përdorur mund të gjurmojë shumë mirë mesazhin tek ju.
- Mos e përdorni këtë shërbim për të dërguar ndonjë gjë që dëshironi të mohoni të dërgoni. Thjesht sepse vetë mesazhi është fshirë, nuk do të thotë që lidhja që tregon mesazhin e fshirë të fshihet. Nëse i dërgoni një email mikut tuaj dhe një pjesë e këtij emaili ka një lidhje me një mesazh nga ky shërbim, një lexues i rastësishëm do ta dijë se kishte diçka tjetër në mesazh. Edhe nëse mesazhi i referuar në lidhje është zhdukur prej kohësh - është e qartë se diçka tjetër është dërguar dhe se ju është dërguar nga shoku juaj.
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:
- Butoni Kopjimi është hequr. Ky buton si parazgjedhje lejon marrësin të kopjojë të gjithë mesazhin në kujtesën e tyre.
- Butoni i Shkarkimit është hequr. Ky buton si parazgjedhje lejon marrësin të shkarkojë mesazhin si skedar teksti.
- Mundësia për të zgjedhur tekstin brenda kutisë së mesazhit hiqet.
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:
- Së pari, ne ruajmë sa më pak të jetë e mundur për sa më pak kohë të jetë e mundur në mënyrë që nëse serveri komprometohet ndonjëherë, çdo rrjedhje informacioni nuk do të dëmtojë përdoruesit tanë. Të gjitha mesazhet e ruajtura në bazën e të dhënave janë të enkriptuara pa asnjë mjet për t'i deshifruar ato. Nuk ka asgjë të ruajtur që lidh ndonjë mesazh me ndonjë nga përdoruesit tanë pasi që ne nuk mbledhim ndonjë informacion personal nga përdoruesit tanë. Të gjitha rekordet në bazën e të dhënave kanë një kohë skadence (TTL) që varion nga 1 minutë deri në 2 javë - pasi të ketë kaluar kjo kohë, rekordi fshihet automatikisht. Prandaj, shumica dërrmuese e informacionit që ka qenë ndonjëherë në bazën e të dhënave ishte fshirë tashmë shumë kohë më parë.
- Ne marrim një numër masash për të parandaluar kompromisin dhe përmbajmë çdo kompromis që ndodh:
- Web serveri, nginx , ekzekutohet në një enë të izoluar si një përdorues i pa privilegjuar pa hyrë në të shkruar asgjë tjetër përveç shkrimeve. Enë funksionon brenda kontekstit të vet SELinux duke parandaluar më tej çdo ndryshim të sistemit të skedarëve ose ikjen e lehtë nga kontejneri. Nuk ka mbështetje për PHP / ASP / JSP / etj. - thjesht duke shërbyer burimet statike.
- Kodi që ekzekutohet / api është shkruar në Go, gjë që duhet ta bëjë atë mjaft elastik ndaj dobësive të tejmbushjes së tamponëve (një vektor i zakonshëm i sulmit). Procesi Go shkon gjithashtu në një kontejner të izoluar si një përdorues i paprelegjuar pa hyrë në të shkruar asgjë tjetër përveç bazës së të dhënave. Enë funksionon brenda kontekstit të vet SELinux duke parandaluar më tej çdo ndryshim të sistemit të skedarëve ose ikjen e lehtë nga kontejneri. Baza e të dhënave, badgerdb , është një pjesë e procesit Go (pa varësi / proces të jashtëm të bazës së të dhënave).
- Rreziku kryesor i një kompromisi në server është që sulmuesi të mund të modifikojë skedarët në një mënyrë që do të rrezikonte privatësinë / sigurinë e përdoruesve tanë. Një proces i dedikuar monitoron të gjithë skedarët e faqeve të internetit për çdo ndryshim dhe na njofton menjëherë në rast se ka ndonjë ndryshim.
- E gjithë aksesi administrativ është i mbrojtur dhe i kufizuar në rrjetet e autorizuara.
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:
- Ndoshta rreziku më i madh dhe ai më unik për këtë shërbim është që përdoruesit tanë nuk do të përdorin gjykim të mirë kur bëjnë dallimin midis asaj që është e përshtatshme për të dërguar dhe asaj që nuk është e përshtatshme për të dërguar . Ndonjëherë dallimi midis "Unë jam komod duke dërguar me email këtë informacion - Unë thjesht dëshiroj që email-i të fshihet pasi të lexoj" dhe "Nuk jam i kënaqur me email këtë informacion - email-i është një transport i papërshtatshëm" mund të jetë mjaft delikat.
- Gjithmonë ekziston kërcënimi se operatorët e kësaj faqe në të vërtetë janë aktorë të këqij që joshin njerëzit për të përdorur shërbimin për të arritur një qëllim të errët përfundimtar. Ne hasim në një mënyrë të besueshme të besueshme - bëjeni gjithçka të lehtë dhe falas - merrni shumë njerëz që përdorin shërbimin - gjatë gjithë kohës me qëllim të mbrapshtë. Bwhahahahaha! Si mund të na besoni?
- Ekziston mundësia që kodi ynë të ketë gabime që ndikojnë në sigurinë ose ne thjesht nuk i kemi menduar mirë gjërat dhe të metat tona tani po i ekspozojnë përdoruesit tanë ndaj rrezikut të panevojshëm. Ne shpresojmë që jo - por nuk mund ta përjashtojmë.
- Ndryshe nga titanët e teknologjisë (p.sh. Google / Facebook / Whatsapp) që kanë terabitë të të dhënave të koduara vazhdimisht që rrjedhin brenda dhe jashtë rrjeteve të tyre të mëdha, ku është e lehtë të kesh komunikime private të përziera me trafikun tjetër, shërbime të centralizuara të pavarura (p.sh. Signal, Telegram, dhe ne) spikasim. Easyshtë e lehtë për një operator të rrjetit apo edhe një organizatë / qeveri të madhe për të parë që adresa IP xxxx po përdor shërbimin XYZ.
- Megjithëse nuk është specifik në të vërtetë për këtë faqe, meqenëse mund të përdoret kundër çdo faqe në internet, sulmet njeriu në mes (MITM) janë një shqetësim i vlefshëm .
Ç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ë:
- HSTS përdoret për të detyruar shfletuesit të lidhen vetëm përmes TLS. Serveri ynë është konfiguruar për të injoruar komunikimin jo-TLS, përveç për të ridrejtuar. Vetëm TLS 1.2 ose më të larta mbështeten.
- DNSSEC përdoret për të nënshkruar zonën e domenit tonë. Kjo mund të ndalojë mashtrimet e implementuara të MNTM-së nga DNS nëse përdoruesi po përdor një zgjidhës rekursiv të vetëdijshëm të DNSSEC.
- Ne përdorim një shërbim për të monitoruar autoritetet e çertifikatave që lëshojnë ndonjë çertifikatë të paautorizuar TLS duke iu referuar domenit tonë.
- Ne kemi botuar shtesa të shfletuesit për të mbështetur kriptimin e mesazheve duke përdorur kodin e ruajtur në pajisjen e përdoruesit përfundimtar.
Ç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:
- Përdoruesi përfundimtar zgjedh një fjalëkalim ose një gjenerohet automatikisht
- 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 )
- Gjenerohet një kripë 32 bajtëshe
- Një çelës rrjedh nga kripa dhe fjalëkalimi
- Gjenerohet një vektor inicializimi 12 bajtësh (IV)
- Mesazhi është i koduar duke përdorur tastin + IV
- 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.)
- Serveri kthen një ID të rastësishme duke iu referuar mesazhit
- 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)
- 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
- Marrësi nxirret nëse dëshiron të deshifroj dhe shikojë mesazhin
- Shfletuesi bën një kërkesë duke specifikuar ID-në e mesazhit
- 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)
- 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ë
- Marrësi do të deshifrojë mesazhin me fjalëkalimin (dhe do të kërkohet për fjalëkalimin nëse nuk është në URL)
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:
- Kriptoni fjalëkalimin në një mesazh me cilësimet e paracaktuara dhe dërgojeni këtë lidhje marrësit.
- 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.
- 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.
- 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.
Ky shërbim nuk e jep lidhjen te marrësi?
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 i urrejmë CAPTCHA-të - ato marrin kohë dhe janë të bezdisshme
- Javascript i palës së tretë mund të jetë invazive për privatësinë dhe sigurinë
- Drejtimi i CAPTCHA-s tonë do të thotë që po regjistrohemi për një lojë të pafund të prishjes së urinës
- Përfundimisht njerëzit mund të dëshirojnë të jenë në gjendje të ndërveprojnë me këtë shërbim përmes API
- Rritja e numrit të përsëritjeve të kërkuara PBKDF2 / SHA-256
Të gjitha mesazhet mund të merren vetëm disa herë - një atribut jo tërheqës për spammers pasi ata mbështeten në dërgimin e shumë mesazheve. Meqenëse një spammer do të duhet të krijojë shumë mesazhe për çdo fushatë të dhënë të bezdisshme - ne kemi vendosur ta bëjmë këtë detyrë aq të shtrenjtë në mënyrë kompjuterike sa ta bëjmë abuzimin e këtij shërbimi për postë të pavlefshme një përpjekje jo tërheqëse. Kjo arrihet duke ndjekur gjurmët e rrjeteve që postojnë mesazhe - të matura në terma të rikuperimeve totale të mundshme. Vetë informacioni i rrjetit është shkëputur në mënyrë të sigurt në mënyrë që të mos mund të nxjerrim përfundimin e rrjetit të vërtetë nga hasha. Ndërsa një rrjet i caktuar poston më shumë mesazhe, ne rrisim numrin e përsëritjeve PBKDF2 / SHA-256 të kërkuara për të postuar mesazhin tjetër. Kjo shumë shpejt rezulton në shumë kohë të CPU-së që kërkohet vetëm për të postuar një mesazh të vetëm. Shpresojmë se kjo metodë do të jetë adekuate për të frenuar abuzimin me spam dhe në të njëjtën kohë, nuk do të ndikojë në përdoruesit e vërtetë. - Mblidhni raporte të padëshiruara nga përdoruesit kur ata marrin një mesazh
Ekziston një buton "Raporto Spam" pikërisht poshtë mesazhit kur një përdorues merr një mesazh. Nëse një mesazh është i padëshiruar, shpresojmë që disa do të marrin 3 sekondat e nevojshme për të klikuar atë buton. Kur marrim një raport të bezdisshëm, ai na paralajmëron dhe gjithashtu faktorë që ndikojnë në përsëritjet e kërkuara PBKDF2 / SHA-256 për një rrjet të caktuar.
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.