「オンオフ」を含む日記 RSS

はてなキーワード: オンオフとは

2017-12-12

Google Home / Android TVは、テレビの電源オンオフ機能対応していません。

なんでだよ、AndroidってGoogleのもんだよね、最初対応しなきゃじゃないのか?

2017-12-09

anond:20171208132512

ありがとう、なるほど良く分かった(分かってない)

水路のパワー凄いんだなあ

混合で温度調整するってことは、極論、ガスが常にフルパワーなら温度設定はいくらでもガス代は同じになるけど

機械は頭良いか効率良くガスのオンオフ、水量調整をして温度設定でしっかりガス代が変化するのかな

2017-11-22

[]IHコンフィ

IHワット数を調べてみた。

帰宅しないとIH型式メーカー不明だがパナソニックだと

仮定すると

保温モードワット数は90もしくは100W

スロークッカーデューティー比1でオンオフさせながら加熱すると

確か80℃だったと記憶している

スロークッカー弱のワット数は130、半分で65なので

IH保温モードの90Wでも ややオーバースペック

おそらく油の温度が70℃80℃になるまで強火でやった上で

そのあと保温モードに下げればよろしいかろう

そして3時間放置か?

[]スロークッカーザワークラウト

ザワークラウト3日3晩 スロークッカーオンオフさせて完成!

(1)

タイマーを使ってスロークッカー(弱130W)の電源を周期的にON、OFFさせる。

繰り返し周期のうち15分だけON(加熱)、90分はOFFタイマーを設定。

  27~30℃ ←発酵適温?

ingredients

キャベツ半玉を5mm幅くらいの千切りにする

キャベツの重さの1.5%ほどの塩、クローブペッパー(いずれもホール)をまぶして軽く揉み合わせる

ローリエ葉っぱ追加

水(キャベツに対して20%くらい)追加

 作り方

時々マッシャーでつついたり、天地ガエシした

3日間+α 発酵させた

 脚注

REVEX 24時間プログラムタイマーII PT25

電気代は3日間で36円くらい

2017-11-09

モバイルバッテリーに直挿しする機器おもしろ

皆がモバイルバッテリー持ってるからこそ出てきた商品だな

USBぶっ刺して終わりっていう代物

乾電池よりずっといいわ

USBスイッチも売ってるから、それ使えばオンオフもできる

結構色々できそう

2017-10-25

もし欲求オンオフコントロールできるようになったら

性欲オフにしたい

性欲が邪魔すぎる

まわりはそのままでもいいんだけど

自分だけでいいから性欲無くなればいいのに

2017-10-10

名言】諦めなければ夢はきっと叶う!できることからまず始めるためには?

スキルアップBLOGでの名言言葉でもよくあることですが、何ごとも諦めなければ夢はきっと叶うということ。

シンプルイズベスト名言ですが、これほど心強い名言は他にありません。とにかくできることからまず始めるためには行動するということ。

たとえ、できそうになくてもとりあえずやってみる精神は大切です。


諦めなければ夢はきっと叶うと本気で信じこむ

本気で叶えたい夢があるのなら、本気で諦めなければ夢はきっと叶うと信じ込むことです。


もちろん、根拠などなくても構いません。そもそも根拠とかくだらないことを考えているから夢から遠ざかるのです。


夢を持つことさえ難しい世の中ですが、本気で夢を叶えるためにはとにかく本気で叶うことを信じ込んでは、それに向けて行動していきましょう。


諦めなければ夢は叶いますが、時には諦めないと夢が叶わない場合もあります



時には諦めなければならない場合もある




この見極めが非常に難しいものですが、こればっかりは経験を積まなければ答えは見つかりません。

しかしたら、人生経験を積んでも見つからいかもしれません。

ある意味ではそれはそれで1つの答えなのですが、時には諦めることも重要です。人間は引き際が大切と言いますが、この引き際がわからない人は私も含めてたくさんいます

今の人生の中で叶わない夢をいつまでもいかけたとしても、実際には幸せから遠ざかるのは事実

しかしたら、追いかけている過程幸せ人生かもしれませんがそれは非常に稀なこと。諦めなければ夢は叶いますが、時には諦めることも大切ということですね。

難しいものです……。


とにかくできることから始めていく




頭の中でアレコレ考えていても夢は叶いません。

本気で夢を叶えるためには、とにかくできることから始めていくこと。小さなことでもいいのです。今の自分自身ができる範囲内で行動していきましょう。

たとえ失敗しても挫けずにそこからまた何かを学んでは、再スタートすればいいだけのこと。

何も失敗は恥ずかしいことではありませんし、むしろ夢を叶えるためには必要不可欠な出来事ですからね。

からこそ、失敗を恐れずにドンドンと夢に向かってチャレンジしていきたいものです。


名言】諦めなければ夢はきっと叶う!できることからまず始めるためには?のまとめ




人間ですから常に夢に向かって頑張ることはできません。

時にはダラダラしたり、サボったりしたいもの。それが人間というものですし、オンオフは大切にしていきたいもの

本気で夢を叶えるためにも、このような考え方は本当に大切です。

それから、夢は何も1つだけとは限りません。あまりにもたくさんありすぎるのもまた違いますが、2つ、3つの夢を持つことは別に悪いことではありませんからね。

途中で夢の内容を変更してもいいですし、時代に応じて変化させていくことは大事なこと。

