Domande frequenti

Perché questo sito è tradotto male? ⎃

Siamo spiacenti, ma gli autori attuali parlano solo inglese. Abbiamo bisogno di aiuto per tradurre questo progetto in altre lingue. Come mezzo semplice ed economico per rendere disponibile questo servizio a persone che non parlano inglese, utilizziamo la traduzione automatica. I risultati sono generalmente accettabili, ma possono risultare in una formulazione strana o addirittura in informazioni completamente imprecise. Puoi aiutarci a migliorare l'esperienza per tutti: invia la traduzione corretta .

Quanto è sicuro questo servizio?

Abbiamo adottato molte misure per rendere questo servizio sicuro per l'uso previsto . Prima di andare oltre questi passaggi, è importante capire quanto segue:

Il nostro obiettivo è offrire questo servizio in un modo che offra opzioni per migliorare la tua privacy e sicurezza. Ecco alcuni passaggi che abbiamo adottato per proteggere le tue informazioni:

Perché ho ricevuto un collegamento qui con un'opzione per decrittografare un messaggio?

Ci scusiamo se ci sono errori in questa traduzione . Questo servizio passa semplicemente un messaggio crittografato da un punto all'altro e tu sei il destinatario. Il messaggio verrà presto eliminato. Gli operatori di questo servizio non hanno modo di leggere il contenuto del messaggio. Di solito qualcuno usa questo servizio quando non vuole che il contenuto di un messaggio rimanga all'interno di vari database/dispositivi/servizi/file/ecc. come è tipico quando si invia un'e-mail/messaggio istantaneo/testo/ecc. Se decidi di decifrare, tieni presente quanto segue:

Cancelli tutto ciò che è stato inviato a questo sito?

Fedele al nostro logo del cestino... tutto viene cancellato poco dopo averlo ricevuto. La cancellazione di tutto è automatizzata: è scritta nel server. Pensala in questo modo: ci sono due classi di informazioni inviate:

Nel caso dei messaggi, puoi controllare quando li eliminiamo specificando: Per impostazione predefinita, tutto ciò che riguarda un messaggio viene eliminato dopo essere stato recuperato una volta o dopo 1 settimana, a seconda dell'evento che si verifica per primo. Quando si tratta di eliminare tutte le altre informazioni inerenti all'invio di qualsiasi cosa sul Web (ad es. il tuo indirizzo IP, ecc.), non ti diamo alcun controllo su quando o come vengono eliminate: le eliminiamo semplicemente tutte ogni 24 ore .

Perché utilizzare questo servizio?

Questo servizio è uno strumento per rendere meno permanenti i messaggi che invii/ricevi. La maggior parte di ciò che comunichi su Internet (chat, messaggi di testo, e-mail, ecc.) viene archiviato e raramente cancellato. Spesso, quando elimini qualcosa, non viene effettivamente eliminato, ma piuttosto contrassegnato come eliminato e non più visualizzato. Le tue comunicazioni aggregate si accumulano anno dopo anno nei database e sui dispositivi su cui non hai alcun controllo. Inevitabilmente, una o più organizzazioni/persone/dispositivi che archiviano le tue comunicazioni vengono violate e le tue informazioni vengono divulgate. Questo problema è così pervasivo che ora ci sono molti siti web che tengono traccia delle organizzazioni che sono state compromesse e che i dati degli utenti sono trapelati. I messaggi temporanei crittografati end-to-end sono una soluzione semplice per rendere meno permanenti alcune delle tue comunicazioni. Ogni messaggio inviato a questo sito ha una durata che va da 1 minuto a 2 settimane - una volta trascorso tale tempo il messaggio viene eliminato. Inoltre, l'impostazione predefinita prevede l'eliminazione di qualsiasi messaggio una volta che il destinatario lo ha recuperato. Inoltre, tutti i messaggi vengono crittografati dal tuo dispositivo fino al dispositivo del destinatario. L'obiettivo principale nell'utilizzo della crittografia end-to-end è rimuovere la nostra capacità di leggere qualsiasi messaggio inviato, rimuovendo così parte del requisito di fiducia. Il risultato finale è che ora è facile inviare un messaggio crittografato tramite un semplice collegamento. Quel messaggio viene eliminato poco dopo l'invio o dopo il recupero. Non è necessario installare/configurare software speciale. Non è necessario creare un account o fornire informazioni personali. Il destinatario non deve essere nei tuoi contatti o nemmeno conoscere questo servizio: l'unico requisito è che possa fare clic su un collegamento.

