Preguntes freqüents

Per què aquest lloc està mal traduït? ⎃

Ho sentim, però els autors actuals només parlen anglès. Necessitem ajuda per traduir aquest projecte a altres idiomes. Com a mitjà senzill i econòmic per fer disponible aquest servei a persones que no parlen anglès, utilitzem la traducció automàtica. Els resultats solen ser acceptables, però poden donar lloc a una redacció estranya o fins i tot a una informació completament inexacta. Podeu ajudar-nos a millorar l’experiència per a tothom; envieu la traducció correcta .

Quina seguretat té aquest servei?

Hem fet molts passos per garantir que aquest servei sigui segur per al seu ús previst . Abans de revisar aquests passos, és important entendre el següent:

El nostre objectiu és oferir aquest servei de manera que ofereixi opcions per millorar la vostra privadesa i seguretat. A continuació, es detallen alguns passos per protegir la vostra informació de manera segura:

Per què he rebut un enllaç aquí amb una opció per desxifrar un missatge?

Disculpeu si hi ha errors en aquesta traducció . Aquest servei simplement transmet un missatge xifrat d’un punt a un altre i tu ets el destinatari. Aviat se suprimirà el missatge. Els operadors d’aquest servei no tenen manera de llegir el contingut del missatge. Normalment algú utilitza aquest servei quan no vol que el contingut d’un missatge quedi dins de diverses bases de dades / dispositius / serveis / fitxers / etc. com és habitual en enviar un correu electrònic / missatge instantani / text / etc. Si decidiu desxifrar, tingueu en compte el següent:

Voleu suprimir tot el contingut enviat a aquest lloc?

Fidel al logotip de la nostra paperera ... tot s'esborra poc després de rebre'l. La supressió de tot s’automatitza: s’escriu al servidor. Penseu-ho així: hi ha dues classes d'informació enviada:

En el cas dels missatges, podeu controlar quan els suprimim especificant: Per defecte, tot el contingut d'un missatge se suprimeix després de recuperar-lo una vegada o tenir una setmana d'antiguitat, el que passi primer. Quan es tracta d’eliminar tota la resta d’informació inherent a l’enviament de qualsevol cosa al web (és a dir, la vostra adreça IP, etc.), no us donem cap control sobre quan o com s’elimina; només l’esborrem cada 24 hores. .

Per què utilitzar aquest servei?

Aquest servei és una eina per ajudar a fer que els missatges que envieu / rebeu siguin menys permanents. La majoria del que comuniqueu a Internet (xats, textos, correus electrònics, etc.) s’emmagatzema i rarament s’elimina. Sovint, quan suprimiu alguna cosa, en realitat no se suprimeix, sinó que es marca com a suprimit i ja no se us mostra. Les vostres comunicacions agregades s’acumulen any rere any en bases de dades i en dispositius sobre els quals no teniu control. Inevitablement, es pirateja una o més de les organitzacions / persones / dispositius que emmagatzemen les vostres comunicacions i es filtra la vostra informació. Aquest problema és tan generalitzat que ara hi ha molts llocs web que fan un seguiment de les organitzacions que han estat compromeses i han filtrat les dades dels usuaris. Els missatges temporals xifrats de punta a punta són una solució senzilla per ajudar a fer que algunes de les vostres comunicacions siguin menys permanents. Tots els missatges enviats a aquest lloc tenen un temps de vida que oscil·la entre 1 minut i 2 setmanes; un cop passat aquest temps, el missatge se suprimeix. A més, la configuració per defecte és suprimir qualsevol missatge un cop el destinatari l’hagi recuperat. A més, tots els missatges es xifren des del dispositiu fins al dispositiu del destinatari. L’objectiu principal d’utilitzar el xifratge extrem a extrem és eliminar la nostra capacitat de llegir qualsevol missatge enviat, eliminant així alguns dels requisits de confiança. El resultat final és que ara és fàcil enviar un missatge xifrat mitjançant un simple enllaç. Aquest missatge s’esborra poc després d’enviar-lo o després de recuperar-lo. No cal instal·lar / configurar programari especial. No cal que creeu cap compte ni proporcioneu cap informació personal. El destinatari no ha d’estar als vostres contactes ni tan sols conèixer aquest servei, l’únic requisit que pot fer clic en un enllaç.

