perguntas frequentes

Por que este site está mal traduzido? ⎃

Desculpe, mas os autores atuais falam apenas inglês. Precisamos de ajuda para traduzir este projeto para outras línguas. Como um meio simples e econômico de disponibilizar este serviço para pessoas que não falam inglês, utilizamos a tradução automática. Os resultados são geralmente aceitáveis, mas podem resultar em palavras estranhas ou mesmo em informações totalmente imprecisas. Você pode nos ajudar a melhorar a experiência para todos - envie a tradução correta .

Quão seguro é este serviço?

Tomamos muitas medidas para tornar este serviço seguro para o uso pretendido . Antes de passarmos por essas etapas, é importante compreender o seguinte:

Nosso objetivo é oferecer este serviço de uma forma que ofereça opções para aprimorar sua privacidade e segurança. Aqui estão algumas etapas que tomamos para proteger suas informações:

Por que recebi um link aqui com uma opção para descriptografar uma mensagem?

Pedimos desculpas se houver erros nesta tradução . Este serviço simplesmente passa uma mensagem criptografada de um ponto para outro e você é o destinatário. A mensagem será excluída em breve. Os operadores deste serviço não têm como ler o conteúdo da mensagem. Normalmente alguém usa este serviço quando não deseja que o conteúdo de uma mensagem permaneça dentro de vários bancos de dados / dispositivos / serviços / arquivos / etc. como é típico ao enviar um e-mail / mensagem instantânea / texto / etc. Se você decidir descriptografar, lembre-se do seguinte:

Você excluiu tudo o que foi enviado para este site?

Fiel ao nosso logotipo de lata de lixo ... tudo é excluído logo após o recebimento. A exclusão de tudo é automatizada - é gravada no servidor. Pense desta forma - há duas classes de informações enviadas:

No caso das mensagens, você pode controlar quando as excluímos especificando: Por padrão, tudo sobre uma mensagem é excluído depois que ela é recuperada uma vez ou completa 1 semana - o que ocorrer primeiro. Quando se trata de excluir todas as outras informações inerentes ao envio de qualquer coisa na web (ou seja, seu endereço IP, etc.), não oferecemos nenhum controle sobre quando ou como ela é excluída - apenas excluímos tudo a cada 24 horas .

Por que usar este serviço?

Este serviço é uma ferramenta para ajudar a tornar as mensagens enviadas / recebidas menos permanentes. A maior parte do que você comunica na Internet (bate-papos, mensagens de texto, e-mails, etc.) é armazenado e raramente excluído. Muitas vezes, quando você exclui algo, não é realmente excluído, mas sim marcado como excluído e não é mais exibido para você. Suas comunicações agregadas se acumulam ano após ano em bancos de dados e em dispositivos sobre os quais você não tem controle. Inevitavelmente, uma ou mais organizações / pessoas / dispositivos que armazenam suas comunicações são hackeadas e suas informações vazam. Esse problema é tão difundido que agora existem muitos sites que rastreiam as organizações que foram comprometidas e vazaram dados de usuários. Mensagens temporárias criptografadas de ponta a ponta são uma solução simples para ajudar a tornar algumas de suas comunicações menos permanentes. Cada mensagem enviada a este site tem um tempo de vida que varia de 1 minuto a 2 semanas - depois que esse tempo passa, a mensagem é excluída. Além disso, a configuração padrão é excluir qualquer mensagem assim que o destinatário a tiver recuperado. Além disso, todas as mensagens são criptografadas do seu dispositivo até o dispositivo do destinatário. O principal objetivo ao utilizar a criptografia de ponta a ponta é remover nossa capacidade de ler qualquer mensagem enviada, removendo assim alguns dos requisitos de confiança. O resultado final é que agora é fácil enviar uma mensagem criptografada por meio de um link simples. Essa mensagem é excluída logo após o envio ou na recuperação. Você não precisa instalar / configurar software especial. Você não precisa criar uma conta ou fornecer qualquer informação pessoal. O destinatário não precisa estar em seus contatos ou mesmo saber sobre este serviço - o único requisito é que ele pode clicar em um link.

