ソーシャルソフトウェアは「分人」をサポートするか?

私とは何か 「個人」から「分人」へから続く。

4798115819仮に「分人」という考え方がいいと思っても、それをテクノロジーでサポートしようとすると、いろいろ難しい問題を具体的に解決しなければならなくなります。Joel Spolsky編『BEST SOFTWARE WRITING』(翔泳社, 2008)から、そのような話題を2つ紹介しましょう。(参考文献リストなし。索引あり。)

1. サポートすることはできない思わせる話(ダナ・ボイドの2004年6月の講演「自閉的ソーシャルソフトウェア」から)

知ってのとおり、インターネットは社会的なアイデンティティがもはや問題とならない世界という幻想を満たしてはいなかった。「チューリングゲーム」(http://turing.gatech.edu/)と呼ばれるプロジェクトで、エイミー・ブルックマンは、ペルソナを通じて他人を演じようとする場合でも、その人の普段のアイデンティティが表れてしまうことを示した。現在、(Microsoft Passportのような)連携アイデンティティを作らせるようなシステムを持つことと、新しいシステムごとにユーザに新しいアイデンティティを作らせるようなシステムを構築し続けることの間には、技術的な緊張関係がある。(p.35)

2. サポートすべきではないと思わせる話(クライ・シャーキーの2003年4月の講演を編集した「グループにとって最悪の的は自分自身である」(原文)より)

ソーシャルソフトウェアの設計では、次の4つを目標にしなければならないそうです。

  • ハンドル名を用意すること
  • よい行いが認識されるしくみを作ること
  • グループへの参加には障壁を設けること
  • グループをスケールの問題から逃れさせる方法を見つけること

以下は、第1の目標の説明に使われた話です(http://en.wikipedia.org/wiki/Kaycee_Nicoleも参照)。

カンザスに住むある女性が、高校生ケイシー・ニコールという別なペルソナとしてオンラインで生活していたが、その作られた高校生に対して夢中になる人が出てくるようになったため、その女性はペルソナを捨てることに決め、ケイシー・ニコールとしての彼女は、自分が不治の病に冒されていると言い始めた。

(中略)

何十人という人が、何百時間もかけて、いったい何が起こったのか解明しようとした。それは分散的探偵活動みたいになった。最後には彼らはニコールのさまざまな投稿をつなぎ合わせ、でっち上げを明らかにした。

多くの人がこれを見て、「ほら、言ったとおり。オンラインではアイデンティティはとても流動的なものなんだ!」と言うことだろう。しかしそれはケイシー・ニコールの話の教訓ではない。本当の教訓は、自分のアイデンティティを変えるというのは、とても変なことなのだということだ。そしてあなたがアイデンティティを変えてでっち上げていたということにコミュニティが気付くと、それは大きな甚だしい罪であるように見なされる。(p.192)

ソーシャルソフトウェアが「分人」のようなものをどうサポートするかは、10年以上前から議論されている、難しい問題です。

ソーシャルコンピューティング入門

4781913210チューリングマシンで表現できるものは原理的には計算可能である。しかし、その計算が現実的かどうかは別問題だ。たとえば社会を理解したいなら、社会全体をチューリングマシンで表現するのではなく、実際に計算できるようなモデル化が必要である。そのモデルは、「インプットとアウトプット」という伝統的な形式にはおそらくならない。増永良文先生の『ソーシャルコンピューティング入門』は、このようなアカデミックな視点から、今日のウェブ社会を理解しようとしている。

集合知の具体的な手法なども紹介して、アカデミックであると同時に実践的でもあるようにしているのはさすが。

(参考文献リストあり。索引あり。)

千葉工業大学までの所要時間(車の場合)

各地点から千葉工業大学正門(北緯35.6898・東経140.0203)までの距離を Google Distance Matrix API で取得し、Mathematica の ListContourPlot で、ColorData["RedGreenSplit"] の色を付けて描きました。利用できるカラースキームは ColorData["Gradients"] で取得できます。

もちろん、この地図で色がついているからといって、海上をスタート地点にすることはふつうはできないでしょう。

TweetDeckの認証に注意!

多くのTwitter用ウェブアプリと同様、TweetDeckでも下のような画面で認証することができるのですが、たとえTweetDeckのユーザであっても、安易に「連携アプリを認証」ボタンを押してはいけません。

TweetDeckの認証画面

TweetDeckは、先日Consumer KeyとConsumer Secretが漏洩したTwitter連携アプリの中の、唯一のウェブアプリです(参考:TweetDeck をハックしたら予想以上に酷かった件)。幸いなことに、OAuthログインができるようにはなっていないため、CSRFのような使い方はできません(上のような画面で止まります)。しかし、フィッシングっぽく悪用される危険はあります。

TweetDeckユーザの中には、上のような画面が出てきたら、つい認証ボタンを押してしまう人がいるのではないでしょうか。

Consumer KeyとConsumer Secretが漏洩しているので、OAuth認証でTwitterを利用するWebアプリケーション(PHP PECL/oauthの場合)をちょっと改造して、たとえばダイレクトメッセージを全部読み込んでからhttps://web.tweetdeck.com/にリダイレクトするようにしておけば、ついボタンを押してしまった人には気付かれずに、秘密の情報を抜き出すことができます。

Twitterは、あらかじめ登録されたコールバック先(ドメイン)にしか転送されないようにするなどの対策をするべきなのかもしれませんが、APIが使いにくくなるのは困るので、現行のConsumer KeyとConsumer Secretを一度向こうにして、これらを暗号化したバイナリの配布を促すという感じにしてもらえればと思います。

ここで紹介したような話とは別に、漏洩したConsumer KeyとConsumer Secretがユーザに害を与えない方法で流用されるのは、最近開発者に対して優しくなかったTwitterの、自業自得な気もします。

複数のブラウザで1枚の地図を作るNode.jsアプリケーション

4774153206Node.jsのサンプルというとまずは「チャット」なのですが、「前からできたじゃん、何が新しいの?」とか言われるだけなので、もう少し派手なのを作りました。

複数のブラウザで1枚の地図を作るNode.jsアプリケーションを、試せるようにしてみました。

お試しサイト1 (AppFog)・お試しサイト2 (Heroku)

わずかな主記憶だけでやっているので、アクセスが多くなるとダメになるかもしれません。

動く様子を再掲します。

追記:コードはここからたどれます。