  |
はてなキーワード: 脆弱とは
ずっとふざけたけもフレネタ日記ばっかり書いてたけど、真面目に解説する
なんか変なブログも増えてきたし
そんなに難しい話じゃない
許容体積が大きいだけだ
作品っていうのは、子供でも理解できる分かりやすさ（広さ）×話の奥深さ（深さ）でその許容量がだいたい決まる
ジブリとかは大体そうだろう
設定やらなんやらは非常に深いが、それを理解せずともアクションを見るだけでも面白いって感じ
けものフレンズの場合は、子供向けを装うことで広さを最大限確保している
実際子供でも楽しめると思う
深さは、元々ゲームの方で設定や文化があったので、放っておいても強い
また、ゲームにはない部分の世界観の設定や謎を小出しにすることで、更に深みを出している
更に、「ゲームがアニメの前にあったが、ゲームとは微妙に設定や時代が違う」おかげで
その差に対する考察が延々とできる仕組みになっている
（.hackの初期とかそんな感じだったと思う）
この時点で作品の許容量は十分すぎる
それが脆弱な土台に立っているような雰囲気を出すことでスリルも出せていると思う
そりゃ面白い
ただしこういう仕掛けっていうのは仕掛ければ仕掛けるほど、一個発動しなかった時全体がガタガタになってずっこける印象がある
そして全てを発動するのは中々骨が折れる作業だ
今回はいくつかの幸運が重なったのと、シリーズ構成を組んでる方が非常に上手いと感じる
いや、状況としては幸運どころか最悪の悲運に近いと思うけど、それひっくり返すんだから創作って面白いよなあ
彼が、絵本を子供のために無料にします！奴隷解放宣言！、の後に、
結果が出た後になっててから、実はマネタイズのためでお金も稼げます、
と急に方針転換をするようなとき、その都度批判が来ることに対して
「イタチごっこ」と表現したようだが、だいぶ勘違いしているのではないか。
と思っているのだろうか。相手は複数いて、一人ひとり立場が違うのだから、
異なる分野から、彼の持論の問題点についてそれぞれのベクトルから
疑問が起こるのは何ら不思議なことではない。
勝手に自分が定義した世論の代表者たる、単一の世論マンが発言したことにして、
論理の矛盾を起こしているので聞くに値しない、と一蹴するのは考えなし過ぎやしないか。
・反省が足りない
・反省してない
・正当化するな
・他人のせいにするな
・逃げるな
・自分と向き合え
・逃げグセがつく
・信用は戻らない
・大人だろ
うんざりだ。
どいつもこいつも清廉潔白な面して教科書みたいな啓発ライフハックをしたり顔で語りやがって。
辛ければ逃げていいんだよ。信用？そんなもん生きてればまたコツコツ積み上げられる。もちろん再びコツコツ積みあげるのは大変だろうよ、いま自分を追い込んでるものが自分の人生を真っ暗にしてるんだったら迷わず逃げていいんだよ。
向いてないんだよ。辛いなら逃げて構わないんだよ。
首相だってやってらんねえってんで辞職する時代なんだ、普通の自分が逃げちゃいけないなんてことはないんだよ。
辛いんだよ、正当化するな？しらねえよ。お前が俺をこの辛さから解放してくれんのかよ。
ダメなやつを偉そうに、そして同情的に啓発的な説教するのはさぞストレス解消になるライフハックだろうよ。
ムカつくんだよ。糞が！
スマホでスケジュール管理？知るかバーカ。くそったれな機械がアラートやメール上げてくるたびにストレスMAXなんだよ。
綺麗にノートとって、手帳に予定を記述するような連中にはさぞ便利だろうよ。
ただ、他人と約束がある。その時点で恐怖を感じで身動きが取れなくなってパニックになるような脆弱な人間も居るんだよ。
強くなれだ？しらねーよ。弱いんだよ。他人の意見を聞け？認めろ？
じゃあ俺の弱さも許容しろよ。弱いんだよ。精神が脆弱でバランス取るのに必死なんだよ。
ダメ人間だ？知ってんだよ。
ダメ人間は自分がダメなこと知ってんだよ。いつだって自責で押しつぶされてんだよ。
オメーに言われなくてもどれだけダメかもわかってんだよ。
他人に文句言っただけで自分の中に「お前が偉そうに言えるのか？」って声がするぐらいなんだよ。
知ってんだよ。
みんな同じじゃねえんだ。
反省するな悪いのは自分だけじゃない、正当化しろ自分を守れ、他人のせいにしろ他人だって他人のせいにしちゃいけないんじゃないのかよ？
逃げろ、いいんだよ逃げちまえ別な場所でやり直せ、自分と向き合う必要なんかねえよ嫌ってほど知ってんだろ？
逃げグセ？しょうがないだろ勝てないんだから、負けて潰れるぐらいなら逃げたほうがマシなんだよ。
信用、知らないよ何の信用だよ。クレジットのスコアでもなきゃ信用なんてまた積み重ねられるよ。
大人だろ？子供じゃないんだから？知るかハゲ、勝手に大人にすんなよいつ大人にしてくれって言ったよ？子供だって言えば面倒見てくれんのか？違うだろ。
アル中やヤク中になってないだけマシだろ。
お前らの健全で清く正しい大人の社会に適合できない脆弱な精神も存在すんだよ。
しょうがないだろ。迷惑も掛けるよ。だけどみんな誰かに迷惑かけてんだろ？
人殺しや暴力を振るったわけでもないんだ、そんなに偉そうに説教たれんなよ。
同じように感じた奴、いいんだ自分を守れ、逃げて忘れちまえ。
責める連中はお前を守ってくれるわけじゃない、自分に迷惑がかかってキレてるだけなんだよ。そいつだって自分のこと考えてるだけなんだよ。
飯でも食ってひなたぼっこして昼寝でもしちゃえ。
「そもそも子供のころから、運動会ってあんまり好きじゃなかったし」
「そういう人もいるだろうな」
「最近は、危ないとかって話もよくあるしね」
「まあ、危ないからこそって側面もあるかもしれないがな」
「逆に、小さい子になでられちゃったよ」
「バブみってやつか」
「気恥ずかしいけど、思わず震えたね」
「おいおい、どこをなでられたんだよ」
「感情」
「逆なでされたのか……」
「最終更新履歴を確認する方法も一応あるから小細工はできないがな」
「以前はタイトルすらないうえ、端的な内容だったな」
「まあ、更新されていくってのはクオリティがより上がることに繋がりやすいこともあるしね」
「その逆もあるがな」
「数ある例の中から真っ先に挙げるのがそれなのか」
※3行まとめ
・まず集めた署名をどう使うのか教えろ
・楽して金儲けしたいだけじゃないの
ソースが産経ニュースのみなので、事実と異なる点や文章の読み違いがあるかもしれません。それを踏まえて、なぜ今回の署名活動がひっかかるのかという個人的な考え。かなり否定的。
◯署名の使いどころはどこ？
記事に『若い女性ファン“刀剣女子”のパワーで展示を実現しようというもくろみだ』とあるけど、署名はどこに使うの？
一番気になるのは、SNSで集めた署名を「こんなに要望があるから刀貸してください」と所有者のところに持っていくのでは……ということ。まさか「これだけの人が見たいと言ってるんだから貸してくれますよね！！！」なんてゴリ押しに使われるんじゃないだろうな、って疑念が残ってしまう。そんな使われ方されるなら絶対に署名したくない。
そうではなくて、例えば「刀を展示したらこれだけの集客が期待されるので、この企画に援助をお願いします」と自治体や企業へ後援を頼むためとかだったら分かる。協力したいとも思う。
そもそも所有者に貸してくださいと頼むための署名だったら、SNSの刀剣女子ではなくて地元商店街や地域の人たちの署名を集めた方が論理的だと思う。「あなたの刀を見たいという人はこんなにいますよ！」という署名だけじゃ、その場所で展示するための根拠が欠けてる。「あなたの刀をここで展示してほしいという人はこんなにいますよ！」という署名もないと、わざわざ遠くまで持ち出して手間暇かけて展示する説得力が足りない。まずは地元誘致の署名を集めた方がよいのでは？
あと、「刀を見たいという人がこれだけいる！」という署名を提示したら「じゃあもっと大きい箱で展示しますね」となってもおかしくないよね。むしろそうしてくれると見る方としてもだいぶ楽です。
始めるときは、まず何に使うのかはっきり説明してから署名運動開始してください。
◯どこまで計画進んでるの？
記事を見ると、ある商業会が主催？ 以前国広の脇差を展示した美術館がある場所らしいので、恐らく展示するとしたらそこでやるのかな。
じゃあ美術館には話が行ってる？ 管理できる体制は整ってる？ 現時点ではどういう日程で計画している？ 所有者には何らかの打診をしている？
そういったことが何も分からない状態で、署名の話だけ先に出てきたのも何だかおかしい感じ。署名活動が始まるときにはある程度ご説明いただけると思うけれども、何も分からずに署名はできない。
というか、筋としてはまず構想を説明を出してから「署名お願いします」じゃない？ 何でいきなり署名のニュースが出るの？ もしかして全然進んでないの？ 進んでないのに署名とかおかしくない？
特に最後の、所有者への打診が一番気になる。他人の持ち物を借りる話を、本人の知らないところで勝手に進めてるってならかなり心象悪い……まず所有者に話を通して、それからの計画じゃない？ 「今はまだ案だけですが、後で正式にお願いさせてもらいます」くらいは通しててくれないと署名なんてできない。
そもそも署名集めても所有者に断られたら計画全滅だよね。そうなったらどうするつもりなんだろう。まさか署名集めたらほぼほぼ成功するなんて思ってないよね？ 「我々は本気で展示したかったけど断られてしまったので…」とか言うのかな。どう説明しても相手のこと下げる表現にならない？
◯金儲けしたいけど金はかけたくない？
ものすごく悪意を持って見ると、そんな風に見えてしまう。地元経済の活性化が第一の目的っぽいし。
別に活性化自体は悪いことではないと思うけど、だったら自分たちで全部企画進めてよ。
客寄せのエサを用意するためにも客の力を使うのかー。刀剣女子（）をいい金ヅルと思ってるんだろうな当たってるけど。
刀見たさに勝手にファンが集まって署名すると思ってるんだろうってのも、記事のインタビューから見え隠れしてる。『「全国の刀剣女子が公開を待ち望んでいる名刀だけに相当数の署名が集まると思う」』ってところね。いや…黙ってホイホイ署名する人ばかりではないからね…刀関連のグズグズ企画が倒れた例もあるからね…。
前回は市が所有してる刀だったから地元資産の活用ってことで上手くいった点もあると思う。それに味をしめたからわざわざよそから借りて更なる儲けを……ってなるとこちらも心持ちが違う。
はっきり言っていけすかない。
そもそも署名がないと実現不可能なくらい脆弱な企画ならやらなくていいよ。しかるべき博物館や美術館でてんじされるのをあと数十年待ちますんで。
あとこれ、記事の書き方もなかなか悪く見える。もし記者がこの署名運動に否定的であえてこんな書き方をしたなら相当凄い。
（でも主催者のツイッター見ると、この記事を割と肯定的に引用ツイートしてるんだよね。商業会としてもこの記事の書き方や見方は間違ってないということなのかな？）
あと、展示が叶えられた結果なにかトラブルや破損があるのも嫌だけど、この企画を断ったあとにどこかで展示がされるときに「あのときは断ったのに！」とか凸する人いそうで嫌だなー。
成功しない限り誰かしらが損しそうな企画だ。今後詳細が発表されたら、不安点が解消されてることを祈る（解消されても署名するかどうかは…）
追伸
他の刀だって経済活性化のために使われてる！という意見もあるだろうけど、所有者マターで進んでた企画がほとんどだと思う。今回のように第三者が主導して、しかも署名というのは……
あと署名って、書いたら「私はこの企画に賛成し応援します」ということにるよな。刀見たいから書く！ ではなくて、本当にその企画に賛同できるかを考えてからじゃないと署名できません。
自分はすごく面白かったんだが、「面白かったね～」って言ってたら「あーーｗｗ俺あの映画だいっきらいだわｗｗｗ」とわざわざ口出ししてくるひとが居て、好きな映画だったはずなのにもうそれで色々と萎えて、楽しかった思い出が全部ぶっ飛んでしまった。もうあんまり思い出したくない。
すごく悲しかった。
まあ自分で気付いていないだけで、同じようなことをわたしもきっとこれまで繰り返してきたんだろう。対人コミュニケーションとは傷付き傷付けられることだし、多くの場合勝手に傷付けられる方が悪い。繊細ヤクザという言葉もあるし、そうならないよう、自分ももっと愚鈍であらねばならない。そう思って溜飲を下げようとしている。
--
本当はその楽しかった思い出を、向こう半年くらいは反芻しながら生きていくつもりだったのに。今はその作品について思い出そうとすると、あのときの場の変な空気とか、自分の子供っぽい激情とか、数刻後にどっと押し寄せた疲れと悲しみが思い出されるので、後悔しかない。↑のひとに対して多少ムムときたのは否定しないが、自分への怒りと後悔の方がそれに勝る。自分がもっと他人の価値観を尊重したうえでコミュニケートできるような人間であれば何も問題はなかった。
--
google:image:オフショルダー@Google画像検索
画像で見ていただくと分かる通り、いわゆる肩が全部出ているタイプの服である。鎖骨とか見える。
ドレス系に多く見られ、ものによればキャバ嬢がよく着てそうと思われる方もいるかもしれない。
他方で、中学生〜高校生が初めてのデートで気合入れて着ちゃう服であったりもする。
オフショルダーと聞いてまず感じるのは、ブラ紐がなぜ見えないのかという疑問である。
一部の場合や、アイドルグループが着る多くのパターンでは、「レースような可愛い肩紐をそのまま見せている」「透明のビニールタイプの肩紐が見える」パターンもあるが、先のGoogle検索でもわかるようにない場合も多い。この疑問に対しては、調査により以下のような事実が判明している。
まだ上の疑問が解決積みでいない紳士の諸君は以下の画像検索により知見を深めて欲しいが、以下のようなものが存在する。
これらの存在価値が「肩紐を見せないため」だけにあるのかは私の調査では不明であるが、このような商品が開発されている以上、「オフショルダーの服を着ている女性はブラジャーをしていないのではないか？」という仮説はほぼ100%の可能性で否定されると考えられる。
物体は重量に従い落下する。そのため、どのような服であっても肩などの突起部分に引っかからないかぎり、その位置で静止できないのが常である。
通常Tシャツなどは肩がその支えとなる。しかし、オフショルダーの服はその肩をオフしている。実に興味深い。
腕は鉛直下向きに向かうにあたり、幅をもって広がっている傾向にあるため、「オフショルダーの服は腕によって支えられている」という仮説が成立しうる。
しかし、では、オフショルダーの女性が腕を躰側へすぼめると、すっぽり脱げてしまうのだろうか？いや、そんな脆弱な服であるはずがない。
となると、やはり、紳士としてこの仮説をたてるのは非常に恥ずかしく、心苦しいのだが、まさかあの、おっぱいによって支えられているんだろうか？
おっぱいがその支えになっていると考えるのは自然かもしれないが、それは決定的な答えにはまだなっていない。
なぜなら、おっぱいが小さめの人でも、オフショルダーの服を着ている状態を見たことがあるからだ。彼女は無理をしていたのだろうか。
あんなに可愛いオフショルダーの服が「おっぱいが大きいか、大きくないか、そこが大切なんだ」というシェークスピアのような命題を掲げる服であるとは、到底信じたくはない。
もしくは、実は先に上げた肩紐のないブラジャーにからくりがあるのだろうか？オフショルダーの服は、実はクリップがついていてブラに挟み込むのだろうか？
金さえ有れば良い教育が受けられて、良い人生が過ごせると思っている皆さん、間違いです。
金持ちの子は良い教育を受けて、良い学校に入り、良い仕事につくというのは一面の事実では有る。
本当の所は「まともな親は、比較的金持ちに多い」のだ。まともな親に育てられるからまともに育つのであって、金持ちだからまともに育つのでは無い。
子供が家に帰ると親が寝転がってポテチ食いながらワイドショーやお笑い番組を見ている。
喫煙者、安酒飲み。
趣味はパチンコorスマホゲーor改造車、宝くじを常習的に購入。
仕事は単純作業or非正規、数年かけてスキルやキャリアを積む仕事についた事が無い。
例えば、上記のような暮らしをする人間に、いくら金をやってもまともな子供は育たない。
貧乏人の子供は貧乏になる確率が高いのだが、それは最も長い時間を過ごす家庭がそのように運営されているからだ。
多くの金持ちの家庭はそうでは無い。
家に帰ると宿題を見てくれて、親は休日に美術館に行ったり読書をしている。子供は自然に学び、本を読み、豊かな文化的素養を養う。
整理整頓は自分の人生を効率的に生きる手段である事を身をもって教えられる。
海外に友人が居る。子供の頃から多様な文化に触れ、その中でアイデンティティを確立する機会が有る。
積み重ねた努力で、ある程度の地位や仕事についている人に囲まれた生活をしている。努力すれば、具体的にどうなれるかを日常的に見ている。
両親共に大学を出ている。子供の頃から大学に行くのが「当たり前」になっている。海外へのホームステイや留学も視野に入り、経験者の話をいつでも聞ける。
高い能力を持つ人に囲まれ、日々の生活の様々な場面で礼儀を学び、見聞を広げられる。
このような日々の暮らしこそが「文化資本」なのである。カネを持っている事など、瑣末な事でしかないのだ。（もちろん文化資本の無い金持ちも居る）
例えば貧乏人にカネだけ与えても、こんな暮らしは出来ない。せいぜい半額惣菜が外食になり、しまむらの服がブランド物に変わるくらいだ。（文化資本を持った貧乏人という存在は極めて少ない。）
東大に入る学生の親は約半分が年収1000万以上だと言う。日本の年収比率から考えれば明らかに偏っている。
もちろん、小学校からSAPIXをはじめとする有名塾に通える環境も一助にはなっている。まぁ塾代だけで、本気で通わせると小学1年から高校3年までで1000万以上かかるし。
しかし、家庭環境が壊れている子供をSAPIXに通わせたとして、有名私立に入れるか？と言われれば無理なんだよね。最も重要な家庭での学習が出来ないから。
良い教育とは、まず最初に家庭で行われる。家庭で教育を受けられない子供は、最初から大きなビハインドを食らって社会に出る。そこにいくらカネをつぎ込んでも無駄。
稀にトンビが鷹を産むが、そんな子供は現在の制度でも返済不要の奨学金がいくらでも有る。
格差とは経済力では無い。本当の格差とは、誰もが選べない幼少期の環境の事なのだ。
教育に過剰な期待をしているブコメが多いけど、家庭でするべき教育を学校が肩代わりしろと言っても無理ですよ。
何事も本人のやる気が無ければ始まらないのだが、その「やる気」をステロタイプな貧乏親は削りとる。
まともな親の子供は親＆周囲のまともな大人からやる気をもらい続ける（ついでに良質な知識、コミュ力、広い見聞も）
要するに、日々の生活が追い風になるか逆風になるかの差がデカイのだ。これに比べれば、スタートラインの差など無いに等しい。
教育費を無料にした所で、大学に遊びに行くバカと、目標持った優秀な学生に二分されるだけ。
優秀な学生は大体親が金持ちだし、そうでなければ奨学金を取れる。
教育費無料なんて教育関係者のポジショントークでしか無いよ。乗せられている貧困層は利用されているだけ。
解決策は無いのか？という話だが、これ以上のバカの底上げは無意味なのでしない方が良いという立場だ。
そもそも日本は、ホームレスですら字が読める国だから、初等教育は行き渡っていると言って良い。
教育費でよく話に出てくるOECD各国だが、字を読めない人が普通に居る国だらけだからな。
日本の識字率は99%以上だから、初等教育（バカの底上げ）に成功している国とも言えるのだ。
巷で叫ばれている大学無償化、奨学金返済不要については、費用対効果が悪すぎるのでやめた方が良い。
20年ほどクズ親に育てられれ、何の文化資本も持っていないFラン大学生なぞ、支援しても無駄だから。
一定数、世間知に長けたワンチャンを掴める層は居るが、そいつらは放置してても勝手に伸びる。学校教育の範疇ではないからな。
やるなら一定以上の偏差値を持つ世帯年収が低い家庭の小中高生に集中して支援するくらいか。
しかし、いずれの場合もバカの感染を防ぐために寄宿舎で預かる必要が有るが、日本でやる事は不可能だろう。
日本国が行う学校教育に幻想を持っている人が多すぎだが、そもそも東大すら世界的には有象無象の一大学でしか無い訳で、本物のエリートは欧米やアジアのエリート養成大学に行ってる。
ただし、日本でエリート養成をする事は無駄に平等を重んじる文化から無理だろうなと思う。
みんな平等に格差をなくそうという思想はご立派だけど、現実的に考えると家庭に介入出来ない限りは不可能だという事。
国（あるいは他人）に出来るのは自力で一定ラインを超えてきた人を支援するくらいだ。
やる気のない（あるいはやる気を奪われた）人は、自助努力が出来ないので救いようがない。
共産党の機関誌である「前衛」を読んでいるコミュニストが、この記事をネタに書いているので見てみた。
http://d.hatena.ne.jp/kamiyakenkyujo/20160605/1465138757
まぁ一言で言えば「そう出来たらいいですね、ところでどこから金が出てくるの？」である。
松本は、さらにそこから夫が主な稼ぎ手で、妻が専業もしくは補助的な労働でそれを支えて、子どものケア労働を担当する「標準家族モデル」がいかに危機やトラブルに脆弱かを述べる。
そして、もし子どもに関わる費用をすべて社会が負担するようになれば、親は自分の食い扶持さえ稼げばよくなり、シングルでもダブルでも不利や不公平は解消すると述べる。これこそが「強い家族」なのだと。
さらにこう続ける。
もし小学校や中学校のように、高校や大学に誰でも行けることはおろか、医療も住宅もそして食事や文化に触れる機会も、子どもが無料でアクセスできるようになれば、その時初めて子どもの貧困は親の責任から切り離される。そこまで社会を進めることの覚悟とセットでなければ、容易に元増田のような非難に遭遇するハメになる、と松本は警鐘を鳴らしているのである。
ユートピアを追求するコミュニストらしい意見だ。で、そんな国どこにあるの？日本人は1億人以上居るので、中東の産油国でもこんな暮らし出来んぞ。
ちなみにその理想を実現しようとした国知ってる、ソ連とかいう強制収容所国家だ。
まぁ共産主義者に財源を追求しても仕方ない。彼らは責任をもって行動した事が無いのだから。
仕方がないので、テキトーだが俺が考える。
日本の0～14歳までの年少人口は1613万人。彼らに衣食住＋文化的な生活＋学習を無償化したとする。
かなり安めに見積もって1人1ヶ月10万円の経費がかかるとして、1年で120万×1613万=19兆3560億円
更に高校生、大学生まで含めると900万人ほど増える、1人月10万で年間10兆円ほどかかる（年齢が高くなるほど消費が増えるが、面倒を見る職員の数は減らせるので同じ経費とする）
合計して約30兆円、数字を見ただけで非現実的だとわかるだろう。
まぁ所得税を3倍にすれば実現可能だ。もしかしたら、共産主義者として望む所なのかもしれない。
現在の日本において、財源を示さずに甘い夢だけを語るのは誠実な態度だろうか？
耳障りの良い話、目の前の人を気分良く救える話は正しいのだろうか？
共産主義者は家族の解体を是とする。旧ソ連では集団主義教育が行われていた事は周知の通りだ。
全ての子供を「学習はおろか、医療も住宅もそして食事や文化に触れる機会も」親の責任から切り離す覚悟が問われるそうだ。
まさしくコミュニストに相応しい思想ですねとしか言いようが無い。
ちなみに私が提唱する解決策？はこんな感じ。ブコメにも有ったが、教育は数世代で解決するしか無いので、まず1代目はお金を稼ごう。
1代だと所詮成金なのだけど、2代続けばその子供は教育が行き届くようになるだろう。
http://anond.hatelabo.jp/20160225194038
とりあえず年収1000万くらいにはなって、経済活動に貢献してから社会保障を語ろう。
元の増田が克服できていないであろう・これから直面するであろう問題を指摘している。
非常に思いやりに溢れていた文章だ。
しかしながら、この増田もまだまだ自分の抱える問題を克服できていない、かつ、
簡単な言葉で表すと、「自分の人生を歩めなかったこと」が彼女を蝕んでいる。
そんな自分を認めることで、それすらも認められていない人間と差別化し、プライドを保っているように思えるのだ。
彼女は未だにプライドに縛られ、本当にやりたいことを抑えているだろう。
彼女は、ある程度自分のプライドが保たれるレベルの組織の編集者のみを想像しているのではないだろうか。
それは結局、編集という仕事に対する情熱ではなく、自らのプライドを保つための餌でしかないのではないだろうか。
もしくは、「編集者になりたかったこと」自体が防衛機制に過ぎず、自身へ向かうネガティブな感情の原因をそこに向かわせることで、
他のコンプレックスから目を背けようとしているのではないだろうか。
内心彼女はどんな行動をすれば清々しい人生になるか気づいているのだろう。
それをしてうまくいかなかった時、プライドが傷つくのが怖いのである。
このままではいつまでたってもプライドを保つために生きていくことになるだろう。
１０年後には自分の人生に対し、別の原因を持ち出して正当化している姿を想像してしまう。
やりたいことを考え、一度プライドを砕かない限り難しいのではないだろうか。
しかし、現実の人々は自らのコンプレックス立ち向かい、プライドをズタズタにし、血みどろになる経験をしているものだ。
向こう見ずなり、愚かなどではなく、自分の欲望・人生に対して真摯なのだ。
そこから逃げてきた人たちが、逃げてきた自分を正当化するために脆弱な理屈をこねくりまわし、
プライドを保とうとしているのをよく目にする。
http://www.nicovideo.jp/watch/sm23488282
彼は社会学者としての立場から法律や改憲論者と論壇で登って答弁しているわけだが、オレには佐藤氏と古市さんとの間で話がまったくかみ合っていないように思える。
正直、この佐藤という人を含め、古市さんを叩いてる人にはマーケット感覚がないんじゃないか？と思うんだが、具体的にどうやってそれを示したらいいのか見えてこない。
山本みずき氏との論壇でも同様だと思う。山本みずき氏にはマーケット感覚がない。一方で古市氏にはマーケット感覚がある。
議論のレベルがかみ合ってない。山本氏も佐藤氏も、社会の泥臭い面や言葉通りにいかない部分が見えてない。古市氏の方が社会を間接的に知る手段が豊富で信頼できると思うんだが
同じように思ってる人はいないのかな。。。
一応個人的に考えてみた内容をまとめてみたので、知見のある方々の指摘や修正がほしい。
是非論駁してみてくれ。
個人的な思考なんだが、『佐藤氏』と『古市氏』のバックヤードに目を向けてみた。
ソースはwikipediaくらいしか簡単に示せるものはなく、佐藤氏のことはオレはほとんど知らないので、あまり知ったようなことは言えないんだが・・・
『佐藤氏』
『古市氏』
https://ja.wikipedia.org/wiki/%E5%8F%A4%E5%B8%82%E6%86%B2%E5%AF%BF
佐藤氏の両親は政治学者と弁護士。つまり歴史と法に重きを置く典型的な法学部タイプ。日本は法治国家で資本主義として成功した社会主義タイプなので、佐藤氏は典型的な右派で保守的なタイプ。
一方で古市氏は環境情報から社会学へと転向した。つまりバックヤードとなる知識や感性は科学者タイプ。
ゆえに、古市氏の論じる分野には必ず〝マーケット〟がある。お金と結びついて物事を考える発言がきちんと身についている。またそこに時価がある。
ここで勘違いしてはいけないのは〝経済〟や〝金融〟ではない、ということだ。要するに〝政治色〟が薄い。よく言えば庶民的。別の言い方をすると〝資本主義的〟。
また彼は友人に起業家を持っており、堀江貴文を含め、財界との繫がりも多い。ほりえもんちゃんねるなどにもよく登場する。
これを〝強い者に擦り寄る〟と表現するものもいるが、そのあたりの〝評価〟は置いておいて、マーケット感覚を得られる環境にいることは間違いない。
http://blogos.com/article/154867/
例えばここで古市氏は『すき家は企業が社会にもたらした社会福祉のひとつ』と述べたことで叩かれているが、なにが間違っているのだろう？と思う。
マイクロソフトをはじめとする新時代の新興企業の多くは、既存の制度を上手に利用して新しい形の報酬を従業員に還付している。
（※その代わり徹底的に税金を逃れている！ ←善し悪しは置いておいて、事実そうである）
どの国に所属しているかよりも、どの会社に所属してその会社が与える福利厚生を受けられるか
ストックオプションを行使できるか、金融資産を持てるかどうかが豊かさへと直結する時代になったのに、いったい何故古市氏の述べていることが的外れなのだろうか？
シリコンバレーでは福利厚生を提供するサービスを行っている会社がＹコンビネーター出身者によって起業されている。
ケータリングサービスやタクシーチケット、社宅システムなど、上げればきりがないと思うのだが・・・
http://asread.info/archives/722
日本に自衛権があることを古市氏は知らなかったと述べているが、これもある意味で間違っていないと思う。
実際のところ、実質的に自衛権を行使できなかったことには違いない。
・ミサイルを発射されながらもそれを撃墜できるのは日本に駐在している二機の米軍潜水艦のみであること。
・敵国が領空侵犯をしても命令がなければ撃墜できない。引いては物理的に〝敵飛行機を押す〟という意味不明な対処しかできない
これらの現行法の脆弱さをどれだけ学者やSEALsは理解してるのだろうか？
http://trafficnews.jp/post/46566/3/
自衛権は認められているが、〝実質的に言って認められていない〟ことと一緒。
であるにも関わらず、古市氏が『日本の自衛権って認められてるんだ…』という発言を〝知識がない〟〝教養が無い〟と評価する論調はいかがなものか。
一方で佐藤氏にはマーケット感覚が無いといえる理由はここにある。つまり法律や政治に関する学問を背景にしているところに問題がある。
この手の人間がやっかいなのは、やたらと知識や雑学は多く言葉に言葉を返すのは上手いのだが、思考回路に多くの前提条件や知識条件が抜け落ちていることが多い。
言ってしまえばマリー・アントワネットのタイプだ。
古市氏の発言が法学や政治に強い識者から叩かれやすいのは何故だろうか。
それは叩く者たちが〝歴史の変遷〟が、実は〝市場の変遷〟であること、をよく分かっていないからだ。
市場経済はより自然科学的だ。お金は政治や法律によって生まれたわけではない。自然に発生して、それが整備されて整えられた。実は人類が進化の果てに手に入れた概念だ。
軍事力と経済力のふたつは大国の力を現す両輪と考えられるが、実は歴史を手繰ると三番目の車輪があったことが分かる。その名も〝宗教〟。
鎌倉幕府の台頭に現れているように、歴史的に見ると既にこの頃から宗教の力は徐々に衰えを見せており、政治と軍事力の二つが世界を動かしていたと言える。
表の世界での政治はほとんどが宗教と密接に関わっており、もっぱらここが市民と政治の大きな接点であったと言える。
一方で軍事力は実質的な世界の掌握と統治を行う役割を担っていた。
少なくとも、日本においては明治維新でサムライが不要となるまではそうだったのだ。
しかし第一次世界大戦、第二次世界大戦に代表されるように、軍事政権は失敗を迎えた。
正しい仕方で行使されなかった軍事政権は、共産主義や社会主義を生み出したからだ。
一方で米国のような市場経済を中心として発展した国は一定の成功を収めた。士・農・工・商のうち、最後に勝ったのは商人というわけだ。
マーケットは〝国の力が弱まりつつある〟ことを明らかにしつつある。既に鎌倉幕府の時代から、政府が持つ立法の力は軍事力か経済力のどちらかを担保にしており、宗教はアイドルでありスケープゴートであったに過ぎない。
そして過去〝政（まつりごと）＝宗教〟が中心だった国家は、現在政治の中心を〝経済〟へと移している。
軍事政権が実質的な掌握を行っていた政治は、現在では財界が実質的な掌握を行う社会へと変化した。そしてそれは加速していく。
実際、国が提供する福祉よりも企業が従業員に提供する福祉の方が優れている場合が多い。しかもマーケットに従った結果なので、相応の人材を兼ね備えており、無駄が無い。
パナマ文書にも代表されるように、国家の枠組みを超えた企業にとっては国境など存在しないも同然。
スターウォーズの通商連合のように、もはや国とは独立した別の政治形態と言って差し支えない。
戦後70年の間で形成されてきた常識などいくらでも覆る。今後の歴史は大転換を迎えると考えてまず間違いない。
その意味では、いまだに全時代的な歴史の踏襲と繰り返し論議を重ねる、マーケット論の無き法学者や政治学者が出る幕は実質的に言って存在しない。
宗教がその存在を弱めたように、政治もまた本質は思想であり宗教であるから、その実質である軍事力や経済力のいずれかに依存せざるを得ず、結果として時代に取り残される。
軍事力の台頭は世論が許さないだろうし、世界もそれを望んでいない。よって、これから重要になるのは、〝個人がどの市場経済に所属しているか〟である。
世界を牽引してきたのは技術革新と金融だ。宗教を背景にした政治はストーリーを創り出す力があったが、現代ではその力は失われている。
闇雲に政治を追いかけても歴史を追いかけても真実は見えてこない。
必要なのは産業界の歴史を追いかけること。経済史の発展と衰退の繰り返しの中に答えがある。
古市氏がどういう器なのかは知らないが、少なくとも歴史と現状を比較して将来を占う上で非常に恵まれた立場にいることは間違いない。
彼は川上の最新情報にアクセスできることが可能で、新時代のリテラシーも十分持っている。
法学者も歴史学者も、企業の間接部門でしかない。プロフィット部門ではない存在の者たちがとやかく言う論壇や議論に意味はない。
その点は古市氏も同様だが、彼は自分の立場が弱者であることを自覚している分、市場に対する的確な論壇を展開できる下地がある。
叩かれるのがその証拠だ。叩いてる奴らのほとんどはマリーアントワネットばかりなのだから、叩かれている姿を見てむしろ安心すべきだ。
アンタ雑だな・・・
そんな言い方じゃ誰にも信用されないでしょ
まず、Windows10 がスパイウェアだと言われているのは下記のブログに詳しく書いてあった
http://d.hatena.ne.jp/msystem/20160409/1460127785
引用すると
Microsoft社の契約内容には、次のような一文が含まれています。
『 プライバシー、データの使用への同意。お客様のプラバシーは、当社にとって重要です。本ソフトウェアの一部の機能については、当該機能を使用する際に情報が送受信されます。 』
つまり、「Windows 10を使うことで、個人情報がMicrosoft社に送信されるが、その点を了解した上で、Windows 10を使う事に同意します。」と言うことです。
一応、情報がMSに送信されるのは利用規約にも明記されているが、その機能をオフにできるとも書いてある。
で、その送信する内容ってのは
下記の個人情報が、全てMicrosoft社に渡ってしまうと思います。
・連絡先
・位置情報
・利用言語
・利用URL
だそうだ。
確かにデフォルトだとスパイウェアと呼ばれてもおかしくはない。
ただ、個人的にはセキュリティサポートが切れた PC ほど脆弱なものはないので、Windows10 あげるなと声高に叫ぶのが良いこととも思えないな
新卒で入った会社を割と早い時期に辞めて地元を離れ、既に今の職場にいる期間の方が長い。早く達成したい目標があって、いろんな無理を覚悟しての転職だった。
現実、前の職場に比べれば比較にならないほど仕事に関するスキルはついたと思うが、ここに来てからあまりに後悔が多過ぎて、また転職したいという思いが日々募っている。そもそもの目標のために手放したものがかなり大きかったのだが、その目標だったものすら既に失われて久しい。十を得るために五を捨て、今頃得られていたであろうその十も、もはや手の届かないところにあるというわけだ。
目標のための覚悟は、目標が失われた時、自分でも驚くほど脆弱なものになってしまった。辛い現実に向き合うための唯一の支えとなっていた言葉は、無機質な文字列となり、今となっては虚しく響くだけだ。結果、日々心に疲労だけが蓄積していく。
後悔は先に立たない。振り返った時初めて、その数に驚き、自分がどれだけ間違ってきたのか思い知るのだ。
ここ数日の都内の道は案の定どこもクソひどい状況だった。
なんの理由もなくクラクションを鳴らす人間なんて基地外くらいなものなの。
ってことはクラクション鳴らされて切れてる人間は、基地外に切れてる痛い人間か、鳴らされてる理由があるのに逆ギレしてる人間ってことに他ならない。
「右折信号の2～3秒が待てねぇのかよ」「車線変更に鳴らすなよ」「法定速度守ってるのに鳴らすなよ」
これ、運転が下手な人間の常套句ね。ついでに言うと、事故をおこす人間のほとんどがこういうこと言う人間。
右折信号で曲がらない車にクラクション鳴らすのは、何も自分が曲がりたいからじゃないの。
自分より後ろにいる曲がれないかもしれない人のために鳴らすのだよ。
曲がれる人にとってみれば2～3秒でも、その信号で曲がれなかった人には数分になるから。
それで無理な右折して事故でも起こされたらそんな夢見の悪い話ないからね。
かと言って一番後ろの車が鳴らしても誰に鳴らしたかわからんだろ。
だから2台目の車は、自分の役割だと知っているから鳴らすんだよ。
それに切れるとか何？バカなの？なんで教えてくれてありがとうって言えないの？どんだけ身勝手なの？
2～3秒待てねぇのかよとか、恥ずかしいセリフよく言えたもんだよな。
車線変更で鳴らされるのは、事故に繋がるような危険な車線変更だから。
運転には流れというものが会って、それを無理に止めようとすることは危険なことなの。
皆がプラス10キロで走ってるとしてその中に法定速度の車があったら、それはつまり時速10キロで走る車の中に止まってる車があるってこと。
流れてれば危険がないのに、そこに法定速度の車があることが危険の原因になってるんだよ。
自分で自分の安全を確かめず人が用意した安全基準鵜呑みにしすぎ。
国に基準基準って叫んでおいて、自分からは身を守ろうとしないの。
ドライバーが最も大切にしなくてはいけないことって何か知ってる？
この言葉の意味がわからないならすぐに運転をやめて免許を返した方がいい。
交通インフラやタクシーつかったほうが結果的に割安になる。遅かれ早かれ事故を起こすのはこれを理解できていない人間だから。
「事故を起こさないための安全に対する配慮」は、もちろん大切なことだけど一番に大切なことではない。
なぜなら、事故の原因の大半は、流れを無視した（もしくは全く読めない）人間による自分勝手な行動だからだ。
もっとわかりやすく言うと、事故を起こさないように慎重な運転をすることが、事故の原因になってるっていうことだよ！
さっきも言った通り、流れができている中で流れに反する行動をとることは＝リスクなの。
慎重になりすぎて交差点で何度も踏むブレーキ、予測できないようなタイミングでする車線変更、流れができあがってる中で頑なに守ろうとする法定速度。
あなたがどう考えていようが、これは危険な行為であるし、身勝手な行為でしかない。
事実、事故の大半は周囲の流れを無視した行動によるものなのだから。
そこには正義も悪もなく、ただ単純に”流れに沿わなかった”という事実しかないんだよ。
これを見てふざけるなって思う人は、本当に車の運転をやめたほうがいい。
「自分の権利だ！」って行使することは、それこそが自己中心的な考えに他ならないからだ。
こんな書き方をされても一理あると耳を傾けるくらいの気持ちでないと、ハンドルを握るには危険が多すぎる。
なぜなら、免許とは運転が許されるライセンスではなく、取得すれば責任の全てを負わされる契約書のようなものだからだ。
運転の習熟度関係なく、初心者も熟練ドライバーも、誰もが平等に裁かれるのが免許というシステムなの。
安全な運転方法をやさしく教えてくれる人間なんて皆無な世界の中で、たとえ鳴らされたクラクション一つからも、次に安全な行動を取れるように学ぶ姿勢がなければ、その人間は遅かれ早かれ加害者であり被害者になってしまう。
皆が理解している通り、車というシステムは多くの歪んだ矛盾の上に成り立っているからね。
こればかりはいくら国に制度を求めても解決しない問題であり、その社会の中で身を守るには、自分が思う安全を押し付けるのではなくて今目の前の流れの中で一番に安全な行動を選択することが何よりも大切なんだよ。
事故で人の命を奪ってしまうということは、加害者になると同時に被害者になるということでもある。
誰よりも安全に配慮していることだけをプライドのようにハンドルを握っていたわたしの父ようには、誰ひとりとして絶対になって欲しくない。
舞台「刀剣乱舞」を観に行った。結論から言うと自分のせいで後半半分しか見られなかった。
12時開演なのに14時開演と勘違いし、1時間ほど見逃してしまった。会場に貼ってあるポスターの公演日程をぼーっと眺めている時に気付いた。頭が真っ白になって慌てて受付に行ったら、途中から通してくれた。
自分の勘違いでいろんな人に迷惑をかけてしまった。一緒に観に来た妹にはどんなに謝っても足りない。また、途中入場にあたって対応してくれたスタッフの人にも手間をかけさせてしまったし、何より演出の邪魔をしてしまったことと他の観劇者の邪魔をしてしまったことが申し訳ない。せっかく劇の世界に没頭していたのに、私が入ったことで一瞬でも気が逸れてしまった人がいるかもしれない。絶対いると思う。
やむを得ない事情があっての途中入場ならまだしも、自分の勝手な思い違いのせいで大勢の人に迷惑をかけてしまった。舞台上からも途中入場した人が見えるのか、と考えるといたたまれなくて情けない。同じ作品でもその場限りの、一期一会の劇になるのが舞台の醍醐味だと思う。それをほんの少しでも壊してしまったのが悔しい。自分が馬鹿すぎて泣けてくる。
今回の失敗が起こった要因は以下の3点だと思う。
1、スケジュール管理の怠り
…前日妹に公演時間を聞かれた時、チケットを確認もせず「14時からだよ」と答えていた。また、スケジュール帳を見返したら「14時」と一度書いた上から「12時」に修正されていた。4の字の上から無理やり2を書いていた。
2、雑な計画
…東京に出れば、電車もバスも5分刻みで来るから来たものに乗れば着くだろう。多分1時間前開場だからそれくらいに着けばいいだろう。荷物はどこかに預けられれば預ければいいだろう。全てをそんな風に雑に考えていた。
…今月は様々な舞台・イベントが立て込んでいて、特に忙しい時だった。その分他の予定と時間がごっちゃになり、勘違いが起こったのではないか。
言い訳がましく並べたが、一番思うのは「舞台に対する関心が低くなっていたのでは」ということだ。そんな事はないと言いたいが、「そんなに好きならどうして時間を勘違いするなど馬鹿なミスをやったのか」と言われると返す言葉がない。「そこまで好きじゃないから間違えたんじゃないの？」と言われても、私には反論する資格がないと思う。
いろんな予定が重なって、関心が分散していたことも否めない。あっちもこっちも考えているうちに、ひとつのイベントをちゃんと確認するのを怠っていたのではないか。
どうにか反論できるなら、「関心が低かった」のではなく「不誠実だった」という方が近いと言いたい。公演をとても楽しみにしていて、ちゃんと気を配っていたつもりだったのは本当だ。しかし気持ちだけでは意味がない。実際の行動を客観的に誠実・不誠実の観点から見たら、私は確実に不誠実だ。
言い訳を重ねて見苦しいと思うが、できない人も自分ではちゃんとやっているつもりなのだ。ただし「やってるつもり」の基準が他の人より低いのだと思う。だから気持ちだけで言えば、できる人と同じくらいできない人も人事を尽くしている。気持ちに見合う行動が何なのかを分かっていないから、不誠実になってしまうのだと思う
今回の失態を繰り返さないためには、
◯予定を立てる時でなく、確認する時もチケット等を見て行う。同伴者がいる場合は、一緒に見て確認する。
◯自分のことを信用しすぎない。特に自分の記憶力は信用しない。必ず調べて確認する。
ということを大事にしたい。
しかしこれらができる人なら、そもそもこんな間違いはしないはずだ。これができないから間違える。20数年生きててこんな基本的なことができない人間なのだから、おそらく私は数年後また同じようなミスをする気がする。今はこれほど悔しく思っていることでも、数年経ったらまた油断しそうだ。妙にプライドが高くてめんどくさがりだから、自分を疑うということをすぐに怠るだろう。なので忘れないように、ここに書き記しておくことにする。思っているだけよりは文字に起こした方が自分の馬鹿さと向き合えるだろう。
今回の失態で痛感したのは「注意してくれる人のありがたみ」だった。先に「できない人はできる人と気持ちは同じだが行動の基準が低い」と述べたが、これを治すには行動の基準そのものを是正しないとならない。しかし大人になると、ああしろこうしろと注意してくれる人がいなくなる。そのため自分の行動が正しくなくても、気付くことができなくなる。
私の場合は実家暮らしなので、まだ母が叱ってくれる。今回の件も説明したら大爆笑したのち具体的な改善点やこれから注意すべきことを教えてくれた。上記の反省点も母の言葉を倣った。ちゃんと叱って、教えてくれる人がいるというのはありがたいことだと思った。慰められたり笑い飛ばしてもらったりするのも良いが、注意をくれる相手を大事にしなければという当たり前のことに改めて気が付いた。綺麗事や道徳心ではなく、本当に身に沁みる。
最後に、わざわざ舞台「刀剣乱舞」の名前を出したのはこの舞台が最高の舞台だったからだ。私に感想を言う資格もないと思うが、途中からでもすぐ飲み込まれるほどの迫力と展開、役者さん達の演技や役作りの完成度に圧倒される。素晴らしい舞台だったからこそ、自分たちの思い出に水を差したことも会場の空気を少しでも乱してしまったことが腹立たしい。私ごときの途中入場に影響されるほど脆弱な作品では決してないのだが、それでもほんの少しだけでも穴を開けてしまったのは事実だと思う。自意識過剰かもしれないが、本当に悲しくて悔しい。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