たとえ叶わなくても夢を持つだけで人生ドンドンと潤っていきます最近とくにこれといった面白いことがない人は、とりあえず小さな夢を持つことをお勧めします。

どこどこに行きたいやあの名物産を食べてみたいでも構いません。

とにかく夢を持つことで、今のくだらない人生から脱することは保証します。

諦めなければ夢は叶うことを信じては、自分だけの夢をこの人生で叶えていきたいものです。

2017-09-26

anond:20170926171834

これと似たような話題で電源のオンオフがわかりづらいって増田無かったか

2017-09-11

艦これ歴9ヶ月でも感じる艦これの要改善

1 無駄クリック要求するな

たとえば1戦後に「進撃」をクリックさせたなら、次の戦いまで自動でいってくれや

なんで能動的に選べもしない分岐でまたクリックさせるの?

行き先はランダム勝手に決めるだけなんだから

クリックする意味ないところではクリックさせるなよだるい

毎日積み重なれば膨大な無駄クリックになってるぞ


2 鋼鉄が余りすぎ

初心者の段階では余るとかじゃなくて

一応提督レベルが100を超えても、どういうプレイスタイルでも鉄だけ余る

大型建造の時ぐらい鉄だけバカスカ食えばいいのに他の資材も使うので変なバランスは解消されない

鉄だけカンスト30万とかい

イベントの間は強敵と戦って艦が壊れまくりで修理に使うんだけどそれでも鉄は数万程度しか使わない

燃料や弾薬は10万単位で溶けるのに

バランス失敗してるんだから鉄の使い道なんか作れよ


3 模様替えを画面のどまんなかにおくな

日常的には使わない使用頻度低いボタンをど真ん中・上に置くな

なに考えてるんだ

独特の読み込みがあるからクリックするとストレスがじわりとくる

4年やっててこんな基本的レイアウト改善しないってなんなん?

ノーギャラで俺に整理させて欲しいぐらいだわ


4 修繕の変なアニメで待たせるな

高速修復してもアニメが動いてる間はまたないとダメ

製作側の自己満足プレイヤー利便性を落とすな


5 セクハラっぽい台詞自動で言わせるな

秘書官自動挨拶雑談をしてくるのはいいとして

なんかこのゲーム提督は全員にナチュラルセクハラを働いてるらしくて

そういう変なリアクション台詞が全艦に搭載されている

びっくりしたり罵ってきたりするうるさ目の声になるわけ

うるさいからあれは自動で流す台詞に入れるな

秘書官グラフィッククリックしたら流れるようにするとか分けておけ

セクハラ提督に成りたくないプレイヤーも居るだろうし


お読みいただければわかるように、ゲームの深い部分は語ってない

簡単に気付けて簡単改善できるようなことばっかしだ

4周年を迎えた大ヒットゲームでこんなのが放置されてるの理解出来ない



追記

秘書放置ボイスだったら設定でオンオフの切り替えが出来たはずだけど。

え、この文読んで放置ボイスの話だと思ったなら文盲ゲームやってない人だよね?

設定オンオフなんて知ってるってことはたぶん文盲だよね?

なんで相手の話も理解できず頓珍漢な返答する文盲にこうやって脳のリソース食われなきゃいけないんだろうね?

文盲は弁えて黙って暮らしてくれよー

たのむよー


https://anond.hatelabo.jp/20170911010114

2017-09-09

PS4夜泣きの大変さ(推定)が分かってしまった

こんにちは、男です。

いや、待ってください。機械赤ちゃんを一緒にするなって書き込んでツイッターに晒さないでください。充分承知であります。ただ、もうちょっとだけ、もうちょっとだけでいいのでどうか耳をお貸しください。

いやね、聞いてくださいよ。私先日PS4を購入したんですよ。まあ所詮ウンコカスの如き給料差し引いて買う訳なので、当然安いやつを買う事になるんですが、いわゆる初期型というやつを買ったんですね。

初期型PS4は外見がなんだか革命的で、キュビズム???まあなんて文字表現すればいいか俺はよく分からないんですけどとにかく黒い直方体のオシャレゲーム機なんですよ。詳しくは検索してください。

で、そんなオシャレゲーム機は当然操作性もスマートで在るべきですよね??なんと対応ボタンに指で触れるだけで電源のオンオフディスクの吐き出しができる超画期的マシンなんですよ。厳密に言うと指を触れる事によって微弱な「静電気」を感じ取ってマシンに電源を入れろ、ディスクを吐き出せ、と指示する訳なんですが。

最初指で触れた瞬間にピッと音がなり画面に「ようこそ」と表示される感動といったらもう堪りませんよ。未来ゲーム機で遊んでる、という高揚感で涙すら浮かびましたもの

いや、ここから問題なんですが、前述した通り電源スイッチは「静電気」で動くんですけど、静電気っていうのはあらゆる所に存在してるじゃないですか。そしてそれらは電気の通る機械の方向に移動するらしいですね。

よーし明日も早いし今日は早く寝るぞーっおやすみーって布団バサーー!!!ってすると布団に溜まっていた静電気が移動して勝手PS4ピッピピッピッピッーーーーよ う こ そ てろてろてろてろーんピッピピッピッガシャガシャ(ディスク吐きだし)!!!!!

うわあああああああ

って事が何度もありまして、なんとか静電気放電させるようにやさしくPS4を触りながら地面を触るという行為をしてたんですけど、もう3回目くらいから憤慨してコンセントを引っこ抜いて寝ました。

