2010/10/30


  • 人が増える
  • サーバが落ちる
  • サーバが落ちる
  • イルカ昇天画像
  • グリーンピースから(以下略
  • Facebook婚
  • Facebook離婚
  • 改変リンク
  • ネタパクリ疑惑
  • 闇プログラマ(以下略
  • 2000人くらいフォローしないと観測範囲が(以下略
  • 勝手にリンク禁止
  • 勝手にフォロー禁止
  • 勝手に「いいね!」禁止
  • はま○やという人が「こんにちわ、こんにちわ」(以下略
  • はせ○わようすけという人が「Facebookの壊し方」をノートに(以下略
  • ○ぬがわまさとという人がXSS(以下略
  • Facebookで動くボット登場
  • ボットと知らずに恋する人現る
  • Facebook版ふぁぼったー登場
  • ダッシュボードに大量の「なるほど5時じゃねーか」
  • 勝手に「いいね!」(以下略
  • FacebookをFBって略すな
  • 認証APIの大胆な変更
  • サポートがユーザに「君らはクライアントの半分を殺した」と言われる
Posted at by



2010/09/10


ようやくTwitterのやりたい事が分かった気がする。

数日前、TwitterのxAuth/OAuthの扱いについての記事を書いた。
レスポンスの悪さや開発者に足を向けているとも思える対応に、イヤミたっぷりの文面を残したのだが...
mattn:

ところで、Basic認証を廃止した事でTwitterはポスト出来てるアプリケーションの50%を殺したんだと、私は信じているよ。

そのお返事が来ました。が、いきなり出口を塞がれてしまいました。

Twitter Support:

Hi,

Again, we ask that you do not distribute your application's keys and secrets with its source. We are happy to review your application for xAuth once you provide the requested information about it (such as an overview of its functionality and a screenshot of it in action on a Unix-based system or Windows). If xAuth is granted, it will only apply to your application keys and developers who want to compile your source will need to register their own application, apply for it to have xAuth as well, and plug their own keys into the source.

I apologize for the inconvenience that this causes. Please let me know how you would like to proceed.

Thanks

こんにちわ

繰り返しますが、アプリケーションの key および secret はソースで配布しない様、私達はお願いしておきます。 お願いしおりますアプリケーションについての情報(UNIX ベースのシステムもしくは Windows での動作スクリーンショット、および機能概要など)を提供頂いた後に、貴方のアプリケーションについて xAuth の審査をするのが楽しみです。 xAuth が権限付与される場合、それは貴方のアプリケーションキーに対してのみ適用され、貴方のソースをコンパイルしたい開発者は各々のアプリケーションを登録し、その上で xAuth を使える様に反映、そして自信のキーをソースに差し込む事になります。

これに起因するご不便をお詫び致します。どの様にされたいか教えて下さい。

ありがとうありがとう
やっぱりオフィシャルの意向としてはCONSUMER_KEYとCONSUMER_SECRETは公開するなというのが指針らしい。
それではという事でまとめて質問してみた。
mattn:

I have few question.

1. How dangerous publishing the key can be possible?
  If I put the key in the source code, what can be happen?
2. How worse is the hyjack as your said?
  Juggle of timeline of users of my application?
  Speaking ill of my application?
  Spam?
3. How many times we get approval to xAuth?
  I got replies of this issue for 1 or 2 days.
  user of my application will also looking for?

I'm finding the best way or best solution of following problem.

1. All users can use my application immediately.
2. The source code is open source completely.
3. Easy to use, no using browser, no copy and paste of pin code.

Do you have any idea?

I created UI. maybe possible to compile on unix.
screenshot is here:
  http://mattn.tumblr.com/post/1090305624/gtktweeter-on-win32-oauth

Currently, I pushed source code to repository without key.

Thanks. Thanks.

幾らか質問があります。

1. キーを公開するという事はどんな危険がありえるのか?
  ソースコードにキーを置く場合、何が起き得るのか?
2. 貴方の仰るハイジャックはどんなに悪い物か?
  私のアプリケーションを使うユーザのタイムラインを改ざん?
  私のアプリケーションに対する中傷?
  肉詰め?
3. xAuth の許可を得るのにどれだけ時間が掛かるのか?
  私のこの件の返事を貰うのに1日もしくは2日掛かっている。
  私のアプリケーションの使用者も待たされるだろうか?

私は以下の問題を解決し得る一番の解決や方法を探している。

1. 全てのユーザが即座に私のアプリケーションを使う事が出来る。
2. ソースコードは完全にオープンソースである。
3. 簡単に使える。ブラウザは使わない。PINコードをコピペしない。

何かアイデアはありますか?

UIを作りました。おそらくUNIXでコンパイル出来ます。
スクリーンショットはこちら:
  http://mattn.tumblr.com/post/1090305624/gtktweeter-on-win32-oauth

現在、私はキーを含まずにリポジトリへソースをプッシュしました。

ありがとうありがとう
問題視してくれたのか、1日以内に返事来た。

Twitter Support:

Hi Yasuhiro,
To answer your first two questions, if your application keys are public, your application may be compromised and have unintended API calls executed on its behalf. With xAuth, this also means that a compromised application can solicit usernames and passwords and take actions on their behalf that they may not intend. One of our API engineers Raffi Krikorian recently wrote about this, and to quote from his post:

Distributing an application with secrets built into it is equivalent to distributing the secrets themselves. I don't believe that there yet exists a viable platform to store secrets in widely distributed software in such a way that they cannot be eventually extracted.
...
This client identifier can never be the sole security mechanism on a platform. Instead, it is only one part of a puzzle used to maintain security on the network. What this does not mean, is that Twitter will allow applications to distribute their keys in the open. Instead, what the Platform team is trying to create is an ecosystem where getting a new key (in Twitter's case from dev.twitter.com) is significantly easier than re-using a key from another application.

You may read the rest at http://mehack.com/oauth-and-the-twitter-api .

As for your particular application, if you offer a compiled binary with its consumer key and secret made as inaccessible as possible, this should satisfy your first and third qualifications. I have granted your application, client ID 80630, xAuth access. Note that if its keys are compromised, they may be reset and your application's xAuth access may be expired for security reasons. Let me know if you have any other questions.

Thanks


こんにちわヤスヒーロ
最初の2つの質問について...もしアプリケーションキーを公開する場合、貴方のアプ リケーションが侵害される可能性があり、意図しないAPI呼び出しを肩代わりする事になります。 xAuth では、この侵害されたアプリケーションがユーザ名とパスワードを求め、意図しないであろう肩代わりのアクションを実行する事も出来てしまうのです。
我々の API エンジニアの一人である、Raffi Krikorian は最近これについて記しており、彼の記事から引用すると:

広く知られた配布ソフトウェアの中において、非公開情報が結果として抽出されない という手法で、それを格納出来る実用的なプラットフォームが存在するだなんて未だ に信じる事が出来ない。
...
このクライアント識別子は、プラットホーム上の唯一のセキュリティー対策にはなり得ません。 それどころか、ネットワークでセキュリティを維持するのに使用されるパズルの一部にすぎません。 これが意図していないのは、各々のキーをオープンに配布するアプリケーションをTwitterは許す事になるであろう、という事です。 代わりに、Platformチームが作成しようとしているのは、他のアプリケーションからキーを再利用するよりも、極めて簡単に新しいキー(Twitterの場合dev.twitter.comから)を入手する為の「エコシステム」です。

この残りはここで読む事が出来ます: http://mehack.com/oauth-and-the-twitter-api

貴方特定のアプリケーションとして、出来るだけアクセスし難い形にした consumer key と consumer secret を含んだ、コンパイル済みバイナリを計画しているのであれば、まず貴方自信と、第三の資格者を満足させる事が出来るでしょう。
我々は貴方のアプリケーションに xAuth アクセスの許可を与えました。クライアントIDは 80630 です。 キーが侵害され、キーをリセットした場合、セキュリティを理由に貴方のアプリケーションの xAuth アクセスは停止させられるでしょう。
何か他の質問があれば、教えて下さい。

ありがとうありがとう
んー...。要するにユーザIDとパスワードによる認証方式とは別に、いくらでも吐き捨て可能な認証ID公布方式を取りたいんだと。まぁ確かにそれならパスワードという、下手すりゃパンツの中身を見られるよりもダメージの大きい物を曝け出されるよりは、幾分ダメージが小さくなるのかもしれない。
ただしその為には、アプリケーションに付与される権限によってパスワードという秘密の園に到達出来ない仕組みが必要であり、かつ申請方式等といったとてもバカげた物を廃止する必要があり、全てオートメーションにかつMachine Readableに遂行出来る様にもすべきだと思う。
さらには既にあるアプリケーション、例えば私の「gtktweeter」についてのページがあり、そこからボタン一発(例えばforkボタン?)で入力情報がコピーされ新たな consumer key と consumer secret が付与されている...という位の自動化が成されない限りは、Twitterの目論見は失敗へと変わるだろう。

あと、cheebowさんからのコメント
cheebow cheebow

「連投しオフィシャルからbanさせるなんて事も可能です。」ってあるけど、この場合banされるのはこのクライアントを使った「ユーザ」だよね? http://mattn.kaoriya.net/web/twitter/20100908165946.htm #Tw

http://twitter.com/cheebow/statuses/23966546230
上のTwitterの回答を見ると、どうやらbanされるのはアプリケーションの様です。実際どの様になるかは分かりませんが。

なお、gtktweeterについてはブラウザを起動してPINを入力させるという、極めてウンコな実装としてgithubにpushしておいた。ソースコードの CONSUMER_KEY と CONSUMER_SECRET を書き換えてコンパイルして使って下さい。えっメンドクサイ?だってTwitterがそうしろと言ったんだもん。

ところでTwitterさん、最後の質問「xAuth の許可を得るのにどれだけ時間が掛かるのか?」はどうなった?
Posted at by



2010/09/08


さて、TwitterがBasic認証を廃止して1ヶ月が経とうとしています。
皆さんクライアントをOAuth対応したり、乗り換えたりしたでしょうか?
今までBasic認証で動いていた、ちょっとした捨てコード、どうなってるでしょうか?
Twitterが始まった当初、gtktwitterというデスクトップGUIで動くTwitterクライアントを作りました。まぁ作りはそれ程優れた物じゃなくて、RTなんか無い頃でfriends_timelineが見れて、発言出来て、@によるリプライが出来る程度の物でした。
ただ純粋なC言語だけでGTKおよびcurlを使ったクライアントという事もあり、一部のgeekからは人気があったみたいです。
さてこのgtktwitterを今回、Basic認証が消え去った現状でも動くようにしてあげようと思い、今回改造を始めた訳です。
まず大きな壁にぶち当たりました。

Twitterクライアントに「twitter」という文字を含められなくなった

今まで作った物をどうしてくれるの?とも思いましたが、まぁそれはTwitterのやり方でもあるので従わなくてはなりません。「gtktwitter」を「gtktweeter」とリネームする事にしました。簡単なお仕事です。
ただし今までgtktwitterとして検索エンジンで引っかかっていた物が既に使い物にならない物になるのは寂しいですが。

デスクトップで認証出来る仕組みがxAuthしかない

Twitterがそうしろと言うならば従わないといけないのです。以前mixi APIがWSSEを採用した時も「AtomPP/WSSEなんかやめちゃえ...」と言ったりもしましたが、Twitterやりたいなら従うしかないのです。


ここまでは順調だと思ってました。
pythonでxAuthを使うサンプル書いたのも、これの布石だったりします。
あの時はCOMSUMER_KEYやCONSUMER_SECRETはクライアントのソースコードに埋め込める物と思ってたんです。

だがしかし、実際にはCONSUMER_KEYやCONSUMER_SECRETをソースコードに埋め込むという事は、APIハイジャックされる可能性がある事を意味しています。
確かにアプリケーション名として、オープンソースで公開されているアプリケーションのCONSUMER_KEY/CONSUMER_SECRETを使い、連投しオフィシャルからbanさせるなんて事も可能です。
じゃぁxAuth/OAuthしか認証方法が無い現状のTwitterで、オープンソースアプリケーションのソースコードに何を持って識別IDを格納出来るのか。

オフィシャルサポートに聞いてみました。以下その会話

mattn:

I'm author of gtktweeter that is GUI application working on unix and windows. I want to use xauth. please


こんにちわ。unixとwindowsで動くGUIアプリケーション"gtktweeter"の作者です。xauthを使いたいです。お願いします。
Twitter Support:

Thank you for your interest in xAuth. As your code is publicly available, your application's keys are posted publicly and external parties could hijack your API access. This presents an abuse risk, and you can understand our concern. Before we can proceed with granting xAuth access, you must remove the keys from your public source. Developers that want to use your code will have to register their own Twitter application and apply for it to have xAuth as well. Once you have made this change, please let us know and include a link to a screenshot of your application in action on either platform. Thanks


xAuthに興味を示してくれてありがとう。君のコードは公開状態なので、アプリケーションのキーが公に開示されてしまっている。部外者がAPIへのアクセスを乗っ取ることが出来てしまう。これは悪用乱用を招きかねないと懸念しており、あなたもそれを理解頂けると思います。私達がxAuthアクセスへの許可を与える前に、公開されておられるソースからキーを削除すべきです。あなたのコードを使う開発者は自らのTwitterアプリケーションを登録する必要がありますし、その上でそのアプリケーションに対してもxAuthの申請を行う必要があるのです。この変更を終えた後に、各プラットフォーム上でアプリケーションが動作しているスクリーンショットへのリンクを含めて知らせて下さい。ありがとうありがとう。
私は目を疑った。ただでさえこの返事を貰うまでに2日半掛かったというのに、このアプリケーションを使いたいユーザが、いちいちアプリケーション登録をし、そのIDをソースコードに埋め込む、もしくはアプリケーション上で設定し、そのCONSUMER_KEY/CONSUMER_SECRETをtwitter supportに連絡し、xAuthに許可が下りて初めてそのアプリケーションを使える様になる。
なんだそれ。

私は続けて質問した。そう、半分キレながら。
mattn:

Hi. What the best way to contain the key or sign into my application?


こんにちわ。アプリケーションにキーやサインを含める一番いい方法ってなんなの?
ちなみに、twitter supportにチケットを登録する際に「Do you feel」という項目があるのだけど、あえて私はこう書いた。
この件に関してまともな回答が得られていないのでtoo bad
この質問に対しての返事も2日かかった。イライラする。
Twitter Support:

We recommend that you do not distribute the keys with your source at all. If you want to provide a compiled binary of your application to download, this may of course contain the keys necessary to function. Let me know how you would like to proceed. Thank


キーを含む全てのソースを公開しない事を、私達は推奨しています。もしコンパイルされたバイナリのアプリケーションをダウンロードとして提供するならば、動作の為に必要なキーが含まれているのかもしれません。どの様にされたいか教えてください。ありがとうありがとう。
やっぱり...

TwitterのxAuthって全然だめじゃん。使えないじゃん。バイナリになったとしてもスニファで確認すればCONSUMER_KEYくらい読み取れるよ。しかもx_auth_passwordなんか生だし。
まさかこんなレベルの運用を考えていたとは思ってなかった。

半分あきらめながら、以下の(イヤミを含んだ)文面を残した
mattn:
Open source.
I want to hear the best way that is possible to ...
* working at all
* publish source code

BTW) I believe that twitter revoke basic auth killed 50% of desktop application posting to twitter.
Best Regards, Thanks.

オープンソースだ。
私は以下を満たす一番の方法を聞きたいんだ。
* 全てで動作する
* ソースコードが公開されている

ところで、Basic認証を廃止した事でTwitterはポスト出来てるアプリケーションの50%を殺したんだと、私は信じているよ。
よろしく。ありがとう。
ちなみに、xAuthを使わずOAuthを使った方法もなくはない。この方法はrequest tokenを要求し、そのrequest token secretを元にaccess tokenを取得する。そのaccess token secretを持ってTwitter APIにアクセスする物。ただしaccess tokenを得る際にはブラウザで許可する必要があり、かつブラウザに表示された数桁の番号をアプリケーション側に知らせてあげなければならない。
ブラウザがどの製品かも分からないし、画面に何が表示されているかなんてアプリケーションは知る術もない。完全手作業でこのPINと呼ばれるコードをコピペするしか無いのだ。
その点、Flickr認証はこのPINを同等(flobと呼ばれる)をAPI経由で貰い、アクセス許可時に引き渡すという方式を取っている為、ユーザは初めての起動時に立ち上がったブラウザで「許可」とすれば良いだけなのである。ちなみに「非許可」とした場合の動作はTwitterもFlickrも対して変わらない。
本当にこれで良かったのか?Twitter。Basic Auth over SSLだけでも残しておいた方が良かったんじゃないの?とか思ってしまう。クライアントの認証にHMAC-SHA1やSSLの対応が必須で、ブラウザ起動の仕組みが必要で、設定ファイルに保存する項目もCONSUMER_KEY/CONSUMER_SECRET/ACCESS_TOKEN/ACCESS_TOKEN_SECRETと4つ増えた。いままで気軽にPerlやPython、Rubyでスクリプトを書いてた様な事は出来ないのだ。
APIで開発者を引き込んだTwitterにとって、この損害は小さくないと思っている。

ちなみに、この件でついカッっとなって一気にブラウザ起動を含めたOAuthのコードを書いた。
何も反省していない。

Twitter API プログラミング Twitter API プログラミング
辻村 浩
ワークスコーポレーション 単行本 / ¥1 (2010年04月21日)
 
発送可能時間:

Posted at by