Este é um serviço de mensagens?

Não. Este serviço foi projetado para complementar os serviços de mensagens existentes, como mensagens instantâneas / e-mail / texto / etc. adicionando a capacidade de impedir que as mensagens enviadas sejam armazenadas por um longo tempo. Não entregamos o link gerado ao destinatário .

Quais são os casos de uso pretendidos?

Então, quais são alguns cenários em que é apropriado usar este serviço? Embora todos tenham necessidades e requisitos diferentes no que diz respeito à privacidade e segurança, eu pessoalmente descobri os seguintes cenários como casos de uso apropriados:

Para que este serviço não deve ser usado?

Este serviço não deve ser usado para informações muito sensíveis por todos os motivos explicados neste FAQ. Abaixo estão alguns exemplos do que não fazer:

Por que não usar PGP / Signal / OMEMO / Matrix / etc.?

Se você conhece a pessoa para a qual deseja enviar mensagens temporárias seguras, envie-as com frequência, espere uma interface semelhante a um bate-papo e / ou pode esperar que o destinatário tenha o software necessário e saiba como usá-lo, este site provavelmente não é o melhor solução. Existem ótimas opções que são open source, suportam E2EE, não baseadas na web, e até mesmo algumas como Signal que também suportam mensagens temporárias. Eu pessoalmente uso um servidor XMMP privado e OMEMO para conversar com amigos próximos e familiares. O uso deste site só pode ser ideal se você não souber qual software o destinatário está executando, não souber seu número de telefone / nome de contato, não souber sua proficiência técnica (mas suponha que ele pode clicar em um link), ou você apenas prefere manter a mensagem enviada fora do transporte de comunicação subjacente.

Que requisitos existem?

É necessário um navegador da Web moderno e atualizado que implemente adequadamente os padrões, incluindo a API Web Crypto. Os exemplos incluem: Chrome, Firefox, Edge e Safari (por volta de 2020 ou depois).

O destinatário pode fazer uma cópia da mensagem?

sim. Mesmo que a mensagem possa se excluir após a recuperação, o destinatário ainda pode ver a mensagem. Sempre que o destinatário puder visualizar completamente a mensagem, uma cópia pode ser feita - isso se aplica a todas as comunicações. Existe a opção de tornar mais difícil para o destinatário fazer uma cópia. Neste caso, três impedimentos para a cópia são implementados:

No entanto, essas proteções contra cópia são fracas porque podem ser ignoradas. Além disso, o destinatário sempre pode simplesmente tirar uma captura de tela ou uma foto da mensagem.

Alguma informação pessoal é coletada?

Não oferecemos suporte a contas de usuário (ou seja, nome de usuário / senha). Não coletamos nenhuma informação que possa identificá-lo (ou seja, nome / endereço / e-mail / telefone). É possível que alguma informação pessoal esteja na mensagem que você está enviando, mas ela está criptografada e não temos como lê-la. Por favor, reveja nossa política de privacidade para detalhes completos.

Quais informações são registradas?

Nosso servidor da web mantém até 24 horas de formato de registro comum em todas as atividades da web. Isso inclui o registro do endereço IP completo de clientes HTTP. Após 24 horas, essas informações registradas são excluídas automaticamente. Todas as solicitações enviadas para / api são postadas, o que significa que nenhuma informação específica da mensagem é registrada pelo servidor da web. Além disso, qualquer informação salva no banco de dados é efetivamente registrada. Todas as entradas no banco de dados, incluindo endereços IP anônimos e com hash, têm um tempo de expiração (TTL) após o qual são excluídos automaticamente. Os tempos de expiração TTL variam entre 1 minuto e 2 semanas.

O que você está fazendo para proteger os servidores?

