Vrae wat gereeld gevra word

Waarom word hierdie webwerf swak vertaal? ⎃

Jammer, maar die huidige skrywers praat net Engels. Ons het hulp nodig om hierdie projek in ander tale te vertaal. As 'n eenvoudige en goedkoop manier om hierdie diens beskikbaar te stel vir mense wat nie Engels praat nie, gebruik ons masjienvertaling. Die resultate is gewoonlik aanvaarbaar, maar kan lei tot vreemde bewoording of selfs onakkurate inligting. U kan ons help om die ervaring vir almal te verbeter - stuur die korrekte vertaling in .

Hoe veilig is hierdie diens?

Ons het baie stappe gedoen om hierdie diens veilig te maak vir die beoogde gebruik daarvan . Voordat ons hierdie stappe gaan, is dit belangrik om die volgende te verstaan:

Ons doel is om hierdie diens aan te bied op 'n manier wat u bied om u privaatheid en veiligheid te verbeter. Hier is 'n paar stappe wat ons gedoen het om u inligting veilig te beskerm:

Waarom het ek 'n skakel hier ontvang met die opsie om 'n boodskap te ontsyfer?

Ons vra om verskoning as daar foute in hierdie vertaling is . Hierdie diens gee eenvoudig 'n geënkripteerde boodskap van een punt na 'n ander en u is die ontvanger. Die boodskap sal binnekort uitgevee word. Die bestuurders van hierdie diens het geen manier om die inhoud van die boodskap te lees nie. Gewoonlik gebruik iemand hierdie diens as hulle nie wil hê dat die inhoud van 'n boodskap binne verskillende databasisse / toestelle / dienste / lêers / ens moet bly nie. soos gewoonlik by die stuur van 'n e-pos / kitsboodskap / sms / ens. As u besluit om te ontsyfer, moet u die volgende in gedagte hou:

Verwyder u alles wat op hierdie webwerf gestuur is?

Getrou aan ons asblik-logo ... alles word uitgevee kort nadat dit ontvang is. Skrapping van alles word outomaties - dit word op die bediener geskryf. Dink so daaraan: daar word twee klasse inligting ingedien:

In die geval van boodskappe, kan u bepaal wanneer ons dit verwyder deur te spesifiseer: Standaard word alles oor 'n boodskap verwyder nadat dit een keer opgespoor is of 1 week oud is - wat ook al eerste gebeur. As dit gaan oor die verwydering van al die ander inligting wat inherent is aan die indiening van iets op die internet (bv. U IP-adres, ens.), Gee ons u geen beheer oor wanneer of hoe dit verwyder word nie; ons verwyder dit alles elke 24 uur .

Waarom hierdie diens gebruik?

Hierdie diens is 'n hulpmiddel om boodskappe wat u stuur / ontvang minder permanent te maak. Die meeste van wat u op die internet kommunikeer (geselsies, tekste, e-posse, ens.) Word gestoor en selde verwyder. Dikwels, as u iets uitvee, word dit nie eintlik uitgevee nie, maar eerder as uitgevee en nie meer aan u vertoon nie. U totale kommunikasie versamel jaar na jaar in databasisse en op toestelle waaroor u geen beheer het nie. Onvermydelik word een of meer van die organisasies / mense / toestelle wat u kommunikasie stoor, gekap en u inligting word uitgelek. Hierdie probleem is so deurdringend dat daar tans baie webwerwe is wat die organisasies dophou wat gekompromitteer is en gebruikersdata uitgelek het. End-to-end geïnkripteer tydelike boodskappe is 'n eenvoudige oplossing om sommige van u kommunikasie minder permanent te maak. Elke boodskap wat na hierdie webwerf gestuur word, het 'n tydsleef wat wissel van 1 minuut tot 2 weke - sodra die tyd verby is, word die boodskap verwyder. Verder is die standaardinstelling om enige boodskap te verwyder sodra die ontvanger dit opgespoor het. Daarbenewens word alle boodskappe vanaf u toestel geënkripteer tot by die ontvanger se toestel. Die hoofdoel met die gebruik van end-tot-end-enkripsie is om ons vermoë om enige ingediende boodskappe te lees, te verwyder en sodoende 'n deel van die vertrouensvereiste te verwyder. Die uiteinde is dat dit nou maklik is om 'n geïnkripteerde boodskap via 'n eenvoudige skakel te stuur. Die boodskap word kort na versending of na herwinning uitgevee. U hoef nie spesiale sagteware te installeer of op te stel nie. U hoef nie 'n rekening te skep of enige persoonlike inligting te verskaf nie. Die ontvanger hoef nie in u kontakte te wees of selfs van hierdie diens te weet nie - die enigste vereiste dat hulle op 'n skakel kan klik.

