  |
はてなキーワード: ドメインとは
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
互助会がホットエントリーに上がらないようにするには、互助会をスパム扱いとすればいいけれど、どこからが互助会でそうでないかは人間にも明確な判断基準が無いからそれは難しい。
いまのホットエントリー入りのアルゴリズムがクソなので、本来の目的である「良い記事をホットエントリーに上げる」ということに注力すればいい。
「良い記事を早くブックマークするのは良いユーザー」「良いユーザーは良い記事を早くブックマークする」という、循環的なアイディアがある。
ユーザースコアははてブのフォロワーとか、機械学習を利用すればブックマークした記事や時間から算出することができる。
そしてブックマークしたユーザースコアの合計を記事のスコアとしてつける。
後は、今のホットエントリ入のアルゴリズムと同じように、一定時間で一定数の記事スコアを獲得した記事をホットエントリ入りとする。
この仕組でもスパムは可能だが、アカウントが大量に必要になるので、別方面でのスパム対策（スパムアカウント対策）で済む。
またユーザースコアの高いユーザー複数が共謀してブックマークするすることでも互助会的なことは可能だが、あまりその可能性は無さそう。
炎上対策についてはブックマークごとにユーザースコアの価値を最初の3ユーザーは100％の価値、次の10ユーザーは90％の価値、と下げていけばいい。（この辺りはRedditのスコアに似た考え方）
自分の作ってるサービス（bh.mgzl.jp）では機械学習でユーザースコアの算出できていない。（実現には膨大なAPIのコールが必要。）
そのかわりフォロワー数とユーザーの総スターをユーザースコアの算出の基準にしている。ただ、スターがユーザースコアに与える影響はとても小さい。1000スターで0.1上がるとかそのレベル。
残念ながら「良いユーザーは良い記事を（早く）ブックマークする」の部分が実現できていないのと、現状のホットエントリーに記事スコアをつけて表示しているだけなので、「良いホットエントリー」にはなっていない。（それでも「マシな感じ」くらいになるように調整し続けている。）
別に統計学をやってたとかそんなんでも何でもないので、破綻している部分もあるかもしれない。
ただ、RPGの与ダメージの様にみたいに足し算をするだけでなく、複雑に計算しないと上手く行かないと思う。アルテリオス計算式みたいに。
ブコメに返信
スター数とお気に入られ数は無駄に多いがキュレーション能力がクソザコナメクジレベルの人もいるので。誰とは言わないが。誰とは言わないが。
いまこの辺りを基準にしている理由は、他に容易に手に入れられそうな指標がないからだったりします。表にでてる指標で良い指標がないんですよね。
ちなみに自分のサービスのユーザースコアは、いろいろ計算して最大3.4、最小-0.5くらいの幅になってます。お気に入られ1000の人と100の人と1の人に差がつけられればいいので。
たぶん既にハテブには独自の良質ブクマ選定機能がある。私はあまりコメ残さずフレ少ないが、技術系や法律系を自分がブクマすると、翌日なぜかホッテントリ浮上する事が。特定分野を集中的にブクマしてると起きる傾向
実際のホットエントリーのアルゴリズムはブラックボックスなのでよくわからないですよね。ブラックボックスにしないでもスパムに食われないアルゴリズムができればいいんですけどね。Googleですら出来てないので無理でしょうが。
このアイディアは「スコア」という単一の指標ですが、「おもしろいブコメをする人」「技術的に優れた記事にブクマする人」みたいなベクトルに分けてもいいかもしれないです。
価値の無いブクマの線引きを固定パラメータですると、結局スパマーに見つかって終わるのでダメでしょうね。1つのパラメーターだけでスパマーに対向するのは無理なので、複数の評価が大事です。本文のアルテリオス計算式の話はこの辺りのことを言ってました。
直近のブクマに関しても、容易に回避可能なのと単にドメインが同じだけ（ニュースサイトとかqiitaみたいなサービスとか）なのか判別不能なので害しか無いでしょう。
更に返信
NGリスト方式だと、無限にNGが増えていってそんな面倒なことをやりたくないってのが大きいです。面倒くさがりなので何もしないでもいい記事だけが上がってきて欲しいのです。
良いユーザーの決め方は、最初は何かしら人間が基準を用意する必要がありますが、その後はブックマークから抽出できるはずなので、動かしてしまえばなんとかなるかと。
最初の基準は、それこそお気に入られ数とかスター数とかわりと適当でいいんじゃないでしょうか。自信はないですが。
Let's Encrypt を使うと無料でSSLが導入できてラッキーと思ったのだが、どうも世の中そう単純ではないらしい。
・Let's Encrypt の使い方
を読むと、まず訳が分からん。コマンドラインが書いてあるから「Telnet必須」なのか？
で、どうも「定期的にサーバを再起動させる必要がある」みたいなので、共有サーバでは話にならなさそう。
専用サーバでないといかん模様（しかも基本的にroot権限は必要）。
だったら「root権限付の専用サーバに乗り替えようか」と探してみれば、安いところでも3,000円くらい。
ナウでヤングな月300円弱の安物サーバで独自SSLを使えば＋1,500円だから、そっちの方が安く付く。
…そういうものなのか。
※2016/04/14追記：
トラバ感謝。「年額1,500円くらいのドメイン認証」があるという記述を読んで探してみた。
ナウでヤングなところだと「月額」1,500円だが、さくらやエックスサーバーだと「年額」1,500円なのな。
そっちで行くのが絶対に安くて楽だよね。
http://www.mermaid-tavern.com/indexs.html
ちょっとバイナリデータのヘッダー解釈とデータ処理をExcelにやらせようとググっているときに引っかかり、中を見て驚愕した。
最初に見た一瞬はイラッとし、ちょっと読むとあまりに低レベルな煽りっぷりに笑い、しかしそれが数百ページもあって、常軌を逸したレベルの量の煽り文を書ける人間性にドン引きした。
人をバカにする文章を書きながら、「ごっこネタ」と言い逃れているあたりが滑稽であり、しかし笑えない。
検索で飛んでくる99%までがオバカなExcel屋とその同類のC#屋とAccess屋である。その実態は企業内低能パソコンユーザーである。ここではそれらを総称して「エクセルバカ」としている。これは ©Microsoft が作り出す産業廃棄物の粗大ゴミである。
このセクションはそのエクセルバカが大好きな「ごっこネタ」である。エクセルバカが能もないのにやりたがる「文字コードごっこ」「バイナリごっこ」「UTF-8ごっこ」「改行ごっこ」「エンディアンごっこ」「16進数ごっこ」「CSVごっこ」「暗号ごっこ」などを総称したものである1)。小学校程度のアタマしかない者が微分方程式を解こうとするのに似ている。なお、私はExcelやBASICなどには興味も関心もない。頭の体操のためにそれで遊んでいるだけである。
確かに不必要に余計なやり方をしている人は困るが、検索してたどり着く人の中には能があり本当にそれが必要だから調べている人がいるだろうに、ひっくるめて全員を罵倒しているのが悲しい。
能がある人は知識を持ってるからググらない？レファレンスを見るからググらない？近くの人に聞くからググらない？本当かな。
というか、文字コードなんてcgi(php,perlあたり)の初学者がWindowsとUnix系の違いを理解していないがために最初に躓く話じゃないの？今はそうでもないのかな？
Excel自体は万能ツールではないし、Excel方眼紙を使う人とか報告書を全部Excelで作れとかいう要求には俺も辟易としている。
けれど、そんなレベルじゃない。明らかに言い過ぎで拡大解釈である。
しかしこの全方位をバカにして煽っていくスタイルはいったいどういう精神構造をしていればできるのだろう。
このドメイン配下のページにリンクしている人、飛んできた人を全員バカ扱いしているようだ。
トップへのアクセスや変な階層に直リンで飛んできた輩は、別のドメインや別ページに飛ばしたうえでIPと検索ワードを取って晒し者にしているらしい。
バカにするだけのためにExcelやBASICを学んだとまで言う。すごい熱意だ。
それに加えて最高に面白いポイントは、ちょっとググっただけで本人らしき名前が簡単に出てくる程度のITリテラシーで、よくここまで言い切れるものだと思った。
実は偽名なのかは知らんが。
これが釣りなら素晴らしい釣りだと思うけど、徹底的に人をバカにする仕方と熱意の強さのせいで釣りに見えない。
そんな素晴らしい能力がある人には見えないけど、こんなことを公言している人がどれだけ仕事ができる人なのか見てみたいもんだ。
どんなオッサンなんだろう。
○朝食：なし
○昼食：おにぎり三つ
○夕食：担々麺
○調子
むきゅー！
明日で同僚の咲の深堀さん似の人と一ヶ月だけだけどお別れなので、
おつかれさまお食事会をした。
だったんだけど、お風呂入って
最近ハマってるNetflixで見れるフルハウスっていう古い海外ドラマを見て
ボーっとしてたら、
なんか胸が苦しくなってきた。
四月から深堀さんがいなくなるってことと、
なんか色々が重なってツラくなってきたのかもしれない。
むきゅーってしてても、パワーがわいてこないです。
むきゅむきゅダンチュを踊れるぐらい、パワーがわくまでは、ちょっと大人しくしてようと思う。
ルカリオ！
これはかき……
いや駄目だって、我慢我慢。
クァンタムブレイク買うしね。
「Killer Instinct シーズン 3」がXbox OneとPC向けに配信。クロスプラットフォームプレイが可能に
http://www.4gamer.net/games/338/G033875/20160330119/
僕もアービター参戦でテンションがあがっているので、本格的に始めるぜ！
と、思ったんだけど、
アービターの単品売りがない？
ま、まじかあ。
KIは操作するキャラクターを単品で買えるのが特徴だったんだけど、
なぜかまでシーズン3のキャラはラッシュしか単品売りがされていない様子。
クァンタムブレイクやバッジとれ〜るの課金もあるので、シーズン3のキャラ全部入りを買うのはちょっとお財布事情的に厳しいな。
というわけで、クレジットカードの決算日が次の月になるまで待ちかな。
『Deus Ex Go』『Just Cause Go』『Life is Strange Go』ドメイン登録が確認
http://www.gamespark.jp/article/2016/03/30/64751.html
へー！ これは面白い試みだな。
僕の好きなHaloとかも出るならやってみたいかも。
たとえ、どれだけ無茶なことを書きなぐっても、自分に被害は及ばないメリット。
匿名である以上、情報の信ぴょう性を担保できない部分がとても残念だ。
http://anond.hatelabo.jp/20160215171759
これも、本来は、『保育園落ちた東京死ね!!!』とボクなら書くだろう…。
保育園を申し込んでいるのは、国ではなく、地域の自治体だからだ。
ま、それをわざわざ、日本とするのはそれなりの考えがあるのだろう。
はてな匿名ダイアリーはドメイン全体で、2016年で、4.7M PVある。つまり月間 470万PVある。
計測が2016年の2月だから3月はこの『保育園落ちた日本死ね』で、これだけメディアで
さわがれているので、軽く100万PVは上がるだろう…。
もしも、この『保育園落ちた日本死ね!!!』を自分のドメインで運営していたならば、RPM 450円で換算すると、
ざっと45万円のAdSense収入が得られている可能性がある。
フルタイムで家政婦を雇える金額だ。ホテルで美味しいものも食べられたはずだ。
ブログ運営は、もちろん本名でなく行える。公序良俗に反しない限り、身元をプロバイダーから当局へ渡されることもない…。
はてな匿名ダイアリーは、しっかり『死ね』という言葉が明示されていてもGoogleから広告料金がもらえている。
匿名ではなく、ネット上のハンドル名でも、実在する個人として、意見を発信したほうが、
『保育園落ちた日本死ね』匿名ダイアリーでなければ家政婦雇えていたのに…
（続き）
まず@animeseiyuの小西寛子に対する言及を見てみよう。
https://twitter.com/search?q=%E5%B0%8F%E8%A5%BF%E5%AF%9B%E5%AD%90%20from%3Aanimeseiyu&src=typd
複数のnaverまとめおよびtogetterがひっかかるが、残念ながらほとんど削除されている。残存している例として
https://twitter.com/animeseiyu/status/593519478404579328
がある。
このまとめを作ったアカウント
https://twitter.com/lovelive_suns
は他にもたくさんのまとめを作っているが、大抵@animeseiyuを経由して拡散している。
また、screen_name、bioおよび固定ツイートは小西寛子陣営に対する煽りそのものであり、これを小西寛子への中傷でない、と言い切るのはやや難しいのではないかと増田は思う。
ところでこの奇怪なアカウント名はおそらくラブライブ！サンシャインのことであろうと推測される。まさかこのアカウントをそのままファンアカウントに転生させるつもりではないだろうが、ドメインゴロみたいな考えもあるらしい。
ちなみに@lovelive_sunsである以前は@tomosenseiであった。
https://twitter.com/togetter_jp/status/593711398301007872
https://twitter.com/HirokoKonishi/status/594404441853296640
@tamatowaは@tomosenseiについてつぶやいている。
https://twitter.com/tamatowa/status/6886588668
https://twitter.com/tamatowa/status/7057712727
https://twitter.com/search?q=%E5%B0%8F%E8%A5%BF%E5%AF%9B%E5%AD%90%20from%3Atamatowa&src=typd
https://twitter.com/tamatowa/status/442445702396776448
まったく正論なのだが、自身が同じ穴の狢になってしまったということなのだろうか…。
https://twitter.com/tamatowa/status/535040930877673472
https://twitter.com/tamatowa/status/592442787997450240
これも他人のことが言えない。
現在は削除されているがbioに「物書き」と書いていた時期はあった。
また時々オープンでない試写会などに出かけている様子を見かけることがある。
長野県警が（おそらく任意で）事情を聞いていた時期に遠出している。
https://twitter.com/tamatowa/status/702596030735319040
https://twitter.com/tamatowa/status/47142940228857858
証拠を積み重ねるのはこの程度でいいだろう。
もしそうならこんな状況証拠を積み重ねる必要は無いし、そもそも小西がインターネットで自分に関する不都合な情報についてもっと上手く立ち回れていればこんな事態にはなっていなかったので、元々誰が悪いかと言えばたぶん小西サイドだと思っている。
長年ウォッチを続けている理由はこのアカウントが一発アウトと言える行為をなかなか起こさないので証拠を集めるしかなかった、というのが大きいが、改めて並べて整理してみると割とドン引きするような所業であった。
この記事では小西寛子が声優業から遠ざかった理由については特に触れなかった。増田自身が興味ないというものあるが、この状況では客観的な判断は難しいからだ。
なのでこの理由について述べること自体が名誉毀損等に当たるのかは正直よく分からない。おそらく「アニメライター」は書類送検されないのではないかと今でも思っている。しかし、倫理的なレベルでいえばこのアカウントは完全にアウトだし、WikipediaからはBANされている。
id:zeroesは自分の正義を妄信しているところがある。相手が悪なら何をやってもいいみたいな節がある上に、そもそもその悪認定がかなり雑なのでタチが悪い。
最後に他の雑な悪認定について追加情報を加えるので、興味がある人は掘ってほしい。
増田のお願いは、@animseiyuの力を削いでほしいということである。
一般のアニメファン声優ファンでこのアカウントをフォローしている人は、ブロック等各自が思う処置をしてほしい。
公式PRアカウントや声優さんはこのアカウントをRTするのをやめてほしい。あなた方がRTするからこそこのアカウントを企業アカウントと勘違いする人が後を絶たないのである。
@animeseiyuをフォローしてないと情報に立ち後れる、という人向けに別途情報を集める方法を伝授する記事を書いても良いが、この記事では省略する。
そもそも@animeseiyuはそこまで情報早くないし、ここまで散々示した通り、偏向しており、場合によっては声優に刃を向ける可能性もある、ということを理解してほしい。
増田は小西サイドが提唱する陰謀論を支持しないが、彼がアニメライターで業界に知り合いがいることは疑いがない（既にポインタは示されている）。ウォッチャーの勘は彼個人の暴走した正義感だと思っているが、陰謀論を否定する根拠もない。
もし@animeseiyuを中心とする陰謀が存在するならば、敢えてこれを凍結せず、しかしこの記事を拡散してもらうことで、それでも@animeseiyuに乗っかる公式アカウントがあれば、それは協力者かもしれない、と言える可能性もある。がその可能性は薄いだろう。
そもそもあのアカウントが掲載している画像は無断転載である。amazonからの転載はアフィリエイトリンクと同時にツイートされれば通常利用の可能性があるが、そもそもあのアフィリエイトIDはどのURLを届け出ているのだろうかという疑問もある。
また、ソースへのリンクを明示せず情報だけツイートされるケースも多く、authorizeされてないまとめアカウントとしては実はかなり問題がある。
id:zeroesおよびサブアカウント群ははてなキーワードにおいてもWikipediaと同様猛威をふるっている。共通する特徴は絶対に自分の意見を曲げないこと、議論をせず無言で差し戻すことである。
WikipediaにおいてZeroesらが執心していたもう一つの揉め事はスペルバウンドという声優事務所関連である。
彼はスペルバウンドが旧ラムズの社長の所有物であるということを証明したかったようで、またそのことは社長の不実を意味すると信じていたらしい。
現在のスペルバウンド社長とラムズの社長は同一人物らしいが、創業時はそうではなかったらしく、そのことが誤摩化しだと思った「Otoame」の逆鱗に触れたという話のようだ。
だが根拠無く印象操作するような記述を繰り返すためここでも終わらない編集合戦が繰り広げられた。
https://twitter.com/tamatowa/status/573461846738403328
編集合戦は議論をしない双方に責任があるのだが相手を一方的に荒らし扱いするのも相変わらず。
id:zeroesはスペルバウンド以外にも胡散臭い（と彼が思う）声優事務所に対して好戦的であった。一部のログが
にある。この件に関してはid:zeroesに分があるように思えるが、法的措置をちらつかされながらも勝利してしまった経験が彼に悪影響を与えたのかもしれない。
細かい案件は更に無数にあり、「@animeseiyuがフラゲ雑誌情報でツイートしてるのにフラゲ雑誌情報をRTしている声優に@tamatowaが説教」など、小粒だが香ばしいものもある。
最後に。
精神を病んでしまった声優さんが元所属事務所に対して攻撃的な文章をブログにアップしたあと自殺を図った、という痛ましい事件があった。この件に対して、@animeseiyuはわざわざ削除されたブログの魚拓を取って晒し上げるという乗っかり方をした。
（この件についてはURLを直接示すと該当魚拓が検索エンジンにクロールされ、セカンドレイプ的な構図になってしまうので、証拠を直接示すことはしない。必要であれば@animeseiyuのツイートを魚拓経由で辿ることができる）
声優と事務所の間にどんなトラブルがあったのか分からないし、どのような理由であれ明らかに精神衰弱状態での言動を保存し、拡散するという行為は一人の人間に対する攻撃としか増田には思えない。この件が増田に@animeseiyuをいつか潰してやると思わせた理由の一旦である。
また、この件に対する@tamatowaのコメントはこちら。
https://twitter.com/tamatowa/status/473672404300873728
繰り返すが、@animeseiyuは潜在的に声優の敵である。
読者の懸命な判断を期待する。
はてなのアカウントでログインできます。パスワードはSSL通信で送信されます。
はてラボは *.hatelabo.jp ドメインで運営されており、*.hatena.ne.jp ドメインとは別にログイン状態が管理されています。
はてなのアカウントをお持ちでない方は新規ユーザー登録でユーザー登録を行ってください。
うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。
http://imgur.com/zktu5Fh http://imgur.com/user/quotesgiant https://www.similarweb.com/website/quotesgiant.com http://aacsb.csudh.edu/UG/tabid/36/forumid/12/postid/2365/scope/posts/Default.aspx http://www.opzk.ru/otzivy/otzyv.html-407 http://www.123cha.com/alexa/quotesgiant.com
よく「炎上をして人が来ても、効果は一時的でそのうちみんなからそっぽを向かれてしまう」と言われます。けど、やり方によっては、炎上によってビジネスの利益を最大化することができるのではないでしょうか。
たとえば、「水素水」について炎上成分バキバキの記事を書きます。科学的にも、論理的にもツッコミどころ満載の記事を。すると、炎上。はてなブックマークがたくさんつく。加えて、それなりにドメインパワーのあるはてなブログからも批判的言及がされる。
もし、意図せず炎上してしまった場合は「どうしよう・・・」と焦るかもしれませんが、意図的に炎上を起こした場合は「よし、被リンクゲット。ドメインパワーも上がった！やった！」と思うだけです。現状では、批判的な言及も被リンクですので。
たとえば、イケダハヤトさんは、クソみたいな薄っぺらいアフィリエイト記事でも、検索上位に表示されているものがあります。なぜこんなことが起こるのか？数々の炎上を起こし、数々の言及をもらってきたイケダハヤトさんのブログは、ドメインパワーがとても強くなっているからです。そんじょそこらのアフィリエイトサイトではかないません。
今までは「炎上で来た読者は長期的な読者には成り得ない」とされていました。実際、そうでしょう。Adsenseでマネタイズするなら、炎上で来た人は、所詮一見様なので、さして金になりません。
しかし「炎上＝一気にナチュラルリンクを獲得する手段」と考えるなら、話は違ってきます。もともと炎上するつもりで書いているなら、炎上なんて屁のつっぱりにもなりません。あとは、ほとぼりが冷めた後に、バキバキのアフィリエイト記事に内容を修正すれば、あっと言う間に秒速マネタイズの完了ですよ。
実際、一部のアフィリエイター「水素水の人」とか「育毛剤の新常識」とかいうサイトとか、はそれを意図して炎上させています。
アフィリエイト以外でも炎上は有効かもしれません。たとえば、サラリーマンをこっぴどくDisる記事を書く。もちろん大半には批判される。でも、「サラリーマン的な生き方」ができなかった人にとっては、「我が意を得たり」と刺さるわけです。実際、イケダハヤトさんの有料noteで「サラリーマンではいけな理由」とか「あなたが悪いのではなく環境が悪い」とかいう記事が売れています。また、サロンのメンバーを調べると、精神病の罹患歴があったり、企業をうつでやめてしまっていたり、ニートだったり、偶然かもしれませんが、社会的な弱者の方が多かったです。
大半の人に嫌われても、そういう「カモ」に刺さる文章を書けば、一定の顧客は増えるわけですよ。それを考えると、炎上って結構効果的なウェブマーケティングになっていくのではないかしら、と思った次第です。
だいたい (ランダムな英数字)@cn.com とかで毎回違うのを使って登録してくる
T/Oでもいいんだが、例示もするし喩えもする。腹立ってるから。
20〜40usersって言えば「まあ一読する価値はある」ってレベルのものだった。はてブロ以前は。
はてブロとともに互助会が生まれて変わった。10人前後の互助会+とりあえず赤字になってればブクマする勢の天井が大体30users台後半。
ここの辺りの記事の質のばらつきがとんでもなくひどすぎてほんと使いにくい。
23users 骨法・堀辺正史氏逝去。「梶原系ハッタリ」が許された時代は遠くなりにけり…… - 見えない道場本舗 - http://d.hatena.ne.jp/gryphon/20160303/p1
22users 出版状況クロニクル94（2016年2月1日～2月29日） - 出版・読書メモランダム - http://d.hatena.ne.jp/OdaMitsuo/20160301/1456758003
前者は骨法堀辺氏の訃報に触れて、骨法の歴史的意義をYouTube、マンガ、インタビュー引用を用いて軽く紹介したもの。
後者はおもに太洋社廃業への具体的数字と、波及と、業界内での立ち位置、そしてそこから見えてくる出版不況の本当のウィークポイントについての見解。
34users 多趣味な男性がモテるはずないのは事実だけど結婚はできるよ - MIKINOTE - http://www.mikinote.com/entry/tashumi-motenai
趣味自慢（お金持ってるんだぜ）、結婚自慢（お金持ってるんだぜ）、おもしろいオレ写真、果てはサンプル数１で雑なポジティブアドバイス風。非モテ論議華やかなりしころに有名中立ブロガーが突如公開したものだったら、逆に大炎上しただろうなあ、という感じ。
22users 北野天満宮の梅苑に行ってきました！ - niko life... - http://niko.hateblo.jp/entry/2016/03/02/202417
そうですか。別に悪くはないんだけど、よくそれを全世界に公開しよう、できる、と思ったね。メレ子とかと比べるのは酷だけど、どうしたってそれはWWWだから同じ天秤に乗る。銀塩があなたの個性らしいけど、まず左手の筋力をつけて、水平を取るところから始めようか。
27users つべこべ言わず１記事でも多く書きやがれ、ＰＶなんて見るな！ - ポジ熊の人生記 - http://www.pojihiguma.com/entry/pvpv-uruseebaka
1つのことしか言ってない。せいぜい1段落で済む話をなんで1700文字も書いてるの？そっちのが“SEO”にイイとでも教わった？ていうか何の何で上から目線なの？誰？
28users 女子の二郎食べてきました - トウフ系 - http://kaishaku01.hatenablog.com/entry/2016/02/29/191249
タイトルと写真2枚で成立してて切れ味ある。ついでに1800kcalって情報も入ってて知見。わりといい感じ。
-------
な？
たとえば靴屋で3万円の値札がついた箱があって、片方は開けてみればMaid in USAの本革のブーツ、片方はクソみたいなクロックスコピー。
パット見では箱の区別は付かない（hatebloドメインでわかることもあるが、独自ドメイン仕様の方がクソ率高い）。
これは靴屋の値付けの失敗じゃん。
クソみたいなクロックスコピーしか作れないのは教育と技術と資源と恥じらいと「既に存る商業メディアや記事、たとえばDPZと同じ基準で戦うんだ」という当然の覚悟が不足してる個人がいるだけであって、それが50円で道端ダンボールセールだったら別に文句は言わないし、ベランダ履き用に買うかもしれない。
はてなブックマーク - 人気エントリー - はてなニュース - http://b.hatena.ne.jp/hotentry/%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9
これとか見る限り、まだ情報の質に対する志向はあるわけじゃん。はてなニュース頑張ってるよ。キュレーションメディアの肥壺にもプレスリリース垂れ流しの怠慢にも落ちずにここ2年ほどのオウンドクソメディアウェーブを善く乗り切ったよ。
このままの棚作りで良しとは思ってないだろ？
