「テクニック」を含む日記 RSS

はてなキーワード: テクニックとは

2016-05-27

http://anond.hatelabo.jp/20160527165817

仁男 なら じんおとこ と入れて変換するだろうし、

他のよしおも独自の変換テクニックマスターしているだろう。

世の「よしお」の皆さんは、そんなに苦労していない。

2016-05-25

いいひと戦略

いいひと戦略って、人を貶めるためのテクニックひとつではないか

○○さんってすごい、○○さんのこれいいですね、といったふうにまずは褒めて持ち上げる。

そして、それを周りにも「○○さんはすごい」を吹聴して広めておく。これで下準備が完了

あとはつかず離れずで愛想良くしておく。

そして、もし○○さんがミスをしたら、その時が絶好のチャンスで、

「あの○○さんがそんなことやるなんてショックだ」

「○○さんはそんな人じゃないと思ったのに」

「どうして○○さんがあんなことを」

ミスしたこと針小棒大に話しつつ、標的の名前を強調していく。

言っていることは擁護している・かばっているようにも聞こえるが、

○○はできない奴だというレッテルを貼ることができる。

特に上司とサシで飲みに時に使うと効果的なテクニックで、

標的の評価を落としつつ、自分自身は周囲に目配り・気配りができる人間として相対的

自分評価を上げることができる可能性が高い。

大企業の“競争”ではこういった手段を使う人間がいる。

2016-05-23

最近ゲームって、オンラインで色々追加とか出来るから楽しみが広がったかも知れないけど、バグ技の類とか、意図せず成立したテクニックとかそういうのもどんどん「修正」で無くなっていくって考えるとなんか寂しい気もする。

2016-05-19

勉強が苦手な人のたった1つの共通点

今まで多くの人間を教えてきた中で、勉強ができる人間とできない人間の間に発見した共通点が一つある。

勉強ができるできないというよりは、その物事習得できるかできないか境界線といったほうがいいかもしれない。



結論から書くと、それは「知る」ということを怠ることだ。



知らないなら勉強ができないのだから当然だと考えるかもしれない。

では聞こう。

あなた習得しようとして諦めた分野に対し、あなたはどれほどのことを知っているだろうか。」



例えば英語はどうだろう。

あなたはどれだけの英単語を知っているといえるだろうか。

ここにprepareという単語がある。

あなたはこの単語を知っているだろうか。

ここで大切なことは、意味がわかるとか発音がわかるとかということではない。

重要なことは知っているかどうかということなのだ。

逆に、発音だけ知っているのでもいい。



ではエクセルの使い方ならばどうだろう。

あなたはどれだけの関数エクセル機能を知っているだろうか。

それを知ろうとせず、自分のやりたいことばかりを解決したりしていないだろうか。



今まで見てきた勉強が得意な人間は、何かを習得しようとした時に、とにかくまず知ることに徹するのだ。

逆を返せば、知りもしようとせず突然答えを求めてくるのは、勉強が苦手な人間だといっていいだろう。



習得には段階がある。

それは、「知る→わかる→できる」という段階だ。

しかし、勉強が苦手な人間は突然”できる”に達しようとばかりしてくる。

からいつまでたってもできないし、できても忘れてしまうのだ。

例えばエクセルの数式一つを覚えたとしても、全体の関数を知らないから応用が聞かないし、エクセルに対する理解は一向に進んでいかない。

なぜなら、それはエクセル理解しようとしたのではなく、その数式を覚えただけに過ぎないからだ。



ここで英語勉強に戻るが、もし本当に英語というもの習得したいと思った時、あなたはどれだけ英語全体像を知ろうとしていただろうか。

どれほどの単語文法があって、会話にどの程度現れて、どんな場面で使われているか

まずはそれを知ろうとせずして、英語勉強としようとしたところで、それはただ、その会話や状況のやり取りを記憶したにすぎないのだ。

よく数週間から数ヶ月程度で英語習得できるなどとする教材があるが、英語全体像を考えればその期間では”知る”に達することすら不可能であることは明白である

まりこれは、英語全体像を知らない、もしくは習得のために全体像を掴む必要が有ることを知らない人間を騙すための常套テクニックといっていいのだ。

それはそうだろう。

習得できないのをやり方のせいにして、やり方さえ変えればできると騙そうとしているのだから



さて、これを読んでもう一度英語習得チャレンジしたいという人がいるならぜひはじめて欲しいことがある。

それは、わからなくてもいいからまず1ヶ月間、とにかくヒアリングだけを徹底的に行うということだ。

例えば10分~20分程度の文章を、できれば日常会話のように話題が展開していくものがいい。

それが終わったらはじめてその英文和訳を目にしてもらいたい。

すでに音として知っているもに対する理解は、知らなかった時に学ぼうとした時とは雲泥の差だということに気がつくはずだ。

そのちがいを実感できたなら、一つ一つのステップを確実に習得しようとするのではなく、とにかくわからなくてもいいから教材を何周も何周も回ってみることをしてもらいたい。

