「しょっちゅう」を含む日記 RSS

はてなキーワード: しょっちゅうとは

2016-05-26

すぐ泣く女が周囲と自分の為にできること

私はすぐ泣いてしまう女である



物心つく前から私は超が付くほどの泣き虫で、毎日大きな声で泣き出しては母親を悩ませていたと聞く。


幼稚園に入ってもそれは変わらず、朝起きて変な形の寝癖が付いていて/雨が降っていて外が暗くて/朝食の牛乳が熱くて…とまぁ本当にどうしようもない理由しょっちゅう泣いていた。


子どもの頃から泣き虫自覚はあってコンプレックスに感じていた。小学校で作った七夕飾りの、短冊にはこう書いてあった。

「なみだが出ちゃうのを止めれますように」



26歳になった今でも私はすぐに泣く性分を引きずっている。こないだも、狙っていた特売品が売り切れたのを知って一人スーパーで涙を流してしまった。アホちゃうか。


他にも泣きたくないのに涙が出て恥をかい経験枚挙に暇がなく、あんまり振り返ってると虚空に向かって「あー!」と言いたくなってくるのでここらで止めておく。




さて、すぐ泣く女というのは世間的にはまぁ重たくて面倒くさくて、関わると厄介な存在と思われがちであるぶっちゃけ私自身もそう思っている。

しかし涙腺と言うのは思い通りに作動してくれないもので、泣いてる場合でないと頭では分かっていても勝手に涙は出てきてしまうし、止めようとすればするほど止まらない。


泣きたくないのに泣いて、周りに引かれて、自分が心底嫌になって、また泣いてしまう。泣き虫人間ならば一度はそんな経験がある筈だ。というわけで、私が26年この性分と付き合っていく中で培った、なるべくそ場の空気をぶち壊さず、かつ自分気持ちが楽になる工夫を挙げてみようと思う。


自称泣き虫の人は多分皆オリジナル処世術を持っていると思うので、もしそんな人がいたら是非自分のやり方と比べてみて欲しい。




自分をよく観察する

まずはここから始めた。成人するまでほぼ毎日泣いていた(特に問題を抱えていたわけではなく「なんとなく」泣いていた)ので、このままではマズイと思った私は毎日泣いてるとき精神状態を観察することにした。「あ、涙出始めたなー」「今頭がカッとしてるなー」「なんか周り見れなくなってんなー」「なんとなく止まりそうな感じがしてきたなー」…これを毎日繰り返すうちに、私は自分が泣いている姿を観覧者の目で眺めることができるようになった。後頭部あたりにもう1人の自分がいて、眺めている様な感覚だ。


もちろん今でも、喧嘩したり、映画を見たりするとどうも観覧者の目になれない日もあるが、それも半年に1回あるかないか程度になった。これによって、まず「涙は出ているけど気持ちコントロールできる」状態を作ることに成功した。



泣き虫を隠さない。泣いても重くないキャラ振る舞う

いずれバレてしまうのだ。隠していたって仕方無い。


泣く姿を見られてしまう前に、「私が泣くのは日常的なことである」「泣いていても頭の中は割と冷静だったりする」「私が涙を流し始めても放っておいて」「もし不快であれば正直に言って」と、できるだけライトな明るい雰囲気で周知徹底させておくと、後々人間関係もそんなにこじれずに済むと分かった。


また、普段から神経質な態度でいると、いざ涙が出た時にどうしても「積もり積もったストレスで爆発してしまった」風に見られるので、日頃からなるべく「おおざっぱなおちゃらけキャラ」で人と接するようにした。少々イジっても誰も罪悪感を持たないくらいの感じで居ておくことで、色々やりやすくなった。


涙は出しっぱなしでも良いが目ヤニ扱いする

例えば仕事中、電話口で客に怒られて涙が出たとする。そういうときに一番やってはいけないのはメソメソすることだ。ありえないくらいその場の空気が壊れるし客は困惑してしまう。


自意識過剰メソメソは隣り合わせの存在だ。自分のことばかり考えて涙を流す時、人は多かれ少なかれ可哀想雰囲気を醸し出す。

周りの人はどう感じるだろう。なんだか自分が悪い事をした様な気になって、モヤモヤした気分になる筈だ。しかし、メソメソ泣いてる人の涙をしっかり咎められる程胆力のある人はそういない。

可哀想な人は最弱故に最強なのだ。だからこそこういうとき絶対メソメソしてはいけない。

一番意識しないといけない対象は客であり、対応であり、要は目の前の仕事である。泣いてることなど本当-----ーにどうでもいい。


涙の存在を頭から消し去る。一番手っ取り早く涙を止められる。もし涙が出続けても、全神経を仕事に集中させる。「涙よ止まれ」と思うことも禁止。ほっといたら勝手に止まるもの心配なんてしなくても良い。

涙は液体なので、顔面を伝ったり視界を曇らせたりして気を散らしてくる。その時は「目ヤニ邪魔だな〜」と思いながら涙を拭う。不思議と涙に意識が向くことはない。


普通に仕事してる+なんかよく分からないけど目ヤニがめっちゃ出る、といった自己認識で動いていると、声色やテンション普段ともあまり変わらない自分がいることに気付く。

周りも普段と一切変わらない態度で接してくれる。


涙のスルー感謝する

残念ながら、どんなに心頭滅却しても私が泣き虫であることには変わりない。私が重い印象にならないよう努力しても、周りの受け流し方次第では、重たくて面倒くさくて関わると厄介な存在にも十分なり得る。


今周りにいる人達は私がすぐ泣くことをスルーしてくれて、たまに泣き虫をイジってくれる。誰も腫れ物に触るような応対をしてこないことが心地良い。

ちょっとしたことですぐ涙を流すのを見て、イラつくことがあるかもしれない。謂れのない罪悪感でモヤモヤするかもしれない。でも、皆それを受け入れてくれている。申し訳なさを感じる。ありがたい。


のんびりした空気の時を選んで、私は「いつもすみませんありがとうございます」と伝える様にしている。その時は泣かない。泣きそうだなぁと思ったらまた別の機会にする。そのくらい徹底している。

仕事で悩みを相談したり、素直な気持ちを話す時、私は絶対泣かないと決めている。冷静に話ができる人だと思われたいから。




工夫さえしていれば泣き虫でいてもいいのだ、と思うようになってから、私は少しずつ泣く回数が減ってきた様に感じる。

しかしたら、オバサンになる頃には私は泣かなくなっているかもしれない。


ただ現状、周りの人達良心に大きく依存していることは確かなので、理解感謝しつつ自分でももっと工夫できることがないか考え、色々試していくのは続けていきたいと思っている。

2016-05-24

AVに望むこと

絶対気持ち良くないとわかるような不安定体位はやめて欲しい。

絶対気持ち良くないとわかるような超早いピストンはやめて欲しい。

絶対気持ち良くないとわかるような超早いフェラや手マンもやめて欲しい。

女優の不自然にでかすぎるあえぎ声はやめて欲しい。