És un servei de missatgeria?

No, aquest servei està dissenyat per complementar els serveis de missatgeria existents, com ara missatgeria instantània / correu electrònic / text / etc. afegint la possibilitat d’evitar que els missatges enviats s’emmagatzemin durant molt de temps. No lliurem l'enllaç generat al destinatari .

Quins són els casos d'ús previstos?

Quins són alguns escenaris en què és adequat utilitzar aquest servei? Tot i que tothom té necessitats i requisits diferents pel que fa a la seva privadesa i seguretat, personalment he trobat els casos següents com a casos d’ús adequats:

Per a què no s’ha d’utilitzar aquest servei?

Aquest servei no s’ha d’utilitzar per obtenir informació molt confidencial per tots els motius explicats en aquest FAQ. A continuació es mostren alguns exemples de què no cal fer:

Per què no només utilitzeu PGP / Signal / OMEMO / Matrix / etc.?

Si coneixeu la persona que voleu enviar missatges temporals segurs, envieu-los sovint, espereu una interfície semblant al xat i / o pugueu esperar que el destinatari tingui el programari requerit i el sàpiga utilitzar, probablement aquest lloc web no sigui millor solució. Hi ha opcions fantàstiques que són de codi obert, suporten E2EE, no basades en web, i fins i tot algunes com Signal que també admeten missatges temporals. Personalment utilitzo un servidor privat XMMP i OMEMO per xatejar amb amics i familiars propers. L’ús d’aquest lloc només pot ser òptim si no sabeu quin és el programari que executa el destinatari, no coneixeu el seu número de telèfon / contacte, ni coneixeu el seu coneixement tècnic (però suposeu que poden fer clic a un enllaç), o simplement preferiu mantenir el missatge que envieu fora del transport de comunicació subjacent.

Quins requisits existeixen?

Es requereix un navegador web modern i actualitzat que implementi correctament estàndards que incloguin l'API Web Crypto. Alguns exemples són: Chrome, Firefox, Edge i Safari (vers 2020 o després).

El destinatari pot fer una còpia del missatge?

Sí. Tot i que el missatge es pot esborrar a si mateix quan es recupera, el destinatari encara pot visualitzar-lo. Sempre que el receptor pot visualitzar completament el missatge, es pot fer una còpia, això s'aplica a totes les comunicacions. Hi ha una opció per dificultar la realització d’una còpia per al destinatari. En aquest cas, s’implementen tres impediments per copiar:

Tot i això, aquestes proteccions contra còpia són febles perquè es poden passar per alt. A més, el destinatari sempre pot fer una captura de pantalla o una foto del missatge.

Es recopila informació personal?

No admetem comptes d'usuari (és a dir, nom d'usuari / contrasenya). No recopilem cap informació que pugui identificar-lo (és a dir, nom / adreça / correu electrònic / telèfon). És possible que hi hagi informació personal al missatge que envieu, però està encriptada i no tenim manera de llegir-la. Consulteu la nostra política de privadesa per obtenir detalls complets.

Quina informació es registra?

El nostre servidor web manté fins a 24 hores de format de registre comú en tota l'activitat web. Això inclou el registre de l'adreça IP completa dels clients HTTP. Després de 24 hores, aquesta informació registrada s'elimina automàticament. Totes les sol·licituds enviades a / api es publiquen, cosa que significa que el servidor web no registra mai cap informació específica del missatge. A més, es registra eficaçment tota la informació guardada a la base de dades. Totes les entrades de la base de dades, incloses les adreces IP anonimitzades i resumides, tenen un temps de caducitat (TTL) després del qual se suprimeixen automàticament. Els terminis de caducitat del TTL varien entre 1 minut i 2 setmanes.

Què feu per protegir els servidors?

