Google marca el sitio de Immich como peligroso

 (immich.app)
1 puntos por GN⁺ 2025-10-23 | 1 comentarios | Compartir por WhatsApp
  • Recientemente, el servicio Google Safe Browsing hizo que todos los sitios relacionados con Immich recibieran advertencias de peligro.
  • Todo el dominio immich.cloud se vio afectado, y el acceso quedó prácticamente bloqueado en la mayoría de los navegadores.
  • La causa fue que URLs internas de despliegue, como los entornos Preview, fueron rastreadas automáticamente y tratadas como falsos positivos.
  • El equipo logró una recuperación temporal mediante una apelación en Google Search Console, pero el problema vuelve a ocurrir cada vez que se crea un nuevo Preview.
  • Debido a la naturaleza de un servicio open source y self-hosted, se trata de un problema estructural, y planean separar en el futuro los entornos Preview en otro dominio.

El incidente en el que Google marcó el sitio de Immich como peligroso

20 de octubre de 2025
Por Jason Rasmussen

Resumen

  • A inicios de este mes, todos los sitios web bajo *.immich.cloud fueron clasificados como sitios peligrosos, y los usuarios comenzaron a ver en el navegador advertencias de seguridad (la llamada "red-screen-of-death").
  • Nadie dentro del equipo entendía con claridad cómo funciona esta característica del navegador, pero ahora ese conocimiento ya se sumó a la lista de "cursed knowledge".

Contexto

  • Google ofrece gratuitamente el servicio Safe Browsing, cuyo objetivo es determinar si un sitio contiene malware, software no deseado o engaños de ingeniería social.
  • Navegadores principales como Chrome y Firefox integran este servicio.
  • No está claro cómo funciona realmente el sistema de evaluación de riesgo.
  • Cuando un sitio se clasifica como peligroso, la mayoría de los usuarios ya no puede usarlo.
  • Solo una pequeña minoría puede entrar usando los enlaces de "ver detalles" y "visitar este sitio no seguro".

Detección del marcado

  • A principios de este mes, muchos sitios del dominio immich.cloud comenzaron a aparecer como "peligrosos", y también hubo quejas de usuarios diciendo que sus instancias autohospedadas de Immich habían sido marcadas.
  • Todos los sitios internos en uso, incluidos los entornos Preview, también mostraban advertencias.
  • La molestia de tener que pasar cada vez por el proceso de "ver sitio no seguro" continuó.

Respuesta a través de Google Search Console

  • Como la advertencia no se quitó incluso después de varios días, decidieron usar la ruta oficial de respuesta: Google Search Console.

  • Este servicio exige crear una cuenta de Google, usar Search Console y solicitar una revisión del sitio marcado.

  • Search Console sí ofrece algo de explicación sobre por qué se tomó la decisión de riesgo.

    • "Google detectó contenido dañino en algunas páginas de su sitio"
    • "Estas páginas presentan riesgos como inducir la instalación de software no deseado o exponer información personal"

  • Al revisar la lista completa de URLs señaladas como problemáticas, todas correspondían a URLs de entornos Preview.

  • Lo más impactante fue que, aunque solo se marque un subdominio individual, todo el dominio queda catalogado como problemático.

Impacto

  • Los entornos Preview y los servicios internos (zitadel, outline, grafana, victoria metrics, etc.) quedaron dentro del alcance del problema.
  • El tile server de producción (tiles.immich.cloud) también fue afectado.
  • Sin embargo, como el tile server se solicita mediante JavaScript y no tiene una interfaz directa para el usuario, se confirmó que seguía funcionando normalmente.

Intento de "solución"

  • En Google Search Console, se requiere usar la función Request Review para apelar y explicar cómo se resolvió el problema.
  • Si se solicita la revisión sin haber resuelto realmente nada, el proceso de evaluación tarda más.

