  |
はてなキーワード: アーキテクチャとは
パスカルアーキテクチャ、DirectX3D 12･Vulkan世代のプロセッサのTegra X2カスタム、CPUがDenverクアッドコア、メモリ４Ｇ～８Ｇの携帯できる据え置きゲーム機でもありかなとは思う。
おそらく携帯ゲーム機としては、発熱やバッテリーの問題から今は出せないハイスペックマシンを持ち運びも可能な据え置きとして出すのだろう。
据え置き機のハイスペックモードでは電源供給・高速駆動させファン冷却で発熱を処理、携帯モードでは省エネモードで駆動させたりするかもしれない。
おそらく携帯ゲーム機としては発熱があるだろうから本体から手が遠い位置にできる分離型リモコンは一石二鳥のアイデアでもあったのだろう。
おそらく二年毎程度サイクルで半導体の微細化省エネ、低発熱、低コスト化が進み新たなゲーム機が出てくるのかもしれない。
例えば、まず持ち運び出来る据え置きとしてNintendo Switch、２年後程度でSwitchの持ち運びモードで動く携帯ゲーム機、さらに２年後にはSwitchのハイスペックモードで動く携帯ゲーム機として。
そうすることで据え置き機のソフトが携帯ゲーム機のスタートダッシュに必要なソフトラインナップとして安心して技術開発できる。 さらに背後にいるこれからさらにハイスペックになっていく未来のスマホ市場という巨大な虎の威を前倒しで今借りられる。
それと共に、携帯ゲーム機のソフトをそのまま、互換上位グラフィックのソフトとして据え置きのNintendo Switchのラインナップに並べられる利点がある。
携帯のゲーム機と据え置きゲーム機が同じソフトを挿して遊べる互換の可能性が、ソフトの相互供給としての可能性が考えられるのだ。
パスカルアーキテクチャを使ったのであれば、逆に携帯ゲーム機が発買されるまではもしかしたらあと2年ぐらい待つのかもしれないとも言える。
もう夏休みも終盤だ。インターネットには様々なガキが溢れている。その昔は夏厨だとかそういった呼称が振られていたがそれも今は昔だ。時代が過ぎゆくのは早い。
私は情報社会の端くれで働いているエンジニアってやつだ。一応それなりに楽しく仕事ができているし、いわゆるWeb系と呼ばれるキラキラした業界で背伸びせずに働いている。所得は美味い。
私が子供だった頃と比べると社会は大きく変わった。素晴らしい変革だ。
コンピューターは安価に手に入るし、プログラミングだってすぐできる。ChromeさえあればリッチなWebサービスだってすぐ作れてしまう。本当に良い時代だ。
あの時代から比べるとプログラミングは身近になったのではないだろうか。なにせ近頃はプログラミングを教える塾もあると聞く。
そんな社会を見渡すとプログラマに憧れるガキがそれなりに居る。
やれLife is TechだのTech Kids CAMPだのキラキラした世界でキラキラ刺激を受けて意識高い系に若くして成り上がっている。
そんな君らに向けて言いたいことというか、老婆心からくる小言を書き残しておきたいと思い筆を執った。
まず最初に、強い言葉を意図して使っている事をお詫びしたい。だが許して欲しい。こういう言葉遣いの方が目立つ。一種の炎上商法だ。増田の醍醐味だと思って欲しい。
あなた達はとても若い。若い故に敏感だ。社会にすぐ影響されてしまう。
もちろんここもそういった影響を与えようとするインターネットの一つだ。悪い大人の妄言だ。
影響を受けることは悪いことではない。まずはたくさんの意見を知り自分なりの考えを見つけて欲しい。
「自己発信」という名のマウンティングをして、作ってもいないのに「○○の取り組みをしています」だの「仲間で集まって起業！」だの。「生産しろ！コード書け！」と説教したくもなるが今回はやめておこう。
大人な私から見れば君らの猿真似はヌルい。ヌルすぎる。そんな君らに社会の戦い方を伝授しよう。
IT業界の戦い方はシンプルだ。全てがマウンティングで出来ている。
知能で殴るかセンスで殴るかの二択だ。
前者は簡単だ。コードで殴れ。数学で殴れ。アーキテクチャで殴れ。
本当に君がそれを得意とするのならどこまででも目指せるだろう。
しかしながら本当に強い奴はだいたいアスペだ。どこかの頭のネジがぶっ飛んでいる最高の連中だ。
自分が素質があると思うならこの方法で戦え。どこまでも走っていけ。
後者はいわゆるキラキラしたエンジニアだ。センスで殴れ。コミュ力で殴れ。プレゼンで殴れ。シンギュラリティーとイノベーションで殴れ。
プレゼンが上手くて、人に取り入るのが上手い。頭が回る。
しかしそれは全て単純なマウンティングだ。自分がなるべくかっこ良く見えるように演出に演出を重ねているだけだ。騙されるな。見抜け。
上手く発信して、力を持った奴にすり寄れ。そしてなるべく話を聞け。連絡はマメにしろ。
君がインスタを使いこなせていると思うならきっと素質がある。戦え。
そして覚えておいて欲しい。
だが覚えておいて欲しい。どいつもこいつもこんな戦い方をしているから抜け道がある。
真に強い奴は上手く目立たず上手く有名になる。上手く立ちまわる。上手いコードを書く。
若いうちはマウンティングしておけば立ち回れる。しかしこの社会は若者だけでは構成されていない。金を動かせる奴は大抵油ののった連中だ。
自分にあった戦い方を見つけて欲しい。そしてIT社会をIT業界をもっと面白くして欲しい。
君らが私達おっさんの脅威になることを願ってやまない。
後なんかweb系の企業がgolang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線。
今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか！
どっちもユーザーです！（ペアーズでは3名ぐらい逢った、メルカリではバイクとMacbook Air売ったなー。）
ポケモンGoとかやんねーし、地味に自分がよく使っているアプリやサービスから成功パターンを得るのがいいのかなぁ
なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが（CtoCなんだから当たり前か、何いってんだ）
人とコンバージョンしたいです。
別に大手企業の上っ面だけのサービス愛の話をするわけじゃない。
サービス愛ってなんなのかずっと気になってる。
けどうちの会社のサービス全然触ってなくて、サービス愛がない、それじゃサービス指向の考え方ができないだろとか、そんな基準で落とされた。
アーキテクチャというか技術面では凄くマッチングしてて、本人もしっかり把握して応募してくれてた。
サービスの表側の機能への愛じゃなくて、裏側の技術への愛も含めてサービス愛だと僕はずっと思ってる。
あとサービス指向ができるとか言って採用されたのが尽くコンピュータアーキテクチャのコの字も知らない奴ばかりでうんざりしてるのもある。
表側だけ見てサービス愛してますとか言われても、現状に満足して新しいものなんて生み出せないでしょ。
むしろ足手まとい。
そうやって失敗してる企業が山程あるというのに、何故みんな学ばないんだろうか。
読んでもらえるかどうかわからないが，一応IDコールしてみる。＞ id:NOV1975氏
この記事，
という点において，「ウォーターフォールとアジャイルはどう違うのか」という問題が混然一体となって語られてて，ちょっとわかりにくい気がした。
そこで，この3つの論点について，自分なりの理解でアジャイルとウォーターフォールの違い（あるいは違わないこと）を書いてみる。
まず，OJTとOffJT(研修，勉強会等)の組み合わせで育てる，というレベルの話では，ウォーターフォールもアジャイルもあまり違いはない。
また，スキルの広げ方についても，ウォーターフォールとアジャイルであまり違いはないと思う。NOV1975氏は，
プログラミングって世界はわりと想像できるんですよね。もうちょっと大きいアーキテクチャの話とか、業務要件の落としこみの部分とかをどういうプロセスで身につけて成長していくんだろうか。
と書いているが，アジャイルでも，最初は既存のものの改修から始めてもらって，新機能の追加（ここで要件落としこみが入る），新プロダクトの設計（ここでアーキテクチャの話が入る），みたいに，徐々に範囲を広げていく感じだと思う。
ただアジャイルのチームでは，最初の「既存のものの改修」の段階から，運用の稼働を減らすことを意識し，テストやデプロイの自動化をしてもらうことになるはず。運用を意識する，という点では，運用系の機能追加（例：監視機能の強化）もやってもらうことになる。これをどこに入れるかは悩ましいけど，比較的初期段階で経験することが多いのでは。
手法レベルでは，アジャイルで特徴的なのは，OJTの手法としてwonodas氏の言うところのレビューやペア・プログラミングを重視している点ではないかと思う。このへんはwwolf氏のあげた「アプレンティスシップ・パターン」にもあるのではないかと思うが，職人と弟子の関係で，日頃の行動の中である種「背中を見せる」感じで（教えるというより）学ばせる感じになると思う。
これは（NOV1975氏自身が書いている通り）ウォーターフォールもアジャイルも変わらないと思う。顧客に提示する価格の中に教育も含まれることになる。
ここで重要なのは，アジャイルの場合教育は顧客にとっても価値が大きい点だと思う。なぜならアジャイルのチームは，システムを開発するだけでなく，運用も行うのが基本。運用の中で継続的に改造や機能追加を行うことで，顧客にとってのシステムの価値を高めていくのがアジャイルの真の意義。そういう活動を続けるために，教育に投資することは顧客にとっても価値があるはず。
話はそれるが，ここで少し面白いなと思ったのは，「属人性」の話。アジャイルのチームでは「属人性」を避ける文化があると思う。だがそれはチーム内の話であって，外から見ると同じチームに開発と運用を依頼することは，チームとしては「替え」がききにくくなる気がする。そのあたりを現状どう解決しているのかはちょっと興味がある。
これはもう，向いてない人はチームから出て行ってもらうのがお互いのため，というのがアジャイルのやり方だと思う。というかそもそもそういう人をできるだけ入れない。なぜならチームの文化が壊れるから。
正直，そういう人でもウォーターフォールだと活きる道がある，というNOV1975氏の考えには納得できないが，なんとか活かしたいという心情は理解できる。なので少し考えてみたけど，人手の作業が最後まで残りそうな QA (Quality Assurance) やマニュアル作成あたりに行ってもらうしかないのではないだろうか。個人的には，向いてない人が向いてない業界にいるのは本人のためにもならないとは思うけれど。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
言語やフレームワークを先に考えるんじゃなくて、実現したいコト／解決したいコトが先でそれをとことん突き詰めて考えるコトが大事。
それがちょっとだけ良くなる程度のものだったら、そもそもそれはあまり問題では無いのかもしれないし、単純に当事者意識や情熱がなくてただ普段と違うコトがしたいだけなのかもしれない。
例えば、車輪のようなものは一見するとちょっとだけ良くなる程度のもののように思えるけれど、突き詰めて考えるとちょっとだけ良くなる類のものではなくて、シンプルだけれどすごく応用範囲の広い要となるものだったりするよね。
その応用範囲までもよく考えたものを、最初の段階から応用範囲に至るまでを効率よく実現するために、何を選択するかをよく考えよう。
海外の有名な会社が作ってるようなものが簡単に作れるからとかあの会社も使ってるから、ありとあらゆる部品が揃ってるや既に知ってるものだから効率が良いなんてものは、参考にはしても選択の理由にするべきものであってはいけない。
そんなコトを理由にしたら、私は自分の頭で考える力も何かを生み出す能力も持ち合わせていません。なんて宣言してるようなものなんだよ。
問題が起きたらまた一から作り直せば良いなんてのは大抵失敗するし、そのコストが支払えない場合は継接ぎだらけで局所的な問題が頻発するものになるコトが多い。そして、最初に感じた効率の良さなんてものはいつの間にか消え去ってしまってる。
必要な部品は何なのかをきちんと洗い出して、それらの部品を柔軟に組み合わせられて効率的に動かせるものを選択するコトなんだ。もしもそれらが存在しないなら、それらも含めて作り出すコトも視野に入れておこう。
こんなコトを言うとオレオレかよなんて声が聞こえてくるコトもあるけれど、初めからそうじゃないものは存在しないんだよ。誰かが作り出したから存在してるんだ。だからやると決めたらきちんとアピールしてディスカッションして継続的に改善しよう。
そんな風に世の中に数多くいる、言語やフレームワーク、アルゴリズム、UI、UX、システムアーキテクチャの設計開発研究をしている優秀な人たちの思考を真似てみよう。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
女が恋愛だ結婚だで与えてくれるらしい幸せとかって、リア充ノリすぎねーか？
短歌の返答とかは昔すぎるとしても、宗教的なノリとか、連理の枝とか、ある程度ノリとしては文学的だったように思う。
でさ。現在女が与えるらしい恋愛の幸せとかって、ノリがリア充すぎる。
そういうリア充ノリ的な幸せを楽しめる男ってどれくらいいるんだろう。
男の感じる楽しさとかって、どっちかっつーと、アーキテクチャー的な。キモオタが電車撮ったり、ゲームの攻略したりみたいなノリじゃん。８割がたの男の楽しみってそうじゃねーかな。
だけど、ドキュンみたいな頭足りない奴はそういう楽しみできないから、リアル充ノリでOKなのは分かる。
イケメンはスクールカーストとかイケメン枠として女が流れてくるから、リア充ノリ楽しめなくても女抱けるから、別にリア充ノリは女が勝手に脳内補完するんだろう。
でも、８割方の普通の男は、リア充ノリクッソつまらないと思うんだけど。
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
手持ちのプログラムをちょっと手を加えれば作れそうだったので作ってみた（総工数0.5MH)。最下位２つが404になってたおかげでちょっと変なことになってるけど、だいたいこんなもんかな。いわゆるホッテントリーに上がる記事を大雑把に分けると、
に分かれる（勿論ミックスもあるけど）。諸君が『くだらねー』と思っている、エクセルだの英語だの簿記だのは後者だな。ただ、はてブはSNSとして機能している側面もあるけど、SBMが本来の目的である以上、インフォメーション系の記事も当然上位に上がってくる。まあ、ブコメが盛り上がっている何か？を表示出来るようにしたいんだったら、日曜プログラミングでちょろっと書けば？と思う今日このごろ。
ブログに書くほどの話じゃないので、スペースお借りしますm(_ _)m
テロリストがゲーム機(PS4)のゲーム内チャット機能を使ってるかも、っていう報道が出ている。
この件でPS4を叩いても仕方が無い。というのはPS4に限らずゲーム内のチャットはテロリストが会話を行うのに適した理由がこんなにも多いからだ
会話経路がゲームの数だけ、星の数ほどある。NW的にはPSNを利用していても、プロトコルや暗号化方法はゲーム毎に異なるのでPSNの根っこで監視をしても結局各ゲーム毎に解析方法を作らなければならない。『釣天使』とかかわり合いたいと思うほど諜報機関は暇では無いだろう。
そして、ゲームの数はアーキテクチャの数であり、それぞれ異なる方式で情報が伝達されている。あるゲームではメッセージサーバ集中管理でも、また別のゲームではP2P通信だったりする。それらを複合的に扱っている場合もあるだろう。テロリストとは無関係な第三者のゲーム機をホストとして会話が行われ、運営者側では会話ログを一切持っていない、こんなケースはいくらでもあるだろう。
サイバー犯罪対策法はログ保存を事業者に義務づけているが、P2Pアーキテクチャではそもそも事業者との通信自体が行われていない。
オンラインゲームの運営は常にチーターとの戦いだ。ゲーム運営者はゲーム機とサーバの間の通信が解読されないように暗号化を当然のように行っているし、鍵割れ対策として鍵交換も頻繁に行われている。また、暗号化アルゴリズム自体もカスタマイズしていることが多い。
平文でへろへろとメッセージが飛んで行くEmailとは根本的に設計・運用レベルが異なる。
ゲームの世界はコミュニケーションに使える手段が豊富だ。プレイヤー同士でコミュニケーションが取りやすいようにチャット機能の他にも各種のアクションやメッセージ伝達手段が豊富に用意されているし、符号化の方法さえ決めておけばあらゆるゲーム内のオブジェクトが通信に使える。
ポケモンを繰り出す順番でメッセージを伝えることもできるだろうし、ゲーム内のインクで床に書いても良い。そこから第三者が意味を感知するのはほぼ不可能だ。これらはもちろんログにも残らない。ゲーム内の全行動・全会話（音声含む）を保存しておけるようなリソースはどこの会社も持っていないし、そんなことに浪費しようとすれば株主が黙っては居ないだろう。
ゲーマーは攻略のために「強い目的意識」を持った「物騒な会話」を日常的に行っている。
何時に集合してなんとかを殺す、とか爆弾を仕掛けてXXが通ったら起爆するとか、普通の会話の中ではあんまり出てこないがゲーム内ではごく普通の会話だ。仮に傍受/平文に解読を出来たとしても、どれが善良な市民の会話でどれがテロリストの会話か識別するのは辛いことだろう。
大多数のITエンジニアが通信路暗号化の基盤として信頼していたOpenSSLに巨大な脆弱性"HeartBleed"が昨年発見され、その脆弱性をNSAが事前に把握していた、という昨年の事件はオープンな暗号化基盤さえも国家レベルの諜報機関に対しては大穴が空いている可能性を示唆するものだった。
このような背景の元では、テロリストが「通信の内容」よりも「通信の存在」の秘匿、そして事後の捜査のしづらさを重視したとしても不思議ではない。
ブコメやトラバでも指摘されているが、事後的に平文の会話ログや行動ログを運営会社に提出させることそれ自体は可能だろう。
しかし巨大IT企業や通信会社と比較して捜査慣れ（証拠提出慣れ）していない、しかも英語が十全に通じるか怪しい国にある運営会社からログを入手し、ゲームの仕様に依存するログを読み取る時間と手間を考えたとき、この夢と虚構と暴力の世界は秘密の謀りごとを埋める森として十分な広さがあるように思えるのだ。
Googleの親会社である「Alphabet」の社訓は"Do the right thing"(正しいことをしなさい)らしい。
1.Googleの人たちが情報収集を行うのは、悪いことではない。むしろ、企業サービスを充実させ、ユーザーをより便利にさせるから良いことだ。(right thing)
2.IMEで.ユーザーの入力情報を収集するのだって、ユーザーを便利にする。(right thing)
3.検索情報をかき集め、ユーザーの興味、思想と言った動向を調べるのだって、なんか……いろいろ役に立ちそうじゃん？(right thing)
4.Javascriptとか、そういった独自フレームワークを定義して、それらでシェアを獲得するのだって、より開発者を便利にすることじゃん？(right thing)
5.くまのプーさんだかパンさんだか知らないけどそれを使って、SEOだっけCEOだっけ？に基いて、検索結果をGoogleが定義したものの順に表示するのはいいことじゃん？(right thing)
6.容量無制限で最近話題になったGoogleフォトを人工知能の餌にするのだってユーザーを便利にするじゃん？(right thing)
7.ありとあらゆる情報を獲得して、Googleの決めたこと以外に逆らえなくなっても、Googleはありとあらゆる情報をGoogleが決めた法則や決まり事によってユーザーに提供されるんだ。
それはきっと、ユーザーを便利にしていくことだから素晴らしく、正しい事なんだよ。
皆がGoogleに付き従うことは、国家に付き従うことと違って革命もテロも犯罪すら起こせない。
なぜなら、我々が付き従うGoogleの作ったアーキテクチャは、Googleの作ったプログラムという絶対法則の世界のうえで成り立つのだから。
素晴らしいことじゃないか。
みんなもGoogleに従おう。Googleは"Right thing"を行うんだ。Googleは"Only right thing"を行うわけじゃない。
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
東大基礎科学科卒。過去250～340年間世界の大数学者達が解こうとして解けなかった、世界史的数学難問4つを解き、現在ロシア科学アカデミー数学の部で審査中。マスターした11ヶ国語を駆使したプロの通訳・翻訳家。矛盾だらけの現代物理学を初め、全科学（自然、社会、人文科学）の主だった物を体系的に批判し各々に別体系を提起。各種受験生(医学部、難関大学入試、数学オリンピック、社会人大学院入試、IT関連資格)支援。
■経 歴
2002年 （至現在）セント・クレメンツ国際大学 物理学教授
2001年 英国系セント・クレメンツ大学で数理物理学の博士号取得
2002年 ロシア科学アカデミー・スミルンフ物理学派論文審査員となる
1999年 英国系ウィットフィールド大学でコンピュータ科学人工知能の博士号取得
1991年 （～1993年）University of California、 Irvine人工知能研究所で確率論批判・学習システムの研究
1988年 （～1991年）世界の認知科学の権威ロージャー・シャンクのCognitive Systemsのデータベース研究所IBSで自然言語処理研究
1986年 （～1988年）欧州先端科学研究プロジェクトESPRITにESPRITディレクターとして仏Telemecanique研究所より参加（生産ラインへの人工知能導入の研究）
1985年 西独ジーメンスのミュンヘン研究所で生産ラインへの人工知能導入の研究
1982年 （～1985年）[仏国]世界一速い列車TGVのメーカーAlsthom社の知能ロボット研究所
1981年 （～1982年）[仏国]グルノーブル大学院、ソルボンヌ大学院で通訳の国家免状取得
1980年 （～1981年）[スペイン]マドリード大学院で言語学履修 西国政府給費留学生
■専門分野
数理物理学Ph.D.、コンピュータ科学人工知能Ph.D.、マスターした11カ国語を駆使したプロの通訳・翻訳家
■講演テーマ
「ビジネスマン、文系卒社員に理工系技術と技術的発明を評価できる眼を」
近年世界の大学でビジネス志向の学生向けに、理系の技術的な事がある程度分かるためのカリキュラム改変が始まっている。しかし申し訳程度であり、また理系の拠って立つ数学物理学の科学理論自体に欠陥が有る事が最近明らかとなっているため、正しい数学と物理学の粋を伝授し、文系でも本物の理系技術評価が出来るように支援する。
「英語を完璧に&現地語（非英語）を或る程度使えるマネジャー急遽創出と、社員の中から各国語通訳をネーティブに肉薄する敏捷性と正確さで急遽育成を支援」
海外のプロジェクトや企業と折衝するとき、英語がネーティブ並みであったり、現地語を自社のディレクター自身がある程度こなせるか、英語、現地語につきネーティブ並みの社員が通訳出来ると先方との話が大きく好転する場合が少なくない。それを本当に実現する教育訓練を私は提供できる。平明に説明し、実体験をしてみたい方がいらっしゃるなら講演会場で手解きをしてみたい。
「発見された言語学理論と外国語訓練方法論を基に、文科省と英会話学校の英語教育訓練方法論の根本的誤りの中枢を詳説」
統語法意味論、文脈意味論、実世界意味論の3レベルで進展するネーティブの母国語習得過程の中、言語能力の真の中枢は解説も無しに親の喋るのを聴いているだけで分かるようになる統語法的意味把握能力で、これは文法用語を全く使っていなくても徹底した文法訓練となっている。ネーティブが敏捷性、精度の点で万全であり、先ず文法的間違いをすることはない理由はここにある。全文法分野について書き換え問題の「即聞即答訓練」を一気に中学生以上の年齢の人に施し、全文法のビビッドな一覧性を習得させるとネーティブに肉薄する敏捷性と精度で外国語を使いこなせるようになることが発見された。
「＜証明された欠陥数学＞ 確率統計と微積分学のビジネス、金融工学、保険業界での使用に対する警告と、それに取って代る新数学体系」
我々物理世界は離散値の世界であることが原因で、物理世界に住む人間の頭脳が考え出した数学の中で連続実数値に基づく確率統計学と微積分学だけが欠陥数学として発現していることが証明された。決して建設的な予測をすることができず、崩壊していく事象に後ろ向きにしか適用できず、せいぜいリスク管理にしか使い道の無い確率統計学をビジネス学の分野では金科玉条の如く信用し積極的やり方で利用しているが、ここに「理論」と現実との間に大きな食い違いが生じている点に警告を発したい。そのためそれに取って代る新数学体系を提起する。全てを分かり易く解説します。
「新エネルギー・エコ向けの発想を大転回した技術的な重要な発明を提起」
20世紀初頭に数理物理学者Henri Poincareは二体問題までは解けるが三体問題(三つの星が互いに重力で引き合いながら運動している時の時々刻々の位置を計算で求める事)以上は微積分学を使って解く事が出来ない事を証明した。これは無限小差分を使う微積分は計算式中で交差する項をほぼ同等とみなして相殺してしまうため、作用反作用の法則(F1*v1=-F2*v2)の取り違い(F1=-F2が作用反作用の法則であると圧倒的多数が信じている)と相俟って、交互に対称な運動しか記述できないため、対称性の有る二体までは記述できても対称性のない三体以上は記述できないためである。この欠陥数学微積分を基に二体までは「エネルギー保存則」を証明したものの三体以上の「エネルギー保存則」は本来的に証明不可能であることが明らかと成った。現に永久磁石がエネルギー保存則を大きく超えることが実証され始めている。それらの実験につき具体的に物理学の素人の方々にも分かりやすく報告したい。
「世界史的体系的誤りに迷い込んだ現代物理学とその使用者への警告とそれに取って代る新物理学」
現代物理学の二本柱、量子力学と相対論の中、量子力学は水素原子の原子核と軌道電子の関係説明を辛うじて試みただけで、水素原子より複雑な原子や分子の構造の説明に実は悉く失敗し、繰り込み・摂動理論はその失敗を隠すため後に持込まれた。軌道電子は光速に比べ無視できぬ速度でクーロン力で原子核に引かれて急カーブしながら等速加速度円運動、大量のエネルギーを消費するが、半永久的に軌道を回る。しかしシュレーディンガーの波動方程式(その波動関数とその共役関数の積は確率)はエネルギー消費に一切言及せず、エネルギー・レベルが一定に保たれるという明らかに矛盾した論を展開する。また確率を持ち込んだからには、エントロピー単調増大法則がここに適用され、水素原子は瞬時に粉々に飛び散らなければならぬ現実に反する二つ目の重大矛盾に遭遇するが、これもシュレーディンガーは見てみぬ振りをする。つまり水素原子の構造の説明にすら量子力学は完全に失敗した。量子力学とは動力学でなく各エネルギー・レベルについての静力学でしかなく、「量子力学」の「力学」なる名前とは裏腹に力を論じられない。論じればエネルギー消費が起こりエネルギーレベル一定論が崩れる。
「現代のフォン・ノイマン型コンピュータ・アーキテクチャーの誤りと、創るべき新コンピュータ・アーキテクチャー」
現代のフォン・ノイマン型コンピュータの計算機モデルが取りも直さずチューリングマシンそのものである。チューリングマシンは決ったパラメータ数の状態間の遷移を静的モデル化したものであるのに対し、歴史的にその直前に発表されたアロンソ・チャーチの計算モデルのラムダ・キャルキュラス(人工知能プラグラミング言語LISPの言語理論でもある)は関数の中に関数が次々に入れ子のように代入されて行き擬パラメータが増えていくダイナミックな仕組みを持つ。この後者は人間が作ったコンピュータを遥かに凌ぎ、宇宙の始原から発生した環境データから関数をf1(t),f2(t),.,fn(t)と次々に学習し入れ子のように代入進化し、次の一ステップの計算には宇宙の始原からの全ての関数f1,f2,...,fnを思い起こし、そのそれぞれの差分を取って掛け合わせる事をしているコンピュータとも言える物理世界とその時間の学習・進化を時系列順に模写するのに持って来いの仕組である。関数と言っても多項式で充分である事を世界の7大数学難問の一つPolynomial=Non-Polynomialの私の証明も交えて平明に解説する。これは日本の国と世界の先進諸国のコンピュータ科学の今後の研究方向を左右する発言となる。
■実 績
【講演実績】
Trinity International University
「コンピュータ科学」 学士号コースの学生に卒業まで全コースを講義
St.-Clements University
「金融工学に必要な数学・物理学」の博士号コースの学生3年間に渡って講義、研究テーマと研究内容、博士論文のアドバイス
St.-Clements University
研究テーマ「コルモゴロフ複雑系の二進ビット・ストリングの下限＝Lower bound for binary bitstring in Kolmogorov complexity」の博士号コースの学生Dr. Bradley Ticeに英語でアドバイス
St.-Clements University
外国語学部のポルトガル語・伊語の通訳・翻訳の学士号コースの学生に教養学部のレベルから全社会科学（経済学、法律学、社会学、経営学）、人文科学（哲学、言語学、心理学、歴史学）、自然科学（数学、物理学、化学、生物学、医学、計算機数学）、エンジニヤリング（Information Technology、ソフトウエア工学、電気工学、電子工学）の各々の学科の全講義を行う。
Госдарственный Университет Санктпетербургской Гражданской Авиации (サンクトペテルブルグ国立航空大学)
物理学学会の論文発表会で幾多の論文の露語によるプリゼンテーション。
【メディア出演】
【執筆】
ti-probabilistic Learning by Manifold Algebraic Geometry, SPIE Proceeding, 1992 Orlando 等 人工知能学会論文
