2013年12月31日

米国の諜報活動(米軍・NSA・CIAなどの通信監視計画「PRISM」を例に)

PRISM_logo_(PNG).png アクセス解析のページの解説と目的(下記URL)にも書きましたが、私のサイト・ブログでは、ご訪問者の関心を知るために、アクセス解析をしています。

 それに加えて、ご訪問者が他のご訪問者の閲覧行動を参考にすることで目的のコンテンツを探しやすくなるように、最近データをまとめて掲載しました。(先日の以下の記事をご参照。)

当サイト・ブログのアクセス解析の方法
http://iwasaki-j-ict.sblo.jp/article/83133482.html

 驚かれた方もいらっしゃるかと思いますが、しばしば「岩崎さんのサイトは広大すぎて、あの話題がどこにあるか分からなくなった」というお問い合わせを頂くので、このようにしました。

http://iwasakijunichi.net/analysis/

 さて、以下は専門的・技術的な話です。

 解析データ取得方法にも書きましたが、2013年の途中(8・9月あたり)からGoogleがGoogle検索における全ての通信をSSL化(暗号化)しました。非常に分かりやすく言うと、普通にGoogle検索してみると、検索結果のURLの冒頭が「http」ではなく「https」となってしまうのがほぼそれに当たります。

 これがアクセス解析をするサイト運営者側にとっては何を意味するかというと、Google検索を使って訪れた訪問者の検索クエリ(情報要求としての検索キーワード)が取得できないケースが増えるということです。
(それは、Googleの解析技術Google Analyticsが取得している検索クエリのほとんどがYahoo!、Excite、gooなどの他の検索エンジンからのそれらであり、Google自身のSSL化された検索サービスであるGoogle検索からの検索クエリは、ほとんどが「not provided=取得不能」として処理されることを意味します。)

Google検索のSSL化を解説している他のサイト
http://www.sem-r.com/google-2010/20130924052529.html
http://www.roundup-strategy.jp/mt/archives/2013/10/google-not-provided-100.html

 現在では、もはやhttp://www.google.co.jp/にさえアクセスできず、このURLを打ち込むとhttps://www.google.co.jp/に強制的にリダイレクトされます。SSL検索の適用は、IEよりもFirefoxや本家本元のChromeのほうが早かったですが、今ではブラウザは何を使おうが無関係です。

 しかも、Googleアカウントにログインしているかいないかも関係なくなっているため、呑気に「ググる」という造語まで造ってググっている日本の若者たちも、知らずにSSL検索をしているわけです。(SSL検索化には後述するような裏がある。)

 しかし、これだけなら、私のような(サイトビジネスなんて考えていない個人の)サイト運営者にはダメージが小さいと言えます。元より、日本ではYahoo!検索の利用者数のほうがGoogle検索の利用者数をかろうじて上回っていますし、私のサイトへの到達の際のトップ検索キーワードである「共感覚」や「アスペルガー」、「解離性障害」、「直観像記憶」などといったキーワードは、多くがYahoo!から検索されたものでしょう。

 一般の主婦の方々などは、Yahoo!ニュースを見ているついでに、「共感覚」や「アスペルガー」などの聞き慣れないキーワードをふと検索したら、岩崎純一という人のサイトに行き着いた、というようなルートを辿っていらっしゃるかと思います。

 Google検索は、上記のような単語を検索するだけなら使いやすいですが、Google検索やGoogle Analyticsの利用者には元より技術者も多いですし、あんな超高機能の検索や解析技術は、元来自分でサイトソースを記述したりプログラムを組んだりしているくらいの人でないと使いこなせないと思います。

 Google検索の全SSL化に対してできることと言えば、かなり少なくなっており、あとはサイト管理者の技術の問題になってきます。私のサイトはPHP、Perl、JavaScriptなどを組み合わせてアクセス情報を取得していますが、それでも、Google検索で打ち込まれた検索キーワードのほとんどは、ものの見事に隠されていて取得できません。かろうじて、以下の私のページにGoogle検索によるURLの一部が記録され、そこからキーワードが確認できる程度です。

http://iwasakijunichi.net/ranking/rank.html

 以下のGoogleの公式声明でも、「Google 検索結果ページから別のウェブサイトにアクセスすると、そのウェブサイトでは、どこからそのサイトにアクセスしたか、および使用した検索キーワードを特定できる可能性」があることが示されていますが、Googleはこのような手法でのクエリ取得も今後は防御していくものと思われます。