Is dit 'n boodskapdiens?

Nee. Hierdie diens is ontwerp om bestaande boodskapdienste aan te vul soos kitsboodskappe / e-pos / sms / ens. deur die moontlikheid by te voeg om te voorkom dat gestuurde boodskappe lank gestoor word. Ons lewer nie die gegenereerde skakel aan die ontvanger nie .

Wat is die beoogde gebruiksgevalle?

Wat is dan 'n paar scenario's waar dit gepas is om hierdie diens te gebruik? Alhoewel almal verskillende behoeftes en vereistes het wat hul privaatheid en veiligheid betref, het ek die volgende scenario's as toepaslike gebruiksgevalle gevind:

Waarvoor moet hierdie diens nie gebruik word nie?

Hierdie diens moet om al die redes wat in hierdie vrae uiteengesit word, nie gebruik word vir baie sensitiewe inligting nie. Hieronder is 'n paar voorbeelde van wat u nie moet doen nie:

Waarom nie net PGP / Signal / OMEMO / Matrix / ens. Gebruik nie?

As u die persoon ken vir wie u veilige tydelike boodskappe wil stuur, dit gereeld stuur, 'n kletsagtige koppelvlak verwag en / of u van die ontvanger die nodige sagteware kan verwag en weet hoe om dit te gebruik, is hierdie webwerf waarskynlik nie die beste oplossing. Daar is wonderlike opsies wat open source is, E2EE ondersteun, nie op die web nie, en selfs sommige soos Signal wat ook tydelike boodskappe ondersteun. Ek gebruik persoonlik 'n private XMMP-bediener en OMEMO om met vriende en familie te gesels. Die gebruik van hierdie webwerf is miskien net optimaal as u nie weet watter sagteware die ontvanger gebruik nie, nie hul telefoonnommer / kontakhandvatsel ken nie, nie hul tegniese vaardigheid ken nie (maar aanvaar dat hy op 'n skakel kan klik), of u hou net die boodskap wat u stuur buite die onderliggende kommunikasievervoer.

Watter vereistes bestaan daar?

'N Moderne en bygewerkte webblaaier wat standaarde insluitend die Web Crypto API behoorlik implementeer, word vereis. Voorbeelde hiervan is: Chrome, Firefox, Edge en Safari (omstreeks 2020 of daarna).

Kan die ontvanger 'n afskrif van die boodskap maak?

Ja. Alhoewel die boodskap homself kan verwyder wanneer dit herwin word, kan die ontvanger steeds die boodskap sien. Elke keer as die ontvanger die boodskap volledig kan sien, kan 'n kopie gemaak word - dit geld vir alle kommunikasie. Daar is 'n opsie om die ontvanger 'n kopie moeiliker te maak. In hierdie geval word drie hindernisse vir kopiëring geïmplementeer:

Hierdie kopieërs is egter swak omdat dit omseil kan word. Die ontvanger kan ook altyd net 'n kiekie of 'n foto van die boodskap neem.

Word enige persoonlike inligting versamel?

Ons ondersteun nie gebruikersrekeninge (dws gebruikersnaam / wagwoord) nie. Ons versamel geen inligting wat u kan identifiseer nie (dws naam / adres / e-pos / telefoon). Daar is moontlik persoonlike inligting in die boodskap wat u stuur, maar dit is geënkripteer en ons kan dit nie lees nie. Lees ons privaatheidsbeleid vir volledige besonderhede.

Watter inligting word aangeteken?

Ons webbediener behou tot 24 uur algemene log-formaat op alle webaktiwiteite. Dit sluit in om die volledige IP-adres van HTTP-kliënte aan te teken. Na 24 uur word hierdie aangemelde inligting outomaties uitgevee. Alle versoeke wat na / api gestuur word, word gepos, wat beteken dat geen boodskapspesifieke inligting ooit deur die webbediener aangeteken word nie. Daarbenewens word enige inligting wat in die databasis gestoor word, effektief aangeteken. Alle inskrywings in die databasis, insluitend anonieme en gehaste IP-adresse, het 'n verstrykingstyd (TTL) waarna dit outomaties verwyder word. Die TTL-vervalstye wissel tussen 1 minuut en 2 weke.

Wat doen u om die bedieners te beveilig?

Bedienersekuriteit is 'n duidelike bron van kommer. Daar is twee hoofareas waarop ons fokus om dit veilig te hou:

Watter veiligheidsrisiko's is daar wanneer u hierdie webwerf gebruik?

Voordat ek spesifiek aandag gee aan sommige van hierdie risiko's, dink ek dat 'n semi-kort analogie kan help om die risiko's in die gebruik van internetkommunikasie saam te vat. Visualiseer dat enige stelsel net so veilig is as die swakste skakel in 'n ketting. Stel u nou 'n scenario voor waarin daar twee mense in 'n geslote kamer is sonder om iets te sien, te hoor of op te neem wat hulle doen. Die een sal 'n boodskap aan die ander deurgee wat dit sal verbrand wanneer hy die boodskap lees. As iemand buite daardie kamer die boodskap wil ontvang wat reeds deurgegee is, gaan dit moeilik wees. Wat is die swakste skakel om die boodskap te bekom? Daar is nie soveel skakels om van te kies nie - dit is 'n redelike kort ketting. Stel u nou voor dat wanneer u 'n boodskap op die internet stuur dat daar minstens 'n miljoen skakels in die ketting is - waarvan baie swak is - baie daarvan heeltemal buite u beheer - en dit is die werklikheid.

Die gebruik van enkripsie kan baie help met die bogenoemde miljoen skakelprobleem, en dit is maklik om te dink dat goed ontwerpte E2EE-stelsels die uiteindelike oplossing bied. Hierdie denke kan u egter in die moeilikheid bring, want 'n aanvaller sal gewoonlik net agter die swakker skakels in die stelsel gaan. Dit is waarskynlik baie makliker om u telefoon of rekenaar oor te neem en 'n invoerregister op te stel om net alles wat u tik, te lees as om gekodeerde boodskappe oor die draad te knak. Die uiteinde van die saak is dat as ek die taak kry om 'n geheim van lewensbelangrike / kritieke belang te kommunikeer, sal ek slegs elektroniese kommunikasie as 'n laaste manier gebruik.

Daar is dus veiligheidsrisiko's as u enige kommunikasie gebruik, maar u gebruik steeds 'n webblaaier om bankdienste te koop, goed te koop, e-pos, ens. Die vraag is regtig ... watter veiligheidsrisiko's is semi-spesifiek vir hierdie webwerf? 'N Paar dink aan:

Wat doen jy aan man-in-die-middel (MITM) aanvalle?

Alle gebruikers van webwerwe kan moontlik die slagoffer van 'n MITM-aanval wees - hierdie webwerf is in hierdie verband nie anders as al die ander op die web nie. 'N MITM-aanval is wanneer 'n aanvaller die kommunikasie tussen die gebruiker se blaaier en die webbediener van die werf kan onderskep en verander. Hierdeur kan die aanvaller enige van die kode / inhoud van die werf verander, terwyl dit steeds aan die eindgebruiker verskyn as die werf waaraan hulle gewoond is. Ons neem 'n paar maatreëls om 'n MITM-aanval moeiliker te maak:

'N MITM-aanval is egter nog altyd moontlik - veral as die aanvaller netwerk / openbare sleutelinfrastruktuur beheer, soos die geval sou wees met groot / magtige organisasies of regerings. Ons bied blaaieruitbreidings wat sommige MITM-risiko's kan help verminder.

Watter voordele bied die blaaieruitbreidings?

Ons bied blaaieruitbreidings as 'n manier om ekstra gemak en ekstra veiligheid te bied. Eenvoudig gestel ... Die uitbreidings maak die stuur van tydelike boodskappe vinniger en makliker. Sekere sekuriteit word ook verkry omdat alle kode wat gebruik word om 'n boodskap te enkripteer en voor te berei, in die uitbreiding gestoor word. Omdat die kode plaaslik gestoor word, bied dit die sender 'n mate van beskerming teen MITM-aanvalle . Dit is egter die moeite werd om daarop te wys dat hoewel die uitbreidings meer beskerming bied teen 'n MITM-aanval wat die inhoud van die boodskap in gevaar stel, kan 'n MITM-aanval steeds effektief wees (dws om die IP-adres van die afzender te bepaal as dit nie TOR / VPN / ens. Gebruik word nie).

Hoe kan ek verseker weet dat alles wat ingedien word, end-tot-einde geïnkripteer is?

In teenstelling met baie ander gewilde end-to-end-geïnkripteerde (E2EE) kletskliënte, is dit redelik eenvoudig om presies te sien wat aan ons gestuur word wanneer u 'n boodskap stuur. Die onderstaande video-tutoriaal toon aan hoe u kan bevestig dat ons geen boodskappe kan ontsyfer wat na die bediener gestuur word nie.

As u daaraan dink, solank ons nie 'n geheime agentskap is wat sensitiewe boodskappe probeer versamel nie, is daar geen voordeel daarvoor dat ons boodskappe kan ontsyfer nie, aangesien die vermoë net vir ons probleme skep. Ons wil nie eers boodskappe stoor nie - dit is egter 'n noodsaaklike euwel om dit te lewer.

Hoe werk end-tot-end-enkripsie op hierdie webwerf?

Op die oomblik gebruik ons simmetriese kodering (AES-GCM 256bit) met sleutels afgelei van wagwoorde (minimum 150.000 herhalings van PBKDF2 / SHA-256). Asimmetriese kodering word nie gebruik nie, want daar bestaan vereistes vir 1) sender wat die kommunikasie begin 2) sender en ontvanger wat nie aanlyn is nie en 3) geen inligting oor die ontvanger nie en 4) ons probeer dinge eenvoudig hou en sleutelbestuur is ingewikkeld. Die standaard Web Crypto API word gebruik vir alle kriptografiese funksies, insluitend RNG. Hier is basies wat gebeur:

  1. Die eindgebruiker kies 'n wagwoord of een word outomaties gegenereer
  2. 'N API-oproep word gedoen om die aantal vereiste PBKDF2 / SHA-256-herhalings te verkry ( hierdie stap is nodig vir strooiposbeheer )
  3. 'N Sout van 32 byte word opgewek
  4. 'N Sleutel is afgelei van die sout en wagwoord
  5. 'N 12 byte- inisialiseringsvektor (IV) word gegenereer
  6. Die boodskap word met die sleutel + IV geïnkripteer
  7. Die iterasie-telling, sout, IV en kodeteks word na die bediener gestuur (tesame met ander inligting soos TTL, RTL, ens.)
  8. Die bediener gee 'n ewekansige ID terug na die boodskap
  9. Die blaaier bied dan aan die eindgebruiker 'n skakel met die teruggestuurde ID en wagwoord of 'n skakel sonder die wagwoord (in welke geval die ontvanger die wagwoord moet ken en invoer)
  10. As die wagwoord deel van die skakel is, is dit in die URL-hash en dus nooit na die bediener gestuur wanneer die ontvanger die GET-versoek rig nie
  11. Die ontvanger word gevra of hy die boodskap wil ontsyfer en wil sien
  12. Die blaaier rig 'n versoek met die boodskap-ID
  13. As die sender wil hê dat 'n CAPTCHA voltooi moet word, word die ontvanger na 'n ander URL gestuur om te bewys dat hy 'n mens is (sodra hy slaag, word hy teruggestuur)
  14. Die bediener stuur die geënkripteerde boodskap en sal die boodskap standaard verwyder op hierdie stadium as die read-to-live (RTL) een is
  15. Die ontvanger sal die boodskap met die wagwoord ontsyfer (en word gevra om die wagwoord as dit nie in die URL is nie)
