Google marca o site do Immich como perigoso

 (immich.app)
1 pontos por GN⁺ 2025-10-23 | 1 comentários | Compartilhar no WhatsApp
  • Recentemente, o serviço Google Safe Browsing passou a exibir alertas de risco para todos os sites relacionados ao Immich
  • Todo o domínio immich.cloud foi afetado, fazendo com que o acesso ficasse praticamente bloqueado na maioria dos navegadores
  • A causa foi que URLs internas de deploy, como ambientes de Preview, foram rastreadas automaticamente e tratadas como falsos positivos
  • A equipe conseguiu restaurar temporariamente o acesso por meio de um recurso no Google Search Console, mas o problema volta a ocorrer sempre que um novo Preview é criado
  • Por se tratar de uma característica estrutural de serviços open source e self-hosted, a equipe pretende separar os ambientes de Preview em um domínio distinto no futuro

Incidente em que o Google marcou o site do Immich como perigoso

20 de outubro de 2025
Por Jason Rasmussen

Visão geral

  • No começo deste mês, todos os sites em *.immich.cloud foram classificados como perigosos, e os usuários passaram a ver no navegador uma tela de alerta de segurança (a chamada "red-screen-of-death")
  • Ninguém da equipe entendia claramente como esse recurso do navegador funcionava, mas agora esse conhecimento entrou para a lista de 'cursed knowledge'

Contexto

  • O Google oferece gratuitamente o serviço Safe Browsing, cujo objetivo é determinar se um site contém malware, software indesejado ou golpes de engenharia social
  • Navegadores importantes como Chrome e Firefox integram esse serviço
  • Não está claro como o serviço determina, na prática, que algo é perigoso
  • Quando um site é classificado como perigoso, a maioria dos usuários deixa de conseguir utilizá-lo
  • Apenas uma parcela muito pequena dos usuários consegue entrar por meio dos links 'ver detalhes' e 'visitar este site não seguro'

Como descobriram a sinalização

  • No começo do mês, vários sites do domínio immich.cloud passaram a aparecer como "perigosos", e usuários começaram a reclamar que suas próprias instâncias self-hosted do Immich também estavam sendo sinalizadas
  • Todos os sites internos usados pela equipe, incluindo ambientes de Preview, também passaram a exibir alertas
  • Isso trouxe o incômodo contínuo de precisar passar toda vez pelo processo de visualizar um "site seguro"

Resposta via Google Search Console

  • Como o alerta não foi removido mesmo após vários dias, a equipe decidiu usar o Google Search Console, que é o canal oficial de resposta

  • Esse serviço exige criar uma conta Google, usar o Search Console e solicitar revisão para o site sinalizado

  • O Search Console fornece alguma explicação sobre o motivo da classificação de risco

    • "O Google detectou conteúdo nocivo em algumas páginas do seu site"
    • "Essas páginas apresentam fatores de risco, como induzir a instalação de software indesejado ou expor informações pessoais"

  • Ao verificar a lista completa de URLs apontadas como problemáticas, todas eram URLs relacionadas ao ambiente de Preview

  • O ponto mais chocante foi que, mesmo que apenas um subdomínio seja sinalizado, todo o domínio passa a ser tratado como problemático

Impacto

  • Os ambientes de Preview e serviços internos (zitadel, outline, grafana, victoria metrics etc.) foram todos afetados
  • O tile server de produção (tiles.immich.cloud) também entrou na área de impacto
  • Ainda assim, como o tile server é acessado via JavaScript e não tem uma interface direta para o usuário, foi confirmado que ele continuou funcionando normalmente

Tentativa de "resolver" o problema

  • No Google Search Console, é necessário usar o recurso Request Review para contestar a sinalização e explicar a resolução
  • Se a equipe pedir a revisão sem realmente corrigir o problema, o processo de análise demora mais