そうすれば、これから学んでいこうとする全体像をつかむことができるし、一つの内容に対して、まるで網の目のように理解がつながっていくことが実感できるはずだ。



何を胡散臭い話をと思うかもしれない。

ではここで、例えば子供言葉を覚えていくプロセスを考えてみて欲しい。

子供の周りには大人同士やテレビの中からなど、常に色々な会話が絶えないはずだ。

子供ははじめ、それを意味もわからずに耳にしているのだ。

そうして、そこに言葉があることを知り、どんな言葉が使われているのかを知る。

次は自分で使ってみようとするはずだ。

その時はじめて意味を考え、時に人に尋ね、時に自分で使ってみて正しいかどうかを確かめる。

そうして繰り返すうちにその言葉自分のものとなり、その時はじめて習得したといえるのだ。

まりこれが、習得のための自然プロセスなのだ



これはどの分野でも同じである

例えば仕事を身に着けたい時、その仕事にはどんな内容があるのかまずは一通り知ろうとすることが大切だ。

だれがどんな仕事をしているのか、それぞれの意味とは何かを考えればいいのだ。

そうすればいざ自分がその仕事習得しようとした時、その結果に何を生み出せばいいのかも見えてくるはずだ。



人の性能はそれほど違いがあるものではない。

どんなに優れた人間でも、”知る”というプロセスを経ずして突然物事習得できるはずはないのだ。

ときたま現れる突然習得できる人間は、何の事はない。過去に同様の分野を経験していて、それに置き換えているだけにすぎないのだ。

それならば、問題があるとすればそのやり方だ。

何事も勉強するのが苦手な人は、まずは”知る”に徹してみるといい。

今まで苦手と思えていた原因がすぐに分かるはずだ。

それは、自分が楽をしようとしていただけに過ぎないということに。

http://anond.hatelabo.jp/20160519113034

なんで蹴りたいのかの掘り下げができない幼稚なテクニック

2016-05-18

ホシノ天然酵母を使ったパン作り日記

天然酵母入手の経緯

嫁さんが常々利用している宅配カタログ

ホシノがあったので気を利かせて買ってくれた

起こしに適した季節になってきた

わざわざ恒温槽とか導入して起こしたくなかったので

この季節は適してますね。3日位で起きるのではないだろうか。

生地の水回し

最近色々思うところがあって、低加水パンにしてみようかと

思った。

低加水のメリット

生地比較的硬くステンレスボウルが汚れない。

指も余り汚れない。

水回しに華うどんテクニックが使えるため短縮化可能

ポリ袋への生地の封入が簡単

焼成時間の短縮化

水の節約

低加水のデメリット

気泡が大きくなりにくい

水回しの上手い下手が結果を左右する。

ヘタするとガッチガッチのパン部分的形成される恐れ

小麦粉熟成による旨味が期待できないか

2016-05-16

SEOネットをつまらなくする仕事をしています

今の職場に入ってしばらくになるが、やっていることは自社アフィサイト記事検索結果上位に入るようにする、

とどのつまりSEOってやつであり、そのためのライティングやら何やらのあれこれに携わっている。

で、色々とモヤモヤが溜まってきた時期にちょうど目にしたのが「プロブロガーものテロ行為絶対に許すな!」とかいはてブ記事だった。

http://xevra.hatenablog.com/entry/2016/05/14/212228

筆者の意図に沿うか確証のない要約をすると、「金儲け目的だけのゴミ記事インターネットを穢すんじゃねえ」というもの

 

うん、ごめんね。俺もそのゴミ記事書いてる一人なんだ。しかブロガーどころか会社挙げて。

しかし言ってることに同意する気持ちを抑えきれず、ついうっかり増田なんぞに手を出してしまった次第。

 

もちろんSEOと言っても何書いたってそれさえやれば伸びるような魔法テクニックじゃないのだが、

実際のところ記事の内容自体は「有用性があるっぽい」ことさえ書いておけば事足りてしまう。

ユーザーがそのキーワード検索して知りたいであろうことをネットで調べて、

虚実入り混じった、いや書いてる本人も何が虚で実かわかってないような曖昧情報

 

「今回は~について徹底解説いたします!」

「~ってことありますよね。実はそれ、~なんです!」

「~で損しないためにはこうしましょう!」

経験者/プロの方に話を聞いてみました!」

 

みたいな誰でも俺でも書けるクソつまんねえ文章にまとめるだけ。

優良なレビューサイトみたいに商材を自分で試しに使ってみるなんてことは当然ない。話をする経験者やプロなんてのも実際にはいない。

まり検索すりゃ出てくるもの以上の情報量記事が書かれることなんて絶対にない。

そんなゴミ記事でもそれなりのビッグワード検索1ページ目に居座ることはできてしまうし、コンバージョン率も上がるのだ。

 

今や少しでも検索ボリュームの多いキーワードはそんなサイトに食い尽くされてしまっており、

検索するたびにまるで俺が書いたかのような内容のうっすいページばかりがヒットする始末。

SEOを知る前は気にも留めなかっただろうこのことが、同族嫌悪も入り混じって憤懣やる方ない。