Hierdie instelling is uiters eenvoudig en bied boodskapkodering vanaf die sender van die toestel na die ontvanger se toestel, maar dit ontbreek natuurlik die waarborg wat asimmetriese enkripsie kan bied in terme van die feit dat slegs iemand in besit van die ontvanger se private sleutel die boodskap kan ontsyfer. Enigiemand met die skakel kan die boodskap in die verstek scenario open waarvolgens die wagwoord deel van die URL is - dit beklemtoon die belangrikheid daarvan om 'n geskikte vervoer vir die skakel te gebruik (dws e-pos / chat / sms / ens.) - 'n besluit wat aan sender. Ons kan, indien daar belangstelling is, ook ondersteuning vir 'n baie basiese asimmetriese skema implementeer waardeur die ontvanger 'n versoek vir 'n boodskap inisieer en die versoekskakel na die sender van die boodskap stuur. Hierdie opstelling sal die behoefte om die wagwoord in die URL te hê, elimineer, maar ook die moontlikheid van die sender om te begin, elimineer.

Die ontsyferingswagwoord kan in die URL wees?

Ja. Dit beïnvloed natuurlik die sekuriteit, want as die metode wat gebruik word om die skakel te stuur onveilig is, is die boodskap onveilig deur assosiasie. Alle oplossings om hierdie probleem uit die weg te ruim, bied aanvullende stappe en ingewikkeldhede wat die gebruikerservaring beïnvloed (dws dinge moet aan beide kante ingestel word voordat die boodskap gestuur word). 'N Asimmetriese skema waardeur die ontvanger 'n versoek vir 'n boodskap inisieer en die versoekskakel stuur, kan werk met ons sleutelvereiste' alles is kortstondig '- dit kan geïmplementeer word. Uiteindelik, as twee partye gereeld boodskappe aan mekaar gaan stuur, bestaan daar beter oplossings as die veronderstelling is dat albei partye die oplossing kan hanteer.

