  |
はてなキーワード: オープンとは
そういえば最近、ちきりん（伊賀泰代）のブログを読んでないなと、ふと気付いた。
https://www.google.co.jp/trends/explore#q=%22%E3%81%A1%E3%81%8D%E3%82%8A%E3%82%93%22
こんな感じで、注目度が2011年11月をピークに下る一方だ。
はてぶのホッテントリでちきりんの日記を目にすることも減った気がする。
もう賞味期限切れなのかな。
自分はたしか2010年か2011年ぐらいにちきりんの日記を知って、その後著書も２冊ぐらい買って読んだ。
最初は発想が面白いと思ったり分析の切り口が鋭いと思ったりしたんだけど、ある時期から、ちきりん自身が主張する「自分のアタマで考える」が悪い方に出ているなという印象を持つようになった。
たまに自分（俺）がそこそこ知っている話題についてちきりんが論じているのをみると、あまりにも調べ物をサボりすぎというか、その道の専門家たちが何を言っているのかを考慮せずに、自分のアタマだけで考えた図とかが載ってて杜撰さを感じるんだよね。
そして年々、煽り口調が激しくなってきた気もする。炎上狙いというか。
ちきりんて結局、IQが高いだけで特に専門性はないコンサルタントって感じの人だったんだよね。
大手金融機関だの外資系コンサル会社だのといったところに勤めてたといっても、要は人事部のおばちゃんでしょ？
社会派ブロガーを名乗ってるけど、人事部のおばちゃんが通用する範囲はさほど広くないよなぁ。
ちきりんは要するに、どんな話題でも短時間でそれっぽい仮説を考えることができるってタイプで、会社とか飲み屋にこういう人がいるとアタマの体操にはなっていいと思う。しかし今のネットでは、ちょっとググれば専門家の見解をふつうに読むことができるから、単なるアタマの体操に過ぎないちきりんの日記に「情報」としての価値はないんだよね。そもそも間違いも多いし。
しかもあるとき気付いたんだけど、ちきりん風の「IQが高いけど専門性（知識）がない人」の言うことって、似てることが多かったりワンパターンだったりして、意外性がじつは少ない。
政治や文化に関する話題ならとにかくリベラルっぽいことを言っておき、経済についてはとにかく市場を礼賛するネオリベっぽいことを言っておき、ビジネスやキャリアの話題ならとにかくグローバル化を礼賛して日本の大企業を叩いときゃいいや的な。
もっとざっくりまとめてしまうと、なんか新しいものにとりあえず着目して、それと対比できる古いものを持ちだして比較し、古い方を叩いて「これまでの常識は通用しなくなる！」みたいなことを述べて終了というワンパターンな芸を繰り返してるだけなんだよね。しかもちきりん風の人たちって、新しいものを称えるのがアイデンティティになってる割に、発想のパターンはすごく古かったりして（たとえばネオリベ的なところ）、その意味でも「あぁ・・・またそれですか？」って感じがする。
http://d.hatena.ne.jp/Chikirin/20140922
このエントリで紹介されてる東浩紀との対談を、俺は動画でみたんだけど、ちきりんの底の浅さが如実に現れていてとてもよい例だと思う。
ちきりんはしきりに、「私は一般人」「東さんが言うような難しいことは分からない」と逃げてたんだけど、難しいとか易しいとかの問題じゃなく、東のほうがはるかに発想が柔軟で意外性のある指摘をしているなと思ったんだよね。
ちきりんのような「IQが高いけど知識がない人」は、身軽に見えて実のところ発想の幅が狭い。東みたいな頭でっかちな人文系オタク知識人のほうがアイディアが豊富で、鋭くて、ちきりんはついてこれなかったんだ。
なんというか、多様性を強調してる割に「ちきりんの主張」はワンパターンだし、「ちきりん風の人たちが言うこと」も決まりきっていて、じつは全然多様じゃない。
「自分のアタマで考える」のは結構なことだけど、自分のアタマで考えただけで過剰な自信を持つタイプの人が言うことってだいたい予想できちゃうんだよなぁ。
そういう点に気づくと、賞味期限切れするのも仕方ないかなーって思う。
あ、そういえば思い出したけど、ちきりんの日記って、コメント欄だけじゃなくてブコメすら途中から非表示にしたんだよね。Twitterでも、ちょっとでもちきりんに批判的なコメントをしたユーザは即座にブロックしてるらしい。
グローバルとかオープンとかそういうのを煽ってる割に、ちきりん自身はとても閉鎖的に振舞っているように思える。
べつに閉鎖的でもなんでも勝手にすりゃいいと思うけど、情弱の信者を囲うだけになってしまったら、イケハヤさんみたいなのと差がなくなってくるよなぁ。
追記：
ていうかさ、この増田へのブコメみてて、ちきりん擁護派が皆無すぎて引いたわ！！！
俺は著書まで買ったんだぜ・・・
さらに追記：
この増田がホッテントリに上がっていたようで、けっこう多くの人に読まれたようだけど、反応としては、
http://www.kandareiji.com/entry/chikirin
という何が目的なのかよく分からない長ったらしい言い訳みたいなブログ記事と、
https://twitter.com/kirik/status/728432263852007424
という簡潔なコメントが、印象的でありました。
70年代生まれ。♀。身長161センチ、ややぽっちゃり。大学（理工系）卒。結婚歴なし。
自分で言うのもなんだがちょっとツンケンとした美人系だと思う。
昨年末に大病を患い仕事をやめ実家に身を寄せている。うまく言えば「家事手伝い」。
病気はどうやら寛解一歩手前までたどり着いたものの、通勤は不可能。
同じく大病を経験した友人に打ち明けたところ、
一行だけ
とだけ送ってくるヤツが結構いる。
大抵そういうのはプロフィールも貧弱で、どこから話のとっかかりをつかめばいいのかわからないレベル。
それでもこちらは返事を返す。丁寧な文面を考えてね。
「僕は日本語が下手なので文章は書けません！ とにかくおつきあいして下さい！ よろしくお願いします！」
と返事が返ってくる。お前はオウムか？
それで「あなたが書いたプロフィール以上のことを私は知りたいんです。あなたのことを聴かせてくれませんか」
それも、サイトの標準装備でお断りの文面を生成するサービスがあるので、
だいたい6〜7行ある、よく練られているけど慇懃無礼な定型文が返ってくる仕組み。
いっそ最初に送るメールも自動で文面を選べる機能にしたらどうだ？
ここまでひどくなくても、こっちは「身体が弱いのでスポーツ系の活動はできません」
「一緒にフルマラソンに出ませんか」
とか書いてくる奴もいた。もうこの時点で泣きそう。
いきなり初対面（というか、顔すら会わせてない）人間に、
「ボッティチェッリ展を観に行ってそのあとラブホテルに行きましょう」
ほかにやりとりが続いた例としては、なんとなく流れでこちらは今日起こったことを書いているんだけど、
返事が
「なるほど、それはよかったですね(^^)」
といつも返ってくる。いつもこの1行だけ返ってくる。それでも眼をつぶってた。
ある日
と書いたら
「なるほど、それはよかったですね(^^)」
ときたもんだ。即座にお断りしました。自動生成ではない文面で。
プロフに「LINEは使っていません」と書いていたんだけど（単に嫌いで使っていなかっただけ）、
そうしたら、いちにちの半分くらいLINEに費やす状態になってしまった件。
「どうしてすぐ返事をくれないの？」
とか、お前はほんとうに30代（それ以上もいた）か？ と文句つけたくなった。
こちらもだんだんすり減ってきて、LINEのIDを携帯電話の契約ごと解除して、
それ以降知り合った人間とはGmailで遣り取りをしたんだけど、
バイトの休憩時間にメールチェックしたら40通以上メールが入ってたときも。
Gmailはやめとけ。
それと、上で書いたディスコミュニケーションは「ほんの序の口」だと思ってね。
あ、あとソメイヨシノには気をつけて。男女ともに。
気をつけていても引っかかりそうになる。それくらい多かった。
みんな案外親切にしてくれて、
色眼鏡で見られる、と思っていたけど、そんなことはぜんぜんなかった。
ゴールデンウイークでいっぱいになる
同じ大学でOB訪問→リクルーター通してトヨタやデンソーの内定をもらう人がいる
サイトがオープンする前にいつでも面接に対応できるようにしておく
マイナビ等に頼るべきではない。
人事は第一志望でないと取らない。
外でのセミナーは1度顔を出しておく。学生の真剣なところを目の当たりにしておく
・イベントに頼るな →学内セミナー（会社説明会と同じ）は重要 AIUは企業が大学に来る。
新聞を読むと（毎月読む）流れがわかる。
２～３か月見てるとわかる
↓
どこで自分を役立たせるか？
キーワードを作って比較。KDDI NTTなど 売り上げ などのキーワード
売り上げというキーワードならソフトバンクが第一志望ですと言える（売り上げで世界一へ）・・志望理由になる
人事が見ている場所・・なぜ？他と比べて？
ある程度絞る必要がある
50～40で絞り込んで研究をしっかりやっておく
場面場面で”これ”という言葉
のめり込んでいる程度はわからない。
ある日、現在は地方に住む同級生から「東京に行く用事があるので会わないか」と連絡があった。
特に用事もなかったので「いいよ」と答えた。待ち合わせ場所としてとある駅を指定された。
都内ではあるが、あまりカフェなどがあるような場所ではなく、交通の便もそれほどよくない駅をしていされたので、
不思議に思ったが、「美術館になるカフェ」があり、落ち着いて話ができるから、ということだったので、
彼女のいうとおり、そこに決めた。
当日、待ち合わせの時間を15分ほど遅れて彼女は到着した。あってすぐに違和感を感じた。
まず、まったく化粧っ気がない、髪も伸びっぱなしで、服もかなり地味でおばさんくさくなっている。
彼女とはもう10年以上の付き合いだが、前はもっと普通の服装をしていたし、地味だと感じることはなかった。
その時は、地方生活に慣れてあまりそういうことに気を遣わなくなったのかな、程度にしか思わなかった。
しかし、そこはまったく美術館ではなく、外見はただのビル。中に入ると、そこは仏教系の新興宗教の道場のような場所だった。
中はかなり静かで、きれいな内装。靴を脱いであがるようになっており、広い廊下の端では信者の方が車座になってすわり、
何事かを熱心に語り合っていた。
そのビルの上のほうにオープンテラスのカフェがあり、そこで話をすることになった。
久しぶりに会ったので、お互いの近況を話たあと、その団体についての説明が始まった。
勧誘ではない、と前置きしながらも、ウェブサイトをスマホで見せながら説明をされたが、
仏教系の団体であり由緒ただしいこと（新興宗教ではないこと）京都のお寺が元締めだということ、
はわかったが、それらの具体的なことが全然わからない、抽象的な話に終始したので、
よくわからないのでまた調べておく、といって話を終わらせた。
あまり長居したくなったので、もう帰る、というと、別の場所に案内したいという。
一応ついていくと、金ぴかの仏像のようなものがおかれた部屋に案内され、説明を受けたが、
最後、出口でパンフレットのようなものを渡され、そのまま解散となった。
後で調べると、かなり高額なお金を巻き上げるような仕組みの団体らしく、
それがゆえに、服装や見た目にお金をかけられなくなっていると想像される。
また、おそらくその団体内で地位をあげていくには、信者の勧誘がノルマとなっているようで、
そのために今回、自分に声がかかったのだろう。
具体的には勧誘はされなかったのだが、深入りはしたくないので、パンフレットは捨てて帰った。
もう彼女と連絡をとることはないだろう。
○朝食：納豆ご飯（つゆたっぷり納豆を二つ）、ツナマヨ、ごぼうサラダ、杏仁豆腐
○昼食：納豆（ねばうま納豆を二つ）、スライスチーズ、ピーナッツ
○夕食：納豆ご飯（昆布だれひきわり納豆、あおさのり納豆）、チキン南蛮
4/29時点の暫定ランク
1.あおさのり納豆（都納豆） ： http://www.miyakonattou.com/products/detail.php?product_id=109
2.つゆたっぷり納豆（おかめ納豆） ： http://www.takanofoods.co.jp/products/detail.php?id=103
3.昆布だれひきわり納豆（昆布だれひきわり納豆） ： http://www.adumas.co.jp/item/detail.php?n=0194
4.ねばうま納豆（おかめ納豆） ： http://www.takanofoods.co.jp/products/detail.php?id=101
まず、昆布だれひきわり納豆は、昨日のつゆたっぷり納豆と同じく、出汁が大目のパターン。
ただ、ひきわりと大目の出汁はイマイチ相性がよく感じなかった。
ひきわりは単体としての味が美味しくなるので、ご飯との相性もイマイチ。
これは普通の出汁の変わりに、あおさのり入りの出汁が入った納豆。
納豆っていう強烈なインパクトに、あおさのりが全く負けていない！
それでいて、別々の味が二つする感じでもなく、納豆の「豆のネバネバした食感」とあおさのりの「ノリの香り」が絶妙にあっている。
なんかもう「納豆って食べ物は普通あおさでしょ？」って思うぐらい、初めて食べたのに、長年のタッグ感が凄いする。
っていうか、今調べたら、あおさって地元の食材なのか、普通に全国的に食べられてるものかと思ってた。
えーっと、ようするにノリです。
お味噌汁に入ってるとテンションが上がる食材ナンバーワンとして有名だと思い込んでた。（そうか、これは地元あるあるなのか）
○調子
むきゅー！
さあゴールデンウィーク開幕！
ゲーム遊ぶぞーーー！
忘れていた。
そう、完全に忘れていた。
Ever17のコメチョ、Never7の大学生ノリ、EVEニュージェネのギャグになってないギャグ選択肢を……
タルい、非常にタルい。
ここ最近の999や善人は脱出ゲームっていうゲーム自体が楽しかったから乗り切れたけど、
このパンチラインのミニゲームは、もうビックリするぐらいどうでもいい。
（パンツを見ないこと、がゲームとして成立してない、見えそうになったら右押すか、L押すかするだけだから）
ミニゲーム自体がただのポイントアンドクリックで、ノベルゲ大好きのくせにPandC大嫌いなので、ちょうタルい。
ああ、R11の序盤が懐かしい、このライターはあれぐらいの極限状態じゃないと、本当にタルいんだよ。
（いやもうそのタルさのまま突っ走った12Rは逆の意味で神ゲーだと思う）
一話一話にオープンとエンドを用意してるわりに、話が一話完結じゃないし、
かといって、上記で書いたタルい感じのまま進むのでなんて言うかもう、
集中力が続かない。
あともう「無理ならやるなや！」ってずっとツッコミ続けてる。
どうも3Dキャラを動かすのがハードのスペックの問題なのかわかんないけど、
描画するのが難しいらしく、
なんていうか「ひだまりスケッチアニメ無印の富士山回」みたいになってる。
平たく言うと「作画崩壊」だ。
（てさ部二期の序盤みたいな感じ）
パンチラミニゲームが楽しいなら、3Dにした意味もあるけど、そのミニゲームもしょうもないから、
「普通にKIDシステム流用して、普通にノベルゲ作れや」って言いたくなる。
とまあ、文句たらたら言ってるけど
（12Rのことは忘れてないが）
なので、あえて不満を言語化して、オーラスに構える大フィナーレを楽しみに待っているのです。
ああ。こんにちは。
今日はゲームのお話をさせてください。そんなに長くないので、ほんのちょっとだけお付き合いくださいね。
私たち人類は、太古の昔っからゲームが大好きなんです。あなたもゲームしますよね？トランプとか、スゴロクみたいなアナログみたいなものから、テレビゲームとか、スマホなんかのゲームもします？ああ、そうですか。あれ、ハマっちゃいますよね。うっかり課金しちゃったりとか。わはは。
でもね、わたしの知ってるゲームシステムは、それよりも、もっとすごいんですよ。「ゲームプール」って言いましてね。映像とサウンドだけでなく、「触った感じ」もリアルに体験することができるやつです。「触覚なんとかファーム」とかいう技術らしいです。自分から言っといてアレですけど、詳しいことは知りませんので、聞かないでください。わはは。
コレすごいんですけど、見た目は全然イケてないんですよねぇ。簡単に言うと風呂ガマです。「棺おけの形した風呂ガマ」ですよぉ。イケてないですよねぇ。この棺おけの風呂に専用のトロトロ液体を入れるんです。んで、そこに横になって浸かるんです。そうです、人が横になるんです。ゲームのために、です。ドロドロの棺おけに、です。さっきの「触覚なんとか」の技術で、ドロドロの液体が「触った感じ」を伝えてくれるんですって。あ。詳しいことは聞かないで。へへへ。
こっからは、歴史の教科書に載ってた話です。先に言っときますけど、受け売りですからね。
このゲームシステムの開発にかかわったY博士ってのが、昔、いたらしいんです。
彼の開発した初期ゲームシステムって、ゴーグルみたいなやつを頭にかぶってイヤホンして、視覚と聴覚に訴えるものだったんですけどねぇ、いや、これはこれで当時は話題になったんですよ。でも、これリアル感に限界がありましてね。どうやったら、リアル感を高められるか、と。
で、結局、Y博士が最後の最後に行き着いた結論が「ゲームプレイ中に、ゲームであることを忘れさせる」システムだったんですよ。ええ、もちろん記憶をなくすのは、一時的なものでゲームが終わったら思い出すんですけどね。
いやいや、これが世界的な大発明でしてね。Googleやら、アップルやら、特許の買収合戦がすごかったんです。ある国なんて、国土の半分と交換に買収交渉したんですよ。びっくりですよねぇ。
ま、いろいろありまして、結局、Y博士は、どこにも売却しないでシステムの設計図から、特許まで全てをオープンにしましてねぇ。そっからですよ、人類が大きく変わっちゃったのは、、、、。
いまでは、人類のほとんどが「ゲームプール」の中にいるんですよ。150億人くらいですかねぇ。プールの外にいるのは、メンテナンスのスタッフだけ。たった40人ぽっちですよ。150億人のメンテナンスするのに、40人ですよ。すごいですよねぇ。
え？みんながやってるゲームですか？
いろいろですけど、ほとんどの人が「REAL STAGE」っていうやつですね。これ、世界中で大ヒットの一番人気です。
現実世界とほとんど変わらない仮想世界で生活するやつなんですけどね。この「REAL STAGE」に130億人くらいいるんですって。「いるんです」って言っても、ホントはゲームプールの中に、ぷかぷか浮かんでるんですけどね。ははは。ぷかぷか。
このゲームの人気のポイントは、なんといっても、「産まれてから死ぬまで、人生まるごと体験できちゃう」とこです。
もちろん恋愛もあるし、結婚もあるし、青春もあるんです。でも、楽しいことばっかりじゃないですよ。困難あってのゲームですからね。学校行って、仕事して、学んだりして、どんどんスキルアップしていくんです。時には特殊な能力を身につけたりすることもあるんです。僕の友達なんか、なんと「将棋」の能力がすごくて、将棋の「能力メーター」が振り切れちゃってましたからね。ゲームの中で、なんとか名人とかになってましたし。ホントいろんなスキルがあって、身につけるのが楽しいもんですよ。
、、、、。
いろいろ、学んで、いろんなスキル身につけたら楽しいですよねぇ、、。
、、、、。
あ。覚えてます？ 最初に言いましたけど、このゲームは「ゲームプレイ中に、ゲームであることを忘れさせる」システムですから。
、、、、。
ゲームやってる、ってことを忘れちゃって、現実世界だと思っちゃうんですよ。もちろん、記憶をなくすのは、一時的なものでゲームが終わったら思い出すんですよ。
、、、、。
、、、。
うーん。
、、、、、、。
、、、。
んー、ここまで、お話ししても、まだダメかぁ。困りましたねぇ。
、、、。
もう、こうなったら言っちゃいますけど、驚かないでくださいよ、、、。
、、、。
この文章読んでる、あなたは「REAL STAGE」の中にいるんですよ。
もちろん、ゲームのプレイ中は記憶を消してるから、分かんないんでしょうけども。
ただねぇ、あれなんですよねぇ。あなたのプレイ見てると、何年も、ずーっと冒険はじめてないんですよねぇ。
せっかくのゲームなのに、もったいなくて、もったいなくて、見てられないんですよ。それで、あなたにアクセスしてるんです。
え？わたしですか？
ほんとは、ゲーム中の人に話しかけるのは禁止されてるんですけど。あなたのプレイ見てたら、もう黙ってられなくて。
いや、ほんとに、もうすこし冒険しないと楽しくないですよぉ。このゲーム。
あ！監視員がやってきたんで、この辺でアクセス切りますよ。あいつにバレたらクビになっちゃいますんでね。
じゃあ、あと数十年分のタイムが残ってるんで、たっぷりゲームを楽し
いつも行くコンビニのお店の
ホッツコーナーのコーヒーがなくなってて、
仕方なくアイツのコーヒーを買ったんだけど、
そういうの見ると
移りゆく季節を感じるわね。
なんかもう本格的に冬、終わっちゃったのね。
そういえば、
いよいよ
春ねって感じだわ。
ビアガーデンが始まったばかりと言っても、まだちょっと寒いじゃない、
あれって、
なんかビアガーデン来たのに
おでん食べちゃったりなんかして
あの上島さんの目隠しして
ほっぺで何の具か当てる利きおでんするのが好きだわ。
あの熱いやつのよ。
うふふ。
でも朝はしっかりめ、
昼は軽く、
そして夜はトマトジュースで続けていけば
痩せると思わない？
信じる力が大切よ。
今回はそのままクラッシュせずに入れてみたんだけど、
クラッシュした方が、
急な仕込みには最適ね！
すいすいすいようび！
今日も頑張ろう！
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
辞めたい辞めたいと思ってたパートを辞める決心がついて、やっと今月で辞めることになった。
今日は最後の繁忙日でシフトも足りないし針のむしろなのは分かっていたけど、逃げないで行った。
案の定、一番当たりのキツいパートからは更にキツく当たられ、他の人は我関せずだった。
予想はしていたけど、どうして自分ばかりこんなにキツく当たられるのか分からない。
思えば入った時から、何か嫌な人だなとは思っていた。
いつも、だいたいそう思う人とは大概仲良くなれないしトラブルになる。
今いれとこのその人も、私が若いバイトの子とたわいもないことを話してるのが気に入らなかったらしく、
その後は穴を埋める為に延長させられた。
後日、そのおばさんは普通に来たらしい。
後から聞いた話しだけど「私は悪くない」の一点張りで、つまりは私が悪いと言うのだ。
確かに話してはいたけれど、普段からおばさんの方がよっぽど話しているし、理不尽だと思った。
それ以前から苦手だったけど、そういうことがあり避けるようになったし、
チマチマチマチマ嫌味や嫌がらせをされるのを、ずっと我慢していた。
シフトはほとんど毎回一緒で、毎日行く前はお腹が痛くてたまらなかった。
おばさんは他の気の強いパートさんの前では静かにし、当たり散らすのは私だけだった。
店長にも相談したけどあの人はああだから、と言われどうして真面目にしてる方がバカを見るのか分からなかった。
とにかくもう仕事のあとはぐったりしてしまい、家事も育児もままならなかった。
そういうイライラが弱いところにいってしまうのが嫌だったし、なによりそうしてしまう自分が嫌だった。
どうして理不尽に人にキツく当たる人がどこにでもいるのだろう。
どうして私は毎回そういう人のターゲットになってしまうのだろう。
旦那に話したら舐められるようなお前が悪いと言われた。
仕事は大変だし、疲れる。当たり前だ。
なんだかもう働くのが怖くなってきたし、人と関わるのが怖くなってきた。
しばらくはゆっくりしてまた新しい仕事を見つけようと思うけど、
どこに行っても気が強く嫌な人間は必ずいる。
とにかく今は早く辞めて悪縁を切ることだけ考えてる。
http://anond.hatelabo.jp/20160422184218
↑これの続き。
-----------------------------------------
こういうことを書き捨てていくと老害がいなくなっただけだって思われるかもしれないんですけど、このセグメント問題ってのはサービス運営の側に立って考えるととても難しいものじゃないかって考えているんですよ。
これについてはきっと中の人も葛藤があるだろうなーってのは思います。なんだかんだ生え抜きの技術者がいるだろうし、自分の知っているユーザー層とは違うサービスになりつつあるという思いがある人はいるんじゃないかな、と想像します。でも、ビジネスとして、商売として考えるならば、敷居を下げて、大衆的な（むしろ衆愚的な）話題のコミュニティであっても、ライトユーザーに拡大できて、キチンと定額課金と広告料を取っていかなければならない。短期的に見れば、これはむしろ最重要課題です。
散々書きましたが、個人の思いを割りきって仕事人間の立場として考えるならば、はてなブログPROの月1,000円（2年契約でも600円）っていうモデルはよく踏み切ったなーって思ってるんです。ネット系ベンチャーのご多分に漏れず、マネタイズで苦労してたはずですからね。
自分でいじれる人にとっては、システムの機能だけ見ればこの有料サービスはほぼ魅力がないです。安いホスティングのレン鯖やクラウドにWordpressを入れたほうが安いし、写真なんてGoogle PhotoだってFlickrだって使えるのに。実際のところは、「好きなアフィリエイトが設定できる」「あれやこれやを堂々とやれる『市民権』を得られる」というメリットが大きいですよね。はてなのユーザコミュニティを活用できて、ブクマとスターが近くて、初心者でも扱える。つまり、あの界隈って、ネットサービスのビジネスモデルとしては私のような厄介なユーザーよりずっと適切なターゲットユーザーなんですよね。
でもね。でも。あくまでも「短期的」は「短期的」でしかないんですよ。
運営している人も絶対わかってると思うんですけど、サービスにはコアが必要なんですよ。ストーリーがあって、そこから生まれたコアユーザーがいて、インフルエンサーになって規模を大きくしていく。特に、はてなみたいなコミュニティは、ユーザーによって育てられてきたサービスでしょう。
古い考えかもしれませんが、ブランドっていうのは一朝一夕ではないんですよ。「ブランドは作れる」なんていう広告代理店の言葉もありますけど、勘違いしちゃいけないのは、その作るってのは買ってすぐできるっていうことではないっていうことですよね。理念があって、コアユーザーがいて、クチコミで広がっていくものでしょ？だから、仮にイメージの転換が急務だったとしても、ユーザー層がガラッと入れ替わっちゃうと、後が続かないんじゃないかなって思うんです。
私自身も仕事で広告出稿したりすることもあります。ECをやってるんで、検索流入や、導線や、コンバージョンも気になります。
だから、アフィリエイトを貼ってくれるようなブロガーさんとはお仕事的にはパートナーだったり、お客さんだったりとありがたい存在でもあります。誤解のないようにはっきりさせておきますと、私はアフィリエイト広告自体は（PV稼ぎのモラル問題とかは別として）全然否定していないです。PVが増えて嬉しい気持ちだってわかりますよ。自分だって嬉しいから。
でも、ネットコミュニティを扱ってきた人間の端くれとしてつくづく実感しているのは、人は思いのこもった言葉で動く、コピペじゃ人は動かない、ってことだったりもします。
本当に好きなものを好きだからとブログを書きたい人は、ポイントがつこうがつくまいが、アフィが貼れようが貼れまいが、とても面白い記事を書いてたくさんの人を連れてきます。上手い下手はありますが、全てではないです。逆に……って、書かなくてもこれは言わずもがな。
アフィで炎上芸をやって、PVガー流入ガーって言う人を見るとちょっと寂しくなります。それが社会の現実だからしゃーない、っていうのもわかるんですけど、世の中には本気で知ってもらいたいと思う情報を見てもらうためにタイトルを一文字変えるとかバナーをA/Bテストするとか、本気でサイトを便利にしたいと思ってボタンを1ピクセルずらすとか何ミリ秒レスポンスを早く返すとかやってる人がたくさんいるわけじゃないですか。どうせなら、そこに乗っかるコンテンツも良いものであって欲しいじゃないですか。
そんな業者やオタクの言うこと知るか、って言ってきた人もいるんだけど、でも、本気で自分が作ったサービスや、あるいは自分が書いた記事で便利に使ってもらいたい、喜んでもらいたいと思っている人間としても、あるいはユーザーとして本当に面白いコンテンツにめぐりあいたい、って思っている人間としても、皆にとってそれぞれ満足できる「界隈」があるといいな、って思うのです。データマイニングを駆使した個人別最適化によってコンテンツが出しわけられているのでも良いのですが、はてなのような個性のあるWebサービスは、できればユーザーが体験を共有できる「オープンなはてな村」であってほしいものです。
最近はじめてブログを書こうと思った学生だって、ITにそれほど強くなくて、お友達とブログを書きたい、ついでにお小遣いももらえたらラッキー、っていう純粋な気持ちでやっている主婦だって、古参から「最近の奴らは……」なんて言われて恐縮する必要なんてないと思うし、共存できると思うんですよ。
ただ、アフィリエイトだけが目的で確信的にやってる層は同じ「素敵ですね！ありがとうございます！」でも、なんとなくわかっちゃうんですよね。そういう記事ばかりが眼に入るようになると、正直ちょっとうんざりします。
また脱線しましたけど何を言いたいかっていうと、要するに、「長期的に見た場合」としては、コアユーザーとサービスの特色がキチンと育っていて、他のユーザーの共益を阻害しない、っていう状態じゃなきゃいけないんじゃないか、っていうことですね。
この特色付けにしても、はてなブログはもうちょっとうまくやれたんじゃないかなあ、って余計なお世話なことを思ったりするところはあります。もっとも、まったく小洒落ていて気が利いた広告戦略やマーケティングとかできるようなキラキラな会社じゃなくて、それとは真逆の非モテ野郎どもだった（勝手な想像）、っていうところがはてなの好きなイメージだったわけではあるのですが。
※ほら、何年か前に、2chで「Webサービスを擬人化したったwww」っていうネタ流行ったじゃないですか。hagexさんがまとめてたと思いますが。あれのね、はてなの擬人化イラスト、皮肉じゃなくてわりと悪くないんじゃね？って思ってたわけです。ミサワがドヤ顔してるやつ。少なくとも、mixiモバゲーがウェーイしてるのとかよりかずっといいですよ。
同じ大衆化の道を辿るにしても変なミニマリスト界隈とか、アフィ軍団とかに捕まるくらいなら、もっと有益なカルチャーを形成できる仕掛けってなんとかならなかったものかなあって。いや、外野が1秒で思いつくこんなことはいくらでも考えつく人がいるだろうし、プラットフォームとコンテンツの話は別だろとも思うし、既にブログMediaで提供されているみんなのごはんとか気に入って見てるんですけど、ジャンルはともかくとして、そういう書き手を集める営業はやっぱキラキラ系のところのほうが上手いんですかねぇ。
お前誰だよ、なんでそんな熱く語ってんだよ、と誰しもに思われると思うんですが、実際のところ私は自分用にブクマを使っていただけのユーザーですし、ブログサイトを作っていじる側が中心だった人間なもんで、自分自身が上げたコンテンツはそれほど無いです。すみません。
最近ちょっとだけはてなブログを個人用日記に使っていたんですけど、今改めてMTでもWPでもないブログポータルを使ってみたらどんな感じでどんなことを思うんだろう、ってことに興味を持ったためです。この文章は、その結果として書いています。
はてなブログ自体は便利で書きやすくてとっても気に入ってます。βテストの時はカテゴリすらなく本当にシンプルで大丈夫か？って思いましたが、特にGoogleフォトやTwitterなどの外部サービスからの貼り付けが気に入っています。確実にダイアリーより使いやすいです。今後もますますの発展をお祈り申し上げますです。
なんだかんだ書きましたけど、要するにですね、私は単なる無名ユーザーですけど、こういう熱心なファンもいるんですよってことなんです。今までたくさんの発見と感動をもらったことに本気で感謝してます。興味深い！参考になる！感謝！とかそういうのではなくて。
距離を置く、と書きましたが、自分の情報クリップの習慣として、はてブ⇒Evernote連携の流れが便利で染み付きまくっているので、引き続き淡々とブクマは利用させていただきたいと思います。今まったくお金を落としていないことに罪悪感すら感じていますので、お礼の気持ちを込めてちょっとスターでも買って、ホソボソやっていきたいなと思います。
古参物書きも、ギークも、ステキ主婦も、手斧軍団も、お小遣い稼ぎの人も、みんながワイワイ楽しくヒャッハーできるやさしい世界ができるといいですね。
草々んじゃーね。
まずは、大変遅ればせながらはてな上場おめでとうございます。2ヶ月遅れですが。
先にお断りしますと、この文章は長いです。12,000文字近くあります。そう言えば最近「長すぎて読めない」ってタグ見なくなりましたね。
元々は数日前に自分のブログに投稿したのですが、アイコンを見てもIDを見ても誰にも認識されていないであろう私がこんなことを書いているのも気持ち悪いような気がして、衝動的に消してしまいました。そんな文章ですが、せっかく書いたので思い返して増田に投下します。それでも交流のある僅かな方からは、「あ、あいつだ」とすぐバレると思いますが、全く構いません。
大げさな振りをしてしまいましたが、この、はてなの世界からゆるやかに距離を置こうと思いまして。
ハイコンテクストな話題で、関係者でも有名ユーザーでもない私が語るには随分と分不相応であろうことは承知しているのですが、私は人知れず長年このはてなという会社とそのサービスの利用者でした。たぶん、相当熱心なファンのほうだと思います。
しかしこのはてなという界隈、おそらく長年世間一般的には「俺ははてなが大好きなんだー！！」とはなかなか言い出しづらい雰囲気と言いますか、一部一種のギーク（ナードか？）臭さみたいなものから逃れられないセグメント感があったために、公の場であまりそれを声を大にして語る機会が無かったという状況があったような気はしています。
勝手な想像ですが、よく言われるとおり先日上場した株式会社はてなとしてはきっと、そういった閉鎖的なカルチャーからの脱却を図る必要があるのは事実なのであろうと考えています。
私は「はてな界隈」という自然発生的な、「インターネット好き」が作ったプラットフォームとコンシューマージェネレイテッドなコンテンツが組み合わさってできた若干マニアックな文化がとても好きで、かつてインターネットに期待していたワクワク感のようなものを自分の感性ともっとも近い形で目指している会社だなと思っていたので、はてなを好んで使っていた理由も、今これを書いている理由も、サービスが向かう方向性とのギャップが発生したということで仕方ないのかな、と考えてはいます。
回りくどい書き方ですが、つまり、ここ最近（数年）の急激な利用者層の変化、人気ブログやホッテントリに上がってくる記事とその使われ方の変化、新たな利用者層との精神的摩擦に疲れて消耗するのが嫌になった、ということです。
私は自分の楽しみのために自分が面白いこと書き、読むっていうスタンスで自分のスペースを使ってきたので特定のユーザー群を非難するのはその趣旨とズレるし、メタな「ブログ論」を書くつもりは無いんです。なのでわかりやすいバズワードは書きませんけど、要は、そういうことです。お察し。
ここまで書いておいてから自己ツッコミを入れますが、私がここでこんなことを書いていても、おそらくそれほどの価値は無いのでしょう。
私は長年使っているとは言いながらも、所謂「はてな村」と言われるような有名ユーザー層に所属するようなアカウントではないし、特別人に見られるコンテンツを上げていたわけでもコミュニケーションを取っていたわけでもないし、こんなことをグダグダ書いていても「知らない人。気持ち悪い。」で片付けられてしまうような気はします。
コンテンツもお金も落としてもいないアカウントですので、ある意味運営側の立場から見れば、「うるさいことだけごちゃごちゃ言って全くサービスに貢献しない面倒くさいアカウント」あるいは「フリーライダー」と言われても仕方がない気がします。
これは別に被害妄想を語っているわけではなくて、自分がサービスを利用して得たメリットと、お客さんとしての価値を第三者的に見た時、そういう風に判断されてしまっても仕方ないかな、と冷静に思っただけです。
最近、はてなブログやブクマを見ていて、「これは自分には合わないな」と思ってケチを付けたくなる機会が多くなってきたことと、でも、ケチを付ける発言力（あるいは権利）のバランスを天秤に掛けて、ああ、もう自分が楽しく見ていられる場所ではないのかな、と感じることが増えてきたことと、単なる1ユーザなのにそんなことを考えてしまうこと、考えさせられてしまうことが嫌になってきてしまったということがあって、こりゃ、私の居場所はもう無いのかもしれないな、と思いつつあるということです。
かつての掲示板サービス群から始まってブログランキングやら、SNSやら、インターネットのサービスではいろんなところでこのような文化の変遷みたいな場面は見てきたはずなのだけれども、思ったより自分の生活の大きな部分にはてブが入り込んで浸透していたことに自分でもかなり驚いていますね。
前提としてなぜ、こんなマイナーキャラの私がそこまで一、ネットサービスに入れ込んでいたのかについてちょっと語らせてください。長くてすみません。
私のはてな歴は12年くらいです。長かったらどうだというわけでは無いのですが、はてなを知ったのはまだ人力検索しか無かったころで、自分が実際にユーザーになったのは例の「日本人にはブログより日記」のちょっと後、「はてなダイアリーをはてなブログに名称変更」とかエイプリルフールネタでやっていたころです。最古参ではなくて、ブログブームの頃に「はてな界隈」を意識するようになったので第2世代くらい、ということになるのでしょうか。
その後アカウントが一回変わっていて今のIDは5、6年くらい前に取りなおしたものなので、おそらく古参ぽさは無いですね。
はてなには他社のサービスと比べてとりわけIT系ユーザーの比率が高いと思いますが、私もそうです。一貫してネット関連ですが完全な同業というわけではなく、何度か変遷を経て今は流通系事業会社のインターネット事業担当になったというキャリアです。
はてなのサービスを認識した時はちょうどMovableTypeの2.6あたりが日本でも流行りだした頃で、「Web日記がhtml無しでこんなに簡単にできるなんて！」「コメントとかトラバとかすげー！コミュニティ作れまくり！」とかっていう話題で日々興奮していたのを覚えています。90年代後半からネットは見ていたけれど、これからいよいよ「普通の人」にもオープンに普及していくんだなー、と夢描きながら仕事で、あるいはプライベートでどう活用しようか考えていたんですよ。「Web2.0」より2年前くらいのことですね。
その頃、ちょうどあるECサイトのコミュニティサービスの担当をしていたんですね。いろいろやりましたよ。掲示板サービスが炎上して閉鎖に追い込まれたり、画像著作権で揉めたり、ブログが使えるようになってからは、「ブログに商品の宣伝を書いてリンクを貼ってくれたら100ポイント！！」とかいう現代であればGoogle警察が1日でぶっ飛ばしにくるようなプロモキャンペーンもせっせこ考えては公開してました。更にその後はOpenPNEベースのmixiっぽいSNSをやったりとか。
今考えるとうわーっていう企画も多かったのですが、おおらかながら大真面目にやってたんですよ。まじめに、ライトユーザーに使ってもらうにはどうしたらいいかとか、コアユーザーがどう伝搬してくれるかとか考えてました。その頃は（ネット上のマーケティングにおいては）セグメントの乖離とかそういう問題も今ほどは研究されていなかったし、たぶん自分でもまだ十分理解できてなかったんですよね。私はそんな感じの人間です。
自分語り方面に脱線したので話を戻しますが、ブログブームちょい前の頃、世の中で出始めたブログのアカウントを片っ端から取っては試すということをやっていたんですよ。ココログ、はてダから始まって、livedoor、goo、Excite、Seesaa、Jugem、FC2、楽天、MSN、ドリコム、ウェブリブログ、ドブログ、Yahoo、ヤプログ、アメなんたら……
でですね、そのときにはてなの特異性に気付いたわけです。
なんだこりゃ、殺風景なサイトだなぁ、なんか研究室みたいだなぁ、システム屋くさいなぁ、ってのが当時の正直な印象です。まったく間違ってないと思いますが。
ダイアリー以外の他のブログサービスはだいたい大手キャリア系か、大手ポータル系か、大手ホスティング系のいずれかじゃないですか。実際仕事で関わることがあったのはそういった会社さん達だったわけだったんですけど、私個人的にはこのはてなダイアリーってやつにとても興味を持ったんですよね。
純粋にIT系オタク集団（失礼）がコミュニティで勝負するっていう構図のサービスがすごく面白いなって思いまして、当時から実際にIT系のギークな技術記事とか、濃厚なネットのいざこざとかそういうのがぐちゃぐちゃと集積されつつあって、うわぁ危険と思いながらもはてなだけは明確に識別して見に行く感じになってたんですよね。
人力検索もそうですが、アンテナとか、キーワードとか。私はネットコミュニティをやりたくてこの世界に入ってきた人間なので、人と人をつなげるサービス、というコンセプトに対して面白いことをやろうとしている人達がいるんだなーって思ってたんです。こんな殺風景な非コミュ論壇だらけのサイトなのに。なんだかそのギャップがまたすごく居心地が良くてね。よく閉鎖的って揶揄されるはてなですけど、私はそんな風に思ったことなかったな。
そう、私は村感というよりは、僻地の秘境だけどここは自由でオープンだ、っていうように感じていたんです。
今はなおさら顕著ですけど、その頃って既にインターネットサービスが外来の大手サービスに集約されつつあったじゃないですか。ブログにしたってMovableTypeもWordpressも外から来たものだし、MySpaceとか、Facebookもそうだし、その後の流れって周知のとおりって感じじゃないですか。強いて言えばmixi……はやっぱべつにいいや。
そんな中、日本のドメスティックな小さなネットベンチャーが純粋なコミュニケーションの仕組みだけで世界観を醸成して、しかも生き残るっていうことに夢を感じたんですよ。まあ、ドメスティックっていう部分について言えば、jkondoさんが渡米した時期とかあったなぁ、とかあるんですけども。
はっきり告白しますけど、私のような自分で新しいプラットフォームを開発するほどの実力が無い中途半端なネット屋にとって、超恥ずかしながら彼らはヒーローだったんですよ。jkondoさんやnaoyaさんは私とほぼ同い年ですけど、勝手に同世代のヒーローだと思ってたんですよ。
はてなブックマークでソーシャル・ブックマークという概念を身近に体験した時は「単なる『お気に入り』じゃなくて、興味を持ったものについて何時でも語り合える世界が作れるんだなあ」ってリアルに衝撃を受けたし、スターが登場した時は（FacebookやTwitterより前に）これ、シンプルだけどもしかして世界を幸せにする機能じゃね？って感動したりしましたよ。
だいたい、jkondoさんはすごいんですよ。私など勝てる要素が無いですよ。スプリントでもロングでもヒルクライムでも絶対勝てないですよ。山も強いし、みんな山手線一周1時間48分てできます？？サラッと書かれてたけど、メチャクチャ速いよ！！俺も何度もやってるけど、大真面目にやっても3時間切るのだって大変だよ。明治通りや中央通りはともかく、田端駒込あたりの裏路地とかどうしてたんでしょうね。メッチャ危ないよ！！つか、あの頃の自転車クラスタみんなどこ行っちゃったんでしょうね……
何の話でしたっけ。そうそう、趣味が合いそうな人達が集ってるっていう話でしたね。
私の文章は、テキストサイトからアルファブロガーあたりまでの文章にめちゃくちゃ影響を受けていると思います。ちょっと極端なことを書いたら「フロムダ先生の真似か」とツッコまれてドキッとしたり、写真クラスタの真似をしてやたらでかい写真を並べてみたり。最近は年に一回お正月だけに現れるmk2さんの文章を見ると涙が出そうになります。長文には慣れています。必死に調べないとついていけないような技術論議や、内蔵をさらけ出して書いたような、編集が入った本では読めないようなブログを読みたいし、そういう記事でみんなが共感していく世界が見たかったんです。
はてなブログの目次記法は便利だと思うんですけど、他所のニュースサイトに貼られた記事を引っ張って目次を並べていかがでしたか？なんていう記事を、私は単純に面白く読めないんですよ。「参考になりました！」じゃねーよ！！ならねーよ！！残念すぎるだろ！！なんて思ってたんですよ。
ここまでで既に5,000文字を超えてしまいましたが、話が飛んでしまったので一旦元に戻します。
つまり、そういった「自分の好きなものを好きと言う」「好きなものを選んで、好きなものを見て共感する」という、人の本能的なコミュニケーションの楽しみの源泉のようなものを、私は求めていたんだと思います。自分の背中に正直な、泥だらけのスニーカーで追い越すような体験を期待していたんです。
もちろん、どんな時代にだって人と人のコミュニケーションにはいろいろあって、変わらないものがたくさんあるんだとは思いますよ。パソ通の時代だって、BBSの時代だって、初期のブログにだって、「読みました。記念カキコ☆」はあったし、コメント欄で交流が繋がって新たな友達ができるという興奮だってあったし。
最近のはてなだって、今、その興奮を新たに体験して純粋に喜びを感じている人達がいるはずだしそれはもちろん喜ばしいことなんですけど、さすがにこの情報過多なご時世なので、ツールと場所の管理と運営をしっかりやっていかないと、純粋な喜びを埋もれさせず、コンテンツの品質を保つのは相当に厳しいなという実感はありますね。
一般化、大衆化、というものはだいたいそうで、単純に「この村も昔は良かったのに」っておじいさんが言っているっていうような話ではないと思うんですよ。
こんなことを話している私自身が既にネット上では「古い側」の人間になっているのかもしれませんが、個人的には、「はてな村」とかって言われている界隈にそれほどイライラするような内輪感を感じたことは無いんですよね。実際にひどい攻撃的な言葉が飛んできて嫌な思いをしたことだってありますし、慣れ合いとかってのは昔も今もあるわけなんですけど、だいたいは好きなことを好きなように書いた、っていうモチベーションによって書かれた記事は、面白ければ当たるし、面白くなければ流行らないわけじゃないですか。読む側だって気に入ったら読めばいいし、気に入らなかったらスルーすればいい。だいたい、広い世界で見ればごく一部のできごとだっていう側面もあったわけじゃないですか。
だから、一定の、嘘を嘘と見抜ける程度のネットリテラシーさえあれば、海水浴場の中に浮かぶ邪魔な漂着物があっても、農耕地が石だらけで荒地になっていても、単に避ければいいだけだって思ってたんです。
むしろ、良い記事にフォローが集まったり、ひどい記事はひどい記事でそれに集まった批判が有益だったり、そうやってやり取りを応酬する中で集合知として収斂されていくという光景は、みんなで海を掃除したり、畑を耕していくような感覚を覚えていつもネットの醍醐味であり爽快ですらありました。
……でもね。最近の例の動向はちょっと様相が違っていて、私のようなユーザーにとってはもうちょっと見ているのが厳しいな、というのが本音です。商業的なまとめサイトが場を汚染している、というような話であればユーザー側コミュニティによるチェックと自浄作用が働きます。はてブはうまいことそういう機能を果たしてきたと思うんですよね。
でも、ユーザー側のほうで「良いと思ったから良いと言った」というお気に入りによるキュレーション機能が働かず、返報性の原理によるコミュニケーションが中心の場になってしまったら、今のままのはてブでは、（コメントツールとしてはともかく）少なくとも情報ツールとしての価値は大きく毀損されます。これは、ユーザーのモラルもありますが、サービスの構造上の問題として避けられなかったことだと思うんですよね。
海や畑が全部「あれ」になったら、もうどうしようもないでしょう。もう去るしかない。
この問題についてはさんっざんぱらたくさんの人に書き尽くされているのでここでは書くつもりないんですけど、小遣い目的で面白くない記事が量産される、共有のヘッドラインが専有されて他のユーザーに影響を及ぼす、内容に関係なく相互フォローする、これらは本人の意識あるなしに関わらず、関係ない人から見たら無益です。
これについてルール違反がないのならば、サービス品質を維持するための運営／システム側の構造課題を疑ったほうが良いし、ユーザー側についても、一部の炎上チャリーンで喜ぶようなやつは単なるスパムなのでこれは単純な絶対悪ですよ。
別に、ネットの世界で今始まったことじゃないんですよ。むしろはてブは牧歌的で今まで性善説でよくやってこれたなっていうレベルじゃないかと思います。Twitterでも「相互フォロー推進委員会」とかあったなあ。一方的に何百人単位でフォローしてきて、ふぁぼりまくって、こっちが反応しないと砂をかけて去っていくようなのが……
ただそういう人達がごにょごにょ楽しくやってるだけならどうだっていいんですけど、今はホッテントリが明らかに使いづらくなっていたり、更には他のSNS経由でこの界隈の記事が流れてきて反応したらおかしなことになったり、実際にそういうことが発生しだしているんですよね。これが結構精神的にくるものがあるんですよね。
というわけで、そういう一団がこのサービスのほんの数%、もしかしたら0.数%の人達であり、ほとんどの普通の人は何も気にせず普通に自分の日記を書いているんだ、てことはわかっていても、でももう気持ち的にこの界隈と一緒の世界でブログを書くのは無理かもしれない。既に古参と言われる人達がかなり去っていっているし、生き残っている人達も読者層が急激に変わっていたりとかして、なんていうか、見ててつらい。
※最近、ある有名人気ブロガーのブログを読んでいて、半年前にも同じテーマで書かれたことがある記事がホッテントリに入っていたのを見たんですけど、ふとブコメを見てみたら、半年前の記事と反応のコメントが全然違くてびっくりしたことがあったんですよ。よく見ると、並んでいるアイコンがガラリと変わっていることに気づきました。読者層が急激に入れ替わっているんですね。
この人はムラ社会に寄る人では（読者から見たイメージでは）無いし、長い人とも新しい人ともバランスのいい関係を築けていてすごいなあ、と思っていたのですが、図らずも急激に「有名人」として新規層の神輿に乗せられているように見える状態になってしまって、一方で彼自身は広告収入で儲けているようなブロガーではないし、内心複雑な気持ちなんじゃないかな、とか勝手な心配をしていたりします。そういう人、何人かいますよね。余計なお世話すぎるとは思うのですが。
------------------
○朝食：なし
○夕食：パン三つ（クリーム、ウインナーとタマネギ、ジャガイモ）、手羽先
○調子
むきゅー！
昨日も書いた通り、画面をマウスで操作して、プリントスクリーンキーを押して、
マウスでエクセルを開いて、コントロールとVを同時押しする作業を、300回ほど繰り返すだけの簡単なお仕事をこなした。
（定時に終わり切らなくて、30分だけ残業した）
○バトルボーン
うーん、普通な感じかなあ、射撃とグレネードって感じで普通だし、あーでも回復ポイントを設置したりするのは楽しいかなあ。
次は同じストーリーモードを、オンラインの五人モードでプレイ。
すると、超楽しい！
ミコさんは味方に狙いを定めると回復レーザーを出せるんだけど、これが超超超超楽しい！！！！！！！
味方の体力を見渡しつつ、ほどよい場所に回復ポイントを投げ入れ、
僕はハッピーウォーズというゲームでも、僧侶をメインにやってたんだけど、
その時は回復よりも建築ってスキルのために僧侶をやってたので、この回復で戦線を支える楽しさは、初めてな感じ。
40分ぐらいかかるから、最初のうちは楽しいけど、慣れるとダレて楽しめなさそうだ。
購入はもう少し考えようと思う。
○朝食：なし
○昼食：おにぎり三つ
○調子
むきゅー！
お仕事頑張った。
でちでちむきゅきゅーーー！ って言いながら、プリントスクリーンとコントロールとVを同時押しする仕事を、8時間頑張った。
頭はいっさい使ってないし、体もいっさい使ってないのに、心底疲れました。
きっつい。
○バトルボーン
自分自身の理想が高すぎる気がするし、その割に就職先がFなんて時点で間違ってる気がするし。
どっちにも落ち度があるかなあって感じが。
＞オープンプラットフォームにしてほしいとか、COBOLは嫌だとか
これなんてFなら普通に避けられないようなとこだと思うがな。そう思ってなかったなら知らなさすぎ。
理由は簡単に言ってしまえば自分の目指すキャリアパスとのミスマッチ。
おそらく人事部の書類にも、今頃そんな感じのことが書かれているんだと思う。
なぜ好き好んでそんな会社に入社して、短期間で退職するはめになったのかを書こうと思う。
入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。
それもあって、同じ分野の研究を企業として行なっている同社に入社しようと考えた。
内定の前後にいくつかの職種のマッチングを行う機会はあり、自分の希望についてはしっかりと主張したつもりだったけれど、
入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。
当然この決定に対して人事に不服を申し立てたけれど、返ってくる答えはあらかじめ用意してあったような定型文と、「みんな我慢しているからお前も我慢しろ」というお説教だけ。
もちろん、規模の大きい会社だし、全員が希望通りの職種につけるとは思っていたわけではない。
でも、曲がりなりにも現代のIT企業に入社したつもりなのに、20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかったし、
綺羅びやかな会社説明の資料の中にそんな説明を見た覚えもなかった。
もちろん決定は全く覆らなかったのだけど、その後も思いつくだけの人脈を辿って色々な人に相談して助言を貰い、
せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、
できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。
それからしばらくの間新入社員研修をこなし（富士通に限らず、いわゆる日本的な大企業は研修期間がやたらに長い）、
そろそろ本格的に業務に携わりたいと思っていた矢先、上司に告げられた自分の担当業務はほかでもない、あの20万人月案件だった。
例によって守秘義務があるので詳しくは書けないのだけれど、業務を行うツールはもちろんMicrosoft Excel。
自分の仕事は言われたとおりにExcelシートに入力し、マクロを実行して成果物となるファイルを吐き出すことだった。
このマクロの挙動はとても怪しいものだったのだけれど、どうやら自分はこのマクロの修正はおろか、ソースを見ることもできない身分らしい。
SIの現場で日々行なわれている業務内容については詳しく知っているわけではなかったけれど、自分のやっていることが著しく非効率的であることだけははっきりとわかった。
そもそも、具体的な配属先については希望とズレがあったにせよ、少なくとも自分は開発職として入社したはずで、SI業務がやりたくてこの会社に来たわけではない。
とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。
確かに、Excelシートへの入力作業に情報学の修士号なんていらないし、キャッシュコヒーレンシの話なんてオタクの気持ち悪い自分語りみたいなものでしょうね。
結局これが引き金になって、転職を決意した。
しばらくの間働いてみてそれから考えるなんて、とんでもなく愚かなことだとようやく気付いた。
ただ、短い期間ではあるけども世話になった上司と、開発職の社員をSI業務に割り当てざるを得ない状況については自分も一定の理解を示しているつもりだったので、
多少なりとも会社への影響を軽減できればと思い、転職するつもりである旨を早い段階で上司に明かした。結果としてこれが大きな間違いだった。
転職の旨を伝えた週の金曜日、自席に上司から電話があり、「働く気がないならすぐに辞めてもらう」といった調子で一方的に退職日を設定された。
流石にこれは法的にも問題がある行為だと思い、すぐに折り返し電話をかけて抗議し、翌週時間をとって直接話すことになった。
翌週直接話してみると、上司はケロッとした顔で「なんだ、働く気がないわけじゃないんだ、勘違いしてた。じゃあ退職日はいつにする？」なんて聞いてきた。
自分が抗議しなかったらどうするつもりだったんだろう。
幸い、書類上は見栄えのいい学歴と、知人からの紹介と、"多少覚えのある"スキルのおかげで転職には全く困らなかった。
そろそろ就職活動が本格的に始まる頃だけど、今の就活生には是非とも就職先は慎重に選んで、貴重な若い時間を無駄にすることがないようにしてもらいたい。
だからもう放っておいて下さい。あなた方には本当に関係のないことですから。
膨大な細長い空き地が延々と続いているんです。
それが出来上がれば交通渋滞が緩和すると言われ続け、今のひどい道路事情が放置され続けてるんです。
住んでいる人たちはずっと塩漬けにされたままなんです。
もともと農道しかなかった土地に十分な区画整理もせずに道路を作ったものだから通勤時間帯の渋滞は壊滅的、かつ歩道が確保できないほどに狭い道路は危険極まりないんです。
市川駅、本八幡駅から日中なら車で10分もあれば行き来できる場所でも、通勤時間帯は40分からヘタしたら一時間かかります。
この周辺から都内へと江戸川を渡るためにある道路は6号、14号、京葉道路のたったの3本。
抜け道という抜け道に車が溢れ、毎日のように小さなこどもたちが危険に晒されてるんです。
原因はなんだと思います？
少なくとも、わたしの知る市川市民はさっさとこんな工事は終わらせて欲しかったと考えています。
子供の頭のすぐ30cm横をバスが通り過ぎるような状況を好ましいだなんて思っているわけがないんです。
最近になってやっと少し工事が進んできましたけど、いったい誰が反対してたんですか？
保育園のことで市川のことを知らない人間がわいてきて好き勝手言うのは構いませんけどね、外環の時と同じく一言言わせてください。
市川のことも知らないでギャーギャーいう暇あったら自分たちのところことだけ考えてろよ。
住んでいるところは楽園ですか？あぁそうですか。
それならなおさら市川市民として言わしていただきますけどね、はっきりいって迷惑です。
これで無理やり保育園オープンして子供が事故にあったりしたってあなた方には届かないでしょうし、届いたら届いたでまた批判するんでしょ？
一体誰が本当の悪なのかよく考えてください。
長い間、友達なんていらないと思ってた。でも一人だと悩みを消化できなくて、悶々とする。「友達がいれば悩みも話せるし、前向きになれるかも！」と思ったが、一年間勤めた会社で一人も親しくなれず、孤独のまま退職しました・・・・。とてもいい職場で、無口で無愛想な自分に優しく接してくれた人もいましたが、社交辞令でしか応対できず、いつまでたってもよそよそしさが抜けきれないのです。向こうがオープンマインドでもこちらはがっちりクローズマインド。そのうち相手もクローズマインドになってしまいました。
こんな自分でも転職には成功し、来月から新しい会社に出勤・・・。こんどこそは友達、いや気軽にオープンに話せる仲間が出来るでしょうか？ずっと一人でいるのも限界。。。友達や仲間がいる生活を夢見る毎日です。
