Tumblr API v2を使用するにあたっては一部の機能を除きアプリケーション登録が必須となっています。
で、自分も最近Tumblr APIを弄ってて色々試すためにポコポコとアプリケーション登録してました。
用が済んだら登録解除すればいいや、ぐらいに思ってたんですが、ふと、そういや登録したマイアプリの解除（unregister）ってどっからやるんだ？と。
で、登録のページを見直してみたんですけど、それらしきボタン等は見当たらず。

登録を解除するボタンが見当たらない…

ドキュメントやフォーラム見てもその辺の内容が見当たらなかったのでapi@tumblr.comに問い合わせてみました。
で、待つこと二日ほど。回答が。

No, you cannot unregister your application manually. If you wish to in the future, please contact support@tumblr.com, and they'd be happy to assist you.

「自分で（手動で）マイアプリの登録解除はできないよ。解除したい場合はsupport@tumblr.comに連絡してくれ」とのことで、やっぱりAPI登録の画面からは出来ないみたいですね。登録解除したい場合にはサポートにメールするしかない見たいです。ガビーン。
ということで皆様アプリケーション登録はご計画的に。

ちなみにconsumer_key等のアプリケーション情報の不正使用が疑われる際には、速やかにsecurity@tumblr.com宛に報告をするように、と アプリケーション開発者用の規約内に言及があります。

Reporting Security Flaws and Unauthorized Access.
You will immediately report to Tumblr any security flaws you discover in any of the Tumblr Services or the Licensed Materials. Tumblr reserves the right, in its sole discretion, to determine what constitutes a security flaw. You will also immediately report any actual or suspected unauthorized access to the Tumblr API or Tumblr Firehose using your credentials. Failure to report such flaws or unauthorized accesses, particularly prior to public disclosure, shall be considered a material breach of this Agreement.

Be a good citizen: report suspected security issues to us before making them public. You can send security flaw reports to security@tumblr.com.

テキトー訳：

セキュリティの欠陥や不正アクセスの報告
あなたがタンブラーのサービスやライセンシングされた製品になんらかのセキュリティの欠陥した場合には、速やかにTumblrに報告するものとします。
Tumblrは何をセキュリティの欠陥と見なすかにおいて、独自の裁量で決定する権利を持ちます。
あなたはまた、あなたの名義で登録されたAPIやTumblr Firehoseの使用において、なんらかの不正アクセス（不正使用）が行われた（あるいは疑わしい）場合、速やかにTumblrに報告するものとします。
これらの報告を怠った場合、特に、報告をする前にその内容を公に開示した場合、本契約に対しての重大な違反と見なされます。

自分でアプリ登録を解除できないのもこの辺、開発者側でその場しのぎの対策で済まさせないように、という意図ももしかしたらあるのかもしれません。

さて、Webページを使いやすく魅力的に見せるためにかかせないアイコン画像ですが、Tumblrのdashboardでも例に漏れず様々なアイコン画像が使われています。

ここんとこいまさらTumblrのAPIを弄ったりしてます。
で、別にそんなに大したことをやるつもりもないんですが、アプリ登録してAPIを使う以上、一応OAuthとかその辺理解しておくべきかな、と思い、まぁ内容的には知ってる人からすれば周回遅れ的なものなんでしょうけど個人的な整理として。

先に要点を書くと、
この記事を書いてる現時点（2014/04/17）で、
・Tumblr APIのアプリ承認方法はOAuth1.0aとxAuthが提供されている。
・TumblrのOAuthではPINコードの入力による承認は提供されていない。
・OAuthのcallback URLの固定は出来ない。
・「xAuth」。XAuthでもxauthでもXAUTHでもない。それぞれ全部別物。（なんでこんなことなってんの…？）
・クライアント型アプリの場合いずれの手段でもconsumer secretは秘匿できない。

Webアプリはまぁいいよね

んで、ユーザースクリプトとかの個人利用的なものを除けば、この手の承認を第三者に要求するのはサーバサイドで動作する「Webアプリ」と、デスクトップアプリケーションやモバイルアプリケーションなどの「クライアント型アプリ」に大別されるわけですが、まぁWebアプリに関してはクライアントサイドJSで無理矢理やろうとか試みない限り（多分出来ないけど※1※2）consumer key & consumer secretはサーバサイドに秘匿されるわけでまぁ基本的にはいいよね、と。