Maar hoef die dekripsiewagwoord nie in die URL te wees nie?

Reg. As die dekoderingswagwoord nie by die skakel ingesluit is nie, word die wagwoord van die ontvanger gevra. As die wagwoord veilig aan die ontvanger gekommunikeer word (of hulle weet dit reeds), bied dit beskerming teen afvang. Die nadeel is egter dat die ontvanger die wagwoord moet ken en korrek moet invoer. Hier is een manier om die wagwoord aan die ontvanger te stuur wat 'n mate van beskerming bied teen onderskep:

  1. Enkripteer die wagwoord in 'n boodskap met die standaardinstellings en stuur hierdie skakel na die ontvanger.
  2. As die ontvanger op die skakel klik en die boodskap ontsyfer, weet hulle dat niemand anders die wagwoord voor hulle gekry het nie, want die boodskap wat die wagwoord bevat, word verwyder wanneer dit opgehaal word. As daar egter 'n aktiewe MITM -aanval is, of as u toestel of die toestel van die ontvanger in die gedrang is, is dit steeds moontlik dat 'n ander party die wagwoord kan bekom.
  3. Bevestig met die ontvanger dat hulle die wagwoord suksesvol gekry het. Byvoorbeeld, as die ontvanger u in kennis stel dat die boodskap reeds verwyder is toe hy die wagwoord gaan haal het, dan weet u dat iemand anders die wagwoord voor die ontvanger gekry het en dat die wagwoord dus in die gedrang is en nie gebruik mag word nie.
  4. Met die wagwoord wat die ontvanger bevestig het, kan u nou 'n boodskap stuur met dieselfde wagwoord vir kodering - deel net die weergawe van die skakel wat nie die wagwoord bevat nie.

