GoogleがImmichサイトを危険なサイトとして表示
(immich.app)- 最近、Google Safe Browsing サービスの影響で、Immich 関連のすべてのサイトに危険警告が表示された
- immich.cloud ドメイン全体が影響を受け、ほとんどのブラウザで事実上アクセスがブロックされた
- 原因は、Preview 環境などの内部デプロイ URL が自動でクロールされ、誤検知 として扱われたため
- Google Search Console で異議申し立てを行って短期的には復旧したが、新しい Preview が作成されるたびに問題が繰り返し発生する
- オープンソース・セルフホスティング サービスの特性上の構造的な問題であり、今後は Preview 環境を別ドメインに分離する予定
GoogleがImmichサイトを危険なサイトとして表示した事件
2025年10月20日
By Jason Rasmussen
概要
- 今月初め、
*.immich.cloudのすべてのウェブサイトが危険なサイトに分類され、ユーザーはブラウザでセキュリティ警告（いわゆる "red-screen-of-death"）画面を見ることになった - チーム内の誰も、このブラウザ機能がどのように動作するのか明確には理解していなかったが、今ではこの関連知識が "cursed knowledge" の一覧に加わった
背景
- Google は Safe Browsing サービスを無料で提供しており、これはマルウェア、望ましくないソフトウェア、ソーシャルエンジニアリングによる欺きの有無を判断することを目的としている
- Chrome、Firefox などの主要ブラウザがこのサービスを連携している
- サービスが実際にどのように危険判定を行っているかは不明瞭である
- サイトが危険として分類されると、ほとんどのユーザーがそのサイトを利用できなくなる問題が発生する
- ごく一部のユーザーだけが「詳細を表示」および「安全でないサイトにアクセスする」リンクを通じてのみ入ることができる
フラグ付けされた状況の認識
- 今月初め、
immich.cloudドメイン上の多数のサイトに「危険」表示が付き、ユーザーからは自己ホストされた Immich インスタンスもフラグ付けされたという不満が寄せられた - 内部で使用している Preview 環境など、すべての内部サイトでも同様に警告が発生した
- 毎回「安全でないサイト」表示を経由しなければならない不便が続いた
Google Search Console を通じた対応
-
数日たっても警告が解除されなかったため、正式な対応経路である Google Search Console を利用することにした
-
このサービスでは、Google アカウントの作成、Search Console の利用、フラグ付けされたサイトに対するレビュー依頼が必須となる
-
Search Console は危険判定の理由について一部説明を提供する
- 「Google が、あなたのサイトの一部ページで有害なコンテンツを検出しました」
- 「これらのページには、望ましくないソフトウェアのインストールを促したり、個人情報を露出させたりする危険要素があります」
-
問題として指摘された URL の一覧を確認したところ、すべて Preview 環境に関連する URL だった
-
個別のサブドメインが1つだけフラグ付けされても、ドメイン全体が不良判定されるという点が最も衝撃的だった
影響
- Preview 環境および内部サービス（zitadel、outline、grafana、victoria metrics など）はすべて影響範囲に含まれた
- Production tile server（
tiles.immich.cloud）も対象だった - ただし tile server は JavaScript 経由でリクエストされ、直接のユーザーインターフェースを持たないため、正常に動作していることが確認された
問題の「解決」試行
- Google Search Console の
Request Review機能で異議申し立てを行い、解決内容を説明する必要がある - 実際には問題を解決せずにレビューだけを依頼した場合、審査期間が長くなる
危険なサイトの復旧要請
-
実質的な問題点はないと判断されたため、以下のように対応内容を伝えた
- Immich はセルフホスティング向けのアプリケーションであり、Immich チーム（https://immich.app/）が当該ドメイン全体を直接管理・運…
- フラグ付けされたサイトはすべて公式の自己ホスト環境にすぎず、他者になりすましてはいない
-
1〜2日以内にドメインは正常判定に戻り、アクセス可能な状態に復旧した
問題を最小化するための取り組み
-
GitHub Pull Request に
previewラベルを追加すると Immich Preview 環境が自動生成され、生成直後に本人確認コメントとともに Preview URL が作成されるhttps://pr-<num>.preview.internal.immich.cloud/ -
新しい Preview 環境が作られるたびに、
immich.cloudドメインが再び危険判定を受ける -
Google が GitHub をクロールして新しい URL を発見・探索し、その後危険扱いしているものと推定される
-
現在の対策として、Preview 環境専用の別ドメイン（
immich.build）へ分離する計画を進めている
より大きな問題
- Google Safe Browsing システムは、オープンソースおよびセルフホスティングソフトウェア の特性を考慮せずに設計されているように見える
- Immich 以外にも、多くの人気プロジェクトが類似の問題を経験している
- Google は任意のドメインをブロックでき、これに対する実質的な対抗策は、Google に継続的にレビューを依頼する以外にほとんど方法がない状況である
Cheers,
The Immich Team
1件のコメント
Hacker Newsの意見
ユーザーコンテンツをサブドメインでホスティングする予定なら、サイトを Public Suffix List に登録すべき https://publicsuffix.org/list/
こうしておけば、汚染されたサブドメインがサイト全体に影響しない
ユーザー生成コンテンツをホスティングするなら PSL に入っているべき、というのは Web 開発者の間では一種の暗黙知になっている
Immich の件のように事前に経験していないとこうした事実はなかなか分からないので、実際に遭遇するまでは大半の人が知らない部分でもある
昔のブラウザは、ドメインにドットがない場合にだけ広範な Cookie 設定を防ぐアルゴリズムを使っていた（例:
.com,.org）しかし
.co.ukのようなサブレベルドメインでは、すべての下位登録ドメインに Cookie が漏れてしまう問題があったTLD ごとに登録ポリシーが異なるため、開発側で解決する方法がなく、結局 Public Suffix List のようなリストを手動で管理する方式が出てきた
ブラウザ自体に生まれつきこうした限界があるのを見ると、Web はまるでダクトテープで作った車のように感じる https://publicsuffix.org/learn/
この投稿に付いた複数のリンクを見ると、実際には問題は2つある
1つ目は PSL を知っていれば比較的簡単だが、2つ目は（特にドメイン名にソフトウェア名が含まれている場合）さらに厄介だ
問題はユーザーコンテンツそのものではなく、Immich の release build を自分のサーバーに直接置いただけなのに、Google が自分のドメイン全体をブロックしたことだ
Immich が実際にユーザーコンテンツをホスティングしていたからではなく、PR preview 用サブドメインでこの問題が起きた
これは明らかに Google 側のコードの問題だと思う
Immich チームの「Cursed Knowledge」リスト全体を一度見るのを勧める https://immich.app/cursed-knowledge
リストにある内容の一部は、むしろ当然のセキュリティ設計にも見える
たとえば「一部の携帯電話では、位置情報権限のないアプリが画像を読むと GPS 情報を自動で削除する」
むしろ自然で望ましい動作に思える
こういう種類のノウハウを
CURSED.mdのような標準ファイルとして各プロジェクトで共有できるとよい現場で得られたさまざまな知識をみんなが学べるようになる
「Postgres のクエリパラメータは 65,000 個が上限」
その数でも足りないという点が面白い
こういう警告文でいつも気になる点がある
かなり直接的に「詐欺師」「攻撃者」というレッテルを貼っているように見えるが、これは名誉毀損にならないのだろうか
Microsoft の未確認実行ファイルの警告も同じだ
昔は「安全かどうか分かりません」という言い方だったのに、最近は「あなたは攻撃者です」と断定するような表示に見える
「詐欺師」という単語は実際の警告文には使われておらず、「攻撃者がサイトにいる可能性がある」「〜かもしれない(might)」という表現になっている
これには第三者のハッカー侵入事例も含まれる
サイト所有者を攻撃者だと名指ししているわけではない
法務チームが文言をかなり慎重に検討したはずだ
私は弁護士ではないが、こうした警告文で法廷まで行った例はないのではと思う
名誉毀損に当たる可能性はありそうだ
これは本当に大きな問題ではないのかもしれないが、Immich のようなところに誰でも PR を送って preview タグさえ付けば、その内容が必ず https://pr-<num>.preview.internal.immich.cloud でホスティングされる仕組みなのか気になる
結局、誰でも何でも自由に載せられることにならないか？
GitHub ではラベルを追加できる人がコラボレーターに制限されているので、完全にオープンではない
それでも、もしコラボレーターがまともな PR を先に送ってラベル獲得後は何でも載せられるなら、リスク要因はある
本当にコストのかからないフィッシング手法のアイデアみたいだ
1社がどのサイトにアクセスできるかまで左右しているなんて信じがたい
アプリ実行を制限するだけでは飽き足らず、今やこのレベルだ
米国議会が長年にわたって非効率に運営されてきた影響が、さまざまな問題につながっている
広告が嫌いなユーザーまで、どうしてこんな大企業を「クール」だと思うように仕向けられたのか不思議だ
広告は誰も望んでいないが、企業にとっては収益手段だ
Google がこうした非倫理的な企業イメージを逆に「かっこいい」ものとして包装しているのが理解できない
オープンインターネットは終わったのだと思う
今やすべてを独占企業が支配している
私は 3 年間 iOS アプリをストアに置いていたが、突然 Apple が存在もしない新しいライセンスを要求し、それがなければアプリを下ろすと通告してきた
3年間何も変わっていないのにこういうことが起きる
今ではセルフホスティングすら好きにできないレベルになってきて、だんだん嫌気が差している
私の友人であり顧客でもある人が、WordPress 系のホスティングと単純なリダイレクトを使っていた
そのホストがいつの間にか「危険なサイト」のブラックリストに載ってしまった
リダイレクトを外した後も自分のドメインまで汚染されたままで、そのせいで Google はそのドメインからのメールすら一切受け取らなくなった
審査リクエストでブラックリストからは外れたが、メール遮断の効果は恒久的に残った
結局新しいドメインを登録したが、こうした Google の振る舞いは、むしろ使い捨てアカウントを作り続ける動機にしかならない
私も 25 年間問題なく使ってきた自分のドメインが誤ってブラックリスト入りし、そのせいでメールまで止められることを想像すると本当に恐ろしい
私の結論としては、用途ごとにドメインを分けて使うのがよいということだ
世界的には複数の TLD が公式サービスっぽく見えてしまう欠点もあるが、今回の件でますますそう確信した
例としては
www.contoso.com（公開用）
www.contoso.blog（公開、ユーザーコメントあり）
contoso.net（内部用）
staging.contoso.dev（開発/ゼロトラストエンドポイント）
raging-lemur-a012afb4.contoso.build（スナップショット用） のように使える
ただ、こうしてドメインを分けると、ユーザー目線ではフィッシングに見える危険がずっと高くなる
以前
githubnext.comからメールを受け取ったが、私は GitHub =github.comだと認識しているので、当然フィッシングかスパムだと思った後で本物のサービスだと分かった
良いアプローチだ
私も今まさに自分のドメインで同じ問題に直面している
Google がうちの家族用 Immich インスタンスを危険なサイトだと判定して、同じドメインで提供していた他のすべてのサービスも Chrome からアクセスできなくなった
警告を回避すること自体はできるが、義母に送った写真アルバムがまったく使えなくなってしまった
私も今年初めに Umami Analytics をセルフホストしたとき、まったく同じ経験をした
https://news.ycombinator.com/item?id=42779544#42783321
Google Search Console に抗議する際に「法的措置」に言及したら、そこでようやくフラグが外れた
私も同じ問題に何年も悩まされている
https://news.ycombinator.com/item?id=45678095