A segurança do servidor é uma preocupação óbvia. Existem duas áreas principais nas quais nos concentramos para mantê-lo seguro:

Quais riscos de segurança estão presentes ao usar este site?

Antes de abordar especificamente alguns desses riscos, acho que uma analogia semi-breve pode ajudar a resumir os riscos do uso de qualquer comunicação pela Internet. Visualize que qualquer sistema é tão seguro quanto o elo mais fraco de uma cadeia. Agora imagine um cenário em que há duas pessoas em uma sala lacrada sem meios para ver, ouvir ou registrar qualquer coisa que façam. Um passará uma mensagem para o outro, que ao ler a mensagem a queimará. Se alguém de fora daquela sala deseja obter a mensagem que já foi passada, isso vai ser difícil. Qual é o elo mais fraco para obter a mensagem? Não há muitos links para escolher - é uma cadeia bem curta. Agora imagine que, quando você envia uma mensagem pela Internet, há pelo menos um milhão de elos na cadeia - muitos deles fracos - muitos deles completamente fora de seu controle - e isso é realidade.

O uso da criptografia pode ajudar muito com o problema de link acima de um milhão e é fácil ser levado a pensar que sistemas E2EE bem projetados oferecem a solução completa. No entanto, esse pensamento pode causar problemas, porque um invasor geralmente irá apenas atrás dos elos mais fracos do sistema. Por exemplo, provavelmente é muito mais fácil assumir o controle do seu telefone ou computador e configurar um registrador de entrada para apenas ler tudo o que você digita do que quebrar mensagens criptografadas pela rede. O resultado final é que, se eu fosse encarregado de comunicar um segredo de importância vital / crítica, usaria as comunicações eletrônicas apenas como último recurso.

Portanto, há riscos de segurança em qualquer comunicação, mas você ainda usa um navegador da web para transações bancárias, compras, e-mail, etc. É um risco aceito pelas enormes conveniências obtidas. A verdadeira questão é ... quais riscos de segurança são semi-específicos para este site? Alguns vêm à mente:

O que você está fazendo sobre ataques man-in-the-middle (MITM)?

Todos os usuários de sites podem ser vítimas de um ataque MITM - este site não é diferente de todos os outros na web a esse respeito. Um ataque MITM ocorre quando um invasor consegue interceptar e modificar as comunicações entre o navegador do usuário e o servidor da web do site. Isso permite que o invasor modifique qualquer código / conteúdo do site enquanto ainda parece para o usuário final ser o site ao qual está acostumado. Tomamos algumas medidas para tornar um ataque MITM mais difícil:

No entanto, um ataque MITM ainda é sempre possível - especialmente se o invasor controlar a infraestrutura de rede / chave pública, como seria o caso de organizações grandes / poderosas ou governos. Oferecemos extensões de navegador que podem ajudar a mitigar alguns riscos MITM.

Quais vantagens as extensões do navegador oferecem?

Oferecemos extensões de navegador como um meio de fornecer conveniência extra e segurança adicional. Simplificando ... As extensões tornam o envio de mensagens temporárias mais rápido e fácil. Alguma segurança também é obtida porque todo o código usado para criptografar e preparar uma mensagem é armazenado localmente na extensão. Como o código é armazenado localmente, isso oferece ao remetente alguma proteção contra ataques MITM . No entanto, vale ressaltar que, embora as extensões ofereçam mais proteção contra um ataque MITM que comprometa o conteúdo da mensagem, um ataque MITM ainda pode ser eficaz (ou seja, para determinar o endereço IP do remetente se não estiver usando TOR / VPN / etc.).

Como posso saber com certeza se tudo o que foi enviado está criptografado de ponta a ponta?

Ao contrário de muitos outros clientes de bate-papo criptografados de ponta a ponta (E2EE) populares, é bastante simples ver exatamente o que é enviado para nós quando você envia uma mensagem. O tutorial em vídeo a seguir demonstra como confirmar que não temos como descriptografar as mensagens enviadas para o servidor.

