「ダウンロード」を含む日記 RSS

はてなキーワード: ダウンロードとは

2016-05-24

アダルトビデオを借りる層

ツタヤで働いてるんだけど、暖簾をくぐる客が結構いる。18と大きく書いてある暖簾だ。



これだけネット動画が散乱してる時代にわざわざレンタルするのはどういう心持ちなのか。

初めは「どうしてもこの女優のこの作品が見たい!」ってお決まりの一本があって、それがネットに転がってないのかと思ったがどうやら違ったようだ。

みな目的もなさそうにぶらぶら歩いている。夢遊病者みたいだ。目だけに性的な光を散りばめていて気持ち悪い。

とにかく、お目当てのコーナーに一直線、無ければ即退散みたいな客はいない。



あと、年齢層として若者は皆無だ。みんなオヤジだ。友達同士でケラケラ笑いながら入ってくる高校生はたまにいるけど。



多分、生活習慣を急に変えられないように、性の満たし方みたいなものも変えられないのかも知れない。

ある年齢層の人達にとっては、パッケージタイトルを流し見ながら自分アンテナに引っかかれば手に取ってみる。そしてまた棚に戻して歩き始める。

といったまさしく足を使ってオカズを探す狩猟スタイルがしっくりくるのだろう。

彼らは決してネットが苦手なのではない。ただ、「巨乳 女子高生 盗撮」みたいなワードポチポチ打ち、瞬時にサムネが羅列されるというのは彼らのスタイルではないのだ。

10年後か20年後、「なんであいつわざわざ女優名で検索してダウンロードなんかしてんの?○○のがずっと楽なのに」って言われる日が来るかも知れない。

俺もアダルトコーナーを徘徊するオヤジ達同様、その新しい波に乗れる自信がない。

2016-05-20

任天堂映像戦略から妄想を膨らませる

スプラトゥーンCGアニメは非常にありそうです、シオカラーズEDダンスする姿が目に浮かびますもん(笑)

ただ映像作品を作って新作ゲームタイアップするだけなら、色々挙げられたように、色々やってるんですよね。

なので、もう少し予想を膨らまして、こんなのが面白いかも、を考えてみました。



ずばり「映画館にアミーボを持って行こう企画」です。



ポケモンだと、もう十年ぐらい映画館ゲーム機ソフトを持って行くと新しいポケモンが貰えるんですよね。

なので、その応用で映画館劇場内に「アミーボをタッチするとアミーボに特別データ記憶させる機械」を設置する、なんて楽しそうです。

これの利点は家庭用ハードリリースされているソフトでも、映画館に行ったこととの連動が出来る事ですね。

スプラトゥーンのアミーボを持って映画館に行って、専用の機械にアミーボをタッチして、特別コスチュームをゲット! とかどうでしょう

(え?、映画の前売り券にダウンロードコード付ければ良い? あー、それもそうかも)



で、ここからさらに、予想を大きくして、

任天堂映画でアミーボに記録したデータを遊ぶ専用の総括ゲーム」が出る事を予想します。(我ながら、予想がデカすぎますが)

アミーボは、一つのソフトデータしか保存できないという特性がありますよね。

からスプラトゥーン映画を見に行って、ガールのアミーボに特別データを保存したら、

次のマリオ映画を見に行ったときに、ガールのアミーボを使って、マリオ特別映画版再現コースダウンロードできないじゃないですか!?妄想妄想を上重ねしています

もちろん、マリオ映画マリオファミリーのアミーボを使えっていうのがスジですが、そこはわざわざ球団を売って作った資金です、どでかく行きましょう。

それがズバリ任天堂映画でアミーボに記録したデータを遊ぶ専用の総括ゲーム」こと



ミートモfor任天堂ムービー」です。



このゲームは、ミートモの家庭用ゲーム機版ですが、アミーボで映画館から持ってきた「映画見たよデータ」を使って遊ぶゲームです。

そう「映画見たよデータ」がある人しか、遊べないんです。

から逆に言えば、ネタバレし放題!

Miiの部屋には、見た映画DVD(のポリゴンモデルです)が蓄積されていって、

そのDVDゲーム上で使うと、Miiが「スプラトゥーン映画シオカラーズライブシーンはどの曲が格好よかった?」みたいなネタバレ質問をしてきて、

