Dažnai užduodami klausimai

Kodėl ši svetainė blogai išversta?

Atsiprašome, tačiau dabartiniai autoriai kalba tik angliškai. Mums reikia pagalbos išverčiant šį projektą į kitas kalbas. Mes naudojame mašininį vertimą kaip paprastą ir nebrangią priemonę, kad ši paslauga būtų prieinama žmonėms, nemokantiems anglų kalbos. Rezultatai paprastai yra priimtini, tačiau gali sukelti keistą formuluotę ar net visiškai netikslią informaciją. Galite padėti mums patobulinti patirtį visiems - pateikite teisingą vertimą .

Kiek saugi ši paslauga?

Mes ėmėmės daug veiksmų, kad ši paslauga būtų saugi pagal paskirtį . Prieš pradėdami šiuos veiksmus, svarbu suprasti šiuos dalykus:

Mūsų tikslas yra pasiūlyti šią paslaugą taip, kad būtų galima pagerinti jūsų privatumą ir saugumą. Štai keletas veiksmų, kurių ėmėmės, kad apsaugotume jūsų informaciją:

Kodėl čia gavau nuorodą su galimybe iššifruoti pranešimą?

Atsiprašome, jei šiame vertime yra klaidų. Ši paslauga tiesiog perduoda užšifruotą pranešimą iš vieno taško į kitą ir jūs esate gavėjas. Pranešimas netrukus bus ištrintas. Šios paslaugos operatoriai niekaip negali perskaityti pranešimo turinio. Paprastai kažkas naudojasi šia paslauga, kai nenori, kad pranešimo turinys liktų įvairiose duomenų bazėse/įrenginiuose/paslaugose/failais/ir tt. kaip būdinga siunčiant el. laišką/momentinį pranešimą/tekstą/ir pan. Jei nuspręsite iššifruoti, atminkite šiuos dalykus:

Ar ištrinate viską, kas pateikta šioje svetainėje?

Tikrai mūsų šiukšliadėžės logotipas ... viskas netrukus ištrinama. Viskas ištrinama automatiškai - ji įrašoma į serverį. Pagalvokite taip - pateikiama dviejų tipų informacija:

Pranešimų atveju galite valdyti, kada juos ištriname, nurodydami: Pagal numatytuosius nustatymus viskas, kas susiję su pranešimu, ištrinama po to, kai ji gaunama vieną kartą arba sulaukia 1 savaitės - atsižvelgiant į tai, kas įvyksta anksčiau. Kai reikia ištrinti visą kitą informaciją, būdingą bet kokiam žiniatinklio pateikimui (pvz., Jūsų IP adresas ir pan.), Mes nesuteikiame jums jokios kontrolės, kada ir kaip ji ištrinama - mes tiesiog ištriname ją kas 24 valandas .

Kodėl verta naudotis šia paslauga?

Ši paslauga yra priemonė, padedanti padaryti siunčiamus/gaunamus pranešimus mažiau pastovius. Didžioji dalis to, ką bendraujate internete (pokalbiai, tekstai, el. Laiškai ir kt.), Yra saugoma ir retai ištrinama. Dažnai, kai ką nors ištrinate, jis iš tikrųjų nėra ištrinamas, o pažymimas kaip ištrintas ir jums nebeparodomas. Jūsų bendra informacija kasmet kaupiama duomenų bazėse ir įrenginiuose, kurių negalite valdyti. Neišvengiamai įsilaužta į vieną ar kelias organizacijas/žmones/įrenginius, kuriuose saugomas jūsų ryšys, ir nutekinama jūsų informacija. Ši problema yra tokia paplitusi, kad dabar yra daug svetainių, kurios stebi organizacijas, kurios buvo pažeistos ir nutekino vartotojų duomenis. Nuolatiniai šifruoti laikini pranešimai yra paprastas sprendimas, padedantis padaryti kai kuriuos jūsų ryšius mažiau nuolatinius. Kiekvienos į šią svetainę pateiktos žinutės galiojimo laikas yra nuo 1 minutės iki 2 savaičių. Praėjus šiam laikui, pranešimas ištrinamas. Be to, numatytasis nustatymas yra ištrinti bet kokį pranešimą, kai gavėjas jį atsiima. Be to, visi pranešimai yra šifruojami iš jūsų prietaiso iki gavėjo įrenginio. Pagrindinis viso šifravimo tikslas yra panaikinti galimybę skaityti bet kokius pateiktus pranešimus ir taip panaikinti kai kuriuos pasitikėjimo reikalavimus. Galutinis rezultatas yra tas, kad dabar lengva siųsti užšifruotą pranešimą per paprastą nuorodą. Šis pranešimas ištrinamas netrukus po išsiuntimo arba jį atsiuntus. Jums nereikia įdiegti/konfigūruoti specialios programinės įrangos. Jums nereikia susikurti paskyros ar pateikti jokios asmeninės informacijos. Gavėjas neprivalo būti jūsų kontaktuose ar net žinoti apie šią paslaugą - vienintelis reikalavimas, kad jis galėtų spustelėti nuorodą.