Solicitação de restauração de site perigoso

  • Como concluíram que não havia nenhum problema real, enviaram a seguinte explicação

    • O Immich é uma aplicação self-hosted, e a equipe do Immich (https://immich.app/) gerencia e opera diretamente todo esse domínio
    • Todos os sites sinalizados eram apenas ambientes oficiais de deploy interno, e não estavam fingindo ser outra pessoa ou serviço

  • Em 1 a 2 dias, o domínio voltou a ser considerado normal e o acesso foi restaurado

Esforços para minimizar o problema

  • Ao adicionar o rótulo preview em um Pull Request no GitHub, um ambiente de Preview do Immich é criado automaticamente e, assim que fica pronto, um comentário de verificação é publicado junto com a URL do Preview

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

  • Sempre que um novo ambiente de Preview é criado, o domínio immich.cloud volta a ser classificado como perigoso

  • A equipe suspeita que o Google rastreie o GitHub, descubra novas URLs, as explore e então as marque como perigosas

  • A medida em estudo no momento é separar os ambientes de Preview para um domínio exclusivo (immich.build)

Um problema maior

  • O sistema Google Safe Browsing parece ter sido projetado sem considerar as características de softwares open source e self-hosted
  • Além do Immich, vários projetos populares já passaram por problemas semelhantes
  • O Google pode bloquear arbitrariamente qualquer domínio e, na prática, há poucas formas de reação além de continuar pedindo revisão ao Google

Cheers,
Equipe do Immich

Leituras relacionadas

1 comentários

 
GN⁺ 2025-10-23
Comentários do Hacker News

  • Se você pretende hospedar conteúdo de usuários em subdomínios, precisa registrar o site na Public Suffix List https://publicsuffix.org/list/
    Assim, um subdomínio contaminado não afeta o site inteiro

    • Se você hospeda conteúdo gerado por usuários, estar na PSL é praticamente um conhecimento tácito entre desenvolvedores web
      É difícil saber disso sem passar por algo como o problema do Immich antes, então a maioria das pessoas só descobre na prática

    • Antigamente, os navegadores usavam um algoritmo que só bloqueava a definição ampla de cookies quando o domínio não tinha ponto algum (ex.: .com, .org)
      Mas isso causava o problema de vazar cookies para todos os domínios registrados abaixo de domínios em subnível como .co.uk
      Como cada TLD tem políticas de registro diferentes, não havia uma forma de resolver isso do ponto de vista de desenvolvimento, então acabaram recorrendo à manutenção manual de uma lista como a Public Suffix List
      Ver que o navegador tem esse tipo de limitação desde a origem faz a web parecer um carro feito com fita adesiva https://publicsuffix.org/learn/

    • Pelos vários links deste post, na prática existem dois problemas

  1. Quando você publica conteúdo de usuários no seu próprio domínio, como no caso do Immich, há a questão de entrar na public suffix list
  2. Quando usuários hospedam projetos open source como immich ou jellyfin no próprio domínio, isso pode ser confundido com phishing
    O primeiro é relativamente simples se você conhece a PSL, mas o segundo é mais complicado, especialmente quando o nome do software aparece no domínio

  • O problema não é o conteúdo do usuário em si, e sim que eu subi a build de release do Immich diretamente no meu servidor e o Google bloqueou o meu domínio inteiro

  • Isso não aconteceu porque o Immich realmente hospedava conteúdo de usuários, e sim em um subdomínio de preview de PR
    Na minha opinião, isso é claramente um problema no código do Google

  • Recomendo dar uma olhada na lista inteira de “Cursed Knowledge” da equipe do Immich https://immich.app/cursed-knowledge

    • Algumas coisas da lista na verdade parecem mais um design de segurança óbvio
      Por exemplo: “alguns celulares removem automaticamente as informações de GPS quando um app sem permissão de localização lê uma imagem”
      Isso me parece um comportamento natural e desejável

    • Seria ótimo se projetos pudessem compartilhar esse tipo de conhecimento em um arquivo padrão como CURSED.md
      Assim todo mundo aprenderia esse tipo de lição adquirida na prática

    • “Parâmetros de consulta do Postgres têm limite de 65.000”
      É curioso que até isso possa ser insuficiente

  • Sempre fico curioso com esse tipo de aviso
    Eles praticamente rotulam alguém diretamente como “golpista” ou “atacante”; isso não seria difamação?
    O mesmo vale para os avisos da Microsoft sobre executáveis não verificados
    Antes a mensagem era algo como “não sabemos se isso é seguro”, mas hoje parece mais “você é um atacante”

    • A palavra “golpista” não aparece no aviso em si; a formulação é algo como “atacantes podem estar neste site”, “might”
      Isso inclui casos em que um hacker terceirizado invadiu o site
      Não estão chamando o dono do site de atacante
      O jurídico provavelmente revisou o texto com bastante cuidado

    • Não sou advogado, mas não me lembro de isso já ter ido parar em tribunal
      Parece que poderia se encaixar em difamação

  • Talvez isso nem seja um problema tão grave, mas fico me perguntando se, em um lugar como o Immich, qualquer pessoa pode enviar um PR e, se receber apenas a tag de preview, esse conteúdo passa automaticamente a ser hospedado em https://pr-<num>.preview.internal.immich.cloud
    No fim, isso não significaria que qualquer um pode publicar o que quiser livremente?

    • No GitHub, quem pode adicionar labels é limitado a colaboradores, então não é totalmente aberto
      Ainda assim, há risco se um colaborador puder primeiro enviar um PR legítimo, ganhar acesso à label e depois publicar qualquer coisa

    • Parece uma ideia de phishing que realmente não custa nada

  • É difícil acreditar que uma única empresa consiga determinar até quais sites você pode acessar
    Como se limitar a execução de apps já não fosse suficiente, agora chegamos a esse nível

    • Vários problemas são consequência de o Congresso dos EUA ter operado de forma ineficiente por muito tempo

    • É impressionante como conseguiram fazer até usuários que odeiam publicidade acharem essas big techs “legais”
      Ninguém quer anúncios, mas para a empresa eles são uma fonte de receita
      Não entendo como o Google consegue embalar essa imagem empresarial antiética como se fosse algo “descolado”

  • Tenho a sensação de que a internet aberta acabou
    Agora os monopólios controlam tudo
    Mantive um app iOS na loja por 3 anos, e de repente a Apple exigiu uma nova licença que nem sequer existe, dizendo que removeria o app se eu não a apresentasse
    Nada mudou em 3 anos, mas mesmo assim foi isso que aconteceu
    Estou cada vez mais cansado de ver que nem self-hosting dá mais para fazer livremente

    • Seria muito útil se você explicasse em mais detalhes o problema com o app iOS e as exigências da Apple

  • Um amigo meu, que também é cliente, usava hospedagem do ecossistema WordPress com um redirecionamento simples
    O host acabou entrando em uma blacklist de “site perigoso”
    Mesmo depois de remover o redirecionamento, o domínio dele continuou contaminado, e por causa disso o Google simplesmente deixou de aceitar emails vindos desse domínio
    Ele conseguiu sair da blacklist após pedir revisão, mas o efeito de bloqueio de email permaneceu para sempre
    No fim, registrou um novo domínio; esse tipo de atitude do Google só incentiva a criação contínua de contas descartáveis

    • Ouvir esse tipo de história dá medo
      Só de imaginar meu domínio, que uso há 25 anos sem problemas, sendo colocado por engano em blacklist e tendo até o email bloqueado, já é horrível

  • Minha conclusão é que vale a pena separar domínios por finalidade
    Isso tem a desvantagem de fazer vários TLDs parecerem serviços oficiais em escala global, mas este caso me deixou ainda mais convencido
    Por exemplo:
    www.contoso.com (público)
    www.contoso.blog (público, com comentários de usuários)
    contoso.net (interno)
    staging.contoso.dev (desenvolvimento/endpoint zero-trust)
    raging-lemur-a012afb4.contoso.build (snapshots)

    • Mas, se você separar os domínios assim, do ponto de vista do usuário o risco de parecer phishing fica muito maior
      Uma vez recebi um email de githubnext.com; como para mim GitHub = github.com, achei naturalmente que era phishing ou spam
      No fim, era um serviço real

    • Boa abordagem

  • Também estou enfrentando o mesmo problema no meu domínio neste momento
    O Google marcou a nossa instância familiar do Immich como site perigoso, e todos os outros serviços servidos no mesmo domínio também ficaram inacessíveis no Chrome
    Na prática dá para contornar o aviso, mas isso torna impossível usar o álbum de fotos que enviei para a minha sogra

  • Passei exatamente pela mesma experiência no começo deste ano ao fazer self-host do Umami Analytics
    https://news.ycombinator.com/item?id=42779544#42783321
    Só removeram a marcação depois que mencionei “medidas legais” ao contestar no Google Search Console