Dit is korrek - ons genereer die skakel en laat dit aan die sender toe om dit die beste by die ontvanger af te lewer. Die doel van hierdie diens is om 'n opsie te bied wat minder permanensie bied in bestaande boodskappe soos e-pos / klets / teks / ens. Daarom is die verwagting dat die skakel wat ons genereer wat op die tydelike boodskap dui, via 'n bestaande boodskaptransport gestuur word. Dit het wel veiligheidsimplikasies wat gebruikers moet verstaan. Kom ons neem 'n SMS-boodskap as voorbeeld, aangesien dit 'n redelik onveilige manier van kommunikasie is. As u hierdie diens gebruik om 'n tydelike boodskapskakel via 'n teksboodskap te stuur, as u die standaardmodus gebruik waarvolgens die wagwoord in die skakel is, kan enigiemand met die skakel die boodskap lees en geen beskerming teen onderskep word aangebied nie. Hierdie diens bied steeds 'n meer tydelike kommunikasie wat privaatheid en sekuriteit kan verbeter. Daarbenewens kan u kies om die skakel sonder die wagwoord te stuur, en dit bied beskerming teen onderskep.

Hoe kan ek my privaatheid soveel as moontlik beskerm terwyl ek van hierdie diens gebruik maak?

Soos elders in hierdie FAQ bespreek, alhoewel ons al baie doen om u privaatheid te beskerm en alhoewel ons geen persoonlike inligting versamel nie, word sommige log-verwante inligting deur ons en ander ingedien en versamel op grond daarvan dat u 'n webblaaier gebruik. Daar is egter verskeie maniere om u privaatheid nog meer te beskerm. Een manier om gratis te gebruik, gebaseer op open source sagteware, en wat baie goed werk, is om die Tor Browser te gebruik. Hierdie blaaier is ontwerp om u privaatheid op verskeie vlakke te beskerm - insluitend die gebruik van die Tor-netwerk . Ons webwerf is reeds toeganklik via die Tor-uienetwerk, wat beteken dat toegang tot ons webwerf via Tor nie die gebruik van 'n uitgangsknooppunt vereis nie, wat beteken dat iemand die afluisterverkeer afluister . Onthou egter dat selfs u internetdiensverskaffer in hierdie scenario kan sien dat u Tor gebruik - alhoewel nie waarvoor nie. U kan selfs verbinding maak met 'n Skynprivaatnetwerk en dan die Tor Browser begin vir twee lae anonimiteit; Hou egter in gedagte dat u internetverskaffer steeds kan sien dat u 'n Skynprivaatnetwerk in hierdie scenario gebruik - alhoewel nie waarvoor nie. As u nie van u ISP wil weet watter protokolle u gebruik nie, kan u verbinding maak met 'n groot openbare WiFi-netwerk soos 'n biblioteek, skool, ens. En dan die Tor-blaaier gebruik.

