Cómo funciona URnetwork

URnetwork es una red de privacidad impulsada por sus miembros. Tu tráfico sale a internet por el dispositivo de otro miembro, no por un servidor VPN en un centro de datos. Los sitios web ven la dirección IP de ese dispositivo en lugar de la tuya. Esta visión general explica la ruta y lo que cada parte puede ver.

Las salidas son miles de dispositivos de miembros repartidos por más de 2.000 ciudades reales en más de 90 países, no IPs virtuales servidas desde un puñado de centros de datos. Los recuentos en vivo se publican en api.bringyour.com/stats/last-90.

La ruta

El tráfico recorre cuatro tramos: tú → extensor → operador → proveedor → internet.

• Cliente. La app o la instancia del SDK en tu dispositivo. Una red (network) es el término de URnetwork para tu cuenta, la unidad de identidad y facturación; puede contener varios usuarios, dispositivos y clientes.
• Extensor. Un salto de reenvío gestionado por voluntarios en una dirección independiente, y el primer tramo. Reenvía tu sesión cifrada a la plataforma sin terminarla, así que transporta bytes que no puede leer. Como es tu primer salto, sí ve tu dirección IP.
• Operador. BringYour, Inc., la parte que coordina la red. Su plataforma (connect.bringyour.com, api.bringyour.com) autentica a los clientes, te empareja con proveedores, retransmite el tráfico y gestiona los contratos y los pagos.
• Proveedor. El dispositivo de un miembro que comparte su conexión y reenvía tu tráfico a internet, de modo que los sitios web ven una dirección residencial en la ciudad del proveedor.

El operador y el proveedor son las dos partes retransmisoras, y el diseño reparte el conocimiento entre ellas. El extensor es un salto de conectividad fuera de ese reparto y no añade cifrado propio. Mantiene la red accesible donde la plataforma está bloqueada.

Quién puede ver qué

En la ruta por defecto, ninguna parte por sí sola reúne tu identidad y tu actividad. Esa afirmación descansa en dos propiedades con alcances distintos.

El proveedor nunca sabe quién eres. El operador se interpone entre tú y el proveedor, así que el proveedor ve un identificador de dispositivo y los destinos que sirve, nunca tu dirección. Esto se cumple en toda ruta retransmitida, sin ningún ajuste que puedas configurar mal.

El operador no puede leer lo que envías. La sesión cliente↔proveedor va sellada de extremo a extremo, activada por defecto en las apps nativas, así que el operador transporta texto cifrado más tiempo y volumen. Esto se cumple en la ruta sellada por defecto; los modos de abajo muestran las rutas sin sellado.

La extensión de navegador y los endpoints proxy no tienen sesión sellada en absoluto. Es una cuestión de alcance, no un valor por defecto, y es arquitectónica: un navegador o un cliente proxy corriente no pueden ejecutar el motor de la red, así que el operador ejecuta el dispositivo del cliente de forma remota y traduce entre protocolos — un sellado iniciado desde ese dispositivo empezaría dentro del operador, la parte a la que el sellado existe para cegar. La implementación cambió el sellado por llegar siquiera a esas plataformas. Allí, lo que impide que el operador acumule tus destinos es una disciplina de almacenamiento fijada por un test, no el cifrado (modelo de amenazas §2.4).

La tabla es canónica. El modelo de amenazas aplica el mismo reparto frente a adversarios con nombre, incluidos un operador hostil y proveedores en connivencia.

Por qué cuatro tramos

La velocidad es un objetivo de diseño, no una concesión. Cada salto adicional alarga el viaje de ida y vuelta entre tú e internet, y por eso las cadenas largas duelen en el uso diario. Acotar la ruta a cuatro tramos mantiene el reparto de conocimiento a velocidad apta para streaming. URnetwork sitúa la velocidad media de streaming en la red en más de 40 Mbps.

La descripción formal es un multisalto acotado en latencia con separación de datos. El protocolo de transmisión admite encadenar proveedores intermedios adicionales; la red en producción usa la ruta de un solo proveedor. Otros diseños hacen otros intercambios. Tor paga las cadenas más largas con latencia. Private Relay de Apple es un reparto cifrado entre dos partes, dentro de implementaciones cerradas, con ambas partes elegidas y pagadas por una sola empresa. La mayoría de las VPN no intentan reparto alguno. El mapa de comparativas los recorre producto a producto.

Qué ocurre cuando te conectas