翌日思いました。これは夜泣きでは、と。

これを一週間くらい体験してから夜泣きの大変さが身を通して分かってきました。

疲れて安眠したいのに音(と光)で強制的に起こされる気持ち(赤ちゃんは発光しませんが)。騒音を気にしてしまう焦燥心。何処にも行き場がない苛立ち。

実際、これまで夜泣きは大変だ、という声を幾ばくかは聞いてきましたが、愚鈍にもそれを受け止める事はせず、寧ろ蔑ろに近い感情を抱いていた事を暴露しなければいけません。私は独身男ですし、生涯妻子を持つことは無いと思いますが、もし夜泣きの面倒をパートナーに任せっきりの方がいらっしゃいましたら、是非協力してあげてください。きっとあなたパートナー疲弊していますあなたの助けがパートナー癒しになることでしょう。

アニメソシャゲに負けた理由通信環境や視聴環境の変化から見る

アニメ時代遅れで、ソーシャルゲーム時代なのかもしれない

https://anond.hatelabo.jp/20170908011453

を見て色々思ったのでつらつらと

今のアニメはつまらない。萌えアニメばかり。スマホゲーと違って進化していない。

そんな意見散見するが、今回は別の視点時代の移り変わりと環境の変化から見ていきたい。

現在通信、娯楽はスマホ大勢を占める時代であり、有線ではなく、限られた通信量と速度の時代だ。

そしてTV地デジを期に大きく衰退し、無料でのアニメ配信を行っていたニコニコも衰退した。

PCスマホの隆盛とともに、その座を追われつつある。

現代の状況として、スマホコンテンツとしてアニメを見た場合

通信量が嵩み、拘束時間が長く、イヤホン必要で、見るのに手間もかかる…というのがアニメになっている。

時間で遊べ、通信量を食わず、音がなくても楽しめる。これが現代スマホコンテンツの条件である

アニメはどれも満たしていない。

からだろう。スマホ漫画を読むという人は多いが、アニメを見る人を私は知らない。

コンテンツとして現代向きでなく、アニメ用のインフラだったTVニコニコも有線回線崩壊している。

現在アニメ問題点

デジタルTV環境はそれほど普及していない。地デジ化による複雑化、環境一新を機に人が離れた。

アナログ終了時はニコニコなどのネット放送が増えていたこともあり、アニメファンTV離れを加速させた。

多くの若者スマホで満足している。

●主要なネット放送サイトだったニコニコは衰退し、ログイン必須で月額課金が画質面などで重要ニコニコでは、

ユーザー離れはユーザー数、滞留時間現象に直結する。そのためついでのアニメ視聴が見込めなくなった

現在アニメは有料のサイトログイン必要サイトでの公開が主であり、敷居が高い

どのサイトで公開してるのかも様々なサイト分散してしまい、わかりづらい。

また、現在完全に終わった規格であるAdobe Flash Playerや、専用のアプリ要求する残念なサイト大手存在する。

これもまた敷居が高い

アニメソーシャルゲームに比べ、通信量が多い。ソーシャルゲーム最初ダウンロード以外は軽い。

イニシャルコストの初回通信量をどこかのWifiでこなせば、あとは軽い。

アニメは長い。外出先で10分以上の動画を見るのは通信量、行動コストから見てきつい。5分でもきついくらいだ

アニメは音声なしに成立しない。スマホの利用は無音利用が多い時代になっている。

改善方法として考えられるもの

デジタルTV環境の普及。NHK民放化するか、契約者以外には見せず、金も取らない方式にすれば

安価情報動画の娯楽装置としてTV復権はありうる。動画が高コスト時代にとって、無料動画装置は魅力的になれるはず。

現状、TVコンテンツの割に高コストである

ログイン不要のわかりやすアニメ放送サイトを作る。スマホサイズならなんとか見れるが、画質が悪い

その代わり、極端に通信容量の少ない設定を用意する。

アニメを細切れにし、OPAパート、BパートEDで視聴出来るようにする。

演出面などの制限は出るが、ユーザー必要な部分だけ見れるようになり、短時間でもアニメを楽しめるようになる。

これでも長いので、OPAパート、Bパート、Cパートなど更に細切れにしても良いかもしれない。

字幕オンオフ選べるようにする。字幕サイズも選べるようにする

2017-08-22

ランチはいつも独りメシ

私はランチに限らず食事は独りで済ませたいと思っています

それは食べることに集中したいから。

集中して味わいたいから。

でも会社の同僚は私をランチに誘ってきます。いつも断るのでもう誘われないですが、世間一般の人はやはりみんなで楽しく食べたいと思っているのですかね?ビジネスではよく取引先とランチミーティングなどと聞きますが、私の場合は無理だなぁ。仕事仕事食事食事区別したい。独りで食べることは気分をリフレッシュさせる意味も含まれていますのでね。私はオンオフをハッキリさせたいのです。

2017-08-09

電車によくいる怒鳴り散らす不機嫌なサラリーマンってなんのために生

悪意とかじゃなくマジ。

どういう価値観で生きてんだろう。

東京地下鉄にいると、不機嫌なサラリーマンの多さにびっくりする。険しい顔をして、ちょっとぶつかっただけの子供とかに怒鳴って。

例外なくくたびれたスーツを着たサラリーマン

機会があれば訊いて見たい。

なんでそんな不機嫌なの?

仕事が嫌なら転職すれば?明日から会社行くのやめればいいじゃん.