答えると、フレンドの答えも見れちゃう



なんて感じで、ゲーム映像の融合がアミーボを介して行われたら面白いなあ、

と思って予想を膨らましてみました。


---

とうとう来た任天堂IP映像コンテンツ化を、今のうちから予想しておく!

http://yamanashirei.blog86.fc2.com/blog-entry-2104.html



コメント欄に書いた内容のコピペ

考えてて楽しかったので、忘れないようにするため、はてなに持ってきとく。

2016-05-17

早朝にスリープモードPCがピボッ!という音、で起動音。その後、静かになった。

もしかしてちょっと前に増田に出てたWindows10記事のやつ?でもWin7から上げてないぞ?もしや勝手更新された?とか思いながらも寝てた。

で、今起きて確認

Windowsを再開しています…のメッセージ再起動がかかってたわけではないようだ。

が、スリープモードではない?休止状態からの復帰の動きのような。

もちろんOSも変更してない、7のままだ。

ただ、Windows Updateにいろいろパッチダウンロードされているよう。

結局、早朝の起動音はなんだったのか。

明日の朝同じ事が起こらないことを祈る。

2016-05-15

小説練習

 元上司とのつきあい旦那よりも長い。

 新卒で入った会社歓迎会関係を持って以来ずっと。

 細心の注意を払っているからバレることはまずない。そのためだけのメールアプリフォルダの奥深くに隠しており、読み終えて返信したら履歴ごと削除する。いつも受信欄も送信欄も空っぽ。もしたずねられたとしてもゲーム広告をさわったらまちがってダウンロードしたけどめんどくさいからそのままにしてるwとごまかす予定。

メールを開くのはひとりで車に乗った時だけ。車に乗ってメールを読み返信し履歴を消したことを確認してからからでる。これは彼氏に教えてもらったルール彼氏トイレの中でしかアプリを開かないそうだw

会うのは隣の市の国道沿いにある24時間営業新古書店駐車場。そこで待ち合わせ5分歩いたところにあるホテルに入る。愛を交わしたあとそれぞれの車でまた移動する。

旦那とも定期的に相手をする。早いので楽だw

家事はそこそこのペースでやっていると思う。ときおりどうでもいい不満を口にしてみる。そうすると旦那家事負担微妙に増える。それも楽でいい。

子供もできた。どちらの子かはわからないw

幸い私に似たし、旦那と彼はごまかそうと思えばごまかせる程度には顔が似ている。

今更、離婚再婚などと面倒くさいことをする気はない。ふたり関係は平凡で穏やかな生活の中にある少しのスパイス。私も彼もその関係で十分だと認識している(はず)。

ところがこのまま幸せに終わるはずの"日常"は突然終わりを告げる。 ある日突然旦那弁護士とともに浮気証拠をつきつける。かなり用意周到に準備していたためにあっという間に家から追い出された。彼も同様の目にあってるようだ。

なぜバレたの? 家から出て行く日に思いきってたずねてみた。

答えは子供だった。ベビーシートで寝ていると思っていた子供メールの内容をこっそり覗き見していたらしい。メールの内容は断片的にしか読めなかったそうだけど、機嫌がいいときしかでない鼻歌を歌っていたから印象に残っていたそうだ。

それがこの歌です。お聞きください。

https://www.youtube.com/watch?v=PImjio4EPgw

 

2016-05-14

chrome使い続けても爆速を維持する方法

chromeインストすんじゃん?

爆速じゃん?

使い続けるじゃん?

重くなってくるじゃん?

解決方法ググるキャッシュを削除だのなんだのどのサイトも言ってるけどそれやっても改善しないじゃん?

 

で。

気づいたんだけど、インスト直後にキャッシュしない設定をしてやれば爆速維持できんじゃね。

シークレットモードブラウジングすればいつだって軽いじゃん。

ようは拡張機能やらキャッシュやらが足引っ張ってるわけだからその片方を最初から切断してやる。

そしたら爆速維持できんじゃね?

 

問題はページ閲覧の度に画像やらをダウンロードするからネットワークに負荷かけるってことなんだけど、

まあただのネットサーフィンなら誤差の範囲だよね。

 

ちなみにキャッシュしない設定は F12 → Networkタブ → disable cache にチェックな。

 

これさえやればおまえのchrome爆速だぞ^^

2016-05-11