クライアント型アプリは

問題はconsumer key & consumer secret（2.0ならapp_id & app_secret）を埋め込んでユーザーの手元に置く形になるクライアント型アプリ。
クライアント型アプリのOAuthについてはTwitterの騒動とかもあったりして、

「秘密の情報もない」し「callback URLを強制」することもできていない。偽のクライアントを作ることが出来て、callback先は自由に設定できる。何でこれで安全に実装できると思っているんだ!! ギルティ!!

なことは理解していたんですがその辺Tumblrはどうなってるんだろう、と。
callback URLが登録時のURLに固定になってたりするんじゃなかろうか、とか勝手に思ってたんですが、試してみると全然そんなことはなくてリクエスト時にフツーに任意のURL指定できました。あれ？
じゃあURLにcallbackする形でなくPINコードの入力方式で、と思いきやTumblrではこちらはそもそも提供されてないっぽい。んぁ。

ってことで、どうもクライアント型アプリではOAuthは使うべきでないっぽいのかなぁ、と思いxAuthの方を調べてみることに。

じゃあxAuthは？

で、じゃあxAuthはどうなんだろう、と。
Tumblrのアプリ登録のページを見ると

Web apps should use the standard OAuth flow, reserving xAuth for apps in which the web authorization process is impractical or impossible, such as native desktop or mobile apps. 

とあります。
「WebアプリはOauth使ってね、xAuthはWebページでの承認が現実的でないor不可能な デスクトップ、モバイルアプリのためのもんだよ」ってな感じでxAuthの使用には申請が必要になっています。

つーかそもそもxAuthってなんぞや、と。
「xAuthってなにそれXO醤ソースみたいおいしそう」ぐらいの知識しかなかったわけですが、ざっと調べた感じでは、「根本的にはxAuthもまたOAuth」である上で、「OAuthと違いユーザーIDとパスワードをユーザーから直接（一時的に）受け取ることでcallback URLやらPINコード入力やらを介さずにtokenを受け取る。」というものである模様。

OAuthと比較して、メリットとしてはサーバ側（callback URL）を用意しなくて良い。なのでcallbackの過程でごにょごにょを考えなくて良い。
デメリットは、OAuthのメリットであるユーザーからアプリ（クライアント）が直接IDとパスワードを受け取らなくていいというのがなくなるぞ、と。
ふむ。

…で、結局consumer key & consumer secretは埋め込むと。
ということは…？
・Tumblr APIを利用したクライアント型アプリを開発&配布する場合、consumer key & consumer secretを抜かれて偽クライアントを作られるリスクは常に存在する。
・自分のアプリのconsumer key & consumer secretを流用した悪意あるアプリをエンドユーザーが承認しないことを信じるしかない。最後のラインは個々のユーザー任せ。

ということ。
なの…？

まぁでもユーザー側で言えば、それがconsumer key & consumer secretを流用した偽クライアントだろうが純正の（?）悪意あるクライアントだろうが、承認すべきで無いことに違いないわけで、結局個々のユーザーがアプリの承認or拒否という判断に責任をもつしかない。Twitterの場合は他の要素も複合的に絡んでたわけで。
だからまぁ一応はこれでいいということになる…のかなぁ。
…そうなの？
…本当に？

まとめ

ということで「まとめ」とか書いてますが正直なんかまだもやもやしてます。
とりあえずはっきりしているのは、その辺もやもやしてるうちは僕はTumblr APIを使ってクライアント型アプリを作るべきではない、ということでしょうか。（もともとないけど。）

結局のところ「OAuthは元々Webアプリ（Webサービス）間の連携のためのものであってクライアント型アプリの承認を想定したものではない。」ということは頭に置いておく必要がある、ということでしょうかね。
というか「OAuthはそもそも『承認』の仕組みであって『認証』の仕組みではない。」という言われてみれば至極真っ当な指摘も各所で散見しました。

うーんなんかうまいことなんないんですかねぇこの辺。（丸投げ）



