  |
はてなキーワード: 原文ママとは
あっ君これヨッピーを本当の意味でイケハヤ化しないために釘を刺したかったんでしょ?そうなんでしょ？
そんな僕の妄想はどうでもいいぞ本当にどうでもいいぞ。
それよりも大事なことは、
yoppymodel 処方箋商売なんてやろうと思ってないよ。本の中でも明言してるけど、僕はそもそもファンの人達からお金取る事はなるべぬしないようにしてるし、今回の本の印税も全額何かしらに還元しようと思ってる
もちろん「ぬ」は問題はない。当然タイピングミスなど拾っていいのは雑魚だけだからだ。
本の中でも明言してるけど、僕はそもそもファンの人達からお金取る事はなるべぬしないようにしてるし、今回の本の印税も全額何かしらに還元しようと思ってる
これがブコメの限界と呪縛なわけで、この内容が本の中でどのように書かれているかわからない。
ファンからお金を取らないってことはファンからお金を取ることを良しとしていないということだ。
とも思ったがちゃんと「なるべぬ」（原文ママ）としていてるからいいや。
ということは問題はこっちだけだ。
うーん。成果物に対して得た正当な対価はちゃんと自分の懐に収めてほしい。
それか、こういうことはバラさずに、いきなり「【PR】本の印税全額使って〇〇やったったｗ」みたいに盛大にやってほしかった。
なんかやるぞーやるぞーつって身構えたらどんな名コンテンツも80％魅力減だよ。
一応「何かしら」つってるからヨッピーの口座に入金するだけでも何かしらの還元であることに間違いはない。
というよりそれが一番である。
事件の概要はITmediaの記事(後述)でだいたい把握できるが、リアルタイムな流れをまとめる。
Wantedly（ウォンテッドリー）のIPOがいろいろ凄いので考察
https://megalodon.jp/2017-0825-0115-02/https://blog.inst-inc.com:443/wantedlyipo/
どこかのIT企業社長が、公開されている資料をもとに、来月に予定されたWantedlyのIPOを「けちくさい（要約）」と批判する。
はてブ数はそれなりにあったが、特に炎上というほどでもなく、何もなければこのまま忘れ去られていたはずである。
Wantedlyにツイートを消された（かもしれない）
https://anond.hatelabo.jp/20170824225804
上記のブログのURLをツイートしたものがDMCA申請によって削除された、他にも何人かツイートを消された人がいるようだ、と増田で報告される。
WantedlyのIPO批判記事、Google検索から消える 「写真を無断利用された」とWantedlyが削除申し立て
http://www.itmedia.co.jp/news/articles/1708/25/news063.html
はてブを中心としてSNSでこの話題がバズり始めた頃、IT関連ニュースサイトではそれなりに信頼性の高いITmediaで記事がアップされる。
この記事が出るまでは「DMCA申請は騙りが可能なので誰かのいたずらかもしれない」という可能性が残っていたが、Wantedly社の回答によって同社が申請したものであることが確定した。
ttps://wantedlyinc.com/ja/news/entries/436
小学生が書いたような謝罪文でWantedly社が燃料を投下する。
修正前は「無断で引用（※編注：原文ママ）」という部分が読者の笑いを誘っていたが、Wantedly社からクレームがあったのか、「無断で利用」に修正されている。しかし文末にその旨書かれているため隠せていない。岡田記者マジ鬼畜。VALU退会記事のときはIT戦士（笑）とか言っちゃってすみませんでした。やっぱりあんたネットのことよくわかってるわ。
ttps://www.wantedly.com/users/8558
はてブやTwitterで、仲暁子氏のプロフィールページのヘッダに使われている女優の変顔画像は無断使用ではないか、と指摘されていたが、エゴサをかけまくっていたのか、その画像が差し替えられた。
ttps://wantedlyinc.com/ja
Wantedlyトップページにあるスクリーンショット画像では仲暁子氏のプロフィールページが使われており、「プロフの画像を差し替えてもこっちは前のままだよプゲラ」などと、はてブ等で笑われていたのをまたしてもエゴサで見つけたのか、こちらも数時間後に差し替えられた。
ちなみに差し替え後のスクリーンショットに使われている吉田祐輔氏の株保有率は0.07%である。DMCA申請もすべてこの人が出している。ああ、切なくて涙がちょちょぎれそうだ……。
進展あったら追記する。
とんでもねぇブラック企業に新卒で当たって、アブグレイブ刑務所で行われた捕虜虐待レベルの労働を課せられ精神疾患で入院し、未だに軽度のパニック障害を起こす程度に軽く心身を破壊され、履歴書を荒らされまくり、処方される薬を飲まないとマジで、どこも外にすら出れず、人生をマトモに軌道に乗せるのに大学出て３～４年はかかった俺の意見を聞いて、参考にしてください。
老婆心からですが、就職を控えた学生の皆様は、どこにでも地雷原のように潜んでいるこういうブラック人間がいるという事を頭の隅に置いておいてください。
１、そもそもブラック企業(部署）の人員は「超攻撃的、好戦的なコミュ障の集まり」
まずブラック企業をまわしてる連中というのは、人間としての常識が通用しません、相手の意見も聞きません、一方的に話を打ち切るならまだマシ、口答えしようものなら1時間近く怒鳴り散らされます。気の弱そうな奴には手が出ます、足がでます、椅子が飛んできます。
教育と称してハンコの傾き具合からフォント位置、言葉尻を取って半端じゃないマウンティングをしてきます、リアルウシジマくんの世界です(恐ろしいことにそこそこの企業）
典型的なｳｪｰｲ系だった同期は３か月で話が通じないと非常事態とばかりに辞めました、真面目一筋さわやか体育会系だった先輩は俺がきて三日目にアルカイックスマイルのまま倒れて病院に運ばれて二度と戻ってきませんでした。
ブラック企業をまわしてる人材の特徴としては、まず根っこは病的なコミュ障です、ネットで煽りや喧嘩しまくってる凄い荒らしがリアルでそれをやっているようなものに近いと感じます。
当然、ほうれんそうなんてものが崩壊しきっているため、スキルらしいスキルはまず身につかないと考えていいでしょう、というか、スキルは独占されて与えられません(人間不信も極まってるから教えたら食い扶持取られて寝首を掻かれると本気で思い込んでいる節があった）
２、彼等の根っこは非常に劣等感とルサンチマンに塗れた過去がある「ナンバー１になれるほどではない有能だった悲劇の陰キャ達」
そういう、「法律は破らないがモラルやマナーは一切守らない、何故なら罰金も刑罰もないから(原文ママ)」というようなタイプのブラック人間というのは、どうも話を聞いている限り生まれ持って悪として生まれてきたような奴というのは、いるにはいても重役社長クラスの人間だけなように思います。
大体が、かなり複雑というか、コンプレックスを抱えて肥大化し、歪んでしまった人間というのが多いと感じました。親が優秀すぎてどれだけ結果を出そうとも褒められなかったとか
野球だかサッカーだかで最後までライバル校や才能あるやつに勝てずナンバー２に甘んじて、才能の限界を感じて自分から降りてくすぶっていたとか、そういう過去が必ずあります。
あと共通するのは、病的なまでに根本は人間不信ということです。結婚しているのに自分の嫁さん子供すら信じていません。溺愛はしているのですが、人とのちゃんとした愛情関係というのが、そもそも理解できていないところがあります(大体ギクシャクしていて家にいたくないから会社にずっと残っていることが多い)
自分自身と共通項があるとすれば、彼等ブラック人材の本質はかなり「陰キャ」に近いといっていいです、それを隠すために真面目系クズではなく、スキルポイントを全部攻撃性に突っ込んだDQNや悪に足突っ込んでクラスチェンジした存在といえるような気がします。
荒木飛呂彦の悪役論でいう「自分の弱さや劣等感を攻撃性に裏返した人間ほどタチの悪い存在はいない」を地で言っていると感じます。
３、何故彼らはブラックにとどまるのか「萌え４コマのようなやさしい世界では、テロリストや凶悪犯罪者みたいな奴等には地獄そのもの」
曲がりなりにも確かに有能ではあるから、ホワイト企業にでも行けばいいのに、と思い、自分も一般派遣ではあるけど(ブラックもう二度と当たりたくないから不安定というリスクを背負って）結構上の企業で働かせてもらっていますが、後述するブラックの影響と先んじて、何故彼等はホワイト企業にいかないのか、なんとなく想像がついた所感を述べます。
純粋に居心地が悪いからというのがあります、ホワイトで人も良くてちゃんと福利厚生も整ってるのに、相手の何気ない善意やそういったところまで、何か自分を陥れて付け込む罠ではないか、裏切られる前に裏切ってやる！こんな所よりもっといいところに食い込んで栄達の足掛かりにしてやるわ！とか、ブラック企業で洗脳を受けて、ブラック思想を無意識レベルで刷り込まれたら、こんな風に考え、わずかなミスでも笑ってフォローされるのが、逆に不気味で怖くて怖くてしょうがありません、超疑心暗鬼になって挙動不審とまで言われてしまうっていうのがあります。
実際、私の見たブラックへ下ってきた元一流企業勤めとか、そんな連中というのは、そういう企業に馴染めなかった「コミュ障」というのがかなり多いです。親和性が非常に高いのかもしれない。
この件に関しては主語がデカい、お前の精神構造がおかしい、とか言われるかもしれませんが、とにかく私たちのように何にも知らずにいきなり社会出てブラック洗脳食らった人間ならまだしも、ブラックの水に合う人間というのは、フリーザ様のようにホワイト環境こそが地獄に思えるのかも…とは思います。
４、ブラック企業に入ってブラック洗脳受けたら、思想や志向がこんな風に変わる「チンパンジーのような猿人の本能に刻まれた悪の才能が開花する」
ここが本題に近くなりますが、最後にブラック企業でブラック洗脳や彼等ブラック人間と机を並べて仕事すると、こんな風に思想から何からが無意識に変わってきます。
まず「相手に言葉尻をとらえられないように返事が曖昧になる」というのがあります、わずかな些細なミスでも手や足が出るレベルで切れられたり、とにかくマウンティングや脅迫の材料にしようとしてきますから、仕事上で必ずこんな風に曖昧だったり、自己防衛的にどもるようなしゃべり方になります(これが治すのに一番苦労した)
次に「すべての善意的行動に何らかの罠や悪意が混じっているのではないかとフル回転で邪推する」というのもあります、ブラックでは支配するのに持ち上げて落としたり、油断させて本音を引き出すためにこれをまずしてくるので、ありとあらゆる善意的行動に対して警戒行動を取るようになります(美人局とか絶対引っかからないだろうなーとは思うようになった）
次は「(法律的ではなくモラルやマナー的な面で)悪いことやゲスい行為をするのに対して、躊躇がなくなったどころか、悪いことに関しての創造性はポンポン飛び出るようになった」です。
躊躇なく目の前で妊婦や老人が立っていても、足を組んで優先席でスマホ弄りながら服が当たっただけでにらみつけられるようになります(自己嫌悪にその後夜凄まじく陥るが、これぐらいオラついて確保していないと付け込まれて食い物にされるのがブラックです、兵隊が反射的に銃を撃つようなレベルで、反射的にこういう行動をしてしまうようになります)
最後は「悪の才能が開花しているのを身をもって感じる」というのが一番自己嫌悪と後悔が凄い強烈に襲ってきます。
進んで善行を行っても何故か裏目に出て立場が悪くなったり怒られるようなサイクルに陥ります、逆のことをすると何故かうまくいったり騙しとおせて評価されるようになります。
オカルト的な話ではなく、単純に思想や性向が悪に固定化されるのがブラック洗脳なので、無意識的にそういう風な行動ルーチンが怒ってしまうのでしょう。
ぶっちゃけ、日本は戦争とかミリタリー技術には遠い平和な国でよかったと本気で思います。左翼的な意味でもなんでもなく、こういうブラック人材がゴロゴロしてる社会で
東欧とか見たいに国民全員が銃の打ち方と戦い方知ってるとかになったら、今頃彼等ブラック人材が、ユーゴ内戦の極悪民兵組織みたいに、集団暴行・銃撃・脅迫・狙撃・破壊工作・略奪・強姦・民族浄化・人身売買に奴隷狩り・違法物品密輸とか、オンパレードで手を染めることは間違いないと断言できます、彼等には行動力があってもそれをするスキルが日本国内にはないから、ブラック企業で新卒いじめるくらいで済んでいると、本気でブラックで人格破壊寸前まで被害を受けたから、私はそう思っております。
ブラック人材はブラック業種に集まります、ブラック業種でもシェアや経営状況が上ならそんな犯罪者通り越してテロリストすれすれのキ〇ガイみたいなのはいねーだろと思うかもしれませんが
彼らは本当のホワイト企業には、水が綺麗すぎて住めないけど強い魚みたいなもんです、ドブ川(ブラックといわれる業種や職種）には、割と上場企業でも普通に多数生息しています。
夢とかではなく、現実的に行動をしてください。彼等ブラック人材こそが、かなうはずのない夢やかなわなかった夢と向かい合えず、その弱さを他人への攻撃性に変換した危険人物たちなのですから。
↓↓↓
夢の中で自分は高校生。現文の授業なので教室を移動すると、いつも数学を担当している先生がいて、家庭科の授業になる。お料理教室みたいな感じで、知らない人もいる。フライパンでパンケーキの生地を広げ、それをアイロンで焼き、キャラクターの形に切るという課題。R君が遅刻してきてすごい怒られる。それをみてS君が笑う。料理をはじめる。まず最初俺はちゃんとパンケーキを作る。そのあとアイロンでパンケーキを焼くもどうやら手順を間違えているらしい。パンケーキを捨て、やり直す。最初にフライパンをアイロンで温めている。アイロンをコンロの上に置くと暑すぎてコンロが灰となる。途中でT君とH君が廊下で遊んでて怒られる。T君が意味不明な言い訳をして逃れる。結局アイロンの使い方がわからないのでパンケーキの生地をペットボトルに流し込みそのペットボトルに顔を書いて完成ということにする。同じテーブルには女の子がいて、その女の子も俺とおんなじことをしている。でこの子面白いなと思い好きになる。その子は元々料理教室の前から友達みたいな感じで仲良くて、白髪が多い。 白髪多いねというと、すごい避けられるようになる。一緒に帰ろうというと、いいよと言われる。新宿のドラッグストアから自転車で並列して一緒にかえる。その人の家に行く。その人の家には特別な事情があるらしく、その話を聞く。ここから回想。父親が大事にしているワインが3つ程あり、それを家族で大事にしていた。ある日なんかの拍子でそれが割れてしまい、火がついて燃えてしまう。その子の弟がそれをみて、父親が大事にしていたものだからせめてとワインのビンの破片を火の中から集める。それを父親に渡すと、1破片18000円で買い取るという。母親がそんなことやめなさいというと父親はもうあの秘密のことを話そうという。結局その秘密はわからず。1破片18000円という高値で売れることがわかり、他のワインを割り火をつける。おこられる。母親が狂い、こんな汚れた娘に触ってしまった自分は穢れてる、と自殺する。ただ母親は本当は生きてて、娘にネグレクトを働く。母親は化け物に憑依されており、そう簡単には勝てないのだ。回想終わり。話を聞いているとその子の母親が帰ってくる。急いでかえる。その子の母親に顔を見られたので殺されるのではないかと焦り、ダッシュで自転車をこぐ。帰り方がわからなくなり、近くの大学生に「N駅はどこですか」と聞くと、めっちゃ笑われながら道を教えてくれる。ダッシュでN駅に向かうと、途中で大学生が「N駅までの行き方聴いたやつがいたらしいよ」「どうせそいつも
●●(聞こえなかった)狙いだろ」という会話が聞こえる。横を見ると火事が起きてて、消防車が出動してる。あの母親がやったらしい。それを消すために、樋口一葉が書いてある(5000円札ではなく)1000円札で封印しようとする。終わり。
↑↑↑
この夢が何を表しているのか、もしわかる人があれば教えてください。
文書作成とかはがき印刷とかExcelで表（本当に表）作らされたりとかしてる高校生なんだけど
「Aってもんつくれ！はよつくれ！ほいちゃっちゃと」とか言ってくるんだが、「うーんやっぱりA'のほうがいいな」
みたいになって、でも自分の能力じゃA'はつくれなかったり、ソフトの使い方もいまいちわからないときがある。
そんなときは滅茶苦茶にｷﾚて「おまえPC得意言うてたやろ！よう言うたなぁ！？（原文ママ）」とかなんとか罵倒されたりたたかれたりけられたりするんだけど。
結局、Bの物ができあがるわけだ。
まぁそれはおいといて。そういうときは惨殺する妄想してるんだけど。
本当に「本当に顧客が求めていた物」っていうのは存在するんだなぁって思った。
一社目→何しようが自由。飯をざっとかき込んで20分程昼寝してた。
二社目→前の会社と同じようにしてたら、副社長自ら「仕事の意識が低い」とお説教。
4年目からうつを患い、昼10分でも良いから寝かしてくれれば、
昼からの仕事の効率が違うと訴えるものの「病気を言い訳にすればいいってもんじゃない」と激怒の上却下。
三社目→同僚がやたらと飯に誘ってくる会社で、俺はそう言うのが嫌いなので
色々言い訳を付けて逃げて、飯をさっさと済ませて公園のベンチで寝てた。
後にそれを見かけた社長より「同僚とコミュニケーションを取れ」と怒られる
「そもそも休憩1時間と労働契約書に書いてあるのは建前上であって、
食事が終わったらすぐに仕事に戻るのが社会人としての常識」（原文ママ
五社目→建物内に併設された食堂で飯を食い、その後昼寝するものの、
結論：
休憩時間は法律上は確か完全に仕事から切り離される権利があると認識していたが、
社会通念上、仕事や同僚から完全に離れて一人で自由に時間を使いたいっての許されない行為。
ああ、クソだなぁ。
バニラエアを相手にちょっと本気を出して見た話（１）https://anond.hatelabo.jp/20170713011805
バニラエアを相手にちょっと本気を出して見た話（２）https://anond.hatelabo.jp/20170713013049
バニラエアを相手にちょっと本気を出して見た話（３）https://anond.hatelabo.jp/20170713030752
バニラエアを相手にちょっと本気を出して見た話（４）https://anond.hatelabo.jp/20170713123253
バニラエアを相手にちょっと本気を出して見た話（５）https://anond.hatelabo.jp/20170713165756
断っておくが、おれはこれをバニラエアの「回答」とは認めていない。
理由は後述する。
以下、原文ママ
おれ様
バニラエアへお問い合わせいただきまして誠にありがとうございます。
先日、メール並びにお電話にてご連絡頂いた件につきまして、回答致します。
この度、奄美空港における車椅子旅客の件につきましては、施設整備の問題が第一としてございましたが、6月14日からはアシストストレッチャー、6月29日からは電動式の階段昇降機を導入致しました。
また、今年11月からは奄美空港のパッセンジャーボーディングブリッジ(搭乗橋)が1基から2基に増設される予定でございますので、より安全にご旅行頂けるようになります。
従来より、障がいをお持ちの方にも弊社便をご搭乗頂くべく、予約センターでの窓口対応、空港でのスタッフの付き添い等、施設面での支障が無い限り、お客様のご希望に添えるよう対応してまいりました。
今後、改めて障がいをお持ちのお客様の目線に立った対応が出来るように啓蒙教育について社内検討していく所存です。
具体的な対策や社員教育の詳細につきましては検討を重ねている段階であり、現地点ではこれ以上のお伝えができかねますこと何卒ご容赦くださいますようお願い申し上げます。
奄美空港におきましては、車椅子をご利用のお客様をはじめそれ以外のお客様にもご心配をおかけすると共に、ご不快な思いをさせてしまいましたことを心よりお詫び申し上げます。
奄美空港での改善策の実施を急ぎ行いましたが、今回の事象を踏まえ、いま一度サービスの提供のあり方につきまして検証するとともに、障がい者の方のお気持ちを強く認識し、安心してご利用いただけるよう努めてまいります。
弊社では全てのお客様へ快適、安全にご利用いただけるべく今後より一層精進して参る所存でございます。
なお、7月10日にメールにて正式な回答を差し上げる旨ご案内しておりましたが、前述の通り現時点でお客様へお伝え出来るのは以上の内容のみとなります。
つきましては、本メールをもちまして弊社の回答とさせて頂きます。
弊社には至らぬ点もあるかと存じますが、どうか今後とも変わらぬご愛顧を賜りますようどうぞ宜しくお願い致します。
*********************************
パッと見、真っ当な謝罪文のように見える。
だが、おれはこの文面に３つの違和感を覚えた（根本的なところも含めると４つだが）
さあ、どこだかわかる？？？
つづく↓
https://anond.hatelabo.jp/20170714113338
例のバニラエアの件について、実際に行動したことを書く。
まあ事の起こりは、ネットのニュースでみたこと（たしか朝日ではなかったと思う）。
で、すぐにこの件についてネットで調べた。
幸いにして、リアルタイムで報道を知ったわけではなかったので、賛否両論を知ることができた。
バニラエアに批判的な意見は、当然「障害者差別だ」というもの。
逆の意見は、「車椅子の人は搭乗数日前に事前連絡が入れるのがルールで、従わない方が悪い」「木島氏はプロ障害者だ」というもの。
プロ○○とは、社会的に弱い立場をわざと利用して不当な利益を得ようとする者たちのことを指し、「プロ市民」「生保不正受給者」「在日ナントカ人」とかがこの部類に入る（おれの定義による）。
こうした連中は反吐が出るほど嫌いだ。
しかし、おれは考えた。
「果たして木島氏の取った行動はプロ障害者扱いされるほど悪質なものだったのか？」と。
そうしているうちに、おれが木島氏に対して思う所と一番スタンスが近いブログをみつけた。
http://www.huffingtonpost.jp/hirotada-ototake/post_15315_b_17326010.html
断わっておくが、おれは乙武信者でもないし、ましてや人道主義者でもなんでもない。
そんな感じで、賛否両論があることを踏まえつつ、なおバニラエアに対する嫌悪感は拭えなかったので、
公式サイトの問い合わせフォームから以下の文面を送った（原文ママ）。
「車いすの男性（44）が、搭乗機に階段で乗降するタラップで不当な取り扱いを受けた」というニュースを見ました。
障害者もまともに受け入れられない程度のスタッフ、サービス力しか持ち合わせていないなら、廃業したらどうか。
はっきり言うが、そんな貧乏な会社なら飛行機の整備もまともにできないのではないか？
というより、喧嘩腰そのものである。てゆうかそれほど頭にきていたので。
「役職付きの肩書を持った人間から貴社の正式な回答」というのは文面のままである。
「この度はご迷惑をおかけし、申し訳ありませんでした」などというどこかのコピペみたいな返答を期待している訳ではないので。
これが、おれをさらに苛立たせるのに十分な内容だった。
ご回答は５営業日を頂戴しております。なお、ご質問の内容によっては、
ご回答までに日数がかかる場合がございます。予めご了承ください。
5営業日とかなめてんのかよと思いつつ、様子を見ることにした。
つづく↓
https://anond.hatelabo.jp/20170713013049
いきなり佐川急便がやってきて、挨拶もなく、まさに開口一番値上げを通告された。今流行りの便乗値上げというやつだろう。
値上げ幅を聞いたらはっきりとは答えなかったが、かなり大幅なものになるという。
確かにうちは優遇するメリットなど皆無な零細個人事業者である。
しかし、だからと言って値上げ理由の説明を求めたら一言「は？」（原文ママ）はないだろう。「は？」（原文ママ）は。
びっくりしたよぉ～？
送り状を作ってくれるようお願いしても、無言で原本を奪い取っていくような、以前から態度に問題のある人ではあった。
そのくせ、母の日のカーネーション営業のときだけは人が変わったようににこやかに売りつけてくる…まあいいや。
とにかくこちらとしても、以前からいろいろ思うところがあったのだ。
少しだけ爽快だったのは、既にうちは佐川急便と同等の条件で配送をしてもらっている業者さんが他にもいる。
そのことを告げて、今のラインから値上げするならうちからは出せなくなると伝えるとさすがに豆鉄砲を食らったような顔をしていた。
うちみたいな零細事業者がまさか他のカードを持っているとは思ってもいなかったことだろう。
来月の1週間ほどある､職場の休みを出張でまるごと潰されたことで､
今いる課をやめたい､と踏ん切りがついた｡
「早く辞めたほうがいい」
と言われるくらい酷い環境だったらしい｡
仕事の内容も､自分で決めて好きなように動け､という仕事の仕方だったが､
仕事のバイブルがあって､道が決まっていて､そこに向かって仕事するやり方が向いていると思う｡
休みと金のために仕事をして､自分の好きなことをしたいと言いたい｡
今の組織では全く出来ていない｡
けれど､誰にも仕事を放り投げれない｡人がいないし自分でノウハウを持ちすぎた｡
だから半年くらい身辺整理をして､来年度くらいにはどこかに行きたい｡
死にたいとは思わないが､いずれ死にたいと思うようになってしまう気がする｡
人と話もしたくない日が週に3日くらいある｡
きっと代わりの人はいくらでもいる｡
もう逃げてしまおう｡
-------
って言う感じの無茶苦茶な司令を出されて､新入社員から経験もないまま､
「ハードの設計･製造全部1人でよろしくね☆ その代わり期限は守れよ」
この時点で仕様書は無い｡というか今もない｡どう考えても無理な指示を出され､とりあえず手を動かし続けた｡
色んな所を走り回って知識を集めて､何とか形になるくらいの設計はした｡
機材は動かない､酷いときは壊れていく｡
上司「よく分からんけど明日までになんとかしろ､どうにかせえ｡試験は明日からや｡」
ぼく「……はい」
こんなやり取りをここ半年くらいずっと続けている｡因みに上司には電気の知識は殆ど無い｡
「まだ直らないの?」「いつまで待てばいいの?」「何もすること無いの?」「どういう状態なの?」
「あれはどうなったんや」「直ったんか」
という強い言葉を浴びせられる｡つらい｡
それが買ったものだったら｡
「ケータイでもメールでもなんでもいい｡地の果てまで追い掛け回せ」
ここ半年ほどは深夜まで対応し､土日も潰され､プライベートが殆ど無い状態である｡
で､従業員がこんな事になってるのに､結構偉い人からこのプロジェクトが注目を浴びているらしい｡
--------
例のポスト、「～なのだ」「～のだ」「してみろ！」と60過ぎたガンコじじいみたいな言い回ししかできていなくて、内容に「ああ、それはそうかも」と同意できる部分があったとしても正直に言って「あなたとお友だちになると疲れそう」です。
この益田さんは最初に「婚活疲れ」と書いているように、今にいたる経緯があってこの結論（というか現時点でのポジション）を見つけたわけで。途中を見ずに結論だけで語るブログ主みたいな人は俺は苦手だなあ。彼女を全否定して生きるって、相当いいご身分なんだろうし完璧な人生を歩んでいるんだろうから、弱い人は弾かれそうだよね。
それと、「人は結婚し、子供を儲けて初めて完成する」（原文ママ。もうね、誤字の仕方がさ……w）……思っていてもいいけど、人の発言をあげつらった上での公共の場で書かないでほしいよね。ブログ主は「人との絆を紡ぎ続けることが人生の喜びだ」と強調するわりに、周囲の人たちへの気遣いが感じられないのがイラッときたのかな、俺。言葉を借りるなら、「お前がそういうならそうなんだろう。お前の中ではな」って感じ。
益田さんには特に言うことはないです。もしお友だちだったら「そんなこというなよ、結婚も悪くないよ」と酒でも飲みながらあーだこーだ言い合いたいくらいかな。
先月今月と、街コンというやつに行き始めた。
きっかけは、別の機会に話せたらいいと思う。
何度目でそれなりの成果を得られたかとか、これまでどんな失敗をしたかとか、そのあたりの記録になればいい。
で、とりあえず、今回は過去2回分を先にざっくり記録していく。
■1回目 2017年1月21日(土) 13:00 〜 16:00
規模：40人程度（推測）
参加：1人
特記：いわゆる謎解きコン
年始に思い立って、というか友人と色々話して予約した。友人と話しはしたが一人参加である。
初参加の為、「とりあえず楽しそう」の観点で選択。アトラクション要素を強く宣伝されており、そこに期待した。
◎良し
自分のことの記載欄に、相手からのひとこと(連絡先とか)記載欄、切り離して使うメモ用紙と、デザイン含めて整っていた。
思えば、謎解きも含めて、準備に比較的手間のかかった街コンなのかもしれない。
◎悪し
・そもそもアトラクション要素が期待できる程のものではなかった。
その上で、謎解きをしたのは初めの席の5人組だけである。それ以降全く関係が無いのは不満足と言えた。
プロモーションのページから、なんとなく雰囲気だけでも日テレの「DERO！」みたいなものを期待してしまった自分が悪いかもしれない。
よくよく考えればそのへんのそれっぽい雰囲気の居酒屋を間借りしているだけである。妥当と言える。
ただ、3回行った今となってはこの要素も別にいらんわなとは思う。
というか席替え的に男性3は固定なので他の組の人数がわからないが、どの組も女性2だった気がする。
割と致命的なポイントだと言わざるをえない。
◎成果
ガチの皆無
◎感想
話を盛り上げることはそこそこ出来たりしたが、本当に全く成果が無かったことには初参加からしてハートブレイクである。
ちなみに連絡先がどうとかそういうことも全く無く、当日はなかなかにショックを受けた。5時帰宅とか、そんなんギャグでしょ。
終了直後流れるように散開していく参加者たちには本当に驚いた。昼開催であるからには、その後2次会がどうとかするものだとばかり思っていた。
この結果から、以降に続いた。
■2回目 2017年1月22日(日) 13:00 〜 16:00
規模：16人
参加：1人
特記：とくになし
1回目は1月21日、2回目は1月22日。そう、ハートブレイクのあまり、帰り道でそのまま予約をしてやった。
◎良し
・広めの部屋にテーブル別着席、全3席。おそらく開催想定は4席だったと思われる。
個室席替えと比較して、全体の雰囲気が感じられた。また反則的だが、別の席とも絡むことができた。
・豆に全体への指示があった。
席替えごとの乾杯に一捻りがあったり、入場時に配られた用紙のコレを話題にしてみてくれなど、面倒でない範囲で指示があった。
というか、面倒であればスルーするだけなので、共有話題が増えるという意味で良いことかと思う。
・あと何故か女性の可愛い率が高かった気がする。（個人の感想）
◎悪し
・性別比がひどかった。1回目と比べても圧倒的である。おそらく男性10に女性6人。
自分のところは男3女2だったが、男4女2のテーブルもあったようで、そこは本当にかわいそうとしか言えない。
・あと、同じ机の隣の男がマジクズファッキンカス野郎だった。これは開催側は全く悪くないが本当に勘弁してくれと思った。
具体的には「高校の時女の先輩にこんなん(自分褒める系)言われてさあ」の如く常に女がいてどうのということを言いたがる、
女性が正直あまり可愛くない二人組のテーブルで「うわなんか腹痛くなってきたわ」とか露骨に態度が悪くなる、
「ほんっと視力大事だよね、俺ちょいちょい目羨ましいとか言われるけどそんなんどうでもよくて視力ほしいもん」
とか喋りだすなど、お前さっさと帰ってくれとしか言いようがない。マジでウザいタイプのカス野郎だった。（個人の感想）
◎成果
連絡先3件 尚レスポンスは続かず
◎感想
かなり仲良くしたい相手が1人ないし2人いた（入手連絡先に含む）が、成果は振るわず。
とりあえず開催中対面で話している時はともかく、開催後のムーブが弱いことを自覚しつつある。
また、前日昼に滑り込めるということは、そういう予約状況ということである。
結果的にそれほど不満ではなかったものの、人数については事前に予見できたかもしれない。
■
思ったより書いてしまった。
3回目のことについてはまた日を改めて記録することにする。
今回は以上です。
『妖怪男ウォッチ』さんなんかを代表例として、昔から女が男を批判するシリーズってあるやん。
その手のネタは、女性誌やワイドショー、はてブでも増田でもよく人気（炎上？）だし、人気コンテンツなんだと思う。
で、俺はお世辞にも女の考えていることが手に取るように分かるほど人生経験豊富じゃないから、
そういうネタを目にするたびに名状しがたい不快感を覚えていた。
なんでこんなに自分勝手に、生意気に上から目線で意見してくるのだろう、と。
（http://blog.livedoor.jp/hankon/ ←みたいな男性目線で反論するブログを愛読している）
とあるブログ主（男）が非モテな半生を書き綴ったような日記に対して
若い既婚女性と思しき人物が次にようなコメントを残していた。ちなみに原文ママではない。
「あなたより年下なので申し訳ないですが、母親のような目線でのコメントになってしまいます」
「ちゃんとご飯食べてますか？ どうしてそんな風に自分を苦しめるような生き方をするのですか」
そのコメントを目にした途端、「なるほど」と腑に落ちるような心持ちになった。
これは自分の直観でしかないのだが、女性は情けない男を目にすると、ある種の母性本能がくすぐられて
上から目線＝母親のような立場で男に「物申す」ような本能があるのではないか、と。
確かに女性が当事者として上から目線で発言していれば「何を自分勝手な！」とイラつくが、
そういう発言をする本人たちはどこか保護者のような、意外に外野的な感覚で発言しているのかもしれない。
言うなれば、口うるさい母親の説教みたいなものだ。そこには多少の愛もあるんだろう。
もっとも、母親の説教である以上、そこには対象者を下に見る感覚があることには違いはない（笑）
そう思うと、女が男を批判するシリーズなんて、実はまともに取り合う必要がないもので、
要は「うっせーなーブス」と適当に受け流していいレベルの戯言なのかもしれない。
発言する方だって、最初からその程度の認識で物申しているんじゃないかと思う。
アウシュヴィッツはとおいむかしのこととなった。
それがいったいどのようなものだったのか、今の私たちには想像することもむずかしい。
アウシュヴィッツを知らなくても私たちは生きてゆけるだろう。私たちは自由だ。
だが、事実はゆるがない。
その数は180万にのぼること。
180万の心があったということ。
そして、その心をなんのためらいもなく消し去ったのもまた、私たちとおなじ心を持った人間だったということ。
そのときそこには人の心をゆがませる強大な力がはたらいていたということ。
私たちは自由だ。アウシュヴィッツを忘れ去ることができるほど自由だ。
それほどの力を私たちは手にした。
でも、その自由が血塗られた歴史のうえにあるとしたらどうだろう。
過去を忘れて自由をとなえることは、自由というものの意味の重さを取りちがえることになりはしないか。
人の心をゆがませる力を、ふたたびまねくことになりはしないか。
自然な心を持ち、自然に生き、自然に死ねることがどれほどすばらしいかを、世界中の人々がわかりあえる日は来るだろうか。
それは私たちしだいだ。
そして、その日が来るまでアウシュヴィッツは終わらない。
遠い昔、私たちとは関係のない場所で、かれらの叫びは時間とともに消えていった。
180万の名も知らぬものたち。
でも、耳をすませば聞こえるはずだ。
心を開けばわかるはずだ。
生まれた国がちがおうと、生きた時代がちがおうと、私達はみな同じ心を持った生き物だ。
物言わぬ者たちの声を聞こう。
さまよう者たちの姿を見よう。
かれらの心を受け入れよう。
アウシュヴィッツを繰りかえさぬため。
アウシュヴィッツを終わらせるため。
つたないが、今につうじるものをかんじるので記した。
・犠牲者総数は1990年代後半時点でのポーランド国立オシフィエンチム・ブジェジンカ博物館公式発表のもの。
具体的には、
自分も大概なクズなコミュ障だが、その自分から見て「ああ、真性のコミュ障ってのはこう言うのを言うんだな」ってのを前職を辞める直前で見かけたので備忘録がてら書き連ねる。
■対象
ありえない程匂いのきつい香水をつけてくる。どれくらいきついかと言うと20畳程はあるだろうかフロアがその匂いで充満する程きつい。体臭等の理由があるのかもしれないがそれでも度を過ぎていた。隣りに座っている自分は毎日匂いのきつさのあまり頭痛に襲われた。
■やたら細かい所にこだわる、自分の意見を曲げない、人の意見を受け入れない
その会社では作成した画像を正式納品物以外は透かしを入れていた。持ち逃げ対策。しかしこれが気に食わないらしく「なんでこんなことをするんですか、必要ないでしょう」と言って聞かない。持ち逃げ対策で事業部当初からの慣例だと言っても「そんな必要はない」と言って一歩も譲らない。
最終的に「そこは議論に時間をかける必要もないし、これ以上時間をかけるのも無駄だからこの話はしない」とはねつけたんだが、そうすると「そんなレベルの低い話をしたくない」と尚も食い下がる。もううっとうしいから言ってることを無視して自分の作業に戻ったがこれが1週間ほど続いた。ありえない。
それだけでなく、自分は見聞でしか無いが経理側の慣例となっている作業に噛み付いて、そこでも2時間程お局とぐだぐだやりあったらしい。そこでも「レベルが低い」発言が何回も飛び出したそうだ。
10社も経験してれば入社数日の自分の意見で会社の慣例を変えられる訳もなく、それをする為にはまず社内で実績と信頼を勝ち取り、意見が通る環境を整える必要があることくら分かりそうなものだが、それが絶対的に理解できず「自分の意見が絶対的に効率的で正しくそれが理解できないのは君のレベルが低いからだ」が思考の基本形式らしい。
ぶっちゃけると、俺はその会社を退職までの最低猶予期間である2週間きっちりで辞めるよう手続きしていた。担当している仕事分量は多く、はなっからまともに引き継ぎできるともしようとも考えていは居なかったが、形式としては一通りの引き継ぎをしたと言う「建前」は必要だ。
なので一応ざっとした引き継ぎスケジュールを作り、それに基づいて引き継ぎ作業を行おうとしたのだが、今やっている作業が終わったら引き継ぎ作業を行うから声をかけてくれと言ってから2時間、3時間たっても一向に声をかけてこない。しびれを切らしてこちらから声をかけた時の会話の概要が下記の通り。
「手が空いたら声をかけてくださいって言いましたよね。今までの時間全く手が空かなったのですか？」
「はい」
「いくらなんでも3時間全く手が空かないってことはないですよね？何やってたんですか？」
「それは急ぎじゃないですよね、いつやってもいいですよね？俺、後一週間（※）でいなくなりますよ。引き継ぎ全然進んでないんですけど、その辺分かった上でやってます？」
「はい」
「分かってるんならどうして引き継ぎの作業じゃなくて、優先順位の低いそっちの作業をするんですか？」
「そう言うレベルの低い話はしたくないです」
「（またそれかよ）」
※…上記のようなやり取りが延々続いており、引き継ぎ進行率は残り1週間で切った所で20％もなかった。
俺は30代後半で子無し嫁無し家庭無しだ。主原因は俺のコミュ障にあるのは明らかだが、生まれ育った家庭環境の関係もあって結婚と言うものに期待も希望もなく、普段はエロゲ、時に風俗で十分満たされており、今後もその生活を変えるつもりは全く無い。
結婚の話になって「俺結婚するつもり無いんですよ」と言われたら、それなりに裏を色々察してそれ以上突っ込まないのが、普通の感性の持ち主の反応だと俺は考える。だが奴は違った。
「え？なんで結婚しないんですか？頭おかしいんですか？何かの思想信条ですか？それともなんか宗教的な理由ですか？」（入社3日目・原文ママ）
相当親しい人間同士の砕けた会話でも、宗教や思想信条と言う言葉を使っては会話しないだろう。ましては入社3日目、顔を付き合わせて3日目の人間に聞くべき話じゃない。流石に俺はキレ気味に
「それは仕事には関係のないことだし、それをあなたに話す義務もないし、そんな会話を赤の他人とするつもりは一切ない」
と断言した所
「コミュニケーションでしょ、会話でしょう、僕とコミュニケーション取るのが嫌なんですか？」（同上）
と来た。
思えばこの時点で「ああ、こいつ無理だわ」と結論づけて会話に壁を作って、引き継ぎ作業にかなりの悪影響を与えたことが今となっては分かるのだが、当時は香水の臭さとあいまってもはや近くにいるだけで文字通り頭痛を覚えたのは記憶に鮮明だ。
■人間落ちる所に落ちる
経歴だけ見れば大したものだった。業界では名が知られた会社を何社も経験していたし、資格欄にもカタカナと英文が踊っていたように記憶している。
一方、その会社は規模は小さく、給料は安く、将来性もない。俺はメンヘラで数社を転々とし「落ちる所まで落ちた」結果、入った会社だ。
なんで大手をやめてこんな所まで落ちてきたのかと経歴だけを見れば思うが、実物を見てみれば成る程「こんな会社まで落ちてくる訳だ」と納得する人間だった。
被った在籍期間は3週間程度だが、それでも「ああ、こいつは絶対に有り得ないわ」と思えるエピソードが他にも多数あった。
例えば、少し物言いがきつい先輩社員に小言を言われた直後、「社長に呼ばれたから作業に戻ります」と嘘をついて30分程姿をくらます等、細かい話をあげればまだまだあげられる。
そいつが普通じゃないことは明らかだが10社近くも経験しているなら、そいつなりには入社1ヶ月未満と言う自分の立場を弁えた上で、自分なりの「入社まもない転職組が取るべき当たり障りのない立ちふるまい」をしているはずだ。
3週間はまだその範囲内だろう。地が出てくる1ヶ月後、3ヶ月後、社内で起こすであろうトラブルは俺の想像の範疇を超えている。
そうやってどこに行ってもトラブルを起こし、社内での信頼や信用を失い続け、最終的に退職勧告を受けて辞めざるを得ないことを何度も繰り返してきたのだろうと俺は見ている。
ここまで来れば何らかの発達障害を疑い同情して勘案すべきってのが模範解答かも知れないが、それなら相応の診断を受けて、その前提で受け入れてくれる企業に行くべきだろう。
周りに通院を勧めてくれる人間がいないことは当人にとっても周りにとっても不幸なことかもしれないが、それは赤の他人が推測してやらなければいけない事案じゃない。
どれだけ立派な資格を取るだけの知力があっても、コミュニケーション能力がなければそれを生かすことはできないのだと生々しく実感した。
一方、少なくとも技術職に分類される社会人に求められるコミュニケーション能力と言うのは、巧みな会話スキルや時事ネタに通じている等ではなく、
・先輩や上司に当たる人間や会社の慣例を受け入れ自分の考えをすり合わせること
の二点程度で十分なのだとも思う。
顧客の要求を読み取り、技術的に実行の可否の判断や必要なスケジュールを弾くのはコミュニケーション能力でなく、技術職の「技術」の範疇に入ると俺は考える。
■辛い3週間だったが
同席した3週間はとにかく辛かったが反面教師として得るものは、皮肉なことだが1年程在籍したその会社の中で一番濃く実用性が高いものであったと思う。
引き継ぎは結局ろくにしないまま退職した。社会人としてそれは筋が通ってないと責められる点かも知れないが、それは本筋でないから触れる程度にしておくが、筋を通さないといけないような立派な会社ではなかったと言う点については明記しておく。ならば退職の意志を示してから2週間の猶予を持つと言う法律を最低限守っていれば責められる謂れはない。
新しい会社に入って1ヶ月をちょうど過ぎた。まだ試用期間ではあるが、直上の上司である社員からは「もうすっかり馴染んでるね」と評価を貰った。自身ひどいコミュ障である俺にとっては、これはかなり上々な評価といえる。
それには反面教師から学んだことを少なからず活かした結果であると考えている。
オイラは現在、バヌアツ人の彼女と、バヌアツで同棲しています。
どんな道のりを歩んだかは、（「大学でうんこを踏んだ結果、元カレの親友が運命の人に昇格した話 」）に寄稿させていただいたので、良ければ読んでみてください◎
経験としては、日本人女性とは人並みに付き合ったり別れたりして、バヌアツ人女性とは2人付き合って、1人が付き合う手前までいった感じです。
ほかにも友人カップルや待ち行く人々を見ていると、「バヌアツ人と付き合うほうが楽。日本人は微妙だなぁ」と思うようになってしまいました。
もちろん、個人差はありますけどね。
当たり前ですが、魅力的な日本人女性はいますので、これからはオイラの独断と偏見です。いい悪いではなく、あくまでオイラの主観的な意見ですからね。（予防線張りすぎ）
家族行事には彼女も呼びますし、パートナーというのは、いつも一緒にいる、という認識です。
だから日本人との付き合いは、なんか堅苦しく思えてしまうんですよね。
最初からざっくり言ってしまいますが、日本人女性はかなりの確立(原文ママ)で女々しいです。
メンタルが弱いと言うか、まわりに気を遣いすぎというか。
日本人共通の特徴なので、それが悪いとは思いません。オイラも日本人ですし。
ですがオイラは、女性は頼れる人であってほしい、と思っているので、堂々としている人が素敵だと思います。
「今日ね、上司にこんなこと言われて……。私って本当にダメな人間だよなぁ。つらい」みたいなことを言われると、「おう、がんばれや」としか言えません。
「転職したいけど、彼ﾋﾟｯﾋﾟが許してくれない」みたいな発言を聞くと、「うわぁーﾋﾟｯﾋﾟに人生決めてもらうのか」と引いちゃいます。
支えあっていくのは当然ですが、やっぱり器が大きく、うじうじしない人がいいですね。
そう考えると、日本人女性はちょっと繊細すぎるように思えます。
引っ張ってくれる、頼り甲斐のあるﾋﾟｯﾋﾟは、なかなかお目にかかることができません。
よく、「付き合うのが面倒くさい」と言う人がいます。
というのも、異性の友人が認められず、記念日は祝って……みたいな制約があるからでしょう。
カップルにもよりますが、異性と2人っきりの飲み会は禁止、という人たちが多いですよね。あと、1週間に1度は会うべきだとか。
留学中、「彼ﾋﾟｯﾋﾟがパーティーに行くなって言う」「写真で女の人と距離が近いって怒られた」と困っている子たちがいました。
これは男女共通ですが、どっちにしろ面倒くさいし、女性の場合はどうしても、「器が小さいなぁ」と思ってしまうんですよね。
オイラは言いたいことは言うタイプなので、なんだかゴチャゴチャ言われるのは好きじゃありません。
これもなかなか面倒くさいです。
男性は総じてﾋﾟｯﾋﾟ自慢をしたがりますが、女性は仲がいい人にも、彼氏を紹介したりすることが少ないようです。家族にも言わない人もいるようで。
オイラの経験では、付き合った日本人で、家族に紹介してくれた人はいませんでした。
紹介してからかわれたり何か言われるのが面倒なんでしょうが、付き合ったなら堂々としたいです。
文化のちがいではありますが、ヨーロッパではすぐに家へ呼んで、友達に紹介します。大切なパートナーですからね。
なので、付き合っていることをオープンにしたくない感覚が、まったくわかりません。
「友達と飲んでるときに彼女が来ると面倒くさい」って考え方とかね。
友達と彼女交えて、みんなでワイワイすればいいじゃない、って思います。
こっちでは、彼氏を呼んだらかなりの確立(原b..)で彼女がついてくるので、みんな当然のように受け入れます。
そういう考え方の方が、オイラは好きです。
嫁に「うちの愚息がねぇー」なんて言われたらグーパンですよ。
「お前の***がどんなもんなのよ！」ってな具合です。
恥ずかしがり、言わずとも伝わる――と思っている姫君が多いようですが、そんなんだから熟年離婚になるんですよ。大切なら大切って言えばいいじゃない。
もっと堂々と、「俺はお前が好き」って態度を出せばいいのに。
恥ずかしいんですか？ オイラを好きなのが？ ふしぎです。
彼女と手をつないでいて、友達に会った瞬間離されたりしましたねぇ。
付き合ってるんなら恥ずかしがる必要ないのに。
愛情表現は人それぞれですが、好きな人に好きって言ってもらいたいです。
よく、「資格を取りたいから、しばらく会えない」なんてことを聞きます。
「最近忙しくて、疎遠気味」とか。
「ひとりの時間がほしい」とかね。それは恋人じゃありませんよ。
恋人っていうのは、やっぱりある程度共有する時間があって当然じゃないですか。
言わなくても通じる、会えなくてもわかってる、みたいなスタンスなんでしょうけど、会いもしなかったらただの近くの親戚ですからね。
パートナーを軽んじてる人、多すぎです。
付き合うならやっぱり一緒に人生を歩んでいく、と思うべきです。
付き合っているのに、「結婚するかわかんないしね」とか言う人が多いのが驚きです。だったらなんで付き合ってるの？
時間があるときに一緒に夜ご飯に行く、レベルが「彼女」ですよね。
パートナーなら、もっと時間や人生を共有しないと、ただの仲のいいと変わりません。
とか言っておいて、どこぞの日本人と付き合う可能性がないわけではありません。
が、いまのところ、「日本人と付き合うとなんか面倒くせー」と思っているので、たぶんないですね。
でもこの上5つにあてはまる男性は、多いのでは？
どちらがいい、というわけではありませんが、オイラとしては、バヌアツの方が魅力的だと思います。
バヌアツで、頼りになってたくさんの時間を共有して一緒に歩めるパートナーを見つけちゃうと、そっちの方がいいなぁーと思ってしまうんですよね。
同じように思っている男性がいれば、バヌアツで彼女を見つけちゃうのもアリですよ。
なんやかんや、やっぱりバヌアツ人はかわいく見えますしね！（ゝω・）vｷｬﾋﾟ
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
全校揃った最後の集会になります。今から日本の将来にとって、とても大事な話をします。特に女子の人は、まず顔を上げて良く聴いてください。女性にとって最も大切なことは、こどもを２人以上生むことです。これは仕事でキャリアを積むこと以上に価値があります。なぜなら、こどもが生まれなくなると、日本の国がなくなってしまうからです。しかも、女性しか、こどもを産むことができません。男性には不可能なことです。
「女性が、こどもを２人以上産み、育て上げると、無料で国立大学の望む学部を能力に応じて入学し、卒業できる権利を与えたら良い」と言った人がいますが、私も賛成です。子育てのあと、大学で学び医師や弁護士、学校の先生、看護師などの専門職に就けば良いのです。子育ては、それほど価値のあることなのです。もし、体の具合で、こどもに恵まれない人、結婚しない人も、親に恵まれないこどもを里親になって育てることはできます。
次に男子の人も特に良く聴いてください。子育ては、必ず夫婦で助け合いながらするものです。女性だけの仕事ではありません。人として育ててもらった以上、何らかの形で子育てをすることが、親に対する恩返しです。
子育てをしたら、それで終わりではありません。その後、勉強をいつでも再開できるよう、中学生の間にしっかり勉強しておくことです。少子化を防ぐことは、日本の未来を左右します。
やっぱり結論は、「今しっかり勉強しなさい」ということになります。以上です。
子供は夫婦で産むものなので、女の子だけをターゲットにせず、皆が結婚して子供は二人作りなさいが適切ではないか
普通に考えて30で結婚してキャリアを捨てて子供を二人産み育て中年になってから大学に進学し何年も学んで社会に出る頃には定年の年頃なので無駄になる