Wat as ek die Verenigde State nie vertrou nie?

Ons bedieners is in die Verenigde State geleë. Verder is ons CDN-verskaffer, Cloudflare, 'n onderneming in die Verenigde State. Ons het probeer om die vertroue in ons of die land waarin ons bedieners woon, te vertrou, bloot omdat ons nie persoonlike inligting versamel nie, geen boodskappe kan dekripteer nie, en alles word verwyder nadat dit ontvang is. Ons kan egter 'n mate van wantroue verstaan omdat dit op die internet gebaseer is en veral as u in sekere lande woon. Ons beplan om opsies in Ysland en Switserland aan te bied vir mense wat die VSA moeilik vertrou. Laat weet ons as dit op u van toepassing is, aangesien ons nie gemotiveerd sal wees om alternatiewe te bied nie, tensy daar regtig 'n vraag is.

Wat doen u om strooipos te voorkom?

As u iemand toelaat om 'n boodskap te plaas wat via 'n skakel kan deurgee, nooi u spammers uit. Die beperking van hierdie probleem is nie heeltemal eenvoudig nie. Ons wil om 'n paar redes nie 'n CAPTCHA van derdeparty laai as deel van die proses vir die stuur van boodskappe nie:

Ons kan moontlik die API-probleem omseil deur een of ander API-sleutelstelsel te gebruik, maar dan moet ons gebruikersinligting versamel wat ons nie wil doen nie. Wat kan ook voorkom dat spammers baie API-sleutels kry? Ons kan nie boodskappe ondersoek om hul gemorspos (wat in die beste geval baie problematies is) af te lei nie, aangesien ons, behalwe om die boodskappe te enkripteer, 'n praktiese beleid het oor die boodskapinhoud. Gegewe hierdie vereistes, gebruik ons twee metodes om strooipos te voorkom: Indien u weet dat spammers hierdie diens misbruik, dien u 'n misbruikverslag in .