ホストみたいなの、ヤクザみたいなの、オッサンすぎる、不潔、怪物みたいなの、という

 どこから連れてきたのか訝しいほどの気持ち悪い男優使うのはもうやめて欲しい。

 主張が強すぎるスター気取りのマッチョとかもやめて欲しい。

 プレーンな容姿フツメン以上の男優を使って欲しい。

中途半端な芝居はやめて欲しい。ドラマ仕立てならドラマ仕立て、そうじゃないなら無駄学芸会は要らない。




ここに上がった様な要素が好きな人は要ると思う。

その人達趣味をないがしろにするつもりは毛頭無い。

しかしこれらの要素がメジャーもののようにしょっちゅう出てくるのはおかしい。

絶対そんな需要は無い。

作り手が高齢化したり新陳代謝なくて自家中毒したりして

変な決まりごとや定石が改定されずにずーっと来てるように思う。




昨今ポツポツ増えてる女性向けAVの方が男から見てもずっと良い。

あれは努力もしてるんだろうが、そもそも老害AV回の決まりごとから無関係でいられるのが強いのだと思う。

AVも進化して欲しい。

進化できない爺はニッチに進んで欲しい。

メジャーにずっといられるのは迷惑だし社会の損失だ。

2016-05-23

http://anond.hatelabo.jp/20160523204808

自分二次元クズ萌えゲス萌えは、あくま現実とは異なる嗜好として認めてほしいなぁと思ってるけど、

二次元の影響力」がどこまであるのかって、自分価値観だけじゃ断言できないので困っている。

「お前は二次元現実区別が本当についているのか?」て人を、ネットではしょっちゅう見るようになってしまたから、自信なくなってきた。

あと、「女の子バカじゃない」と言っても、女の子バカにしたい連中にとっては格好のネタなんだよね、イケメンだったらDVモラハラクソ野郎でもいいんだろうとか。

2016-05-20

何様やねん

社内恋愛してたのが別れて居辛くなったか会社辞めます

みたいなことが別に会社でもなんでもない友人グループで発生して、

女の子の方は破局後もグループの他の奴らとこれまで通り仲良くやってたけど、

「女が来るなら行かない」とか「女が楽しそうにしてるとツラい」とか言って引きこもって、

たまにその女の子抜きで集まった時は「俺を気遣え、慰めろ、あっ今傷ついた、傷ついたぞー!」っていう態度を出しまくった結果、グループ全体から疎遠になったことについて、

「俺の方がグループ先住だし、女をグループに招き入れたのも俺なんだから、女が出ていくのが普通じゃないの?

 なんであの女まだ俺の友達と遊んでんの?納得いかない。あとグループの奴らは裏切り者。あの女に全部奪われた。」

って言い続けてるヤツがいる、もう何年も前の話なのに……。ソイツそのあと別の彼女できてまた別れたりとかしたのに……。



「女が来るなら行かない」とか言い続けて、遠まわしに自分から二択を迫った結果、自分が選ばれなかったのだという現実を受け止めて欲しい。

あと、そいつ血縁関係があって付き合いがそうそう切れないっていう理由で、

俺もグループの奴らと、繋がりは維持してるものの一時に比べてかなり疎遠になってしまって、迷惑をこうむって結構イラついてることにもそろそろ気付いてほしい。

俺が当時のグループの奴らと交流することについては「別にいいよ」「自由にすればいい」って言う割に、

遊んでるの察知するとTwitterでこれみよがしに落ち込んでみたりして大変面倒なので、俺もグループの奴ら側もお互い変に気を使ってしまうからっていう理由で遊ぶ機会が相当に減ってしまった。



彼が、いくら面倒くさい振る舞いをしても無条件に味方になる友人なんか君の周りにはいないし、自分の振る舞いが周囲には大変面倒くさく感じられてるっていう現実に気付く日はくるんだろうか。

しょっちゅう「もう誰も信じられなくなった」「傷ついて学んだ」って言ってる割に、

「あの女がおかしい」みたいなことを、まだその相手と多少交流があるとわかってる相手に言ってくるあたり、未だに全然わかってなさそうで怖い。

血縁関係さえなかったら10年来の友人の俺もさっさと見捨てたい程度には振る舞いが年々面倒くさくなっていくけど、彼はどこでどう拗らせてしまったんだろうなあ……。





書いてて思ったけど、「俺が先住だから(破局して俺がお前見るとツラいから)お前が出ていけ」はやっぱり違うわ。

未練があって居辛い方が勝手に逃げていってくださいよ。って感じな気がする。そして未練があったのはソイツ側だけだ。

友人グループから会社でその人がいないと仕事が全く回らないから~とかいうような重要なポジションってわけでもないし、

未練からくるツラさを感じてる側が一旦距離を置くのは自然な成り行きだし、その結果疎遠になるのは本人の人徳なり魅力なりが足りなかったってだけの話な気がする。

授乳中の感覚

赤ちゃんおっぱいを飲む時、乳首を吸ったら吸った分だけ母乳が出ているわけではない。

射乳反射というものがある。赤ちゃん乳首を吸うとその刺激でオキシトシンというホルモンが分泌され、その働きによって母乳乳首から排出される現象のことだ。乳首への刺激だけでなく、赤ちゃんの泣き声や匂い想像だけでオキシトシンが分泌されることもあるそうな。赤ちゃんが吸わなくとも、自分乳首を触っていると母乳が出てきてしまうことがある(授乳初期は乳首しょっちゅう詰まるので詰まっている部分を探して押し出す必要がある)。

