Preguntas frecuentes

¿Por qué este sitio está mal traducido? ⎃

Lo siento, pero los autores actuales solo hablan inglés. Necesitamos ayuda para traducir este proyecto a otros idiomas. Como un medio sencillo y económico para poner este servicio a disposición de las personas que no hablan inglés, utilizamos la traducción automática. Los resultados suelen ser aceptables, pero pueden dar lugar a una redacción extraña o incluso a información completamente inexacta. Puede ayudarnos a mejorar la experiencia para todos: envíe la traducción correcta .

¿Qué tan seguro es este servicio?

Hemos tomado muchas medidas para que este servicio sea seguro para el uso previsto . Antes de repasar esos pasos, es importante comprender lo siguiente:

Nuestro objetivo es ofrecer este servicio de una manera que ofrezca opciones para mejorar su privacidad y seguridad. A continuación, se indican algunos pasos que hemos tomado para proteger su información:

¿Por qué recibí un enlace aquí con una opción para descifrar un mensaje?

Pedimos disculpas si hay errores en esta traducción . Este servicio simplemente pasa un mensaje encriptado de un punto a otro y usted es el destinatario. Pronto se borrará el mensaje. Los operadores de este servicio no tienen forma de leer el contenido del mensaje. Por lo general, alguien usa este servicio cuando no desea que el contenido de un mensaje permanezca dentro de varias bases de datos / dispositivos / servicios / archivos / etc. como es típico cuando se envía un correo electrónico / mensaje instantáneo / texto / etc. Si decide descifrar, tenga en cuenta lo siguiente:

¿Eliminas todo lo enviado a este sitio?

Fiel a nuestro logotipo de papelera ... todo se elimina poco después de recibirlo. La eliminación de todo está automatizada: se escribe en el servidor. Piénselo de esta manera: hay dos clases de información enviada:

En el caso de los mensajes, puedes controlar cuándo los eliminamos especificando: De forma predeterminada, todo lo relacionado con un mensaje se elimina después de que se recupera una vez o tiene 1 semana de antigüedad, lo que ocurra primero. Cuando se trata de eliminar toda la otra información inherente al envío de cualquier cosa en la web (es decir, su dirección IP, etc.), no le damos ningún control sobre cuándo o cómo se elimina, simplemente la eliminamos toda cada 24 horas. .

¿Por qué utilizar este servicio?

Este servicio es una herramienta para ayudar a que los mensajes que envíe / reciba sean menos permanentes. La mayor parte de lo que comunica en Internet (chats, mensajes de texto, correos electrónicos, etc.) se almacena y rara vez se elimina. A menudo, cuando elimina algo, en realidad no se elimina, sino que se marca como eliminado y ya no se muestra. Sus comunicaciones agregadas se acumulan año tras año en bases de datos y en dispositivos sobre los que no tiene control. Inevitablemente, una o más de las organizaciones / personas / dispositivos que almacenan sus comunicaciones son pirateadas y su información se filtra. Este problema es tan generalizado que ahora hay muchos sitios web que rastrean las organizaciones que se han visto comprometidas y han filtrado datos de usuarios. Los mensajes temporales cifrados de un extremo a otro son una solución simple para ayudar a que algunas de sus comunicaciones sean menos permanentes. Cada mensaje enviado a este sitio tiene un tiempo de vida que va de 1 minuto a 2 semanas; una vez transcurrido ese tiempo, el mensaje se elimina. Además, la configuración predeterminada es eliminar cualquier mensaje una vez que el destinatario lo haya recuperado. Además, todos los mensajes se cifran desde su dispositivo hasta el dispositivo del destinatario. El objetivo principal al utilizar el cifrado de extremo a extremo es eliminar nuestra capacidad de leer los mensajes enviados, eliminando así algunos de los requisitos de confianza. El resultado final es que ahora es fácil enviar un mensaje cifrado a través de un enlace simple. Ese mensaje se elimina poco después del envío o al recuperarlo. No es necesario instalar / configurar software especial. No tiene que crear una cuenta ni proporcionar ninguna información personal. El destinatario no tiene que estar en sus contactos o incluso conocer este servicio, el único requisito de que pueda hacer clic en un enlace.

