Google bloqueia o site da Immich

É o cenário que todo proprietário, desenvolvedor ou administrador de sites teme: o seu site funciona perfeitamente e, de repente, torna‑se inacessível para o mundo. Os usuários não veem o seu conteúdo, mas sim um assustador aviso em tela cheia. A suposição natural é um crash de servidor, um ataque DDoS ou uma invasão maliciosa. Mas e se o culpado não for um atacante externo, mas uma decisão silenciosa e automatizada de um dos mais poderosos guardiões da Internet?

Foi exatamente isso que aconteceu com a equipe por trás do Immich, uma solução self‑hosted de backup de fotos e vídeos, recentemente. Todo o domínio deles foi subitamente marcado como “perigoso”, efetivamente apagando‑os do mapa para a maioria dos usuários. A jornada frustrante para descobrir a causa revela um perigoso ponto cego nos sistemas automatizados que atuam como xerifes autoproclamados da web — um ponto cego que pode afetar qualquer um.

Conclusão: Um guardião opaco pode apagar você da web

Um único sinal pode fazer você desaparecer

O Google Safe Browsing é um serviço gratuito integrado diretamente a navegadores como Chrome e Firefox. Seu objetivo é proteger usuários identificando e bloqueando sites que hospedam malware, software indesejado ou praticam “engenharia social”. Quando um site é sinalizado, os visitantes se deparam com uma tela de alerta vermelha. Para a equipe do Immich, essa experiência foi mais um item indesejado na sua lista de “Conhecimento Amaldiçoado”.

O impacto é imediato e devastador. Como descobriram: “seu site basicamente se torna indisponível para todos os usuários”. Apenas uma pequena fração de usuários mais técnicos ousará clicar através dos vários avisos para acessar o “site inseguro”. Para todo o restante da audiência, o site simplesmente deixa de existir. Agravando a situação está o fato de que o processo real que define um site como “perigoso” não é transparente, tornando o sistema um árbitro poderoso porém opaco da acessibilidade.

Conclusão: O alarmante efeito dominó de um único subdomínio

Um “mau” link interno pode derrubar todo o seu domínio

Após investigar o Google Search Console, a equipe Immich encontrou a origem: seus próprios ambientes internos de preview não públicos. Eram sites temporários gerados automaticamente para desenvolvimento, com URLs como main.preview.internal.immich.cloud. Os sistemas automatizados do Google aparentemente rastrearam esses sites temporários e concluíram que eram “enganosos”.

Mas a descoberta mais crítica e contraintuitiva foi o dano colateral. A marcação de um único subdomínio interno não ficou isolada. O sistema aplicou o rótulo “perigoso” ao domínio inteiro immich.cloud, derrubando serviços de produção e páginas informativas. Isso afetou até o servidor de tiles em produção em tiles.immich.cloud. Felizmente, como observaram, as requisições para esse servidor são feitas via JavaScript e não são visíveis para o usuário, então ele parecia funcionar normalmente.

O mais alarmante foi perceber que um único subdomínio sinalizado aparentemente invalida todo o domínio.

Conclusão: A “correção” é um ciclo interminável frustrante

Ser removido da lista pode virar tarefa de Sísifo

O processo oficial de recurso é criar uma conta Google, registrar o site no Search Console e enviar uma solicitação de revisão. A equipe Immich fez isso, explicando que os sites marcados eram seus próprios deployments. Um ou dois dias depois, a revisão foi aceita e o domínio estava limpo novamente! 🎉

A vitória, contudo, foi passageira. Logo descobriram que estavam presos em um purgatório algorítmico. O processo de desenvolvimento cria novos ambientes de preview para pull requests no GitHub. Assim que uma nova URL de preview era postada num comentário, os crawlers do Google a encontravam, rastreavam o site e marcavam imediatamente de novo todo o immich.cloud como perigoso. Tudo começava novamente — um inútil jogo de “whack‑a‑mole” digital.

Diante desse ciclo sem fim, a equipe elaborou um workaround: mover todos os ambientes de preview para um domínio dedicado — immich.build — isolando efetivamente o processo de desenvolvimento dos serviços de produção para evitar futuras quedas em todo o domínio.

Conclusão: O sistema parece cego ao desenvolvimento open source

Isso não é apenas o problema de um projeto; é uma ameaça ao open source

Essa experiência não é exclusiva do Immich. Ela evidencia um problema sistêmico mais amplo que representa uma ameaça significativa a projetos open source e self‑hosted. Muitos outros projetos populares — Jellyfin, YunoHost, n8n e NextCloud — enfrentaram exatamente o mesmo problema. A questão chegou até à base de usuários do Immich, pois “alguns usuários começaram a reclamar que seus próprios deployments estavam sendo sinalizados”.

O fluxo de trabalho que define o desenvolvimento open source moderno — criar ambientes públicos de preview para revisão da comunidade — está sendo interpretado erroneamente pelos sistemas automatizados do Google como atividade enganosa. Isso não é um bug; é um ponto cego fundamental de design.

O Google Safe Browsing parece ter sido construído sem considerar software open source ou self‑hosted.

Quando um fluxo de trabalho padrão e transparente é marcado como ameaça, pune justamente as comunidades que constroem as ferramentas livres e abertas das quais tantos dependem.

Conclusão: O dilema de uma web centralizada

A história do Immich lembra que guardiões centralizados detêm um poder imenso — e frequentemente arbitrário — de tornar grandes partes da web inacessíveis. Embora serviços como o Safe Browsing sejam criados com boas intenções, sua abordagem automatizada e padronizada pode causar danos significativos e involuntários a projetos legítimos. Isso nos obriga a uma pergunta difícil.

À medida que entregamos mais controle a guardiões opacos e automatizados, devemos perguntar: estamos construindo uma Internet mais segura ou, sem querer, estamos cimentando os espaços vivos e colaborativos onde nasce a próxima geração de software open source?