子供が生まれるまでは眉唾に思っていたが、実際に授乳が始まると「まじホルモン超出てる!ホルモン超働いてる!」という感じであった。なぜなら左胸から授乳していると右胸からポタポタ母乳が垂れ出したかである。(左胸が吸われていても両胸から乳が出る仕様

赤ちゃん最初の数十秒〜数分はチュッチュと乳首を軽く吸っているだけで、射乳が始まるとゴックンゴックンと喉を鳴らして飲みはじめる。赤ちゃんがゴックンゴックンしだすので射乳しているのが分かるし、射乳が始まる時に乳首がツーンとする感覚がある(これはない時もある)。

以上、今だけの感覚なので増田に書き記しておく。

2016-05-19

http://anond.hatelabo.jp/20160519012234

なにいってんだよ。

あんなもん、メインのお客はテレビ視聴者だろ?


開催国でなじみの薄い競技かつ自国選手が出てない試合の観客席が空席だらけなんてのは、

オリンピックしょっちゅうじゃん。

2016-05-18

http://anond.hatelabo.jp/20160518135844

2chとかでも政府の思い通りにはなしが進まなくなるとあらし部隊しょっちゅう来るよな、

ここでは今「スレッド分散」「熊本事件へのすり替え」が使われて「windows10に入ってるスパイウェア」がごまかされようとしてる。

2016-05-17

http://anond.hatelabo.jp/20160516224719

対向車線を逆走しちゃったとかアクセルブレーキ間違えて店に突っ込んだとか

しょっちゅう報道されてるだろ…

2016-05-15

このところ童貞董卓と見誤る

割としょっちゅう

別に三国志ファンでもないのに

フォントが変わったりしてないよな

あれか、スマホで見る機会が増えたからか

2016-05-14

ライター矢作晃」問題について

今日1日を素敵な思いで過ごしたい人は、もっと後になってから読んでください。

土曜日大事な時間、なんでこんな不毛なこと…と思いながら…

時間ほどかけて友達リストをつくりました。

お察しかもしれませんが、この投稿が共有されている人は「矢作晃」とある程度、交流がある方々です。

この投稿は、(余計なお世話かもしれませんが)特に 石野 純也 さんと 星川 哲視 さん、あたりに読んで欲しくて書いています。

【1.どう接するべきか(林案)】

子供を育てたことがある人ならわかると思いますが、ダダをこねる赤ん坊にいい顔をしてしまうと、子供のダダはひどくなるばかりです。おそらく最良の方法は無視する、あるいはちゃんと向き合って接する場合には「気をそらす」だと思います。

心をわずらっている彼が、最近、再び暴れているという知らせを何人かから受けて、彼のツイートやらFacebookの投稿、そこでのコメントのやりとりなどを観察しました(ブロックしているけれど、ブラウザプライベートモードを使うとパブリックな投稿は読めるようです。まあ、そりゃ当然か...)。

自分の不幸のアピールは彼の天賦の才能なので、それを見て「かわいそう」、「何か言ってあげなきゃ」と思う同情心の気持ちはわかります。

でも、彼のことをこれから先、一生面倒をみる覚悟がないなら、そして本当に彼を思いやるなら、そこで突き放すことも大事だと思います。

人間は誰しも「人に認められたい」願望があります。彼は特にそれが強いと思います。

さらに自己肯定力はやたらと強いので、誰かがちょっとでも同調をしてしまうと「やはり、俺は正しいんだ」と、この24時間ほどの爆発を生んでしまうというのが私の見立てです。

同情のコメントがなくても、おそらく愚痴ツイートは続いていたでしょう。

でも、ここまで増長することはなかったと思います。

「それでも彼のことが心配だ。何かしたい」という人はいるでしょう。

そういう人への私のオススメは、他の関連のない話題に彼を誘導することです

赤ちゃんあやし方と一緒です)

彼が好きなアニメマンガが好きで、そこいら辺の話が得意な人は、その話で盛り上がるのもいいでしょう。

(この記事の末尾に参考になりそうなうつ病対策のページのリンクを貼っておきました)

「彼の原稿が好き」と本心で思っているのなら、それを書くことについて、私がとやかく言う権利はありません。

 ただ、彼のことを本当に思うなら、もう少し経ってから、過去形で「好きだった」と書いた方がいいのではないかと思います。

【2.なぜ「過去形」なのか?】

彼が言っている通り、彼のIT関係の執筆の仕事は終わりだと思っています。

ただ、今終わったのではなく、とっくの昔に終わっていたと、私は見ています。

 私は彼とは付き合いが古く、同情心や心配さからMacPeopleに彼の連載を提案していたこともありました。「とりあえずお試しで」と特集記事を振った結果、彼は逃亡し、音信不通になり、結局、連絡こずで、私とその編集者で全部を丸かぶりして死ぬ思いをしたこともあります。

 その後も、何度か彼に仕事を与えようと、面白い製品発表の声かけを彼にも回したり、自分企画した重要イベントに彼を呼んだこともあれば、面白いネタを持っている広報会社の人を紹介したこともそれこそ何度もあります。ムーンライトウェーブの望月さんなどもその一人ですよね。

 望月さんなどは本当に彼によくしてくれていると思います。でも、おそらく、彼が呼ばれたイベントを記事にしたことはほとんどないと思います(と、ここは私もまったく人のことは言えないのですが…苦笑)

 編集者などにつなごうと呼んだパーティーも隅で昔からの知り合いと話をするばかりで(性格的に無理か、と途中から諦めました)。

 ここで聞きたいのですが、そもそも、この中で、誰か彼がここ1〜2年で書いた記事を読んだ人、いらっしゃいますか?

 もしかしたら、よく検索すればインプレスかどこかで見つかるのかもしれませんが、彼の最近のPublicへの露出で私が知っているのは有名な彼のツイッターと、あとは Kohichi Aoki と 松尾 公也さんのPodcastくらいです(他に本当にあるのでしょうか?)

 彼は同情心集めが得意で、昔から付き合いがあるインプレス系の方々のスネをかじり続けているのは知っています。インプレスの方々が、他の若い方々にあげられたはずのチャンスの一部を彼に与え続けていたことも。それによって彼は自分が「まだまだライターとしてやっていける」という誤解を長く持ち続けてきてしまったこともわかっています(が、その担当が誰だかわからないし、おそらく友達になっていないので、この投稿をシェアできずに残念です。ご存知の方、ぜひ、この投稿をコピペしてシェアしてください)。

 しかし、そのインプレスも、昨年、彼が海外で暴力沙汰を起こしてからは彼のことを干している、と人に聞きました(被害に遭われた方は散々でしたね)。

 つまり、彼はもうほとんど仕事をしていないんじゃないかと思っています。

 もしかしたら、週刊アスキーが、獲物のいない猟場、食料のない餌場に、ノラ猫の餌をまいているのかもしれません(が最近、読んでないのでわかりません)。

 実は彼のITジャーナリスト業だか、ライター業はとっくに終わっていたんじゃないでしょうか(彼が認めたくないだけで)。

 そこにまんまとアップルさんが、まるでアップルのせいで廃業したかのように見せたと愚痴る口実を与えてしまったのが今回の事件の全貌だと思います。

 

 インプレスに干されてからなのかは、彼の記事は検索しても出てこないくらいに発見が難しいです。ツイッターでもフォロワーは、そこらの大学生以下くらいですよね。 マスメディアならぬ、ナノメディアに近いのですが、地上波テレビでも取れない席が自分に与えられなかったと言って彼は愚痴ります。

 それくらいに存在感のない記事、読者も求めていない記事、編集者もお情けで仕事を与えて手間が増えただけでもしかしたら迷惑かもしれない記事。

 それでも「かわいそうだから何か仕事を与えなきゃ」という不健全な負の連鎖、いつまでもつづけられるわけがないですよね?

 特に今はどこのメディア不況だと聞きます。

 そもそも、あの見苦しいツイートの主の記事を載せるなんてメディアブランド戦略としてもどうなんでしょう。

彼がこの先も「ITジャーナリズム最先端をつっ走って」まだまだこれからかなり遠い先までどんどん走り続けられると本気で信じている人は、ここにいらっしゃいますか?

 このあと、書きますが、彼は自己肯定力だけは強いので、走らせる距離が長いほど、崖の高いところにまで登っていきます。

 今、ここで彼に同情して、もっと先にいけるよ的な声をかけてもっと高いところから堕ちさせるのは、本当に彼にとって良いことでしょうか?

 だから、無責任に彼に自信を与えるのはやめてほしいと、私は思っています。

 自分人生大事な時間を彼のために割くのは、時間と脳の無駄遣いなので、私は今回の件を本当に最後にしたいです。

【3.自己肯定力

私は、何気に彼との付き合いが古いです。

私がアメリカ学生で、彼がバイトで編集の仕事を始めたあたりから知っています。