勤務先だって、そんな嫌々仕事をやられても生産性低いだろうし、全体の士気にも影響するだろうに。

家庭があるから辞めれないといったって、別にバイトだっていいわけじゃん. プログラミング勉強をして受託するとかでもいいし(自分フリーランスエンジニアなのでこう思ってしまう)

そもそもそんな嫌々働いてるアンタをほっとく家庭なんて捨ててもいいんじゃないの?

なんでもっと楽しい方を選ばないの?

そういう努力はしないの?

等.

----------

コメちょっと読みました.

ここで喚いてる時点で同列

どうでもいいんだよなあ. 上とか下とか本当どうでもいい. そうういうおっちゃんの理由事情心理匿名で知りたいんだ俺は...

そう書いてるお前は上で幸せ

わかる。あとクソッ!殺すぞっ!とかずっと窓に向かって呟いてて、なんつーか、これが日本現実だよなぁって思う。

俺が想定してる「怒鳴り散らすオッサン」像に近い。不機嫌オーラだけでなく、なんつか、行動してるんだよな。ぶつかってきたり必要以上に反応したり

今度あったら直接問いただしてみては

それも暴力じゃない?だからこういう場できいてるわけで 俺はいいけど相手はどう思うかな.

例外なくサラリーマン」ってホントか?ヤバい身なりの婆さんとか、性の喜びおじさんみたいな人とか、電車はいろんなタイプのブチ切れ人間がいるぞ?

そうかもしれない. ただ会社員ってことはある組織一定以上評価されて、安定的人間関係が一応あるってことで、電車内の姿とは確実にオンオフあるってことだろ. うまく言えないけどそこが気になるんだよ 一体会社ではどう抑圧してんだ

簡単に言いますけどそんな年取ってから転職先なんてないでしょうし仕事がたのしくてしてるなんてほんの一握りかと

転職すれば?とは書いたけど、別に転職じゃなくてもいいわけ

とにかく状況を変えればいいじゃんか なんでしねえんだ ってこと

日々の暮らし理由なら、生計立てる方法はいろいろあるじゃん

俺は学生時代ネットショップ開いたりして十分自活してたよ

バイトだってあるじゃないか 少なくともあれほどの状態になってまで会社にいる意味ってあんのかマジって本当に思うよ

あのエネルギーがありゃ、なんだってできると思うよ

仕事がたのしい人が少ないかしょうがないってのは、ストレス自分の中だけじゃ収まらなくなってる人間にとって勤め続ける理由にはならんと思うんだが

-----

コメントまたちょっと読んだ. 200くらいついて驚いてる.

まれるために多少煽りを入れたのは許してくれ. 句読点死ぬほどどうでもいい

オッサンには幸せになって欲しいと思ってる.

俺はそういうオッサンをやり過ごせる無関心な社会が嫌なんだよ. そういうオッサンについて語りたかったんだよ.

今度からそういうオッサンを見つけたら思い出してくれ

2017-06-28

型落ち格安3Dプリンター 3D SYSTEMS Cube 3 の購入前に知っておくべき事

別にわざわざ増田で書くような事でもないのだが、増田を使ってみたかったというのもあるので、ここで書く。

手軽なFDM方式3Dプリンタである3D SYSTEMS社のCube 3rd generationの新品未開封品がオークションストアなどで比較安価取引されている。

私もそれを、ひょんな事から入手する事になったが、数日使ってみた換装は、「新規ユーザーには全くおすすめできない」である。以下、その理由説明していきたい。

ネット上の情報垣間見ても、ある点においていくぶん評判の悪い機種でもあり、またすでにメーカーの方でも製造終了かつディスコンとなっており(※消耗品提供はしばらく行われる)ので、あえてこれから新規で購入する理由普通ないはずであるが、上に書いたようにオークション等では新品で比較的安く入手できるため、ある意味入手しやすい機種と言えなくもない。だが繰り返すが、以下に記すようなトラブルにめげない自信のない人は、この機種を購入すれべきではない。

Cube3の特徴

私の見立てでは、Cube3は家庭用の安全で手軽な3Dプリンターとして設計されている。誠意ある大人の言う事に耳を傾ける事ができ、言ってる内容が理解できる程度の知性があれば、就学前の子供でも充分安心して使う事ができるように思える。しかしそれ故の痒いところに手が届かないような面も多く見られる。以下、それらを私なりに整理してみた。

長所
届いたその日からすぐに使える

パッケージには、プリンター本体の他に、専用マテリアルカートリッジ工作物の取り外し用のヘラペンチなど、3Dプリンティング必要なほぼ全ての道具が同梱してあり、手順通り開梱しセットアップすれば(※セットアップ時にネットアクティベーションする必要はあるが)、すぐに使い始める事ができる。

調整が簡単

工作物が乗るベッドの調整は自動化されており、手動での調整は滅多に行う必要がない。仮に必要になったとしても、付属の工具で、操作画面に表示されている通りにネジを回すだけの簡単さだ。

マテリアル排出ノズル一体型のカートリッジ方式で取り付け取り外しはワンタッチ

これがCube3の最大の特長(にして最大の弱点)で、排出ノズル(Cube3では「ジェット」と呼ぶ)がフィラメントを納めたマテリアルカートリッジと一体となっており、フィラメントに直接手を触れずにマテリアルの装填と交換ができる。カートリッジプリンタ本体の左右のへこみに一つずつ、都合二つまでワンタッチで嵌め込んで固定されるようになっており、他のプリンタのように、武骨なリールハンガーなどが必要ない、スマートな外観となっている。