Ar tai pranešimų paslauga?

Ne. Ši paslauga skirta papildyti esamas pranešimų siuntimo paslaugas, pvz., Momentinių pranešimų/el. Pašto/teksto/ir kt. pridedant galimybę užkirsti kelią išsiųstų pranešimų ilgam saugojimui. Gautos nuorodos gavėjui nepristatome .

Kokie yra numatyto naudojimo atvejai?

Taigi, kokie yra kai kurie scenarijai, kai tikslinga naudotis šia paslauga? Nors kiekvienas turi skirtingus poreikius ir reikalavimus, susijusius su jų privatumu ir saugumu, aš asmeniškai radau tinkamus naudojimo atvejus:

Kam ši paslauga neturėtų būti naudojama?

Ši paslauga neturėtų būti naudojama labai jautriai informacijai dėl visų šiame DUK paaiškintų priežasčių. Žemiau pateikiami keli pavyzdžiai, ko negalima daryti:

Kodėl gi ne tik naudojant PGP/Signal/OMEMO/Matrix/etc.

Jei žinote asmenį, kuriam norite siųsti saugius laikinus pranešimus, dažnai juos siųskite, tikitės į pokalbį panašios sąsajos ir (arba) galite tikėtis, kad gavėjas turės reikiamą programinę įrangą ir žinos, kaip ja naudotis, ši svetainė tikriausiai nėra ta geriausias sprendimas. Yra puikių galimybių, kurios yra atvirojo kodo, palaiko E2EE, o ne žiniatinklio, ir net kai kurios, pavyzdžiui, „ Signal“ , taip pat palaiko laikinus pranešimus. Aš asmeniškai naudoju privatų XMMP serverį ir OMEMO, kad galėčiau kalbėtis su artimais draugais ir šeima. Naudojimasis šia svetaine gali būti optimalus tik tuo atveju, jei nežinote, kokią programinę įrangą gavėjas naudoja, nežinote savo telefono numerio/kontaktinės rankenos, nežinote jų techninių įgūdžių (bet manote, kad jie gali spustelėti nuorodą), arba tiesiog norite, kad jūsų siunčiamas pranešimas nepatektų į pagrindinį ryšio transportą.

Kokie reikalavimai egzistuoja?

Reikalinga moderni ir naujausia interneto naršyklė, tinkamai įgyvendinanti standartus, įskaitant „Web Crypto“ API. Pavyzdžiai: „Chrome“, „Firefox“, „Edge“ ir „Safari“ (maždaug 2020 m. Arba vėliau).

Ar gavėjas gali padaryti pranešimo kopiją?

Taip. Nors gautas pranešimas gali ištrinti save, gavėjas vis tiek gali jį peržiūrėti. Bet kuriuo metu, kai imtuvas gali visiškai peržiūrėti pranešimą, galima padaryti jo kopiją - tai taikoma visiems ryšiams. Yra galimybė gavėjui apsunkinti kopijos darymą. Šiuo atveju įgyvendinamos trys kopijavimo kliūtys:

