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

Google セーフブラウジングのインシデント

2025年10月10日原文(statichost.eu)

概要

  • 2025年9月25日、約6時間にわたり statichost.euドメイン全体 がGoogle Safe Searchで 危険サイト扱い
  • 利用者は 警告表示やアクセスブロック を受け、カスタムドメインにも影響。
  • 原因はフィッシングサイトの増加 によるGoogleの自動検出。
  • サイト運営者は 迅速に対応し、数時間でブロック解除
  • Googleの 影響力と監視体制の問題点 についての考察。

statichost.euがGoogle Safe Searchで危険サイト扱いされたインシデント

  • 2025年9月25日、 statichost.eu全体がGoogle Safe Searchによって「詐欺サイト」認定
  • 約6時間にわたり、 Google Safe Search利用者はstatichost.euへのアクセスが警告またはブロック
  • 一部のカスタムドメイン も影響を受け、正常なサービス提供が困難な状況。
  • Hacker Newsでも議論が発生 し、注目を集めた事例。

インシデント発生から対応までの流れ

  • 月曜日の朝、 複数ユーザーから「セキュリティ警告でアクセス不可」と報告
  • 自身でstatichost.euにアクセス、 TLSや技術的問題は未検出
  • 問題の共通点が「Google」 であることに気付き、Chromiumで検証。
  • Google検索でstatichost.euが検索結果から消失、異常を認識。
  • Google Search Consoleで「セキュリティ問題」の巨大エラーメッセージ を確認。
  • 週末に発生したフィッシングサイトが原因 で、statichost.eu全体がブラックリスト入り。
  • Googleから問題サイトのリスト提供 を受け、速やかに該当サイトを削除。
  • Googleへのレビュー申請 を実施し、数時間後に自動的にブロック解除。
  • 解除通知はSearch Console内のみ、メール連絡等は一切なし。

Google Safe Browsingの仕組みと影響力

  • Google Safe Browsingの目的は 「世界中の情報を安全にアクセス可能にする」 こと。
  • 実態は Googleが不適切と判断したサイトの巨大なブラックリスト
  • このリストは 主要ブラウザや多くのサービスで利用 されており、 「50億台以上」の端末に影響
  • Google ChromeはデフォルトでアクセスURLをGoogleへ送信
    • 「高度な保護」設定ではページ内容も一部送信、大規模な監視体制。
  • 多くのブラックリスト入りサイトは確かに危険 だが、 誤検知(false positive)も存在
  • 全てのフィッシングサイトを網羅できていない現実

Googleの支配力・監視体制への懸念

  • Googleはインターネットの多くのやり取りを「コントロール/監視」
  • Googleの判断だけに依存する危険性
  • 友好的なブランドイメージや過去の実績に惑わされない警戒心 の重要性。
  • Googleに「誰を信じるか」を委ねず、自らの判断力・ネットリテラシーを重視

今後の対策と改善策

  • 今後はstatichost.euではなくstatichost.pageドメインで新サイト作成
    • Public Suffix Listへの追加申請中、さらなるセキュリティ強化を目指す。
  • 同様のインシデント発生時の影響範囲縮小 を図る運用体制。

まとめ

  • Google Safe Browsingの意義は認めつつも、その巨大な影響力と誤検知リスクは無視できない問題
  • サービス運営者はGoogle依存を減らし、複数の対策と独自判断力を持つことが重要
  • 利用者側も警告やブロック表示に盲目的に従わず、慎重な情報判断を心掛ける必要性

Hackerたちの意見

大手SNS企業じゃない限り、ユーザーコンテンツを受け入れるのはどんどんリスクが大きくなってる気がする。

もともとそうだったよ。アップロード一回とISPやGoogle、AWS、MSへのクレームがあれば、アカウントが停止される可能性があるからね。

ユーザーコンテンツを別のドメインに置いて、そのドメインをパブリックサフィックスリストに追加するのはいいアドバイスだよ。実際、インフラ提供者なら最初から知っておくべきことだと思う。ここには著者の無知から来る誤解が多いね。

もちろん、これは真実だよ!こういう事件が起きないと、なかなか気づかないもんだよね。 :)

その通り、これは何年も前から知られていることだし、数十年にもわたって文書化されてる。Githubや他の大手ユーザー生成コンテンツの提供者は、リスクやその軽減方法についての公開文書を持ってる。そういう実践を無視するホスティングプロバイダーは、自分たちと顧客を危険にさらしてるってことだね。

正直言って、私はこの分野に約20年いるけど、公共サフィックスリストのことを聞いたのは初めてだ。

ここには著者自身の無知から外れた多くの悪意がある。あなたが言いたいのは、著者の無知に向けられるべきだということだと思うけど、そうじゃなくてそれを引き起こした状況に向けられるべきだと思う。

何かが事実上の標準だと思うなら、公共サフィックスリストは今のところちょっと生煮えな感じがする。思いついた2つの人気の公共サフィックス、'livejournal.com'と'substack.com'をチェックしたけど、どちらも載ってなかった。もしかしたら私が間違ってるのかもしれないけど、バグじゃなくてこれらのサフィックスは含まれるべきじゃないのかもしれない。でも、その理由が思いつかないんだよね。

PSLって、問題が起きた後に初めて知るものだよね。正直言って、変なもので、ブラウザがサブドメインを違う扱いする基準にはどこにも載ってないGithubのリポジトリなんだ。こういう情報は、ホスティングを始めたからって急に頭に浮かぶわけじゃないし、存在を知らなかったら、こんなプロジェクトを探そうとも思わなかっただろうな。みんなが使えるオープンなもので、しかも現代のインターネット対応のコンピュータやマルウェア対策サービスに組み込まれてるなんて、全く予想外だった。

一般的には良いアドバイスだけど、今回のケースでSafe Browsingが何か悪いことをしたとは思えない。まず、実際にフィッシングサイトを一時的にホスティングしていたみたいだし:> statichost.euのすべてのサイトはSITE-NAME.statichost.euのドメインを持っていて、週末にはフィッシングサイトが急増してた。次に、彼らはパブリックサフィックスリスト(https://publicsuffix.org/)を使って、ドメイン全体がタグ付けされないようにすべきだった。サブドメインが異なるユーザーに属していることをGoogleがどうやって知るの?それがPSLの役割だから。私の読みでは、Safe Browsingはこのケースで正しく機能していて、脅威が取り除かれた後はすぐにサイトを復旧させたよ。

GoogleやSafe Browsingが特に何か悪いことをしたとは言ってないよ。私の言いたいことは、Googleがインターネットに対して持っている力が大きすぎるってこと。実際に起こったことは、私が悪者からの防御に十分な努力をしていなかったからだって分かってる。新しい別のドメインはPSLへの追加待ちだけどね。追記:上で言ってる「努力」は、コンテンツのリアルタイムモデレーションのことを指してるよ。

公共サフィックスリストに載るのは、言うほど簡単じゃないよね。[1] 彼らは気が向けば「ノー」と言えるし、「プロジェクト」としてその権利を維持しようとしてるから、ビジネスとは違うんだよね。[2] それには利点も欠点もあるけど。[1] https://github.com/publicsuffix/list/blob/main/public_suffix... [2] https://groups.google.com/g/publicsuffix-discuss/c/xJZHBlyqq...

Hacker Newsで議論の続きを見る