Google markiert Immich-Seiten als gefährliche Websites

 (immich.app)
1 Punkte von GN⁺ 2025-10-23 | 1 Kommentare | Auf WhatsApp teilen
  • Durch den Dienst Google Safe Browsing erhielten zuletzt alle mit Immich verbundenen Websites eine Warnung als gefährlich
  • Die gesamte Domain immich.cloud war betroffen, wodurch der Zugriff in den meisten Browsern praktisch blockiert wurde
  • Ursache war, dass interne Deployment-URLs wie Preview-Umgebungen automatisch gecrawlt und als Fehlalarm eingestuft wurden
  • Über die Google Search Console konnte das Problem kurzfristig per Einspruch behoben werden, tritt aber bei jeder neuen Preview erneut auf
  • Aufgrund der Eigenschaften eines Open-Source- und Self-Hosting-Dienstes handelt es sich um ein strukturelles Problem; künftig sollen Preview-Umgebungen auf eine separate Domain ausgelagert werden

Der Vorfall, bei dem Google Immich-Seiten als gefährlich markierte

  1. Oktober 2025
    Von Jason Rasmussen

Überblick

  • Anfang dieses Monats wurden alle Websites unter *.immich.cloud als gefährlich eingestuft, und Nutzer sahen im Browser Sicherheitswarnungen, den sogenannten „red-screen-of-death“
  • Im Team wusste zunächst niemand genau, wie diese Browserfunktion eigentlich arbeitet, inzwischen gehört das Wissen dazu zur Liste des „cursed knowledge“

Hintergrund

  • Google bietet den Dienst Safe Browsing kostenlos an, um festzustellen, ob Malware, unerwünschte Software oder Social-Engineering-Täuschungen vorliegen
  • Große Browser wie Chrome und Firefox binden diesen Dienst ein
  • Wie die tatsächliche Risikobewertung erfolgt, ist unklar
  • Wenn eine Website als gefährlich eingestuft wird, können die meisten Nutzer sie faktisch nicht mehr verwenden
  • Nur ein sehr kleiner Teil der Nutzer kann noch über „Details anzeigen“ und „Diese unsichere Website besuchen“ darauf zugreifen

Wahrnehmung der Markierung

  • Anfang des Monats wurden viele Websites der Domain immich.cloud als „gefährlich“ markiert, und Nutzer beschwerten sich zudem, dass auch ihre selbst bereitgestellten Immich-Instanzen markiert worden seien
  • Auch alle intern genutzten Seiten wie Preview-Umgebungen waren von den Warnungen betroffen
  • Dadurch musste jedes Mal umständlich der Weg über die Anzeige der „sicheren Website“ gegangen werden

Reaktion über die Google Search Console

  • Da die Warnungen auch nach mehreren Tagen nicht verschwanden, entschied man sich, den offiziellen Weg über die Google Search Console zu nutzen

  • Dafür sind ein Google-Konto, die Nutzung der Search Console und eine Review-Anfrage für die markierte Website erforderlich

  • Die Search Console liefert einige Hinweise dazu, warum eine Website als gefährlich eingestuft wurde

    • „Google hat auf einigen Seiten Ihrer Website schädliche Inhalte erkannt“
    • „Diese Seiten enthalten Risiken wie die Aufforderung zur Installation unerwünschter Software oder die Offenlegung personenbezogener Daten“

  • Bei der Prüfung der vollständigen Liste betroffener URLs zeigte sich, dass es sich ausschließlich um URLs aus Preview-Umgebungen handelte

  • Besonders schockierend war, dass bereits die Markierung einer einzigen Subdomain dazu führte, dass die gesamte Domain als problematisch eingestuft wurde

Auswirkungen

  • Betroffen waren Preview-Umgebungen und interne Dienste wie zitadel, outline, grafana, victoria metrics usw.
  • Auch der Production-Tile-Server (tiles.immich.cloud) war betroffen
  • Da der Tile-Server jedoch nur per JavaScript angesprochen wird und keine direkte Benutzeroberfläche besitzt, funktionierte er weiterhin normal

