ついに最終回を迎えた本連載ですが、最後に最も重要ながらも、なかなか理解しにくい、パーミッションモデルについて解説します。
せっかく思いついた面白いガジェットのアイディアも、これによって実現可否が分かれてしまうことがあるくらい、重要です。この機会にしっかり理解してしまいましょう。
パーミッションモデルとは何を指すのか
SNSでパーミッションと言ってパッと思いつくものに、情報の公開範囲が挙げられるでしょう。例えばmixiの日記には「全体に公開」、「友達まで公開」、「友達の友達まで公開」、「グループを指定して公開」といった選択肢があります。この機能により、ユーザーは自分が書いた日記を誰が見ることができるか、決めることができます。他にも自分の本名や年齢、誕生日等についても、公開範囲を指定できるSNSは少なくありません。このようなSNSのネイティブ機能の場合、登場人物は「SNS（コンテナ）」「持ち主ユーザー（オーナー）」「相手ユーザー（ビューアー）」です。
図1 通常のSNSにおけるパーミッション関係
しかし、OpenSocialガジェットの場合、これらに加えて「ガジェットディベロッパー」が登場人物として加わってくることで、話が複雑になってきます。
コンテナとユーザーとディベロッパー
例えば、あなたが友達だけに見せるつもりで書いた日記が、ある日ネットの掲示板でさらされていたらどう思いますか？ 内容によってはとても困った状況に陥るかもしれません。何かSNSの機能に不具合があったか、友達の誰かが流すしかありえない、と思うでしょう。だって、日記を見れるのはコンテナか、友達のビューアーしかいないのですから。
そして、この話にディベロッパーが加わるとどうなるでしょう？
例えば、先ほど例に挙げたOpenSocialガジェットが、日記の情報にアクセスすることができたと仮定しましょう。その場合、ユーザーはあくまで他のユーザーに対しての日記の公開範囲を設定したに過ぎず、ガジェットがその設定を超えて日記の情報を取得できるとしたら、その段階でプライバシーとして保護されていない状況と言えるでしょう。
これまでの連載でお気づきと思いますが、ガジェットはJavaScriptとHTMLでできているとはいえ、ディベロッパーの実装次第では、取得した個人情報を外部サーバーに送信することは容易です。つまり、悪意のあるガジェットディベロッパーなら、SNSの持つあらゆる情報を盗み出し、プライバシーを蹂躙することができてしまうのです。
図2 OpenSocial対応SNSにおけるパーミッション関係
先ほどの例で言えば、ネットの掲示板にあなたの友達まで公開の日記がさらされている原因に、ガジェットディベロッパーが容疑者として加わることになります。
コンテナは個人情報の流出を2つの理由から防がなければなりません。ひとつはユーザーのプライバシーを守るというモラルのため。もうひとつは個人情報保護法を遵守するコンプライアンスのため。もちろん、ソーシャルグラフという重要な資産を守るという意味もあるかもしれません。
コンテナが打てる対策はいくつかあります。
- 信頼できるディベロッパーのみがガジェットを提供可能な仕組みを導入する
- 規約に同意することでユーザーにリスクを受け入れてもらう
- システム的な制約を設け、ディベロッパーが取得できる個人情報を限定する
gooホームで取られている対策は、これら3つすべてです。
ここですべて説明することは出来ませんので、システム的制約の部分に絞って話を進めます。
基本ルール
※以下で言う「個人情報」は、アクティビティやアプリデータを含む、あらゆるユーザーにまつわるデータを指します。
- 対象が同じガジェットをインストールしていること
ガジェットをインストールすることで、ユーザーがガジェットディベロッパーに個人情報の提供を同意したものと見なすことから、ガジェットをインストールしていれば、公開されている個人情報を取得することができる、というルールになっています。逆に言うと、ガジェットをインストールしていないユーザーの個人情報は、基本的に取得することができません。
- 友達なら基本情報を取得することができる
ガジェットをインストールしていないユーザーの個人情報は直接取得することはできませんが、ガジェットをインストールしている人の友達一覧としてなら、基本的な情報（gooホームの場合id, ニックネーム、プロフィール画像url、プロフィールurl）に限り、取得することができます。
- 更新・削除は対象がビューアーの場合のみ
ガジェットをインストールしているからと言って、他人の個人情報を変更できるのでは困ります。個人情報の更新や削除については対象がビューアーの場合、つまりガジェットを操作している人の場合のみ行うことができます。
ここで解説した基本ルールはgooホームのものですが、orkutでも同様のルールが適用されます。mixiアプリについてはまだ仕様が揺れている状態のようですが、おそらくは似たようなものになるでしょう。ただ、hi5のように誰の情報でも取得できるし、好きなように書き換えることができてしまう何でもアリな環境も存在したりしますので、一概にこれがOpenSocialのルールである、とは言い切れないことは覚えておいてください。
まとめ
今回は誌面の都合上、パーミッションモデルの基本的な部分のみについて解説しましたが、さらに掘り下げたいという方は、goo Developer's Kitchenの解説をご覧ください。
繰り返しになりますが、パーミッションモデルはOpenSocialにおいて、欠くことのできない要素です。正直な話、JavaScriptが書ければ OpenSocialガジェットを作ることはそれほど難しいものではありませんし、ガジェット全体からすればOpenSocial固有のAPIを利用する部分など、知れています。本当にOpenSocialガジェットや、ソーシャルウェブアプリケーションが書けるかどうかは、パーミッションモデルを理解しているかどうかである、とあえて断言します。
最後に
はてブチェッカーというガジェットとgooホームを題材に、これまで8回に渡りOpenSocialガジェットの実装方法を解説してきましたが、いかがでしたでしょうか？筆者としては、実は書き足りないことが山ほどあります。
もしOpenSocialに関して疑問や質問がありましたら、ぜひGoogle GroupsにあるOpenSocial Japanコミュニティに投稿してください。私や共著者の田中洋一郎を含め、OpenSocial好きが集まっているコミュニティですので、きっと誰かが回答してくれるはずです。
また、OpenSocial Japanコミュニティを中心に、月一回程度OpenSocial Hackathonという勉強会が開かれています。Hackathonはその場で実装を行うことを通じ、実践的にAPIを学んで行こうという試みです。次回はgoo、mixiの共同開催を計画しています。ぜひ一度ご参加ください。
それでは、ご愛読ありがとうございました。