金儲けするななんて言わない。もっと単純な文句だ。つまんねえ記事ばかりで検索上位独占してんじゃねえよと。

数十分検索した程度の知識しかないてめえらの憶測や要約にユーザーの2割だか3割だかかっさら価値があるのかと。

そのトピックプロとして携わってる人の話とか、商材なら購入した人のレビューとか、

そういう「実」のあるページをずっと後ろに追いやってまでロクに中身のない「虚」が揃ってしゃしゃり出てくんじゃねえ。

 

もし人が書いてたらそう言いたくなるようなゴミ記事ネットをつまらなくする仕事をしています。みんな本当にすまん。

これでも記事の切り口や視点を工夫するとか、自分なりに少しでもマシなものを書こうと努力はしてるから今は堪忍してくれ。

 

でもGoogleアルゴリズムだってどんどん進歩してるし、

いつかはこんなゴミ記事実体のある記事と見分けられるようになるかも知れないと希望を抱くこともあった。

けど、どんなタイトルクリックしたくなるかとか、トピックをどう取り上げたら読み手感情(特に正義感とかね)を煽られるかといったような、

人間の半ば生理的とも言える要素に訴えかけられたらGoogleだってどうもしようがない。

週刊誌スポーツ紙テレビ新聞などがそういうテクを如何に使ってるかってのはこの仕事最初に学んだことの一つだけど、

その手法に則っている限りGoogleいくらアップデートを重ねてもゴミ記事が無くなることはないんじゃなかろうかとも今では思う。

 

ただ医療関係はマジに適当なことしか書いてないアフィサイトしゃしゃるの勘弁してくれ…

よくないねボタンがあったら片っ端から豪打してやりたい。

 

救いなのはちゃんと「実」のあるページもSEO対策をきちんとしてるところは検索トップに出ていること。

うちの社長もそういう本当に有用もの作りに乗り気で、計画中の新サイトはその道に職として携わる人にライティングを依頼する方向とか。

それを聞いてこの会社に入って良かったなと思ったけど、それが実現した暁にはそこに俺の仕事はあるのだろうかと気が気でない。

2016-05-13

平成9年生まれ風俗嬢

しばらく射精してなかったのでお手軽に射精しようと

柏の激安風俗にいって指名もせずにはいった

ずいぶん幼い感じだなーと思い年齢聞いたら

なんと平成9年生まれだった

今までの一番低年齢は平成3年生まれしか自称)だったので今回は群を抜いて若く

しかもなんで自分風俗いるか言い訳がましく言うので何度も中折れ気味になってしまった

勿論テクニックはないのでフェラ自体気持ちよくなかったがまったく風俗ずれしていない地方アイドルっぽい可愛らしいルックスと相まって

罪悪感でいっぱいになったがまた行ってしまいそう

平成5年生まれと7年生まれの娘がいるのに…

2016-05-07

ブクマ大量に貰えるらしいのでExcelテクニック晒す

Excelというキーワードがやたらブクマ集めるようなので今使っているExcelスキル晒すわ。

Excel2010で動作確認済み。一応ググったら出るはず。

クイックアクセスツールバー(Alt + 数字キー)

正直言ってショートカットキー知らなくても大体これでなんとかなる。

オプションから追加してもいいし、やりたい処理のボタン右クリックして追加してもいい。

俺が追加してるのは下記の通り。

・シートの行を挿入

・シートの行を削除

・シートの列を挿入

・シートの列を削除

Ctrl + Shift + 「+」とかはセルの挿入とかいう余計なダイアログボックス出るのでNG

セルを結合して中央揃え

正直言ってセルの結合なんて使いたくないけど元のフォーマットに合わせるために使わざるを得ない場合がある。

・その他の罫線

罫線操作に役立つ。

Excel方眼紙で図を作る際にも役立つ。

Alt +「o」→ 「h」→「r」

シート名変更。別にマウスでカチカチやらなくてもできる。

Alt +「e」→「m」「c」

シートの移動またはコピー別にマウス使わなくてもできる。

Alt + 「e」→「l」