¿Es este un servicio de mensajería?

No. Este servicio está diseñado para complementar los servicios de mensajería existentes, como mensajería instantánea, correo electrónico, texto, etc. agregando la capacidad de evitar que los mensajes enviados se almacenen durante mucho tiempo. No entregamos el enlace generado al destinatario .

¿Cuáles son los casos de uso previstos?

Entonces, ¿cuáles son algunos escenarios en los que es apropiado utilizar este servicio? Si bien todos tienen diferentes necesidades y requisitos en lo que respecta a su privacidad y seguridad, personalmente he encontrado los siguientes escenarios como casos de uso apropiados:

¿Para qué no debería utilizarse este servicio?

Este servicio no debe usarse para información muy sensible por todas las razones explicadas en estas preguntas frecuentes. A continuación se muestran algunos ejemplos de lo que no se debe hacer:

¿Por qué no usar PGP / Signal / OMEMO / Matrix / etc.?

Si conoce a la persona a la que desea enviar mensajes temporales seguros, envíelos con frecuencia, espere una interfaz similar a un chat y / o puede esperar que el destinatario tenga el software requerido y sepa cómo usarlo, este sitio web probablemente no sea el mejor solución. Existen excelentes opciones que son de código abierto, admiten E2EE, no basadas en la web, e incluso algunas como Signal que también admiten mensajes temporales. Yo personalmente uso un servidor XMMP privado y OMEMO para charlar con familiares y amigos cercanos. El uso de este sitio solo puede ser óptimo si no sabe qué software está ejecutando el destinatario, no sabe su número de teléfono / identificador de contacto, no conoce su competencia técnica (pero suponga que puede hacer clic en un enlace), o simplemente prefiere mantener el mensaje que envía fuera del transporte de comunicación subyacente.

¿Qué requisitos existen?

Se requiere un navegador web moderno y actualizado que implemente correctamente los estándares, incluida la API Web Crypto. Los ejemplos incluyen: Chrome, Firefox, Edge y Safari (alrededor de 2020 o después).

¿Puede el destinatario hacer una copia del mensaje?

Si. Aunque el mensaje puede borrarse a sí mismo al recuperarlo, el destinatario aún puede ver el mensaje. Siempre que el receptor pueda ver el mensaje por completo, se puede hacer una copia; esto se aplica a todas las comunicaciones. Existe una opción para que al destinatario le resulte más difícil hacer una copia. En este caso se implementan tres impedimentos para copiar:

Sin embargo, estas protecciones contra copias son débiles porque se pueden omitir. Además, el destinatario siempre puede simplemente tomar una captura de pantalla o una foto del mensaje.

¿Se recopila alguna información personal?

No admitimos cuentas de usuario (es decir, nombre de usuario / contraseña). No recopilamos ninguna información que pueda identificarlo (es decir, nombre / dirección / correo electrónico / teléfono). Es posible que alguna información personal pueda estar en el mensaje que está enviando, pero está encriptada y no tenemos forma de leerla. Revise nuestra política de privacidad para obtener detalles completos.

¿Qué información se registra?

Nuestro servidor web mantiene hasta 24 horas de formato de registro común en toda la actividad web. Esto incluye registrar la dirección IP completa de los clientes HTTP. Después de 24 horas, esta información registrada se elimina automáticamente. Todas las solicitudes enviadas a / api se envían por POST, lo que significa que el servidor web nunca registra información específica del mensaje. Además, cualquier información guardada en la base de datos se registra de manera efectiva. Todas las entradas de la base de datos, incluidas las direcciones IP anónimas y con hash, tienen un tiempo de vencimiento (TTL) después del cual se eliminan automáticamente. Los tiempos de vencimiento de TTL varían entre 1 minuto y 2 semanas.

¿Qué está haciendo para proteger los servidores?

La seguridad del servidor es una preocupación obvia. Hay dos áreas principales en las que nos enfocamos para mantenerlo seguro:

¿Qué riesgos de seguridad existen al utilizar este sitio?

Antes de abordar específicamente algunos de estos riesgos, creo que una analogía semi-breve podría ayudar a resumir los riesgos en el uso de cualquier comunicación por Internet. Visualice que cualquier sistema es tan seguro como el eslabón más débil de una cadena. Ahora imagine un escenario en el que hay dos personas en una habitación sellada sin medios para ver, escuchar o grabar nada de lo que hacen. Uno le pasará un mensaje al otro quien al leer el mensaje lo quemará. Si alguien fuera de esa sala desea obtener el mensaje que ya se transmitió, será difícil. ¿Cuál es el eslabón más débil para obtener el mensaje? No hay muchos enlaces para elegir, es una cadena bastante corta. Ahora imagine que cuando envía un mensaje en Internet, hay al menos un millón de enlaces en la cadena, muchos de ellos débiles, muchos de ellos completamente fuera de su control, y esa es la realidad.

El uso de cifrado puede ayudar enormemente con el problema del millón de enlaces mencionado anteriormente y es fácil dejarse llevar por la idea de que los sistemas E2EE bien diseñados ofrecen la solución definitiva. Sin embargo, ese pensamiento puede meterte en problemas, porque un atacante normalmente solo irá tras los enlaces más débiles del sistema. Por ejemplo, probablemente sea mucho más fácil controlar su teléfono o computadora y configurar un registrador de entrada para leer todo lo que escribe que descifrar mensajes cifrados por cable. La conclusión es que si tuviera la tarea de comunicar un secreto de vital importancia, solo usaría las comunicaciones electrónicas como último recurso.

Por lo tanto, existen riesgos de seguridad al usar cualquier comunicación, pero aún usa un navegador web para realizar operaciones bancarias, comprar cosas, correo electrónico, etc. Es un riesgo aceptado por las enormes comodidades que se obtienen. Realmente la pregunta es ... ¿qué riesgos de seguridad son semi-específicos de este sitio? Algunos me vienen a la mente:

¿Qué está haciendo con los ataques man-in-the-middle (MITM)?

Todos los usuarios de sitios web pueden ser potencialmente víctimas de un ataque MITM; este sitio no es diferente de todos los demás en la web en este sentido. Un ataque MITM ocurre cuando un atacante puede interceptar y modificar las comunicaciones entre el navegador del usuario y el servidor web del sitio. Esto permite al atacante modificar cualquier código / contenido del sitio sin dejar de parecerle al usuario final que es el sitio al que está acostumbrado. Tomamos algunas medidas para dificultar un ataque MITM:

Sin embargo, un ataque MITM todavía es posible, especialmente si el atacante controla la red / infraestructura de clave pública, como sería el caso de organizaciones grandes / poderosas o gobiernos. Ofrecemos extensiones de navegador que pueden ayudar a mitigar algunos riesgos de MITM.

¿Qué ventajas ofrecen las extensiones de navegador?

Ofrecemos extensiones de navegador como un medio para brindar comodidad y seguridad adicionales. En pocas palabras ... Las extensiones hacen que el envío de mensajes temporales sea más rápido y sencillo. También se gana algo de seguridad porque todo el código utilizado para cifrar y preparar un mensaje se almacena localmente dentro de la extensión. Debido a que el código se almacena localmente, esto ofrece al remitente cierta protección contra ataques MITM . Sin embargo, vale la pena señalar que, si bien las extensiones ofrecen más protección contra un ataque MITM que compromete el contenido del mensaje, un ataque MITM aún podría ser efectivo (es decir, para determinar la dirección IP del remitente si no se usa TOR / VPN / etc.).

¿Cómo puedo saber con certeza que todo lo enviado está cifrado de un extremo a otro?

A diferencia de muchos otros clientes de chat encriptados de extremo a extremo (E2EE), es bastante sencillo ver exactamente lo que se nos envía cuando envía un mensaje. El siguiente video tutorial demuestra cómo confirmar que no tenemos forma de descifrar los mensajes enviados al servidor.