È un servizio di messaggistica?

No. Questo servizio è progettato per integrare i servizi di messaggistica esistenti come messaggistica istantanea/e-mail/testo/ecc. aggiungendo la possibilità di impedire che i messaggi inviati vengano archiviati per lungo tempo. Non forniamo il link generato al destinatario .

Quali sono i casi d'uso previsti?

Quindi quali sono alcuni scenari in cui è appropriato utilizzare questo servizio? Sebbene ognuno abbia esigenze e requisiti diversi in termini di privacy e sicurezza, personalmente ho trovato i seguenti scenari come casi d'uso appropriati:

Per cosa non dovrebbe essere utilizzato questo servizio?

Questo servizio non deve essere utilizzato per informazioni molto sensibili per tutti i motivi spiegati in questa FAQ. Di seguito sono riportati alcuni esempi di cosa non fare:

Perché non usare semplicemente PGP/Signal/OMEMO/Matrix/ecc.?

Se conosci la persona a cui vuoi inviare messaggi temporanei protetti, inviali spesso, ti aspetti un'interfaccia simile a una chat e/o puoi aspettarti che il destinatario disponga del software richiesto e sappia come usarlo, questo sito web probabilmente non è il soluzione migliore. Ci sono ottime opzioni là fuori che sono open source, supportano E2EE, non basate sul web, e anche alcune come Signal che supportano anche i messaggi temporanei. Personalmente utilizzo un server XMMP privato e OMEMO per chattare con amici intimi e familiari. L'utilizzo di questo sito può essere ottimale solo se non si conosce il software utilizzato dal destinatario, non si conosce il numero di telefono/l'handle di contatto, non si conosce la propria competenza tecnica (ma si presume che possano fare clic su un collegamento), oppure preferisci semplicemente mantenere il messaggio che invii al di fuori del trasporto di comunicazione sottostante.

Quali requisiti esistono?

È necessario un browser Web moderno e aggiornato che implementi correttamente gli standard, inclusa l'API Web Crypto. Gli esempi includono: Chrome, Firefox, Edge e Safari (circa 2020 o successivi).

Il destinatario può fare una copia del messaggio?

Sì. Anche se il messaggio può eliminarsi al momento del recupero, il destinatario può comunque visualizzare il messaggio. Ogni volta che il destinatario può visualizzare completamente il messaggio, può essere eseguita una copia - questo vale per tutte le comunicazioni. C'è un'opzione per rendere più difficile per il destinatario fare una copia. In questo caso sono attuati tre impedimenti alla copiatura:

Tuttavia, queste protezioni contro la copia sono deboli perché possono essere aggirate. Inoltre, il destinatario può sempre semplicemente fare uno screenshot o una foto del messaggio.

Vengono raccolte informazioni personali?

Non supportiamo gli account utente (es. nome utente/password). Non raccogliamo alcuna informazione che possa identificarti (es. nome/indirizzo/e-mail/telefono). È possibile che alcune informazioni personali siano contenute nel messaggio che stai inviando, ma sono crittografate e non abbiamo modo di leggerle. Si prega di rivedere la nostra politica sulla privacy per i dettagli completi.

Quali informazioni vengono registrate?

Il nostro server web mantiene fino a 24 ore di formato di registro comune su tutta l'attività web. Ciò include la registrazione dell'indirizzo IP completo dei client HTTP. Dopo 24 ore, queste informazioni registrate vengono eliminate automaticamente. Tutte le richieste inviate a /api sono POST, il che significa che nessuna informazione specifica del messaggio viene mai registrata dal server web. Inoltre, tutte le informazioni salvate nel database vengono effettivamente registrate. Tutte le voci nel database, inclusi gli indirizzi IP anonimi e con hash, hanno un tempo di scadenza (TTL) dopo il quale vengono automaticamente eliminate. I tempi di scadenza TTL variano tra 1 minuto e 2 settimane.

Cosa stai facendo per proteggere i server?