シートの削除。別にマウス(以下略

(範囲選択した上で)Alt + 「i」→「e」→「s」

連続データダイアログボックスが出現。単純に値を増やすだけもできるしオートフィルもできる。

(範囲選択した上で)Shift押しながらマウスドラッグ

範囲選択したセルを切り取って挿入する。切り取ったセル分だけシフトするので便利。

F4

前回行った書式設定を行う。最近知ったが便利っぽいので今後使っていきたい。

繰り返し行う作業が増えたらやること

Excel (やりたいこと) ショートカットキー」でググる

大体出るが、たまに出ないことがあってYahoo知恵なんとかでありません的な情報が得られるのでそのときはクイックアクセスツールバーVBAで補う。

はてなブログ独特の文体ってあるよね

理屈よりもアクセス意識したがゆえに、文章が上ずべりしてるなにかしらの空虚さというか

アフィのためにテクニックむき出しのあの感じほんと独特

そしてなによりブックマークにならぶこれまた上ずべりした互助会連中のコメント



面白かったです^ ^

参考にします!

すごいですね~



などなど、なんともいえない感じというか、botじゃねーの?感がすごい

そしてbotじゃないとわかって怖くなるよ

人間が打ち込んでるんでしょ?すごくない?感情あるのかね

人工知能ってもうできてるんじゃないかなって思ったよw

2016-05-06

http://anond.hatelabo.jp/20160505235650

なんだったら3Pとか4Pとかしたいよね〜

ゴムつけて、こうやったらこの娘喜ぶよ〜とかテクニック共有しあったりすると、お互い技術向上と気持ちよさ向上とハッピーだし

なんだったらテクもないのに秘め事として向上心もみせないような配偶者とこれから50年付き合わなきゃいけないとか不幸だよ

2016-04-26

お前が電車を止める前に伝えておくと生きる意味のある人間などこの世にいない

から

「生きる意味が無くなったか死ぬ

とかアホなこと抜かして電車止めんじゃねえよボケが。

家に帰って寝ろカス

 

人間にあるのは「死んだ理由」だけ。

お前が電車止めて死んだとしたらその理由死ぬ前に書け。

借金背負ってどうしようもなくなったか負け犬として死にます」って文章にしてみろ。

それを1時間でもいいし丸一日何回も読み直せ。

「俺こんな理由で死なないといけないの?」

って馬鹿らしくなるから

実際借金死ぬとか馬鹿しかないからそもそも死ぬなって話なんだけど。

世界を救うわけでもない、たった一人の女の子を助けるために死ぬわけでもない、

ガンダムホワイトベースを守るために死ぬわけでもない。

自分借金というネガ死ぬだけ。

新大陸発見しようとしたが志半ばで死にました」

難病に苦しむ人を救うために研究していたが自分病気にかかり死んでしまった」

人類宇宙進出のために飛び立ったがロケットが爆発して死んだ」

これはいいよ。

だってどっからみてもカッコいい死にざまじゃん。

もし成功してれば英雄になってただろうし、その志は後世に受け継がれるよ。

夢に人生賭けて叶わなかったとしても夢中で死ねたらそれはそれで満足だろう。

命賭けてまでやりたいことがない方がむしろ不幸だろ。

何が楽しくて生きてるの?

って

 

でも借金死ぬってダサすぎるでしょ。

あの世が仮にあってそこで閻魔様や事故で死んだ人や病気で死んだ人の前で

借金で死にましたフヒヒサーセンw」とか自己紹介できる?

無理でしょ・・・

そもそもそんなショックで精神的におかしくなるなら最初からリスクを取るなよ。

何もないところからいきなり借金が生まれるわけないだろ。

被害者面すんな。

つーか自己破産どうした。

 

死ぬ理由を考えろ。

死ぬことが終わりだと思うからダサすぎる選択ができる。

死ぬことが全ての行動の終点だと考えろ。

終わりじゃなくて行動に対する答えである結末が死なんだよ。

そこまで死まで含めて長い長い目で見た行動なんだよ。

畳の上で死ぬこと、電車に飛び込んで死ぬこと、夢をかなえて死ぬ夢やぶれて死ぬ

全部着地点は死だ。

なのにわざわざクソみたいな理由

電車の走るレールに向けて着地しにいくやつが馬鹿しか思えない。

なんで何十年生きてきて最後死ぬ理由がレールの上にジャンプなの?

 

勿体ない。

本当にそう思う。

 

生きる理由は無い。

死ぬ理由を考えろ。

 

追伸:

ブコメついたか調子にのって「PS」とかやるの正直クソダサだから嫌だけど誤解があるのだけは勘弁ならんから言っとくけどよ。

俺も自殺考えて頭おかしくなった張本人からな。

そのクッソダサい理由教えてやろうか?

単位落として留年確定したから死にます

これが理由

これで泣いて鬱になって電車に飛び込もうと毎日思ってホームセンター練炭キョドりながら買ってたわ。

それで自分でもおかしくなってるの分かりながらこのままじゃまずいと思って

教授と親と友達時間タップリ使って改善しましたわ。

俺が自分でどうしたらヤバい精神状態から抜け出せるのか歯を食いしばりながら当時考えましたわ。

そりゃ死にもの狂いで考えたわ。

そのとき必死さ考えたらメンヘラ自殺なんてもう一回追撃で殺してやりたいくら

何の努力も無くクソダサで死にやがって・・・それはもういいか。

とにかく朝昼晩必ず1回は状況報告を親と教授にしたよ、無かったら電話かけまくってくれって。

自分ひとりで考えると碌なことにならないって客観的に思ってるなら考えるのをやめて他人依存したらいい。

そのために信用できる他人とつながりを常に取り続ける仕組みを考えたらいいだけだったから。

結局留年したし就職うまくいかなかったし夢は破れたけどそんなもんもうどうだっていいわ。

留年たか自殺したみたいなクソダサで死ぬより100倍マシだから

歯食いしばって枕や布団噛みながらウンウン苦しんで学校行って卒業しましたわ。

これ全部クスリでもなんでもなく自分意志でやったことだからな。

心の病気意志ねじ伏せられる。

その原動力が死んでも嫌だという価値観形成から来てる。

こんなクソダサな理由死ねるかよっていうガソリンを俺は用意できたか自殺しなかった。

これは理由はなんでもいいが自分否定しきれないロジックをくみ上げておけば防止できるってことだ。

甘えてロジックを組み上げもせずに無気力自殺して被害者ぶるんじゃねえよ。

頭の臭いした枕の味知ってんのかお前は。

知らずに死んでも、被害者ぶるのか。

何様だ。

ここまで書くとドヤ顔正義感)が「それは気力の無い人には~」とか言い出す馬鹿がいるけど、