La seguretat del servidor és una preocupació òbvia. Hi ha dues àrees principals en què ens centrem per mantenir-la segura:

Quins riscos de seguretat hi ha quan s’utilitza aquest lloc?

Abans d'abordar específicament alguns d'aquests riscos, crec que una analogia semi-breu pot ajudar a resumir els riscos de l'ús de qualsevol comunicació a Internet. Visualitzeu que qualsevol sistema només és tan segur com l’enllaç més feble d’una cadena. Imagineu-vos ara un escenari en què hi hagi dues persones en una habitació tancada sense mitjans per veure, escoltar ni enregistrar res del que fan. Un passarà un missatge a l’altre que en llegir-lo el cremarà. Si algú fora d’aquesta sala vol obtenir el missatge que ja s’havia aprovat, serà difícil. Quin és l’enllaç més feble per obtenir el missatge? No hi ha tants enllaços per triar: és una cadena força curta. Ara imagineu-vos que quan envieu un missatge a Internet que hi ha almenys un milió d’enllaços a la cadena –molts d’ells febles - molts d’ells totalment fora del vostre control– i això és realitat.

L’ús del xifratge pot ajudar molt amb el problema de l’enllaç anterior i és fàcil d’atraure pensant que els sistemes E2EE ben dissenyats ofereixen la solució final. Tanmateix, aquest pensament pot posar-vos en problemes, perquè un atacant normalment sol buscar els enllaços més febles del sistema. Per exemple, probablement sigui molt més fàcil agafar el vostre telèfon o ordinador i configurar un registrador d’entrada per llegir tot el que escriviu que trencar missatges xifrats per cable. La conclusió és que si m’encarregués de comunicar un secret d’importància vital / crítica, només utilitzaria les comunicacions electròniques com a mètode d’últim recurs.

Per tant, hi ha riscos de seguretat mitjançant qualsevol comunicació, però encara utilitzeu un navegador web per fer banca, comprar articles, correu electrònic, etc. És un risc acceptat per les enormes comoditats adquirides. Realment la pregunta és ... quins riscos de seguretat són semespecífics d’aquest lloc? Alguns em vénen al cap:

Què feu sobre els atacs home-al-mig (MITM)?

Tots els usuaris de llocs web poden ser víctimes d’un atac MITM: aquest lloc no és diferent de tots els altres que hi ha al web en aquest sentit. Un atac MITM és quan un atacant és capaç d'interceptar i modificar les comunicacions entre el navegador de l'usuari i el servidor web del lloc. Això permet a l'atacant modificar qualsevol codi o contingut del lloc mentre apareix a l'usuari final com el lloc al qual està acostumat. Prenem algunes mesures per fer més difícil un atac MITM:

No obstant això, un atac MITM sempre és possible, especialment si l'atacant controla la infraestructura de xarxa pública / de clau, com seria el cas de les organitzacions o governs grans / potents. Oferim extensions de navegador que poden ajudar a mitigar alguns riscos de MITM.

Quins avantatges ofereixen les extensions del navegador?

Oferim extensions de navegador com a mitjà per proporcionar comoditat i seguretat addicionals. En poques paraules ... Les extensions faciliten i envien missatges temporals. També es guanya certa seguretat perquè tot el codi utilitzat per xifrar i preparar un missatge s’emmagatzema localment dins de l’extensió. Com que el codi s’emmagatzema localment, això ofereix al remitent certa protecció contra atacs MITM . No obstant això, val la pena assenyalar que, si bé les extensions ofereixen més protecció contra un atac MITM que compromet el contingut del missatge, un atac MITM encara podria ser eficaç (és a dir, determinar l'adreça IP del remitent si no s'utilitza TOR / VPN / etc.).

Com puc saber amb seguretat que tot el que s’envia està encriptat de cap a extrem?

A diferència de molts altres populars clients de xat encriptats de punta a punta (E2EE), és bastant senzill veure exactament el que ens envia quan envieu un missatge. El tutorial de vídeo següent mostra com confirmar que no tenim manera de desxifrar els missatges enviats al servidor.