1. Inicio de sesión. La app inicia sesión con un token que caduca en torno a un día y se renueva automáticamente, así que un token robado se vuelve inútil rápido. Los ingenieros lo llaman JWT. Las cuentas pueden usar correo o teléfono, inicio de sesión con Google o Apple, la firma de una cartera Solana o Bittensor, una frase de recuperación (seedphrase), o una Cuenta instantánea (Instant Account) de un toque y sin correo cuya credencial completa es una frase de recuperación. La frase es comparable a las cuentas numeradas de Mullvad y sobrevive a una reinstalación; el servidor la genera, la muestra una sola vez y guarda solo hashes, así que perderla es perder la cuenta.
2. Llegar a la plataforma. El cliente abre un canal cifrado hasta la plataforma: TLS sobre WebSocket, o QUIC/HTTP-3 donde la red lo permite. El canal atraviesa un extensor y termina en la plataforma. Primero compiten las rutas directas; el tramo del extensor toma el relevo cuando fallan.
3. Encontrar proveedores. El cliente pide proveedores que encajen con tu selección: el mejor disponible, un país de la lista o una ciudad que encuentras tecleando su nombre en el buscador. La plataforma puntúa a los candidatos de forma continua por fiabilidad y velocidad medida y devuelve un conjunto ordenado.
4. Abrir contratos y listo. El cliente mantiene una ventana de varios proveedores y equilibra tus conexiones entre ellos. El perfil por defecto ejecuta dos ventanas: un conjunto de calidad de 2–6 proveedores para HTTPS y un conjunto de velocidad de 1–2 para todo lo demás. Lo habitual es tener entre tres y ocho proveedores activos. Las conexiones a un sitio dado quedan fijadas a un proveedor, de modo que ese sitio ve una sola dirección estable durante toda tu sesión. Un proveedor que rinde poco o se cae es reemplazado; el resto de la ventana absorbe su trabajo. Cada byte viaja bajo un contrato de transferencia, la unidad contable que mide lo que transporta cada proveedor.

Tu identidad de salida es plural: varios proveedores a la vez, rotando con el tiempo, así que ninguna salida ve más que una porción de tu navegación. La ventana es también la estrategia de velocidad: las conexiones residenciales varían más que los servidores de centro de datos, y descartar las lentas mantiene el streaming fluido.

Cifrado

El canal cliente↔plataforma siempre va cifrado: TLS 1.3 o QUIC.

La sesión sellada. La app cifra el tráfico hasta el proveedor, de modo que el operador retransmite bytes que no puede leer. Lo que le llega es texto cifrado más tiempo y volumen. El control se llama Cifrado poscuántico (Post Quantum Encryption) en el panel de conexión de las apps de Android, iOS, macOS, Windows y Linux, activado por defecto en las cinco. El sellado es un handshake TLS 1.3 directo entre cliente y proveedor, con el intercambio de claves poscuántico híbrido X25519MLKEM768 y AES-256-GCM por mensaje. Las claves de identidad son Ed25519; "poscuántico" se refiere solo al intercambio de claves.

Alcance: con el sellado activado, un proveedor que no consiga establecerlo no transporta tu tráfico en absoluto. El cliente se niega a enviar datos de aplicación en claro en vez de recurrir en silencio al respaldo — un proveedor con el que no se puede sellar se omite, no se usa sin sellar. Todas las compilaciones actuales de proveedor admiten el sellado, así que esto afecta sobre todo a las antiguas, y cuesta disponibilidad, no confidencialidad. Desactiva Cifrado poscuántico y vuelve el comportamiento anterior: el tráfico puede entonces tomar la ruta estándar, donde la plataforma puede leer las direcciones y los contenidos de los paquetes.

Límite: ninguna app informa aún de si una conexión concreta va sellada. Esa carencia es real, pero ya no es la peligrosa — no te pueden degradar en silencio mientras el sellado esté activado. Esto, y todo lo demás contra lo que URnetwork no defiende, está recogido en el modelo de amenazas.

Anonimización fuerte, y el modo directo. Un proveedor ve las direcciones de destino del tráfico que sirve, como hace hoy tu ISP. No sabe quién eres: por defecto nunca ve tu IP real; solo la plataforma la ve. Ese valor por defecto es el interruptor Anonimización fuerte del panel de conexión, que viene activado. Desactivarlo activa el modo directo: el cliente habla directamente con el proveedor y el rendimiento sube. El coste: ese proveedor pasa a ver tu dirección real. Los perfiles alojados fuerzan el modo directo a desactivado en cualquier caso.

Qué puede ver cada parte

