  |
はてなキーワード: 新サービスとは
初増田です。
はてブで出ていた疑問に対して分かる/できる範囲でこた…推測してみます。
耐えれない若手は辞めて行きます。長く居過ぎたり家庭を持つと辞めようにも辞めれませんが。
子会社の子会社とか。○○センタ、って名前で乱立する謎の部署のことかもしれません。（特定回避のために会社表記？）
無駄なことをしている理由は、非効率化により業務量を水増しし、グループ全体の仕事（社員）を減らさないためです。
労組が非常に強く、採用凍結前までに異常に増えた社員を辞めさせられず、どうにかして収容する組織と仕事を作る必要があります。
（給料自体は一定年齢以上は2,3割カットしたようです……それでも、こういった仕事・組織でも年収600～800万は貰えるようですが。）
ただ、それでも決裁リレー（ミニ）は有りますし、こういった人達（組織）へ与える仕事を無から作り出す仕事をさせられたりと大なり小なり闇を抱えてますが。
日常生活・企業活動と切っても切り離せないインフラを提供しているグループなので…
膨れ上がった人件費は全部原価の中に入れて、その上に適当な額の利益を積んだ上で皆様に提供しています。
一応民営化されていますが日本全国で（ほぼ）独占的にサービス提供しているため、まず潰れません。
地域単位では競合事業者はいますが、こちらが全国レベルでサービス提供しているため、設備・運用のボリュームディスカウントが激烈に効いており、
どれだけ無駄のある運営をしていても、かなり良い勝負になっているか、悪いことにこちらが上回っています。
新サービスの研究開発などは、親会社が全部やってくれるのでその成果提供を受けて実際に展開するだけでよかったりして、そういった投資が必要ないのも有るでしょう。
俺が古参だからかも知れないけど、リリースが新しいもののほうが「使ってない」感強い。
一番生き残ってるのが一番古いサービスってどうなんだろうな。
2014以降にリリースされた大承認・Quyo・大チェッカーなんかは、久々の新サービスって謳われた割に使ってる人がまわりにいない。
それどころかたまに遊ぶはてなユーザーの友人に聞いても「何それ」なんて返ってくる。
関西在住。大学時代から10年以上TBSラジオをpodcastで聴きつづけてきた。
今回のpodcast終了の発表で、twitterのタイムラインは悲鳴で埋まった。私も悲鳴を上げたうちの一人だ。
新サービスのストリーミングを試したが、失敗の予感しかしないので理由を書く。
TBSラジオを愛するリスナーの一人として、改善を願っています。
悪いところ
飛行機内、新幹線での移動中、地下鉄、海外旅行中などではそもそも聴けなくなる。
・iPodやタブレット端末など、WiFi以外の通信が出来ないものは外出中聴けなくなる。
上と同じ理由。
・移動中に聞くとパケットを圧迫する
podcastは通学中、出勤中、ランニング中などに聴く人が多いと思う。ヘビーリスナーほど通信費がかかる。
・ながら聴きがしにくくなる
podcastアプリならバックグラウンド再生しながらゲーム、ブラウジングなどが可能だったが、プラウザでストリーミングを開いている状態だと、気になったキーワードを即検索したりしにくい。
・お気に入りを保存しておけない
無理だよね。。
無理だよね。。。
・倍速再生出来ない
いつも1.5倍速で聴いてるので、もう普通の速度だとスローに聞こえて苦痛。
・会員登録しないと全部聴けない
いいところ
・一週間以上たっても消えないでアーカイブが残る
ありがたい。podcastも昔はこうだったんだけどね。
利用者からすると、圧倒的に出来ることが少なくなり、利便性がさがってしまう。
10年以上聞き続けてきた私でさえ、この不便さに耐えて継続して聞き続けられるか不安だ。
この知らせを聞いて、自分がラジオリスナーではなくてpodcastリスナーだったんだなあと気がついた。
利用者の利便性を下げる独自のプラットホームへと引っ越しして、マネタイズに成功した例はあまり多くない気がする。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
2月26日から、イオンモバイルの新サービスが始まるということで期待していたし、申し込もうと思っていたのだが、初日からトラブルが続いてて、入会手続きに大分時間がかかっているよう。
ネットで調べてみたところ、申込内容をセンターにFAXで送り、センターで申込内容を手入力で処理しているようだ。
また、とあるブログで、申込に行った人が店員に聞いたこととして書かれていたことだが、「1日あたり1店舗につき1人くらいのペースで開通してるようです」とのこと。
イオンモバイルの公式のTwitterアカウントでは、スタッフを増員して対応するとしているが、今後どれだけ申し込みの処理を捌けるようになるのか。
希望する客には、自分で開通作業出来るようにした方がいいのではないかと思うのだが、今後改善されるだろうか。
料金も安いし、余った通信容量を繰り越せるなど、なかなかいいサービスなので、このまま消えてしまうなんてことがなければいいなと思う。
テロがなくならない本当の理由は、世界を変えるためには選挙に行くよりもテロをしたほうが効率的だからである。
しかしながら、テロなどしたってそうそう世界は変わるわけはなく、選挙に行くより少しマシという程度なわけだが、これは厳然とした事実だ。
私の印象だと、選挙制度というものは民意を抽出する手段として不十分だ。
選挙とは、民意を抽出する手段の一つにすぎないはずなのに、選挙であることに拘り過ぎてる。
そんな時に、国民全員にアンケートをするなんて、無謀だと思わないか？
10000人もアンケートを取れば十分だと思う。
それで、街角でとっつかまえて即答してもらう。
投票所に来てもらうとなると、強烈にそのサービスに好意的な人と、強烈にそのサービスを嫌う人ばかり投票所にくることになる。
比例代表は○○党にお願いします。って別の党の候補者が言ってるだろ。特に連立を組んでるJ党とK党なんかは。
そういう戦略性も含めて、選挙が公平っていう考え方もあると思うけど、手段と目的を間違えてる感がありゃしないか？
例えば、選挙権をランダムに10000人に与えて、選挙権が与えられた人間はかならず投票所に来なければいけない。来なかったら逮捕。
ランダムに選ぶってところが、システムの開発にお金はかかるだろうけど、それだって今よりはお金も安くあがるだろう。
街頭で支持政党をアンケートして、その割合で議席を振り分けたほうがよっぽど民意だろ。
そりゃ、街に出てるリア充と出ないひきこもりで支持政党が極端に違うってこともありえるから、街頭調査という方法が正しいかは検証の余地はあるだろうけど。
あるいは、間接民主制なんかやめて、A法案に賛成か反対かをメールで国民全員に送りつけて返信してもらえばいい。
あ、でもそうするとワタミみたいな会社だと社員全員会議室に集められて、上司の監督の元で投票させられちゃうだろうな。ダメだこりゃ。
あくまで選挙によるということを重要視する価値観は、古代ギリシャのなかでしか通用しない。
イケメン無罪とか、バイセクシャルが普通とか、そういう価値観までひっくるめた、文脈のなかでは、選挙で選ぶことが善なのだろうけど、現代においては、イケメンだって犯罪を犯せば償わなければいけないし、バイセクシャルは少数派だ。
選挙が絶対という考えだけが残っているけど、上記の通り、民意を抽出する手段としては不完全であることこの上ない。
相撲で白黒つける政治や、亀の甲羅を焼いてひび割れの具合で政治するよりは少しマシであるが、その程度でしかない。
バーッカじゃねーの？
相撲で決着っていいよな。
若いほうが強いだろうし。
★“リニアの「速さ」は、出張には中途半端かも？：日経ビジネスオンライン”
の記事内に「新幹線に会議室を作ればヒットする」と書いてあった。
また、企業重役の移動時間内に、ベンチャー企業が「ハコ乗り」して、企業重役相手にプレゼンする新サービスを、東京のハイヤー会社が始めたらしい。
★博多⇒東京の上り「のぞみ」１６号車指定席の一部列車を「プレゼンテーション・モニター車両」にしてみてはどうか？
名古屋⇒新横浜間（「のぞみ」の次停車駅が最も長くなる区間）に、企業が１６号車の数十名にプレゼンテーションや試供品プレゼントやアンケートを行う。
乗客は企業プレゼンを聞いたり、アンケートに協力したりする代わりに、運賃を５，０００円割り引いてもらう。
JR東海は、乗客への割引分＋αを、企業から場所代として徴収するビジネスモデル。
★「なぜ上り１６号車か？」と言えば、プレゼンテーターが最も東京寄り（つまり、運転席側）でプレゼンするため。
途中号車だと、プレゼンテーターの場所を、「トイレに行く人」とか「号車を移動する人」が邪魔してしまう。
「なぜ博多発列車か？」と言えば、少しでも協力いただける乗客を確保したいため。
★企業が一般人を集めてモニターとかアンケートとかテスト品品評会とか開く場合、普通相場として５，０００円程度を参加者に支払っている。
そう考えたら、「モニター等に協力すれば、５，０００円割引」というのは、相場に合っている
★例えば、東京駅に２１時頃到着する博多発「のぞみ」車内で、キリンビールが新しいビールのサンプルを配って、
乗客から味やパッケージデザインについて意見を募る、そういう使い方
或いは、保険会社が１６号車乗客に新しい保険のプレゼンするとか、携帯会社が１６号車乗客に新しいスマホをプレゼンするとか、
★企業のモニターとかアンケートとかって、参加者が主婦とかの「有閑者」に偏りがち。
忙しいビジネスパーソンに対して、なかなか意見を募る場が存在しない。
ビジネスパーソンのモニター意見を集約できる場として、「のぞみ１６号車」は貴重
★プレゼンカーが軌道に乗れば、「プレゼン対象乗客は女性限定」とか「６０歳以上限定」とか
「０～６歳の子供がいる人限定」のような「顧客属性を限定」するようにすれば、より突っ込んだプレゼンが成立する
★LCCでもプレゼン・フライトは成立しえるが、LCCはあまりカネ持っている人は乗らないからなあ。
レガシー航空会社が、プレゼンフライトみたいなことをする勇気があるかどうか。
★ウィーラー・トラベルなどの高速バスで、カネのない若者相手のプレゼンバスも、成立するといえば成立する。乗客は皆ヒマそうだし。
「東京⇒大阪昼行バスで、アンケートとか座談会に協力いただければ、運賃タダにします」バスがあれば、相当ヒットするだろうなあ。
東京～大阪バスで「アンケートに協力すれば無料バス」はさすがに難しいが、
「都内～成田空港バス」「大阪市内～関西空港バス」ならば、アンケートやプレゼンに協力してくれるならタダ、というバスは成立しそうな気がする。
自身、年に数回やっている事なのでメモとして残しておく。 ただし Win 8 以降に関しては当てはまらない事も有るかも知れない。
１． 下記をあらかじめダウンロードしておき、CD-RW や USB メモリに書き込んでおく。
ａ．最新の Windows サービスパック（Windows インストールメディアが最新サービスパックを含んでいればもちろん不要）
ｂ．チップセットドライバ（Intel の場合は インテル・チップセット・ソフトウェア・インストール・ユーティリティー http://www.intel.com/p/ja_JP/support/highlights/sftwr-prod/inf ）
ｃ．SCSI or AHCI ドライバ（Win Vista 以降は標準で AHCI に対応したので不要）
ｄ．対応する最新の DirectX http://support.microsoft.com/kb/179113/ja （なお AMD 製ビデオデバイスの場合は不適合でブルースクリーンとなる事がある）
ｅ．各種デバイスドライバ（特にビデオと有線ネットワークは必須）
２． BIOS 設定を確認する。 AHCI が使えるなら、AHCI にしておく。 ブート順序（どのディスク／デバイスから起動するか）も設定する。
この際、起動デバイスをどのようにパーティショニング（分割）するかを考え、起動用パーティションを確保する。 既存のパーティションをそのまま使う人もいるが、面倒であってもいったんパーティションを削除して新たに確保し直す事を推奨する。
これは Windows サービスパックや他ドライバよりも先にインストールする事が推奨される。
http://www.intel.com/jp/support/chipsets/inf/sb/CS-009270.htm
他に何かをインストールしていると、それが要因となってサービスパックのインストールに失敗する事例があるため、チップセットドライバの次に優先的にインストールする事を推奨する。
Win XP の頃まではビデオ・オーディオドライバよりも先にインストールする事が推奨されていたが、Vista 以降はマザーボードの事情により左右されるようになったので、この時点でインストールしなければならないとは言い切れない。 DirectX の最適なインストール時点は、個々の事情に合わせて調査する必要がある。
ちなみに現在、DirectX は Web インストーラ http://www.microsoft.com/ja-jp/download/details.aspx?id=35 が主流であるため、８．項以降にインストールしても問題は無いのだろうと推察される。
７． ビデオデバイスがあれば装着し、そのドライバをインストールする。 場合によっては適宜設定を行う。
Windows はもともと標準ビデオドライバを内蔵しているが、（たとえオンボードビデオであっても）より適合したドライバでそれを上書きする事を推奨する。
８． オンボードデバイス（オーディオ、有線ネットワークなど）のドライバをインストールする。 また、後のトラブルを避けるために、ネットワーク名を半角英数字だけに変更する事を推奨する（※１）。
９． その他のデバイスを装着し、ドライバをインストールする。
要するに、ハードウェア・デバイスのインストール順序は、より「内蔵」度の高いものから、低いものへと行うのが原則である。
Windows の状態によっては、Windows アップデート自体がすぐに使えない事がある。 そのような場合、Windows アップデートを行おうとすると、Windows から指示が出されるので、それに従う。
ここで失敗する場合、インターネット接続に問題がある可能性が考えられる。 ネットワーク設定を確認する。
メーカー製 PC におけるプリインストール Windows の場合は不要。
http://windows.microsoft.com/ja-jp/windows/genuine たとえメーカー製 PC であっても、中古品の場合は検証を推奨する。
１３． Windows アップデートで、まず Internet Explorer のバージョンを上げておく。
先にこれをやっておく事で、古い IE の余計なアップデートパッチを適用しなくて済む。
１５． この時点で、システムのバックアップを作っておく事を推奨する。
以上
※１
実際に起きた問題例として、サードパーティ製のファイアウォール・ソフトが、日本語を含むネットワーク・アダプタ名を認識出来なかった、という事があった。
これに限らず、海外製のソフトを使う事が多い場合、フォルダ名やファイル名などは、極力、半角英数字だけを使うようにした方がトラブルを避けられる。 本来、そうであってはならない事ではあるが。
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
ちょっと追記も含めて書きなおした。
・メールがLINEやその他のインスタントメッセンジャーアプリに置き換わる。
・インスタントメッセンジャーのなかにも、迷惑メールにあたるものが来るようになる。
・最初はSNSが統合され、次第にタクシー配車や、レストラン検索、地図アプリなど実用的なアプリがメッセンジャーに内包されていく。
・売りたい人と買いたい人をつなぐ、楽天的なサービスが拡充。工場直販が増加。中抜き専門の中間業者が死んでいく。
・ここまで完全無料。クリックして処理完了までの間、広告がちらっと見えるだけ。
・銀行口座直結でのオンライン決済システムや送金システムを内包。決済や送金用のオンライン上に少額口座が開けるように。
・最初はバーコード認証だったが、次第に非接触式ICでスピーディーに。
・普及はクレジット決済システムが普及していない途上国が先行。特に、中国では検閲を煙たがりクローズドなSNSに走る人が続出。
・オープンなインターネットを志向する先進国では普及送れる。グーグル帝国の支配は緩まず。
・当然、中国当局は検閲してる。それでも追いつかなくなるほど普及。13億人の会話を全部検閲するには常識で考えて無理。
・バーチャル通貨、バーチャルクレジットカードを経由して、金貸しまでできるようになる。ノウハウを活かして、利用者同士で借りたい人と貸したい人をつなぎまくる。
・ここまでも完全無料。クリックして処理完了までの間、広告がちらっと見えるだけ。
・中国当局、銀行もクレジットカード会社もぶっ潰す可能性に今頃気づく。当然規制しようとするが、大きすぎて潰せない。国家戦略として積極的に輸出する道を選ぶ。
・Google焦る。矢継ぎ早にパクリまくる。新サービスの会社を買収しまくる。
・Apple、iPhoneにNFC搭載。日本では思ったほど普及していかない。iTunes経由じゃないとチャージ出来ないSuicaはやっぱり使いづらい。
・意外と信販会社は生き残る。2020年でも米国はクレジットカード会社の天下。貧乏人は安いし便利だけど大雑把すぎて不具合だらけの中華アプリとGoogle謹製アプリは庶民。中間層から富裕層はみなアメリカンエキスプレス。
・LINEが頑張るが、前例のない新ビジネスはすべて所管省庁からお叱りを受けてすぐ撤退。スタンプがGifアニメになる程度の進化にとどまる。
・日本の戦略はクールジャパン、HENTAIの国の路線。男の娘だからロリじゃありません！的な寝言を言い続ける。
・中国がITで躍進。韓国とインドが米国のIT下請け。GoogleとAppleの帝国の支配力は弱まるが、それでも米国は好景気続く。金融業も潤って100年後も金持ち。
・米国と中国がネットの2大勢力としてしのぎを削っている頃、経産省が国産スマホOSの開発に乗り出す。富士通に投げる。
・国民健康保険と住基ネットカードと年金手帳と運転免許証を統合した情報端末！というのが売り。
・年金と健康保険は厚労省、運転免許は内閣府ということで折り合いがつかず、頓挫。
・運転免許情報と住基ネット情報だけ入った端末がdocomoから発売。結局、OSはAndroid。ただし、役所じゃないとOSはアップデート出来ないという仕様。
・21世紀はイスラムが躍進するかのように見えたが、そんなに躍進しない。利権を争ってイスラム国同士でもめる。宗派同士の争いを煽って収集がつかない。
・中華アプリの決済システムはイスラム法に抵触しないと中国人が売り込む。米国がイスラム過激派の口座を差し押さえるとかなんとかで中華アプリの使用停止に乗り出したり、出来なかったり。
・日本、左派が政権をとり、日米安保を捨て、中韓ともっと…みたいな寝言を言う。
・その矢先、中国と米国が金持ち同士仲良くやろうぜと接近。日本と韓国が困る。台湾、もっと困る。
・いつか破裂すると言われ続けた中国経済は順調に成長、急激な高齢化だけが悩み。
ど素人でもプロ並みのチラシが作れてしまう…「Picky-Pics」がデザイナー殺しな件 : まだ東京で消耗してるの？
約5万点の素材からドラッグするだけで、プロ並みのデザインが仕上がる新サービス “Picky-Pics (ピッキーピックス)”、本日リリースです！ (フェンリル | デベロッパーズブログ)
無料でモリサワフォント18書体やレイアウト・素材を使ってプロ並みデザインができる「Picky-Pics」 - GIGAZINE
むかしMacOS用ソフトで、本当にチラシやハガキのレイアウトを適当にランダムで作ってくれる海外製ソフトがあった。
そこは公開辞めて単なるデザイン事務所になってしまったけど、名前が思い出せない。（OSX以降は動かなくなってしまい、ソフトも捨ててしまったんで）
要するに、増田速報のサイト上にある記事タイトルをクリックすると元記事に飛ぶ仕様。
https://twitter.com/ottatiyarou2/status/478140936484945921
今まで無断転載されてた記事もサイト上からは消えてるっぽいかな。きちんと掘ってはいないけど、たぶん。
はてなが管理してるはてなブログ上でこうも堂々と著作権侵害ってようやるわと思ってたけど、運営から警告来たのかな。
あいかわらずシコシコ転載してる増田速報は早く潰れてほしいも端緒になったかもしれないね。
とりあえずめでたい。
ということで今後は、はてなのまとめとかいう無断転載サイトを掘る作業に戻ります。
（情強の皆様は知ってると思いますが念のため、50ブクマ以上の増田新着記事チェックは以下からどうぞ。）
http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fanond.hatelabo.jp%2F&sort=hot&of=0&threshold=50
ところで同じ作者(id:ottati)のリリースしたガゾウテレビとかいう新サービスも思いっきり著作権侵害ですね。
http://b.hatena.ne.jp/entry/ottati.hatenablog.com/entry/2014/06/15/105623
ちなみに画像の無断転載は文章よりも言い逃れ聞かないので警告なしに訴えられても知らんよ。
はてなブログでの揉め事などを見て、「繰り返している」と感じる古参がいる。
繰り返すというのは素晴らしいこと。
そもそも人類の歴史というのは、同じ所をぐるぐると回りながら、一周するごとに1ミリずつ積み上げていく知恵の蓄積であったはずだ。
ほむらは何度でも同じことを繰り返し繰り返し、前回とは少しだけ違う結末へ辿り着いてはまた繰り返して前へ進もうとした。
２年４ヶ月前、はてなが開始した新サービスは、タイムリープであった。
終焉を迎えつつあったはてなのブログ文化であったが、気が付いたらそこには既視感のある光景が広がっていた。
どこかで見たような、それでいて何かが少し違う風景。
繰り返しの引き金を引いたはてな以外でも、前回の記憶を残している人がいる。
彼の者の到来によって限界集落と化し、終焉を迎えつつあったはてなは、繰り返すことで物語を紡ぎ続けようとしたのだ。