俺も気力なかったっつーの。

何もしたくなかったっつーの。

でもそれでも行動起こしたのはこのままじゃヤバいって思わないとヤバいって頭で思ったからだからね?

このままじゃヤバいとすら思えないなら本当に生きる力ないから死んだ方がいいよ。

ヤバいと思わないとヤバい」なんて脳信号は「女の子パンチーおーくれ」レベル信号強度しかねえよ。

そんなんに気力とか必要ないから

その種火を必死に大きくしていくのも最初からガソリンぶちまけてるわけじゃねえよクソが。

女の子パンチレベルを何度も何度も継ぎ足してやって復帰したんだわボケが。

人を超人扱いすんなっていうのと自分過小評価して特別扱いして甘やかすなボケが。

それが甘えだっつってんだよ。

俺とお前の決定的な違いは「思おうとしなかった(甘えたかった→自殺たかった)」か「思おうとした(苦痛を選択した→自殺したくなかった)」かの違いでしかない。

その選択さえ無意識に介入しようとしなかったお前には神の啓示で逃れられない宿命であり運命で、

自分は何一つ悪くなく圧倒的被害者であり弱者であると信じているんだろうな。

でもそれただの勘違いだしそれに気づくチャンスも腐るほどあったから。

意図的無意識的に自分でそれに気づこうとしてこなかったし、

こうやって指摘されても顔を背けバリアを貼ってるんだから全部故意自殺から

あ、人工呼吸器付けてるなら謝る。

 

死が逃げるという発想も、自分で死が逃避にならないというロジックを組み上げられないせいだろ。

そのテクニックがないことを自覚しろ

テクニックがないなら宗教でも何でもいいから何かに頼って依存しろよ俺みたいに。

結局はお前がお前の意志で変えようとしない限り何一つ変わらないんだよ。

この前提を否定しきれる論理も無いのになあなあで自殺に向かおうとする心の弱さとちゃんと向き合え。

言葉が届かないんじゃなくて言葉拒否してる自分を変えろ。

理解しようとする気が無いのに数学物理も覚えられるわけねえだろ。

言葉も同じだ。

理解する気が無い自分自覚しろ

自分自身と向き合い切れてない。

緊急回避しないといけないなら死ぬ気でそれだけ考えろよ。

 

ちゃんと考えろ。

そのちゃんと考えないことがクソダサな死因に繋がってるんだよ。

もう一度聞くけどお前という人生の本の最後

借金でフヒヒFin

電車に乗られたwあべしw」

恋人に振られてリスカしてたら血が止まらなくなってえ~」

とか

綴りたいか。

綴りたいのか

ならもう仕方ないな。

他人はお前にどうすることもできない。

お前は無敵だな。

 

ごめん自殺衝動説について言っとくの忘れてた。

そういう無意識下の行動に影響を与えるほど意識によって強く刻み込む作業ができていれば

衝動自殺しました、なんてことにもならないんだよ。

どれだけショック受けても自殺しないやつはしないんだし

自殺するやつとの決定的違いはそこだ。

自分無意識コントロールしようとする意識が全くないし

無意識意識に対しての無意識として自覚・知覚して対立しようとしないから操作改変もできない。

から自分もっと見つめろと言っている。

無意識の行動ひとつひとつにも理由がありそれを紐解いて分析することで無意識改変が行える。

無意識の行動っていくらウンコしたくても路上で下脱いで野糞するのかよ?

無意識最強じゃねえよバーカ。

奴隷になることを受け入れてる意識なだけだろ。

どんだけ甘えたいんだ。

そんな低レベル意識で生きる意味が、とか借金で夢も希望も、とか

どの口で言ってるんだ。

意識低いなら無意識の死にたくないって本能の声にだけ耳を傾けてろよ。

中途半端すぎるわ。

無意識最強とか言いつつ死ぬって矛盾してるだろ。

自分の中のエラーと向き合えって言っても

お前はまた低次元意識バリアー貼るんだろうな?

いくらでも逃げれるしホームレスにもなれるのに

自分が死しか選択しようとしないから死ぬのに他人がどうやって助ければいいの?

屁理屈こねるのは上手いくせに自分が死なないためのロジカルシンキングできないってどんだけ雑魚ナメクジなんだよ。

それだけ頭回ることに自信があるなら自分を騙すか自分論破できないロジックを組めよ。

それをやらずにセンチメンタルな気分に浸りたいだけだろ。