Além disso, se você pensar sobre isso, contanto que não sejamos uma agência secreta tentando coletar mensagens confidenciais, não há nenhum benefício em sermos capazes de descriptografar mensagens, pois ter essa capacidade apenas cria problemas para nós. Não queremos nem armazenar mensagens - é um mal necessário entregá-las, no entanto.

Como a criptografia de ponta a ponta funciona neste site?

No momento, estamos utilizando criptografia simétrica (AES-GCM 256 bits) com chaves derivadas de senhas (mínimo de 150.000 iterações de PBKDF2 / SHA-256). A criptografia assimétrica não é usada porque existem requisitos para 1) remetente iniciar a comunicação 2) remetente e destinatário não estarem online ao mesmo tempo e 3) nenhuma informação sobre o destinatário e 4) estamos tentando manter as coisas bem simples e o gerenciamento de chaves é complicado. A API Web Crypto padrão é usada para todas as funcionalidades criptográficas, incluindo RNG. Basicamente, aqui está o que acontece:

  1. O usuário final escolhe uma senha ou uma é gerada automaticamente
  2. Uma chamada de API é feita para obter o número de iterações PBKDF2 / SHA-256 necessárias ( esta etapa é necessária para o controle de spam )
  3. Um sal de 32 bytes é gerado
  4. Uma chave é derivada do salt e da senha
  5. Um vetor de inicialização de 12 bytes (IV) é gerado
  6. A mensagem é criptografada usando a chave + IV
  7. A contagem de iteração, salt, IV e texto cifrado são enviados ao servidor (junto com algumas outras informações, como TTL, RTL, etc.)
  8. O servidor retorna um ID aleatório referente à mensagem
  9. O navegador, então, apresenta ao usuário final um link que contém o ID e a senha retornados ou um link sem a senha (neste caso, o destinatário deve saber e inserir a senha)
  10. Se a senha fizer parte do link, ela estará no hash da URL e, portanto, nunca será enviada ao servidor quando o destinatário fizer a solicitação GET
  11. O destinatário é questionado se deseja descriptografar e ver a mensagem
  12. O navegador faz uma solicitação especificando o ID da mensagem
  13. Se o remetente exigir que um CAPTCHA seja preenchido, o destinatário será direcionado para outro URL para provar que é humano (assim que passar, será direcionado de volta)
  14. O servidor envia a mensagem criptografada e, por padrão, exclui a mensagem neste ponto se o read-to-live (RTL) for um
  15. O destinatário irá descriptografar a mensagem com a senha (e a senha será solicitada se não estiver no URL)
Esta configuração é extremamente simples e oferece criptografia de mensagem do dispositivo do remetente para o dispositivo do destinatário, mas obviamente não tem a garantia que a criptografia assimétrica pode oferecer em termos de saber que apenas alguém em posse da chave privada do destinatário pode descriptografar a mensagem. Qualquer pessoa com o link pode abrir a mensagem no cenário padrão em que a senha faz parte da URL - isso ressalta a importância de usar um transporte apropriado para o link (ou seja, e-mail / chat / texto / etc.) - uma decisão deixada para o remetente. Podemos, se houver interesse, também implementar suporte para um esquema assimétrico muito básico, por meio do qual o destinatário inicia uma solicitação de uma mensagem e envia esse link de solicitação ao remetente da mensagem. Essa configuração eliminaria a necessidade de ter a senha no URL, mas também elimina a capacidade de o remetente iniciar.

A senha de descriptografia pode estar no URL?

sim. Isso obviamente impacta a segurança porque se o método usado para enviar o link for inseguro, a mensagem será insegura por associação. Todas as soluções alternativas para eliminar esse problema apresentam etapas e complexidades adicionais que afetam a experiência do usuário (ou seja, as coisas devem ser configuradas em ambas as extremidades antes de enviar a mensagem). Um esquema assimétrico em que o destinatário inicia uma solicitação de mensagem e envia o link de solicitação poderia funcionar com nosso requisito de chave "tudo é efêmero" - isso pode ser implementado. Em última análise, se duas partes vão enviar mensagens uma para a outra com frequência, existem soluções melhores, supondo que ambas as partes possam lidar com o uso dessas soluções.