Tačiau šios apsaugos nuo kopijavimo yra silpnos, nes jas galima apeiti. Be to, gavėjas visada gali tiesiog padaryti ekrano kopiją ar pranešimo nuotrauką.

Ar renkama kokia nors asmeninė informacija?

Mes nepalaikome vartotojų paskyrų (ty vartotojo vardo/slaptažodžio). Mes nerenkame jokios informacijos, kuri galėtų jus identifikuoti (ty vardas/adresas/el. Paštas/telefonas). Gali būti, kad jūsų siunčiamame pranešime gali būti tam tikros asmeninės informacijos, tačiau ji yra užšifruota ir mes negalime jos perskaityti. Jei reikia išsamios informacijos, peržiūrėkite mūsų privatumo politiką.

Kokia informacija registruojama?

Mūsų žiniatinklio serveris saugo iki 24 valandų įprastą žurnalo formatą bet kokioje žiniatinklio veikloje. Tai apima viso HTTP klientų IP adreso registravimą. Po 24 valandų ši užregistruota informacija automatiškai ištrinama. Visos užklausos, išsiųstos /api, yra POST., Tai reiškia, kad žiniatinklio serveris niekada neregistruoja jokios konkrečios žinutės informacijos. Be to, visa duomenų bazėje išsaugota informacija yra veiksmingai registruojama. Visi duomenų bazės įrašai, įskaitant anoniminius ir maišytus IP adresus, turi galiojimo laiką (TTL), po kurio jie automatiškai ištrinami. TTL galiojimo laikas svyruoja nuo 1 minutės iki 2 savaičių.

Ką darote, kad apsaugotumėte serverius?

Serverio saugumas yra akivaizdus rūpestis. Yra dvi pagrindinės sritys, į kurias mes sutelkiame dėmesį, kad ji būtų saugi:

Kokie pavojai saugumui kyla naudojant šią svetainę?

Prieš konkrečiai sprendžiant kai kurias iš šių rizikų, manau, kad pusiau trumpa analogija galėtų padėti apibendrinti bet kokios interneto ryšio riziką. Įsivaizduokite, kad bet kuri sistema yra tokia pat saugi kaip silpniausia grandinės grandis. Dabar įsivaizduokite scenarijų, kai uždaroje patalpoje yra du žmonės, neturintys galimybės nieko matyti, girdėti ar įrašyti. Vienas perduos pranešimą kitam, kurį perskaitęs jis sudegins. Jei kas nors už kambario ribų nori gauti pranešimą, kuris jau buvo perduotas, tai bus sunku. Kokia yra silpniausia nuoroda norint gauti pranešimą? Nėra tiek daug nuorodų, iš kurių galima rinktis - tai gana trumpa grandinė. Dabar įsivaizduokite, kad kai siunčiate pranešimą internete, kad grandinėje yra bent milijonas grandžių - daugelis jų silpnos, daugelis jų visiškai nepriklauso nuo jūsų - ir tai yra realybė.

Šifravimas gali labai padėti išspręsti pirmiau minėtą milijono nuorodų problemą ir nesunku susimąstyti, kad gerai suplanuotos E2EE sistemos siūlo galutinį sprendimą. Tačiau toks mąstymas gali sukelti nemalonumų, nes užpuolikas paprastai tiesiog seka silpnesnes sistemos grandis. Pvz., Tikriausiai daug lengviau perimti telefoną ar kompiuterį ir nustatyti įvesties registratorių, kad jis tiesiog perskaitytų viską, ką įvedate, nei sklaidyti užšifruotus pranešimus per laidą. Esmė ta, kad jei man būtų pavesta perduoti gyvybiškai svarbią/kritinę paslaptį, elektroninius ryšius naudočiau tik kaip paskutinę priemonę.

Taigi naudojant bet kokius ryšius kyla pavojus saugumui, tačiau jūs vis tiek naudojate žiniatinklio naršyklę bankininkystei, daiktų pirkimui, el. Tikrai kyla klausimas ... kokia saugumo rizika yra pusiau būdinga šiai svetainei? Į galvą ateina keletas:

Ką jūs darote dėl žmogaus viduryje (MITM) atakų?