その後は、海外の取材先で同じ部屋に泊まることもありました。部屋に戻ると、彼が半裸で鼻をほじりながらずっと2ちゃんねるを見ているおぞましい光景を何度か見てきました。消し去りたい私の心の傷の1つです。

そんな私が見るに彼の最大の特徴は:

異常なくらいまでに「自己肯定力が強い」ことです。

彼は、まるで「ポジティブであることが悪いことであるかのように、人のことを「ポジティブ野郎」などと呼んでいるようです。

ただ、自分のことをポジティブに分析する能力では、私は彼の足下にも及びません(いつも、自分ダメだと思って苦しんでいる側なので)。

彼のツイートを昔から見ていると、彼の周りではやたらと物が壊れるんです。

しょっちゅうフォーマットや再インストールをしている印象です。

あきらかに異常な頻度で物が壊れます。

(彼にとっては)もちろん、壊れるものが悪いわけです。

メーカー愚痴を書き始めます。

自分の記事が読まれないのは読者が悪いし、

他の人の記事が読まれるのも読者が悪い、そんな記事を読む読者は地獄におちろ、みたいなノリで罵ります。

自分の媒体力とか自分の記事がどれだけ求められているか、といった部分に関係なく、イベントに呼ばれないと招待しない人を罵ります

昔からやっているから俺を呼べ、みたいな考え方です

自分以外の考え方は一切、認めません。

私が何を取材するか、どう書くか、どう考えるかまでいちいち批判してきます。

ITジャーナリストたるもの、スペックシートを接続詞でつなげたような、無味無臭な記事でないと客観性が足りなくてダメみたいな古い自分だけの考えを振りかざして、それに従わない人間を批判します。

ちょっとだけ自分の考えを言うと「私は客観的な記事は存在しない」、実は存在していると思っている人ほど実は危ないという考えの持ち主です。

実はどのニュースピックアップするかでも主観は入ってくるし、

「褒め 大さじ 3杯/悪いところを見つけ出して批判/スペック 小さじ2杯/個人的感想 一振り」みたいなレシピ客観性と考えるのも間違いだと思っているし、長年、レビュー記事にはシリアスだったMACPOWERで「そのレビューは本当に正しいのか」という自己批判企画をずっとやろうとしていた私的に言うと

ベンチマークテストですら客観ではないと思っています

作る側は世の中にどんなベンチマークテストがあるかを知っているから、そこに向けて性能などをoptimizeしているのは、日本語入力プログラムだけでないことはみなさんもご存知でしょう

でも、日本では「報道客観的でないと」という考えがあまりにも広く根付いている。

だから、「あえて最初から主観」を強く出すのが私のスタイルです。

この話をすると長くなるので(すでに長いですが)、私は文字によるコミュニケーションを信じていません。

そういう人もいれば、無味無臭な書き方をする人もいる、そういうバランスがあり、どの記事からどの記事へも1クリックでいけるのが現代人のバランス感覚だと思います。

それをITジャーナリズムかくあるべきの同じレシピJIS規格された矢作色の世の中になったら、記事は1本読んだら他は読む必要がなくなってしまいます。

ここでちょっと脱線。

みなさんの中で言葉の仕事をしている人は、自分がこう書けば相手に伝わる、と思っている人もまだいるかもしれませんが、25年、執筆の仕事をしていて強く思うのは、読者は自分の知識の範囲やその時の感情フィルターで、自分で読みものを想像創造しています。

いいことを書いたつもりの記事でも、それを批判と捉える人もいるし、私の記事とか感想の振れ幅がめちゃくちゃ大きくてすごく面白いです(ただポエムとか言ってる中身も読んでいない、バカの壁養老孟司読んでください]の人は別としてちゃんと読んでいる人の感想です)

脱線しちゃいましたが、彼は自己固定が強いあまり

業界で起きている時流の変化にも順応しようとしなければ(変わる時流が間違っている)

自分の記事がどんなに読まれなくても、それは読まない読者が悪いので書き方に工夫をする必要もないのです

ある意味脳内では幸せな人ではあるけれど、脳の中と外とのギャップが、いよいよ、大きくなりすぎて破綻し始めたのが今起きていることです

【4.言われの無い矢作犠牲者たち】

ここで、誰も見ていないツイッターとはいえ、2ちゃんねらーがRTし始めて、私とかに絡む人も出てきて、

それでも相手にしちゃうと、調子にのるから、表では静観を続けている私ですが、あまりにもな言われ放題みたいなので、いくつか自己肯定をさせてください。

というか、神尾さんも被害にあっているので、彼のことから擁護すると

私は神尾さんのこともよく知っているので、ここで断言しますが、

彼は神尾さんがSさんと交際があるような書き方をしていますが、

よく知っている人間として断言しますが、神尾さんが好きな人やら何やらについて深いコメントは避けますが(いや、いいお父さんです wink絵文字

Sさんとの交際だけはないことはよく知っています。

証拠を示せと言われると難しいのですが、

1つは神尾さんは交際相手に関して、好みのタイプがかなりしっかりしていて(というか狭い!)、Sさんは良くも悪くもそこから外れるからです。

2つめは、証拠というよりは、矢作デタラメな主張を崩す内容ですが、彼はジャーナリストを唱いながらもろくな事実確認も無しに神尾さんがアップルスペシャルイベント愛人Sさんのことらしい)を連れてきたと書いていますが、実はこれ、神尾さんにとっても私にとってもとSさんは初対面でした。

音楽の男女デュオが実は別々に結婚相手がいても「実はつきあっているんじゃないか」と噂が立つのと同じで、交際とかの経験が少ない人ってやたらとそういうの勘ぐって噂たてたがりますよね。

まさにソレです。

神尾さんがSさんが近しいのは、今、神尾さんがやっている未発表の?プロジェクト関係あります。

彼は、いつも「IT業界の中にいる人」や「ガジェット好きな人」からは真実は見えてこない、とスマートフォンサービスもっと一般の人目線で評価させることの重要性を主張していました。

で、若い女の子とつきあわないまでも、おしゃべりするのは好きなので、よく女子高生女子大生ヒアリングをして探るのが神尾さんのスタイルです(もともと、ドコモの時からそういう仕事をしていましたみたいで、奥様との出会いも...)

実は幅広い年齢層の女性にヒアリングをしていますが、Sさんもそうしたサンプルの中だったのが、色々、話をするうちに本気でライターになりたいという思いを知ったみたく、面倒見よく、いろいろな人に紹介しては、「あの人からは〜〜を学べ」と教育しているようです。私もSさんデザインについての講義を請われました。

ウェアラブルを筆頭に、今やデジタル製品はどんどん生活領域に入ってきているのに、ファッション誌ではデジタルに詳しい人がまだ少ない。

そんな中、生活者目線で記事がかけるライターを増やす必要がある、というのは神尾さんの強い信念で、近々、発表あると思いますが(って書いちゃっていいのかな?)実は神尾さんは最近、そっち方面での活動に本腰を入れています。

 Sさんは、ある意味、その活動の実験台というか第1弾。

 一緒に仕事しているし、(うらやましいことに仕事を振っているので)一緒にいる時間も長いかもしれないけれど、彼とSさんの噂がたつのをみていると