※1 軽く試してみた感じ、callbackのURLがjsonでは受け取れないっぽい。
※2 2014/4/19追記：他の方の書いたユーザースクリプトみてたらやってるっぽい記述があったので実際のところどうなのかはよくわからない

「知らんがな」って？いやいやそう言わずに。

本日TumblrにログインしたところDashboardに上記のようなパスワードの変更を促すメッセージが表示されていました。

「Learn more」のリンクからは英語版公式ブログの記事にリンクが貼られており、「Heartbleed」への対策であるとの内容が書かれています。（内容が内容だけに日本語版の記事もいずれアップされるかと思います。）
2014/4/12追記：日本語公式記事きました。

「Heartbleed」というのは先日発見されたOpenSSL（インターネットのセキュリティ技術）の脆弱性の通称で、かなり深刻な規模のもの、とされています。
自分はセキュリティそこまで明るくないので詳細への言及は避けますが、ようはTumblrや個別のサービスうんぬんではなく、もっと広いレベルでわりと洒落にならないセキュリティーホールが見つかっちゃって、過去から現在進行形で色々被害が出ている可能性があり、その界隈の人々が奔走している状況です。

このブログではTumblrの出来事、として拾いましたが、上記の通り影響は多岐にわたるものであり、公式ブログでも「あらゆるパスワード、特にあなたにとっての重要なサービスのパスワードをまとめて変更する良い機会と言えるかもしれない」といった事が書かれています。

この「Heartbleed」関連で、他のサービスでもなんらかのアナウンスが出される可能性はありますので、当面ちょっとその辺アンテナはっておいた方がいいかと思います。

なんかこのポストを見に来てくれる方がちょくちょくいらっしゃるようなので他の特殊文字についても色々試してみました。

一応おさらいしておくと、Tumblrのポストでハイフンを使ったタグを入力するとブログの「(ブログURL)/tagged/（タグ名）」のタグページが生成されないよ、というおはなしです。
で、他の記号・特殊文字はどうかと思いつく限りで試してみた結果下記の様になりました。（2014/4/6時点）

	タグページ生成の有無	URL上で変換される表記
「 」（半角スペース）	○	-（ハイフン）
「　」（全角スペース）	○
「-」（ハイフン）	×
「_」（アンダースコア）	○
「.」（ドット）	×
「:」（コロン）	○	%3A
「;」（セミコロン）	○	%3B
「+」	×	%2B
「=」	○	%3D
「/」	×	%2F
「¥」	○
「&」	×	%26
「~」	○
「^」	○
「"」（ダブルクォート）	○	%2A
「'」（シングルクォート）	×	%27
「@」	×	%40
「(」	×
「)」	×
「{」	×
「}」	×

と、いった結果になりました。 ダブルクォートがOKでシングルクォートがダメ、とかはちょっと予想しずらいですね。まぁどっちもあんまり使わないと思いますが。
比較的使いそうな範囲で使用しない方がいいのは「-」「.」「+」「&」「@」「(」「)」あたりでしょうか。

 あと、ついでにわかったのですが、一つのポストにつけれるタグの数は30個が上限のようです。 まぁそんなにつけることないと思うので十分だと思いますけど…。

ということでTumblrのタグページを活用しようと思っている方のお役に立てば幸いです。
またなんか見つけたら追加します。

Tumblrでは他人のポストに対するリアクションとして「リブログ」の他に「Like（スキ！）」があります。

今でこそ僕も使い分けてますが、しょっぱなから節操なくリブログしてたので当初は「リブログだけでいいじゃんLikeいらなくね？」とか思っていました。

で、現在メインブログがそれなりの数の人がフォローしてくれているおかげでそれなりの数の通知がくるわけですが、見ていると「Like」の使い方って人それぞれでなんだかおもしろいなぁ、と思った次第で。

っていまさら書くのもなんか野暮ったい感もありますが。
いや、ほらアレです。最近すっかり定着した感のある企業のエイプリルフール企画。
そういやTumblrはなんかやってなかったの？と思って調べたらやっぱりやってたみたいです。

さてさて三月も終わりですね。 先月はろくにブログ記事も書いてないんですがまぁ恒例（にしてみよう）と言うことでメインブログのアクティビティ晒しを今月もやってみます。

 先月はこんな感じでした。