FDM方式であるため、ノズルは200度まで加熱されるため、マテリアルの交換時にうっかり触ると火傷するのでは?と思われるかもしれないが、良く見るとノズルは放熱性の良いアルミ製であり、また操作画面の指示通りに取り扱う限り、ノズル温度が高い状態でノズルを取り外される事がないよう工夫されている。

マテリアルの種類や残量はカートリッジに内蔵されたEEPROMに記録されており、例えば工作物指定されたマテリアルが装着されていない時には、プリンター側でそれを検知して、カートリッジを交換するよう促してくれる。

デュアルノズル構成

無論お気づきとは思うが、一回のプリントで同時に二つのマテリアル使用できるデュアルノズルである二色でのプリントサポートはPLAでと工作物ABSでというように、異なるマテリアル使用する事もできる。

新しいファームウェアと専用スライスソフトウェアでは、水にぬらすととけるPVAのフィラメントサポートとして使用する事もできる。

専用のスライサー

Cube3の専用スライサーは工作物の配置や使用するマテリアルの割り当てをするだけではなく、工作物にあったサポートの生成をフルオートで行ったり、サイドウォーク工作物の周りに設置し、工作物をはがしやすくするための薄い板で、工作物ととの間はミシン目になっている)の生成を指定する事ができ、モデリングの段階で面倒な作業をする必要ほとんどない。

またスライス結果をWifi接続されたプリンターに直接送信したり、またはUSBメモリ用にファイルで保存する事もできる。

短所
とにかくランニングコストが高い

ノズル一体型カートリッジ方式であるがゆえに、この機種以外の機種では全く使う事ができない。つまりメーカーが今後同じカートリッジ使用した機種を製造しない限り(そしてそれは望み薄と言わざるを得ない)、このディスコンの機種でカートリッジ供給が終了すると、そこで製品寿命が尽きてしまう事になる。そればかりか、一般的リール売りのフィラメントにくらべて、価格のわりにはカートリッジ内のフィラメントの量はかなり少ないと言わざるを得ない。

カートリッジ方式なのに、密閉されていない。

マテリアルほとんど、特にPLA(ポリ乳酸)は湿気をよく吸収してしまう。メーカーでは相対湿度25%以下での保存を推奨しているため、湿度の高い日本では、除湿剤入りのケースに密封しなければならないかもしれない。

しかもすぐジャム

湿気を吸うと、マテリアルはしなやかさを失い、もろくなる。すると、フィラメントカートリッジ内で折れてしまい、ジェットから排出されなくなってしまう。これが割と簡単に起きてしまう。少なくとも私の場合、一晩放置しただけで、付属の2本のカートリッジが2本とも、ジャムってしまった。

実は、このすぐジャムるという特性ユーザーの間ではかなり良くしられているらしく、YouTUBEなどで様々なハックが披露されている。私もこれで助けられた。

電源を切るたびに、せっかく行ったギャップ調整が初期化されてしまう。

FAQによると、ギャップ調整は電源を入れるたびにやりなおして欲しいという事らしい。困った事に、マニュアルに書かれているギャップ調整方法は実は間違っていて、正しいやり方はFAQの方に書かれているので、要チェック。

一度印刷を開始すると、イルミネーションオンオフができない。

Cube3はこれでもかというくらい、各所に白色LEDイルミネーションが設置されていて、大変美しいのだが、下手すると何時間もかかる印刷中、ずっとイルミネーションを点けておく必要もないので、なぜ印刷中はオンオフできないの?としか言いようがない。

(追記予定)

2017-06-14

http://anond.hatelabo.jp/20170613211847

生活

挨拶

ドアの開閉

照明スイッチオンオフ

蛇口の開閉

衣服を畳む(洗濯物含む)

鏡を見る

箸で物をつまむ

食器に口をつける

食べ物を噛む

食べ物を飲む

液体を飲む

冷蔵庫を開閉する

椅子に座る

テレビチャンネルを切り替える

時計を見る

デスク

ペンを持つ

芯を出し入れする

マウスクリックする

ブラウザのタブを切り替える

del、backspase、enter、spaceキーを叩く

サイトを最新に更新する

・癖

ため息

各部位のストレッチ

関節を鳴らす

貧乏ゆすり

鼻をすする

指で机をリズムよく叩く

独り言

爪をかじる

頭をかく

鼻を触る

ホリック

スマホを手に取る

SNSリロードする。もしくは最新を表示する

SNSアクションを起こす

ソーシャルゲームを起動する

メールの受信ボタンクリックする

伸び続ける増田ブコメ確認する(僕の増田は一日平均100ブコメは確実)

2017-05-22

映画ドラマを用いた英語リスニング学習

私は英語趣味にして久しく、英語学習法などいろいろ探したり手を付けたりしてみたが、リスニングに関しては出来るようになりそうなのを見たことすらない。なので自力手法を開発していくしかなかったのだが、その手法はなかなかの成果を上げ、最近では自分の納得いくリスニング力にかなり近づくことが出来た。嬉しいので今回その手法シェアしてみようと思う

私は大人向けのドラマ映画を見ながらリスニング力を鍛えたが、子供向けのものも実はリスニングレベル的には大差がないので、より面白く感じてモチベーションを保てるものをやっただけだ。自分の好きなものを見て、楽しく続けるのが結局は一番効率的になる。英語教材は高いが映画DVDなら100円で借りてこれるのでお金もかからない。