「ん〜、(彼のツボは)そこじゃない」(笑)と心の中でツッコミを入れたくなってしまいます。

 まあ、仮に神尾さんは打たれ強いし、いいとしたとしましょう。

 それにしても本当に根も葉も無いのに、変な噂を立てられて、好奇の目でみられているSさんの立場はどうなるのでしょう?

 彼は精神を病んでいるから、ここは狂犬に噛まれたと思って我慢しろ、というのでしょうか?

 九州にいて、なんとかライター業でやっていきたいと思っていた彼女のやる気を見て、神尾さんがライターの顔ぶれの若返り(平均年齢下げることも考えて)東京仕事できる環境作って、呼び寄せたところで、わめけばいいと思っている見苦しい老害(病害)のために若い才能の1人を犠牲にするのは本当に正しいことでしょうか?

神尾さんが元ドコモコンサル仕事をして、という批判もしているようですが、だからこそ、矢作なんかには書けない、会社の裏事情などの視点が書けるのだと思うし、それを是とするか非とするかは読者次第だと思います。

 もしかしたら、NDAなどがないものは、disclosureとして記事で関係性を明らかにしたら良いかもしれません。

 私もコンサルをしている、ということで彼の批判を受けていますが、一時期、そうでないことがあったのは私の失敗でした(1年半くらい)。でも、そこでも自分なりに中で線引きはしてきたつもりです。

 また、それ以後は、実はコンサルティング契約を結ぶときに、コンサルティングをすることになったからには、ソーシャルメディアでは応援するけれど、マスメディアなどでの記事ではとりあげない、ということを約束していますし、そもそも自分が記事を頼まれる業界とは別の業界コンサルティングが多いです。

 どうしても、コンサルティング先のことを記事で書く必要が生じたときは、去年のfashionsnapの記事や毎日新聞日経産業がそうでしたがdisclosureとして、株を持っているかいないか関係なく、関係性に関する注意文を示してきました。ここら辺はもしかしたらメディア側でガイドラインを作ってくれた方が良いかもしれませんね。別に神尾さんもそこは否定しないと思います。

ちなみに書いている記事が製品のレビューなどが中心だと、少ないかもしれませんが、トレンドの分析などを記事にする人は、その洞察に価値を感じた相手から講演などの依頼を受けるのは、かなり自然で海外でもよくあることだと思います。私自身は書きたいが、心底のモチベーションではなく「世の中を変えたい」がモチベーションなので、企業の中に入って現状をよくするために手を動かす機会の方が圧倒的に増えています。全部明かせないのが残念ですが、一部は今月26日に発表になります。

【5.私の自己肯定

つづいて私の方の自己肯定

彼は自分が正しいと信じていないとやっていけない人間です。

なので、ツイッター喧嘩でも、やたらと関係のない人にいきなりメンションを送って巻き込んで、その人たちが自分の味方であるかのように見せる演出をします。

私は彼にとっての仮想敵なので、批判される側だけれど、彼がそうやって私の周囲の人間にメンションし始めるのは正直迷惑でした。

ある日、携帯おサイフ系の発表会の実況をしていた時に、たまたま彼の病気が強めに出ていた(私がソフトバンクワールドで講演したことへのジェラシーかもしれません)のだと思いますが、こちらはツイッター実況で言葉もらさないように忙しいのに、彼がやたらとつっかかってきて「お財布いらない?レシートはどうする?」とか言ってきたので、そこで喧嘩になりました。

(ちなみにレシートは、皆さんがアップルストアで日々そうしているようにメールで送ってもらえばいい話ですよね?そういうところ、相手を批判するためなら事実を都合よく忘れるところが多いのも彼の特徴です)

今と同じようにツイッターで暴れ出して、そこを周りの人がなだめて、ほめて、彼が「やった見てくれている人がいる、これは甘えなきゃ」と「自殺してやる」と叫びだして(本当に絶望した人は、言わずにひっそりやっていると思います。彼は構って欲しいだけなんです。かまう方法によってプラスなこともあるけれど、同じ壺の中でいくら上に持ち上げても落ちる距離が長くなるだけ、別の壺に移し替えて気分転換されることが大事)、警察に保護されて、その後は親が迎えに来ておさまったようです。

 そこで、私も「もう付き合ってられないや」と思い。

でも、彼のフォローをやめて、そのことに彼が気がついたら大騒ぎするだろうと、わざわざ彼の行動をツイッターでチェックして、彼が海外に行っていてメールとかも増えて気がつかないだろうというタイミングを見計らって(嫌いな奴のために、俺、なんでこんなに気を使ってやっているんだろう。と自分を責めながら)TwitterFacebookInstagramなどすべてのソーシャルネットワークで彼をブロックしました。

 自分を不快にするものが視界に入らない方が、彼も健全に生きられるだろうという配慮だったのですが、私も誰かをブロックするのは初めての経験でわからなかったのですが、私が彼をブロックしていても、彼がフォローしている誰かが私のツイートをRTすると彼に見えてしまうようです。

 もちろん、自己肯定感が強い彼は、私のツイートがRTされてくると、その人をアンフォローして自分の方から改善の道を選ぶのではなく、RTする人たちを「そんなのRTするな」と批判し始めます。

 私がティム・クックに遭遇したのが、やらせとか言っているようですが、実はそうではないと証明できるつづきの写真がいくつかあります(あれは実はWWDCの一般開発者ランチ場所で撮影しました。私が話していたら、すぐに開発者たちがよってきて、大騒ぎになったのでその写真があります)。

 彼が書いている批判の多くは、彼が勝手思い込みで書いているだけの事実無根が多く、証拠がそろっているものもいくつかありますが、相手にするのもバカバカしいので、無視しているだけ。

 良識のあるみなさんの中にもつきあい長い人多いので、真に受けていない人多いだろうけれど、つきあい新しい方は要注意です。

 そんな中、今回、彼が(これまでなんで招待されていたのか不明だけれど、記事は書いていたんだろうか?)今年、地上波テレビでも取れない取材枠を得られなかったことで、「世界一詳しい俺が呼ばれない」と大騒ぎしたようですが、実際のところは既に終わっていた自分仕事の失敗をアップルになすりつけるためだけの見苦しい行為。

 まあ、それも病気ゆえ(実際に通院して薬で治療しているようです)なのでしょうが、病気だからといって周りがどこまで好き勝手に批判されるのを耐えなければならないのか、非常に強く疑問に思ったのが今回の事件であり、無責任な同情コメントが彼を増長させているという事実を知ってもらい、そういうことを同意していただけるならやめて欲しいと思って、この長い記事を書きました。

私は、最近はかなりちゃんとした方々とのお付き合いが多いので、

IT/モバイル業界のあまりにも見苦しい醜態話、およそFacebookパブリックには投稿できませんでしたが、隠す内容ではないのでコピペしてアングラ掲示板で広めてもらったりする分には構いません(というか私は読まないので、感知しようがない)。

