mixi魚拓を作るメカニズム
自分で作る時間は無さそうなので、この記事が合っていた場合（後述するが法的問題が絡んでくるので100%の自信がない、間違っていたらツッコミ希望）ご自由に作って頂いて構いません。ていうか作っていただければ「おおおー」と思います(？)。
mixi上の日記が、本当に公開されていたことを証明する。即ち、いわゆる炎上時に記事削除や公開範囲変更、アカウント削除で「逃れる」ことを防ぐ。と、いうメカニズムの提案。
「教えて君.net」の記事で書いたんだけど
「この記事はいずれ削除/変更されるに違いない」と思ったら、まずIE/Firefoxツールバーとして公開されている「存在証明サービス」ツールを使ってウェブページを保存する。しかし、このままでは、後から保存データを提示し「このページを公開していただろ！」と問い詰めても、「そんなページは公開していない/（記事ページを保存した）お前が勝手に改ざんしたんだろ？」と言い逃れされてしまう。「Webページの存在証明」が凄いのは、ウェブページの保存と同時にタイムスタンプを生成している点。後で検証用ツールを使うと、そのタイムスタンプが正しいか、ウェブページデータが保存後に改ざんされていないかをチェックすることができる。タイムスタンプが正しく、改ざんの痕跡がなければ、そのページデータは間違いなく当該日時に当該URLで公開されていたものだ。記事の削除/変更で「なかったこと」にされるのを防ぐことができるぞ。
この方法論（だけ）では、mixiの存在証明を生成することはできない。実際、この「Webページの存在証明」は、mixiなどの会員制サイトには対応していない。
ちょっと基本的な部分というか前提から話を始めるので、ある程度知識がある人は次のhrまで飛ばして下さい。
ウェブページの存在証明（キャッシュ/魚拓）を生成するには、二つの方法論がある。
- 一般ユーザーの自分自身のマシンにデータ取得を行わせる
- 信頼できるマシン（例えば「Webページの存在証明」サーバー）にデータ取得を行わせる
mixiなど会員制サイトのキャッシュを取る場合に関して言うと
- mixiユーザーであるユーザー自身にデータ取得を行わせる
- サーバー側でmixiアカウントを持っておいて、そのユーザーにデータ取得を行わせる
の、二択な訳だ。そして、これらは両方共に問題を持っている。
まず、分かりやすいのが後者。
先にはっきり言っておくと、mixiの会員規約はあくまでmixiの会員規約であり、それを破ることは「mixiから見た悪」でしかない。これは、まぁ、例えばMMOにおけるRMTのポジションを考えればいい。運営側がそれを禁止したところで、それは例えば「アカウント削除しますよ」の意味でしかない（従って、この記事で書くメカニズムは「mixiの会員規約に反しない」を命題とはしない）。しかし、「mixi日記を取得する」という場合は、少しまずい。不正アクセスになる可能性があるからだ。
mixiの日記、例えば僕の日記は、全てのmixiユーザーに公開されている。しかし、非mixiユーザーには公開されていない。非mixi ユーザーが「僕の日記」の取得を、サーバーなど第三者経由で行った場合、それは「自分が閲覧する権限のないウェブページの取得」となる。この法的解釈は結構微妙だし争えば勝てるかもしれないが、少なくとも、争う覚悟が必要になる。
次に、前者。
これは即ち「ブラウザで今表示しているデータをそのまま保存する」ということなんだけど、これでは「そのページが本当に当該URLとして公開されている」ということを証明できない。例えば「hostsファイル」というキーワードで理解してくれれば話が早いんだけど、ブラウザを騙す、即ち、本来のウェブページと異なるウェブページを「そのURLのページ」とブラウザに思いこませることは可能なんだ。そのようにしてブラウザを騙せば、例えば他人のmixi日記を偽造し、それを「当該URLにおいて公開されていたmixi日記である」と偽ることができてしまう。故に、この方法では「保証」を行うことができない。
と、いうことで、つまり会員制サイト内ウェブページの存在証明には
- 一般ユーザーの自分自身のマシンにデータ取得を行わせる
- 信頼できるマシン（例えば「Webページの存在証明」サーバー）にデータ取得を行わせる
の、二つの方法論がある訳だ。それぞれ単体では問題があるが、これを組み合わせれば、話は変わってくる。以下の動作だ。
- 上記「Webページの存在証明」のようにローカルアプリケーションを用い、「今ユーザーが表示しているウェブページ」を取得する
- 同時にサーバーに対してリクエストを行う。サーバーは、リクエストを受けて、作っておいたmixiアカウントで当該URL（mixi日記）の取得を行う
- ユーザーのローカルアプリケーションは、1で取得されたデータをサーバーに対して送信する
- サーバーは、送信されたデータと、2で取得したデータとの同一性をチェックする
- 同一であれば「当該時刻に当該URLで公開されていたデータ」として存在証明発行を行う。上記「Webページの存在証明」と同様にページデータをタイムスタンプ付きでクライアントに渡す
この方法であれば、上記の二つの問題点を解決することができる。ブラウザを騙して偽mixi日記の存在証明を行おうとしても、そのデータはサーバーが取得したデータと同一でないため弾かれるし、非mixiユーザーは存在証明発行を行うことができなくなる。非mixiユーザーが（例えば第三者から受け取ったデータなどを使って）存在証明発行を行う可能性があるとしても、その責任をサービス提供側からユーザー側に投げることができる。あと、Proxomitronを使った広告削除などを行っていると、「同一」でなくなるために存在証明発行ができなくなる訳だけど、それは「Proxomitron切れよ」という話だ。
……という提案なんですが、間違ってたらツッコミ宜しくお願いいたします。
TrackBack
この記事へのトラックバック