Solicitud de recuperación de sitio peligroso

  • Como concluyeron que en realidad no había un problema sustancial, enviaron una explicación de respuesta como la siguiente:

    • Immich es una aplicación self-hosted y el equipo de Immich (https://immich.app/) administra y opera directamente todo ese dominio.
    • Todos los sitios marcados son entornos oficiales de despliegue propio y no están haciéndose pasar por terceros.

  • En 1 a 2 días, el dominio volvió a considerarse seguro y se recuperó el acceso.

Esfuerzos para minimizar el problema

  • Si se agrega la etiqueta preview a un GitHub Pull Request, se crea automáticamente un entorno Immich Preview, y en cuanto se genera, también se publica la URL Preview junto con un comentario de verificación.

    https://pr-<num>.preview.internal.immich.cloud/

  • Cada vez que se crea un nuevo entorno Preview, el dominio immich.cloud vuelve a recibir la clasificación de peligroso.

  • Se sospecha que Google rastrea GitHub, descubre la nueva URL, la explora y luego la marca como riesgosa.

  • Como medida actual, están planeando separar estos entornos Preview a un dominio dedicado (immich.build).

Un problema mayor

  • El sistema de Google Safe Browsing parece haber sido diseñado sin considerar las características del software open source y self-hosted.
  • Además de Immich, varios proyectos populares han experimentado problemas similares.
  • Google puede bloquear arbitrariamente cualquier dominio y, en la práctica, no parece haber otra respuesta más que seguir solicitando revisiones a Google de manera constante.

Saludos,
El equipo de Immich

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-23
Opiniones en Hacker News

  • Si planeas alojar contenido de usuarios en subdominios, debes registrar el sitio en la Public Suffix List https://publicsuffix.org/list/
    Así, un subdominio contaminado no afecta a todo el sitio

    • Entre desarrolladores web hay una especie de conocimiento implícito de que, si alojas contenido generado por usuarios, sí o sí debes estar en la PSL
      Es difícil enterarse de estas cosas si no te toca vivir un caso como el de Immich, así que la mayoría no lo sabe hasta que lo sufre en carne propia

    • Antes los navegadores usaban un algoritmo que solo impedía establecer cookies amplias cuando el dominio no tenía puntos (por ejemplo, .com, .org)
      Pero eso causaba el problema de que, en dominios de subnivel como .co.uk, las cookies se filtraban a todos los dominios registrados por debajo
      Como cada TLD tiene políticas de registro distintas, no había forma de resolverlo desde el lado del desarrollo, y al final surgió el enfoque de mantener manualmente una lista como la Public Suffix List
      Viendo esta limitación tan fundamental del navegador, la web se siente como un auto hecho con cinta adhesiva https://publicsuffix.org/learn/

    • Viendo varios enlaces de este post, en realidad hay dos problemas

  1. El tema de registrar en la public suffix list cuando subes contenido de usuarios en tu propio dominio, como Immich
  2. El problema de que, cuando la gente aloja proyectos open source como immich o jellyfin en su propio dominio, se confunda con phishing
    El primero es relativamente fácil si conoces la PSL, pero el segundo es más complicado, especialmente cuando el nombre del software está incluido en el dominio

  • El problema no es el contenido de usuarios en sí, sino que subí directamente el release build de Immich a mi propio servidor y Google bloqueó todo mi dominio

  • No fue porque Immich realmente alojara contenido de usuarios, sino porque el problema ocurrió en un subdominio de preview para PR
    Creo que eso claramente es un problema en el código de Google

  • Recomiendo ver completa la lista de “Cursed Knowledge” del equipo de Immich https://immich.app/cursed-knowledge

    • Algunas cosas de la lista en realidad parecen un diseño de seguridad bastante obvio
      Por ejemplo, “algunos teléfonos eliminan automáticamente la información GPS cuando una app sin permisos de ubicación lee una imagen”
      Más bien suena como un comportamiento natural y deseable

    • Estaría bueno poder compartir este tipo de conocimientos en un archivo estándar como CURSED.md en cada proyecto
      Así todos podrían aprender ese tipo de conocimiento obtenido en la práctica

    • “Los parámetros de consulta de Postgres tienen un límite de 65,000”
      Da risa que incluso eso no alcance

  • Siempre me pregunto algo con este tipo de advertencias
    Te etiquetan de forma bastante directa como “estafador” o “atacante”, y me pregunto si eso no podría considerarse difamación
    Pasa lo mismo con las advertencias de Microsoft sobre ejecutables no verificados
    Antes te decían algo como “no sabemos si es seguro”, pero ahora parece que afirman directamente “tú eres el atacante”

    • La palabra “estafador” no aparece en el mensaje real; usan frases como “puede haber un atacante en el sitio”, “might”, etc.
      Eso también incluye casos en los que un tercero comprometió el sitio
      No están señalando al dueño del sitio como atacante
      Seguro el equipo legal revisó el texto con mucho cuidado

    • No soy abogado, pero no recuerdo que esto haya llegado a tribunales
      Podría considerarse difamación

  • Puede que no sea un problema tan grave, pero me pregunto si en un lugar como Immich cualquiera puede enviar un PR y, con solo ponerle la etiqueta de preview, ese contenido termina alojado automáticamente en https://pr-<num>.preview.internal.immich.cloud
    ¿No significa eso que cualquiera podría subir lo que quiera libremente?

    • En GitHub, quienes pueden agregar etiquetas están limitados a colaboradores, así que no está completamente abierto
      Aun así, si un colaborador puede enviar primero un PR legítimo, conseguir la etiqueta y luego subir cualquier cosa, sí hay un riesgo

    • Suena como una idea de phishing realmente gratis

  • Cuesta creer que una sola empresa pueda decidir incluso a qué sitios puedes entrar
    No les bastaba con limitar la ejecución de apps; ahora ya estamos en este nivel

    • Muchas de estas cosas son consecuencia de que el Congreso de EE. UU. haya funcionado de forma ineficiente durante tanto tiempo

    • Me sorprende cómo lograron que incluso usuarios que odian la publicidad sigan pensando que estas grandes empresas son “cool”
      Nadie quiere anuncios, pero para la empresa son una forma de ganar dinero
      No entiendo cómo Google logra maquillar una imagen corporativa tan poco ética como si fuera algo admirable

  • Siento que el internet abierto ya se terminó
    Ahora los monopolios controlan todo
    Tuve una app de iOS en la tienda durante 3 años y, de repente, Apple empezó a exigir una licencia nueva que ni siquiera existía, diciendo que si no la presentaba iban a bajar la app
    No había cambiado absolutamente nada en esos 3 años, pero así fue
    Cada vez me cansa más que ni siquiera el self-hosting se pueda hacer libremente

    • Sería de mucha ayuda si pudieras explicar con más detalle qué pasó con tu app de iOS y los requisitos de Apple

  • Un amigo mío, que también es cliente, usaba hosting del ecosistema WordPress y una redirección simple
    En algún momento el host terminó en una blacklist de “sitio peligroso”
    Incluso después de quitar la redirección, su propio dominio siguió contaminado, y por eso Google dejó de aceptar por completo correos desde ese dominio
    Logró salir de la blacklist tras pedir una revisión, pero el efecto de bloqueo del correo quedó para siempre
    Al final registró un dominio nuevo, y este tipo de comportamiento de Google más bien incentiva a seguir creando cuentas desechables

    • Escuchar historias así da miedo
      Solo de imaginar que mi dominio, que he usado bien durante 25 años, termine en una blacklist por error y además me bloqueen el correo, me parece espantoso

  • Mi conclusión es que conviene separar dominios según el uso
    Tiene la desventaja de que, a nivel global, varios TLD pueden parecer menos oficiales, pero este caso me dejó aún más convencido
    Por ejemplo
    www.contoso.com (público)
    www.contoso.blog (público, con comentarios de usuarios)
    contoso.net (interno)
    staging.contoso.dev (desarrollo / endpoint de zero trust)
    raging-lemur-a012afb4.contoso.build (para snapshots)

    • Pero si separas así los dominios, desde la perspectiva del usuario hay mucho más riesgo de que parezca phishing
      Una vez recibí un correo desde githubnext.com, y como para mí GitHub = github.com, naturalmente pensé que era phishing o spam
      Resultó ser un servicio real

    • Buen enfoque

  • Yo también estoy pasando por el mismo problema con mi dominio
    Google marcó como peligroso nuestro Immich familiar, y por eso todos los demás servicios del mismo dominio quedaron inaccesibles en Chrome
    En teoría se puede saltar la advertencia, pero eso hace que el álbum de fotos que le envié a mi suegra quede prácticamente inutilizable

  • A mí me pasó exactamente lo mismo a inicios de este año cuando hice self-host de Umami Analytics
    https://news.ycombinator.com/item?id=42779544#42783321
    Cuando reclamé en Google Search Console y mencioné “acciones legales”, recién entonces quitaron el flag