Google blocca il sito Immich
È lo scenario temuto da ogni proprietario, sviluppatore o amministratore di siti: il sito funziona perfettamente e, all’improvviso, diventa inaccessibile al mondo. Gli utenti non vedono i tuoi contenuti, ma una spaventosa schermata di avviso a pagina intera. Si pensa subito a un crash del server, a un attacco DDoS o a un hacking. Ma se il colpevole non fosse un attaccante esterno, bensì una decisione silenziosa e automatizzata di uno dei più potenti gatekeeper di Internet?
È esattamente ciò che è successo al team dietro Immich, una soluzione self‑hosted per il backup di foto e video, recentemente. L’intero dominio è stato improvvisamente contrassegnato come “pericoloso”, di fatto cancellandolo per la maggior parte degli utenti. Il percorso frustrante per individuare la causa rivela un pericoloso punto cieco nei sistemi automatizzati che si comportano come sceriffi autoproclamati del web—un punto cieco che potrebbe colpire chiunque.
Conclusione: Un gatekeeper opaco può cancellarti dal web
Un singolo flag può farti sparire
Google Safe Browsing è un servizio gratuito integrato direttamente nei principali browser come Chrome e Firefox. Il suo obiettivo è proteggere gli utenti identificando e bloccando siti che ospitano malware, software indesiderato o praticano “social engineering”. Quando un sito viene segnalato, i visitatori trovano una schermata di avviso rosso. Per il team Immich, è stato un’aggiunta indesiderata alla loro lista di “conoscenze maledette”.
L’impatto è immediato e devastante. Come hanno scoperto: “il tuo sito diventa essenzialmente non disponibile per tutti gli utenti”. Solo una piccola frazione di utenti tecnicamente esperti oserà cliccare oltre i molteplici avvisi per accedere al “sito non sicuro”. Per il resto del pubblico, il sito smette di esistere. A complicare il quadro è la mancanza di trasparenza sul processo che porta a definire un sito “pericoloso”, rendendo il sistema un arbitro potente ma opaco dell’accessibilità.
Conclusione: Il preoccupante effetto domino di un singolo sottodominio
Un “cattivo” link interno può abbattere l’intero dominio
Dopo aver analizzato la Google Search Console, il team Immich ha trovato la fonte: i propri ambienti interni di anteprima non pubblici. Siti temporanei generati automaticamente per lo sviluppo, con URL come main.preview.internal.immich.cloud. I sistemi automatizzati di Google avrebbero effettuato il crawl di questi siti temporanei e li avrebbero classificati come “ingannevoli”.
La scoperta più critica e controintuitiva è stata il danno collaterale. La segnalazione di un singolo sottodominio interno non è rimasta isolata. Il sistema ha applicato l’etichetta “pericoloso” all’intero dominio immich.cloud, bloccando servizi di produzione e pagine informative. È stato coinvolto persino il tile server di produzione tiles.immich.cloud. Per fortuna, come hanno notato, le richieste avvengono via JavaScript e non sono visibili all’utente, quindi sembrava funzionare normalmente.
La cosa più allarmante è stata realizzare che un solo sottodominio segnalato può invalidare l’intero dominio.
Conclusione: La “soluzione” è un ciclo infinito frustrante
Essere de‑segnalati può diventare un compito da Sisifo
La procedura ufficiale: creare un account Google, registrare il sito nella Search Console e inviare una richiesta di revisione. Il team Immich l’ha fatto, spiegando che i siti segnalati erano i propri deploy. Dopo uno o due giorni la revisione è stata accettata e il dominio ripulito! 🎉
La vittoria, però, è stata effimera. Ben presto si sono ritrovati intrappolati in un purgatorio algoritmico. Il loro processo di sviluppo crea nuovi ambienti di anteprima per ogni pull request su GitHub. Non appena una nuova URL di anteprima veniva pubblicata in un commento, i crawler di Google la trovavano, la eseguivano e marchiavano immediatamente di nuovo l’intero immich.cloud come pericoloso. L’intero processo ripartiva – un infruttuoso gioco di “whack-a-mole” digitale.
Di fronte a questo ciclo senza fine, il team ha ideato un workaround: spostare tutti gli ambienti di anteprima su un dominio dedicato — immich.build — isolando di fatto lo sviluppo dai servizi di produzione ed evitando futuri blocchi su tutto il dominio.
Conclusione: Il sistema sembra cieco allo sviluppo open source
Non è solo il problema di un singolo progetto; è una minaccia all’open source
Questa esperienza non è unica per Immich. Evidenzia un problema sistemico più ampio che rappresenta una minaccia significativa per i progetti open source e self‑hosted. Molti altri progetti popolari — Jellyfin, YunoHost, n8n, NextCloud — hanno affrontato lo stesso problema. Il problema si è esteso anche agli utenti Immich, poiché “alcuni hanno iniziato a lamentarsi che i propri deploy venivano segnalati”.
Il flusso di lavoro che definisce lo sviluppo open source moderno — creare ambienti pubblici di anteprima per la revisione della community — viene interpretato erroneamente dai sistemi automatizzati di Google come attività ingannevole. Non è un bug; è un fondamentale punto cieco di progettazione.
Google Safe Browsing sembra essere stato costruito senza considerare software open source o self‑hosted.
Quando un workflow standard e trasparente viene etichettato come minaccia, penalizza proprio quelle community che costruiscono gli strumenti liberi e aperti da cui tanti dipendono.
Conclusione: Il dilemma di un web centralizzato
La storia di Immich è un monito sul fatto che i gatekeeper centralizzati detengono un potere enorme — spesso arbitrario — di rendere inaccessibili intere sezioni del web. Pur essendo creati con buone intenzioni, servizi come Safe Browsing, con un approccio automatizzato uniforme, possono causare danni significativi e involontari a progetti legittimi. Ci costringe a una domanda difficile.
Mentre cediamo sempre più controllo a gatekeeper opachi e automatizzati, dobbiamo chiederci: stiamo costruendo un Internet più sicuro, o stiamo inconsapevolmente asfaltando gli spazi vivaci e collaborativi in cui nasce la prossima generazione di software open source?