  |
はてなキーワード: アクセス権限とは
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
要するに PackageInstaller が権限チェックするタイミングと、実際にインストールするタイミングの間に、対象の .apk を置き換えてしまうという手法となります。(Google Play ストアからのインストールの場合は、一時的な .apk は /sdcard などではなく端末内のセキュアな場所に置かれるために、書き換えることができません。)
また Android 4.3 以降は、権限チェック時に AndroidManifest.xml のチェックサムを記録しておき、インストール時にももう一度それを確認するように PackageInstaller が修正されているようです。(一部のベンダの端末では 4.3 でもこのチェックをしていないので脆弱性の影響を受ける)
さらには、4.4 以降であれば、上記のチェックサム確認の他に、そもそもアプリが自由に /sdcard を書き換えることができなくなっているので、.apk を書き換えること自体ができなくなっていますね。
ユーザにできる自衛策としては、Google Play からのみアプリをインストールする、といったところでしょうか。
あるいは、/data/local/tmp はアプリからは書き換え可能でしたっけ？
できないのであれば、PC で .apk ファイルをダウンロードしたのち、adb install でインストールする、という手もありなのかな。
あ、ちなみに Amazonアプリストアアプリ (ややこしいな) は既にこの問題に対処しているようなので、Amazonアプリストアは安心して利用しても大丈夫かと思います。
数百億円かけて集めた名簿が、一夜にして悪意ある人間に盗まれて
ライバル企業は名簿屋を挟んでロンダリングすれば合法的に使えてしまう…という状況は、
盗む側・利用する側にとって利益が大きすぎてどうしようもない。
いままで存在しなかった名簿が数百万件も売りこまれてくれば、
どう考えても合法的に得たものではないとわかると思うんだが…これでも許されるのだろうか。
とはいえ名簿がデータで簡単に持ち運びできる時代、
アクセス権限を持つ個人が借金などに追われて悪意を持って動くこともあるわけだし
民事で賠償請求されようがどうせ払わなければいいわけだし、（ひろゆきのように）
刑事罰で１年や２年懲役になろうが
協力者から後日、収益を還元してもらうなどすれば…十分にペイするわけで
これはもうセキュリティ強化と重罰化だけでは防ぎようがないと思う。
そこで個人情報流出で被害を受けるのは流出した「個人」であり、
個人情報を利用する側の最終的な動機が「収益」であることから
流出した情報の利用を末端でストップさせる仕組みというのはどうだろう。
たとえばＤＭや勧誘においては個人情報の入手経路を多段階で示すことならびに
またリストの削除は一括してできる仕組みの導入を義務付ける。
１：水族館のイベントでH22.10.12にA社にご自身が提供しました。
２：規約に基づき同日、子会社であるB社にも共有されました。
３：H24.3.1 B社が規約に基づき名簿業者C社に転売されました。
４：C社から名簿を買ったD社がＤＭを送らせていただきました。
…といったリストおよびチェックボックスがあり、全削除にチェックして返信した場合
A,B,C,Dの全社から一括削除が義務付けられれば拡散も防げるようになる。
さらに、1人5,000円+実被害額などの賠償額を明確に定めておき
もし不正にA社が取得していた場合、利用したD社がまず個人に賠償することを義務付ける。
（その後、D社からA社に同額を請求したらよい。）
これでまともな企業であれば出所の怪しい名簿を利用することをやめるだろう。
そしてダミー会社を挟んだり、委託でごまかしたりしても訴求するように
D社が賠償をできない、倒産した…といったときはC,B,Aとさかのぼって
会社ならびに役員に遡及できるようにする。
名簿を共有したり転売することで利益を得る以上、
その先の損害については知らないというのは許されない。
また個人情報を犯罪者や胡散臭い会社に売ることそのものが減るだろう。
どうっすか？
以下は2月に岡田斗司夫の会員制SNS「クラウドシティ」に辞めた社員が残った社員とクラウドシティの会員のために書き残した。
http://anond.hatelabo.jp/20120527012755
http://anond.hatelabo.jp/20120527215622
も参考に。
――――――
さよならオタキングex 私がオタキングexを辞めた理由 その１ 「自ら率先して能力を低下」
私は2010年3月の立ち上げからオタキングexに参加していました。2011年に入ってからは実績と言えるほどの仕事はしていません（できなかったというほうが正しい）でしたが、2010年はオタキングexの公式サイト制作やその後のコンテンツの管理など、それなりに貢献はしてきたと考えています。
「参加していました」と冒頭で言っているように、現在は退職しています。正確には、2011年11月17日付でオタキングexの社員向けSNS「バベルの塔」に岡田斗司夫や他の社員の目に必ず触れる形で退職届を出しました。
退職をする際、岡田斗司夫が提示したある方針に納得できないことを理由に挙げましたが、実際はそれほど単純な話ではありません。様々な不満の蓄積が積み重なっての結果でもあります。
1年半あまりに渡ってやってきた活動を途中で辞めるにあたって、岡田斗司夫に対して思い残すことはなかったのですが、残った社員に対してはそれなりに申し訳ないと考えていました。残る人たちに対するダメージを最小限にするためには、スパっと辞めるのが一番よいと判断し、そのためバベルの塔では退社理由を短い文章にとどめ、同時に周辺をかき乱したくはないという意志を明確にするため、バベルの塔とクラウドシティへのアクセス権限停止も申し出ました。
ただ、このような退社の仕方では、私が辞めた理由の説明責任を果たしたことにはならない。なので、一部有志に対して私がオタキングexを辞めた理由を数回に渡って書きました。これから続く長い文章は、12月初旬に書いたものです。
当時からこの文章について「転載はご自由に」としてきましたが、それを情報がより拡散しやすいクラウドシティに掲載するために体裁を変えているのは、2011年11月と2012年2月で状況が大きく変わっているからです。2011年11月に退社宣言をしたのは私一人でしたが、その後オタキングex（現FREEex）では退社宣言が相次いでいる状況だと聞いています。
しかも、退社宣言をしているのは何もしてこなかった人ではなく、皆それなりにオタキングex内（あるいはクラウドシティでも）で存在感を示してきた人ばかり、いわゆる今まで核となってきた人たちです。3月の社員の更新手続きの際に何もしなければそのまま退社することになります。それを待たずして退社宣言をしている理由はニュアンスの違いがありますが、「これ以上ここにいてもいいことがない」と判断している点で共通しています。
今後FREEexに入社を検討される方、あるいはクラウドシティの入会継続を考えている方の参考にしていただければと思います。
――――――
１つ目は、岡田斗司夫が最近、明らかに仕事を手抜きしていて、それに伴い能力も劣化していること。しかも、自分が止めようとしても、本人が自らの能力劣化を推し進めていて、周りもそれに賛同して許してしまっていること。
自分が何かを指摘する度に岡田斗司夫にイヤな顔をされるのは別に構わなかったのだが、それにより批判を言いたくても言えない人たちを萎縮させ、さらに言いにくい雰囲気にしてしまっている。しかも、一部社員はそのようにして社長を甘やかすのはいいことだと本気で信じている。
仕事の手抜きについては、アスキーの「「ま、金ならあるし」」を明確な例として挙げたい。
ある食堂が今まで提供してきた定食の料金を無料にするが、その代わり残飯を提供すると言ったらどうするか。大半の人は金を払っても、今までの定食を食べるはずだ。
ま、金は雑誌の最終ページという一等地に掲載されている。雑誌にとっても看板コラムのはずなのに、最近はクラウドシティの宣伝が目立つ。一等地にある食堂で残飯を出された揚げ句、「うまいもの食べたいなら１万円払ってクラウドシティへ！」と宣伝されているアスキー編集部、そして読者の立場になって考えたことはあるのだろうか。
自分は2011年に入ってから、岡田斗司夫が講演などのアウトプットばかりでインプットがない状況をまずいと思っていた。社員とクラウドシティ市民との交流もいいが、それだけでは発展性がない。なので2011年の2月、クラウドシティ市民も同席したオフ会で、「ま、金」は様々な分野の専門家をインタビューしたらどうか、と提案した。去年「ま、金」でやった苫米地英人との対談をまとめた「お笑いウルトラリッチ」のイメージだ。
個人的には、今後本を執筆する上でも参考になる人をインタビューすれば、連載＋本の材料＋音声、映像はクラウドシティやウェブのコンテンツと、一石三鳥になるのでは、という目論みもあった。
この提案に対し、岡田は「対談記事なら誰かが書き起こせばいいし、俺も楽ができる」とすごい安易な解決策に走ろうとした。週刊アスキーは元々インタビュー連載が多いし、巻末の看板コラムをインタビューにするというのはありえない。「それは無理でしょう」と私は言ったけど、本人は恥も外聞もなく、アスキーに提案。当然ながらアスキーには断られた。
そうしたら、楽ができるからという発想で身辺雑記を書くようになった。しかも、「オタキングexへの道」を書き始めたのを途中でぶった切ったままで。11月からは身辺雑記すら書くのが面倒になって、（ボイスチャットシステムの）Teamspeakで、クラウドシティの市民の日記を読んだ感想を話すようになった。でも、話している内容を全く練っていない上、考察も浅いので、面白いとは言い難いものばかりだ。
今まで１週間に１回、〆切という発生装置があって、考えることを凝縮するプロセスを定期的にしていたと思うんだが、それが今は「悩みのるつぼ」だけになってしまった。しかも、そのるつぼもクラウドシティ市民の意見をかなり参考にしているので、切れ味は鈍い。
岡田自身もおそらく自分の能力低下に気付いている。だから、2011年後半に入ってから社員と会ったり、アウトプットを増やそうとしている。でも今必要なのは発信することではなく、インプットを蓄積する＝聞くこと、しかも何らかの体系的な知識を持つ専門家からのインプットだ。そうしたインプットの欠如がここ15年にわたり評論家・岡田斗司夫を「言っていることは面白いんだけど、裏付けが乏しいから信憑性に欠ける人」にしているので。
岡田斗司夫が最後にテレビ出演したのは2010年10月、「ハーバード白熱教室」の特集番組に出たときだ。このとき注目されたのも、本を読んだりテレビを見てツイッターをするだけでなく、六本木でサンデル教授の授業に出たりするなど、質のよいインプットがあり、それなりに咀嚼する時間があったからだ。
ただ、最近は社員と会っていても、自分の話をするだけに終始していると聞く。これでは考えの咀嚼や積み重ねにはつながらない。
2011年に開催したイベントでは同志社大での講演が評判よかったようだが、これは2010年10月に開催して観客の反応がイマイチだった「国民スナフキン計画」の雪辱戦で、関西の社員総出によるバックアップもあったからこそだ。
だから最近のイベントは11月末に開催したディズニーリゾートでのニコニコ生放送をはじめ、見るに値しないつまらないものが多い。しかも、本人はニコ生の海賊放送をはじめ、イベントをやりたがり、周りもそれを後押ししている。さらに言うと、本人はニコ生をやった後は疲れてぐったりなので、自分の考えを広めるための媒体に注ぐエネルギーがどんどん削がれていっている。そんなマイナススパイラルが続いている。
自分としては、岡田斗司夫を「昔の名前で売っています」といった、通販番組に出演しているタレントのようにするためにオタキングexに入ったわけではない。本人が立ち上げ時に「東京ドームで『ひとり夜話をやりたい』」と言ったように、よりメジャーになるための手助けをできればと思っていた。
でも、最近の岡田斗司夫はex内やクラウドシティに目を向けるばかりで、率先して通販タレントになろうとしている。周りもそれに満足して、それがいいことだと思っている。これにはついていけない。そもそも、本人の能力と影響力の低下は、exの理念である「人類の苦痛を0.3％軽減する」ことから遠ざかることにしかならないはずなのだが…。
続く。