https://support.google.com/websearch/answer/173733?hl=ja

 興味深いのは、Googleが黙って勝手にSSL検索化を推し進めたことであり、かつこれがアメリカ政府当局、とりわけNSAやCIAによる諜報活動の一環であることが判明したことです。Googleも、あとでしぶしぶその活動の一端を認めています。

PRISM_Collection_Details.jpg SSL化は、セキュリティーの向上とプライバシーの保護だけが目的ではなく、特にアメリカ国家安全保障局(NSA)やCIAによるPRISM計画(世界中のユーザーの電子メール・文書・SNSの内容・顔写真・その他電話などの通信内容についての監視・傍受・情報収集計画)と関係があるようです。

PRISM (監視プログラム)
http://ja.wikipedia.org/wiki/PRISM_%28%E7%9B%A3%E8%A6%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%29

 エドワード・スノーデン氏が最初にこれらの一端を暴露したのが今年の3月ですから、ちょうどGoogleにとっては、SSL検索化をPRISM対策の口実とするよいタイミングだったと思われます。

 しかし、本当はPRISM計画がスノーデン氏や英ガーディアン紙やワシントンポスト紙によって暴露されたことで一番焦ったのは、Googleだと思います。現在、PRISM計画に協力していることが判明している企業は、Microsoft、Apple、Yahoo!、Facebook、AOL、Skypeなどで、そして、まさにGoogleこそその代表格であり、Google傘下のYouTubeも協力しています。

 Google検索のSSL化は、NSAやCIAが仕掛けてくるクラッキングや傍受に対してセキュリティーを向上させ検索ユーザーの個人情報を保護することではなく、逆にNSAの情報監視計画に本格的に参画するための足掛かりなのだろうと見受けられます。NSAやCIAなどの政府当局とGoogleなどの企業がタッグを組んで、スノーデン氏のような(彼らにとっては)裏切り者の息の根を止めるために、暗号化技術を逆手に取ったということもあると思います。

 結局のところ、SSL検索化によっては、我々一般利用者の目に他の一般利用者の情報が隠されるということに過ぎません。アメリカ政府やNSAと、それらに対して表向きは反発しているGoogleなどだけは、世界中の恋人や夫婦たちのメールやSNSでの会話を盗み見できるというわけです。いやはや、便利なものですね。日本にはそんな技術はないと思います・・・。

 私は、SNSと言えば今でもmixiやTwitterを使っていますが、それは技術力が適度に低い(技術力の結集が甘くて、アメリカ政府やGoogleレベルから優先的に傍受の対象とされない)からであり、一方でGoogle+やFacebookに何でもかんでも載せている人は、まず間違いなくアメリカやGoogleに思いっきりプライベート情報を抜かれていると思っておいたほうがよいと思います。日本人であっても同じことです。

 最近では、アメリカ政府やNSA、CIAが他国政府の通信を傍受していることも、普通にニュースで報道されるようになっています。日本の米軍基地関連の問題にしても、相手にしていても埒が明かない日本政府を通さずに、直接に沖縄県民や日本国民の電子メールやSNSの内容を傍受して世論の動向を知り、どこに基地を移設すれば最も世論の反発が小さいかを見極めたり、時には世論を操作・扇動するほうが手っ取り早いとアメリカに思われても、仕方がないと思います。

 尖閣漁船事件の映像も、その真相が、政府筋から漏れずに、海上保安官の個人的な行動によって漏れたのですから、どこに潜んでいるか分からない他国の国家機密情報を探るために、セキュリティー意識があまりない日本のSNSユーザーの個人情報や通信内容、検索クエリ、所持画像、所持映像などを探ることでその国の真相を知ろうとすることは、軍事的にも一つの常識なのかもしれません。もちろん、アメリカ政府やNSAやCIAやGoogleだけが持っている、Google Analyticsをはるかに超えた解析技術や高度なクラッキング・傍受技術によって行われていると思いますが。

 SSL検索化の表向きの口実の一つに「Search plus Your World」がありますが、本当に表向きで、実際には、Google+を利用して公開・共有された個人情報はSSL検索化に伴って、どんどんパーソナライズされています。

 一見すると論理矛盾ですが、パーソナライズ検索が可能になるのは、Googleが少なくとも先進国のSNSユーザーやGoogleのSSL検索ユーザーといった末端の個人のプライバシー情報を徹底的に取得しているからで、実際、個人的にGoogleから追われているとしか思えないようなパーソナライズ検索結果を、多くのGoogle+ユーザーに対して出すことが可能になっています。