Detrás de la fila del operador:

• La forma almacenada de tu dirección de conexión es un hash unidireccional con clave del bloque /29 (IPv4) o /56 (IPv6) que la rodea, no la dirección en sí. Una ciudad/región/país aproximados derivados de la dirección se guardan por conexión.
• La disciplina está en el código, no solo en la política. El registro HTTP pasa por una lista de cinco cabeceras permitidas. El registro de transferencias anota ids de cliente y de red y recuentos de bytes, sin ningún campo de destino, host, URL, SNI, puerto o dominio donde escribir. La ruta de datos del proxy no registra nada, fijado por un test de regresión.
• El sellado hace tu tráfico ilegible para el operador. La disciplina de almacenamiento cubre lo que el operador sigue viendo (asociaciones con proveedores, recuentos de bytes, ubicación aproximada) y lo sustituye donde no hay sellado: la extensión de navegador, los endpoints proxy y las apps nativas con el sellado desactivado.
• Límite: estas son propiedades de los registros que escribe el código. Los logs de acceso del balanceador de carga de entrada nunca se auditaron, y líneas con direcciones y SNI llegan al stderr de los servicios, cuyo destino en producción no está establecido. El registro completo: el modelo de amenazas.

Código abierto, y qué no está auditado

Toda la pila es de código abierto: las apps, el SDK, el motor del protocolo y el propio código de servidor del operador, así que los mecanismos descritos aquí pueden leerse en lugar de tomarse en confianza. El código abierto demuestra el diseño, no qué compilación está desplegada.

Ninguna auditoría independiente cubre el protocolo, el motor connect ni el código de servidor del operador, que es donde viven las afirmaciones de privacidad. Dos evaluaciones de terceros de 2025 cubren otras superficies. Una es una prueba de penetración independiente de la aplicación web y la API (abril–mayo de 2025). La otra es una evaluación MASA AL2 de Leviathan Security Group sobre la app de Android, que la superó; Leviathan la acota como no siendo una evaluación de seguridad integral. Código abierto bajo escrutinio permanente es la respuesta de URnetwork a la auditoría anual de un momento dado. Registro completo: el modelo de amenazas.

Compartir sin riesgo: la capa ip_security

Compartir tu conexión no debería significar heredar el riesgo legal de un desconocido. El cliente proveedor incluye ip_security, una capa de seguridad de tráfico de código abierto dentro del motor connect y uno de sus componentes más grandes. Inspecciona la propia salida del proveedor, su salida a internet. El tráfico de riesgo se bloquea antes de salir por la conexión del miembro:

• Filtrado de clase DMCA. Un detector con seguimiento de estado reconoce firmas de BitTorrent y de intercambio de archivos y descarta el tráfico opaco que no encaja con ningún protocolo legítimo, de modo que las transferencias P2P infractoras no salen por la línea del miembro.
• Filtrado de clase CFAA. Los patrones de acceso no autorizado, escaneo y explotación se descartan sin respuesta, de modo que la conexión no es el punto de partida de la intrusión de otro.
• Un detector construido para no ver. La comprobación de intercambio de archivos borra el nombre del servidor de su propia clave de flujo. Decide con direcciones, puertos y los bytes iniciales de un flujo, y lleva sus contadores por protocolo y puerto, nunca por dirección.

Una coincidencia produce un paquete descartado. Una coincidencia de BitTorrent emite además una señal de abuso al operador: el id de dispositivo del par y un booleano, sin destino, dominio ni contenidos. El operador no incluye hoy ningún gestor para esa señal, así que no se guarda nada al recibirla. Los descartes de protocolo opaco son silenciosos, sin informe.

La capa se ejecuta en el borde, a ambos lados de él: en tu dispositivo cuando te conectas, para que el tráfico que la red no va a transportar nunca llegue a un proveedor, y en el dispositivo del proveedor, donde el tráfico sale. El operador no inspecciona el tráfico de forma central, y el sellado no esquiva el filtro, porque el filtro se ejecuta en los extremos que el sellado conecta. Con el kill switch (interruptor de corte) activado (un conmutador explícito en todas las apps, activado por defecto en la extensión de navegador), el tráfico bloqueado se detiene en lugar de recurrir a tu propia conexión. La mayoría de los países tienen leyes de las familias CFAA y DMCA; un mismo estándar las responde en cada salida, y URnetwork cumple la ley allí donde distribuye. El filtro se mantiene, no está congelado: sus listas de amenazas se regeneran en cada versión a partir de feeds públicos de malware, abuso y botnets (Spamhaus DROP, el rastreador de botnets de abuse.ch, Emerging Threats y otros), así que una app al día bloquea el espacio de direcciones malicioso conocido más reciente. Los términos del servicio cubren compartir conexión.