Visi interneto svetainių vartotojai gali tapti MITM atakos auka - šiuo atžvilgiu ši svetainė niekuo nesiskiria nuo visų kitų žiniatinklio svetainių. MITM ataka yra tada, kai užpuolikas gali perimti ir modifikuoti ryšius tarp vartotojo naršyklės ir svetainės žiniatinklio serverio. Tai leidžia užpuolikui pakeisti bet kurį svetainės kodą/turinį, o galutiniam vartotojui vis tiek atrodo, kad yra ta svetainė, prie kurios jie yra įpratę. Imamės tam tikrų priemonių, kad apsunkintume MITM ataką:

Tačiau MITM ataka vis dar įmanoma, ypač jei užpuolikas kontroliuoja tinklo/viešojo rakto infrastruktūrą, kaip tai būtų padaryta didelėms/galingoms organizacijoms ar vyriausybėms. Mes siūlome naršyklės plėtinius, kurie gali padėti sumažinti kai kurias MITM rizikas.

Kokius pranašumus siūlo naršyklės plėtiniai?

Siūlome naršyklės plėtinius , kurie suteikia papildomo patogumo ir papildomo saugumo. Paprasčiau tariant ... Plėtiniai leidžia greičiau ir lengviau siųsti laikinus pranešimus. Tam tikras saugumas taip pat įgyjamas, nes visas kodas, naudojamas šifruoti ir paruošti pranešimą, yra saugomas plėtinyje. Kadangi kodas saugomas vietoje, tai suteikia siuntėjui tam tikrą apsaugą nuo MITM atakų . Tačiau verta pažymėti, kad nors plėtiniai labiau apsaugo nuo MITM atakos, kuri kenkia pranešimo turiniui, MITM ataka vis tiek gali būti veiksminga (ty nustatyti siuntėjo IP adresą, jei nenaudojate TOR/VPN/ir tt).

Kaip galiu tiksliai žinoti, kad viskas, kas pateikta, yra užšifruota?

Skirtingai nuo daugelio kitų populiarių šifruotų (E2EE) pokalbių klientų, gana paprasta tiksliai pamatyti, kas mums siunčiama, kai siunčiate pranešimą. Žemiau pateiktame vaizdo įrašo mokyme parodyta, kaip patvirtinti, kad mes niekaip negalime iššifruoti į serverį siunčiamų pranešimų.

Be to, jei gerai pagalvotumėte, kol nesame kokia nors slapta agentūra, bandanti rinkti neskelbtinus pranešimus, mums nėra jokios naudos, jei galime iššifruoti pranešimus, nes turėdami tokią galimybę mes tik sukuriame problemų. Mes net nenorime saugoti pranešimų - tačiau būtina juos perduoti.

Kaip šioje svetainėje veikia visapusiškas šifravimas?