A més, si us hi plantegeu, sempre que no siguem cap agència secreta que intenti recollir missatges sensibles, no podrem desxifrar missatges, ja que tenir aquesta capacitat només ens crea problemes. Ni tan sols volem emmagatzemar missatges, però és un mal necessari per enviar-los.

Com funciona el xifratge d'extrem a extrem en aquest lloc?

En aquest moment, estem utilitzant xifratge simètric (AES-GCM 256bit) amb claus derivades de contrasenyes (mínim de 200.000 iteracions de PBKDF2 + SHA-256). El xifratge asimètric no s’utilitza perquè existeixen requisits per a 1) l’emissor que inicia la comunicació 2) l’emissor i el destinatari no estan en línia alhora i 3) no hi ha informació sobre el destinatari i 4) intentem que les coses siguin reals senzilles i la gestió de claus sigui complicat. L'API web Crypto estàndard s'utilitza per a totes les funcions criptogràfiques, inclosa la RNG. Bàsicament, això és el que passa:

  1. L'usuari final introdueix un missatge de text i pot especificar diverses opcions, inclosa una contrasenya.
  2. Es genera una contrasenya segura per obtenir una clau. Si l'usuari ha especificat una contrasenya, es combina amb la contrasenya generada.
  3. Es fa una trucada a l'API per obtenir el nombre d'iteracions PBKDF2 + SHA-256 necessàries (aquest pas és necessari per al control de correu brossa )
  4. Es genera una sal de 32 bytes
  5. Una clau es deriva de la sal i la contrasenya
  6. Es genera un vector d’inicialització de 12 bytes (IV)
  7. El missatge es xifra mitjançant la clau i IV.
  8. El recompte d'iteracions, salt, IV i text xifrat s'envien al servidor (juntament amb alguna altra informació com TTL, RTL, etc.)
  9. El servidor retorna una identificació aleatòria que fa referència al missatge
  10. A continuació, el navegador presenta a l’usuari final un enllaç que després es pot compartir amb un destinatari. Tota la informació sobre el missatge es guarda al component hash de l'URL i, per tant, no s'envia al servidor durant una sol·licitud GET estàndard.
  11. L'enllaç es comparteix amb un destinatari.
  12. Al destinatari se li demana si vol desxifrar i veure el missatge.
  13. Quan el destinatari tria veure el missatge, el navegador fa una sol·licitud especificant l'identificador del missatge.
  14. Si el remitent requereix que es completi el CAPTCHA, el destinatari es dirigeix a un altre URL per demostrar que és humà (un cop superat es torna cap enrere).
  15. El servidor envia el missatge xifrat i, de manera predeterminada, suprimirà el missatge en aquest moment si el text de lectura en directe (RTL) és un.
  16. El destinatari desxifrarà el missatge i se li demanarà una contrasenya si cal.
Aquesta configuració és extremadament senzilla i ofereix xifratge de missatges des del dispositiu del remitent fins al dispositiu del destinatari, però, per descomptat, no té algunes de les garanties que pot oferir el xifratge asimètric. Qualsevol persona que tingui l'enllaç pot obrir el missatge a l'escenari predeterminat (això subratlla la importància d'utilitzar un transport adequat per a l'enllaç (és a dir, correu electrònic / xat / text / etc.)), una decisió que queda al remitent.

La clau de desxifratge pot estar a l'URL?

Sí. Si no s’utilitza una contrasenya, qualsevol persona amb l’enllaç pot llegir el missatge. Això, òbviament, afecta la seguretat perquè si es pot interceptar el mètode utilitzat per enviar l'enllaç, es podrà interceptar el missatge. Totes les solucions per eliminar aquest problema introdueixen passos i complexitats addicionals que afecten l'experiència de l'usuari (és a dir, les coses s'han de configurar en els dos extrems abans d'enviar el missatge). En última instància, si dues parts s’enviaran missatges mútuament amb freqüència, existeixen millors solucions suposant que ambdues parts puguin gestionar l’ús d’aquestes solucions.