La sicurezza del server è una preoccupazione ovvia. Ci sono due aree principali su cui ci concentriamo per mantenerlo sicuro:

Quali rischi per la sicurezza sono presenti quando si utilizza questo sito?

Prima di affrontare in modo specifico alcuni di questi rischi, penso che un'analogia semibreve potrebbe aiutare a riassumere i rischi nell'uso di qualsiasi comunicazione Internet. Visualizza che qualsiasi sistema è sicuro solo quanto l'anello più debole di una catena. Ora immagina uno scenario in cui ci sono due persone in una stanza sigillata senza mezzi per vedere, ascoltare o registrare qualsiasi cosa facciano. Uno passerà un messaggio all'altro che leggendolo lo brucerà. Se qualcuno fuori da quella stanza desidera ottenere il messaggio che è già stato passato, sarà dura. Qual è l'anello debole per ottenere il messaggio? Non ci sono molti collegamenti tra cui scegliere: è una catena piuttosto corta. Ora immagina che quando invii un messaggio su Internet che ci sono almeno un milione di anelli della catena - molti dei quali deboli - molti dei quali completamente fuori dal tuo controllo - e questa è la realtà.

L'uso della crittografia può essere di grande aiuto con il problema del milione di collegamenti di cui sopra ed è facile essere indotti a pensare che i sistemi E2EE ben progettati offrano la soluzione definitiva. Tuttavia, questo modo di pensare può metterti nei guai, perché un utente malintenzionato di solito va dietro agli anelli più deboli del sistema. Ad esempio, è probabilmente molto più semplice prendere il controllo del telefono o del computer e configurare un logger di input per leggere semplicemente tutto ciò che si digita piuttosto che decifrare i messaggi crittografati via cavo. La linea di fondo è che se fossi incaricato di comunicare un segreto di importanza vitale/critica, userei solo le comunicazioni elettroniche come metodo di ultima istanza.

Quindi ci sono rischi per la sicurezza utilizzando qualsiasi comunicazione, ma usi ancora un browser web per operazioni bancarie, acquisti, e-mail, ecc. È un rischio accettato per le enormi comodità ottenute. In realtà la domanda è... quali rischi per la sicurezza sono semi-specifici per questo sito? Me ne vengono in mente alcune:

Cosa stai facendo con gli attacchi man-in-the-middle (MITM)?

Tutti gli utenti dei siti Web possono essere potenzialmente vittime di un attacco MITM - questo sito non è diverso da tutti gli altri sul Web in questo senso. Un attacco MITM si verifica quando un utente malintenzionato è in grado di intercettare e modificare le comunicazioni tra il browser dell'utente e il server web del sito. Ciò consente all'attaccante di modificare qualsiasi codice/contenuto del sito pur continuando a sembrare all'utente finale il sito a cui è abituato. Adottiamo alcune misure per rendere più difficile un attacco MITM:

Tuttavia, un attacco MITM è sempre possibile, soprattutto se l'aggressore controlla l'infrastruttura di rete/a chiave pubblica, come nel caso di organizzazioni o governi grandi/potenti. Offriamo estensioni del browser che possono aiutare a mitigare alcuni rischi MITM.

Quali vantaggi offrono le estensioni del browser?

Offriamo estensioni del browser come mezzo per fornire maggiore comodità e sicurezza aggiuntiva. In poche parole... Le estensioni rendono l'invio di messaggi temporanei più semplice e veloce. Si ottiene anche una certa sicurezza perché tutto il codice utilizzato per crittografare e preparare un messaggio è archiviato localmente all'interno dell'estensione. Poiché il codice è memorizzato localmente, questo offre al mittente una certa protezione contro gli attacchi MITM . Tuttavia, vale la pena sottolineare che mentre le estensioni offrono una maggiore protezione contro un attacco MITM che comprometta il contenuto del messaggio, un attacco MITM potrebbe comunque essere efficace (ovvero per determinare l'indirizzo IP del mittente se non si utilizza TOR/VPN/ecc.).

Come posso essere sicuro che tutto ciò che viene inviato è crittografato end-to-end?

A differenza di molti altri client di chat crittografati end-to-end (E2EE), è abbastanza semplice vedere esattamente cosa ci viene inviato quando invii un messaggio. Il video tutorial qui sotto mostra come confermare che non abbiamo modo di decifrare i messaggi inviati al server.

