Google bloquea el sitio de Immich
Es un escenario que cualquier propietario, desarrollador o administrador de sitios web teme: tu sitio, funcionando perfectamente un minuto, de repente se vuelve inaccesible para el mundo. Los usuarios no ven tu contenido, sino una aterradora advertencia de página completa. Lo natural es pensar en un fallo del servidor, un ataque DDoS o un hackeo malicioso. Pero ¿y si el culpable no es un atacante externo, sino una decisión silenciosa y automatizada de uno de los guardianes más poderosos de Internet?
Esto es exactamente lo que le ocurrió al equipo detrás de Immich, una solución autoalojada para copia de seguridad de fotos y vídeos, recientemente. Todo su dominio fue marcado de repente como “peligroso”, borrándolos de facto del mapa para la mayoría de los usuarios. Su frustrante recorrido para descubrir la causa revela un peligroso punto ciego en los sistemas automatizados que actúan como los sheriffs autoproclamados de la web—un punto ciego que podría afectar a cualquiera.
Conclusión clave: Un guardián opaco puede borrarte de la web
Una sola marca puede hacerte desaparecer
Google Safe Browsing es un servicio gratuito integrado directamente en navegadores como Chrome y Firefox. Su objetivo es proteger a los usuarios identificando y bloqueando sitios que alojan malware, software no deseado o que realizan “ingeniería social”. Cuando se marca un sitio, los visitantes se encuentran con una pantalla roja de advertencia. Para el equipo de Immich, esta experiencia fue una incorporación indeseada a su lista de “Conocimiento Maldito”.
El impacto es inmediato y devastador. Como descubrieron: “tu sitio básicamente se vuelve inaccesible para todos los usuarios”. Solo una pequeña fracción de usuarios técnicos se atreverá a atravesar múltiples advertencias para acceder al “sitio inseguro”. Para el resto de tu audiencia, tu web deja de existir. Agravando el problema está la falta de transparencia del proceso que determina que un sitio es “peligroso”, convirtiendo al sistema en un árbitro poderoso pero opaco de la accesibilidad.
Conclusión clave: El alarmante efecto dominó de un solo subdominio
Un enlace interno “malo” puede tumbar todo tu dominio
Tras revisar la Google Search Console, el equipo de Immich encontró la fuente: sus propios entornos internos de vista previa, no públicos. Eran sitios temporales generados automáticamente para desarrollo, con URLs como main.preview.internal.immich.cloud. Los sistemas automáticos de Google aparentemente rastrearon esos sitios y concluyeron que eran “engañosos”.
Pero el descubrimiento más crítico y contraintuitivo fue el daño colateral. La marca en un único subdominio interno no quedó aislada. El sistema aplicó la etiqueta de “peligroso” a todo el dominio immich.cloud, tumbando sus servicios de producción y páginas informativas. Incluso afectó a su servidor de teselas en tiles.immich.cloud. Por suerte, como indicaron, las solicitudes a ese servidor se hacen vía JavaScript y no son visibles para el usuario, por lo que parecía funcionar con normalidad.
Lo más alarmante fue darse cuenta de que un solo subdominio marcado aparentemente invalidaba todo el dominio.
Conclusión clave: La “solución” es un bucle interminable frustrante
Ser desmarcado puede convertirse en tarea de Sísifo
El proceso oficial de recurso es crear una cuenta de Google, registrar tu sitio en Search Console y enviar una revisión. El equipo de Immich hizo exactamente eso, explicando que los sitios marcados eran sus propios despliegues. Un día o dos después, la revisión fue aceptada y el dominio volvió a estar limpio. 🎉
La victoria, sin embargo, fue efímera. Pronto descubrieron que estaban atrapados en un purgatorio algorítmico. Su proceso de desarrollo crea nuevos entornos de vista previa para pull requests en GitHub. En cuanto se publicaba una nueva URL de vista previa en un comentario, los rastreadores de Google la encontraban, la rastreaban y marcaban de inmediato de nuevo todo immich.cloud como peligroso. El proceso comenzaba otra vez: un juego inútil de golpear topos.
Ante este ciclo sin fin, idearon un workaround: mover todos los entornos de vista previa a su propio dominio dedicado—immich.build—aislando efectivamente el proceso de desarrollo de los servicios de producción para evitar futuras caídas del dominio completo.
Conclusión clave: El sistema parece ciego al desarrollo open source
No es solo el problema de un proyecto; es una amenaza para el código abierto
Esta experiencia no es exclusiva de Immich. Señala un problema sistémico más amplio que amenaza seriamente a proyectos open source y autoalojados. Muchos otros proyectos populares—incluyendo Jellyfin, YunoHost, n8n y NextCloud—han sufrido exactamente lo mismo. El problema incluso alcanzó a la base de usuarios de Immich, ya que “algunos usuarios empezaron a quejarse de que sus propios despliegues eran marcados”.
El flujo de trabajo que define el desarrollo open source moderno—crear entornos públicos de vista previa para revisión comunitaria—está siendo malinterpretado por los sistemas automatizados de Google como actividad engañosa. No es un bug; es un punto ciego de diseño fundamental.
Google Safe Browsing parece haberse construido sin considerar el software open source o autoalojado.
Cuando un flujo de trabajo estándar y transparente se marca como amenaza, se castiga a las comunidades que construyen las herramientas libres y abiertas de las que tantos dependen.
Conclusión: El dilema de una web centralizada
La historia de Immich recuerda que los guardianes centralizados tienen un poder inmenso—y a menudo arbitrario—para hacer que secciones enteras de la web sean inaccesibles. Aunque servicios como Safe Browsing se crean con buenas intenciones, su enfoque automatizado y uniforme puede causar daños importantes e involuntarios a proyectos legítimos. Nos obliga a una pregunta difícil.
A medida que cedemos más control a guardianes opacos y automatizados, debemos preguntar: ¿estamos construyendo una Internet más segura, o estamos allanando sin querer los espacios vivos y colaborativos donde nace la próxima generación de software open source?