ハクソク

世界を動かす技術を、日本語で。

Googleが「Immich」サイトを危険と警告

2025年10月23日原文(immich.app)

概要

  • 2025年10月、 Immich関連サイト がGoogle Safe Browsingにより 危険サイト扱い
  • Google Safe Browsing は多くのブラウザに組み込まれ、警告が表示される仕組み
  • サブドメイン一つが フラグされると、全ドメインに影響
  • 問題解決には Google Search Console でのレビュー申請が必須
  • 今後の対策として プレビュー環境のドメイン分離 を検討

ImmichサイトがGoogleに危険とフラグされた経緯

  • 2025年10月、 immich.cloud 配下の全サイトが 危険サイト として警告表示
  • ブラウザで「赤い警告画面」が表示され、ほぼ全ユーザーがアクセス不可状態
  • Immichチーム内でも Safe Browsingの仕組み が不明で混乱
  • Google Safe Browsing はマルウェアやフィッシング等を検知する無料サービス
    • ChromeやFirefoxなど主要ブラウザに統合
    • フラグの基準や仕組みは公開されていない
  • 一度フラグされると、 「詳細」→「安全なサイトに進む」 を選ばない限り閲覧不可

フラグ発覚と影響範囲

  • ある日、 immich.cloud 配下の複数サイトが一斉に 危険判定
  • ユーザーからも 自分のImmich環境が警告表示 との報告
  • 社内のプレビュー環境や内部サービス （zitadel, outline, grafana, victoria metrics等）も全て影響
  • tiles.immich.cloud のようなプロダクション用タイルサーバーも影響を受けるが、JavaScript経由のため一部は正常動作

Google Search Consoleによる対応

  • 数日経っても警告が消えず、 Google Search Console が唯一の公式対応窓口と判明
  • サイト復旧には Googleアカウント作成→Search Console登録→レビュー申請 が必要
  • Search Consoleでは「 有害なコンテンツ検出」「 ユーザーを騙す行為」といった理由が表示
  • フラグされたURLは プレビュー環境 のものが中心
  • 一つのサブドメイン がフラグされると 全ドメインに波及 する仕様

問題解決の流れと再発

  • Search Consoleの「 レビュー申請」で以下の内容を説明
    • Immichは 自社運用の自社製品
    • フラグされたサイトは 自社のプレビュー環境 で、他社や他人のなりすましではない
  • 申請後、 1～2日で復旧。一旦「安全なサイト」に戻る
  • しかし、 新たなプレビュー環境を作成 すると、再び 危険サイト扱い に
    • GitHub上のPRに新しいプレビューURLが投稿される
    • GoogleがGitHubをクロール→新URLを検出→再度フラグ

今後の対応策

  • プレビュー環境専用ドメイン（immich.build） への移行を検討
  • これにより、 本番ドメインへの波及防止 を目指す

Safe BrowsingとOSS・セルフホストの課題

  • Google Safe Browsing はOSSやセルフホスト型ソフトウェアの運用に配慮されていない設計
  • 他の人気プロジェクトでも 同様の問題 が発生
  • Googleは 任意のドメインを即座にフラグ可能 で、ユーザーアクセスがほぼ遮断される
  • 対応策は 都度Googleにレビュー申請 するしかない現状

まとめ

  • Google Safe Browsing によるフラグは ドメイン全体に多大な影響
  • OSS・セルフホスト運用者 にとっては 避けがたいリスク
  • 現時点では ドメイン分離や迅速なレビュー申請 が唯一の自衛策

Hackerたちの意見

これ、最近別のホスティングサイトが引っかかった件と関係あるっぽいね。 https://news.ycombinator.com/item?id=45538760

└

同じ独占の乱用って点では似てるけど、これは明確にファーストパーティのコンテンツを指してるから、ユーザーコンテンツとは違うよね。

これ、対策次第では大した問題じゃないかもしれないけど、誰でもImmichにPR（何でも含めて）を提出して、previewタグを付けたら、そのPRの内容がhttps://pr-.preview.internal.immich.cloudにホストされるってこと？ それって、実質的に誰でもそこに何でもホストできるってことじゃない？

└

無料でフィッシングできる素晴らしいアイデアだね。

└

GitHubではコラボレーターだけがラベルを追加できるから、ちょっと違うかも。でも、確かに危険な感じはするね（正当なPRを提出してラベルをもらった後に、好きなことをコミットできちゃうってこと？）。

チームの「呪われた知識」のリストもぜひ見てみて。 https://immich.app/cursed-knowledge

└

Postgresのクエリパラメータの話、面白いね。65,000パラメータじゃ足りないの？！

robots.txtでその内部サブドメインを検索からブロックしたら、Googleはまだ文句言うの？

└

「plex.example.com」みたいな完全に内部のドメインを使ってる人の話を聞いたことがあるけど、公開インターネットに出てないのに、Googleがそれをplexのなりすましと見なすこともあるみたい。Googleは、名前が他のサービスを偽ってると思ったら、名前だけでブロックすることもあるんだ。安全なブラウジングでサイトがブロックされる条件は正確にはわからないけど、私のnextcloud.something.tldのドメインは今まで一度もフラグが立ったことがない。でも、他の人が問題を抱えてるサポートスレッドを見たことがあって、ドメイン名が原因の可能性が高いと思う。

ユーザーコンテンツをサブドメインでホストするなら、Public Suffix Listにサイトを載せた方がいいよね。 https://publicsuffix.org/list/ それがいろんなサービスに反映されて、汚染されたサブドメインがサイト全体を汚染しないってことになるはず。

└

画像だけがユーザーコンテンツの場合、これって本当に関係あるのかな？普通、PSLはクッキーやユーザーが提供したフォームの文脈で見ることが多いけど。

└

あぁ、Jothan Frakesを見かけて、一瞬、好きなスターフリートのファーストオフィサーの俳優が後にソフトウェアを書くようになったのかと思ったよ。

Hacker Newsで議論の続きを見る