Mas a senha de descriptografia não precisa estar na URL?

Correto. Se a senha de descriptografia não estiver incluída no link, será solicitada a senha ao destinatário. Se a senha for comunicada com segurança ao destinatário (ou se ele já souber), isso fornecerá proteção contra interceptação. No entanto, a desvantagem é que o destinatário deve saber e inserir corretamente a senha. Esta é uma maneira de enviar a senha ao destinatário, que oferece alguma proteção contra interceptação:

  1. Criptografe a senha em uma mensagem com as configurações padrão e envie este link ao destinatário.
  2. Quando o destinatário clica no link e descriptografa a mensagem, ele sabe que ninguém mais obteve a senha antes dele, porque a mensagem que contém a senha é excluída após a recuperação. No entanto, se houver um ataque MITM ativo ou se o seu dispositivo ou o dispositivo do destinatário tiver sido comprometido, ainda é possível que outra parte obtenha a senha.
  3. Confirme com o destinatário se ele obteve a senha com sucesso. Por exemplo, se o destinatário informar que, ao tentar recuperar a senha, a mensagem já foi excluída, você sabe que outra pessoa obteve a senha antes do destinatário e que a senha está, portanto, comprometida e não deve ser usada.
  4. Usando a senha que o destinatário confirmou que possui, agora você pode enviar uma mensagem usando a mesma senha para criptografia - basta compartilhar a versão do link que não contém a senha.

Isso é correto - nós geramos o link e deixamos para o remetente a melhor forma de entregá-lo ao destinatário. O objetivo deste serviço é fornecer uma opção que ofereça menos permanência nos transportes de mensagens existentes como e-mail / chat / texto / etc. Portanto, a expectativa é que o link que geramos, que aponta para a mensagem temporária, seja enviado por meio de um transporte de mensagem existente. Isso tem implicações de segurança que os usuários devem entender. Vamos pegar uma mensagem de texto SMS como exemplo, já que esse é um método de comunicação bastante inseguro. Quando você usa esse serviço para enviar um link de mensagem temporária por mensagem de texto, se usar o modo padrão em que a senha é incluída no link, qualquer pessoa com o link pode ler a mensagem e nenhuma proteção contra interceptação é oferecida. Este serviço ainda fornece uma comunicação mais temporária que pode aumentar a privacidade e a segurança. Além disso, você pode optar por enviar o link sem a senha e isso fornecerá proteção contra interceptação.

Como posso proteger minha privacidade o máximo possível enquanto uso este serviço?

Conforme discutido em outro lugar neste FAQ, embora já façamos muito para proteger sua privacidade e mesmo que não coletemos nenhuma informação pessoal, algumas informações relacionadas ao log são enviadas e coletadas por nós e por outros através do uso de um navegador da web. No entanto, existem várias maneiras de proteger ainda mais sua privacidade. Uma forma de uso gratuito, baseada em software de código aberto, e que funciona muito bem, é usar o navegador Tor . Este navegador foi projetado para proteger sua privacidade em vários níveis - incluindo o uso da rede Tor . Nosso site já está acessível através da rede Tor onion, o que significa que o acesso ao nosso site através do Tor não requer o uso de um nó de saída, o que impede que alguém escute o tráfego do nó de saída . No entanto, tenha em mente que mesmo neste cenário, seu ISP pode ver que você está usando o Tor - embora não para quê. Você pode até mesmo se conectar a uma VPN e, em seguida, iniciar o navegador Tor para duas camadas de anonimato; no entanto, lembre-se de que seu ISP ainda pode ver que você está usando uma VPN neste cenário - embora não para quê. Se você não quiser que seu ISP saiba quais protocolos você está usando, você pode se conectar a uma grande rede WiFi pública, como uma biblioteca, escola, etc. e, em seguida, usar o navegador Tor.