http://cloud.watch.impress.co.jp/docs/column/infostand/20120116_504861.html

 mixiについては、(簡単にクラッキングできるので、クラッキングする楽しみがないという意味で)「PRISM計画からもGoogleからも相手にされない、お遊び程度のSNSだ」という発言が、欧米のクラッカーや技術者たちの間で見られますが、Facebookは、それ以上の技術で作られているからこそ、危ないと思います。Facebook上の個人情報はNSAやCIA、はたまたGoogleが監視しており、自由に利用できる状態にあるでしょうし、そのために規約も書き変えられ続けていることに、多くのユーザーが気づいていないと思います。

 アメリカやGoogleがやろうとしている情報監視・操作は、日本の特定秘密保護法のような法整備で対応できるようなものではないと思います。


【画像出典】

PRISM (監視プログラム)
http://ja.wikipedia.org/wiki/PRISM_%28%E7%9B%A3%E8%A6%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%29

2013年12月26日

当サイト・ブログのアクセス解析の方法

アクセス解析データ例1 つい先日、当サイト・ブログのアクセス解析データ書庫を公開しました。

http://iwasaki-j.sblo.jp/article/83132560.html(メインブログでの報告)
http://iwasakijunichi.net/analysis/(アクセス解析データ書庫)

 アクセス解析の結果は上記ページをご覧いただくとして、以下に技術的なこと、解析方法についてメモしておきます。

