  |
はてなキーワード: デスクトップとは
突然、宣伝インタビュー記事(https://thinkit.co.jp/article/10488)という燃料を投下してきたので、http://anond.hatelabo.jp/20160616172213に引き続きこき下ろす。
これは上記記事とあまり関係ないのだが、ホームページなどで特に目立っているので、あえて書くことにする。
メジャーなブラウザであるIE、Edge、Firefox、Chrome、Safariは国産ではない。そのせいなのか知らないが、やたらと「国産」を強調している。
しかし、国産であることのメリットはあまりない。あるとすれば、要望・バグ報告などのサポートが(製作者にとって)やりやすい、要望が通りやすいぐらいである。ただ、国産でなくても、サポート体制がしっかり整っているところは少なくなく、国産の優位性はさほどない。
エンジンは国産ではなく、ただのChromium派生ブラウザである。セキュリティ問題報告に対して報奨金制度を出して安全にすると言いたいのだろうが、国産だから安全というわけでもない。国産ブラウザは全体的に多機能・重量級な傾向にあり、それを嫌う人には全くメリットにはならない。
たったこれだけのメリットのためだけに、なぜ国産と強調することにこだわるのだろうか。
これは認識が甘い、と言わざるを得ない。というか、無理だろうと言いたい。
「ユーザーの声で進化するブラウザ」を謳うのであればサポート体制の強化が必要である。
しかし、いくらサポート体制を万全にしても、地理的に離れていることもあり文化が異なる。国が変われば求められていることも変わるが、もし特定の国を優先するならば、世界中のユーザーの声を聞くことは不可能である。無理に行うと妥協点を探すことになり、下手をすれば誰も求めていない機能が出来上がる恐れがある。ローカライズすると妥協点を探すことが多くなり、日本国内だけを相手にしていた時より困難になりそうだ。
その上、ユーザー要望で機能を揃えただけではただの器用貧乏である。ブラウザの将来性が感じられない。それでは海外では受けないのではないだろうか。
意味不明。これはつまり、将来的にはアドウェアになる、ということを遠回しに言いたいのか？(たぶん違う)
例示した「セキュリティ上問題になる危険なリンクは自動で排除する」は非常に危険。これが実現すると、一企業が恣意的に操作できるので、よほどD社への信頼がない限り不可能ではないだろうか。「中国系の外資系元社員が作ったブラウザ？」と勘ぐられているのでは道のりは長いだろう。
「特定業界の法人向けに専用ブラウザを開発していくプランもあります」というビジネスの展望があるそうだ。私企業なので、こうした利潤追求は当然である。しかし、この文脈だけだと、コンシューマー向けには具体的な話がない。似たようなスタンスであるVivaldiのような期待はしてくれるな、ということか。
マネタイズが難しく、市場的にも先細りな将来しか見えてこない(MSがやめたくてしょうがない)デスクトップアプリよりも、マネタイズのやりやすいスマホ向けに力を入れるほうがよいはずなのに、可能性を自ら捨てている。
アプリストアのリジェクトが不安だからやめたって、規約が厳しいiOSならともかく、ゆるゆるなAndroid向けをやらないのは意味不明。これでは「うちには全然技術がないから無理」と言っているようなもの。あるいは、できる人を入れる余裕がないということだろう。
先に断っておくが、元になっているChromiumは修正BSDライセンスなので、そのライセンスの条件を守っていればChromium派生ブラウザのソースコードを公開する義務はない。Google Chromeがその例である。
と回答したが、本音を言いたくなくて言い訳しているように聞こえてしまう。ブラウザを開発できる人数で公開するかどうかを判断したの？これでは開発者が多いほど外部の貢献者にバグを修正してもらえる可能性が高くなるので、バグ修正にかかる開発コストを0でやってくれることが期待できるという本音が透けているのだが。そういう本音が事実かどうかはわからないが、ほかに考えられることは、外部の貢献者が増えることで発生するであろうD社内部で決めた方針のブレを防ぎたいからとか、パクられるのが嫌とかの理由で晒したくないからとか、特に理由はないけどとりあえず言い訳しといたとか。
やはり、ブラウザの将来そのものについて具体的なことは何も書かれていなかった。ユーザーの要望に依存した受動的な開発体制だから何も出ないのではないか。こんなことで国内のシェアを増やすことができると思っているのだろうか。
Vivaldiでいいじゃん、Cent Browserでいいじゃんという人に対しては全然効果がないだろう。むしろ、墓穴を掘ったような感じである。
USB給電の問題ならハードかソフトが原因の切り分けが必要だけど、5年も使ってるならやっぱりまずは一度クリーンインストールだろうね。
ところでデスクトップなのかノートなのか書いてないからわからないけど、どっちにしてもSSDは2.5インチ規格なのでどちらでも問題なし。
SSDといっても基本的にはHDDとケーブルもコネクタも同じ規格なので、何か特別な処理を必要とするわけではない。
さらにストレージ換装によるメリットは、元データを削除しないで済むという点。
SSDに変えてから、元のHDDからゆっくりとデータをバックアップすればいいので、バックアップ→データ削除→バックアップ失敗発覚みたいな事故が起こらない。
最悪HDDに接続しなおせばもとの環境で起動できるので、パーツ交換の類ではかなり難易度は低い。（個人的にはCPU交換のほうが神経を使う）
簡単な手順
・購入時に付属していたインストールディスクを用意（なければリカバリディスクを作成）
・CD（DVD/BD）ドライブにディスクをセットして電源を入れる
・もとあるHDDを増設してデータを移行する（管理者権限とかあるから、ユーザーアカウントは同じ設定だと楽）
個人の使い方にもよるけど、SSDは基本的に容量が小さいので、マイドキュメント関連は場所をHDDに移動させたほうが運用が楽になる場合がある。
・なのでその人が主体のプロジェクトが実際に走り出したらボロばかり出てくる
・周囲がそれを必死にカバーして結果的に丸く収まっただけなのに本人は満足気
・注意されたらその時は神妙な顔でしんみりするのに後々全く活かされない
・だから周囲から細かいイライラを買ってばかりなのに本人は気付かない
・直属の上司が優しすぎる
・机が汚い
・やることリストは書きだしただけでやった気になっている
・単純に処理が遅い
・それでも自分なりに一生懸命やっているので自分の「できない点」に目が向かない
・打ち合わせをちゃんと聞いていなくてよく聞き返す
・自分が受ける仕事を緊急性や重要性で分類できずにただ受けた順に消化する
・人に仕事をうまく頼めない
・やる気だけはあるのですぐに出来もしないのに安請け合いして後々自滅する
・誰かに強く当たらなければならない場面でそれができない
今は省電力のほうに注力している気がする、なぜかデスクトップも。
やったーーーーーーーーーーー！！！！大学生活最初の夏休み！！！！！！！！！！！
ということで、国立大学で理系学生ライフはじめた人の感想として、高校生のうちからこんなところ見てる人に向けて心得ておくといいことを色々書いてみます。今大人の増田さんにも昨今の大学生の一例として見て欲しいです。
これから書くことは個人の感想だし、高校時代の友人や先輩からの受け売りもあるし、さらにすべての大学に対してうまく当てはまるものではないことをお断りしておきます。というか高校生に向けた話なら今書かずに3月にでも書いたほうがいいとか、具体的な勉強方法については例えば"シケプリ"制度のある東大や横市医には全く当てはまらないとか、まあだめな所いろいろあると思います。ごめんなさい。
これ分かってないとだいぶやばいので一応書いておきます。大学入った瞬間すでに真っ白に燃え尽きてしまっててこの半期でリタイアしかけてる人を実際に見てしまってるので・・・。
1日が勉強と(睡眠OR風呂OR飯)で終わる日が何度もあります。受験の時は一応飯と睡眠は毎日とってたはずなんだけどなぁ。
これは失敗談なのですが、スマホ(もしくはSIMの刺さるスマートデバイス)は買いましょう。必須です。あなたがまだガラケーで親の承認得られないようでしたら合格直後に量販店に駆け込んでSIMフリー端末とプリペイドSIM買いましょう。ハイエンドである必要はないです。
今の大学生、コミュニケーションツールはほぼLINEの一人勝ちで、あとは若干のtwitterです。メールの時代は終わりました。私は頑なに(親の意向もあったのですが)ガラケー、しかも通話とSMSのみの契約だったのですが、そのせいでLINEを全くと言って良いほど使ってなく(一応PC上のAndroid仮想マシンとガラケーのSMSを使ってアカウントは作ってましたけど)入学直後の友達作りに完全に乗り遅れました。というわけで(別にスマホ持ってなかったのが主原因ではないですけど)今私には同学科の友人がいません。ココ重要。
もちろん友達作りだけでなく、「いつでもどこでもすぐググれる環境」を作っておくことはとても良い勉強の見方になります。もちろん重要な情報は本読んだほうがいいですけど、ちょっとしたことを最小の時間で解決できるという点において本当に便利です。
これも失敗談です。新学期が始まった直後は、サークルを宣伝するのを主目的とした(と今となっては感じます・・・)"履修相談テント"がキャンパスにたくさん並びます。履修相談とは読んで字のごとく履修について相談をすることで、例えば学内で使うwebサービスの使い方とか、要項に載ってない暗黙の了解とか、どの授業はテストが難しいだとかこの時間はこの授業をうけるといいとか、そういうことを先輩が教えてくれるらしいです。
しかし入学当初の私は、忙しいはずの先輩たちがそんな自らの時間を割いて後輩のためにいろいろ教えてくれるなんて虫のいい話があるわけ無い、全部宗教勧誘だと勝手に思って近づきもしなかったのですが、本当にいろいろ教えてくれるそうです。さらにメインの目的であるサークルの宣伝もそこまで押し売りみたいなものではないらしいです。
私は理想的な時間割を作ることに失敗し、本来1回生で終わるはずの第2外国語を2回生でもやるはめになったようです。あの時履修相談テントに行っていれば・・・！と常々思います。どうにかまだ留年条件は満たしてないと思いますが・・・。
自分用のノートパソコン持ってないなら買いましょう。必須です。入学直後ガイダンスで偉い人に「学内備え付けのパソコンが沢山あるから買わなくてもいい」みたいなこと言われましたが嘘でした。学内パソコンはたくさんありますが基本的に自分のパソコンを毎日持ち運んで毎日使います。授業の内容まとめたりレポート書いたりとかちょっとした空き時間にできます。後述するコンデジとICレコーダーの母艦としても大活躍します。
個人的にはB5サイズ程度でキーボードが打ちやすい、(自宅にデスクトップ機があるので)CPUは最重要というわけでもない、みたいな基準でアウトレットの型落ちThinkPad X250買いました。
別途PC用の手持ちバッグ持ち運ぶのが手間でなければB4サイズでもアリですし、生協で20万円とかするLet'snoteとか売ってますが、Let'snoteに期待されるであろう軽さ電池持ち頑丈さに加えて生協の手厚い補償とかを考えて価値があると思うならそれもアリだと思います。今のところ非Windowsで困る場面もあまり無い感じなので、Macでドヤリングも悪くないです(でもUSB typeCしか付いてないアレはどうなんでしょうかね)。surface持ってる人意外といますが、大学の机は得てして特に前後方向に狭いのでキックスタンドのせいであまり奥に置けないことを考えたほうがいいです。高い買い物なので、よく悩んで、量販店で実機触って、満足できるもの買いましょう。
なおOffice付属のものを買う必要はありません。まっとうな大学ならDreamsparkもしくは何らかの包括契約とかで実質タダみたいにOffice使えます。
これは私が文字書くのがすごい遅いせいでもあり、またノート写してくれる友だちがいないせいでもあり、また大学の授業というのはまあ本当に教授によって様々なので一概には言えないのですが、スライドをぱっぱっと切り替える人とか速記みたいなスピードで(でも読める)文字書いてすぐ消す人とかいるので、ノート取るの追いつきません。ただただ文章書く・話すだけの人ならパソコンやポメラでメモ取ればいいのですが、図とか数式とかいっぱい出てくるとそうも行きません。そういうとき現代の学生はすぐスマホで写真撮ったりするのですが、運悪く後ろの席にしか座れなかったりするとデジタルズームしかできないスマホのカメラだとどうしても文字が潰れて読めないことがあります。光学ズームのあるデジカメはそういう時の強い味方です。1万円前半くらいのでもいいので持ってると便利です。もちろんシャッター音は消しましょう・・・。
教授はとんでもなく重要なことを唐突にしゃべります。そういう時ちょっとでも眠くなったりボーッとしてるとアウトなので、授業中は常にICレコーダーで録音してます。万一なにか聞き逃しても後で確認すればいい、というのは精神的な余裕も生まれるので良いです。スマホで代用もできなくはないとは思いますが、専用ハードウェアは便利ですよ。PCと接続してデータ移せる機能は必須だと思いますが、外部ストレージが刺さるとかマイクが動いて指向性変わるとか電池交換が可能とか薄いとか、そこらへんは個人の好みで。
この手のものは操作感が命なので、ソフトの作り込みが良い主要3社(オリンパス・パナソニック・ソニー)が鉄板です。
紙で配られた資料はスキャン(してOCR)しましょう。電子データで配られた資料はプリントアウトしましょう。紙には紙の(直接書き込んでメモしやすい／切り取ってノートに貼れる)、電子データには電子データの(なんといっても検索性)良さがあります。
スキャナー持ってない場合、Office Lensなどのアプリで代用もできます。これはなかなかの優れもので、カメラで四角いもの撮ると自動で四角いもの検出して正面から撮ったように伸縮してコントラスト調整して読みやすくする、まで自動で行ってくれます。Microsoft純正アプリだけあってOneDriveへのアップロードもできますし、そうすればOCRも行ってくれます、これがスマホで完結する時代になったのですから恐ろしいものです。ただ自分の場合はハードオフのジャンクコーナーから動きそうなフラットヘッドスキャナ見極めて500円くらいで買いました。
プリントアウトはコンビニでもいいですが、最近は新品のレーザープリンタでもローエンドは1万円しないとかとんでもない安さになってるので、突然レポートをプリントアウトしなきゃいけなくなったりする時とかに備えて1つ家においているとほんとうに便利です。ただしこの手のローエンド品はドラムが交換できないようになっているので、つまりドラムの寿命が来たらその時点でプリンタの寿命なわけです。でもそれでも何万枚かはプリントアウトできるらしいので大学生が一人で使うぶんには全く困りません。交換用トナーもリサイクル品なら高くありません。レーザープリンタ、おすすめです。
理系と言ったら英語です(誰でも英語必須だと思いますが)。英語は何世紀にもわたって世界的なブームが続いてるので、絶対色んな場面で英語使います。東工(予定)や横国などみたいに院の授業は全部英語というのは極端な事例ですが、英語しか資料がないという場面はこれから何度も出くわすと思います。
授業で教えられるものだけでは足りないと思ったので、自ら英語に触れていくことにしました。これは私が個人的に合っていると思うやり方で、効率性とかよりも楽しさ・挫折しにくさ・"英語が嫌いにならないこと"が重点です。ちなみに海外渡航経験はゼロです。
リーディングは自分の興味ある物のネット記事とか読み漁るといいです。googleのニュース検索の中から適当にチョイスして読むとかいい感じです。
日常的に英語に触れる、という点ではブラウザやスマホやゲームやPCの言語設定を英語にするのが最高です。
つい最近ですが、持て余してるパソコンにUbuntuを英語設定でインストールしてみました。変なことするとエラーメッセージとかが英語でバンバン出るのでLinuxと英語が一挙に勉強できてヤバいです。Reboot even if system utterly broken!!
リスニングはラジオのAFN。あっBGMほしいな～といった時にちょくちょくかけます。AMの放送局とかありますがネットで聞けます。英語の冗談で笑えた時本当に嬉しいですよ。
ライティングはたまに海外の掲示板にチョロっとなにか書いたりとか、スピーキングはスマホにOKGoogleしたりとか、その程度です。
私は以上4つの定番ingに加えて、基本的な英単語について瞬間的にイメージをするというのも大事だと思ってて、P-Study systemをやっています。簡単な単語集を制限時間1.5秒とかで4択からパッパッと答えていくのが好きです。
これはおすすめするか迷ったのですが、Wikipediaの「Unicode6.0の携帯電話の絵文字の一覧」をぼーっと眺めることもあります。これも基本的な英単語を瞬間的にイメージする練習です。
Unicode6.0の携帯電話の絵文字の一覧 - Wikipedia
センター本番の英語は8割とか散々な結果で辛かったのですが、今の成績を見る限りどうにか帰国子女グループの次くらいにはできるようになってるみたいです。
レッドブルとかモンスターエナジーとか、エナジードリンクキメると本当に目が冴えますよね。でもただでさえ生活バランス崩れるのにそこにさらに追い打ちをかけるようなことはこれからはやめたほうがいいと思います。エナジードリンクは体力が増えるのではなく体力を前借りしてるだけです。生活リズム・体調が一番大事。18過ぎたら老化始まりますよ。野菜食べましょう。
運動しましょう。ネタではないです。ポケモン捕まえるためにランニングとかでもいいと思います。北大とか筑波とかだだっ広いところだとキャンパス内の散策だけでもいい運動になりそうです。体動かさない日が何日も続くと結構ダウナーになったりします。
個人的な経験になるのですが、体動かした後というのは疲れるというのよりも先に学業が捗るというのが来ます。高校までは通学に1時間とかかけてそれがそこそこの運動になってたわけで、大学のすぐ近くで一人暮らし始めて一気に運動量減ってたんですね。それで今まで運動不足という状況に陥らなかったわけです。
残念な話なのですが、学部学科にかぎらずチャラチャラした見た目・生き方の学生が存在します。ウェイはみんな早慶に行って国立のましてや理系の道に進めばもはやそういったのに出くわすことはないかと思ったのですが、大きな教室に1~2グループとか、ウェイは存在します。これは個人的にすごいカルチャーショックで大学に入ってからの悲しみランキング堂々トップなのですが、そういった生き方の人間はどこにでも一定数存在するということを高校生のうちに知っておけば、もう少しショックは減らせたのかなという思いです。
多くの講義は最後の日に試験があるわけですが、過去問を持っていると本当に捗ります。もちろん試験対策にもなるわけですが、普段の授業でも過去問を見ながら授業を受けるとどこが重要なポイントかがよくわかります。過去問なんて受験までの話だと思ってたのですがどうやらそうではないようです。
過去問の入手方法ですが、もうこれは同じ学科の知っている友人や先輩に頼むのが一番だと思います。残念ながらわたしにはそういった頼れる人がいないので、次点の手段であるインターネットを使います。
なんたるインターネットリテラシー欠如の無頓着かという話なのですが、例えばtwitterで鍵もかけずに学内でしか知り得ない情報を話すような学生というのが若干数いるので(プロフィールに大学のことが書かれてなくても、学内で起こったちょっとした出来事とかをキーワードに検索すると釣れます。教室内での出来事なら確実に同じ授業を受けている人になります。もちろんそこからフォロワーを芋づる式にたどっていくこともします)、そういったアカウントを監視して何か試験に関する情報をつぶやかないかどうか待つわけです。
ごく一部に限りますが、試験問題をアップロードしている非公式サイトなども存在したりします。むしろtwitterではそういうサイトの情報を得ることのほうが多いかも。
実験したらレポート書きます。おそらく(あなたが高校生ならあなたが思っている以上に)大学生活のうち大部分をレポート書くのが占めると思います。
「学生実験 レポート」とかググると章立ての仕方とか出てくるのでそれに従います。もしかしたら教授からなにか指定されるかもしれませんがその場合はそっちを優先します。
多くの場合目的→原理→手順→実験結果→考察→参考文献みたいな章立てで書いていくのですが、最初から順番に愚直に書いていくのはお勧めできません。実験が終わった段階で手順と実験結果は終わっているようなものですし、多くの場合教授が最重要視するのは考察です。まず原理を書いて自分が実験でなにをしたかったのかを再確認し、適当な関連しそうな事項が載っていそうな本を図書館で探して参考文献リストを埋め、本をパラパラめくりながら考察を考えていきます。次に自分が原理や考察を書いて何を学んだのかを目的の項でさもこれから学ぶかのように書き、最後に手順と実験結果を適当に埋めます。
もしWordでレポートを書く場合、"スタイル"を用意しましょう。スタイルとは段落や文字列などに個別にフォントなどを一括設定できる機能です。例えば「目的」と打ったあとその行にカーソル合わせたまま「見出し(自作)」とかいったスタイルを選択するとその行がMSゴシック12ptで「1. 目的」となってそこで改行するとスタイルが自動的に「本文(自作)」とかになってフォントがMS明朝10.5ptに変更されたりします。めちゃくちゃ便利。またページ番号も自動で入力されるように設定します。実験ごとに指定される書式とかあると思うので、それにそってスタイルを自作してテンプレートとして保存しましょう。スタイル機能、Wordにおける超超超重要機能なので絶対使いましょう。
また、とにかく何かしら文章を書いてページを埋めてレポートを書いた気分に浸りたい場合、"=rand()"と打ってみましょう。数段落の文章が自動で挿入されます。自分の場合何も書く文章が思いつかない時にこれをすると、なんだか自分がすごく文章をかける人間なんじゃないかと錯覚して結構書く文章を思いついたりします。
明るい青春、楽しいキャンパスライフなどというのは理系学部生には無縁の話です。実験・レポート・課題・自習の毎日です。もちろん自分が専門にしたいことを中心に学べるのはとても良いことなのですが。
そんな中でも趣味が1つあると、誇張でなく「生きる希望」になります。私は受験勉強に本腰を入れてから一切の趣味活動(上のリンクでバレバレです)を控えて、いざ合格した時に解禁してみると随分とそれを取り巻く環境が変わっていたのを知って戸惑ったのですが、それでも学業とは切り離して好きなものを持っていることに大きな大きな安心感を持っています。
以上、こんな感じです。まだまだ効率化しなくちゃいけないところはいろいろあると思いますが、どうにかほとんど単位は取れそうです。
その後steamサマーセールで過去の名作を1000円以下で買い漁った。
もう続編が何本も出てるようなやつだ。
今その1作目から順に遊んでいるが、自分はたかが3D酔いのためにこれほどまでに人生の損をしていたのかと嘆きたいくらいの気分で一杯だ。
3D酔い対策のために肩を左右に揺すりならが遊んでいるが、それもまた臨場感があってよい。
それでもまだ30分も遊ぶと胸焼けに近いものがなくはないが、それを差し引いても楽しい。
恐らく自分は3D酔いに弱いことを認めたくないために海外のFPSを頑なに否定し続けていたのだろう。
それが克服できた今にしてみれば、なんとも滑稽なアンチ思考としか思えないくらいに下らない。
今までゲームといえばコントローラーかアーケードスティックしか使ったことがなかったが、キーボードとマウスで操作する感覚が新鮮で、しかもマウスでの方向転換は直感的でコントローラーより何倍も操作がし易い。
コントローラーでの操作に比べて、突然羽が生えてしまったかのように自由に動ける。
この感覚だけでも正直言って病みつきになりかねないくらい楽しい。
core2quad以降のCPUを積んでいるデスクトップマシンなら2万円以下のグラボで新作以外大半の名作は遊べるからPS4とか手が出なくて悩んでるなら超オススメ。
もうsteamのサマーセールは終わってしまったが、大体日替わりで色々なゲームのセールをしているので、とりあえずアカウントだけ作っておいてたまに覗いてみるといいよ。
・なのでその人が主体のプロジェクトが実際に走り出したらボロばかり出てくる
・周囲がそれを必死にカバーして結果的に丸く収まっただけなのに本人は満足気
・注意されたらその時は神妙な顔でしんみりするのに後々全く活かされない
・だから周囲から細かいイライラを買ってばかりなのに本人は気付かない
・直属の上司が優しすぎる
・机が汚い
・やることリストは書きだしただけでやった気になっている
・単純に処理が遅い
・それでも自分なりに一生懸命やっているので自分の「できない点」に目が向かない
・打ち合わせをちゃんと聞いていなくてよく聞き返す
・自分が受ける仕事を緊急性や重要性で分類できずにただ受けた順に消化する
・人に仕事をうまく頼めない
・やる気だけはあるのですぐに出来もしないのに安請け合いして後々自滅する
・誰かに強く当たらなければならない場面でそれができない
win7, CS6のindesign/illustratorで、画像配置をするときに、デフォルトで開くフォルダが
別の作業にかかったときにそこから別の場所に画像を探しに行くのが地味に面倒なのです。
「今開いているai/inddがあるフォルダ」もしくはデスクトップに変える設定などはありませんでしょうか？
仕事サボって増田見てるデザインDTP関係者とか結構いるんだろ教えろよ
よろしくお願いします！
Impress Watchがリニューアル(http://www.watch.impress.co.jp/20th/)した。
記事URL構造が過去記事も含めて変わってしまった事はあまり知られていない。
はてななどの各社担当者が自作サーバーのノウハウを紹介 -BB Watch変更する
http://bb.watch.impress.co.jp/docs/news/20091126_331459.html
↓
上記の記事は471usersを集めているが、
リダイレクト先は勿論0user、つまりブクマ無しとなってしまう。
せっかく記事を見つけてブコメも閲覧しようにも見られないのだ。
ではImpress Watchの全過去記事が新URLになっているかと言うとそうではなく、
調べるとPC Wacthでは2009/04/08の記事から変更されているようだ。
■リダイレクトされない
http://pc.watch.impress.co.jp/docs/2009/0407/fujitsuf.htm
■リダイレクトされる
Acer、初のNVIDIA IONベースの超小型デスクトップ「AspireRevo」
http://pc.watch.impress.co.jp/docs/2009/0408/acer.htm
↓
つまり、2009/04/08〜2016/06/01の7年2ヶ月のブコメは簡単に参照できなくなった。
同様の問題はWikipediaのhttps化の時も発生している。
Impressと言えば新聞社等のニュース配信と異なり、過去の記事も削除されることなく
長期保存(最古は96年4月:http://pc.watch.impress.co.jp/docs/article/960417/index.htm)されているので
その事実にはただただ感謝するしかなく、今回のURL変更に文句を言うつもりもない。
ただWikipediaのhttps化の時と同様の話ではあるが、
比較的規模の大きなサイトがURL構造を変更してリダイレクト対応を行った際には、
はてなブックマーク運営側においては別URLの提示を示す等の対応を行って頂きたい。
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
元増田です。
ブコメとかトラバとかで名前が出てたゲームについて追記しようと思ったけど長くなりそうなのでトラバにします。みんなありがとう。
みんなのMMO思い出話っぽいのが見れて楽しい、回顧厨なのかもしれない。
自分の中でMMOって昔自分が触ってた頃の雰囲気しか知らないので、
「MMOといえばこんな感じ」っていうイメージがあるけど、それ自体がその時期特有のもので、今はもう幻って感じが現実なのだなあと痛感した。
俺はおっさんになったし、時代も変わっているのだね、そうだね。
あれはイヤこれはダメって、ただ自分がわがまま言ってるだけなのも、わかっちゃいるんだけどなー。
新しいことを習得するのを億劫がるとか、まさしくって感じで嫌な年の取り方をしてしまったなあと思う。
FF14とDQⅩはどうした？っていうのについては、月額課金ゲームをまだやったことない、ROとかFF11とか14とかそういうの。
テイルズのやつが月額課金だったけど、メインで遊んでたのはcβで、正式サービス始まった時にパッケージは買ったけど結局一度もログインしなかった。
別に月額課金できないほど困窮してるってわけではないんだけど、心の弱い俺としては、
「お金払ってるんだからこっち遊ばなきゃ！」っていう強迫観念とかを自分でコントロールできない気がして、リアルな精神状態や生活がロクなことにならなさそうな気がして今のところ避けている。
過去何度か月額課金の壁を越えそうになりつつ踏みとどまっているので、今回も結局踏み越えないかもしれない。
とはいえ、求めている世界に近しいところはそちら側な気もするので、踏ん切りさえ付いたらサクっと払いそうな気はする。
・LoL
一番MMO関係ないけど、触ったことがあるので。いわゆるMOBA
身内がみんなやってるのでなんのかんの北米サーバー→日本サーバーと丸2年ぐらいやってる
ラムス君かわいいです。でもフルメタルラムス君の方がもっとかわいいです
なんとなくログインしてるけどプレイしない時間が増えてきたところで「久しぶりにMMOやりてーなー」って思い始めたんだと思う
対人戦が苦手だからソロだとやっても橋ぐらいで、サブ垢作ってはAI戦でアカウントレベルを上げたり、
お金貯めてチャンピオン(キャラ)解放する作業ばっかりして、いつまでたっても上達しないクソ雑魚ナメクジです
2年やってるけどたまに本気でAI戦で負けます、っていうあたりでやってる人は俺のヤバさを感じられるんじゃないかなって思います
あと対人は負けたらイーってなるし、勝っても今一つ楽しめないんですよね、何人かで遊んでて勝っても、気分がよくなってる自分に後から自己嫌悪してしまう
まあ、その辺は真っ当なスポーツマンシップを学ばないまま大人になってしまった弊害だと思って諦めています
ネトゲにおける自分の病気めいた癖が顕在化したタイトルでもあって、思った以上に自分は女性キャラを使えない病気にかかっていた
LoLみたいな、格ゲーぐらいのノリでキャラクターを選ぶゲームですら、女性キャラを選べるように精神的な壁を乗り越えるのに1年以上かかったっていう
それもランダムでキャラクターが選択されるモードで、観念してそのキャラ使うしかない状況に自分を追い込んで慣らしていってようやく……みたいな感じ
それどころか最初は人間のオス(イケメンども)のキャラクターすら、なんか恐れ多くて使えなかったっていう……あ、病院はもう行ってるんで大丈夫ッス、サーセン
とある週末、軽い気持ちで金曜の夜にクリエイトモードっぽいやつでソロプレイ開始した後、
ほぼ不眠不休で謎の密林都市を作ろうとプレイし続けて月・火と会社休んで危うくそのまま会社に行かなくなりかけたのでダメゼッタイ
よく無事に社会に戻ってきたと思う
封印。
・黒い砂漠
やはりおすすめする声が多いなー、人気あるんですね
名前は何回も見るので、ここか？ここなのか？って公式サイトには20回ぐらいアクセスしてるけど、
戦闘がアクション性が高いっていうのと、全部火力職とか誇らしげに書いてあってビビってしまっているのと、あと職業が性別固定なのを見て毎回引き返してます
あと友達の家にPC持ち寄ってみんなでLoLで遊ぶことが多かったせいで、微妙なスペックのグラボ積んだノートPCをメインで使ってるので、
せっかくのクオリティなのに画質とか多分だいぶ下げなきゃいけないんだろうなーとか、かといって流石にPC買い換えるところまでは投資できない……
熱のこもったトラバで非戦闘ギルドの存在を知ってちょっと興味が出てきましたが、やっぱり職業選択の自由が欲しいです先生……
もしかしたらキャラ作るエネルギーがあれば土曜日ぐらいに触ってみるかも
・ToS
ブコメとか見てるとToSやると思うって人が多くて、なんか割とみんな同じなんだなあみたいなことを思いました
すれ違うこともあるかと思うので、その時はよろしくお願いします
・ECO
・メイプル
メイプルは友達がどっぷりやってたけど、徐々に出会い厨化していく様を横で見ててうわあって思ってたのでその印象のせいで抵抗を感じてる
ちょっと興味あるけどログレスはMMOなのかMOなのかスマホなのかブラウザなのかなんかもう色々よくわかんない感じで？？？ってなってる
・UO
・ロードス
なんか自分の中でこの二つが同じ枠になってる
キャラが縦に長いゴボウみたいなヤツって印象があるけど、それで合ってるのかわからない。なんかごめん
・PSO2
でも昨日少しだけ触ったiOSのPSOもどきっぽい雰囲気のMMOがなんかとてもアレだったので、
それよりは真っ当に面白そうなイメージで、ちょっと逆に興味が出てきたところ
・FPS系
FPSは多分向いてないと思われる
昔サドンアタックを誘われてしばらく一緒に遊んだけど、コイツがいると勝てないみたいなレベルで友達に見捨てられるくらい上達しなかった
2ヶ月ぐらいやってたんですが、それでもキルデスが1/20とかそんな感じ
オフでFarCryのなんだったかが雰囲気が好きでせこせこやってましたが、難易度下げててもすぐ死ぬのでファストトラベル離脱を駆使しないとまったく進められませんでした
犬に襲われてパニクってロケットランチャー足元にぶっ放して死ぬタイプのアレです
あと出てきた敵にビビりすぎて叫びながらマガジンが空になるまで死体を撃ち続けたりしてすぐ弾切れ起こす系です、硬直して指が離せなくなるんですよねーｗ
・WoW
オーダー＆カオスがダメだった自分には重そうっていうイメージだけでまだ手を出せてない
何かの機会に触ってとっつけそうならやるかも、でもスカイリムとかオブリビオンとかまだやったことないからちょっと不安
・DQⅩ
これはなぜかどうしても合わないんじゃ……
ドラゴンボールも苦手だから鳥山さん風の絵が単純に苦手なのかも
なんだろう、別に底抜けハッピーラッキーキラキラウフフな物語でもないはずなのに、
世界とキャラクターが放つ陽の気が強すぎて、みてるとクラクラするんだ。オブラートが200枚ぐらい欲しい
・FF14
・RO
ToSまでにFF14を含めて色々やってみてそれでもだめならここに足を踏み入れそう
でもここに流れ着く前にToSが始まる気がしてる
[追記]
なんか気を悪くしたんならすまんかったけど
一番最初に書いた通り、まともに(といっても数ヶ月継続とかだけど)過去にプレイしてたのが無料で遊べた2タイトルだけの人間だし、
最近は色々試してはいるけど、別にMMO大好きで追いかけてた人間でも、濃いオンラインゲーマーでもなくて、
ただの昔触ってたMMOはこんな感じで楽しかったけど、今はあーいうのないの？って探してるだけのおっさんだからなあ。
思った以上になかなか見つからないから、なんかいいの知らない？(やっぱ金払えばあるもんなの？)って気持ちと、
同じようにさまよってる人がいたら試す試さないの参考になったりすればいいなーって思って書いてたんだけど、
そこまで月額課金やデスクトップでMMOやってないと論外扱いされて呆れられる世界だとは知らなかった。
FF11やってた金持ちのボンボンが一人いたくらいで、他に周りで月額課金のゲーム遊んでた人を一人も知らなかったから、
人口比率的にそんなもんで俺みたいな人の方が多いのかと思ってたけど、「MMO好き」な人たちの界隈じゃそんなことないんだな。素直にびっくりした。
あと、昨日から何人か引っかかってるみたいだし難民って言い方がマズかったのかなー、わがまま乞食にでもするか、別にどっちでもいい。
ノートPCだけど、大体のゲームは勝手に環境調整してくれるし、
とりあえず入れてみよう！で突撃しても別に不満を感じることなく動くから、あんまり不自由感じてなくてまだスペックを気にしたことないんだ。
黒い砂漠は例外的に画面が綺麗ですげえんだよってアチコチで言われるから、なんかある程度高いスペックで遊ばないともったいないのかなーって身構えちゃうだけ。
もうマジ最低だ。眠りが浅いせいもあるだろうが最近はほぼ毎日３時半ぐらいに起こされる。
警告しておく。デスクトップPCでスリープを使ってるやつは絶対にwin10にしたらダメだ。
ノートは知らん。
俺は情報工学系の学部を出て１０年ぐらいプログラマーをやってる人間だが、
何をしてもなおせなかった。
俺より詳しいやつなら直せるのかもしれんが、自信がない奴はやめておけ。
他の会社の同僚や友人は全員win10にしていないが、それが正解だと思う。
ちなみにググると同様の報告がたくさんあった。
調べずにアップグレードしたのは俺のミスだが、試しに使ってみたかったのと
すぐに戻せるように別パーティションにクリーンインストールして、win7とデュアルブートできるようにしてあるから
軽い気持ちで入れてみただけだ。
もう使わねーよバーカ！！ということでwin7に戻す。
ちなみに俺がやった対策は以下の通りだ。直ってないのだから、何の情報にもならないかもしれないが、一応書いておく。
電源オプションの「スリープ解除タイマー」を無効にするというやつだ。
当然直らないので、次にイベントログでスリープまわりのログを見てみた。
どうやらwin10はスリープした数秒後には必ず「システムがスリープ状態から再開されました。」という紛らわしいログが出るようだ。
最初はこれが原因かと思いいろいろと無駄な時間を費やしたが、結局これは関係なかった。
それと、スリープから復帰する時は毎回システム時刻をハードウェアクロックと同期してるログが出るが、
これは手動で復帰させた時も毎回まっさきに出てるので関係なし。
タスクスケジューラで全項目をひとつひとつ見ていったが、俺の場合は
「UpdateOrchestrator」の「Reboot」の「タスクを実行するためにスリープを解除する」
のチェックが入っていたので、外した。もちろん直ってない。
windowsアップデートが悪さしてるという報告もネットではよく見かけるが、
俺の場合はログに何も出ていないし、アップデート検知時にスリープから復帰する設定にもなっていないので、関係なし。
その他確認したこと。
自動メンテナンスでスリープ解除を許可するという項目があるが、最初からチェックは付いていなかった。
ネットワークカードからの信号で勝手に復帰するという情報もあったが、俺のNICにはそういう設定はなかった。
NIC以外のデバイスで「電源の管理」という設定があるデバイスはマウスとキーボードのみだったが、
これらはスリープから復帰する時に使ってるので、これらから復帰できなくなると利便性が下がるので、変更しない。
ここからは俺の推測だが、この問題はもう直らないんじゃないか？
なぜなら、win10が出てかなり経っており、ネットでもそれなりに言及されていることから
マイクロソフトも把握してからかなり経っているが、それでも直る気配が微塵もないからだ。
それとwin7やwin8と比べてスリープからの復帰が若干速くなったという情報も見かけることから、
スリープまわりの動作がまるっと変更されてると見て良い。
ということで寝室にデスクトップPCを置いていて、かつスリープを使う人限定だが、Windows10はおすすめしない。
追記：2016/05/09 21:02
id:enhanky すでに書いているが、タスクスケジューラの全項目をひとつひとつ確認したんだが、ダメだった。
そもそも俺のwin10には Microsoft\\Windows\Media Center が無い。
powercfg -waketimers コマンドは
になる。
スリープから勝手に復帰する原因がたくさんある中で、まさかピンポイントで正解を当てるやつが居ることにビビったわ。
いや、まだ１晩しか様子を見てないから、本当に合ってるかはわからないけど、少なくとも今日は良く眠れた。
あの「ヴぁっ」って音で起きちゃわないか怖かった。
デバイスマネージャのネットワークアダプタのプロパティの詳細設定で Wake On Magic Packet と Wake On Pattern Match っていう設定項目がEnableになってたから
Disableにしたら、いけたっぽい。
ネットワークアダプタの設定に「電源の管理」って項目がなかったから、てっきり関係ないのかと思ってた。
あと気になったブコメに返信。
Windows Updateは関係なかったって上でも書いてるのに、３時半というとこだけ見て馬鹿にしてるやつなんなの？
自動メンテナンスでスリープ解除される設定になってないって言ってるじゃん。
シャットダウンしろとか言ってるやつ。確かにSSDだから起動は速いけど、スリープからの復帰に比べたらぜんぜん遅いし、巡回してるサイトや作業途中のものを開いたままにしてたりするから、スリープが便利なんだよ。
休止状態という設定ができるのは知らなかったので参考になった。
あとマイクロソフトに言いたいんだが、何のためのイベントログだよ？！
NICが原因でスリープから復帰してるなら、ログに残せよなー。ログに残ってさえいればこんなに苦労しなかったのに。
それと、設定変更画面へのアクセスが悪すぎる。何回も見直したのに、もう例えば自動メンテナンスの設定変更画面に検索以外でどうやったらたどり着けるのかわかんねーよ。
powercfg -devicequery wake_armed ってコマンドもキーボードとマウス以外出てないからNICが原因だとすぐにわからなかったし。
というわけで、解決したっぽいけど、やっぱりwin10はおすすめしない！
追記：2016/05/13 3:30
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