Versuch der „Lösung“ des Problems

  • In der Google Search Console muss über die Funktion Request Review Einspruch eingelegt und erläutert werden, wie das Problem behoben wurde
  • Wird nur eine Review angefordert, ohne das Problem tatsächlich zu beheben, dauert die Prüfung länger

Anfrage zur Wiederherstellung der als gefährlich markierten Website

  • Da man zu dem Schluss kam, dass faktisch kein echtes Problem vorlag, wurde die folgende Erklärung eingereicht

    • Immich ist eine Anwendung für Self-Hosting, und das Immich-Team (https://immich.app/) verwaltet und betreibt die gesamte betreffende Domain direkt selbst
    • Bei allen markierten Websites handelt es sich um offizielle, selbst bereitgestellte Umgebungen, die niemanden imitieren

  • Innerhalb von 1–2 Tagen wurde die Domain wieder als unbedenklich eingestuft und der Zugriff wiederhergestellt

Bemühungen zur Minimierung des Problems

  • Wird einem GitHub Pull Request das Label preview hinzugefügt, wird automatisch eine Immich-Preview-Umgebung erstellt; unmittelbar danach erscheint zusammen mit einem Verifizierungskommentar die Preview-URL

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

  • Jedes Mal, wenn eine neue Preview-Umgebung erstellt wird, wird die Domain immich.cloud erneut als gefährlich eingestuft

  • Es wird vermutet, dass Google GitHub crawlt, dabei neue URLs entdeckt, besucht und anschließend als gefährlich einstuft

  • Als aktuelle Gegenmaßnahme ist geplant, Preview-Umgebungen auf eine separate Domain (immich.build) auszulagern

Das größere Problem

  • Das System Google Safe Browsing scheint ohne Berücksichtigung der Eigenschaften von Open-Source- und Self-Hosting-Software entworfen worden zu sein
  • Neben Immich haben auch mehrere andere populäre Projekte ähnliche Probleme erlebt
  • Google kann offenbar beliebige Domains nach eigenem Ermessen blockieren, und es gibt praktisch kaum andere Gegenmaßnahmen, als bei Google fortlaufend Reviews zu beantragen

Cheers,
Das Immich-Team

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-23
Hacker-News-Kommentare

  • Wenn man plant, Benutzerinhalte auf Subdomains zu hosten, sollte man die Site in die Public Suffix List eintragen: https://publicsuffix.org/list/
    Dann kann eine kompromittierte Subdomain nicht die ganze Site beeinträchtigen.

    • Wenn man nutzergenerierte Inhalte hostet, muss man eigentlich in der PSL stehen; unter Webentwicklern ist das eine Art stillschweigendes Allgemeinwissen.
      Ohne einen Fall wie bei Immich erlebt zu haben, ist es allerdings schwer, so etwas zu wissen, daher kennen die meisten es nicht, bevor sie selbst darüber stolpern.

    • Früher verwendeten Browser einen Algorithmus, der breit gesetzte Cookies nur verhinderte, wenn die Domain keinen Punkt enthielt, also etwa .com oder .org.
      Bei Sublevel-Domains wie .co.uk führte das aber dazu, dass Cookies an alle darunter registrierten Domains durchgereicht werden konnten.
      Da jede Top-Level-Domain andere Registrierungsregeln hat und sich das entwicklungsseitig nicht sauber lösen ließ, entstand am Ende ein manuell gepflegter Ansatz wie die Public Suffix List.
      Dass Browser von Haus aus solche Grenzen haben, lässt das Web wie ein mit Panzertape zusammengebautes Auto wirken: https://publicsuffix.org/learn/

    • Wenn man sich die verschiedenen Links unter diesem Beitrag ansieht, gibt es in Wirklichkeit zwei Probleme.

  1. Das Problem, in die Public Suffix List aufgenommen zu werden, wenn man wie Immich Benutzerinhalte unter der eigenen Domain veröffentlicht
  2. Das Problem, dass Nutzer Open-Source-Projekte wie immich oder jellyfin unter ihrer eigenen Domain hosten und dann für Phishing gehalten werden
    Das erste ist vergleichsweise einfach, wenn man PSL kennt; das zweite ist deutlich kniffliger, insbesondere wenn der Domainname den Namen der Software enthält.

  • Das Problem ist nicht der Benutzerinhalt selbst, sondern dass ich den Release-Build von Immich direkt auf meinem Server gehostet habe und Google daraufhin meine gesamte Domain blockiert hat.

  • Das Problem trat nicht auf, weil Immich tatsächlich Benutzerinhalte gehostet hat, sondern auf einer Subdomain für PR-Previews.
    Ich halte das ganz klar für einen Bug in Googles Code.

  • Ich empfehle, sich die komplette Liste mit dem „Cursed Knowledge“ des Immich-Teams einmal anzusehen: https://immich.app/cursed-knowledge

    • Einiges auf dieser Liste wirkt eher wie selbstverständliches Security-Design.
      Zum Beispiel: „Einige Smartphones entfernen GPS-Informationen automatisch, wenn eine App ohne Standortberechtigung ein Bild liest.“
      Das wirkt eher wie ein natürliches und wünschenswertes Verhalten.

    • Es wäre schön, wenn Projekte solche Arten von Know-how in einer Standarddatei wie CURSED.md teilen könnten.
      Dann könnten alle von diesem in der Praxis gewonnenen Wissen profitieren.

    • „Postgres-Abfrageparameter haben ein Limit von 65.000.“
      Dass selbst das nicht reicht, ist schon bemerkenswert.

  • Bei solchen Warnhinweisen frage ich mich immer:
    Sie verteilen ziemlich direkt Etiketten wie „Betrüger“ oder „Angreifer“ — fällt das nicht unter Verleumdung?
    Dasselbe gilt für Microsofts Warnungen vor nicht verifizierten ausführbaren Dateien.
    Früher hieß es eher: „Wir wissen nicht, ob das sicher ist“, heute eher: „Sie sind ein Angreifer.“

    • Das Wort „Betrüger“ wird in der eigentlichen Warnung nicht verwendet; dort steht eher, „Angreifer könnten sich auf der Site befinden“ oder Formulierungen mit „might“.
      Das schließt auch Fälle ein, in denen ein Dritter die Site kompromittiert hat.
      Der Site-Betreiber wird damit nicht als Angreifer bezeichnet.
      Die Rechtsabteilung wird die Formulierung vermutlich sehr sorgfältig geprüft haben.

    • Ich bin kein Anwalt, aber ich glaube nicht, dass so eine Warnformulierung jemals vor Gericht gelandet ist.
      Es könnte allerdings durchaus als Verleumdung gelten.

  • Vielleicht ist das gar kein so großes Problem, aber ich frage mich: Kann bei Immich wirklich jeder einfach einen PR einreichen, nur das Preview-Label bekommen, und der Inhalt wird dann automatisch unter https://pr-<num>.preview.internal.immich.cloud gehostet?
    Dann könnte ja letztlich jeder beliebigen Inhalt frei hochladen, oder?

    • Auf GitHub ist das Setzen von Labels auf Personen mit Kollaborationsrechten beschränkt, also völlig offen ist es nicht.
      Trotzdem gibt es ein Risiko, falls ein Kollaborateur erst einen legitimen PR einreicht, dadurch das Label bekommt und danach alles Mögliche hochladen kann.

    • Klingt nach einer echten Idee für kostenlose Phishing-Infrastruktur.

  • Es ist kaum zu glauben, dass ein einzelnes Unternehmen sogar mitbestimmen kann, auf welche Websites man zugreifen darf.
    Es reicht offenbar nicht mehr, das Ausführen von Apps zu beschränken — jetzt sind wir schon hier.

    • Das ist eine Folge davon, dass der US-Kongress über lange Zeit ineffizient gearbeitet hat.

    • Es ist erstaunlich, wie sie es geschafft haben, sogar Nutzer, die Werbung hassen, dazu zu bringen, solche Großkonzerne für „cool“ zu halten.
      Werbung will eigentlich niemand, für Unternehmen ist sie aber ein Einnahmemodell.
      Ich verstehe nicht, wie Google dieses unethische Unternehmensbild noch als etwas „Cooles“ verkaufen kann.

  • Ich habe das Gefühl, das offene Internet ist vorbei.
    Jetzt wird alles von Monopolen beherrscht.
    Ich hatte drei Jahre lang eine iOS-App im Store, und plötzlich verlangte Apple eine neue Lizenz, die es gar nicht gibt, mit der Ankündigung, die App sonst zu entfernen.
    In diesen drei Jahren hatte sich überhaupt nichts geändert, und trotzdem lief es so.
    Es geht mir zunehmend auf die Nerven, dass man inzwischen nicht einmal mehr Self-Hosting frei betreiben kann.

    • Wenn du das Problem mit der iOS-App und Apples Anforderungen genauer erklären würdest, wäre das wirklich hilfreich.

  • Ein Freund von mir, zugleich Kunde, nutzte WordPress-basiertes Hosting und eine einfache Weiterleitung.
    Irgendwann landete der Host auf einer Blacklist für „gefährliche Websites“.
    Selbst nachdem die Weiterleitung entfernt wurde, war auch seine eigene Domain weiterhin kontaminiert, und Google nahm von dieser Domain überhaupt keine E-Mails mehr an.
    Über eine Prüfungsanfrage kam die Domain zwar wieder von der Blacklist, aber die E-Mail-Sperre blieb dauerhaft bestehen.
    Am Ende registrierte er eine neue Domain; Googles Verhalten motiviert letztlich nur dazu, immer neue Wegwerfkonten anzulegen.

    • Wenn ich so etwas höre, macht mir das Angst.
      Allein die Vorstellung, dass meine seit 25 Jahren problemlos genutzte Domain fälschlich auf eine Blacklist gerät und dann auch noch E-Mail blockiert wird, ist furchtbar.

  • Mein Fazit ist, dass man besser für jeden Zweck getrennte Domains verwenden sollte.
    Das hat zwar den Nachteil, dass verschiedene TLDs weltweit weniger wie ein offizieller Dienst wirken, aber dieser Fall bestärkt mich noch darin.
    Zum Beispiel:
    www.contoso.com (öffentlich)
    www.contoso.blog (öffentlich, mit Benutzerkommentaren)
    contoso.net (intern)
    staging.contoso.dev (Entwicklung/Zero-Trust-Endpunkt)
    raging-lemur-a012afb4.contoso.build (für Snapshots)

    • Wenn man Domains so trennt, wirkt das aus Nutzersicht allerdings viel eher wie Phishing.
      Ich habe einmal eine Mail von githubnext.com bekommen, und da ich Github = github.com im Kopf hatte, hielt ich sie selbstverständlich für Phishing oder Spam.
      Am Ende stellte sich heraus, dass es ein echter Dienst war.

    • Guter Ansatz.

  • Ich habe derzeit mit meiner eigenen Domain dasselbe Problem.
    Google stuft unsere Familien-Immich-Instanz als gefährliche Website ein, wodurch auch alle anderen Dienste unter derselben Domain in Chrome nicht mehr erreichbar sind.
    Man kann die Warnung zwar umgehen, aber das Fotoalbum, das ich meiner Schwiegermutter geschickt habe, ist damit praktisch unbenutzbar.

  • Ich hatte Anfang dieses Jahres genau dasselbe Erlebnis, als ich Umami Analytics selbst gehostet habe.
    https://news.ycombinator.com/item?id=42779544#42783321
    Erst als ich mich in meiner Beschwerde bei Google Search Console auf „rechtliche Schritte“ bezogen habe, wurde die Markierung aufgehoben.