Inoltre, se ci pensi, finché non siamo un'agenzia segreta che cerca di raccogliere messaggi sensibili, non c'è alcun vantaggio per noi di essere in grado di decifrare i messaggi poiché avere questa capacità ci crea solo problemi. Non vogliamo nemmeno memorizzare i messaggi: è comunque un male necessario consegnarli.

Come funziona la crittografia end-to-end su questo sito?

In questo momento, stiamo utilizzando la crittografia simmetrica (AES-GCM 256 bit) con chiavi derivate da password (minimo 150.000 iterazioni di PBKDF2/SHA-256). La crittografia asimmetrica non viene utilizzata perché esistono i requisiti per 1) mittente che avvia la comunicazione 2) mittente e destinatario non online contemporaneamente e 3) nessuna informazione sul destinatario e 4) stiamo cercando di mantenere le cose semplici e la gestione delle chiavi è complicato. L'API Web Crypto standard viene utilizzata per tutte le funzionalità crittografiche incluso RNG. In sostanza, ecco cosa succede:

  1. L'utente finale sceglie una password o una viene generata automaticamente
  2. Viene effettuata una chiamata API per ottenere il numero di iterazioni PBKDF2/SHA-256 richieste ( questo passaggio è necessario per il controllo dello spam )
  3. Viene generato un sale di 32 byte
  4. Una chiave è derivata da salt e password
  5. Viene generato un vettore di inizializzazione a 12 byte (IV)
  6. Il messaggio viene crittografato utilizzando la chiave + IV
  7. Il conteggio delle iterazioni, il salt, IV e il testo cifrato vengono inviati al server (insieme ad alcune altre informazioni come TTL, RTL, ecc.)
  8. Il server restituisce un ID casuale riferito al messaggio
  9. Il browser presenta quindi all'utente finale un collegamento che contiene l'ID e la password restituiti o un collegamento senza la password (in tal caso il destinatario deve conoscere e inserire la password)
  10. Se la password fa parte del collegamento, è nell'URL hash , e quindi mai inviata al server quando il destinatario effettua la richiesta GET
  11. Al destinatario viene chiesto se desidera decrittografare e visualizzare il messaggio
  12. Il browser effettua una richiesta specificando l'ID del messaggio
  13. Se il mittente richiede il completamento di un CAPTCHA, il destinatario viene indirizzato a un altro URL per dimostrare di essere umano (una volta superato viene reindirizzato indietro)
  14. Il server invia il messaggio crittografato e per impostazione predefinita eliminerà il messaggio a questo punto se il reads-to-live (RTL) è uno
  15. Il destinatario decrittograferà il messaggio con la password (e gli verrà richiesta la password se non è nell'URL)
Questa configurazione è estremamente semplice e offre la crittografia dei messaggi dal dispositivo del mittente al dispositivo del destinatario, ma ovviamente manca la garanzia che la crittografia asimmetrica può offrire in termini di conoscenza che solo qualcuno in possesso della chiave privata del destinatario può decifrare il messaggio. Chiunque abbia il collegamento può aprire il messaggio nello scenario predefinito in cui la password è parte dell'URL - questo sottolinea l'importanza di utilizzare un trasporto appropriato per il collegamento (es. email/chat/testo/ecc.) - una decisione lasciata al mittente. Se c'è interesse, possiamo anche implementare il supporto per uno schema asimmetrico di base in base al quale il destinatario avvia una richiesta per un messaggio e invia quel collegamento di richiesta al mittente del messaggio. Questa configurazione eliminerebbe la necessità di avere la password nell'URL, ma elimina anche la possibilità per il mittente di iniziare.

La password di decrittazione può essere nell'URL?

Sì. Questo ovviamente ha un impatto sulla sicurezza perché se il metodo utilizzato per inviare il collegamento non è sicuro, il messaggio è insicuro per associazione. Tutte le soluzioni alternative per eliminare questo problema introducono passaggi aggiuntivi e complessità che influiscono sull'esperienza dell'utente (ad esempio, le cose devono essere impostate su entrambe le estremità prima di inviare il messaggio). Uno schema asimmetrico in cui il destinatario avvia una richiesta per un messaggio e invia quel collegamento di richiesta potrebbe funzionare con il nostro requisito chiave "tutto è effimero" - questo può essere implementato. In definitiva, se due parti si invieranno messaggi di frequente, esistono soluzioni migliori presumendo che entrambe le parti possano gestire l'utilizzo di tali soluzioni.

Ma la password di decrittazione non deve essere nell'URL?

Corretto. Se la password di decrittazione non è inclusa nel collegamento, verrà richiesta la password al destinatario. Se la password viene comunicata in modo sicuro al destinatario (o già la conosce), ciò fornisce protezione contro l'intercettazione. Tuttavia, lo svantaggio è che il destinatario deve conoscere e inserire correttamente la password. Ecco un modo per inviare la password al destinatario che offre una certa protezione contro l'intercettazione:

  1. Cripta la password in un messaggio con le impostazioni predefinite e invia questo link al destinatario.
  2. Quando il destinatario fa clic sul collegamento e decrittografa il messaggio, sa che nessun altro ha ottenuto la password prima di lui perché il messaggio contenente la password viene eliminato al momento del recupero. Tuttavia, se è attivo un attacco MITM o se il tuo dispositivo o il dispositivo del destinatario è stato compromesso, è comunque possibile che un'altra parte possa ottenere la password.
  3. Confermare con il destinatario di aver ottenuto con successo la password. Ad esempio, se il destinatario ti informa che quando è andato a recuperare la password, che il messaggio era già stato cancellato, allora sai che qualcun altro ha ottenuto la password prima del destinatario e che la password è quindi compromessa e non deve essere utilizzata.
  4. Utilizzando la password che il destinatario ha confermato di possedere, è ora possibile inviare un messaggio utilizzando la stessa password per la crittografia: è sufficiente condividere la versione del collegamento che non contiene la password.

Esatto: generiamo il collegamento e lasciamo al mittente il modo migliore per consegnarlo al destinatario. L'obiettivo di questo servizio è fornire un'opzione che offra meno permanenza nei trasporti di messaggi esistenti come e-mail/chat/testo/ecc. Pertanto, l'aspettativa è che il collegamento che generiamo che punta al messaggio temporaneo venga inviato tramite un trasporto di messaggi esistente. Ciò ha implicazioni sulla sicurezza che gli utenti dovrebbero comprendere. Prendiamo come esempio un messaggio di testo SMS poiché questo è un metodo di comunicazione piuttosto insicuro. Quando si utilizza questo servizio per inviare un collegamento temporaneo a un messaggio tramite un messaggio di testo, se si utilizza la modalità predefinita in cui la password è inclusa nel collegamento, chiunque abbia il collegamento può leggere il messaggio e non viene offerta alcuna protezione contro l'intercettazione. Questo servizio fornisce ancora una comunicazione più temporanea che può migliorare la privacy e la sicurezza. Inoltre, puoi scegliere di inviare il collegamento senza la password e ciò fornirà protezione contro l'intercettazione.

Come posso proteggere il più possibile la mia privacy durante l'utilizzo di questo servizio?

Come discusso altrove in questa FAQ, anche se facciamo già molto per proteggere la tua privacy e anche se non raccogliamo alcuna informazione personale, alcune informazioni relative ai log vengono inviate e raccolte da noi e da altri in virtù del tuo utilizzo di un browser web. Tuttavia, ci sono diversi modi per proteggere ancora di più la tua privacy. Un modo gratuito, basato su software open source, e che funziona abbastanza bene è utilizzare Tor Browser . Questo browser è progettato per proteggere la tua privacy su più livelli, incluso l'utilizzo della rete Tor . Il nostro sito è già accessibile tramite la rete Tor onion, il che significa che l'accesso al nostro sito tramite Tor non richiede l'uso di un nodo di uscita, che impedisce a qualcuno di intercettare il traffico del nodo di uscita . Tuttavia, tieni presente che anche in questo scenario, il tuo ISP può vedere che stai usando Tor, anche se non per quale motivo. Puoi persino connetterti a una VPN e quindi avviare Tor Browser per due livelli di anonimato; tuttavia, tieni presente che il tuo ISP può ancora vedere che stai utilizzando una VPN in questo scenario, anche se non per quale motivo. Se non vuoi che il tuo ISP sappia quali protocolli stai utilizzando, puoi connetterti a una grande rete WiFi pubblica come una biblioteca, una scuola, ecc. e quindi utilizzare il browser Tor.

E se non mi fido degli Stati Uniti?

I nostri server si trovano negli Stati Uniti. Inoltre, il nostro provider CDN, Cloudflare, è una società con sede negli Stati Uniti. Abbiamo cercato di rimuovere la necessità di fidarci di noi o del paese in cui risiedono i nostri server semplicemente perché non raccogliamo informazioni personali, non possiamo decifrare alcun messaggio e tutto viene eliminato poco dopo essere stato ricevuto. Tuttavia, possiamo capire una certa sfiducia poiché è basato sul web e soprattutto se vivi in determinati paesi. Abbiamo in programma di offrire opzioni in Islanda e Svizzera per le persone che hanno difficoltà a fidarsi degli Stati Uniti. Fateci sapere se questo è il vostro caso, poiché non saremo motivati a offrire alternative a meno che non vi sia una domanda reale.

Cosa stai facendo per prevenire lo spam?

Ogni volta che permetti a qualcuno di pubblicare un messaggio che può essere inoltrato tramite un link, inviti gli spammer. Arginare questo problema non è del tutto semplice. Non vogliamo caricare un CAPTCHA di terze parti come parte del processo di invio del messaggio per alcuni motivi:

Potremmo forse aggirare il problema dell'API utilizzando un sistema di chiavi API, ma poi dobbiamo raccogliere informazioni sull'utente che non vogliamo fare. Inoltre, cosa impedisce agli spammer di ottenere molte chiavi API? Non possiamo esaminare i messaggi per dedurre la loro presenza di spam (che è molto problematica nella migliore delle ipotesi) poiché, oltre a crittografare i messaggi, abbiamo una politica di non intervento sul contenuto dei messaggi. Dati questi requisiti, utilizziamo due metodi per prevenire lo spam: Se sei consapevole che gli spammer stanno abusando di questo servizio, invia una segnalazione di abuso .

Perché c'è un'opzione per richiedere al destinatario di completare un CAPTCHA?

Anche se è vero che non ci piacciono i CAPTCHA, riconosciamo che hanno uno scopo e hanno un tempo e un luogo (almeno per ora). Questo è un modo semplice per il mittente di assicurarsi che il destinatario sia umano e che i processi automatizzati non accedano al messaggio.

Chi gestisce questo servizio e perché è gratuito?

Siamo solo una coppia di ragazzi che a volte hanno dovuto affrontare la difficile situazione di non avere buone opzioni per proteggere la nostra privacy. Spesso ciò derivava dalla comunicazione con amici e familiari che non erano molto attenti a come gestivano i loro dispositivi e le informazioni. Altre volte ciò si verificava quando si utilizzavano forum basati sul web come Reddit o si utilizzavano sistemi di supporto basati sul web. Abbiamo trovato alcune soluzioni di messaggi temporanei basate sul Web, ma nessuna offriva E2EE, il che significava che non potevamo fidarci di loro. Quindi abbiamo appena creato la nostra soluzione e abbiamo deciso di darla via in modo che altri possano trarne vantaggio.

Come posso fidarmi delle risposte alle domande di cui sopra?

In realtà non dovresti fidarti di nessun sito web solo perché dice certe cose - in genere è una buona idea verificare eventuali affermazioni. Abbiamo cercato di rimuovere il requisito di fidarci il più possibile di noi utilizzando la crittografia end-to-end. Ad esempio, è abbastanza facile verificare che non possiamo leggere alcun messaggio poiché sono crittografati . Abbiamo anche mantenuto il codice javascript che esegue questo sito molto semplice in modo che sia facile da leggere e capire. Rendere tutto il codice open source consente alle persone di verificare cosa è in esecuzione; tuttavia, tieni presente che non c'è modo di verificare veramente cosa sta eseguendo il server. Sebbene sia vero che gran parte del requisito di fiducia viene rimosso con la crittografia end-to-end, è ancora un fattore che i nostri utenti pesano molto quando decidono di utilizzare questo servizio o meno.