Waarom is daar die opsie om van die ontvanger 'n CAPTCHA te voltooi?

Alhoewel dit waar is dat ons nie van CAPTCHA's hou nie, besef ons dat dit 'n doel het en 'n tyd en plek het (ten minste vir eers). Dit is 'n eenvoudige manier vir die sender om seker te maak dat die ontvanger menslik is en dat outomatiese prosesse nie toegang tot die boodskap het nie.

Wie bedryf hierdie diens en waarom is dit gratis?

Ons is maar net 'n paar ouens wat soms die moeilikheid gehad het om nie goeie opsies te hê om ons privaatheid te beskerm nie. Dit was dikwels die gevolg van kommunikasie met vriende en familielede wat nie baie versigtig was met die hantering van hul toestelle en inligting nie. Dit het terselfdertyd plaasgevind tydens die gebruik van webgebaseerde forums soos Reddit of die gebruik van webgebaseerde ondersteuningstelsels. Ons het 'n paar webgebaseerde oplossings vir tydelike boodskappe gevind, maar niemand het E2EE aangebied nie, wat beteken dat ons dit nie kon vertrou nie. Ons het dus net ons eie oplossing gebou en besluit om dit weg te gee sodat ander daarby kan baat.

Hoe kan ek die antwoorde op bogenoemde vrae vertrou?

U moet eintlik geen webwerf vertrou nie, net omdat dit sekere dinge sê - dit is gewoonlik 'n goeie idee om enige eise te verifieer. Ons het probeer om die vereiste om soveel as moontlik op ons te vertrou verwyder deur middel van end-tot-end-enkripsie. Dit is byvoorbeeld redelik maklik om te oudit dat ons geen boodskappe kan lees nie omdat dit geënkripteer is . Ons het ook die JavaScript-kode wat hierdie webwerf bedryf, baie eenvoudig gehou, sodat dit maklik is om te lees en te verstaan. Deur al die kode oopbron te maak, kan mense verifieer wat loop; Hou egter in gedagte dat daar geen manier is om werklik te verifieer wat die bediener gebruik nie. Alhoewel baie van die vertrouensvereistes met die end-tot-end-enkripsie verwyder word, is dit steeds 'n faktor wat ons gebruikers baie weeg as hulle besluit om hierdie diens te gebruik of nie.