また、彼に親しいインプレスの編集の方や、あまり存じ上げないのですが、 山口 健太さん 中山 智さん といった彼と親しい面々は私自身があまりお付き合いがないので、タグ付けしてみたけれど、この投稿がシェアできていない可能性があるので、どなたかが回してもらえればと思います(もっとも近しい方なら、彼がどういう精神状態で、どう対処したら良いかもよくご存知かもしれませんね)。

 近しい方々は、どこかでは彼の問題や、接し方も詳しいと思うので、その辺りの情報共有やアソバイスもいただければ嬉しいです。

 また、 narumiさんは、週刊誌的なノリでこの話題をとりあげないか心配で、あえてシェア対象から外しています。

正直、時期がきたら本人にも読んでもらいたいですが、今はまだ暴れだしたら困るのでやめておきましょう。

なお、矢作さんと、それでもお付き合いを続ける方のために、いくつかどう接したらいいかの参考になりそうなサイトを見つけてきたので、以下にまとめておきます(自己肯定力ネガティブな影響については一番最初の記事が詳しいです):

http://www.utsubyou.co/entry/2015/10/20/#more3

http://oshiete.goo.ne.jp/qa/2130663.html

http://mojostyle.net/sigoto-16/

tag: 海老原 昭、 法林 岳之

この記事は、私がつくった「IT系」(何人追加したのかの確認する方法がわかりません)というリストの人にシェアしています。Facebookでつながっていないのでリストに入れられなかった人は、タグ付けしてみました。ウォールに表示されてしまった人は、投稿右上のメニューから「タイムラインに表示しない」を選べばタイムラインへの表示を消せます。もし、タグ付けされている人も読めるようならシェアされていない人は、あとでタグ付けします。

自分は普段、こういう押し付けはしないほうだと思いますが、この投稿が見れている人たちにとって「矢作問題」はそろそろ一段落をつける頃だろうと思い、あえて押し付けてしましました。

土曜日の大切なひとときにスミマセン。

2016-05-12

なんだか切なくなった高校生時代壁ドンの思い出

一週間ほど前、ほんとに偶然にその同級生に再会した。

たまたま、ある資格試験の条件にその高校卒業証明書必要だったのでざっと約二十年ぶりにくらいに寄ったんだ。

場所こそ一緒だが在学時とは建物自体が建て変わっていて、当時とは随分違う雰囲気だった。

同窓会すら一度も呼ばれた事もやっている事自体も知らないし、ほんとに親しかった友人くらいとしか卒業してからは会ってない。

大して思い出にふけるほどの記憶もなかったが、せっかく立ち寄ったのだから航行の周囲をぶらぶら散策してみる事にした。

ちょうど高校の裏に当たる小さな公園は当時のままだった。

真面目に部活動なんかやった事もなく、一応は軽音楽同好会に属してはいものの、文化祭やその他の催し物がある際にその練習の為に適当に顔を出す程度で、実態ほとんど帰宅部みたいなもんで、親しい友達とその公園適当にだべったりして無駄時間を過ごしてた。

流石にその公園をぶらついていると懐かしさもこみ上げてきて、このベンチでよく屯してたよなぁ、などと思い出に浸っているその時。

 

もしかして増田君?」

 

声のする方を振り向くと、公園入り口に同年代くらいの主婦らしい感じの人が立っていた。

主婦らしいって言うのはいわゆるママチャリを両手で支えていたからだが、後で聞くと3年ほど前に離婚して母子家庭になっているのだという。

 

「え?、ああそうですけど?」

 

何かどっかで見た記憶のある顔つきだったけど、すぐには思い出せなかった。

 

「やっぱり!、久しぶりだねー、どうしたの?こんなところで」

 

まだ思い出せない。

 

「いえ、ちょっと高校に用があって・・・あの、すみませんけど」

 

そこまで言うと彼女は、こちらが思い出せないことを見透かしたようにちょっと意地悪そうな感じでニヤついて言った。

 

「やだ、あたしの事覚えてないの? 私、増田君の後姿ですぐ分かったのに」

と言いながら、ママチャリ公園の脇に立てかけて、その肩まで伸びた髪の毛を両手で後ろにくいっと上げた。

 

「あ!、思い出した!」

あははー、だよね、あの頃はずっとショートカットだったから今とはイメージ違うもんね」

 

はっきり言って「思い出した」と言ったのはとっさの嘘で、髪まで上げられて思い出せないなんてちょっと恥ずかしいと思ったからだ。

それが同級生のK子だと名前まで思い出したのは、その公園のベンチに二人で座って昔話や世間話をし始めて五分くらい経ってからだ。

それで、久しぶりだから当時の同級生たちと同窓会なんて出来たらなぁ、とか話している最中に俺はある出来事を思い出したんだよね。

 

「そう言えばさ、確か図書室かどっかでK子のこと、泣かした事なかったっけ?」

 

うっすらとした記憶だけど、とにかく不意に思い出したんだ。

俺がそう尋ねると、K子が、もうビックリして目を見開いたとしか言いようのない表情になったので、こっちもビックリした。

 

「え?・・ってちょっとやだ!な、何思い出してんのよ!」

 

明かに狼狽してた。

「いやさ、なんかそんなことあったような気がしてさ。ごめん、思い出したくなかった?」

・・・思い出したくないとか、ていうか忘れたことないよ、あの時の事・・・

  

そういうとK子は少し赤くなりかけてきた空を見上げて黙りこくった。ちょっとの間だけど、俺も返答に困ってなんか変な沈黙時間になってしまった。

 

ただ、その沈黙の間に少しずつ当時のことを思い出してきたんだ。

「そうそう、その時さ、俺、K子がなんで泣いてんのか全然分かんなかったんだよね。で困っちゃってさ、確か、変な感じで慰めたりしてたよな」

 

と俺が愛想笑いしながら言うと、K子はちょっと俺を睨み付けた。

 

増田君って、当時は確実に童貞だったよね。ていうか彼女だって作ったこともなかったでしょ? あそこでキスしないなんて無茶苦茶傷付いたよ(笑)

「キ、キス?」

だってさ、あそこで壁ドンまでしてキスしないとか普通あり得ない」

 

・・・そこまで言われて俺は完全に思い出してしまった。

それは高三の時の放課後の事だった。

K子は隣のクラスだったけど、高二くらいから仲のいい友達同士になっていて、他の同級生友達などと一緒に良く遊んだりしていた。

で、文化祭の調べものか何かでお互いに図書館を利用する事があり、しょっちゅう一緒になってたんだよね。

ていうか不思議なくらい、二人きりで居残る事が多かった。もちろん帰る時も一緒。

あと、付き合っていると言う事はなかったけども、2回ほど遊園地とかでデートしたりもしていた。

正直言えば、俺は彼女の事が好きだった。でも、彼女の言うとおり付き合ったことなんか一度もない完全童貞だったし、彼女はどちらかと言えばもてるタイプ女の子で、何人かの男子と付き合っていたことも知っていた。

から多分、当時の俺としては、彼女と付き合えるとか夢物語に等しかったんだな、きっと。

 

それで、その日も図書館で二人っきり居残っていたんだけど、ほんとにどうでもいいことで軽い口論になったんだ。