Además, si lo piensas bien, siempre que no seamos una agencia secreta tratando de recopilar mensajes confidenciales, no hay ningún beneficio en que podamos descifrar mensajes, ya que tener esa capacidad solo nos crea problemas. Ni siquiera queremos almacenar mensajes; sin embargo, es un mal necesario entregarlos.

¿Cómo funciona el cifrado de extremo a extremo en este sitio?

En este momento, estamos utilizando cifrado simétrico (AES-GCM de 256 bits) con claves derivadas de contraseñas (mínimo de 150.000 iteraciones de PBKDF2 / SHA-256). El cifrado asimétrico no se utiliza porque existen requisitos para 1) el remitente que inicia la comunicación 2) el remitente y el destinatario no están en línea al mismo tiempo y 3) no hay información sobre el destinatario y 4) estamos tratando de mantener las cosas realmente simples y la administración de claves es Complicado. La API de cifrado web estándar se utiliza para todas las funciones criptográficas, incluido RNG. Básicamente, esto es lo que sucede:

  1. El usuario final elige una contraseña o una se genera automáticamente
  2. Se realiza una llamada a la API para obtener el número de iteraciones PBKDF2 / SHA-256 requeridas (este paso es necesario para el control de spam )
  3. Se genera una sal de 32 bytes
  4. Una clave se deriva de la sal y la contraseña.
  5. Se genera un vector de inicialización de 12 bytes (IV)
  6. El mensaje se cifra con la clave + IV
  7. El recuento de iteraciones, sal, IV y texto cifrado se envían al servidor (junto con otra información como TTL, RTL, etc.)
  8. El servidor devuelve una ID aleatoria que hace referencia al mensaje.
  9. Luego, el navegador presenta al usuario final un enlace que contiene el ID y la contraseña devueltos o un enlace sin la contraseña (en cuyo caso el destinatario debe conocer e ingresar la contraseña)
  10. Si la contraseña es parte del enlace, está en el hash de la URL y, por lo tanto, nunca se envía al servidor cuando el destinatario realiza la solicitud GET.
  11. Se le pregunta al destinatario si desea descifrar y ver el mensaje.
  12. El navegador realiza una solicitud especificando el ID del mensaje
  13. Si el remitente requiere que se complete un CAPTCHA, el destinatario es dirigido a otra URL para demostrar que es humano (una vez que pasa, se le devuelve)
  14. El servidor envía el mensaje cifrado y, de forma predeterminada, eliminará el mensaje en este punto si la lectura en vivo (RTL) es una
  15. El destinatario descifrará el mensaje con la contraseña (y se le pedirá la contraseña si no está en la URL)
Esta configuración es extremadamente simple y ofrece cifrado de mensajes desde el dispositivo del remitente al dispositivo del destinatario, pero por supuesto carece de la garantía que el cifrado asimétrico puede ofrecer en términos de saber que solo alguien en posesión de la clave privada del destinatario puede descifrar el mensaje. Cualquiera con el enlace puede abrir el mensaje en el escenario predeterminado en el que la contraseña es parte de la URL; esto subraya la importancia de utilizar un transporte adecuado para el enlace (es decir, correo electrónico / chat / texto / etc.) - una decisión que se deja a la remitente. Podemos, si hay interés, también implementar soporte para un esquema asimétrico muy básico por el cual el destinatario inicia una solicitud de un mensaje y envía ese enlace de solicitud al remitente del mensaje. Esta configuración eliminaría la necesidad de tener la contraseña en la URL, pero también elimina la posibilidad de que el remitente inicie.

¿La contraseña de descifrado puede estar en la URL?

Si. Esto obviamente afecta la seguridad porque si el método utilizado para enviar el enlace es inseguro, el mensaje es inseguro por asociación. Todas las soluciones para eliminar este problema introducen pasos y complejidades adicionales que afectan la experiencia del usuario (es decir, las cosas deben configurarse en ambos extremos antes de enviar el mensaje). Un esquema asimétrico mediante el cual el destinatario inicia una solicitud de un mensaje y envía ese enlace de solicitud podría funcionar con nuestro requisito clave de "todo es efímero"; esto puede implementarse. En última instancia, si dos partes se van a enviar mensajes entre sí con frecuencia, existen mejores soluciones asumiendo que ambas partes pueden manejar el uso de esas soluciones.