Šiuo metu mes naudojame simetrinį šifravimą (AES-GCM 256bit) su raktais, gautais iš slaptažodžių (mažiausiai 200 000 PBKDF2 + SHA-256 iteracijų). Asimetrinis šifravimas nenaudojamas, nes egzistuoja reikalavimai 1) siuntėjui, inicijuojančiam ryšį 2) siuntėjui ir gavėjui tuo pačiu metu neprisijungus prie interneto ir 3) nėra informacijos apie gavėją ir 4) mes stengiamės, kad viskas būtų paprasta, o raktų valdymas yra paprastas. sudėtinga. Standartinė žiniatinklio kriptografinė API naudojama visoms kriptografinėms funkcijoms, įskaitant RNG. Iš esmės štai kas atsitinka:

  1. Galutinis vartotojas įveda tekstinį pranešimą ir gali nurodyti kelias parinktis, įskaitant slaptažodį.
  2. Norint gauti raktą, sukuriamas saugus slaptažodis. Jei vartotojas nurodė slaptažodį, jis derinamas su sugeneruotu slaptažodžiu.
  3. Norint gauti reikiamų PBKDF2 + SHA-256 pakartojimų skaičių, iškviečiamas API skambutis ( šis veiksmas reikalingas norint kontroliuoti šlamštą )
  4. Sukuriama 32 baitų druska
  5. Raktas gaunamas iš druskos ir slaptažodžio
  6. Sukuriamas 12 baitų inicializacijos vektorius (IV)
  7. Pranešimas užšifruojamas naudojant raktą ir IV.
  8. Į serverį siunčiamas iteracijų skaičius, druska, IV ir šifruotas tekstas (kartu su kita informacija, pvz., TTL, RTL ir kt.)
  9. Serveris pateikia atsitiktinį ID, nurodantį pranešimą
  10. Tada naršyklė pateikia galutiniam vartotojui nuorodą, kurią vėliau galima bendrinti su gavėju. Visa informacija apie pranešimą saugoma URL maišos komponente ir todėl nėra siunčiama į serverį standartinės GET užklausos metu.
  11. Nuoroda bendrinama su gavėju.
  12. Gavėjas paraginamas, jei nori iššifruoti ir peržiūrėti pranešimą.
  13. Kai gavėjas nusprendžia peržiūrėti pranešimą, naršyklė pateikia užklausą, nurodydama pranešimo ID.
  14. Jei siuntėjas reikalauja užpildyti CAPTCHA, gavėjas nukreipiamas į kitą URL, kad įrodytų, jog yra žmogus (kai jis praeina, jis nukreipiamas atgal).
  15. Serveris siunčia užšifruotą pranešimą ir šiuo metu pagal numatytuosius nustatymus ištrins pranešimą, jei tiesioginis skaitymas (RTL) yra vienas.
  16. Gavėjas iššifruos pranešimą ir, jei reikia, bus paprašytas įvesti slaptažodį.
Ši sąranka yra labai paprasta ir siūlo šifruoti pranešimus iš siuntėjo įrenginio į gavėjo įrenginį, tačiau, žinoma, trūksta kai kurių asimetrinio šifravimo teikiamų garantijų. Kiekvienas, turintis nuorodą, gali atidaryti pranešimą pagal numatytąjį scenarijų - tai pabrėžia, kad svarbu naudoti tinkamą nuorodos perdavimą (pvz., El. Paštą/pokalbį/tekstą/ir tt) - sprendimas paliekamas siuntėjui.

Iššifravimo raktas gali būti URL?

Taip. Jei slaptažodis nenaudojamas, pranešimą gali perskaityti visi, turintys nuorodą. Tai akivaizdžiai daro įtaką saugumui, nes jei nuorodos siuntimo metodas gali būti perimtas, tada pranešimas gali būti perimtas. Visi šios problemos sprendimo būdai apima papildomus veiksmus ir sudėtingumą, kurie turi įtakos vartotojo patirčiai (ty prieš išsiunčiant pranešimą, viskas turi būti nustatyta abiejuose galuose). Galų gale, jei dvi šalys dažnai siunčia pranešimus viena kitai, egzistuoja geresni sprendimai, darant prielaidą, kad abi šalys gali tvarkytis naudodami tuos sprendimus.

Bet iššifravimo raktas neturi būti URL?

Teisingai. Pranešimo autorius gali nurodyti slaptažodį, kad apsaugotų pranešimą. Šis slaptažodis naudojamas išvesti slaptą raktą, kuris nėra URL dalis . Jei naudojamas saugus slaptažodis ir jis saugiai perduodamas gavėjui (arba jis jau jį žino), tai apsaugo nuo perėmimo. Tačiau trūkumas yra tas, kad gavėjas turi žinoti ir teisingai įvesti slaptažodį. Štai vienas būdas nusiųsti slaptažodį gavėjui, kuris suteikia tam tikrą apsaugą nuo perėmimo:

  1. Užšifruokite slaptažodį pranešime su numatytais nustatymais ir nusiųskite šią nuorodą gavėjui.
  2. Kai gavėjas spustelėja nuorodą ir iššifruoja pranešimą, jis žino, kad niekas kitas negavo slaptažodžio prieš juos, nes žinutė, kurioje yra slaptažodis, ištrinama. Tačiau, jei yra aktyvi MITM ataka arba jei jūsų ar gavėjo įrenginys buvo pažeistas, vis tiek įmanoma, kad kita šalis gali gauti slaptažodį.
  3. Su gavėju patvirtinkite, kad jis sėkmingai gavo slaptažodį. Pvz., Jei gavėjas jus informuoja, kad kai jie atvyko gauti slaptažodžio, kad pranešimas jau buvo ištrintas, žinote, kad kažkas kitas gavo slaptažodį prieš gavėją, todėl slaptažodis yra pažeistas ir neturėtų būti naudojamas.
  4. Naudodami slaptažodį, kurį gavėjas patvirtino turintis, dabar galite išsiųsti pranešimą naudodami tą patį šifravimo slaptažodį.