おすすめ音楽を教えてほしい

みんなはいま何で音楽を探しているのだろうか?soundcloudは使ってるけど、そういうSNS(?)の類って結局まずは趣味が合う人をフォローしないと意味がない。

で、趣味が合う人がみつからなくて迷子趣味が合う人ってどうやって探すんだ?

そんなに音楽が好きなわけでもないので、時間をかけて探す余力・財力はない。

あと、ネットでたれながして聞くよりはちゃんとアルバムがほしい。

自分が好きなのはradioheadコクトーツインズmy bloody valentineアソビ・セクス最近のものだとミツメ、tychoが好き

このアーティストに辿り着いた経緯ははっきりしていて、radioheadは昔好きだった新居昭乃が好きと発言していて聞きだした。新居昭乃小学生のころ好きだったアニメ主題歌を歌っていた。

アソビ・セクスitunesの日替わり無料ダウンロードみたいなので気に入った。それの流れでシューゲを聞いてみて、マイブラコクトーけが残った。

ミツメとtychoは友達が聞いてた。

いまはアーティスト発言を追えるほどの熱量音楽に向かない。人におすすめを聞きたい。

要するにわがままなんだが……。

特にアソビ・セクス好きな人がいたら他に何を聞いているのかを知りたい

WiFiフリースポットが近所にあって捗る

夕食食べるついでに重そうなもんダウンロード、とかのサイクルで回せそう

7GB制限とかあんまり意識せずに済むな…

ってよく考えたらネットカフェ行った方が安いし長時間だった

しろまり行かない飯屋にWiFi目当てで行くとか集客されてた

モスおいしかったけども

2016-05-10

【尋】おすすめエロ