アクセス解析データ例2◆解析エンジン
 Google Analytics:http://www.google.co.jp/intl/ja/analytics/
 Webalizer:http://www.webalizer.org/
 Google APIなどを用いた独自エンジン
 その他、表示用の解析エンジンなど・・・詳しくは「サイト制作環境等」(http://www.iwasaki-j.sakura.ne.jp/seisaku.html)をご参照。
 ↓ ↓ ↓
◆設置
 Google AnalyticsのトラッキングコードをPHPで全ページにインクルード。Webalizerをサーバーにインストール。
 さらに、それらをPHPプログラムで一括管理。
 ↓ ↓ ↓
◆主な解析結果の取得
 ファイル・ページビュー数、訪問者数、デバイス・OS・ブラウザ情報などを取得。
 ↓ ↓ ↓
◆解析フィルタ1
 検索クエリについて、SSL検索を原因とするGoogle Analyticsの(not provided)を除外。
(2013年以降のGoogleによるGoogle検索における全ての通信のSSL化に伴う。)
 ↓ ↓ ↓
◆解析フィルタ2
 同一IPからの同一の検索クエリによる2回目以降の訪問をカウントから除外。
 ↓ ↓ ↓
◆検索エンジン、サイトのサーバー、表計算ソフトの同期
 ExcelのWebクエリを検索クエリデータベースに同期。
 ↓ ↓ ↓
◆不適切なクエリの監視
 一部の暴力的・反社会的・成人向けまたは名誉棄損に該当するキーワードを含むクエリを除外。
(それらを学術的に調査する目的で検索した可能性もありますし、検索するだけなら当然犯罪ではありませんので、表現が過度のもの以外は除外していません。)
 ↓ ↓ ↓
◆公開
 月ごとに同期を停止。静的PDF化。
posted by 岩崎純一 at 11:34| Comment(0) | TrackBack(0) | アクセス解析

2013年12月02日

HTMLファイルのままで共通部分(メニュー・プラグイン)などをPHPで引き込む方法

【2015年2月17日追記】
 今回の記事で「HTML」・「.html」と書いてあるところは、それぞれ「XHTML」・「.xhtml」と読み替えてもほぼ通用します。私のサイトはほぼXHTMLで書いてありますが、汎用性を高めるため、HTMLを基準に執筆しました。


【以下、本文】

 私のサイトには、各ページに共通の部分が色々とあります。(ヘッダ、メニューバー、フッタなど。)

 今では世の中のサイト・ブログのほとんどがそういう共通部分を持っていると思います。一番困るのが、ページ数が多いサイトでその共通部分に変更点が出てきた時でしょう。

 今さらフレームページを使う人は少ないでしょうし(検索から訪れた閲覧者がトップページに辿り着けないことすらありますし、SEO上も圧倒的に不利)、そうかと言って共通部分を一ページずつ手作業で修正したところで、すぐに日が暮れます。そこで、共通部分だけを別に取り出しておき、その一つのファイルだけを更新することで全ファイルにそれを反映できるような方法があれば、それに越したことはないわけです。

 それには、SSI(Server Side Include)のincludeを使う手もありますが、Perl・CGIと併用するなどしてHTMLとして吐き出すようになっている場合、XSS(クロスサイトスクリプティング)の攻撃に遭うおそれがあり、あまり推奨できない方法かと思います。

 JavaScriptでも可能ですが、クライアントサイド・スクリプトなので、閲覧者にブラウザの設定を要求することになります。もっとも、JavaScriptをオフにしてネットを見ている人は、今やほとんどいないと思いますが。

 既存のWikiエンジンを引っ張ってきて使う手もありますが、外観はどうしてもサイトでもブログでもない、それこそWikipediaのようなものになってしまいます。

 そこで、PHPでincludeして共通部分を表示させる方法を考えるわけですが、それだけだと、ファイルの拡張子を.htmlではなく.phpとしなければなりません。

 しかし、拡張子を.htmlとしたままでPHPを記述できる(拡張子が.phpや.htmlのファイルを拡張子が.htmlのファイルにPHPで引き込める)方法があります。

 私のサイトでの方法を簡単に紹介します。(詳しく知りたい方はご連絡下さい。または、他にも似たような方法を解説しているサイトがありますので、検索してみるとよいと思います。)

 上から順に進んでいって下さい。


●共通部分を除いた各ファイル(共通部分を引き込む側のページ)「A1、A2、A3・・・An」と、共通部分の各ファイル「B1、B2、B3・・・Bn」を用意する。

 拡張子は、テキストデータ(.txt)としても動く場合があるが、.phpか.htmlがよい。Bxの各ページには、html・meta・head・bodyなどのタグは不要で、Axに挿入したいタグ・文字列をそのまま書く。CSS(スタイルシート)の記述をidなどで引き込む場合も、そのまま書く。

 完成したAxとBxを適宜サーバーにアップロードする。(標準のFTPソフトなどによるアップロードでよい。)


●Axの各ページにおける共通部分の挿入(表示)部分に以下を記述する。ただし、Bxを一つ下のディレクトリにdirBアップロードした場合は「dirB/Bx.php」とするなど、適宜修正すること。

<?php include("Bx.phpまたはBx.html"); ?>
※ 両端の全角のところ(カッコとハテナ)は全て半角に修正して下さい。


●【この項目の作業は、PHPがCGIとして動く「さくらインターネット」のようなサーバーでのみ必要。】
 SSHが使えるターミナルエミュレータなどでサーバーにログイン。PHPのCGIファイルのある階層を確認し、Axをアップロードした(つまり、PHPファイルを動かしたい)ホームディレクトリやサブディレクトリにコピーし、「php.cgi」にリネームする。
(現在では、「さくらインターネット」でもコピー不要の場合が多い。)


●以下を記述したphp.cgiファイルを作成する。「さくらインターネット」でも、最近は先ほどのCGIのコピーではなく、以下のphp.cgiの作成だけで足りる場合が多い。Axをアップロードしたディレクトリにアップロードし、パーミッションを705か755にしておく。

#!/bin/sh
exec /usr/local/bin/★
(★:CGIとして動くPHPのファイル名を記述。)


●.htaccessファイルを作成する。以下のように記述し、最後に改行を加え、Axをアップロードしたディレクトリにアップロードする。

DirectoryIndex index.html index.htm index.php .ht
Action myphp-script /php.cgi
AddHandler myphp-script .php .html
最後に必ず改行を加える


●Axの各ページをブラウザで表示させ、動作を確認。


●上記.htaccessファイルを設置したことで、そのディレクトリの配下のサブディレクトリ内のページが表示できず、500errorなどを返すようになった場合、上記と同じ.htaccessファイルを作成し、表示ができなくなったサブディレクトリにアップロードする。先述のPHPのCGIファイルのコピーが必要なサーバーでは、これらのサブディレクトリにも同様にコピーする。これで、再び表示できるようになる。


 以上です。サーバー側でPHPでの処理がなされ、HTMLとして吐き出されるので、PHPのincludeの記述がソースに現れることはありません。静的HTMLの一部の記述だけでなく、色々なスクリプトやプラグインを引き込むことができます。

 メンテナンスとしては、PHPのバージョンを変えていく必要があります。使っているサーバーが対応しているPHPのバージョンを確認することが最優先ですが、なるべく新しく、かつ安定しているバージョンを使いましょう。

 .htaccessの設置ディレクトリ配下にある全てのサブディレクトリは、その設定の影響を受けるので、サブディレクトリ内に書き込み可能なスクリプト(Perl・CGI使用の掲示板やメールフォーム)があると、それらの書き込み内容が実行されます。閲覧者がXSS(クロスサイトスクリプティング)の憂き目に遭うこともありますので、.htaccessの設置やCGIのパーミッション変更にも十分注意しましょう。