Tai teisinga - mes sukuriame nuorodą ir paliekame siuntėjui, kaip geriausiai ją pristatyti gavėjui. Šios paslaugos tikslas yra suteikti galimybę pasiūlyti mažiau pastovumo esamuose pranešimų perdavimuose, pvz., El. Todėl tikimasi, kad mūsų sukurta nuoroda, nurodanti į laikiną pranešimą, bus išsiųsta per esamą pranešimų perdavimą. Tai turi saugumo problemų, kurias vartotojai turėtų suprasti. Imkime SMS žinutes kaip pavyzdį, nes tai yra gana nesaugus bendravimo būdas. Kai naudojatės šia paslauga laikinam pranešimui siųsti su numatytais nustatymais, visi nuorodą turintys asmenys gali perskaityti pranešimą ir nesiūloma jokia apsauga nuo perėmimo. Ši paslauga vis dar teikia laikiną ryšį, kuris gali pagerinti privatumą ir saugumą. Be to, slaptažodis gali būti naudojamas apsaugai nuo perėmimo.

Kaip galiu kiek įmanoma apsaugoti savo privatumą naudodamasis šia paslauga?

Kaip aptarta kitur šiame DUK, nors mes jau daug darome, kad apsaugotume jūsų privatumą ir nors nerenkame jokios asmeninės informacijos, tam tikrą su žurnalu susijusią informaciją pateikiame ir renkame mes ir kiti, jums naudojant žiniatinklio naršyklę. Tačiau yra keletas būdų, kaip dar labiau apsaugoti jūsų privatumą. Vienas iš būdų, kurį galima laisvai naudoti, remiantis atvirojo kodo programine įranga ir kuris veikia gana gerai, yra naudoti „ Tor“ naršyklę . Ši naršyklė skirta apsaugoti jūsų privatumą keliais lygiais, įskaitant „ Tor“ tinklo naudojimą . Mūsų svetainė jau pasiekiama per „Tor“ svogūnų tinklą, o tai reiškia, kad norint patekti į mūsų svetainę per „Tor“ nereikia naudoti išėjimo mazgo, o tai neleidžia kam nors pasiklausyti išėjimo mazgo srauto . Tačiau atminkite, kad net ir tokiu atveju jūsų IPT gali matyti, kad naudojate „Tor“, nors ir ne dėl ko. Jūs netgi galite prisijungti prie VPN ir paleisti „Tor“ naršyklę, kad gautumėte du anonimiškumo sluoksnius; tačiau atminkite, kad jūsų IPT vis tiek gali matyti, kad šiuo atveju naudojate VPN, nors ir ne dėl ko. Jei nenorite, kad jūsų IPT žinotų, kokius protokolus naudojate, galite prisijungti prie didelio viešojo „WiFi“ tinklo, pvz., Bibliotekos, mokyklos ir pan., Tada naudoti „Tor“ naršyklę.

Ką daryti, jei nepasitikiu JAV?

Mūsų serveriai yra JAV. Be to, mūsų CDN tiekėjas „Cloudflare“ yra JAV įsikūrusi bendrovė. Mes bandėme pašalinti poreikį pasitikėti mumis ar šalimi, kurioje yra mūsų serveriai vien todėl, kad nerenkame asmeninės informacijos, negalime iššifruoti jokių pranešimų ir viskas ištrinama netrukus po to, kai ji gaunama. Tačiau mes galime suprasti tam tikrą nepasitikėjimą, nes jis pagrįstas žiniatinkliu ir ypač jei gyvenate tam tikrose šalyse. Planuojame Islandijoje ir Šveicarijoje pasiūlyti variantų žmonėms, kuriems sunku pasitikėti JAV. Praneškite mums, ar tai taikoma jums, nes mes nebūsime motyvuoti siūlyti alternatyvų, nebent yra reali paklausa.