Però la clau de desxifratge no ha d’estar a l’URL?

Correcte. L’autor del missatge pot especificar una contrasenya per protegir-lo. Aquesta contrasenya s'utilitza per obtenir una clau secreta que no forma part de l'URL . Si s’utilitza una contrasenya segura i es comunica de manera segura al destinatari (o ja ho saben), proporciona protecció contra les interceptacions. No obstant això, l’inconvenient és que el destinatari ha de conèixer i introduir correctament la contrasenya. Aquí teniu una manera d’enviar la contrasenya al destinatari que ofereix una certa protecció contra la intercepció:

  1. Xifreu la contrasenya en un missatge amb la configuració predeterminada i envieu aquest enllaç al destinatari.
  2. Quan el destinatari fa clic a l'enllaç i desxifra el missatge, sap que ningú més no ha obtingut la contrasenya perquè el missatge que conté la contrasenya s'esborra quan es recupera. No obstant això, si hi ha un atac MITM actiu o si el dispositiu o el dispositiu del destinatari han estat compromesos, encara és possible que una altra part pugui obtenir la contrasenya.
  3. Confirmeu amb el destinatari que han obtingut correctament la contrasenya. Per exemple, si el destinatari us informa que quan va anar a recuperar la contrasenya que el missatge ja havia estat esborrat, sabeu que algú ha obtingut la contrasenya abans que el destinatari i que, per tant, la contrasenya es troba compromesa i no s’hauria d’utilitzar.
  4. Mitjançant la contrasenya que el destinatari va confirmar que posseïa, ara podeu enviar un missatge amb la mateixa contrasenya per xifrar.

Això és correcte: generem l'enllaç i deixem al remitent la millor manera de lliurar-lo al destinatari. L'objectiu d'aquest servei és proporcionar una opció que ofereixi menys permanència en transports de missatges existents com ara correu electrònic / xat / text / etc. Per tant, l’expectativa és que l’enllaç que generem que apunti al missatge temporal s’enviï mitjançant un transport de missatges existent. Això té implicacions de seguretat que els usuaris haurien d’entendre. Prenem un missatge de text SMS com a exemple, ja que es tracta d’un mètode de comunicació força insegur. Quan utilitzeu aquest servei per enviar un missatge temporal, amb la configuració predeterminada, qualsevol persona amb l'enllaç pot llegir el missatge i no s'ofereix cap protecció contra la intercepció. Aquest servei encara proporciona una comunicació més temporal que pot millorar la privadesa i la seguretat. A més, es pot utilitzar una contrasenya per proporcionar protecció contra les interceptacions.

Com puc protegir la meva privadesa tant com sigui possible mentre utilitzo aquest servei?

Tal com es comenta en altres preguntes d’aquestes PMF, tot i que ja fem moltes coses per protegir la vostra privadesa i, tot i que no recopilem cap informació personal, algunes de les informacions relacionades amb els registres les enviam i recopilem en virtut de la vostra utilització d’un navegador web. Tot i això, hi ha diverses maneres de protegir encara més la vostra privadesa. Una manera d’utilitzar de manera gratuïta, basada en programari de codi obert i que funciona força bé, és utilitzar el navegador Tor . Aquest navegador està dissenyat per protegir la vostra privadesa en diversos nivells, inclòs l’ús de la xarxa Tor . El nostre lloc ja és accessible a través de la xarxa de ceba Tor, el que significa que l'accés al nostre lloc mitjançant Tor no requereix l'ús d'un node de sortida, cosa que nega algú que escolta el trànsit del node de sortida . Tot i això, tingueu en compte que, fins i tot en aquest escenari, el vostre proveïdor d'Internet pot veure que utilitzeu Tor, tot i que no per a què. Fins i tot podeu connectar-vos a una VPN i després iniciar el navegador Tor per obtenir dues capes d’anonimat; Tanmateix, tingueu en compte que el vostre proveïdor d'Internet encara pot veure que utilitzeu una VPN en aquest escenari, tot i que no per a què. Si no voleu que el vostre proveïdor d'Internet conegui quins protocols utilitzeu, podeu connectar-vos a una gran xarxa WiFi pública, com ara una biblioteca, un centre educatiu, etc. i després utilitzar el navegador Tor.

