  |
はてなキーワード: メソッドとは
「これをやれば、終わった後に1,000万円現金でもらえます」
という妄想するとやる気が出る。
例えば
妄想「この床に散らばってるお菓子の食いかけの袋、出しっぱなしの服 を片付ければ1,000万円！」
俺「なにぃ！こんなんおちゃのこさいさい！ただ拾うだけじゃん。」
妄想「次の訪問予定先は うちの会社超アンチで嫌味しか言ってこない A社 ○○所長です！
しかも君が作った提案資料は昨日の一夜漬けで穴だらけ！絶対○○所長に突っ込まれるぞー！
でも、、そのA社訪問が終わったら、、現金で1,000万円あげちゃう！！！」
俺 「まあ、、どっちみち行かないわけにはいかないし、、
1,000万円もらえるなら○○所長に嫌味言われるくらい大した事ないな。
自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。
彼のへの感想。
富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いから想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身が自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると（後述の富士通に入社して10年が経った人の話にもあるのだけど）新人の能力の客観的な判断材料って大学と資格（応用情報レベル以上）程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代で富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士卒しか居なかった覚えがある。あと確か2～3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。
ただ、20万人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、（自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた）、そういうのに入社して間もなく入ってしまうと自身の勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。（自分は炎上案件に放り込まれた新人が寮で死んでたとか話を聞いたことある）
はあ、としか。この人がこう判断した際の判断材料にするであろう自己の体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業の経営とか体制とか理解出来るんかね？と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分の体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的や巨大企業特有の問題があってそうなってるんだなって思う事が多々あった。
近い時期に入社したと思われる。具体的な話が自分の経験と一致してる。特に、富士通のソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか（特に学生なんかじゃ）判らないかなと。
それでこれらの話を見てどんな人が富士通（というか大企業）に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる（要するにそこそこの大学に行って卒業した人）、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであんまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解しやすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社は子会社で色々アルかもしれないけど。
入社は10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1～2年したら子会社の統廃合とのことで富士通本体と連携してる部署（自分がそうだった）は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由は実家の事業を継ぐ事にしたため。
入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と
富士通本体のソフト開発配属の人達で研修をやったのだけど、その際に富士通本体の人達と知り合った。（この際に全員のプロフィール冊子が配られた）そのときは流石子会社に入る人達と本体とじゃレベルが違うな～と思いましたね。（ちなみに自分はMARCHより下の院卒。）
自分が配属されたのは某製品部署のAPI部分チーム。その製品がC言語やJava言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPのポートにプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙でヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語のAPIをリニューアルするって開発してたのだけど、設計担当がJavaしかやったことない人で色々とC言語の流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね（ちなみに機能はそれサーチか？思うのもあった）。もっと酷かったのが初期製品のJavaの公開メソッドで、マニュアルには「このメソッドの引数○○を□□を指定した場合は戻り値のObjectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。
これは、ミドルウェアの開発をやってる人達って基本的にC言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSはWindowsとLinuxとSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。
それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkのAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0でGenericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計も実装も結構良い感じに出来たと思う。ああ、そういえばRuby用のAPIも効率化の開発ツールとかの名目で仕事中に勝手に作ってたなあ。他にもC言語のAPIも内部実装がクソすぎ！とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対にLDしてるんで完全に趣味なんだけどな。これでAPIはC言語とJavaと.NETになった訳だけど、現場の案件で使われたのってほぼ全てJavaだったと思う。（開発中のサーバのテスト用アプリはC言語だけど）。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業の仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟は必要かもね。
で、.NETのAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理と作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品の担当が増える事に。インストーラはWindowsがInstallShieldというクソみたいな言語上で作られたもの。LinuxとSolarisがシェルスクリプトでのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか）とか保守作業が大変だった覚えある。
んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品の派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味でC++で勉強してたので何とかなった。あと、結構OSの知識（プロセスとか）が必要でWindowsとLinuxとSolarisで動くコードを書く必要があってまあまあ大変でした（と言ってもifdefで切り分けるだけなんだけど）。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品のバッチ処理に使えないかとか話が出てきたあたりで自分が退職する事に。（退職の話は1年ぐらい前に話し合って決定済み）引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしまい実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。
振り返ってみて残業時間は月40～60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部（だったかな？）単位で残業禁止になってホントに残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通のソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか（そんなに深くはないけど）色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモを体験出来たのは良かったです（こなみ）。
私が住んでいる場所は北海道の士別市という場所で、そこにはくら寿司はおろかマクドナルドさえない。
だから「隣りの女子高生」の会話メソッド作文をなすには、学生がよくいくお焼き屋に舞台を遷さねばならない。
お焼き屋に行くと、富川という私より25歳ほど上の男が店番をしている。
元来、私の学生時代は富川の母が店主であった。私たちは富川のばばあだとか、富川のばあさんと呼んでいた。
富川の息子、今店番をしている男は、若いころから数年前まである政党の党員として、近隣の名寄市や旭川市で活動していた。
富川のばばあが高齢になったから、今は店を手伝ってよくいる。それまでは市議や道議なんかと活動を共にして走り回っていた。
富川のお焼き屋は、お焼きはもちろんそれなりだが白玉善哉が美味いことで知られている。
私もそれを頼む。それとアイスコーヒー。
私は旭川東高校から北海道大学経済学部に進み、沼田町役場に奉職した。
今から3年前、仕事を辞めた。仕事は嫌いではなかったし熱意もあったのだが、書いていた小説がかなり売れるようになって、家族とともに故郷の士別に引っ越した。
妻の実家はこれまた近くの秩父別町にあるから、まぁ親孝行なもんだ。
富川の店に2人のＪＫがやってきた。そしていよいよ、彼女たちの会話が始まる。
「やんぬるかな」
「それときらら8087xの取引価格がまた小樽の相場師によって引き下げられとるわ」
「え、とーさん大丈夫だべか？」
「やんぬるかな」
「旭川の方では軍が言って組合作って自分らで検査しとるそうだ」
「うっちじゃそれ無理っぺよ！ まとめんの出来る人居るの？」
「折角景気も天気もいいのにこれじゃいつまでも銭こはいらんやね」
「わややわ！ やんぬるかね！」
「すったこ～」
2089年に勃発したモンゴルと神聖ローマソヴィエト第三二重帝国民主主義人民共和国との抗争は、この北海道の小さな町にも好景気をもたらした。
内地の敦賀や鳥取・長崎に代表される人体機械化製品・生体兵器（CBM）生産による圧倒的な戦時景気ではない。
戦争の際は、北海道のこの土地の生産物はユーラシアの兵士の食料になる。今も昔もそうだ。
どちらの陣営にも食料は必要だから、豆やコメの値段はだいたい五倍くらいになる。
CBMの景気の良さには到底及ばないが、片田舎にも相応の贅沢をもたらした。
ただし、一つ問題点があった。
士別市は田舎すぎて、自前の公定検査組織を持たず、経済都市小樽の相場師がやってきて買い付けて行く。
憎き小樽の相場師は、それを時にため込み、時に吐き出し、戦争に支えられる好景気とはまた別の次元で儲けを生み出していた。
どこにどういう価値の変動があるのか巧妙に隠されている。
しかしどうやら、士別の人々が幾ばくかの損をしていることは間違いないようだ。
北海道の農協制度は2050年代に崩壊し、ほとんどの自治体は後継機関を持たなかった。
「それならば君らが組合を作ればいい」
「ふぇえ、無理無理無理ぺよ」
無理なことはない、かもしれない。彼女たちの世代は全く新しい教育体系を得た世代で、理論を建てる訓練や説得力のある思考に関する訓練をを相当積んでいる。
かつて明治という時代に近代的な学制が施行された際、子どもたちの多くは親よりも文字が読め、文字が書けた。かつてそういう世代があった。
いま彼女たちはそれと同じような時代を生きている。閉鎖的な親たちの社会、見識、学識をネット社会の成熟が打破したわけだ。
糞みたいな田舎でも、都会の清廉な学生が受けるような学習の「効果」が期待できるようになった。
それを一身に受けた世代が彼女たちだ。先ほどの経済の話もかつての世代が高校生のときにやる話ではない。
私の役割は多分ここまでだろう。あとは記録し100年先にこの出来事を記そうと思う。
富川の店は若い世代の地域政治・地域経済を議論する場になるだろう。
富川は母の様子を気にしながらも、この士別で政治を考え、次世代に伝えることが出来るだろう。
外国のカッフェのようだ。
あまり話題にはなってない作品なのかもしれないど、これってかなり面白いことしてると思うんだよね。
女の子が艦船に乗って戦うみたいな、いっけんガルパンの亜流みたいに見えるんだけど、実はぜんぜん違うのです。
ガルパンの物語構造は、基本的にスポ根的なドラマツルギーに基いていて、ラブライブ!とかとほとんど同じです。
要は、「努力、友情、勝利」のジャンプメソッドmeets美少女なわけ。
ガルパンは戦車を、ラブライブ!はアイドルを素材にして美少女スポ根を展開してるわけで、その先祖はトップをねらえ!あたりかな?
で、ハイフリなんだけど、これって冒険小説的ドラマツルギーなんだよね。
アリステア・マクリーンとかギャビン・ライアルとかの古き良き冒険小説。
不可解な敵や、限定された状況下でのサヴァイヴとかまさにそんな感じ。
これで、内輪に裏切り者とかいたらまさに古典的冒険小説な展開だよ。
つーことで、男臭い冒険小説的物語構造に、ポップな美少女をぶち込んだこのアニメ真骨頂なのだ。
それなりの文章力ではあるけれど、筆者のお笑い論を登場人物の口を借りて喋らせてるエッセイっぽさのほうが大きかった
作中に出てくる意味のない掛け合いもまったくおもしろくなかったし
火花っつータイトルにするぐらいだから、チャンピオンのバチバチみたいにいろんなお笑いメソッドを持った芸人たちが火花たててぶつかるくらいのアツい話かと思ったらむしろ真逆
作中では花火しか出てこなかったけど、火花は火花でも線香花火って感じ
自分のフィールドを出た次の作品が物語としてどれだけおもしろいかで、本当の意味で又吉直樹の才能は見えると思う
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
馬鹿1がコリアンへの差別を扇動するようなデマを流す（←死ねばいいのに）
↓
馬鹿2が馬鹿1のツイートを遡ってコミケにサークル参加予定であると把握
↓
↓
↓
馬鹿2の取り巻き「オタクってこんな時にもコミケの心配しかしねえのか。クソだな」
twitterでこの流れ見てたんだけど嫌がらせメソッドとしてすごい洗練されてると思った。
あと某フットボールクラブの「Japanese Only」横断幕を例に出して批判してた奴も見かけたけど、あれを掲げた奴がクラブからの出禁を食らうのと「スタジアムで『Japanese Only』を掲げた奴が参加する予定のアイドルのコンサートに殴りこみをかける」のは全然違う話だってわかんないのかな。すげえな。
ネトウヨの自分としては、本当の事態が起きたとき対応が後手になるのでデマはやめてほしいし、
真剣に現地の心配をしてるならそんな下らん悪ふざけできんだろと思う。
嫌儲とかなんJ民とかの露悪的なものを善しとする流れなんだろうなと思ってる。
http://blog.livedoor.jp/kaikaihanno/archives/48369885.html
ジョークでも当事者にされるのは嫌なものだというのは分からんでもないが、
70年前の空襲による民間人大量虐殺の根拠となったプロパガンダを
否定する気のない人たちが反差別だとか反ヘイトスピーチだとかやってるんだから
右と左で話が噛合うはずもないね。みんな自分が大切だと思う問題のことばかり。
そして話し合うことをやめて罵倒か敵失を拾うことばかり夢中になってる。
それです。ついでにいうと、穴モテありきな戦略に走ってる人に限って穴モテ狙いの男を批判して『私、こんな経験あるんやで』が多すぎるから『節子、それ経験やない！ただの消費行動や』と三沢文也a.k.a.青二才さんが追加
＞言ってる意味が全然わからないんですけど「穴モテしてるだけの、たいして恋愛経験のない女が偉そうに恋愛論を語るな」ってこと？
君のリクエストに最大限お答えして、はあちゅうの記事なんかとは比べ物にならない程のゲスさと、両名へのIDコールまでやったら、僕は色々な意味で期待してたアオヤギさんからブロックされて軽く凹んだよｗ
男の友情を優先させすぎると、そのせいでモテなくなるから程々にしておこうと思った。一応、ちゃんと読めばちゃんと中身があるし、今のインターネットをきっちりと切り取った記事を書いただけに、すごく聡明な彼女からブロックされたことに「え？」とはなったけど…落ち度は僕にあるしなぁ〜
あとさ…あの記事って、そもそもゲス女系にシンパシーのある女性が読めば、
「あなたがモテないのはあなたが気持ち悪いから」の法則で、論理が正しいとか正しくない以前にレトリックで「ああ、こいつはコンプレックスの塊だからそこから女を批判してるんだ」とか議論をすり替えるのよね…つまり不毛
アオヤギ・トイアンナ両名にツイートされてからついたブコメが「青二才は童貞」「コンプレックスの塊」だといった資質を問う声があるわけだが…童貞ではないけど、経験が少ないからあんまり恋愛の話をしないようにしているんでしょ？
まして、人の恋路にアドバイスできるほど僕は上手じゃないでも、上手じゃないからこそ「いい理論があればうまくなりたいなぁ〜」と思って、本や記事をぐらい読む程度には興味はあるわけさ。でも、その大半は自己肯定欲の低い男性を説教して安心させる記事か、女性同士の世間話をメディアに載せただけ
「泣けば許されると思ってる女がいる」
とまでは言いません。ただ、ゲスなことを言うだけ言って、支持するだけして、そのことを批判された時に「私が悪かった」感が一ミリもないはあちゅうとか峰なゆからへんのひとを見てたら、
「【女の子いじめたらかわいそうでしょ】待ちなんだなぁ〜」と。
一応、二村ヒトシメソッドと、恋愛工学の理論を重ねながら語ったのは、（当然ながら男女問わず、）ある程度理屈っぽく考えられる人なら「二村ヒトシの言い方でたいていのことは批判できるし、（著書を読んでいる人なら気づいたと思うが）都合のいいように出し入れできれば、無敵の論法」と気づくため
ただ、僕はいわゆる「ゲス女」にイラッときた時に言うのはコンプレックスというよりも、自分の母親がバブリーな価値観に染まって、早々と寿退社した分際で、男の趣味が昭和から出てないのに、それを押し付けられて子どもの時にすげー迷惑したから。そういう女が増えると僕が生きづらくなるんよ…
ただ、自分の中で「子どもの時にされてすごく嫌な思いをしたことをしてる女を増殖させる出版社や二村ヒトシは大半の人が生きていくのをしんどくする」と思って言えば言うほど…僕の身の周りの女性の自己肯定を低くしちゃうんだよなぁ…。
いや、僕も男は９９．９９％死ねばいいと思ってる派だけどさ
僕は「男は競争に勝って１万人に一人にならないと幸せになれない」と思ってるけど、女性については「考える事をめんどくさがらなかったら幸せになれる」と思ってる派なんですよね…。意外とわかってもらえないというか逆に取られがちだけど
僕が男の人に「好きなことを大事にしよう」だの「楽しめ」だのと言うのは、競争の勝ち負け、モテとお金のあるなしを幸せの基準にしちゃったら、男の大多数は競争に負けて幸せになれないから。
女性に対して「考えるのがめんどくさいからって共感できることに乗っかってない？」と言うのも、逆
ただ、僕に近づいてくる女て、僕が「考えるのがめんどくさって共感できそうなことを言う人」じゃない代わりに、僕と同じように「私の性では１万人に一人しか競争に勝ち抜けず、そういう人しか幸せになれないから大半の人は死ぬか、生きている以上最大限の現実逃避をするしかない」的な人なんだよね
で、僕はすごく話があって心地よいんだけど…ただ、あまりにも僕に都合が良すぎてと言うか、自己肯定欲が低すぎて「趣味があるから生きてるけど、それがなかったら死んじゃうんじゃないの？」という女の子とばかり会うのよね。心の穴の一致？うん
「遊んで暮らしたい」じゃなくて、「遊んで暮らし」ます。ビジネスマンのマッチョイズムとか、キッチリ感がないから、とことんちゃらんぽらんかつ現実逃避して凡人らしく生きます。そりゃ、マネタイズのことは考えるけど、お金について考え過ぎると病むからあくまでもほどほどに。
最近の交友関係見てると、男の方はいい意味でも悪い意味でも現実を生きてないか、社会舐めてるかで競争自体を拒否してる人にいっぱい会う。
道徳的な話はナシね。
【日本】軍と外務省に勝手な行動を許してはならない。あと、強いやつとは戦わないメソッドを徹底するべき。
【イタリア】強いやつ同士が戦ってる時は、勝敗が決定的になるまで手を出すべきではない。
【フランス】隣の国より強くならなければならない。
【イギリス】ヤバそうな奴は強くなる前に叩かなければならない。
【アメリカ】10倍やそこらの戦力差では戦争を抑止できないようなので、もっと一方的に強くなる必要がある。あと開戦はこっちから仕掛けるべき。
こうしてみるとフランス以外はちゃんと反省を生かすことに成功しているが、
それで平和が近づくかどうかは別の話という気もする。
よくある話題なんだけど二次創作の許可を公式に確認しに行って公認「二次創作お断り」をいただく問題がtwitterで盛り上がっているよう
問い合わせして返答内容をさらすだけでキモオタや同人作家どもを攻撃できて、（今回は特に）ましてや一次創作者サイドからのレスがもらえるなんて荒らし的に無茶苦茶最高のメソッドだということに今回気づいた
身バレとか訴訟とかを恐れずに荒らしに励むなら、わざわざ実際に作者に返答を求めず返答を捏造し燃えそうなところに投下すれば簡単に燃え上がるだろうし、もし作者がその捏造を指摘するとなればその際には自身の二次創作ポリシーについてコメントせざるおえない状況が生まれ最高にハッピーなことになりそうだ
おお！なんて素晴らしいことを思いついてしまったのだろうか！二次創作に自信ニキが多いtwitterやpixivで流行ったネタは今後全てそうしていきたい気分だ！
どう思いますか？
http://ameblo.jp/sary0222/entry-12102204797.html
★受講料 ３５万円
合計４日間で、
今の段階できっちりは決めません。
が、現時点で決めたことを書きます。
★サヌキとアワ(スクール開始1ヶ月前に音源もしくはオリジナルDVDをお渡しします。スクールでは皆さんそれぞれのわからない所を説明します。)←サヌキとアワ、みっちりやります。
★降伏論
(数秘スクールのようにみっちりじゃありません。皆さんの数秘を読み解きます)
★命への信頼
★今を認める、自分を知る
(頭に詰め込むより体感するのが一番です。
私とディズニーリゾートで遊んだら、感覚として掴めます♡愛される自己中が。)
★お金の循環のこと
★想いを放つ意味
★わたし満たし力
★姫になる方法
★電話でお話 ３０分 １回(セッションじゃないですが、スクール期間内ならいつでも)
【詳細はこちらです♡】
とにかく４日間で、
http://ameblo.jp/sary0222/entry-12146082372.html
３日目のカリキュラムは、
東京ディズニーシーで遊ぶ♪
11時にパーク内で集合予定。
でも、みんな楽しんでたよ♪
５ヶ月後の３月の月収は、
1,400万を超えましたよ❤
10倍以上です♪
庶民じゃなくなっても、本当に欲しいものの絶対量って変わらないんだね。
明らかに今の方がお金があるのに、お買い物の金額は変わらない。
ちなみに、月収100万から1,400万までのプロセスは全てブログに書いてきています。
で、自分自身の幸せに投資したスクール生には言葉で伝えるし、姿で魅せます。
１期生として来たみんなは本当に凄いんだわ、嗅覚が。
受付開始した時から、スクールの３日目までに、SAORI YAMAMURAは宣言通り、
８桁プレイヤーになってるんだもん。
＜当記事は『バットマン vs スーパーマン』の重大なネタバレを含みます＞
男「……どうだった？」
女「……いや？」
男「……ん？」
女「だめでしょ……完全にだめでしょ……『バットマン・フォーエバー』よりダメだったでしょ……映画版『DOOM』よりダメでしょ……」
男「客あんま入ってなかったね」
女「むしろ観るべきでしょ。みんな観るべき。オススメしてもいいくらい。汝が敵を知る目的のために観ろと」
男「俺ならオススメされてもいやだね。単につまんないってだけじゃない。おれこれ嫌い。大嫌い」
女「上映中寝てなかった？」
男「寝れないでしょ。だってうるさすぎだし」
女「お酒でも飲んでたらアイゼンバーグの演技もすこしは真に迫って見えたかもね」
男「各所でいじられてるようだけど、バットマンを演じていたベン・アフレックは悪くなかったよね」
女「そうそう。ベンアフは悪くない。髪型もキマってたし、何より雰囲気がいかにもブルース・ウェインって感じだった。
演技よりは脚本がひどかった。
キャラクターが浅薄すぎ。登場人物全員。『マン・オブ・スティール』に出演した面々でさえそう。
初登場のバットマンについては前からファンの注目を浴びることはわかってたはずでしょ。絶対に『ダークナイト』三部作と何が同じで何が違うのか、比較されるのは避けられない。
それが何？ あっちにふらふら、こっちにふらふら。『おれは孤独だー地下にひきこもるぜー」とかなんとか基地でやってた次のカットには、パーティで社交してる。スターク社長かっつーのお前は」
男「スタークのプレイボーイキャラはアル中の素でやってるけど、ウェインのは演技だよね。社交用の仮面をかぶってる。だからさ、アフレックが悪いんじゃないんだってば」
女「そう、全然悪くないんだけど」
男「そもそも俺、ザック・スナイダーの作品嫌いなんだよね。『エンジェル・ウォーズ』もクソだったし。何あのメンヘラの妄想。
今回のBvSには彼の監督としての弱点がほぼ全面に駄々漏れてしまっているように思う。
そりゃ、いいところもあるよ。ときどき素晴らしいアクションシーンを取るし、火の表現にはこだわりを感じる。観てて時々はいい映画に思えてくることもあるんだ」
男「そう撮影監督が良い。スーパー・ビーイング同士のバトル描写は新鮮だったし、ダークな雰囲気にもしっくりハマっていた。この暗いトーンというのがくせ者で、ノーランのときはちゃんと機能してたんだよね。
ところがワーナーはノーラン以外にもノーランみたいなトーンで描くことを求めてしまった。ジョークは入れるな。笑えるようにするな、ってね。『グリーン・ランタン』はその最たる犠牲者だよ。
ワーナーは、２５０億ドルもの予算を任せるにあたってスナイダーならノーラン路線を継承できるだろうと考えた。そして脚本家たちに今後シェア・ユニヴァースを展開できるように膨らみをもたせたホンを書かせようとした。
一方で、出資者たちが求めたのはマーベル/ディズニーみたいなヒーロー映画だったのさ。そして……」
女「ちょっと待って。『アベンジャーズ:AoU』も似たようなもんでしょ。AoUは『やらなきゃいけないこと』が多すぎた。ちょうど、マーベル・シネマティック・ユニバースが次のフェイズに移行するための大事な試金石だったから、AoUはむりくりなプロットにならざるを得なかった」
男「そうだな、たしかに同じ問題を抱えていた。
けど、AoUはなんとかそれを乗り切ってそれなりの支持を集めただろ。
理由は二つある。
一つ、AoUの監督だったジョス・ウィードンがザック・スナイダーより優れた監督だったってこと。
二つ目、各キャラクターが均等に、特に彼らの感情が均等に仕込まれていたってこと。
なんたって、どのキャラクターも『自分の映画』でキャラを掘り下げてきたんだからね。
ストーリーが多少薄かろうが、誰だってアイアンマンを知ってるし、ソーを知ってるし、ホークアイを、フューリー長官を知っている。
事前に他の積み重ねてきたキャラ造型を"収穫”すれば、『アベンジャーズ』ではキャラの説明に要する時間を節約できる。ところがBvSときたら……」
女「しょうがないところもあるよ。ここ十年のマーベルとDCのシネマティック・ユニヴァースを比べてみてよ。マーベルが順当に年輪を刻んできたのに対して、DCはリブートや路線変更や主役俳優の交代が相次いで、積み重ねなんかほとんど残らなかった。
DCはBvSただ一作品だけでマーベル映画十六年分の歴史においつこうとしているのよ」
男「そうだね、マーベルは長い時間をかけて準備してきた」
女「マーベルには一つの確かなメソッドが確立されている。新キャラが紹介されて、今後どう他のキャラと絡んでくるのか、そういうのが映画全編を通しで観なくてでさえわかっちゃう。セリフやカメオを拾ってるだけでもね。マーベルは観客を巻きこむ術を心得ている。
女「BvSの冒頭はすごくクールだった。
『マン・オブ・スティール』のバトルシーンをウェイン目線の別アングルから再解釈する。これはすごい良いアイディアだったと思う。そこまではほんと良かったんだけど、その後がもう陳腐の極み。
恍惚とした表情で天国に召されるブルース少年を観た瞬間、がっくりきたでしょ」
男「脚本がとにかく浅いし弱い。ファンは批評家の『暗すぎるトーン批判』を批判してたけど……」
女「だって楽しくないんだもん」
男「いやそれは問題じゃなくて」
女「問題でしょ」
男「いや『バットマン・ビギンズ』も楽しくはなかったよ」
女「あれは楽しいものだったたよ。『楽しい』の定義が違うな。『ビギンズ』はいっぱいアクションシーンがあったし、エキサイティングだった。次から次へといろんなことが起きて観ていて飽きないんだ。
でもBvSは『楽し』くない。キャラがお互い見つめ合ってるだけでしょ」
男「うんああまあ確かにそうだな。トロいんだよな全体的に。いらないシーンが多すぎるし、なおにプロットは穴だらけ。ワンダーウーマンが登場してからはアクション映画としてすごかったけれど」
女「それは本当に『すごい』と形容していいものかな。単にその前の部分より『マシ』だったってだけじゃない？
アフリカの村で大量虐殺事件が起きました。それでスーパーマンはみんなを救えるわけじゃないんですってんならまだわかるけど、『おい！ スーパーマンが村人を撃ったらしいぞ！」ってのはどういうこと？
スーパーマンが銃で人を撃ったりするわけないだろが！
なに疑ってんのあの世界の人らは。
だいたいフィンチ議員が意味不明すぎるんだよ。なんであんなキレてるの？ 彼女はレックス・ルーサーに対してどういう感情を持ってるの？ 結局何がやりたくて動いてるの？
マーベル映画のキャラたちはそれぞれの拠って立つところが明確なのに」
男「ストーリーも感情も描写不足。演出もそんなによくない。まあ、結局しかし脚本なんだよな」
男「一番がっかりしたのはメインイベント――つまりタイトル曰くの『バットマン vs スーパーマン』のバトルだ。
バットマンが優勢で――スーパーマンを負かしつつあったんだけど」
男「いいんだよ。いいんだけど。
よし、このままバットマンがスーパーマンの野郎を吊るして処刑だ！ ってなったところでさ、いきなりバトルを中断するわけ。
それでバットマンが『マーサって俺のママの名前じゃん！ お前、ママを知ってるのか！ じゃあ……友達ってことだな！』――仲直り！
……おいおいおい待てよ、と」
女「（爆笑）」
男「××すぞと思ったね。さすがにね。そして始まる例の回想シーン」
女「ほんともうかんべんして欲しいよね。もういいじゃん。もう観たくないよ。だってみんな知ってるでしょ？ 『バットマンのクソ両親は殺されました』って。何回それやれば気が済むのって話。バットマンには悪いけど」
男「ドゥームズデイ倒したあとさ、二つの葬式が平行して描かれるじゃん。映画の演出の方向性としては、観客にあたかもスーパーマンがマジで死にましたみたいに誘導してるんだろうけどさ。
観てるほうは『ねーよ』ってハナから白けるよな。
スーパーマンの死で終わるスーパーマン映画がどこの世界にあるっていうんだよ。
いいか、アメコミの世界には絶対生き返らないキャラが三人いる。
そのうち二人はブルース・ウェインのお父さんとお母さん。
残りの一人はスパイダーマンのベンおじさんだ」
女「その三人、ほんとうんざりするくらい死ぬよね」
男「必要な死ではあるんだよ。そのヒーローのオリジンの深い部分に関わる死なんだから。この三人以外の奴らは逆に死んでも生き返りまくる。スーパーマンも当然生き返る。
だいたい『ジャスティス・リーグ』の予告見てるんだから、スーパーマンが死なないことくらいわかるだろ！！！
それなのに十分そこいらもちんたら葬式やって悲しいですね、って何の茶番だ！１！！」
女「『ジャスティス・リーグ』の前準備としてもガタガタだよね。
何あの十五年前のドラマみたいなしょぼいインターネット描写は」
男「おじいちゃんにとっては電子メールはいつも秘密めいてみえるんじゃないんですか」
女「ダイアナ・プリンスがバットマンを出しぬいてハイテク機器を盗みとるじゃん。それでいて、『あら大変。これわたしじゃ解読できないわ』ってなんだそれ女子か。写真をバットマンから送ってもらうために盗みを働くってどんだけ遠回りなのよ。いまどきアマゾネスでも Amaazon.com で買い物できるっつーの」
男「あー」
女「で、さあ、その機密ファイルにアクアマンが出てくるじゃん。沈没船から出てきてトライデントを振りかざしてワーっなるやつ。観てて、ほんとくっだんねーと思った。
あの場面にDC映画のひどさが凝縮してたね。脚本家の怠慢の象徴だよ。マーベルだったらクビ間違いなし。
繰り返しになるけど、マーベルのキャラはどこへ向かって収斂していくのかはっきりしているし、一方でファンが喜ぶ要素をよくリサーチしてる。だから私たちはネットで話題をシェアしたりリツイートしたりいいねしたりするんだよ」
男「もちろんマーベルだって完璧じゃない。現場と上層部がクリエイションの方向性の相違から何度もトラブルをおこしている。エドガー・ライトやウィードンが去ったのもその一端だ。それでも比較的いいものを作り続けている」
女「一番不出来なマーベル映画でさえ、一般的には『良い出来』だよね」
男「公平性を期して言うなら、DCはテレビドラマだと面白いエンタメを作れるんだよね。
いっそ、ドラマをそのまま映画にもってくりゃあいいのに。俳優もさ。そっちのほうが断然いいものが撮れるはずだよ」
女「アメリカではテレビの俳優は映画に出演しちゃいけないって不文律が存在するっていうよね。真偽はわかんないし、都市伝説みたいなもんだけど。
でも、もしDCがそのルールを自社の作品に適用してるんだったら……こんなにアホなことはないよ。
DCがモタモタしてるあいだに、ここのところマーベルもNetflixとのタッグを組んで『デアデビル』を筆頭にすばらしいドラマを量産しはじめた。
マーベルならテレビと映画をクロスオーバーさせるくらいのことは軽くやってのけるだろうね」
男「マーベルドラマはマイナーキャラも上手く扱っている印象があるね。『ジェシカ・ジョーンズ』なんか知名度のわりにはよく練られた、丁寧なドラマだよ」
女「ルーサー役のジェシー・アイゼンバーグの演技はどう思う？」
男「なんであんないけ好かないガキになっちまったのかな。レックス・ルーサーじゃなくて『レックス・ルーサー・ジュニア』に変更されたのは何か説明があってしかるべきだったんだけど、そういうのもなかったし」
女「パパに虐待されて育ったから、スーパーマンにコンプ持つようになったみたいな感じだったよね」
男「アメコミの悪役っていうのは前もって完成されたキャラクターだから、実は性格俳優とあまり相性がよくない。良い役者と人気キャラの両立はむずかしいんだ。
アイゼンバーグがどんなにがんばって悪役を演じてみても、観客は『ああ、いつものジェシー・アイゼンバーグだな』って思っちゃう。
一番の問題はロン毛のまま出しちゃったことだよな。
まるで『バットマン vs スーパーマン vs マーク・ザッカーバーグ』ってかんじ」
女「わたしが懸念してるとこもそこ。BvSのアイゼンバーグは一人だけ別の映画で演じてるみたいだった。腰抜けぞろいの他のキャラクターと比べて明らかに浮きまくってたわよ」
男「シリコンバレーで調子こいてるIT起業家を悪役にしてみるか、程度の発想でしかないよね」
女「アメコミ映画のヴィランとしはキャラが貧相だった。ダークサイドに落ちるほどの動機もなければ、ヴィランとしてのヴィジョンも備わってない。
男「たしか、DCのライターで……ジェフ・ジョーンズだったかな？ が言ってたんだけど、
『レックス・ルーサーがスーパーマンを憎む理由はこうだ。（ルーサーによれば）スーパーマンのせいで人類は自信をなくし、堕落してしまった。人類は自分たちが作り出した問題の後始末をスーパーマンに任せっきりにしている。
それこそが、ルーサーが『スーパーマンは危険だ』と主張する理由なんだ。ルーサーはスーパーマンを打倒することで人類に強さを取り戻させようとしているんだ。彼はヒューマニストなんだ』」
女「なるほど」
男「ところがこの映画では……」
女「あんまり頭もよく見えないよね。思わせぶりに暗躍しといて、バットマンとスーパーマンを対峙させるお膳立て以上のことはなんもやってない。どんな隠し玉が出るかと期待させといて、四十分前に観客に見せたもの以外は何も出てこない」
男「まあ、さすがにバットマンとスーパーマンがマザコントークでもりあがるなんてのはルーサーも僕達も予想できなかったけどね」
女「おもわずふたりともクリプトナイトで刺したくなったわ……」
男「ドゥームズデイとのバトルシーンはかっこよかった。ワンダーウーマンが登場した瞬間は『これこそ俺が見たかった映画だ！』と興奮したよ。二時間映画を観ていて初めてグッと来た瞬間だった」
女「ワンダーウーマンは余計な描写がないのがよかったよね。『ジャスティス・リーグ』が今から心配だな。DCのクリエーターたちって、自分たちがどこへ向かって何をしてんのか理解できてるのかな？ 現場から上層部含めてさ」
男「最初の計画どおり、ジョージ・ミラーに監督させりゃあよかったんだよ。ジョージ・ミラーの『ジャスティス・リーグ』……想像しただけでワクワクしない？」
女「するする。私としてはベン・アフレックでもよかった。でもバットマン役として参加することになったからって、監督からは降りちゃった。もったいない」
男「周囲の非難を恐れたんだろうね。自分で監督して自分で主演するスーパーヒーロー映画って、どうしても嘲笑を免れないだろうし」
女「気にすること無いのに。ベン・アフレックはバットマンのキャラメイクを繊細に達成していた。声もちゃんとバットマンやってたし、演技もすばらしかった。そういや、ジェレミー・アイアンズのアルフレッドはどうだった？」
男「そこそこって感じ」
女「でも、そこそこ止まりでしょ。アルフレッドにしては暖かみに欠けていた。アイアンズがやるとアルフレッドってよりかはルシアス・フォックスっぽいよ」
男「あー、『GOTHAM』は観てる？ ドラマの」
女「いや？」
女「『ゴッサム』はねえ……観たかったんだけどさ。CMでウェインの両親が死ぬシーンをやってるのを観てさ……ちょっと耐えられなかった」
男「三十分前からお前そればっか言ってるな」
女「別に言いたくて言ってるわけじゃないっての」
男「批評家から叩かれまくってる反動か、BvSを過剰に擁護する人たちがいるね。『人生で最高の一本』だとか」
女「何言ってんだか」
男「そういう人には『君はもっと映画を観る必要があるね』としか言えないね。人生で他に観た映画がこの前の『ファンタスティック・フォー』だけなのか？ 『市民ケーン』を観てみなさいよと。どっかからダークスリラーの名作リスト探してきてさ、かたっぱしから鑑賞すればいいよ。そうすれば暗い世界観に相応しいキャラ造型やストーリーメイクが理解できるはずだよ
世の中にはもっとすばらしい映画があるんだって、増田にも知ってもらいたいな」
参考：
https://soundcloud.com/rottentomatoes/batman-v-superman-is-rotten