悲劇ヒーロー悲劇のヒロイン気取りか?

から特別扱いしだがるんだな。

そんなやつ有史以前から腐るほどいましたか・・・さら誰も感動せんから

誰のパクリとか言えないレベルでありふれてるから

つまるところ泥臭い渦に飛び込むのが嫌なんだろ?

脳を焼かれるようなループ自分から飛び込むのが嫌なんだろ?

みんなそれ乗り越えて人格を作り上げて大人になってきたのにそれするのが嫌な子どもなんだろ?

から同情されないんだよ。

まだ理解する気がないのか。

 

自分がそうだから他人がそうとは限らない説。

これも、もういいからそういうの。

何も例外とか無いから

自殺したくなる→自殺する→死ぬ→クソダサな理由が死因。

俺の言ってるのは全部これだけだから

俺だけは特別事情、とかそんなもんねーから

お前の抱えてる悩みとか人類発祥してメソポタミア文明できた当たりから

似たようなもの数えきれないほどあっから

何もそこにオリジナリティとかねーからマジで

いやマジでマジで

何もオンリーワン理由じゃないんで。

その意味不明自意識の高さやめてくれる?

というかその実益のないプライドの高さが自殺へのトリガーになってるってこと自覚したら済む話なんだけどな。

そこらへんに転がってるクソダサな理由で死のうと思ってることを

頑張って正当性持たせようとしても無駄から

 

あの手この手で言い方変えてクソダサな理由自殺すんなって言っても

案の定「衝動で~」とか「ケースバイケースで俺だけ特別」とか言ってバリア貼ってくるやつ多いな。

まさにその防衛行為自分無意識に向き合いメスを入れて手術することを拒み続ける末期患者なんだけどな。

まず自分病気ってことを自覚してそれと向き合ってどうやって対策を取るのか考えるのはやって当然だし、

そこまで余力がない・・・とか言われてもなら余力のできる環境緊急回避するだけの分別くらい付けろよ。

大人なんだから誰にも頼らなくても頼まれなくても自分意志でやれよ。

それ病気になっても病院に行かないのと何も変わらんからな?

心の病で運命づけられたものと思って兆候絶対あるのに何も講じてこない自分責任だろ。

全て自己責任だよマジで。むしろ誰のせいにできるんだよ。

お前の人生はお前しか保証できないしメンテできねーよ馬鹿が。

お前の親もお前の子どももお前の人生は歩いてねーからマジで

なんで自分・・・マジで意味分からんわ。

いやわかるけどな。

いつまでも甘えていたいと思ってるんだろ?俺がそうだったからな。

お前は違う?違うわけねーだろ行動が同じだから分かるわ。

気力使いまくる自分の中に神を作る工程の辛さにやる前から怯えてるんだろ。

メンヘラっぽくやんでれ最悪死ねばいいからとそれをせずに甘えてるんだろ、

完全に当時の俺だわ。

でも俺の理由は俺だけの特別理由オンリーワンだと勘違いしてるんだろ、

完全に当時の俺だわ。

もう完全に俺のパターン入ったわ。

無意識にメスを入れることを怖がってるんだろ、

病院いかない爺ちゃんといっしょ!何も変わらないいっしょ!いっしょです!ざんね~ん!

行動がすべてを物語ってる。

口よりも雄弁に。

どれだけ俺は違うって喚いても行動がいっしょ。

考えてることもいっしょ。

何もかも同じ。

バリア貼るだけのプライドはあるのに意識低くてメンテは怠るとか最初から分裂症だとしか思えん。

自分自力でちゃんと統合しなさい。

 

誤解を恐れず箇条書きにしてやるよ。

1.自分に生きる意味があると思っている目標志向があるが実力が無い、もしくは過去に失敗経験がない

2.達成不可能となり精神的不調に陥り、対処法を知らない ※A

3.目標達成不可能という現実と向き合いたくないためにあえて精神的不調の檻から出ようとしない

4.長期化すると自分がこうなったことには何か意味があり特別だと思い込み努力放棄する理由を構築し始める ※B

5.この段階で他人が助言しても「自分特別バリアによって聞き入れられなくなる ※C

6.現実的センチな気分に浸るのも限界になり、現実と向き合わなければならない段階に来る ※D

7.死の恐怖から現実に戻るか、戻りたくない場合自殺する ※E

 

※A 生きる意味が失われた、と思い始めるから不調を来す。メンタルダメージのある失敗経験が無いため大人になっても対処法が分からない。

※B この不幸動機が生きる理由となり活動できる。

※C やっと見つけた次の生きる理由否定されたことによる過剰防衛反応

※D 貯金が無くなる、仕事を失うなどの命には関わらないが生活人生が変わり決断が迫られるターニングポイント

※E このとき真面目な無能であればあるほど悲劇のヒロインになり切れているので自殺する。

 

1~7が短期長期どっちでも起こっていることで何も変わりない。

何も特別性はない。

どこにでも転がってる大人になり切れなかった子供たちの話。

http://anond.hatelabo.jp/20160426152527

それならお前は美少女がいないと何もできないという答えしか導き出せないし、

