2009年2月10日(火曜日)

森の生活 82日目: 化石コンプリート

公開: 2009年2月14日1時0分頃

街へいこうよどうぶつの森 (www.amazon.co.jp)、82日目。

化石「アンキロのしっぽ」が出て……。

ついに化石コンプリートしました!

今後は化石は売るだけなので、ちょっと寂しい?

「森の生活 82日目: 化石コンプリート」にコメントを書く

Google謎の謝罪

公開: 2024年4月25日20時40分頃

こんなのが出ていますね: 「Google Japan Blog: Google のマーケティング活動について (googlejapan.blogspot.com)」。

Google Japan では、製品を多くのユーザーに知ってもらうために、さまざまなプロモーション活動を実施しています。
今回、そのプロモーション活動の一部でブログを活用したことが、Google のサーチに関するガイドラインに違反することが判明し、このプロモーションに関しては中止しました。ご迷惑をかけた関係者各位とユーザーの皆さまにお詫びするとともに、再発防止に向けて、透明性の高いコミュニケーションに努めてまいります。

これだけ読んでも何が何に違反したのかさっぱり分からないわけで、コミュニケーションがあまりにも不透明だと思いますが……。

幸いにして、CNETに詳しい話が出ていますね。

グーグル、プロモーションで謝罪--抵触したサーチガイドラインとは (japan.cnet.com)

要はこういう事のようで。

Googleがブロガーにお金を払って記事を書いてもらっていた
しかしGoogleの検索ガイドラインでは、そのような行為はペナルティ対象とされている

別に法的にまずいことをしたわけでもないのですし、ちゃんとペナルティを課せば良いだけでしょう。GoogleのサイトがGoogle検索の結果に一切出ないようになれば、それでOKかと。

「Google謎の謝罪」へのコメント (2件)

IPAを騙る標的型攻撃の分析

公開: 2024年4月25日17時5分頃

「ソーシャル・エンジニアリングを巧みに利用した攻撃の分析と対策－脆弱性を狙った脅威の分析と対策について－ (www.ipa.go.jp)」。

IPAの名を騙るメールが届き、添付されているPDFを開くとAdobe Readerの脆弱性を突いた攻撃が発動、バックドアが作動……というシナリオのようで。なかなか興味深いです。HTTP Proxyに関する話も興味深いところですね。

しかし、本マルウェアは、感染したコンピューターのインターネット接続設定を確認し、HTTP Proxy サーバーが利用されていた場合、それを利用してインターネット上に存在する攻撃者用制御サーバーと通信する機能を備えています。そのため、HTTP Proxy サーバーを導入するだけでは、本マルウェアによる脅威を低減することは困難です。
(～中略～)
認証付きのHTTP Proxy サーバーを導入することで、本マルウェアとインターネット上に存在する攻撃者用制御サーバーの通信を防止することが可能です。
(～中略～)
しかし、技術的には、認証付きHTTP Proxy による対策を回避することも可能なため過信は禁物です。

基本的には、Adobe Readerをきちんとアップデートしていれば喰らわずに済む話ではあるのですが。

※MS製品ならMicrosoft Update一発でおおむね安心なのですが、それ以外をちゃんとアップデートできているかと言われると、なかなか自信を持って答えられないですね。JREとかFlash PlayerとかQuick Timeとかいろいろありますし、それらが全てのマシンでちゃんとアップデートできているのかと問われると……。

「IPAを騙る標的型攻撃の分析」にコメントを書く

脆弱性を見つけるのは法的に黒っぽい?

公開: 2024年4月25日18時30分頃

「セキュリティ&プログラミングキャンプキャラバン2008　レポート (blog.s21g.com)」。

脆弱性を見つけるのは法的に黒っぽいですが、みなさん、どうしてるんですか？

ふぇー。黒っぽいですか。情報セキュリティ早期警戒パートナーシップガイドラインの付録には「不正アクセス禁止法に抵触しないと推察される行為の例」というのが出ていたりしますが、園田さんの「早期警戒パートナーシップ」という発言はその話ですかね。ちなみにこんな感じです。

1) ウェブアプリケーションの利用権者が、正規の手順でログインするなどして通常のアクセスをした際に、ブラウザとサーバとの通信の内容を観察したところ、それだけで脆弱性の存在を推定できた場合。
2) ウェブページのデータ入力欄にHTML のタグを含む文字列を入力したところ、入力した文字列がそのまま表示された。この段階ではアクセス制御
機能の制限を回避するに至らなかったが、悪意ある者に別の文字列を入力されれば、このサイトにセキュリティ上の問題が引き起こされかねないと予想できた場合。
3) アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察されるURL 中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。（ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。

以上、情報セキュリティ早期警戒パートナーシップガイドラインより

まあ、抵触しないと推察されるというだけなので、グレーですけれども。ここに書かれているのはあくまで一例で、基本的には、

Webサイトの運営者や利用者に迷惑をかけないこと
不正アクセス禁止法の構成要件を満たさないようにすること

という2点に注意すれば良いのかなと思っています。後者はけっこう難しいですが。

脆弱性みつかったお！ → 仕様です

すぐ仕様と言ってくるならまだ良いのですが、「脆弱性みつかったお→修正しました→なおってないお→修正しました→なおってないお→仕様です」とか対応されると、修正を諦めて仕様と言い張ることにしたとしか見えなかったりしますよね……。

「脆弱性を見つけるのは法的に黒っぽい?」にコメントを書く