スポーツ勉強など通常のトレーニングでは、考えて仮説を立て実際にやってみて実証するといったプロセスをとる必要があるが、リスニングは考えても出来るようにはならない。英語音声を何回も聞いてみて、必死意味を考えてみたところで何を言ってるかわかるようにはならない。

まず第一に音を覚える必要がある。だから英語字幕が出ない映画ドラマなどは見ても意味がない。英語字幕ありとパッケージに書いてあるものを借りてきて見なければならない。

英語字幕を出さずに視聴をする意味があるかというのは実は大きな問題である最初は何を言ってるのか全く分からないはずなので字幕なしで見る意味はない。

字幕を出しながらの視聴でもネイティブペラペラしゃべっていると字幕を読むのすらついていけないという人も多いだろう。一時停止をしながら意味確認しようとしても、映画ドラマに出てくる口語表現イディオムは難しいため一時停止しても意味がわからないということもある。その場合はまずリーディングの訓練をすることをおすすめする。簡単英語小説なら普通に読破出来るくらいのリーディング力がないと、ドラマ映画を視聴するのは難しい。

ある程度のリーディング力がつけば、一時停止して字幕を見ながらネット検索などで一つ一つ意味確認していく、という作業を全体通して2,3周繰り返すことで、字幕英文意味を全て把握することが出来るようになる。そうしたら字幕を消して視聴し、役者がしゃべっているセリフと頭のなかにある英文を比べていく。一致してるように思えない場合は、字幕を出したり消したりしながら同じシーンを繰り返し視聴し、字幕英文を繰り返し音読し、テレビの中の役者セリフに近づけていく。これは出来るまで100回でもやる価値がある。

1箇所を100回やっても分かるようにはならないが、長期間やり続けることで音の解像感が上がっていき、役者の話している音ひとつひとつが捉えられるようになり話している言葉も徐々に分かるようになってくる。

音を聞いて頭の中の英文と比べる作業は初めはものすごく疲れるし、うまく出来ないので辛くなるだろう。わからない箇所を100回音読する作業を全体通して3,4周するのが理想だが、別に10回でもいいし、1周でもいい。やり続けることが一番大切なので出来るペースでやっていくことだ。初めは一時間ドラマ一話に一ヶ月かかるかもしれないが、そのうち音読必要な箇所が減り必要音読の回数も減り、聞き取れるまで何周もする必要もなくなるので、一日かからず出来るようになる。

からないシーンを何回も聴き直すためには、巻き戻しを効率的に行えるようにすると良い。このためにはDVDを取り込んで再エンコードし、キーフレームの間隔を狭めるという作業必要になる。これは多大なPC知識必要で、法的にもグレーなので自己責任で行って欲しい。

それと、動画再生パソコンで行うこと。Media Player Classic Home Cinemaのようなソフトが良い。「前のキーフレームに戻る」「次のキーフレームに行く」「字幕オンオフ」「再生/一時停止」のキーボードショートカットを覚えて自由に使いこなせるようにしておく。私は全て矢印キーに配置することで快適に操作できている。

役者の音声と英文対応をとっていくうちに、様々な役者の様々な発音、訛り、音響による音の違いなどが頭に入ってきて、やがて初見の音でも何を言ってるのか分かることが増えてくる。そうなればいよいよ映画を予習なく最初から字幕なしで見るというトレーニングが出来る体制が整う。

音は覚えられたが、話のスピードが速くてついていけない、途中で疲れて集中が途切れてしまって意味が取れない、といった場合がある。そういった問題対処するためには、脳の動作スピードを上げる筋トレのような作業必要で、このために字幕を出さずにそのまま聞くトレーニング有効である

この脳の動作速度の問題は、実は大半がリーディングでも鍛えることが出来る。返り読みなしのリーディングをスラスラこなすことが出来るなら、リスニングでも音さえ取れれば意味を捕まえることは難しくない。リスニング能力の向上に行き詰まったら、リーディングトレーニングも併用することをおすすめする。

私のおすすめトレーニング法は、ただ辞書を引きながら英語小説を読んでいく、というものだ。児童文学にも大人の鑑賞に耐える楽しいものが多いので、そういったところから徐々にレベルを上げていけば良い。小説児童文学でもいろんな語彙が出て来るので、辞書を引いていけば自然に語彙力もついていく。

日本人一般的英語力では児童文学でも読破はかなり難しいが、そこは学習参考書とかネット検索質問サイトなどを駆使しつつ根性で何とかする。最初さえ越えてしまえば後は「小説を読む」「映画ドラマを見る」といったことだけで英語力は際限なく上げることが出来る。楽しくて実用にもなる最高の趣味になることは保証できる。

2017-04-28

http://anond.hatelabo.jp/20170428101311

腕時計は基本装飾品なんで、ノットくらいの値段の腕時計が一番使い勝手が悪いように思うんだがなぁ。

増田が書いているけど、ノットならチープカシオのほうが「ああ実用のためなんだな」と分かりやすくて使い良いと思う。

そもそもどういうとき腕時計必要かと言うと、仕事取引先と会っているとき携帯時間確認するのが憚られるときなんだよね。

から、そこそこ高くておっさん臭いデザイン時計需要があるんだよ。

プライベートなら、携帯時間確認すればいいんだし、ノットくらいの価格プライベート用っぽい腕時計って、あまり使用する場面がないと思うんだよね。

