Solicitudes legales y transparencia
Qué puede — y qué no puede — entregar AegisLink en respuesta a una orden legal.
Traducción de cortesía. En caso de discrepancia, prevalece la versión en inglés.
Esta página existe para que usuarios, periodistas y autoridades conozcan la respuesta antes de que nadie pregunte. Está escrita a partir de la arquitectura del sistema, que es de código abierto y verificable de forma independiente: la respuesta honesta a la mayoría de las solicitudes es que los datos no existen, no que nos neguemos a entregarlos.
La versión corta
AegisLink está diseñado para que el operador guarde lo más parecido a nada que sea posible. No podemos descifrar mensajes, no conocemos los nombres, números de teléfono ni direcciones de correo electrónico de los usuarios (nunca los recopilamos) y no guardamos registros de quién habla con quién, cuándo ni con qué frecuencia. Un requerimiento judicial no puede obligarnos a entregar registros que nunca se crearon.
Lo que NO tenemos
| Lo que se suele pedir | Nuestra respuesta |
|---|
| Nombre real, número de teléfono o correo electrónico del usuario | Nunca se recopilan. El registro crea un par de claves en el dispositivo del usuario; no se piden datos personales en ningún momento. |
| Contenido de los mensajes | No podemos descifrarlo. Todos los mensajes están cifrados de extremo a extremo (X3DH + Double Ratchet); las claves privadas solo existen en los dispositivos de los usuarios. |
| Adjuntos, contenido de las llamadas de voz/vídeo | No podemos descifrarlos. Los adjuntos se cifran en el cliente; las llamadas son entre pares con DTLS-SRTP, y la señalización de las llamadas se sella antes de llegar al relay. |
| Listas de contactos / grafo social | No se almacenan. Los contactos viven solo en el dispositivo del usuario. El relay enruta sobres cifrados individuales y no guarda ningún registro de las relaciones. |
| Historial de mensajes | No se almacena. El relay guarda en cola un mensaje cifrado solo hasta que se entrega, y después lo elimina. |
| Registros de acceso, registros de IP, horas de inicio de sesión | No se registran, por configuración y por diseño (access_log off; la aplicación no guarda registros de acceso por usuario). |
| Registros de frecuencia de mensajes / de análisis de tráfico | No se almacenan. Además, los mensajes se rellenan hasta tamaños fijos por tramos, así que incluso los textos cifrados almacenados filtran una información mínima. |
| Datos de ubicación | Nunca se recopilan. La app no pide permisos de ubicación. |
| Información de pago | No aplica. La app es gratuita y no tiene pagos ni cuentas; las donaciones voluntarias se hacen en una página web externa y no se vinculan a ninguna identidad. |
Lo que SÍ tenemos (lista completa)
Ser honestos sobre lo que queda importa más que un mensaje de marketing impecable:
- Material de clave pública: claves públicas de identidad, prekeys firmadas y prekeys de un solo uso que publican los dispositivos para que otros puedan iniciar sesiones cifradas. Es material criptográfico público por diseño.
- Sobres cifrados no entregados: textos cifrados opacos en cola para destinatarios sin conexión, que se eliminan al entregarse. No podemos leerlos.
- Tokens de push: un token de push de Apple (APNs) o de Google (FCM), entregado directamente o a través del servicio push de Expo, por cada dispositivo que quiera recibir notificaciones de activación. El contenido del push nunca incluye contenido ni la identidad del remitente — es un "despierta" genérico. El token lo guarda la infraestructura de Google/Apple, como en cualquier app que use push.
- Datos de conexión transitorios: la app llega al relay a través de Tor, así que el relay ve un circuito de Tor y no la dirección IP del usuario. Nuestros servidores sí ven la IP de las peticiones que llegan por internet normal (como las visitas a esta web) y, durante una llamada, la de los dispositivos que usan nuestro servidor TURN, solo mientras dura la petición o la llamada. Se guarda en memoria para limitar abusos, no se escribe en registros de acceso y nunca se asocia a una identidad.
Nuestros compromisos
- Nunca añadiremos una puerta trasera, custodia de claves (key escrow) ni escaneo en el cliente. Los clientes son GPL-3.0 y el relay es AGPL-3.0 — un servidor modificado debe publicar su código fuente, y de todos modos el protocolo trata al servidor como no confiable: ni siquiera un relay totalmente malicioso puede leer mensajes ni falsificar identidades (ver PROTOCOL.md, modelo de amenazas).
- Responderemos a los requerimientos legales válidos con lo que existe — que es la lista anterior — y no inventaremos capacidades que no tenemos.
- Cuando la ley lo permita, notificaremos a los usuarios afectados las solicitudes que les conciernan y publicaremos estadísticas agregadas sobre las solicitudes recibidas.
- Si alguna vez se nos obliga legalmente a cambiar algo de lo anterior, lo diremos en la máxima medida que permita la ley. Sin embargo, la garantía más fuerte es estructural: cualquiera puede montar su propio relay y no quedar sujeto a ningún operador.
Verifica, no confíes
Cada afirmación de esta página se puede comprobar en el código fuente: el relay (server/), la capa de eliminación de metadatos y relleno (mobile/src/crypto/metadata.ts) y el documento del protocolo (PROTOCOL.md). Si encuentras una discrepancia entre esta página y el código, es un problema de seguridad — repórtalo a través de SECURITY.md.
Contacto para requerimientos legales: aegislink.report@gmail.com
Legal Requests & Transparency
What AegisLink can — and cannot — produce in response to a legal order.
This page exists so that users, journalists and authorities all know the answer before anyone asks. It is written from the system's architecture, which is open source and independently verifiable: the honest answer to most requests is that the data does not exist, not that we refuse to hand it over.
The short version
AegisLink is designed so that the operator holds as close to nothing as possible. We cannot decrypt messages, we do not know users' names, phone numbers or email addresses (we never collect them), and we do not keep logs of who talks to whom, when, or how often. A subpoena cannot compel us to produce records that were never created.
What we do NOT have
| Commonly requested | Our answer |
|---|
| User's real name, phone number, email | Never collected. Registration creates a keypair on the user's device; no personal data is requested at any point. |
| Message content | Cannot decrypt. All messages are end-to-end encrypted (X3DH + Double Ratchet); private keys exist only on user devices. |
| Attachments, voice/video call content | Cannot decrypt. Attachments are encrypted client-side; calls are peer-to-peer with DTLS-SRTP, and call signaling is sealed before it reaches the relay. |
| Contact lists / social graph | Not stored. Contacts live only on the user's device. The relay routes individual encrypted envelopes and keeps no record of relationships. |
| Message history | Not stored. The relay queues an encrypted message only until it is delivered, then deletes it. |
| Access logs, IP logs, login timestamps | Not logged, by configuration and by design (access_log off; the application keeps no per-user access records). |
| Message frequency / traffic analysis records | Not stored. Additionally, messages are padded to fixed size buckets, so even stored ciphertexts leak minimal information. |
| Location data | Never collected. The app does not request location permissions. |
| Payment information | Not applicable. The app is free and has no payments or accounts; voluntary donations are made on an external web page and are not linked to any identity. |
What we DO have (complete list)
Being honest about the residue matters more than a clean marketing claim:
- Public key material: identity public keys, signed prekeys and one-time prekeys published by devices so others can initiate encrypted sessions. This is public-by-design cryptographic material.
- Undelivered encrypted envelopes: opaque ciphertexts queued for offline recipients, deleted on delivery. We cannot read them.
- Push tokens: an Apple (APNs) or Google (FCM) push token, delivered directly or through Expo's push service, per device that wants wake-up notifications. The push payload never contains content or sender identity — it is a generic "wake up". The token is held by Google/Apple infrastructure as with any app that uses push.
- Transient connection data: the app reaches the relay through Tor, so the relay sees a Tor circuit rather than the user's IP address. Our servers do see the IP address of requests that arrive over the regular internet (such as visits to this website) and, during a call, of the devices using our TURN server — only while the request or call lasts. It is kept in memory for rate limiting, not written to access logs, and never associated with an identity.
Our commitments
- We will never add a backdoor, key escrow, or client-side scanning. The clients are GPL-3.0 and the relay is AGPL-3.0 — a modified server must publish its source, and the protocol treats the server as untrusted anyway: even a fully malicious relay cannot read messages or forge identities (see PROTOCOL.md, threat model).
- We will respond to valid legal process with what exists — which is the list above — and will not fabricate capabilities we do not have.
- Where legally permitted, we will notify affected users of requests concerning them and publish aggregate statistics about requests received.
- If we are ever legally compelled to change any of the above, we will say so to the maximum extent the law allows. The strongest guarantee, however, is structural: anyone can self-host the relay and be subject to no operator at all.
Verify, don't trust
Every claim on this page is checkable in the source code: the relay (server/), the metadata-stripping and padding layer (mobile/src/crypto/metadata.ts), and the protocol document (PROTOCOL.md). If you find a discrepancy between this page and the code, that is a security issue — please report it via SECURITY.md.
Contact for legal process: aegislink.report@gmail.com
Richieste legali e trasparenza
Cosa può — e non può — fornire AegisLink in risposta a un ordine legale.
Traduzione di cortesia. In caso di discrepanza prevale la versione inglese.
Questa pagina esiste perché utenti, giornalisti e autorità conoscano la risposta prima che qualcuno la chieda. È scritta a partire dall'architettura del sistema, che è open source e verificabile in modo indipendente: la risposta onesta alla maggior parte delle richieste è che i dati non esistono, non che ci rifiutiamo di consegnarli.
In breve
AegisLink è progettato in modo che l'operatore detenga il più vicino possibile al nulla. Non possiamo decifrare i messaggi, non conosciamo nomi, numeri di telefono o indirizzi email degli utenti (non li raccogliamo mai) e non conserviamo registri di chi parla con chi, quando o con quale frequenza. Un ordine di esibizione non può obbligarci a produrre registri che non sono mai stati creati.
Cosa NON abbiamo
| Richiesto di frequente | La nostra risposta |
|---|
| Nome reale, numero di telefono, email dell'utente | Mai raccolti. La registrazione crea una coppia di chiavi sul dispositivo dell'utente; non vengono richiesti dati personali in alcun momento. |
| Contenuto dei messaggi | Non possiamo decifrarlo. Tutti i messaggi sono cifrati end-to-end (X3DH + Double Ratchet); le chiavi private esistono solo sui dispositivi degli utenti. |
| Allegati, contenuto delle chiamate vocali/video | Non possiamo decifrarli. Gli allegati sono cifrati lato client; le chiamate sono peer-to-peer con DTLS-SRTP e la segnalazione delle chiamate viene sigillata prima di raggiungere il relay. |
| Elenchi dei contatti / grafo sociale | Non conservati. I contatti risiedono solo sul dispositivo dell'utente. Il relay instrada singole buste cifrate e non conserva alcuna traccia delle relazioni. |
| Cronologia dei messaggi | Non conservata. Il relay tiene in coda un messaggio cifrato solo fino alla consegna, poi lo elimina. |
| Log di accesso, log degli IP, orari di accesso | Non registrati, per configurazione e per progettazione (access_log off; l'applicazione non conserva registri di accesso per utente). |
| Registri sulla frequenza dei messaggi / di analisi del traffico | Non conservati. Inoltre, i messaggi vengono riempiti (padding) fino a dimensioni fisse a scaglioni, quindi anche i testi cifrati conservati rivelano informazioni minime. |
| Dati di posizione | Mai raccolti. L'app non richiede permessi di localizzazione. |
| Informazioni di pagamento | Non applicabile. L'app è gratuita e non ha pagamenti né account; le donazioni volontarie si fanno su una pagina web esterna e non sono collegate ad alcuna identità. |
Cosa ABBIAMO (elenco completo)
Essere onesti su ciò che resta conta più di uno slogan di marketing impeccabile:
- Materiale di chiave pubblica: chiavi pubbliche d'identità, prekey firmate e prekey monouso pubblicate dai dispositivi affinché altri possano avviare sessioni cifrate. È materiale crittografico pubblico per progettazione.
- Buste cifrate non consegnate: testi cifrati opachi in coda per destinatari offline, eliminati alla consegna. Non possiamo leggerli.
- Token push: un token push di Apple (APNs) o Google (FCM), consegnato direttamente o tramite il servizio push di Expo, per ogni dispositivo che vuole ricevere notifiche di risveglio. Il payload push non contiene mai contenuti né l'identità del mittente — è un generico "sveglia". Il token è detenuto dall'infrastruttura di Google/Apple, come per qualsiasi app che usa le notifiche push.
- Dati di connessione transitori: l'app raggiunge il relay tramite Tor, quindi il relay vede un circuito Tor e non l'indirizzo IP dell'utente. I nostri server vedono invece l'IP delle richieste che arrivano tramite internet normale (come le visite a questo sito) e, durante una chiamata, quello dei dispositivi che usano il nostro server TURN, solo finché dura la richiesta o la chiamata. Resta in memoria per limitare gli abusi, non viene scritto nei log di accesso e non viene mai associato a un'identità.
I nostri impegni
- Non aggiungeremo mai una backdoor, un deposito delle chiavi (key escrow) o una scansione lato client. I client sono GPL-3.0 e il relay è AGPL-3.0 — un server modificato deve pubblicare il proprio sorgente, e il protocollo tratta comunque il server come non fidato: nemmeno un relay completamente malevolo può leggere i messaggi o falsificare identità (vedi PROTOCOL.md, modello di minaccia).
- Risponderemo alle richieste legali valide con ciò che esiste — ossia l'elenco qui sopra — e non inventeremo capacità che non abbiamo.
- Ove consentito dalla legge, informeremo gli utenti interessati delle richieste che li riguardano e pubblicheremo statistiche aggregate sulle richieste ricevute.
- Se mai fossimo legalmente obbligati a modificare qualcosa di quanto sopra, lo diremo nella misura massima consentita dalla legge. La garanzia più forte, tuttavia, è strutturale: chiunque può avviare il proprio relay e non essere soggetto ad alcun operatore.
Verifica, non fidarti
Ogni affermazione di questa pagina è verificabile nel codice sorgente: il relay (server/), lo strato di rimozione dei metadati e di padding (mobile/src/crypto/metadata.ts) e il documento del protocollo (PROTOCOL.md). Se trovi una discrepanza tra questa pagina e il codice, si tratta di un problema di sicurezza — segnalalo tramite SECURITY.md.
Contatto per richieste legali: aegislink.report@gmail.com