Ką darote, kad išvengtumėte šlamšto?

Kiekvieną kartą, kai leidžiate kam nors paskelbti pranešimą, kurį galima perduoti per nuorodą, pakviečiate nepageidaujamo e. Pašto platintojus. Šios problemos sprendimas nėra visiškai paprastas. Mes nenorime įkelti trečiosios šalies CAPTCHA kaip pranešimo siuntimo proceso dėl kelių priežasčių:

Galime išspręsti API problemą naudodami tam tikrą API raktų sistemą, tačiau tada turime surinkti naudotojo informaciją, kurios nenorime daryti. Be to, kas neleidžia šlamšto siuntėjams gauti daug API raktų? Negalime išnagrinėti pranešimų, kad nustatytume jų šlamštą (o tai geriausiu atveju yra labai problematiška), nes, be pranešimų šifravimo, mes turime praktinę pranešimų turinio politiką. Atsižvelgdami į šiuos reikalavimus, mes naudojame du būdus, kaip užkirsti kelią šlamštui: Jei žinote, kad šlamšto siuntėjai piktnaudžiauja šia paslauga, pateikite pranešimą apie piktnaudžiavimą .

Kodėl yra galimybė reikalauti, kad gavėjas užpildytų CAPTCHA?

Nors tiesa, kad mums nepatinka CAPTCHA, mes pripažįstame, kad jie tarnauja tam tikram tikslui ir turi laiką ir vietą (bent jau kol kas). Tai paprastas būdas siuntėjui įgyti tam tikrą garantiją, kad gavėjas yra žmogus ir kad automatiniai procesai neprieina pranešimo.

Kas teikia šią paslaugą ir kodėl ji nemokama?

Mes esame tik pora vaikinų, kurie kartais susidūrė su keblumu, kad neturi gerų galimybių apsaugoti savo privatumą. Dažnai tai lėmė bendravimas su draugais ir šeimos nariais, kurie nebuvo labai atsargūs, kaip elgėsi su savo prietaisais ir informacija. Kitais atvejais tai atsitiko naudojant žiniatinklio forumus, tokius kaip „Reddit“, arba naudojant žiniatinklio palaikymo sistemas. Radome keletą žiniatinklio laikinų pranešimų sprendimų, tačiau nė vienas nesiūlė E2EE, o tai reiškia, kad negalime jais pasitikėti. Taigi mes tiesiog sukūrėme savo sprendimą ir nusprendėme jį atiduoti, kad kiti galėtų iš to gauti naudos.

Kaip galiu pasitikėti atsakymais į aukščiau pateiktus klausimus?

Tikrai neturėtumėte pasitikėti jokia svetaine vien todėl, kad joje sakomi tam tikri dalykai - paprastai gera mintis patikrinti bet kokius teiginius. Mes bandėme pašalinti reikalavimą kuo labiau pasitikėti mumis naudodami visapusišką šifravimą. Pavyzdžiui, gana lengva patikrinti, ar negalime perskaityti jokių pranešimų, nes jie yra užšifruoti . Mes taip pat išlaikėme labai paprastą „JavaScript“ kodą, kuriame veikia ši svetainė , kad ją būtų lengva skaityti ir suprasti. Padarę visą kodą atvirą šaltinį, žmonės gali patikrinti, kas veikia; tačiau atminkite, kad nėra jokio būdo iš tikrųjų patikrinti, kas veikia serveryje. Nors tiesa, kad didžioji dalis pasitikėjimo reikalavimo pašalinama naudojant visapusišką šifravimą, vis dėlto tai yra veiksnys, kurį mūsų vartotojai daug laiko, kai nusprendžia naudotis šia paslauga.