あ、女の人ならオンオフ兼用で使えるんで、20代の女ならいいと思うけどね。

2017-04-15

http://anond.hatelabo.jp/20170415151332

あれも安物のスイッチなので、何度もオンオフしていると壊れる。

まぁジョークグッズなので仕方ないだろう。

2017-03-07

Dell Inspiron 15 3567でキーボードのみを使ってタッチパッドオンオフする

  1. Windowsキー+X → Bを押して「Windows モビリティ センター」を開く
  2. TabキーまたはShift+Tabキーを何度か押してタッチパッドの「オフにする / オンにする」ボタン選択する
  3. スペースバーを押す

めんどくせえなおい

2017-02-15

普通が一番いい

友達には話してないけど案の定ADHDだ。うちの母親父親もその気があるので遺伝率ぶっ高い。前々からwebとかのセルフチェックやると「気になるなら通院」とか言われるし、時間などの約束を守るのがなんかツラいので時々すっぽかすのはよくある。いや、つらいって言うか、単純に感情云々の前にスイッチが入らない。スイッチが入らないか仕事納期とか結構遅れるし、部屋は汚いので時々テレビゴミ屋敷特集やってたらいつか自分がそうなるんじゃないかと思ってゾッとする。他にもいろいろあって毎日憂鬱になる。同じく怒りのスイッチが入っちゃうとキレたら止まらないのも時々ある。母親ちょっとアレなのでこの間、

「もう少し自立してください。」

って何も考えずに言われたので何十年ぶりに大喧嘩したけど、母親はどうして俺が怒ったのか一生理解出来ないと思う。何も考えてないし、昔からそういう人だから何も考えずにズケズケ言うのでなるべく一緒に居たくない。

からお金管理死ぬほど出来ないので酷い時には一日の食費が300円以下になる。どこの国の貧困層だよ。あまりに困ったのでいろいろ調べて近所の区役所にある福祉課みたいなところでお金管理してもらうサービス探して登録した。元々年金暮らしとかの身寄りが居ないお年寄りサービスなのにお年寄りじゃない中年が来たからはじめは向こうも半信半疑だった。担当の人に状況を話すと向こうもエキスパートなので話は聞いてくれて献身的にやってくれるが、約束した事が全く出来ない。だけど状況は改善してる。ついでに話すと図書館で借りた本も1年以上返せなくなくて漠然と困ってる。毎月電話が来るけど本が返却できないし、こないだも担当者が返しに行こうか?って言ってくれたけど、いい年した大人なのに本も返却できない自分は人として足りなさすぎてその後少し悲しくなった。最近は毎月交通違反徴収警察がやってくる。

ただ一つだけ長所があって、測ったらIQ自分もびっくりするぐらいに高くてRPGのアビリティの振り分けが失敗したおかしな突出したキャラが出来てしまったが感がすごくある。中学生の時に担任先生プライバシー問題から言っちゃいけないけど、お前はクラスで突出してIQいからがんばれって言われたのを思い出す。誤解されると嫌なので言っておくと別に自分特別存在とか思った事一度も無い。

人の顔と名前を覚えるのがとても苦手だけど、仕事の打ち合わせとか、バーで人と話しても顔と名前は思い出せないけど、会話の内容はかなり記憶していて次会った特に半年前ぐらいだと誰がどこに座っててどんな会話したとかほぼ忘れないので時々気持ち悪いって言われる。

基本的に誰にも言ってない。言ったところで理解されないし、してもらおうとも思ってないし、どうせ偏見になるので誰にも話したくない。こないだも心優しい友達

自分も少なからずそういうところがありますよ」

って慰めてくれた。優しい。でもきっと根本的に伝わってないって思うからやきもきするし、なんか自分短所を押して話すのもちょっと違う。レイヤーがずれてて疲れるし、友達が悪い訳じゃないか申し訳無い。結局最終的に根性論になるし、精神病んじゃう人がネットアウトプットしてるの見ても誰徳なんだろう?って思う。逆の立場なら心ないか絶対努力問題とか上目線で言っちゃう理解がないってこういう事だ。だから僕の周りは僕のADHDを知らないので「基本ポンコツだけどやればすごく出来る人」みたいな評価になってる。社会人に求められるのは野球に例えると「2割でも打てばいいか毎日バッターボックスに立つ人」だけど、僕は基本1割未満の5分ぐらいでたまに10割に近づくので普通に会社は使いにくいのは自分でもよく分かる。結局フリーランスになってスイッチオンオフ活用する生活してる。

そんなこんなで通院してた事があった、病院でもらったクスリをもらうと自分の中で変化が起きた。

まず、数日に一度部屋でほうきとちりとりを持ってて部屋でニヤニヤしちゃった事がある。ゴミ屋敷に近づいてる僕の部屋がいままでより"は"きれいになってた。床が見えてるんだもの

あと、昔から疑問になってる事があって、怒りがやって来た時に友達

「寝て起きたら忘れるよ」

って言ってくれるけど、そんなやついるのか?って思ってた。そうなったらもうダメ。寝ても覚めても何年経っても怒りなんて収まらない。未だに何十年も前の怒りとか簡単によみがえる。だから最終的に当事者トラブルになる。上にも書いたけど、嫌なやつは無神経なので何言ったか覚えてないだろうけど、言った本人が忘れてても、僕は場面状況から思い出すからムカつく奴はきっと死ぬまで忘れない。嫌な奴と会わないようにしてたら友達ほとんど居なくなった。だったけど、クスリを飲んでたらイライラしなくなった。まーいいやみたいになった。ホントに寝て起きたら怒りが結構収まってる。自分でもブレイクスルーみたいになった。ちょっと感動して主治医に、