Atravesar bloqueos

Los extensores llevan la ruta a través de cortafuegos locales y regionales. Cada uno responde TLS en puertos de servicio verosímiles (443, DNS-over-TLS 853, LDAPS 636 y otros) y ante los escáneres parece una CDN mal configurada. Cada uno lleva codificado de fábrica reenviar el flujo cifrado a la plataforma desde una dirección propia, así que bloquear connect.bringyour.com no bloquea la vía de entrada. El cliente rota por identidades de extensor generadas, con fragmentación y reordenación aleatorias de paquetes, hasta que una funciona. Donde solo escapa el DNS, un transporte con forma de DNS remodela los paquetes QUIC como consultas y respuestas DNS. Cualquiera puede ejecutar un extensor.

Proveedores y cobertura

Las ubicaciones están respaldadas por presencia: una ciudad se ofrece solo mientras el dispositivo de un miembro está en línea en ella. La plataforma geolocaliza la conexión que observa; un proveedor no puede declarar su propia ciudad. Una dirección que parece un centro de datos, una VPN o un rango reanunciado se degrada en lugar de recibir confianza. Límite: ninguna parte externa ha medido la flota, y nada verifica que los proveedores ofrecidos a un cliente sean independientes entre sí o del operador. Ver el modelo de amenazas.

Compartir conexión es voluntario y consiste en ceder ancho de banda sobrante: está apagado hasta que lo enciendes, va solo por Wi-Fi salvo que permitas datos móviles, y apunta al tráfico público o únicamente a tus propios dispositivos. El tráfico público se mide: la plataforma estampa en cada contrato de transferencia un secreto que solo ese proveedor posee, de modo que el proveedor puede comprobar que un contrato es genuino y para la audiencia que aceptó. El depósito en garantía se denomina en bytes; ambos extremos declaran lo que transportaron, y la cifra liquidada es su promedio dentro de una tolerancia. Los proveedores participan en el protocolo UR; ur.xyz documenta las recompensas, y esta página no las repite. Los niveles gratuitos existen porque los miembros de pago financian el crecimiento de la red. Cualquiera puede ser proveedor.

Planes y la API del operador

Hay dos planes: uno gratuito con una cuota de datos diaria, y Pro con una cuota mensual grande, más clientes simultáneos y las comodidades de proxy y WireGuard. Pro puede pagarse con USDC en cadena desde una cartera. La cuota se mide, no se estrangula: cuando se agota, la red deja de abrir transferencias nuevas en lugar de ralentizarte. El túnel se queda en silencio, tu propia conexión queda intacta y la cuota se rellena en su ciclo. Los números vigentes están en ur.io/products, legibles por máquina en GET https://api.bringyour.com/x402/skus.

Todo lo que hacen las apps pasa por la API REST pública del operador (autenticación, dispositivos, descubrimiento de proveedores, suscripciones, estadísticas), documentada en la referencia de la API. Los agentes tienen acceso de primera clase: un servidor MCPv2 en mcp.bringyour.com (OAuth; herramientas providerLocations y fetch) y compras x402 de pago según necesidad. Ver ur.io/agents.

Endpoints de respaldo: HTTPS, SOCKS5, WireGuard

Para el software que no puede integrar el SDK, el operador mantiene endpoints puente: un proxy HTTPS CONNECT, SOCKS5 y un endpoint WireGuard para apps WireGuard estándar. SOCKS5 admite CONNECT y UDP associate; BIND no está soportado, y los datagramas UDP de más de 2 KiB se descartan por diseño. Límite: la ruta WireGuard asigna una dirección de túnel estable de un pool privado asignado por la plataforma, no tu IP real. Esa dirección estable permite correlacionar a un cliente entre proveedores, y el endpoint entrega al cliente un resolvedor público fijo (1.1.1.1). Las apps y el SDK siguen siendo la forma más privada de usar la red.

Adónde ir ahora

• Configuración: las guías de primeros pasos para Android, iOS, macOS, Windows, Linux, la extensión de navegador y el SDK.
• Profundidad por plataforma: los recorridos de cada app.
• Otros productos: los docs comparativos y el mapa de comparativas.
• El protocolo: ur.xyz para el whitepaper, la economía y las recompensas a proveedores.