August 09, 2009
もう既に10.6万人ぐらいになっていました。
今後ともよろしくお願いいたしますm(__)m
10万人のユーザーが中心になってモバツイッター上で確認されてるツイッターユーザーの数が22万人。イメージとしては、ほとんどのユーザーが誰かと誰かのフォロワー関係の大多数を共有しているという構造で世間が狭いハズという認識でいたのですが、日本のツイッターユーザーは5月に77万人を超えているという話でしたので、まだまだ断片的な情報に過ぎないんでしょうね。ただ、もっと少ない時から、モバツイユーザー : 把握してるユーザー全体は、1:2ぐらいの比率だったから、ユーザーを40万人ぐらい抱えたら大多数の日本人ユーザーを把握できるんでしょう。
あと、いずれ対応を迫られると思ったので、さっきoAuthにも対応してみました。Peclのライブラリを使って、5hぐらいの対応時間でした。
oAuthは、あくまでも「PCからの簡単登録」という機能にしました。
早くモバイルのtwitterがユーザー登録＆oAuthによる認証登録に対応して欲しいなぁ・・・。
なお、この機会にセキュアなところを期待される方は、
１．oAuth設定後に、
２．設定画面で「パスワードロック」をON
にすると良いと思います。モバツイのURLに対してツイッターパスワードによるログイン確認を必須にできます。（このパスワードはもちろん保存しません。）
ちなみに、DBの実装的には認証方式を記述するカラムを追加して、通常はnull、oAuth経由の登録であれば「'oAuth'」という文字を入れるようにして、それ以外は、oAuthのtokenとsecret_tokenをそれぞれID,Passとしてみなして保存しています。
apiリクエストの際には、認証方式を見て、HTTPのRequest処理をちょちょいと振り分けてるだけ。あとは一切変わりません。
で、作ってみて、そりゃそうだよなと思ったのですが、こんなことを書くと怒られるかもしれないのですが、こんなややこしいことをやっていても、よくよく考えるとすべてのWebサービスがDBレベルでの情報漏洩を前提としたサービス設計（というかユーザーエクスペリエンス設計が正しいか）ってないよな、と思ったのと、oAuthは、あくまでもユーザーの意志で、passwordがexpire可能で、サービス毎にユニークなID、Passが発行されますね、というのがoAuthの実態なのですが、最近、若干、問題になっているtwitterサービスが乗っ取られて、twitter上でよろしくないことが起きるリスクは、oAuthを使おうが使うまいが一切変わらないということが、ソースコードを見てはっきり理解できたので、パスワードを預けるか否かだけで全然信用できない、とか、そもそもoAuthだから、このサービスは安心ということはないので、oAuthという文字に踊らされすぎないように、みなさんご注意ください。（なおモバツイはそもそもユーザーの意志で、いつでもパスワードを消すことができるサービスですし、DBではパスワードは暗号化されています。）
データの持ち方については、あくまでもエンジニアのリスク管理レベルで、まぁそりゃそうだよねと腑に落ちる認証ではありますが、仕組みを理解しなくて良いユーザーからすると、そこってどうでも良い世界だったりするし、むしろoAuthだからって信用しちゃいけないのは先般のDMスパムが起きたとおりだと思います。やっぱりクッキー認証があるからってパスワード入力を求めないってのは、この認証方式が利便性重視なことを物語っていると思います。そこが守られないからってユーザーリテラシーが低いとか、UIが悪いと言ってしまった時点で、この方法はセキュアな認証方式としては現時点では本末転倒な可能性が高いと思います（今のままだと、どんなに頑張っても、文言を読まないでクリックするユーザーは絶対に存在します）、僕は、むしろその利便性に共感を覚えてしまった方なので、この方式は「PCからの簡単登録」である、と判断した次第でございます。
-------------------
上記について補足追記
こういうことを書くと、ID,passを保存してることをOAuthと比べて変わらないと言って、混乱を招く部分があったが、そういう意図ではない。
僕が変わらないと言った部分は、OAuthだけではサービスが乗っ取られた場合に、サービスの機能を利用して起こりうる「なりすまし」にはOAuthは特に関係のあるものではない、ということ。
と言うのも、OAuthとは全然違う話に課題があって、今、twitterクライアントが抱えるセキュリティリスクとして、twitter自体の存在感やユーザーが増えてくるに従って、この「なりすまし」が重要な問題になってきています。少なくとも僕はそこに関心を置いていました。そこについてはOAuthではカバーできないことがわかりました。
一度api利用に認可を与えてしまったOAuthのキーは、ユーザーがストップをかけるまでは認可の範囲で自由に利用可能です。そりゃまぁ当たり前ですね。
ですが、正直実装してみるまで、OAuthってこんな感じのものかってのが、よくわからなかったってのと、そもそもリスクとしてイメージしていたのは、もし、ストップをかけるまでに起こってしまった事象が極めて重大な問題で、OAuthが持つ、後からサービス単位で認可を止められるメリットですら、大した意味を持たないような話を想定しています。
（あえて言うなら、初めて女の子とHしてみるまで、過大な幻想を持っていました、みたいなニュアンス）
そうならないようにするのは、あくまでもアプリケーション開発者、運用者が頑張るところです。
もちろん、パスワードそのものがDB内のデータやプログラムのソースコードが流出、漏洩するなどと言ったシステム上の極めて重大なトラブルに関して強いのは、もちろんOAuthです。
例えば、SSLというプロトコルがあると思いますが、SSLを使ってるからと言ってもビジネス面においても100%安心でも安全というわけではないわけですね。Verisignなどで取得したSSLは通信路の暗号化と、所在の証明という2点の安全を担保してくれるメリットがあるわけですが、SSLを使っているからと言って、商品を送らない詐欺がなくなるわけでもなければ、SQLインジェクションによる個人情報漏洩がなくなるわけではない。
そこはビジネスやアプリケーションの開発者が守らなくてはいけない部分で、OAuth についても「OAuthを使ってるtwitterアプリは安全」という言葉があったとしたら、その言葉はいささか乱暴で、あくまでもOAuthが担保してくれる部分と、全く担保してくれない部分があるよってことが言いたいわけです。
サービスの作り手も、OAuthを使ってるからって安心しすぎないで、あくまでもユーザーの信頼を預かっているんだということを常に念頭に置いた上で面白いアプリケーションを作って欲しいです。
言ってることは、OAuthは「apiの委譲に過ぎないんだから、そんなの当たり前じゃん」というところにすぎません。が、「安全」という言葉は一人歩きするから怖いんですよ。で、後から問題が起きて叩かれるのはOAuthです。
しかしながら、逆に「だからOAuthを使わなくてもいいんじゃないの？」と思われてしまうのは、全くの本意ではないので、そんなことを言いたいわけじゃないんだよ、ということを追記しておきます。何の意味もないものを導入したりはしませんよ。
PHPのPECLのOAuthライブラリを使って、ゼロから初めて5時間で実装から7台の稼働中のサーバーにインストールしてリリースできました。若干概念の理解に手間取りましたが、先人の書き込みをぐぐって、サンプルプログラムを流用させてもらえば、すぐに利用できるものですので是非、開発者の方は是非、ご利用ください。
というか冒頭に書きましたが、いずれid,passによる認証は使えなくなると思うので、先々を考えてもOAuthにするべきです。
手元にWindows mobileがないので、もしよかったら画面キャプチャしてどんな感じか送っていただけたりしませんでしょうか？
いつも、役立っています。
いつも、役立っています。