先生!今までマイナスだったのがクスリ大分プラスになってるんですね!」

と興奮気味に話したら主治医が、

田中さん。言いにくいのですが、世の中の人普通レベルがここぐらいですね...」

って悲壮感出して来たのでそこが何となく切な面白い感じだった。お笑い面白いのは切なさが含まれるところだ。同じく、別の日も自分性格的にハッキリわかっていた方が楽なので率直な意見を聞こうと思って自分の程度が5/10ぐらいかな?と思って聞いたら

「大変申し上げにくいのですが、8か9です」

ってまた切な面白いがきた。

結局、何となくいつもの億劫がやって来て病院に行かなくなったけど、自分の中では答えが出てて、クスリを飲んでるときには真人間に近づくけど、別人になって毎日頭がぼーっとする。頭の回転も悪くなってるのがわかる。実はそこが一番悲しくて、鬱病の人がマイナスになって健常者の時のプラマイ0に戻るのと違って、何十年もこれでやって来て急に別人になったら今までの自分は何だろう?大層な話だけど、アイデンティティって何だろうってすごく悩んだ。クスリを飲んでる今後の人生自分人生なのだろうか?ってなったのが大きい。だからいろいろ諦めて自分人生を受け入れることにした。クスリで踊らされる人生は僕の人生じゃなくて他人人生だ。

から頭の回転が人より抜群に速い。でも当たり前の事ができない。すごく困る。

自分問題点なんて俯瞰で見える。初見の人にはすごく頭良さそうって言われる。実際頭"だけ"良いし。だけど問題解決するための行動ができない。問題解決方法がわかるのに。車で例えるとエンジンフェラーリなのに足回りが竹馬レベル

美人が困るって意味ちょっとわかる。好きで美人に生まれた訳じゃ無いのに男から襲われそうになったり、ちょっと優しくしたら童貞勘違いする。毎日油断できない。ちょっと似てて頭良いって褒められるけど、頭良い"だけ"のポンコツなんて何もハッピーじゃない。人を見下してるんじゃなくて本当に普通がいい。毎日解法がない数学解いてるみたいだ。地獄ってそばにある。

最後に】

どうせブクマとかで心ない奴に、

「そんなこともできないなら頭悪いだろ」

とか謎の上目線で言われるだろうけど、そういう人はそういう認識で。利口なフリして揚げ足でも取ってろww

案の定文章の読解力の無い奴からの謎のコメント来たけど、じゃお前が俺と代わってくれよ。

【追記】

id:supu6000 こいつのコメントホントバカ医者で診断されたから書いた”だけ”なのにね。カミングアウトできない環境ってこういうバカいるから。

僕は診断もしてないし専門家判断がないのに勝手アスペ呼ばわりしたり、それって差別って理解してないのかな?

http://anond.hatelabo.jp/20170217144516

こういう考え方しかできないのって本当にかわいそうな人ですね。

単純に心優しい人に感謝を述べただけなんだけど。勝手につけあがる呼ばわりとかウケる

別に文筆業じゃないのに、事実だけを書いてもネガな事しか考えられないって人として欠落してるなw

この人は問題認識ができない気の毒な人なんだろうな。読解力とか弱そう。

id:IvoryChi

上にも書いたけどさ、言語理解が高いっていうなら文筆業でも無い俺にそこまで求めて、勝手副作用呼ばわりすんなよw

そっちの方が問題だよ。こういう頭良いフリしてるバカが一番苦手。

キリが無いからやめよう。

こいつらが健常者なら僕は永遠に障害持ちでいいし、一生リアルでもカミングアウトしなくてもいいやww

こういう奴らが世間にはたくさんいるかぎり差別とか永遠に無くならない。

2017-02-07

ソシャゲ放置ボイスについて

メニュー画面でしばらく何もせずに放置していると、突然ボイスが流れてくるゲームがある。

しかしあれ、「ああそういや放置してたわ助かったー!」ってことがそんなにあるのだろうか。

極めて個人的感想だが、こちらが聴く用意もできていないのにいきなり声を出されるのは、

まり気分のいいものではない。

艦これみたいに、オンオフの設定があるのはいい。できれば全部ああしてほしい。

ただ、艦これ時報のボイスもあり、あちらに関する設定はないのがちょっとなあと思うこともある。

「だったらボイス全部切ればいいだろ」と言われそうだが、そう単純な話でもない。

中破や戦闘不能のボイスまで切ってしまうと戦況が把握しにくく、ながらプレイがやりにくいのだ。

から普段のボイスはあった方がいい。ちなみにBGMは切っている。

断っておくと、ボイスがあることそれ自体は喜ばしい。ただ機能のもの邪魔なのである

2016-11-02

精神安定剤飲んでる社畜くん

メンタル弱い社畜アル中くんより重症

社畜アル中くんは少なくとも業務時間にヤクに頼ることはしない

しかしおクスリ常習者の病人社畜くんはオンオフ関わらずヤクに頼っている

2016-04-26

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

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

上記の問題点は、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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-02-28

ペットオンオフできたら飼いたい

飼うの大変じゃない?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん