Bluesky: los feeds privados de sus usuarios son públicos

Más de 1.300 feeds privados, a la vista de cualquiera

Un análisis publicado en el blog de Melanie Kat encontró más de 1.300 feeds RSS que usuarios habían suscrito en Skyreader, un lector de feeds construido sobre el AT Protocol de Bluesky, sin autenticación ni restricciones de acceso. Entre ellos había feeds de pago de 404 Media, feeds exclusivos para backers de Patreon y feeds privados de repositorios de GitLab.

Para un founder, esto no es una curiosidad técnica. Si tu producto guarda datos de usuarios en una arquitectura descentralizada, cada decisión de diseño sobre qué se publica y qué no puede convertirse en una filtración silenciosa que nadie autorizó.

¿Cómo se filtraron esos feeds privados?

El punto de partida fue el propio Personal Data Server (PDS) de Bluesky. Un PDS es el servidor donde se almacena la data de una cuenta, y el usuario puede autoalojarlo. Buena parte de esa información es pública por diseño: con una herramienta como PDSls.dev cualquiera puede explorar el contenido de una cuenta.

La autora del análisis no quiso autenticar su cuenta en Skyreader sin saber antes qué quedaría expuesto. Así que tomó los handles de quienes habían dejado reseñas de la app en atstore.fyi —un directorio de aplicaciones del AT Protocol— y los consultó en PDSls.

Lo que encontró: cada feed al que te suscribes queda publicado en un objeto de datos llamado app.skyreader.feed.subscription, con una clave feedUrl que contiene la dirección del RSS. Es decir, el nombre de la persona y el feed que lee quedan vinculados y accesibles.

El siguiente paso fue más sistemático. Consultando un relay de Bluesky (como bsky.network) se puede pedir cada registro de esa colección. No es una sola llamada a la API: el relay devuelve un array de DIDs (identificadores descentralizados) y desde ahí hay que resolver el PDS de cada uno para pedir los registros con la data real. El resultado fueron esos más de 1.300 feeds, todos obtenidos sin autenticación.

No es solo Skyreader: el patrón se repite

El problema no es exclusivo de un lector de feeds. La autora señala que varios clones de Discord almacenan cada mensaje de forma abierta, y que un clon de Twitch funciona igual: se puede ver a la gente chatear en Stream.place e incluso buscar dentro de esa data. Si todo el chat de Twitch fuera fácilmente buscable, muchos usuarios se llevarían una sorpresa.

El patrón es el mismo en todos los casos: una arquitectura pensada para la interoperabilidad y la transparencia termina exponiendo información que el usuario creía privada, simplemente porque nadie le explicó cómo funciona.

El caso W Social: la misma arquitectura, otro escándalo

Este riesgo ya escaló a nivel regulatorio en Europa. Según Cybernews, la plataforma europea W Social —que abrió su beta pública en junio de 2026 y se presenta como una alternativa a X enfocada en privacidad— tuvo que salir a responder tras un hallazgo del periodista tecnológico alemán Gavin Karlmeier: una base de datos públicamente visible con cuentas de la plataforma.

Más de 2.500 usuarios tenían su nacionalidad expuesta y casi 2.000 sus nombres completos, según el reporte. W Social negó una brecha de datos y atribuyó la exposición a la naturaleza pública del AT Protocol desarrollado por Bluesky Social PBC. La empresa explicó que, al verificar una cuenta, escribe un registro en su cuenta de moderación dentro del protocolo, y que ese registro es público por diseño.

Aras Nzarovas, investigador sénior de seguridad de Cybernews, advirtió que esa data puede usarse para doxxing, phishing dirigido y ataques de toma de cuentas. Su punto más incómodo para cualquier equipo de producto: en un sistema descentralizado, borrar un dato publicado por error es difícil. Si un usuario escribió su dirección donde iba su apellido, esa dirección ya quedó publicada.

¿Qué significa esto para tu startup?

Si estás construyendo sobre el AT Protocol, o sobre cualquier arquitectura descentralizada, la lección es que "público por defecto" no es lo mismo que "el usuario entiende que es público". La autora del análisis lo resume así: algunos dirán "ese es el punto", pero no está convencida de que los usuarios comprendan el riesgo.

Para un founder, hay tres implicaciones concretas:

• Tu superficie de exposición es tu esquema de datos. Cada lexicon que defines es una promesa sobre qué se hace público. Si guardas un dato sensible en un campo que el protocolo publica, ese dato se filtra, aunque tu interfaz nunca lo muestre.
• La interoperabilidad amplifica los errores. En un sistema centralizado, un bug de privacidad se corrige con un deploy. En uno descentralizado, el registro ya está replicado en relays y PDS de terceros.
• El cumplimiento normativo no desaparece por ser descentralizado. W Social tuvo que responder ante el escrutinio por GDPR precisamente porque sus registros eran accesibles en la web abierta.

Acciones concretas para tu equipo

1. Audita tu lexicon antes de lanzar. Revisa cada colección que escribes en el AT Protocol y pregúntate si el dato que contiene es algo que el usuario aceptaría ver indexado en Google. Si la respuesta es no, no lo guardes ahí.
2. Documenta la exposición en el onboarding. No basta con una política de privacidad genérica. Explica en lenguaje llano qué queda público y qué no, con ejemplos del propio producto.
3. Prueba tu producto como lo haría un atacante. Antes de escalar, intenta reconstruir la data de tus usuarios usando solo herramientas públicas, como hizo el análisis de Skyreader. Si puedes listar suscripciones, mensajes o identidades sin autenticarte, tus usuarios también pueden ser listados por cualquiera.

La descentralización ofrece ventajas reales: portabilidad, resistencia a la censura y menos dependencia de un intermediario. Pero traslada al usuario una responsabilidad que antes asumía la plataforma. Tu trabajo como founder es cerrar esa brecha con diseño, no con letra pequeña.

Fuentes

• Do At-Proto Users Know This Is Public? (fuente original)
• European X alternative W Social denies leaking personal data to the open web