鉛筆貸してと言われて、単に貸さなかっただけ、っていうね。

それでK子が怒って泣き出し図書館を飛び出ていったのを俺が追いかけた。

そして追いついたそこで、彼女壁ドンしたと。

 

「懐かしいよねー。でもあそこでキスされてたら、もしかしたら結婚まで行ってたかもよ(笑)

「そ、そうなの?マジで?」

だってさ、増田君の事好きだったもん。増田君すっごくやさしかたから」

ちょ、ちょっと待て。え?

「それ、マジで言ってんのか?」

「うん、マジな話。増田君が私のこと好きだって事も知ってたよ。聞いてたもん、増田君の友達のA男から

「げ!、あいつめ、余計な事を・・・

A男は当時俺の唯一の親友だった。あんなに口の堅かったと・・・いや、実際には軽かったのか。

 

「えー。だったら相思相愛だったんじゃねぇかよ」

「ほんとだね」

 

彼女はくすくす笑いながら言った。

 

「結局その絶好のタイミング逃しちゃったし、なんかあの後お互い忙しくなっちゃったしね。人生って分からないものよね」

「で、でもさ、告白もなしにキスなんか出来ないって」

・・・あはは増田君てばまだ童貞なの?(笑)

 

なわけねーだろ。子供も二人いるって。

でも、確かに、思い出せばあんな絶好のタイミングキスに持っていかないとか、アホだったのだ俺は。

・・・くそしか彼女が俺を好きだったとか知らんし。

 

そのあと、連絡先を交換して、俺も仕事の途中で寄っただけだから帰社しないといけなかったし、彼女彼女用事があるとかで別れたんだけどね。

ふと、帰り際に高校のほうを眺めたんだけど、その当時の図書館壁ドンした廊下も校舎ごと消え去って跡形もなかった。

 

そういや、確か・・・お互い卒業して半年くらい経った時、彼女から電話があったなぁ。

何話したか覚えてないが、一回だけ、そんな事があった。

多分、それでも俺は鈍感で気付かなかったんだろうな、K子の好意を。

 

俺が彼女童貞喪失したのはそれから7年も経ってからだ。

なんだか無性に切なくなってしまった。

アホな高校生活送ってたんだなぁと。

最悪なことに、俺、K子のこと想像してオナってたりしてたもんな。

サイテーだ。

2016-05-06

ごはん系の漫画って基本エロ本じゃん

ひとがおいしくごはん食ってる描写を読んで楽しいなんてそれエロ本じゃん。

ひとがセックスして気持ちよくなってる描写読んで楽しくなってんのと同じじゃん。

美味しんぼとかバンビーノとか酒のほそ道とか、飯漫画はいっぱい持ってる。呑みながらツマミ感覚しょっちゅう読む。

完全にオナニーしかない。

「食べてはないけどごちそうを食べてる人を見ながら満足感を得る」

「ヤってはないけどヤってるひとをみながら満たす」

ニアだ。

飯食い系の漫画多いのわかる。

Slack仕事生産性を下げている

Slack にかぎらず、チャットツール全般に言える話だけど。

 

チャットの会話で伝えられる情報量は対面で話したときのそれより圧倒的に低いので

対面で話したら 3 分で済む話を Slack20 分だらだらするとか、

そういうことないですか?

 

私はしょっちゅうあって悩まされてます

そういう意味では Slack って仕事生産性をむしろ下げてると思うんだけど。。。

歌舞伎座で見る日本の闇

歌舞伎無形文化財指定され、歌舞伎座の1番良い席は2万弱もする。(舞台の完成度としては、2万弱を払ってもいいくらいの価値はある)昔は、庶民の娯楽であったが、今や日本が誇る伝統芸能。娯楽ではなく芸術である

しかし、観客に芸術を観るマナーが備わっていない。「オホホ」と高らかに笑うような高貴な人であれとは言っていない。普通でいて欲しい。しかし、高齢者にはそれが通じないということが歌舞伎を観に行くと身に染みてわかるようになる。

演劇音楽舞踊…と様々なジャンル舞台を観てきたが、歌舞伎断トツで最悪である。それは高齢者が多いから。居眠りはしょっちゅう見かける。しかし、居眠りくらいはどうでもいい。ビニールのガサガサ音からまり、隣の人とのお喋り、携帯を鳴らす、携帯ディスプレイ確認挙句の果てには上演中の写真撮影マナーという以前に犯罪であるサルでもわかる

もちろん、熱心なファンマナーの良い方ばかりであるが、特に関心もなく来て(友人の誘いなのかバスツアーだかなんだか知らんが)場を荒らすような老婆たちがどうしても目立つ。一切物音を立てるなということではない。しかもこのご時世、学生のほうが明らかにマナーが良い。「最近の若者は」というあの定型句はもう使えない。

結果、こんな老害のために私は今日税金を払うのかとやるせなくなる。歌舞伎座は華やかな世界である一方、日本の闇を見る事ができる場所。この世の終わりが近い。

2016-05-05

百合好きの男嫌いについてもっと言語化されてほしい

 レズビアンがみんなミサンドリーだとか、百合好きがみんなミサンドリーだというのはナンセンスだが、「これはどうにも男嫌いがにじんででるだろう」という百合作品を頻繁に描く人はいるし、男嫌いが強い百合読者も男にも女にもいる。

 具体例を出せば、漫画で言えば大北紘子の『裸足のキメラ』や竹宮ジン『ラブフリッカー』などには男性社会、更には男性のものへの怒りが感じられるし、読者で言えば俺自身などである

 異性愛者男(シスヘテロ男性)のことを主人公を抑圧或いは簒奪してくる仮想敵として描き、それらへの怒りや抵抗をカタルシスとする物語百合物の定番であり、ハリウッド映画ロシアが悪役になるのと同じくらいしょっちゅう見かける。(ハリウッド映画ロシア悪役が多少減ったように、最近は男への怒りが強い作品が減ってきているとも思うが)

 また、読者が自分男性嫌悪から百合を好み、また男性性への怒りがにじむ百合作品に触れることで男性嫌悪が強まる、という例もある。

 男性性の野蛮さ、暴力性、硬さや大きさやなんやかやへの憎悪

 それはそれで自由なのだが、男を嫌っても社会生活上男と関わらねばならなかったり、自分自身が男なので男から逃げられないタイプ人間が、うまいこと男性嫌悪を処理できず苦しむルートもあって、これはかわいそうである。俺も悩んでるので俺かわいそう。

 まあミサンドリスト全体に共通する悩みではあるんだろうけど、中でも百合好きという共通項をもって語ってもらえたりすると、俺が共感やすくて嬉しいのでもっと語られてほしい。

 その語り手が女性だと「クソミサンドリスト」みたく叩かれるし、男性だと「他の男を排除して自分けが女を味わいたいというただの処女厨の延長だから聞くに値しない」と叩かれたりするのでやりづらいけど、負けずにがんばって発信してきましょうや。



※追記

『裸足のキメラ』『ラブフリッカー』は、男への憎さが出ていてもなお(または出ているからこそ)、よい百合漫画だと感じたか名前をあげたので誤解されませんよう。