Què passa si no confio en els Estats Units?

Els nostres servidors es troben als Estats Units. A més, el nostre proveïdor de CDN, Cloudflare, és una empresa amb seu als Estats Units. Hem intentat eliminar la necessitat de confiar en nosaltres o en el país on resideixen els nostres servidors simplement perquè no recopilem informació personal, no podem desxifrar cap missatge i tot s’esborra poc després de rebre’ls. Tot i això, podem entendre certa desconfiança, ja que es basa en la web i, sobretot, si resideu en determinats països. Tenim alguns plans per oferir opcions a Islàndia i Suïssa per a persones a qui els costa confiar en els Estats Units. Si us plau, feu-nos-ho saber , ja que no estarem motivats a oferir alternatives tret que hi hagi una demanda real.

Què feu per evitar el correu brossa?

Sempre que permeteu que algú publiqui un missatge que es pugui retransmetre mitjançant un enllaç, convideu els spammers. Resoldre aquest problema no és del tot senzill. No volem carregar cap CAPTCHA de tercers com a part del procés d’enviament de missatges per alguns motius:

Podríem solucionar el problema de l'API mitjançant l'ús d'algun sistema de claus API, però després hem de recopilar informació de l'usuari que no volem fer. A més, què és el que impedeix que els spammers obtinguin moltes claus API? No podem examinar els missatges per deduir-ne l’espam (cosa que és molt problemàtica en el millor dels casos), ja que, a part de xifrar els missatges, tenim una política de descompte sobre el contingut dels missatges. Tenint en compte aquests requisits, utilitzem dos mètodes per evitar el correu brossa: Si sabeu que els spammers estan abusant d'aquest servei, envieu un informe d'abús .

Per què hi ha una opció per exigir al destinatari que completi un CAPTCHA?

Si bé és cert que no ens agraden els CAPTCHA, reconeixem que serveixen per a un propòsit i tenen un temps i un lloc (almenys per ara). Aquesta és una manera senzilla perquè l’emissor tingui la seguretat que el destinatari és humà i que els processos automatitzats no accedeixen al missatge.

Qui gestiona aquest servei i per què és gratuït?

Només som un parell de nois que de vegades teníem la dificultat de no tenir bones opcions per ajudar a protegir la nostra privadesa. Sovint això resultava de comunicar-se amb amics i familiars que no tenien gaire cura amb la manera com manegaven els seus dispositius i informació. En altres ocasions, això es produïa quan s’utilitzaven fòrums basats en web com Reddit o s’utilitzaven sistemes de suport basats en web. Hem trobat algunes solucions de missatges temporals basades en web, però cap ha ofert E2EE, cosa que significa que no podíem confiar en elles. Per tant, acabem de construir la nostra pròpia solució i decidim donar-la perquè altres es puguin beneficiar d’ella.

Com puc confiar en les respostes a les preguntes anteriors?

Realment, no hauríeu de confiar en cap lloc web només perquè diu certes coses; normalment és una bona idea verificar qualsevol reclamació. Hem intentat eliminar el requisit de confiar en nosaltres el màxim possible mitjançant l'ús del xifratge d'extrem a extrem. Per exemple, és bastant fàcil d’ auditar que no podem llegir cap missatge ja que estan encriptats . També hem mantingut el codi javascript que fa funcionar aquest lloc molt senzill perquè sigui fàcil de llegir i entendre. Fer que tot el codi sigui de codi obert permet a la gent verificar el que s’està executant; no obstant això, tingueu en compte que no hi ha manera de verificar realment el que està executant el servidor. Tot i que és cert que gran part del requisit de confiança s’elimina amb el xifratge d’extrem a extrem, continua sent un factor que pesen molt els nostres usuaris a l’hora de decidir utilitzar aquest servei o no.