  |
はてなキーワード: バックドアとは
だからアカシックレコードが実在してそれを予言者でもない一般人がリアルタイムで確認できるとするじゃん
アカシックレコードには「あなたは10分後に自宅のトイレで大便をひねり出す」って書かれていたとして
それに反する行動を取ろうと増田ならその場で大便をひねり出すじゃん
そうした時点でアカシックレコードの予言は的中しなくなるわけじゃん
増田、リビングで、大便、漏らした～(森本レオ)になるわけじゃん
そしたらアカシックレコードが役目を全うするには「増田、リビングで、大便、漏らした～(森本レオ)」って書いてある
アカシックレコードを確認しようとする限りアカシックレコードは記述を改ざんしないといけなくなる
うーん？
最初から最後まで結果を記述してるはずのアカシックレコードの内容が変わるっておかしくない？
おかしい
これってアカシックレコードを認識することで行動を変えれる存在が悪いんだよね
ということは人間だけがアカシックレコード＝運命に干渉できる存在ってわけ
自由に改ざんできるようになった結果、未来がどうなってくるのか予測がまるでつかない
物理的な宇宙の法則で、宇宙改竄をブロッキングするシステムになっているのか、
そこに人類は帰っていくのか、
はたまた力尽きて勝手にめでたく滅亡するのか、
あ、あ、とにかく分からんけど
宇宙に種子をばらまくよりもばらまく先の星で勝手に生命が誕生するのを待った方が圧倒的に楽だろ
数光年先で地球とソックリ同じ星があるからってそれで何か不思議な現象でも巻き起こんのかっていう
地球上で誕生した生命が最も尊いという考え方は人間ならそう思うのが自然だが
宇宙スケールでみたら、あ、別に人類じゃなくても次の奇跡を待てばいいだけなので…って話だぞ
生命の謎を考えるのならまずDNAの目的、多様性を保持しながら情報を遺伝させていること
それ自体の目的を解き明かさない限りは宇宙に種子をばらまくことに意義があるかどうかも分からん話だ
技術的特異点を迎えて宇宙の法則を解き明かし、宇宙の法則のバックドアを見つけるということが目的だったとしたら
地球を飲み込む前にそこまで到達すれば済むことになる
あー話はそれたな、なんだったか
「その距離を保つんだ。それ以上は近づくとバレる可能性が高まる」
固まって行動するのは危険だとミミセンが判断し、追跡役は変装が得意なドッペル一人に。
他はドッペルから更に離れてついていくことに。
相手に少しでも不審に思われたら追跡役を交代するか、最悪シロクロとタオナケに撹乱してもらう作戦にした。
万全の体制は過剰とも思えるほど、追跡は順調であった。
街頭にいた信者や野次馬が、今は嘘のようにいなくなっていたことも大きい。
だが、あまりにも順調すぎて気を緩めていた一同は、ある重要なことを失念していた。
「！ しまった、駐車場だ！ あの教祖、車で逃げるつもりだ！」
予想外の事態にミミセンも動揺を隠せない。
それが予想外であったことよりも、予想外にしてしまった自身の不甲斐なさが、何よりミミセンにとってショックだったのだ。
だが、こんなときでも冷静に、目的を見据えて行動できるのが弟の強さであった。
そして、それが弟が彼らのリーダー的存在である最大の理由でもある。
「落ち着け！ むしろチャンスだ。いま教祖は一人、しかも車で来ているなら、その中に“何か”あるんじゃないか？」
弟の言葉にミミセンも平静さを取り戻し、すぐに思考を巡らせる。
「そうだ！ タオナケの超能力でタイヤをパンクさせるんだ。そうすれば予備のタイヤを取り出すために荷席のドアを開けるはず。その瞬間を狙うんだ！」」
だが、ここでまたアクシデントが発生する。
１回念じるのに数秒かかるのだが、ここまでの追跡で体力と精神を削っていたため普段よりも時間がかかっていたのだ。
しかも、既に5回以上は念じていたのに成功しないという運の悪さである。
諦めかけた弟たちに、千載一遇のチャンスが舞い降りる。
教祖は車に乗り込まず、おもむろにバックドアを開けていたのだ。
「天は俺たちを見放していなかった！ 強行突破するぞ！」
弟の合図で、全員で車に向かって走り出す。
「な、なんですかキミたち、いきなり」
荷席の中を覗いた一同は、大量に入っていた意外なものに驚く。
「……水だ」
FBIが裁判所と組んでアップルにiphoneのロックを解除できるようなソフトウェアを作れって命令を出し、話題になっています。
そのことの是非はとりあえず置いておいても、Appleの反論が羨ましい。民主主義と自由を基盤に置く、すごくアメリカらしい反論。
わたしたちは国を愛し、アメリカの民主主義を心の底から信じています。だからこそ、FBIからの要請に再考を促ししたいと思います。この要求が意味することを改めてよく検討することはすべての人の利益にかなうと信じています。
FBIの要求は正当な動機があると信じていますが、政府が私たちの製品にバックドアを作るよう強制することは間違っています。究極的には、この要求によって、政府がまさに守ろうとしている自由が損なわれるのではないかと恐れています。
We are challenging the FBI’s demands with the deepest respect for American democracy and a love of our country. We believe it would be in the best interest of everyone to step back and consider the implications.While we believe the FBI’s intentions are good, it would be wrong for the government to force us to build a backdoor into our products. And ultimately, we fear that this demand would undermine the very freedoms and liberty our government is meant to protect.
アメリカでは政府に「政府がやっていることは、民主的でないし、自由を損なうから、非アメリカ的で、間違っている」と言えます。つまり、民主的であることや自由であることは、政府の利益よりも上位にあります。
日本では、どうでしょうか。「政府がやっていることは、XXXだから、日本にふさわしくなく、間違っている」と、大多数の人が同意するような何かはあるでしょうか。政府の利益もしくは「(時の政府が考える)国益」よりも上位に存在するものはあるでしょうか。あえていうなら天皇制だけど、天皇制は歴史的にみても権力の暴走のブレーキにはならないのではと思います。権力を追認することでずっと生き延びてきた制度です。
アメリカのNSAはグーグルとかヤフーとかフェイスブックの情報を全て収集して分析することができる。
出荷前のルーターを押収し、バックドアを仕込んで消費者に届けたり
アメリカ大陸にいくつかあるぶっといケーブルから通信をぶっこ抜いたりとあらゆる手で情報を集めている。
通常のネットを介さない飛行機上の通信ですら傍受することができるらしい。
そして、それは中東のテロリストの動向を探るためだけに使われるわけではなく、経済や国際政治の場面でも使われる。
ブラジルのでっかい石油会社が次にどういう経営判断を下すのか、NSAはわかってしまう。
もちろん国連に派遣されるような日本のお役人さんもみんな盗聴、監視され、趣味嗜好や家族構成、毎週欠かさず電話をしている相手は誰か、昨日何を検索したかまで全てわかってしまう。
そしてアメリカの担当者は全てを把握した上で交渉のテーブルに着く。
アメリカだけではないかもしれない。アメリカ、カナダ、イギリス、オーストラリア、ニュージーランドの五カ国は諜報分野でものすごく緊密に連携している。
あらためて、これ、本当に恐ろしくないか。
なんでこれが明らかになって、オバマはまだ普通に大統領を続けられているの。
こわい。
政党にしかカネが流れないシステムになってるから、議員は政党の奴隷になるしかない。
＃表向きね。バックドア仕掛けてたやつもいたけど。
しかもその政党が衆参両院に奴隷をもつから、参議院が衆議院の劣化コピーになる。
つまり政党助成金分程度（さらに盛ってもいいよ）を議員個人に与える。かつ政教分離と同程度に政党の衆参分離を義務づける。分離を担保するために半額程度政党助成金を残すのが結果としていいかも。
議員報酬が増えることに疑いを持つ人もいるだろうから、全額もしくは一定額以上はクレカみたいなのにすればいい。必要なら家族カードを発行すれば家計にも使えるし。今どき国内で困ることはないでしょ。もちろん明細は webで公開ぐらいの勢いね。
B-CASカードがお祭り状態なので技術的なことをネットに転がっている情報から調べてみました。
もし間違いがありましたら後学のため教えてください。。
http://gigazine.net/news/20120518-b-cas-card/
・B-CASカードにはKm(マスターキー)というカード毎固有の暗号鍵が含まれている
・放送波から流れてくるTS(トランスポート・ストリーム)にはEMMとECMというというパケットが含まれている
・ECMはすべてのB-CASカードに向けて投げられるパケット
みたいな
- この情報はB-CASカード内にあるRAMエリア「契約情報」にコピーされる ★1
- EMM自身にはB-CASカードID(6Byte)が非暗号化されて入っている
・ECMには日時情報とKs(スクランブルキー)が含まれている
- 日時情報と上記「契約情報」でACL(アクセス・コントロール)を行なっている ★2
と、いうことで★1と★2において★1の契約情報を偽造できればたとえばwowwowを契約していないのに
契約できていることになりそうです。ただ問題は★1の部分はEMMで更新されるということ。
単純にB-CAS内のRAMエリアを書き換えても時間がたてばEMMで元に戻りそうです。
参考:
http://oshiete.goo.ne.jp/qa/3456801.html
http://blog.goo.ne.jp/ikedanobuo/e/8b59ccca2dac45f02a5ae15815fb4a75
http://www.marumo.ne.jp/db2012_5.htm#12
http://www.marumo.ne.jp/db2007_c.htm
EMMデータには暗号化されていない部分にカードID番号(6Byte)
http://www.arib.or.jp/english/html/overview/doc/2-STD-B25v5_0.pdf
知らなかったのですがB-CASカード内にはCPUが入っているそうです。
そのCPUがEMM/ECMのパース、暗号の復号、「契約情報」エリアの管理を行なっているようです。
今回は特定のB-CASカードに含まれるそのCPUが特定され、ファームを書き換えられるようにしたそうです。
ファームを書き換えさえすればEMMの「契約情報」をRAMエリアの「契約情報」にコピーさせる処理を
よって今回突破されたことをまとめると、
・特定のB-CASカードにはRAMエリア書き換え、CPUファームを書き換えるバックドアが設けられていた
・特定のB-CASカード対応の改造版ファームを作る猛者がいた
ということのようです。
以下は興味。
各B-CASカード宛てにパケットを送るなんて現実的じゃないよね？どうやってるんだろう？
特開２０００－１２５２７２ 【発明の名称】放送システムでのメッセージ伝送方法
http://www.j-tokkyo.com/2000/H04N/JP2000-125272.shtml
TSにはハッシュキーのみ含み、データはB-CAS内に予め保持しておくそうです。
確かに契約パターンはそんなに多くはないだろうからこれでいけそうですね。
EMMもひとつのTSパケット中に何個か含めることができるそうです。
そんでもって、 Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、 Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォームを提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。 msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千もの API コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。
Amazon は自分のものにしている。 Amazon の AWS （ aws.amazon.com ）は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。
Apple も、明確に、自分のものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ？。彼らは実に見事なドッグフードを作る。彼らの APIコールは Microsoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。
Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする（って言うのかどうか知らないけど）のも嫌いだ。そもそもGoogle+はぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Googleに成功して欲しいと思ったらね。で、僕は成功して欲しい！。まあ要は Facebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。（訳注：この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え！。"アドバイス" thx ！）
Microsoft と Amazon 、それに Facebook （たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…）の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね？大きな差だろう？。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものをデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。
どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。
僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 Maps API は一体どこにあるっていうんだ？。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにある API は全くけちな代物だ。まさに本当の意味でドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部 API に比べれば、まるで不格好な別物だよ。
Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティなプラットフォーム部隊が、無敵で予算も自信もたっぷりのプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。
ゼロから構築したプログラマブルなプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps や Docs なんかが思い浮かぶ。 Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大な Microsoft Office プログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、 T-Rex の対決みたいなものさ。 Docs チームだって、このスクリプティング機能が無ければ Office に太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Apps スクリプトが Spreadsheet だけで動作して、 API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。
皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。
みんなは、外の人たちが Google は傲慢だって言い続けているの、知っているよね？。僕は Googler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた（遠い記憶をさかのぼってよ）、 Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから、傲慢だ傲慢だと言っているんだろう。
でも、もし僕らが、僕らは全ての人に対して完璧なプロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。
デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要なポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこい Chrome チームってのははっきりと傲慢だから、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。
これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。
Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。
Microsoft はプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。
でも、 Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。 Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。
たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったら Google を倒せる？。 Google に足りないものはなんだ？」
僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。
プラットフォームの黄金律「自分のドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」（訳注："アドバイス" thx ！）。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。 MS Office をプラットフォーム化した人たちに尋ねてみればいい。あるいは Amazon をプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドアを秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。
僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。
この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに6年かかっていると言える。僕が紳士的ではなくて申し訳ないと思う。プロダクトやチーム、個人を僕が誤解していたら申し訳ないと思う。もし僕らがたくさんのプラットフォームを実は作っていて、僕や、僕が話した人たちみんなが偶然知らないだけだったとしたら、申し訳ないと思う。
でも、僕らは今すぐに始めないとならない。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。バカにしに行くんでもなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかもしれない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
togetterがchromeが固まるくらい重いのと、書いてある内容に同意できてもエタ東となる4時の組み合わせは気分が悪いので、自分用に。
最初に書いておくと、これは特にpixiv擁護ではない。というより、擁護できる部分は特にない。
pixivを擁護したがっている人たちというのがいて、連日出てくる問題を鎮火させようと頑張っている。
カオスラウンジとズブズブだったpixivも悪の企業であると認めず、pixivは悪くない、pixivは俺たちの居場所だ、と信じて自分たちの立場を守ろうとする。（俺正義タイプ）
本の宣伝をしたいが代替サービスのユーザーがまだ少ない。pixivを宣伝用に使い続けるしかないのからpixivを守りたい。（我欲タイプ）
pixivとかユーザーのことなんて全くどうでもいいけど、批判に対して反対意見を言える俺かっこいい。（自己顕示タイプ）
大体想像できる動機はこんなところ。
メンツは固定しているないが、毎度の騒動で発生源となっているtogetterまとめを網羅的に眺めると、誰が鎮火しようとしているのか分かりやすい。
はてブでいうとb:id:sa_tie、b:id:katsura_1、b:id:tailtame辺りが該当。彼らを駆り立てているものは一体何なのか。（なお、エタ東も方向性が違うだけで同類にカテゴライズしている）
もっとも動機が不純だからといって、成すことが正しければ良い結果をもたらすこともあるし、独善が「悪事」としか呼べない暴走を引き起こすこともある。評価は人による。
pixivの新規登録画面は極めてシンプルで、pixiv idの用途については特に記されていない。（※要改善）
登録するとユーザーにはユニークな数字のidが付与されるので、pixiv idはログイン用のみだと考えている人は少なからずいるようだ。
実際にはpixiv id名でディレクトリが作られるほか、スタックフィード（活動履歴）のid、アカウントを共用するpixivブログや、姉妹サイトdrawr（flashで手書きできるサイト）のidとして利用されている。
pixiv idを外部から見られないものとして、個人名を使うなどする人もいて、問題となったことは過去に数度ある。id変更の機能追加をするという話もあったが今のところは実現していない。
今回の騒動の発端となったのはこのpixiv idが画像の絶対パスから参照可能だ、という最初期から判明していたことを何度運営に要望を出しても改善されないまま放置されたことに業を煮やしたことユーザー達のtwitterである。
これを、「最初期から判明していたことだから今更問題ではない」と擁護する連中が現れた。
「idは最初期から漏洩するような仕様で、スタックフィードなどからidを参照することも可能だ」と判っても問題点を把握できないユーザーが多数いたことで、危機の周知は次段階に移る。
「IDとパスワードを同じにしている人は危ない。プレミアムユーザーならクレジット番号などの登録もしているので危ない。」と危険を訴えた。この辺りから「ただの言いがかりレベル」などと鎮火ツイートが広がる。
現在のPCスペックの技術の向上は目覚しく、家庭用でもハイスペックなPCがあれば簡単なパスワードであれば数分～数十分で破ることもできるとされる。
が、それはメモリ内で高速に試行できるローカル環境上の話であって、web上のパスワード認証に対して必要とする時間は全く別物という視点が抜け落ちていて、とても現実的ではない。
だが、総当たりなどせずとも、簡単な単語やIDと同じパスワード、誕生日などであれば簡単にログインできてしまう可能性がある。
それを、「例えローカル上で10万回/秒でログイン試行できるPCでも、web上のパスワード認証に対しては通信とサーバーレスポンスがボトルネックとなって100回/秒程度のパフォーマンスしか発揮できないと思う。並列で大量にリクエストを殺到させればサーバーが落ちるだけだし、そもそも膨大なオーダーのログイン攻撃が仕掛けられれば、突破するより前にファイヤーウォールが異常を関知するか、サーバー管理者が気付く。そもそもイラストコミュニティサイトに対して逮捕されるリスクを犯して潜入したところで、成りすまして暴言コメントを書いたり個人情報を抜く程度で、不正アクセスのリスクにリターンが見合っていないわけで…。」
などと問題点をすり替えて、指摘する側がさも間違っているかのように発言を繰り返す。
大手ポータルサイトや銀行、携帯キャリア、有料ポイントを運用するネトゲなどであればそれなりに堅牢なログイン構造にするのが当然で、既に大手のお絵描きコミュニティ、しかもカードの支払まで行われるサイトにパスロックがないというのが問題でないはずがない。
admin.pixiv.net他に接続するとグローバルIPからでもログイン認証が出てくるというもの。発覚したのは実は1年も前だという。今回twitter等で公になってからも1時間程度は誰もがアクセス可能であった。
あくまでログイン認証画面が出てくるだけで、ID/パスワードが判明したわけでもなく、webのログイン認証に対するブルートフォースは非現実的なのは変わらないが、「外部からadminツールにログイン可能」というセキュリティ意識の無さが露呈し、大騒ぎとなる。
更に話が広まる際には「adminツールが流出した」「バックドアが仕掛けられた」「ログインにキーロガーが仕掛けられている」「アクセスするとウイルスを仕込まれる可能性がある」「今すぐ退会せよ」など虚実入り乱れた話となる。
普通に考えれば、外部からアクセス可能な状態で晒され続けたという事態が発覚した時点でサーバーを落として対策を取るはずなのだが、隠蔽体質に定評のあるpixivが何のアクションも起こさない為、念のためアクセスを控えるよう呼びかける。
「そこまで大事になっているのであればサーバーを落とすわけで、実害はない」などと見当違いな「俺の脳内のpixivのセキュリティ安全神話」ツイートが擁護派から出てくる。
admin.ads.pixiv.orgに接続すると「It workssl!」と表示されるもの。これがapacheのデフォルト表示「It works!」と異なることから、「何者かに書き換えられたか、運営が謎のミスをしたのか」と疑惑が生まれる。
ads.pixiv.orgは広告関連のサーバーのようだが、侵入された場合は他のサーバーも同様に危険である可能性が高く、「個人情報やカード情報が抜かれる危険性もある」と指摘されると「万が一侵入されていても個人情報が流出する可能性は低い」と根拠のないpixivの言い訳を持ち出す。
カード情報は決済代行会社が保存していると運営から「なぜか」一部ユーザーにメールで通知されていたようで、ここまでの騒ぎになっておきながらサイトトップでも発表しないなど、さらに不信感が募る。
「IDが漏洩する危険性がある」という問題点から、罪のないユーザーが被害に遭うことを防ごうしたものの、サービス開始時からの仕様で改善される望みが薄い。
さらに管理者ページが外部から閲覧できたことは、あってはならないセキュリティ意識、にもかかわらず、「批判は的外れで間違いだらけ」というまさに的外れな擁護ツイートが広まる。
ここまでサンドバックになってて何も発言せずパスロックを実装するpixivはある意味凄いが、その沈黙がさらなる疑惑を生んでいることにいつ気が付くのか。
84 ：名無しさん＠お腹いっぱい。：2011/01/06(木) 22:22:49
585 名前：sakurazaka.jpn.ph[] 投稿日：2011/01/06(木) 22:15:17 ID:B05NruFc0
今回のまとめ作ったけど横に長すぎた
・東日本が削除人の作業時のログを見つける。http://be.2ch.net/test/sss/hoop.datとか。
これは誰がいつ削除したかがわかる程度。
・だが、/test/sss/以下の全ファイルリストがApacheの仕様で見れた。
しかもbe鯖のsss/以下にはなぜかcgiが拡張子なしで置かれてた。
元の現在動いてるcgiスクリプトを探し出し、それに対してコマンド実行。
・そのcgiも糞で、パスワードなしで2chの全キャップが入手でき、他にもパスなしで板移転なども可能だった。
ファイル一覧も取得可能だった。
・いろんな人がそれを実行した。板移転もやりたい放題、キャップも全部ばれたのでお止めも自由。
・しかもファイル一覧取得にもバグがあり、そこからOSのコマンドを叩くことも可能。ここで全部のcgiソースを入手可能。
・もちろんこのバグは全鯖共通で持ってるので過去の鯖でも実行可能。どこまでやられたかは不明。
だったらそれを明らかにすればよい。
自分でなにもかもやるんじゃなくて、第三者の手を借りればよい。
知人友人ではなく、まったくの赤の他人。できれば全国展開しているような規模の大きいところ。
（コンプライアンスの関係でそういうところは縛りが多い）
パソコン関係だけ言ってみると、
パソコンだけ、ネットワークだけ、と五月雨式にやっても意味がない。
弱いところから入り込まれる。一度に一気に全部やるのが鉄則。
ルータは正しく設定すれば外と隔離できる。（原理的に外から入り込めない）
ルータには強固なパスワードかけて他からアクセスできないように。
無線LANなんて危ないものはやめて、すべて有線でつなげ。
パソコンにはバックドアを仕掛けられないように、すべて初期化。できればデータもすべて捨て。
ウィルス対策も万全に、ファイアウォールはルータがあればいらないけど心配ならつけても害はない。
2006年1月 Googleが中国に進出 当局の検閲を受け入れる
2009年12月 Aurora事件 シリコンバレーの企業に大規模ハッキング
ハッキングの手口
メールでURLリンクを送りつけ→従業員が間違って悪意のあるサイトを訪問→
IE6の脆弱性（JavaScriptのバッファオーバーフロー）を突いた暗号化された
McAfeeの説明
Adobe Reader の脆弱性を突いたpdfを添付した電子メールを従業員に送りつける→
『Trojan.Hydraq』というバックドア型トロイの木馬がインストールされる→
社内ネットワークに侵入
iDefenseの説明
34社がターゲットになった
Google, Adobe, Yahoo, Symantec, Juniper Networks, ノースロップ・グルマン、ダウ・ケミカルなど
Googleが侵入に気付く 台湾のサーバーを覗く(逆ハック）
1/2 Adobeが侵入に気付く
1/4 攻撃終了 攻撃者のサーバーが閉じられる
1月 Google社内で議論 セルゲイ・ブリンは中国撤退論、ラリー・ペイジとエリック・シュミットは続行論
1月第2週 ヒラリーがGoogle, MS, Twitter, シスコ幹部と会談
1/12 Googleがブログで中国撤退検討を表明、また検閲廃止を表明
Adobeが侵入されたことを発表
1/17 現在の情勢
予定
