Google blokkeert Immich-site
Het is een scenario dat elke eigenaar, ontwikkelaar of beheerder vreest: je site draait perfect en is een minuut later ineens onbereikbaar. Bezoekers zien niet jouw inhoud, maar een angstaanjagende paginavullende waarschuwing. Logische vermoedens: een servercrash, een DDoS‑aanval of een hack. Maar wat als de oorzaak geen externe aanvaller is, maar een stille, geautomatiseerde beslissing van één van de machtigste poortwachters van het internet?
Precies dat overkwam het team achter Immich, een zelfgehoste oplossing voor foto- en videoback-ups, recentelijk. Hun hele domein werd plotseling als “gevaarlijk” aangemerkt – en daarmee voor de meeste gebruikers feitelijk weggevaagd. Hun frustrerende zoektocht naar de oorzaak legt een gevaarlijke blinde vlek bloot in geautomatiseerde systemen die zichzelf als sheriffs van het web zien—een blinde vlek die iedereen kan treffen.
Belangrijk inzicht: Een ondoorzichtige poortwachter kan je uit het web wissen
Eén enkele flag kan je laten verdwijnen
Google Safe Browsing is een gratis dienst, direct geïntegreerd in grote browsers zoals Chrome en Firefox. Het doel: gebruikers beschermen door sites te blokkeren die malware, ongewenste software of “social engineering” bevatten. Zodra een site wordt geflagd krijgen bezoekers een felrood waarschuwingsscherm. Voor het Immich‑team was dit een ongewenste toevoeging aan hun lijst met “vervloekte kennis”.
De impact is onmiddellijk en vernietigend. Zoals ze ontdekten: “je site wordt in feite onbereikbaar voor alle gebruikers”. Alleen een kleine groep technisch zeer vaardige mensen durft door meerdere waarschuwingen heen te klikken om de “onveilige” site te bereiken. Voor de rest van je publiek houdt je website simpelweg op te bestaan. Lastig daarbij is dat het proces waarmee een site als “gevaarlijk” wordt bestempeld niet transparant is, waardoor het systeem een machtige maar ondoorzichtige arbiter van bereikbaarheid wordt.
Belangrijk inzicht: Het zorgwekkende domino‑effect van één subdomein
Eén “slechte” interne link kan je hele domein neerhalen
Na een duik in Google Search Console vond het Immich‑team de bron: hun eigen interne, niet‑publieke previewomgevingen. Tijdelijke sites, automatisch gegenereerd voor ontwikkeling, met URLs zoals main.preview.internal.immich.cloud. De geautomatiseerde systemen van Google hadden deze omgevingen blijkbaar gecrawld en als “misleidend” aangemerkt.
De meest kritieke en tegenintuïtieve ontdekking was de nevenschade: Een flag op een enkel intern subdomein bleef niet geïsoleerd. Het volledige domein immich.cloud kreeg het label “gevaarlijk”, inclusief productie‑services en informatieve pagina’s. Zelfs hun production tileserver op tiles.immich.cloud werd geraakt. Gelukkig verlopen verzoeken naar die server via JavaScript en zijn niet direct zichtbaar voor eindgebruikers, waardoor hij ogenschijnlijk bleef werken.
Het meest verontrustend: één geflagd subdomein kan blijkbaar het hele domein ongeldig maken.
Belangrijk inzicht: De “fix” is een frustrerende eindeloze lus
Ont‑flaggen kan een Sisyfus‑taak worden
De officiële route: een Google‑account aanmaken, je site registreren in Search Console en een herbeoordeling aanvragen. Het Immich‑team deed precies dat en legde uit dat de gemarkeerde sites eigen deployments waren. Een dag of twee later werd de review geaccepteerd en was het domein weer schoon! 🎉
De overwinning was echter van korte duur. Al snel zaten ze vast in een algoritmisch vagevuur. Hun ontwikkelproces maakt voor elke pull request op GitHub een nieuwe previewomgeving. Zodra een nieuwe preview‑URL in een comment verscheen, vonden de Google‑crawlers deze, crawlden de site en markeerden onmiddellijk opnieuw het hele immich.cloud‑domein als gevaarlijk. Het proces begon weer van voren af aan – een zinloos spel digitaal whack‑a‑mole.
Geconfronteerd met deze eindeloze cyclus bedacht het team een workaround: alle previewomgevingen verhuizen naar een eigen dedicated domein—immich.build—en zo de ontwikkeling isoleren van productie om toekomstige domeinbrede blokkades te voorkomen.
Belangrijk inzicht: Het systeem lijkt blind voor open‑source ontwikkeling
Dit is niet alleen het probleem van één project; het is een bedreiging voor open source
Deze ervaring is niet uniek voor Immich. Ze wijst op een breder systemisch probleem dat een serieuze bedreiging vormt voor open‑source en zelfgehoste projecten. Veel andere populaire projecten—Jellyfin, YunoHost, n8n, NextCloud—liepen tegen precies hetzelfde aan. Het probleem bereikte zelfs Immich‑gebruikers: “enkele gebruikers begonnen te klagen dat hun eigen Immich‑deployments werden geflagd”.
De workflow die moderne, transparante, collaboratieve open‑source ontwikkeling definieert—publieke previewomgevingen voor community review—wordt door de geautomatiseerde systemen van Google verkeerd geïnterpreteerd als misleidende activiteit. Dit is geen bug; het is een fundamenteel ontwerppunt dat over het hoofd is gezien.
Google Safe Browsing lijkt gebouwd zonder rekening te houden met open‑source of zelfgehoste software.
Wanneer een standaard, transparante ontwikkelworkflow als bedreiging wordt bestempeld, straft dat juist de communities die vrije en open tools bouwen waar zovelen op vertrouwen.
Conclusie: Het dilemma van een gecentraliseerd web
Het Immich‑verhaal herinnert ons eraan dat gecentraliseerde poortwachters enorme – vaak willekeurige – macht hebben om hele delen van het web onbereikbaar te maken. Diensten als Safe Browsing zijn goed bedoeld, maar hun geautomatiseerde eenheidsaanpak kan aanzienlijke, onbedoelde schade veroorzaken aan legitieme projecten. Het dwingt ons tot een moeilijke vraag.
Terwijl we meer controle overdragen aan ondoorzichtige, geautomatiseerde poortwachters, moeten we ons afvragen: bouwen we echt een veiliger internet, of leggen we onbedoeld de levendige, collaboratieve ruimtes plat waar de volgende generatie open‑source software ontstaat?