1. あんまん (http://adultrank.x.fc2.com/)

FC2アダルト動画ランキングをまとめているサイト属性(OL盗撮、ハメ撮り...etc)ごとに動画を探すことができ、自らの性癖に合った動画を発掘することができる。とりあえず手っ取り早く抜きたいという紳士には「総合カテゴリお勧めしたい。ランキングの集計期間を新着、2日間、1週間、年間、全期間などから選ぶことができ、最近出てきた良エロ動画から殿堂入り動画(昔から人気)まで手軽に探すことができる。このサイトの1番の強みは、多くの動画が「はめ込み型」で掲載されているという点である。つまりどういうことか、それはFC2唯一の欠点である「視聴回数制限」を気にせずに何度も異なる動画再生して抜き動画を選別できることを意味する。有料会員向けの動画は残念ながら(当然というべきか)再生することが出来ない。(最近ランキングに登場する有料会員向け動画が増えてきており、動画探しに支障をきたし始めている。すんでのところで留まっているが、そろそろ有料会員になりたい欲求が爆発しそうである。)

2. Xvideos ダウンローダー(http://dl-xvideos.com/)

今度はXvideosダウンロードランキングまとめサイト。1時間24時間、30日間で集計期間を選ぶことができる。あんまんのように属性性癖動画を発掘することはできないが、このサイトあんまんとは異なる強みを有している。(周囲に人がいないのを確認した後に)サイトを開き、集計期間「1時間」の列にある動画を上からスクロールして確認していって欲しい。ラッキーであれば、かなりグレーな、それか完全にア○トな動画を見つけられることができる。どのような動画なのかは実際に自分の目で確認してくれ。ラッキーの頻度は高く、2~3日続けて確認すれば必ず1つは見つけられるのではないかと思う。

私が頻繁に(毎日)使用しているのは、主に上記の2サイトである。こうやって匿名ダイヤリーに書くのは初めてで、はてな記法も知らず、非常に読みにくい文章になってしまったことは申し訳なく思う。

そもそも、何故このような投稿に至ったかというと、「良いものシェアしたい」という単純な思いつきと、

他に良いサイトがあれば是非みんなに教えていただきたいという想いからです。

この駄文を読んで、少しでもためになったという人、こんなサイト知ってたよという人、誰でも良いのでおすすめエロサイト教えてください。

トラックバック/コメントおすすめエロサイトURL書いてくれるとめちゃくちゃ喜びます

----------------------------------------------

追記:

トラバ/コメントありがとうございます。1つ「まとめさいと」という書き方に語弊があると感じましたので、訂正いたします。これら2つのサイトは、FC2,Xvideosランキング(内1つは日本の?ダウンロードランキング)を自動的に反映してるものであり、個人が転載しているものではないということです。

2016-05-08

[]「お漏らし百合

物静かで友達も少なくて1人で本を読むのが好きなタイプ大学生のお姉さんと、

生意気で覚えた知識を披露したくてしょうがないちょっと調子に乗ってる系の小学生女の子が、

たまたま二人でお出かけすることになり、

スマホの道案内を使って先導する小学生女の子だったが、お手洗いに行きたい、ということが中々言い出せず我慢しきれず道でお漏らしをしてしまい、

お姉さんに粗相の後片付けをしてもらった上に、年上なのに気遣いができなくて申し訳なかった、とお姉さんに謝られて、

人間としての器の大きさとか、自分がまだまだ子であることを自覚した小学生女の子が気を許し、

二人は末永くラブラブする場合




大学生のお姉さんは松井恵理子

小学生女の子照井春佳で決まりです!



アイマス声優になったのは偶然なので、プロデューサーの人は気にせずアイドル名前を上げてもかまいません。(つうかアイマス声優いねん! ラジオも山ほどやってるから自然と知る機会が増えるしさあ)

未確認で進行形姉妹になったのも偶然ですから荒井チェリーファンも気にせず三者三葉声優をあげてもかまいません。

りりくる声優になったのも偶然ですが、今WindowsないのにDMMで購入してダウンロード中なのと関係はありそうな気がしなくもないです。

2016-05-07

ガルフレとナナシスダウンロードしてみた

これで追いかけるスマホ音ゲーが五つになった

大丈夫なのだろうか

2016-05-05

絵師漫画家名前ググる公式サイトより上位に違法DLサイトが表示される件

そりゃ自分商業漫画無料ダウンロードできるんなら製品版買う必要性が無くなる訳で

グーグル絵師名前でググったら確実に無料漫画がヒットしない様に努める必要があると思う。

著作権的な意味で。

この前知り合いの絵師が言ってたけど、言えば一覧から消してくれるけど、でも1週間もすれば別の違法DLサイトが上位に来るから

イタチごっこで諦めたって。

キーワードで上位に来ない様にする努力グーグルがやらないのか、それともそういう違法サイトが全くといっていいほど摘発されてないから

いずれにせよ、この両方をやられるべきであって、検索しても違法サイトに繋がらない状況を作ってやる事で

少しは絵師漫画家お金が入ってこれば良いなと思う。

2016-05-04

Windows 10アップグレードが終わらない

2・3年使ってなかったWin7PCWindows10インストールしている

が、かれこれ4・5時間、まだ終わらない

進んでいるようではある、少し前にライセンス使用許諾書みたいな画面を見た

が、今現在更新プログラムダウンロードしています」「更新プログラムをチェックしています 0%」から画面が動かない

これには数分かかることがありますとあるが余裕で30分位は経過している

同じ画面がずっと続くと進んでいるのか分からない、ひょっとして固まってるのか?と思ってしま

進捗を見せてくれたら安心するのに

そこまで低スペックPCでもないと思うのだが

ああもうイライラする

追記

Windows Updateが遅い、進まない、終わらない、失敗する問題の解決方法

直近の不具合の報告事例ずばりだった

なんか疲れたのでもうやめることにする…

2016-05-03

http://anond.hatelabo.jp/20160502205737

モーターとレーザーの消費電力など合わせると音楽データダウンロードの300倍であるのをなんとかしてから言って欲しい

2016-05-02

ポータブルCDプレーヤー市場復活してくれ

まずはAmazonポータブルCDプレーヤーカテゴリを見てくれ。

https://www.amazon.co.jp/b/ref=s9_acss_bw_ct_cepetile_ct5_a4?_encoding=UTF8&node=3481221&pf_rd_m=AN1VRQENFRJN5&pf_rd_s=merchandised-search-4&pf_rd_r=FQNJSVADJK842K35B9XT&pf_rd_t=101&pf_rd_p=312030149&pf_rd_i=3371411

完全に市場が死んでる。

大手オーディオメーカーは何年も前に撤退して、残ってるのは所謂安物製品だけだ。


今こそ手軽に高音質で聴けるポータブルCDプレーヤー必要だと思うんだが、いかがだろうか。

CDなんて時代遅れかいうけど、CDというメディア現在もっとも手軽に高音質が楽しめるメディアだと思うんだけども。

PCオーディオ環境を整えたり、ハイレゾ対応ウォークマンやらを買ってハイレゾを購入するなんてことをするよりも、ちょっと良いCDプレーヤーヘッドホンイヤホン聴く方がかえって良いのではないか。

10年前に売ってたソニーCDウォークマンの音質面でのコストパフォーマンスに敵うデジタルオーディオプレーヤーなんてほとんどない。

2万円かそこらであんな高音質を楽しめたんだよ。


現在の状況はなんだ。

最速で新曲聴くためにCDフラゲするものの、結局CD聴くことはせずわざわざスマホウォークマンに取り込んでから聴く

レンタルが開始されるまで待って借りて取り込んで聴く

レンタルじゃメジャーな物しか置いてないのでマイナーものダウンロードするかCDを買うか。

あるいはYouTubeストリーミングサービスで楽しむか。

良い音質で楽しみたいからちょっと高いウォークマンやらプレーヤー買って高い金払ってハイレゾ聴く(これもマイナーもの配信されない)。

PCオーディオをがっちり整えて、CDから取り込んだデータ再生する。


そんなんするよりそのままCD聴けば一番高音質なんじゃないか?

今の状況ってすごいヘン。

CD聴く」という文化は死んでるのに、CDがないと始まらないような環境音楽を聴いてる人ばかり。

CDってまだまだ身近にあるよね。ブックオフとかで安く手に入るし。


から一周回って最近普通にCD買ってCD聴くようになった。

10年前のソニーCDウォークマンで。

店頭コンサート会場で買ったのに家に帰って取り込むまで聴けないなんてこともないし。

家で聴くのもCDで聴いた方が良いし。

意外とポータブルCDプレーヤーって便利よ。


(追記:ちなみに今の技術ならCDケース並みのサイズプレーヤーを作ることは普通に可能らしい。あとCDハイレゾ両方再生可能なタイプとか欲しい。)

C言語


Gnu pack

Develop版 インストール

C直下gnu pack のユーザーガイドHTML

ダウンロードする gnu pack devel-11.0 exe

三万から五万に素数がいくつあるか

gccmeadowを使う

ホームディレクトリにCというのを作る

mkdir と打つ

その後Prog1 というのを作る

CD で移動

Prog1をカレントディレクトリに。

home/c/plog1/01


emacs & と打つ


#include <stdio.h>

main() {

Printif("hello.");

}

と打つ

実行画面に $ gcc -o hello hello.c. ドルマークは一つだけ。

$ ./hello

hello

演習1

学籍番号と氏名を表示させるプログラムensyu1をつくる。

実行形式→Ensyu1cをつくる 文字化けがあるので シフトJIS

エスケープシーケンスに注意 使う文字の前に入れるらしい


プログラム


演習2

プログラムensyu2c.を作成

Ensyu2という実行形式ファイルコンパイルせよ


エスケープシーケンス. ¥n を利用して

アスキーアートを作れ


-----------

中間テストまではメイン関数のみ その後は自分関数をつくる

2016-05-01

上司

スマホなんて絶対贅沢品」といっていた上司を説得して、スマホに変え、見事にスマホ中毒になった。

電車の中でアプリゲームしてるやつって子供っぽい」と言っていた上司スマホにツムツムをダウンロードし、見事に上司はツムツムにハマってランキング上位に入るようになった。

今度は「ディズニーランド魔法にかかるやつマジウケるわ」とdisってくる上司と今度ディズニーランド行く。絶対ハマるだろ。

2016-04-30

平成26年青果卸売市場調査報告

id:damae 日本ではかろうじてアブラナ科が対抗できているといえようが(日本人ダイコン大好きだよなあ)、世界的にはナス科がすでに支配している。トマトジャガイモという双璧を崩せるライバルがいない

確かに。日本におけるアブラナ科地位確認してみよう、と思い立ったので調査


平成26年青果卸売市場調査報告

http://www.e-stat.go.jp/SG1/estat/List.do?lid=000001140076

から「全国及び主要都市野菜卸売数量・価額・価格」をダウンロード。主要49品目(47品目+その他の菜類+その他の野菜)を科別に集計してみた。


品名 価額(億円) 数量(万t) kg単価 金額 量%
ナス科 4548 177.2 257 21.0% 16.5%
アブラナ科 3579 369.8 97 16.5% 34.5%
(ユリ科) 3087 157.5 196 14.3% 14.7%
ウリ科 1906 73.6 259 8.8% 6.9%
(その他野菜) 1780 33.9 526 8.2% 3.2%
キク科 1533 75.9 202 7.1% 7.1%
(きのこ派) 1165 25.6 455 5.4% 2.4%
セリ科 993 74.7 133 4.6% 7.0%
アカザ科 590 12.1 488 2.7% 1.1%
マメ科 507 7.1 712 2.3% 0.7%
ヤマノイモ 453 12.8 354 2.1% 1.2%
ヒルガオ科 407 21.6 188 1.9% 2.0%
スイレン 249 5.1 486 1.2% 0.5%
イネ 240 10.2 235 1.1% 1.0%
ショウガ 221 3.7 605 1.0% 0.3%
(その他菜類) 189 5.4 349 0.9% 0.5%
サトイモ科 179 6.2 287 0.8% 0.6%
ウコギ科 17 0.3 546 0.1% 0.0%
総計 21642 1072.7 202 100% 100%


まさかナス科1位。数量ベースだとアブラナ科が2位ナス科ダブルスコアの圧倒的1位なのだが、金額だとこんなことに…。まさに

id:yuru_harukaze 好きな野菜ランキングならナス科の勝利じゃない?生産額でもナス科な気がする。流通量なら圧倒的にアブラナ科っぽい、1こが重いから

という予測通りの結果。

ま、まあ「その他野菜」や「その他菜類」がこれだけ大きいと分からないよね、とお茶ツバキ科)を濁してみる。



FAQ
  • id:uunfo エングラーやクロンキストのユリ科みたいな大雑把な分類使うのもうやめて
    • 最初そうしようかと思ってたんですが、シェアがどっちも14%になったんでついそのままにしてしまいました(謎言い訳)。下に品目別の表を付けたのでそれでご容赦ください。

付録、品目別ランキング

====

というわけで

単位でなく品目でのランキングです。参考として、価額順位・数量順位・単価順位も載せています

その他が1位ですが、仕様です


品名 価額(億円) 順位 数量(万t) 順位 kg単価 順位
その他の野菜 V.A. 1779.9 1 33.9 10 526 15
トマト ナス科 1545.7 2 50.4 8 307 30
きゅうり ウリ科 1461.6 3 49.4 9 296 31
たまねぎ (ヒガンバナ科) 1286.4 4 115.3 2 112 44
キャベツ アブラナ科 1247.3 5 141.3 1 88 47
レタス キク科 1114.3 6 60.8 7 183 42
ねぎ (ヒガンバナ科) 1013.4 7 31.1 11 325 26
なす ナス科 813.1 8 25.1 12 324 27
だいこん アブラナ科 799.5 9 104.4 3 77 48
ばれいしょ ナス科 789.0 10 72.8 5 108 46
にんじん セリ科 754.1 11 68.2 6 111 45
ミニトマト ナス科 666.8 12 11.7 20 572 12
ピーマン ナス科 638.5 13 16.4 15 389 22
ほうれんそう (ヒユ科) 590.2 14 12.1 19 488 17
はくさい アブラナ科 553.8 15 86.4 4 64 49
ブロッコリー アブラナ科 504.4 16 15.8 16 319 28
しいたけ (シメジ科) 461.1 17 5.1 30 913 5
やまのいも ヤマノイモ 453.3 18 12.8 17 354 24
かぼちゃ ウリ科 443.9 19 24.3 13 183 41
かんしょ ヒルガオ科 406.7 20 21.6 14 188 40
しめじ (キシメジ科) 348.0 21 7.7 25 454 19
アスパラガス (キジカクシ科) 319.2 22 3.1 34 1043 2
ごぼう キク科 306.1 23 12.7 18 241 37
にら (ヒガンバナ科) 300.0 24 5.8 27 521 16
えのきだけ ニレ科(誤) 287.5 25 11.2 21 257 35
れんこん (ハス科) 249.4 26 5.1 29 486 18
こまつ アブラナ科 241.0 27 8.4 23 285 33
しょうが ショウガ 221.1 28 3.7 32 605 10
その他の菜類 V.A. 189.0 29 5.4 28 349 25
さといも サトイモ科 179.0 30 6.2 26 287 32
スイートコーン イネ 177.9 31 8.5 22 208 38
にんにく (ユリ科) 167.9 32 2.3 35 746 7
えだまめ マメ科 144.6 33 2.2 36 653 9
さやいんげん マメ科 143.8 34 1.9 38 766 6
さやえんどう マメ科 129.1 35 1.3 43 1025 3
セルリー セリ科 114.2 36 4.7 31 243 36
かぶ アブラナ科 103.9 37 8.3 24 125 43
ししとうがらし ナス科 94.8 38 0.9 45 1092 1
ちんげんさい アブラナ科 90.5 39 3.2 33 281 34
しゅんぎく キク科 88.9 40 1.6 41 568 13
みつば セリ科 78.6 41 1.3 42 597 11
なめこ (モエギタケ科) 67.9 42 1.7 39 402 20
たけのこ イネ 61.9 43 1.7 40 374 23
そらまめ マメ科 48.2 44 1.2 44 402 21
パセリ セリ科 46.4 45 0.5 48 955 4
実えんどう マメ科 41.3 46 0.6 47 728 8
カリフラワー アブラナ科 38.7 47 1.9 37 199 39
ふき キク科 23.9 48 0.8 46 309 29
うど ウコギ科 16.5 49 0.3 49 546 14


http://anond.hatelabo.jp/20160428222726

2016-04-26

anond:20160426145507 の続き

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

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

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

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

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

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

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

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

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

他の選択肢

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

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

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

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

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

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

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

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

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

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

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

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

2016 年 4月 Insane Coder

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

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

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

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

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

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

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

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

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

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

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

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

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

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

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

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

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

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

さらに

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

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

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

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

2016-04-25

スマモバ最悪

都内23区でも速度出えへん。

ダウンロード常時1Mbps以下。

pingも遅い。

アップロードはそこそこ早いが、wimax未満。



解約するいうたら、月額使用料と端末代金と違約金で7万くらいする。

まあ、こんなとこに3年も払うのばかばかしいから解約するけど。

ゴミですわ。



スマモバは絶対やめた方がいい。ちょっと冒険しすぎたわ。

サイトからしてちょっと怪しいけど・・・

皆さんお気をつけて。

2016-04-24

http://windows.microsoft.com/ja-jp/eos

コンテンツ ペインまでスキップ

Windows XPサポートは終了しました。お使いの PC安全を保ってください。詳しくはこちら

閉じる

Windows XPサポートを終了させていただきました。

Windows XPサポートセキュリティ更新プログラム等の提供が終了しています。2014 年 4 月 9 日 (日本時間)以降、このセキュリティ更新をせず PC を利用し続けることは、PC脆弱性を解決しないままで使用し続けることになり、セキュリティ上、危険状態になります。最新環境への移行をご検討ください。

Windows XP サポート終了とは何ですか。

Windows XP 向けのセキュリティ更新プログラム有償サポート技術情報アップデートなどの提供が終了します。Windows XP脆弱性発見された場合でもセキュリティ対策などのサポートは行われませんのでご注意ください。

また、この日以降、Windows XP から Microsoft Security Essentialsダウンロードすることもできなくなります

Windows XP を使い続けるとどうなりますか。

サポート終了後も Windows XP を搭載したコンピューターを引き続き使うことはできますが、お使いのコンピューターセキュリティウイルスリスクに晒される可能性が高くなる場合がありますInternet ExplorerWindows オペレーティング システムサポート ライフサイクルを引き継ぐので、Windows XP 上の Internet Explorer 8サポートも終了となりますWindows XP PCインターネット接続し、Internet Explorer 8 を使って Web サーフィンをする場合PCセキュリティの脅威にさらされる可能性があります。また、今後はソフトウェア開発会社ハードウェア製造元が新しいバージョンWindows に合わせて製品を開発するため、Windows XP では動作しないアプリデバイスが増えていくと予想されます

使っている Windowsバージョンサポートが終了するとどうなりますか。

今使っている Windowsバージョン確認する

これからコンピューター保護するには、どうすればよいですか。

サポート終了後もお使いのコンピューター保護するには、2 つの方法があります

現在PCアップグレードする

ほとんどの旧型のコンピューターでは、最新バージョンWindows である Windows 10 が動作しません。PCWindows 10システム要件を満たしているかどうかを確認するには、Windows 10仕様についてのページをご覧になることをお勧めします。詳しくは、FAQ をご覧ください。

新しい PC の購入

お使いの PCWindows 10 が動作しない場合は、新しい PC の購入のご検討お勧めします。魅力的な最新 PC を数多くご用意していますので、ぜひお確かめください。これまでよりも性能が向上し、軽量化され、デザインも洗練されていますが、平均的な価格12 年前の一般的PC よりも大幅にリーズナブルになっています

最適な PC を見つける

ファイルフォルダーなどの移動が無料

Microsoft は Laplink とパートナーシップを結び、パソコンデータ引越し eXPress提供しています。このツールは、古い Windows PCファイルフォルダーなどを選んで新しい Windows 8.1 または Windows 10 PC転送します。

開始する

もっと詳しく

中堅中小企業向け Windows XP

Windows XPサポートは終了しましたが、ビジネス保護継続する必要があります

企業向け Windows XP

Windows XPサポートは終了しましたが、会社保護継続する必要があります

Office 2003 のサポートを終了させていただきました。

Office 2003 のサポートの終了について詳しくは、こちらをご覧ください。

お役に立ちましたか?

皆様からのご意見は、このサイト改善に役立ちます

このページを共有する

みんなにも教えてあげてください。このページを友だちや家族と共有しましょう。

Facebook

Twitter

Facebook でつながる

FacebookWindows情報を得る

その他の Microsoft サイト

Office

Office

Surface

Surface

Lumia

Lumia

Xbox

Xbox

Skype

Skype

OneDrive

OneDrive

Outlook.com

Outlook.com

MSN

MSN

Bing

Bing

Microsoft ストア

Microsoft ストア

対象ユーザー

開発者

IT プロフェッショナル

小規模企業

大規模企業

学生

人気のあるダウンロード

Windowsダウンロード

Windowsテーマ

壁紙

フォト ギャラリー

ムービー メーカー

言語パック

Windows サービス パック

よく行われる検索

Windows 10 アップグレード

Windows 10 FAQ

Microsoft アカウント

スタート メニュー

アプリ

Internet Explorer 11

Windows 10 の新機能

無料ウイルス対策

インターネット ブラウザー

Continuum and Touch

Wi-Fi センサー

最新情報

Windows Insider Program

Windows ブログ

Windows 10プライバシー

製品情報

Windows 製品

Windows 10

Windows デバイス

Xbox アプリ

Microsoft Edge

Windows アプリ

Hotmail

Microsoft Security Essentials

サポート

Windows 10 サポート

Windows Phone サポート

サポートに問い合わせる

シアトルから

日本地域の変更


© 2016 Microsoft

免責事項利用規約商標プライバシーCookieサイト マップ

http://www.update.microsoft.com/windowsupdate/v6/thanks.aspx?ln=ja&&thankspage=5

更新プログラムの入手にこのサイトをご利用いただきありがとうございます

このサイト使用するには、Microsoft Internet Explorer 5 以降が必要です。

ブラウザを最新バージョンアップグレードするには、Internet Explorer ダウンロード Web サイトを参照してください。

別の Web ブラウザ使用する場合は、Microsoft ダウンロード センター から更新プログラムを入手するか、自動更新使用することで、優先度が高い最新の更新プログラムが常に適用されるようにすることができます自動更新有効にするには、次の手順を実行してください。

[スタート] ボタンクリックし、[コントロール パネル] をクリックします。

コントロール パネルクラシック表示にしているかカテゴリ表示にしているかに応じて、次のいずれかを実行します。

[システム] をクリックし、[自動更新] タブをクリックします。

[パフォーマンスメンテナンス] をクリックし、[システム] をクリックして、[自動更新] タブをクリックします。

必要オプションクリックします。自動更新オフになっていないことを確認します。

2016-04-23

久々のXP

IE7googleとか開けない

温情してくれるのはyahooぐらい

ブラウザダウンロードができない

msのページではpc買い換えろって出てる

web業界死ね

http://anond.hatelabo.jp/20160423084419

勝手動画再生されると、余計なもんダウンロードさせようとするんじゃねーよ!と速攻停止ボタン押すかページから離脱する

回線が細かった時代の名残の癖だな