E se eu não confiar nos Estados Unidos?

Nossos servidores estão localizados nos Estados Unidos. Além disso, nosso provedor de CDN, Cloudflare, é uma empresa com sede nos Estados Unidos. Tentamos eliminar a necessidade de confiar em nós ou no país em que nossos servidores residem, simplesmente porque não coletamos informações pessoais, não podemos descriptografar nenhuma mensagem e tudo é excluído logo após o recebimento. No entanto, podemos entender alguma desconfiança, uma vez que é baseado na web e especialmente se você mora em determinados países. Temos alguns planos de oferecer opções na Islândia e na Suíça para pessoas que têm dificuldade em confiar nos Estados Unidos. Por favor, deixe-nos saber se isso se aplica a você, uma vez que não estaremos motivados para oferecer alternativas a menos que haja uma demanda real.

O que você está fazendo para evitar spam?

Sempre que você permite que alguém poste uma mensagem que pode ser retransmitida por meio de um link, você convida spammers. Limitar esse problema não é totalmente simples. Não queremos carregar um CAPTCHA de terceiros como parte do processo de envio da mensagem por alguns motivos:

Poderíamos possivelmente contornar o problema da API usando algum sistema de chave da API, mas então temos que coletar informações do usuário, o que não queremos fazer. Além disso, o que impede os spammers de obterem muitas chaves de API? Não podemos examinar as mensagens para inferir seu spam (o que é muito problemático na melhor das hipóteses), pois, além de criptografar as mensagens, temos uma política de interceptação no conteúdo das mensagens. Dados esses requisitos, empregamos dois métodos para prevenir spam: Se você está ciente de que os spammers estão abusando deste serviço, envie uma denúncia de abuso .

Por que existe a opção de exigir que o destinatário preencha um CAPTCHA?

Embora seja verdade que não gostamos de CAPTCHAs, reconhecemos que eles têm um propósito e têm um tempo e um lugar (pelo menos por agora). Essa é uma maneira simples de o remetente obter alguma garantia de que o destinatário é humano e de que os processos automatizados não estão acessando a mensagem.

Quem está executando este serviço e por que é gratuito?

Somos apenas um casal que às vezes se depara com a situação difícil de não ter boas opções para ajudar a proteger nossa privacidade. Muitas vezes, isso resultava da comunicação com amigos e familiares que não tomavam muito cuidado com a forma como lidavam com seus dispositivos e informações. Outras vezes, isso acontecia quando se usava fóruns baseados na web como o Reddit ou sistemas de suporte baseados na web. Encontramos algumas soluções de mensagens temporárias baseadas na web, mas nenhuma oferecia E2EE, o que significava que não podíamos confiar nelas. Então, acabamos de construir nossa própria solução e decidimos distribuí-la para que outras pessoas possam se beneficiar dela.

Como posso confiar nas respostas às perguntas acima?

Na verdade, você não deve confiar em nenhum site apenas porque ele diz certas coisas - normalmente é uma boa ideia verificar quaisquer afirmações. Tentamos remover a exigência de confiar em nós o máximo possível por meio do emprego de criptografia ponta a ponta. Por exemplo, é muito fácil auditar que não podemos ler nenhuma mensagem, pois elas estão criptografadas . Também mantivemos o código javascript executando este site de forma muito simples para que seja fácil de ler e entender. Tornar todo o código fonte aberto permite que as pessoas verifiquem o que está sendo executado; no entanto, lembre-se de que não há como verificar de fato o que o servidor está executando. Embora seja verdade que muitos dos requisitos de confiança são removidos com a criptografia ponta a ponta, ainda é um fator que nossos usuários pesam muito ao decidir usar este serviço ou não.