2016-05-04

http://anond.hatelabo.jp/20160504224519

とりあえずID教え合ってそっからいっさい連絡取らないなんてことしょっちゅうだけどね

男女問わずそんな感じ

2016-05-03

ポータブルCD復活賛成派だけど、どうせならCD自体が滅んだ方がいい

http://anond.hatelabo.jp/20160502205737

いまだにCD買ってる人間から言わせてもらえば、CDをどうにかして手軽に聴けるようにするための機械ってのはあってもいいかなって感じがする。

でも、CD買ってるのってCDが好きだからってわけじゃなくて、CDを買うことで得られるメリットが大きいから仕方なく買ってるわけで。

パッケージとして売られてるのがCDから買ってる。ビデオテープレーザーディスクDVDBDっていう変化でも別にメディア自体に対する愛着はない。

でもせっかくモノとしてあるのだからCDが少しでも活躍する機会が増えるのなら大いに結構

ただ、そんなんよりCDというメディアが無くなってしまった方がいっそいいのかもと思うことがしょっちゅう


CD買うことのメリットってなんなの?って話だが。

一言でいえば全部「所有欲」ってやつに含まれものばかりだ。

まず、アートワーク目的ってのが大きい。ジャケットとかブックレットとかのね。最近じゃ他にも特典いろいろ付けてくるけど。

これはいわゆる「モノ」なので、データだと手に入らない。

もう音楽自体データ販売にしてブックレットとかは欲しい人向けに別売すりゃいいじゃん、映画みたいに。

……と考えたことはある。自分にとってブックレット価値結構かい

モノとしての価値もそうだけど、DL販売だと欠けてる部分だし。

DL販売だと歌詞とかスタッフクレジットとかが簡単に見れないのって何か不親切だよね。それくらい簡単に見れるようにしてよって思う。

歌詞ネット見りゃすぐ出てくるけど、これは誰が演奏してるとかどこでレコーディングされたとか、そういう情報ブックレット見ないとわからん

からCDより高音質だけどブックレット無いハイレゾと、それなりの高音質でブックレットついてるCDだったらCDを選ぶ。

あとアートワークとしての価値でいえば、CDプラスチックケースははっきり言ってクソだから改善してほしい。

すぐ傷つくし、割れるし、すげぇ扱いづらい。

デジパックとか紙ジャケの方がいいな。


結局は、別に音楽が入ってる媒体はなんでもいい。

これがレコードになったとしても、カードになったとしても、やっぱり買い続ける。

そこにアートワークがある限りはね。

PLAYBUTTONっていうメモリーテックが作ってるメディアがあるんだけど、こういうのでもいいんだ。

http://playbutton-japan.com/

缶バッジくらいのサイズ音源が入ってて、イヤホン挿すだけですぐ聴ける。音質もそれなり。

小さくて、それでいてデザインとして優れている。

最近アニメ系でもグッズとして出始めてて、コレクションとして需要がそこそこある。

ただこれ、データが取り出せないのは欠点だな。これのバッテリーが死んだら終わりだ。


多くの人にとってCDってデータを取り出したあとは置物になってしまうのだから最初から置物になるのを想定したメディアづくりをした方が良い。

任天堂amiiboなんて良いアイディアだと思う。

あいフィギュアデータ入れて販売すればいいのに。

2016-04-29

嫁の奇行(?)なんだが、並べてみると記憶に関するパラメータ特にバグってるというかピーキーというか

客先のトイレ事情は勤務状況の満足度を左右する指標のうち大きなものの一つだが

トイレデフォでくさい、かつ、しょっちゅう列を作っている、という現場があった

思えばアレだった

混んでいる時に同じ会社の別フロアトイレを使うということはよくあるのだけど

どうしたわけか1つ下のフロアはすごく臭いうんこの後に遭遇する確率が高かった

そういや営業部署のフロアだし肉食べたあとのうんこなのかも、などと思っていた

そんな客先トイレの思い出

トイレの快適さってマジで大事

くさい会議室

空気の流れが悪い会議室男性大勢会議した後の残香

そういうのにたまに当たって鼻がもげそうになる

なにあれなんなの加齢臭

それの発展形で、空気の流れが悪い会議室サーバールームにしてた現場があって

24時間運用業務男性が詰めてたりするわけですよ

しか機密情報エリアということで外部業者掃除が入らない

その部屋はしょっちゅうもんわりとしたくさいにおいになってた

増田話題で思い出したけど、いやーひどかった

空調って大事

2016-04-28

小池一夫かいうツイカスジジイ

小池一夫かいジジイツイートがうざい。

当たり前のことをさも「ワイが初めて言ったったで~」って感じで呟く。

しかしょっちゅうパクツイはするは自分に直接害が及ばないように家人責任押し付ける。

「簡単にはブロックしないよ」と言いつつパクツイ指摘したり話が本当か質問しただけで速攻ブロックする。

そんなしょうもない自尊心の塊のクソジジイ信仰するバカどもにも呆れる。

思考停止してジジイ発言の繰り返しみたいなリプするし内容も薄っぺらい。

あいう「自分らが正義」みたいに考え他者の考えを排他的に考えるやつらこそ害悪だ。

2016-04-27

スマホを買った

ガラケーからの移行、Android

いろいろ操作してたら携帯の連絡先とGMailの連絡先がリンクする設定に

なんかもう非常にウザい

いろんなアカウントが芋づる式に繋がる恐怖

めんどくさいので会社の知人、昔の知り合いなんかは連絡先からスッパリ削除した

変に繋がっても困る

ラインしょっちゅう無駄雑談電話をしてくる知人がいるので最初から使わない

こんな使い方をしてスマホ意味あるのかと自問自答中

とりあえずスマホネットのできるゲーム機としての能力を発揮中

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (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 のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

  • 必要以上のアクセス権をサードパーティに与えることになる。
  • 認証情報を格納する場所が増えるということは、盗まれる危険が増える。
  • パスワード等を変更したときに API 利用者側でも更新が必要になる。
  • ひとつアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
  • 特別な認証要素を使っていると、制限が多すぎる。

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の 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 がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、Permalink | トラックバック(3) | 12:44

2016-04-24

富士通やめたあと増田で書く人が多い理由

富士通って辞めた後に会社のこと平気でペラペラ喋る人ばかり雇ってたの?

元増田も言ってたけど管理職の人以外は悪い人なんか誰もいなくて、すごく優しい世界だったからやめるまでは不満はあるけどいいところもたくさんあって、人間関係壊したくないから誰にも吐き出せなかったんだよね。

自分自身退職して他の仕事につくまで、会社なんてこんなもんかなっておもってたところもあるし。悪いところはないはずなのにすごくしんどかったんというのは後から気づいたんだ。 優しいけど非効率で息が詰まるような世界って感覚が通じるかどうかわからんけど。

から、やめた後に、俺はなにげにあの空気が嫌いだったんだって気づいた時についしゃべりたく成る。あとは、とにかく富士通やめると周りからなんでやめたんバカなんってしょっちゅう言われるからそのモヤモヤというか自己弁護みたいなのを吐き出したく成るというのもある。