¿Pero la contraseña de descifrado no tiene que estar en la URL?

Correcto. Si la contraseña de descifrado no está incluida en el enlace, se le pedirá al destinatario la contraseña. Si la contraseña se comunica de forma segura al destinatario (o si ya la conocen), esto proporciona protección contra la interceptación. Sin embargo, la desventaja es que el destinatario debe conocer e ingresar correctamente la contraseña. Aquí hay una forma de enviar la contraseña al destinatario que ofrece cierta protección contra la interceptación:

  1. Cifre la contraseña en un mensaje con la configuración predeterminada y envíe este enlace al destinatario.
  2. Cuando el destinatario hace clic en el enlace y descifra el mensaje, sabe que nadie más ha obtenido la contraseña antes que él porque el mensaje que contiene la contraseña se elimina al recuperarlo. Sin embargo, si hay un ataque MITM activo o si su dispositivo o el dispositivo del destinatario se ha visto comprometido, es posible que otra parte pueda obtener la contraseña.
  3. Confirme con el destinatario que ha obtenido correctamente la contraseña. Por ejemplo, si el destinatario le informa que cuando fue a recuperar la contraseña, que el mensaje ya se había eliminado, entonces sabe que otra persona obtuvo la contraseña antes que el destinatario y que, por lo tanto, la contraseña está comprometida y no debe usarse.
  4. Con la contraseña que el destinatario confirmó que posee, ahora puede enviar un mensaje usando la misma contraseña para el cifrado; simplemente comparta la versión del enlace que no contiene la contraseña.

Eso es correcto: generamos el enlace y se lo dejamos al remitente cuál es la mejor manera de entregárselo al destinatario. El objetivo de este servicio es proporcionar una opción que ofrezca menos permanencia en los transportes de mensajes existentes como correo electrónico / chat / texto / etc. Por lo tanto, la expectativa es que el enlace que generamos que apunta al mensaje temporal se envíe a través de un transporte de mensajes existente. Esto tiene implicaciones de seguridad que los usuarios deben comprender. Tomemos un mensaje de texto SMS como ejemplo, ya que este es un método de comunicación bastante inseguro. Cuando utiliza este servicio para enviar un enlace de mensaje temporal a través de un mensaje de texto, si utiliza el modo predeterminado en el que se incluye la contraseña en el enlace, cualquiera que tenga el enlace puede leer el mensaje y no se ofrece protección contra la interceptación. Este servicio aún proporciona una comunicación más temporal que puede mejorar la privacidad y la seguridad. Además, puede optar por enviar el enlace sin la contraseña y esto proporcionará protección contra la interceptación.

¿Cómo puedo proteger mi privacidad tanto como sea posible mientras utilizo este servicio?

Como se discutió en otra parte de estas preguntas frecuentes, aunque ya hacemos mucho para proteger su privacidad y aunque no recopilamos ninguna información personal, nosotros y otros enviamos y recopilamos cierta información relacionada con el registro en virtud de que usted utiliza un navegador web. Sin embargo, existen múltiples formas de proteger aún más su privacidad. Una forma de uso gratuito, basada en software de código abierto, y que funciona bastante bien es utilizar el navegador Tor . Este navegador está diseñado para proteger su privacidad en varios niveles, incluido el uso de la red Tor . Nuestro sitio ya es accesible a través de la red Tor onion, lo que significa que acceder a nuestro sitio a través de Tor no requiere el uso de un nodo de salida, lo que niega a alguien que espíe el tráfico del nodo de salida . Sin embargo, tenga en cuenta que incluso en este escenario, su ISP puede ver que está usando Tor, aunque no para qué. Incluso puede conectarse a una VPN y luego iniciar el navegador Tor para obtener dos capas de anonimato; sin embargo, tenga en cuenta que su ISP aún puede ver que está usando una VPN en este escenario, aunque no para qué. Si no desea que su ISP sepa qué protocolos está utilizando, puede conectarse a una gran red WiFi pública, como una biblioteca, escuela, etc. y luego usar el navegador Tor.