現時点でそれで満足しているのなら必要ないだろう。

お金に困ってる人がお金を稼いで満足していて、

死にかけたらお金なんて意味ないって言いだすパティーンで、

今はお金最高って言ってるターンだからお前には必要ない。

スピリチュアルを求めだすのは死にかけてからか死のうと思いだしてからから

物欲に狂える内は大人しく狂っておいた方が生産性がいい。

そういうのに満足できなかった末期の人間にとって必要なのが宗教

それを自前するか自前するだけのテクニックが無いなら既存のものに頼る。

それだけの話。

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/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、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 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ 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 のような場合は期限切れがあってはならないので、パスワード等を預かる

http://anond.hatelabo.jp/20160426130945

いや1行目にその余事象云々の式は書いたじゃん。高校数学特有っぽい用語が好きじゃないから単語を使わなかっただけで。

でも元増田レベルだとその前に確率原理に立ち返るべきなんだよ。気軽に1から引くとかやったら「なぜ確率は1から引いていいのか?引くとは?」という疑問が出るだろ。

高校レベルの(測度論的に定式化されていない)ナイーブ確率論は「根元事象の数を数える」以外の原理存在しない。

増田がごちゃごちゃ書いたのは全てその数える操作ショートカットするためのテクニックに過ぎない。

そんなのは原理理解してからやればよい。

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-25

今風のブログではなくて、昔ながらの日記」を書いている人いる?

自分ブログテイストに合わないからこの記事は書かないとか

ただの日記は注目浴びないからダメだとか

よく読まれるために目次を付けるような小手先テクニックとか

めんどくさ~

2016-04-24

はてなで紹介されるイラスト美術関連記事にわかぶりが酷い。

執筆者が酷いんじゃなくて、そのレベルまで落とさないとついてこれない読者が悪いし、

そのレベル記事執筆者の思惑通り引っかかってしまうあたりがとてもひどい。

専門用語も並べられてるけど言ってることは補色と隣接補色のみ説明していて、

そこから図解してスプリットコンプリメンタリー形成されることすら説明していない。

ところがにわかはてなー無駄に難しい用語に感心してしまう。

こないだのトレースの対する記事ももうちょっと突っ込んだ練習法を書けるんだけど、

この分じゃこいつらに教えるのはもったいないとすら思えてしまう。

トレースが上達する、ではなくトレースで上達する方法。もちろんそればっかやっててうまくなるわけないけど。

後でやるなんてタグつけて放置するから、いつまでたっても外縁しかからないんだろうな。

そして外縁をありがたがるという流れ。本物による単なるさわりしかない、本物っぽい感じに弱い人々。

筆者は優しく丁寧にわかやすPVを稼ぐ記事を投下して、結果的に誰のスタディにも繋がらないというこの感じ。

アニメ塗りって実は面の把握ができれば上達早いんですよね、はいそうですね、

位のやり取りが有名人のひとことですごい発見になってしまったり。正直頭が痛い。

あーそれ車輪の再開発ですよ、って何度目にしただろう。こないだ線なしで面から塗って塗り重ねながら完成させる手法が独創的、

なんて若手のイラストレーターが紹介されていたけど、自分の知ってる界隈じゃ2011年からそれやってるもっと上手い人がいたし、

海外じゃスピードペインティング系の普通テクニックだし、何より俺自体それずっとやってました、みたいな。

有名になったもん勝ちなんですかねえ。

ユージュアルサスペクツが軽んじられる原因について※完全ネタバレ注意

http://azanaerunawano5to4.hatenablog.com/entry/2016/04/24/005535

おおむね記事内容同意した上で。

ユージュアルサスペクツの問題は、テクニックとか以前に新規で観た人が面白くない(あえて断言)ところだと思う。(好きな人ごめんなさい)

公開当時の印象は全く異なるのだろうが、今の観客からたらこうだろうという観点で以下書いています。あと自分自身、そんなに好きな作品ではないです。以下本文。

まず有名なあのオチだが、残念なことに作品の知名度とあらすじからして、今の観客が真っ先に思いつくのがあのオチなのだ。逆に言えばパイオニアなのだが、そんなもの関係ない新規観客にとってこれはかなり辛い。

そしてドラマ部分が決定的に弱い。あのオチを想定している観客にとって、キントの主観のみで語られる取り調べ室のストーリーはそもそも怪しすぎる。一応キントとキートン友情ものに見せかけて…というネタなのだが、観客が疑った状態では感情移入し辛くドラマとして苦しい。

さらに、映画のオープニングは事実部分の映像なのだが、そこにキートンが殺されるシーンが入っているのが完全に失敗。取り調べ室のストーリーが嘘もしくは間違いだと観客にわからせてしまっている。

またドラマが弱い要因として、キャラクターの魅力の乏しさもある。前記の二人はいいが、他のメンツは如何にもモブという枠を出ないため、こいつが犯人では…と想像する楽しみや余地がない。犯人でありそうなのはキントか刑事かコバヤシくらいだよな、って印象だ。