¿Qué pasa si no confío en los Estados Unidos?

Nuestros servidores están ubicados en los Estados Unidos. Además, nuestro proveedor de CDN, Cloudflare, es una empresa con sede en Estados Unidos. Hemos tratado de eliminar la necesidad de confiar en nosotros o en el país en el que residen nuestros servidores simplemente porque no recopilamos información personal, no podemos descifrar ningún mensaje y todo se elimina poco después de recibirlo. Sin embargo, podemos entender cierta desconfianza ya que está basado en la web y especialmente si vives en ciertos países. Tenemos algunos planes para ofrecer opciones en Islandia y Suiza para las personas que tienen dificultades para confiar en EE. UU. Háganos saber si esto se aplica a usted, ya que no estaremos motivados para ofrecer alternativas a menos que exista una demanda real.

¿Qué está haciendo para evitar el spam?

Cada vez que permites que alguien publique un mensaje que se pueda transmitir a través de un enlace, invitas a los spammers. Frenar este problema no es del todo sencillo. No queremos cargar un CAPTCHA de terceros como parte del proceso de envío de mensajes por algunas razones:

Posiblemente podríamos solucionar el problema de la API mediante el uso de algún sistema de claves API, pero luego tenemos que recopilar información del usuario que no queremos hacer. Además, ¿qué puede evitar que los spammers obtengan muchas claves API? No podemos examinar los mensajes para inferir su spam (que es muy problemático en el mejor de los casos) ya que, además de cifrar los mensajes, tenemos una política de no intervención en el contenido de los mensajes. Dados estos requisitos, empleamos dos métodos para prevenir el spam: Si sabe que los spammers abusan de este servicio, presente un informe de abuso .

¿Por qué hay una opción para exigir al destinatario que complete un CAPTCHA?

Si bien es cierto que no nos gustan los CAPTCHA, reconocemos que tienen un propósito y tienen un tiempo y un lugar (al menos por ahora). Esta es una forma sencilla para que el remitente obtenga cierta seguridad de que el destinatario es un ser humano y que los procesos automatizados no están accediendo al mensaje.

¿Quién administra este servicio y por qué es gratuito?

Somos solo un par de personas que a veces nos enfrentamos a la difícil situación de no tener buenas opciones para ayudar a proteger nuestra privacidad. A menudo, esto se debe a la comunicación con amigos y familiares que no tienen mucho cuidado con la forma en que manejan sus dispositivos e información. En otras ocasiones, esto se produjo al usar foros basados en la web como Reddit o al usar sistemas de soporte basados en la web. Encontramos algunas soluciones de mensajes temporales basadas en la web, pero ninguna ofrecía E2EE, lo que significaba que no podíamos confiar en ellas. Así que creamos nuestra propia solución y decidimos regalarla para que otros puedan beneficiarse de ella.

¿Cómo puedo confiar en las respuestas a las preguntas anteriores?

Realmente no debe confiar en ningún sitio web solo porque dice ciertas cosas; por lo general, es una buena idea verificar cualquier afirmación. Hemos tratado de eliminar el requisito de confiar en nosotros tanto como sea posible mediante el uso de cifrado de extremo a extremo. Por ejemplo, es bastante fácil auditar que no podemos leer ningún mensaje ya que están encriptados . También hemos mantenido el código javascript que ejecuta este sitio muy simple para que sea fácil de leer y comprender. Hacer que todo el código sea de código abierto permite a las personas verificar qué se está ejecutando; sin embargo, tenga en cuenta que no hay forma de verificar realmente qué está ejecutando el servidor. Si bien es cierto que gran parte del requisito de confianza se elimina con el cifrado de extremo a extremo, sigue siendo un factor que nuestros usuarios pesan mucho a la hora de decidir utilizar este servicio o no.