キャラクターの弱さを補うためか、妙に大袈裟な設定が取り入れられているが(伝説悪人カイザー・ソゼとか謎の日本人弁護士とか)、これがまた地味な作品内容から浮いていて、余計な疑いを観客にもたらす。

あとホラ話のくせに、終わってみればなんかセコい話なんだ。ソゼ、セコッ!て印象を持っちゃうんだ。

シックスセンスが早くも古典と化しているのと比較すると、こういったドラマ部分の差が大きいと思われる。良くも悪くもシックスセンスはわかりやすドラマで牽引し、幽霊という見せ物要素で観客を飽きさせず、オチの目くらましとしてのドラマがそれ単体でも十分観れるものに出来上がっているのだ。対してユージュアルサスペクツはオチ一点勝負に走りすぎたきらいがある。ここで一般的評価に差が出てきたのだと思う。

また、この映画演出というか見せ方にも難がある。オープニングの映像で、カイザーソゼは左手で銃を横にして撃つ。セリフでの説明ではなく映像でソゼのくせを描き、左半身麻痺のキントを容疑者から外すための演出だ。それ自体はいいのだが、残念なのはこの映像が妙に思わせぶりで映画好きにはあからさまに怪しく映るし、普通の観客は左効きにあまり気付かない、という困ったシーンになっていること。銃を水平にして撃つくせはキートンなのだが(右利きだが)、前述の通りここでキートン殺害されるため二重にトリックを阻害しているのだ。

また、ここは好みが別れるところだろうが、この映画クライマックスオチは「キントがソゼだった」ではなく、「取り調べ室の話はホラでした」なのだ。この違いはデカく、オチの爽快感を削いでいると個人的には思う。実は刑事はキントがソゼだったとは気付いていないし、深読みすれば本当はキントがソゼでない可能性もある。想像が広がるという意味はいいのだろうが、受けるインパクトという意味ではかなり大きさに差が出る。

どうもここら辺のちぐはぐさを踏まえるに、新味を抜きにして脚本演出などの技術的な観点から見るとそこまで完成度の高い映画ではないように個人的には思えるのだ。キントとソゼの演じわけなどケビンスペイシーの名演技はあったが、あとから見ればこの映画評価ほとんどは彼一人が担った印象を持つ。いや、パイオニア作品なんてそんなものなんだろうけれど、後一歩足りてない感は否めない。

から、この映画現在の観客にあまり歓迎されないとしたら、それは結構健全なことであるとも思う。ユージュアルサスペクツが過去映画になったとしたら、それは映画進化してるってことだ。

http://anond.hatelabo.jp/20160423184004

面接テクニックとかじゃないけど、趣味を尋ねられたときにそれが余暇の過ごし方とかいうどうでもいいことを訊いてるんじゃなくて、

時間を割いてどんなものを得ようとしているか、実際に得ているものは何かを訊いているのではないかという思考に至るくらいの想像力必要なんじゃないのかと思った。

本を読んだら内容を考察したり書評を書いたりして残してる?

自分思考価値観はどう変化したか具体的な本を挙げて言える?

それとも文学的とまではいわなくても、書や表現に関して何か体系的なところに興味があるの?

本を読んで得た知識で何か作り出したりアウトプット出してるの?

実は本を読んで終わりなんじゃないの?

上のエントリみても全然そういうことに対する言及ないよね。

読書はたくさんしているのかもしれないけど、その割に言いたいことをまとめて、ちゃんと伝える方法を得られていないのでは?

本当に「趣味読書であることが鼻で笑われる原因なの?

2016-04-23

増田文学不毛

増田文学はいくつかの特徴がある。

実体験を偽装しつつ多少のフィクションを入れてそれとなく読者を誘引してフィクションで笑かし、オチを付けるというものだ。

中身自体普通作品と同じくどんでん返しなどを含めた創作テクニック使用される。

ところで筆者はこのうち増田文学の最大の特徴である実体験に見せかけた作り話、という側面が大嫌いだ。

あるいは実体験かもしれないという面白さは作者の面白さではなく、面白さに拍車をかけるためのものであって、それを力として錯覚するのは筋違いだ。

そして一握りの作者は時々自分の力を錯覚するコメントを残して悦に浸っている有様ですらある。

実体験かもしれないという仮定剥がし純粋フィクションとして面白いかどうかが力量だ。

ここにはバイラルの力量があるか否かという下らない尺度は含まれない。

バイラルの力量は残らない、忘れられる、消費されるの三段で構成される。

そんな意味互助会ブースト不正のなんだのと言っている話が散見されるのも、この実力のないバイラル空気に感じる不条理なのだろう。

こないだブログ界隈の売れ方を自慢する阿呆出会ったが、文法的に間違っているものを推進していたり、とにかく安く早く短く売れることを目標にしていて反吐が出そうだった。

本当にバイラルをやりたいんだったら自分の腕だけで笑わせるんだ。それが実力ってもんだろう。

2016-04-16

http://anond.hatelabo.jp/20160416193307

あえてマジキチのフリすることで場を白けさせるのは昔からあるテクニックだよな

ただそれやってると本当のマジキチになるけど