  |
はてなキーワード: STATEとは
○朝食：ウイダー
○昼食：おにぎり三つ（梅、梅、鳥五目）（ごめん、二つにしてサラダ買えってアドバイスを無視ってしまった。理由は朝寝ぼけていてルーチンで行動してしまった、明日から気をつけます９
○調子
むきゅー。
今日は深夜に放送されたE3のブリーフィングの感想を書きます。
念のため言うと、僕はXboxOneは日本のDayOne組なので、Sやスコルピオに関しては買い替えという観点から感想を書いてます。
従来機がモデルチェンジ。
動画の4k対応は残念ながら、僕の持ってるテレビは対応してないし、魅力は感じない。
HDRの方は4k対応じゃなくても恩恵があるみたいだけど、対応ソフトがどれぐらいかとかを考えると、さすがに買い替えの理由にはならないなあ。
小型化も、据え置き機で、もう置き場を確保している以上どうでもいいし、電源内蔵も同じ理由でどうでもいいな。
というわけで、マイナーバージョンアップって感じで、さすがに買い替える理由にはならない感じです。
「お前の国が気に入らないから売ってやらん」と言われてるものを真面目に見て「面白そー」とか思えるほど豪胆じゃないっすわ。
とか思ってたけど、動画見ると普通に面白そうだし、マーカスも出るみたいだし、海外版買おうかなあ。
DL版ならお手軽購入できるらしいけど、ここはパッケージ版を輸入するのも経験として面白そうかも。
何にしても、日本語字幕つけてくれて本当にありがとうございます。
えーっと、1のラスボスだっけ？
なんかあんまり印象が濃いキャラではないけど、KIのあの濃い連中に対抗するためには、ローカスト側じゃないといけないから、致し方ないのかなあ。
レア社からラッシュ、Haloからアービター、ギアーズからラーム将軍。
ふうむ、Fableからテレサとかどうですかね、え？ もうブランド崩壊？ ぐすん。
モータースポーツの方は、ガチレースゲーで僕には難しすぎるけど、こっちの方は僕でも出来るカジュアル感が魅力なので、砂漠や水場などシチュエーションが増えるのは、本当に魅力的だ。
そうえば、Horizon2のDLCのストームアイランドをまだやってなかったから、それで予習するのも良いかも。
テンションアーップ！
ロボと協力するTPSかな？ と思いきや、アスレチック要素もあるみたいで、中々面白そうだ。
いやもちろん、オーソドックスなTPSでも良いんだけど、仲間？ らしきコアをもったロボの育成とか、教育とか、そういう要素があると楽しそうだなあ。
みたいな感じ？
なんか色々発表されたけど、イマイチ理解できてないな、4亀とかゲームウォッチとかが記事にして欲しい。
コミュニティは夢が広がるね、日本でも細々と少ないながらもファンはいるわけだから、それなりには盛り上がりそうだ。
PC版、PE版、360版、One版のクロスプレイ化ってことか！
これは凄いな。
凄いけど、別にサーバーを立てたりしないといけないのかな？ ちょっとその辺の翻訳が分かりづらくて理解できなかった。
今までXboxOneを持ってて、このゲーム日記を読んでる人とかいないだろ、と思い込んで交流企画をやってこなかったけど、
さすがにマイクラが動く物を持ってない人は、この日記を読んでないだろうから、マイクラで交流企画とかやっても面白いかもね。
（※誤解してた見たいです、追記してます）
……全く興味がわかないけど、選択肢が増えるのはいいことだね。
ただ多分僕が住んでる国が気に食わないから、このサービスは利用できなさそうだ。
なんか最早「先輩」呼びされるようなゲームが幾つかある気がするゾ。
あの、こういう、精神病らしきものを題材にしたゲームは色々思い出してツラくなるので、プレイしたくないです。
と、毎年毎年言い続けているので、いい加減ゲームがプレイできる程度の英語力を身につけるべきな気がしてきた。
ゲームを遊ぶために英語を勉強するってのは、中々皮肉な気がしなくもないが、ローカライズをただ待っているのも無駄な気もしてきた。
伊織のプロデューサーが出たということは、765プロのアイマスがXboxにお帰りなさいする日も近い。（近くない）
要するに、ファーストタイトルのDL版は今後Win10版とXboxOne版のセットが基本になるよ、って感じかな？
ユーザー目線では良いことしか言ってないので、素晴らしい試みですね。
ふわああああふわふああああああふわああああ。
なんじゃこりゃ！
滅茶苦茶メチャクチャ楽しそうじゃんか！
ヘッドフォンを装着してからBGMが壮快になる演出たまらんな。
面白そうだけど、なんとなく、本当になんとなくだけど、おま国されそう。
1がおま国なんだっけ？
と思って今調べたら完全版はスチームで買えるのか。
にしても、デッドラ4といいゾンビ続くね。
ふわあああああふわあああふわああああ！
本当に、本当に、ありがとうございます！
ブルート好きなんですよ！
あとなんか、マンティスの小型版みたいなのテンション上がるわあ。
どの年代なんだろう、人型兵器いるってことは、Halo4以降は確定かな？
スピリットオブファイアが漂流した先で戦うのかなあ、って予想してたけど関係ないのかな？
いやー、面白そうだ。
実質世代交代なんかなあ？
日本マイクロソフトに期待してもしゃあないので、気長に待つなり、輸入の手段を探すなり、今のうちから心持ちをしっかりとしておこう。
Win10
Gear VR
ガッカリです。
ガッカリだし、そもそも、この話って4月ぐらいに普通にニュースになってなかったけ？
（いや別にニュースになってたことを発表しちゃいけないわけじゃないから、問題ないんだけど、なんか早とちりで、ぬか喜びしてしまった）
「OCamlでは」普通に副作用を使うライブラリしかないからスケールしない、って書いてあるのに
なんで勝手に一般化して、Haskellとかでもスケールしないことにしたいの？ 本当に牽強付会のオンパレードですね。
http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158
＞OCaml の全ての GUI ライブラリは状態は副作用を使うことを前提にメインループが設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体を自分で書く事になり、一般的にはスケールしません。Haskell の GUI ライブラリでは普通は状態は State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリを OCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用的意味があるとは思えませんが。
kenokabeさんは故意か無意識か、自分の有利なように論文を曲解していますが、
「面倒なんで全部訳しませんが」と言ってる部分に、氏には都合の悪い真実が書かれていますね。
＞Conventional imperative programming captures these dynamic values only indirectly, through state and mutations.
「伝統的な命令型プログラミングは、これらの動的な値を状態と変化を通じて間接的にしか捉えていません」
これのどこをどう読んだら「状態渡しはスケールしない」になるんだ……
ひょっとして状態渡しをモナド化したのがStateとか、基本的なことを全く理解していない？
http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158
「OCaml の全ての GUI ライブラリは状態は副作用を使うことを前提にメインループが設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体を自分で書く事になり、一般的にはスケールしません。Haskell の GUI ライブラリでは普通は状態は State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリを OCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用的意味があるとは思えませんが。」
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
Woho. Anglers are allowed two salmon per day with a minimum size for Chinook at 24 inches or larger. Salmon seasons from May 2016 to April 30, 2017 are currently being developed.
Last weekend Prowler Charters here in Bandon took clients out bottomfishing. Fishing for rockfish was excellent, but very few ling cod were taken. Strong ocean currents made for a fast drift which makes the conditions tough. Wayne Butler, the captain of the Miss Chief, told me that the depth at the Bandon bar was much deeper than last year. This winter's large rain event naturally flushed out the entrance, which makes bar crossings much safer. Anglers surf fishing out at Bullards Beach State Park reported good pinkfin surf perch action last week. Live sand shrimp or Berkley Gulp sand worms in camo colors have been working best. Perch fishing has been good up on the beaches in Coos Bay. Anglers are also catching pinkfin and striped perch along the Coos Bay south jetty. Boaters are catching rockfish inside the bay near the No. 7 buoy and the train trestle bridge
But while pundits have occasionally contorted themselves into logical pretzels to explain away Ford’s casual racism and misogyny — “He was just drunk!” “He always fights for the little guy!” — none has ever been able to explain away his deliberate and calculated anti-LGBT statements and actions.
Ford never hid anti-LGBT animus. From his earliest days on council, when he opposed funding small grants to diversity and AIDS-prevention campaigns, he made it explicit that his opposition stemmed from disgust with LGBT people, not from a desire to protect the public purse.Superman grany przez Cavilla to ten sam poziom, co w Człowieku ze Stali - moim zdaniem Cavill bardzo się stara, żeby jak najciekawiej zagrać Supermana, ale to i tak jedna z najnudniejszych postaci w całym komiksowym uniwersum, więc niektóre wysiłki pozostają niezauważone. Moim zdaniem to wina postaci i fani muszą się do tego przyzwyczaić.
Trzecią postacią, która ma szanse zaprezentować nam się trochę dłużej na ekranie jest oczywiście “ten zły”, czyli Lex Luthor, który grany przez Eisenberga kojarzył się raczej z o wiele bardziej szalonym Zuckerbergiem z The Social Network, niż komiksowym czarnym charakterem. Być może się czepiam, ale gdyby Luthor się w tym filmie nie przedstawił, nie miałbym pojęcia kim właściwie jest ten rudy gość, który z jakiegoś powodu postanowił być bardzo złośliwy.
he astonishments of the quasi-Biblical clashes and catastrophes in the director Zack Snyder’s “Man of Steel” left me impatient to see his “Batman v Superman: Dawn of Justice.” The earlier film conveyed an awed and even terrified sense of the colossal, a delight in the cinematic ability to realize wrenching destruction and, at the same time, to shiver at the very imagination of it. Snyder turned the superhero universe around on itself, constructing backstories and out-there stories of an apocalyptic force; it was silly but potent, shallow but thrilling. Perhaps Snyder’s new film is the victim of great (or any) expectations, but “Batman v Superman: Dawn of Justice” remains literally Earth-bound, and this fair planet is where Snyder bumps up against the limits of his vision.
Where “Man of Steel” opens big, with an intergalactic origin story that has the heightened tone of pseudo-scripture, the first big set piece in “Batman v Superman” is a catastrophe from home, a virtual replay of the 9/11 attack on the World Trade Center, with Bruce Wayne (Ben Affleck) looking on with horror and hatred as the tower of Wayne Industries collapses (vertically) into a blinding gust of light-gray powder—as a result of the battle waged by Superman (Henry Cavill) against the Kryptonian usurper General Zod.
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/loyola-chicago-vs-wichita-state-live-s-tream
https://www.justgiving.com/baylor-vs-oklahoma-state-live-s-tream
https://www.justgiving.com/baylor-vs-oklahoma-state-live-s-tream
https://www.justgiving.com/baylor-vs-oklahoma-state-live-s-tream
https://www.justgiving.com/baylor-vs-oklahoma-state-live-s-tream
https://www.justgiving.com/baylor-vs-oklahoma-state-live-s-tream
超わかる。
あいつら「いかにイケてる（と俺らが思う）論文タイトルをつけるか」に命掛けてるから。
タイトルに何の情報量も無くて科学論文としての体裁保ってねーだろって論文いっぱいある。
競争が激化しすぎて一発芸の世界みたいになっちゃってるんだよね。とにかく初見でインパクト与えた奴が勝ち、みたいな。
査読システムもなんか大学受験ゲームみたいな感じになってきちゃって、ルールブック丸暗記してきましたか？みたいな評価になってる。
とにかくなんでもいいからstate-of-the-art出せばオッケーだしstate-of-the-artじゃなかったらクソだよね、学問的に意味のある積み上げ？そんなもんはstate-of-the-art出してから言えよカスwwwwwって感じになってる。
そんでサクっと一発インパクト出して（情報系なら）GoogleとかFacebookとかMicrosoftあたりに就職すればOKっていう。
工学系もそうなるべきだと思うけど失敗は論文にならないのほんと歪んでると思うわ。
その結果、どいつもこいつも無理矢理state-of-the-artを捻り出して論文出してくるから、空気を読んで「これは意味のないstate-of-the-art」とか読む側が判定しないといけない。クソすぎる。
結局、工学は科学じゃないんだなってのは凄い感じる。リアルで言うと工学系の大学教員連中がブチ切れで噴き上がるから言えないんだけどね。
お前らそんだけ瞬間沸騰するってことは普段からよっぽど後ろめたく思ってんだろっていう。まあ競争的資金のゲームデザインがクソで、みんなそのクソゲーに過学習しちゃった結果なんだけどね。
ノースカロライナ州の税法に詳しくは無いけど、
発電所がtown limitsの外側、extraterritorial sectionsに位置するので、町は税収を得られない（※訳者はアメリカの法制度に疎いのでどういう意味か分かりませんでした）
これ、アメリカだと(特殊な州を除いて)一般的な話だと思うよ。
知ってるかもしれないけど、アメリカは以下の枠組みで区分けしてる。
CountryがUnited States、StateがNorth Carolina、CountyがNorthamptonで、TownがWoodlandね。
市や町の隣が即他の市や町になる日本には生まれなかったんだろうけど、
町と町との間がなんにもないので、郡っていう行政区分で管理してるわけね。
（郡と契約して行政サービスをアウトソーシングしてる市もあるから、郡と市との関係は上下というより区分けね）
よく映画なんかで街の看板が出てたりすると思うんだけど（ラスベガスへようこそ的な）、あれが市境ね。
それで普通はCity limitsとか言うんだけど、その境界の枠内は、市や町の権限が及ぶ、とされてる。
アメリカは大抵の州で市や町の権限が強くて、いろいろ決められるわけね。
だから、ウッドランドの町境の外なら、当然治外法権（町の権限が及ばない）ので、税収は得られない。
なので、発電所は資産税をノーザンプトン郡に直接納税する形になるはず。
知ってる限りでは、ノースカロライナ州でも地目変更なんかは所有者と直接交渉するハズで、たぶん「郡管轄の土地を、町が所有している」という状況なんだと思うよ。
（別に珍しい話じゃなくて、管理外にしとかないと面倒だからとか、歴史的な経緯で近所の土地持ってるとか。日本でも役所の保養所とかあるよね）
（消防訓練云々も、一番近所の消防署がウッドランド町だってことかな。治安維持はたぶん郡の仕事）
まあ町の持ってる土地をどうする？って話で、近所にデカイ発電所とか作んないで欲しいなあ税収も増えないし、という話じゃないかな。
ルート66とか有名になったけど、すぐそこに見える距離で新しい道路ができたら、ほんのチョットズレてる町がガッツリ寂れるのもアメリカだし。
（ピクサー映画Carsの寂れた町に、町保有の近所の土地に太陽光発電所立てさせてくんないかな、と大企業がよってきたイメージで大体あってる）
個人的には感情論だとは思うんだけど、ちっちゃな町で近所に巨大施設出来そうなのをイヤだというのはわかる。
（地目変更に町が絡まない）郡の土地だけで発電所建てちゃおうと思えば出来るとは思うけどね。たぶんしないんじゃないかな。
グーグルマップで見ても緑豊かな郊外な感じだし、まあ植生にダメージ与えるから嫌だっていう人が出てくるのはしかたがないんじゃないかなー
レジンキャストミルク (電撃文庫) 藤原 祐
☆社会福祉の思想と歴史―魔女裁判から福祉国家の選択まで (MINERVA福祉ライブラリー) 朴 光駿
絶対に解けない受験世界史 (大学入試問題問題シリーズ) 稲田義智
99歳ユダヤのスーパー実業家が孫に伝えた 無一文から大きなお金と成功を手に入れる習慣 矢吹 紘子
女子マネージャーの誕生とメディア―スポーツ文化におけるジェンダー形成 高井 昌吏
世界一即戦力な男――引きこもり・非モテ青年が音速で優良企業から内定をゲットした話 菊池良
愛についての感じ 海猫沢 めろん
借金の底なし沼で知ったお金の味 25歳フリーター、借金1億2千万円、利息24%からの生還記 金森 重樹
☆猫背を伸ばして 新装版 (フレックスコミックス) 押切蓮介
こんな上司が部下を追いつめる―産業医のファイルから (文春文庫) 荒井 千暁
フルーツ果汁100% 第1巻 (白泉社文庫 お 3-1) 岡野 史佳
☆「個性」を煽られる子どもたち―親密圏の変容を考える (岩波ブックレット) 土井 隆義
予備校なんてぶっ潰そうぜ。 花房 孟胤
コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus) 西尾 泰和
☆九月、東京の路上で 1923年関東大震災ジェノサイドの残響 加藤 直樹
そこに僕らは居合わせた―― 語り伝える、ナチス・ドイツ下の記憶 グードルン・パウゼヴァング
クリスマスに少女は還る (創元推理文庫) キャロル オコンネル
Three Essays on the State of Economic Science Tjalling C. Koopmans
The Elements of Style, Fourth Edition William Strunk Jr.
☆船に乗れ!〈1〉合奏と協奏 藤谷 治
11/22/63 上 スティーヴン キング
システム×デザイン思考で世界を変える 慶應SDM「イノベーションのつくり方」 前野隆司
追われ者―こうしてボクは上場企業社長の座を追い落とされた 松島 庸
グロースハック 予算ゼロでビジネスを急成長させるエンジン 梅木 雄平
To Repair the World: Paul Farmer Speaks to the Next Generation (California Series in Public Anthropology) Bill Clinton
☆社会心理学講義:〈閉ざされた社会〉と〈開かれた社会〉 (筑摩選書) 小坂井 敏晶
Making the Modern World: Materials and Dematerialization Vaclav Smil
高校教育のアイデンティティー―総合制と学校づくりの課題 (「教育」別冊 (9)) 小島 昌夫
☆名作はこのように始まる〈1〉 (ミネルヴァ評論叢書・文学の在り処) 千葉 一幹
グラミンフォンという奇跡 「つながり」から始まるグローバル経済の大転換 [DIPシリーズ] ニコラス サリバン
☆天涯の武士―幕臣小栗上野介 (1之巻) (SPコミックス―時代劇画) 木村 直巳
ぐいぐいジョーはもういない (講談社BOX) 樺 薫
LEAN IN(リーン・イン) 女性、仕事、リーダーへの意欲 シェリル・サンドバーグ
鬼畜のススメ―世の中を下品のどん底に叩き堕とせ!! 村崎 百郎
男性論 ECCE HOMO (文春新書 934) ヤマザキ マリ
You haven't received payment because you haven't shipped the item out. You are to ship the item( Apple iPhone 6S Factory Sealed Unlocked Phone, 64GB (Gold) ) through USPS/post office Express. shipping cost $18 including insurance. The client paid $90 for shipping. The total amount that will be transferred to you after you have shipped and gotten back to us with the shipment reference number is $1200. Kindly ship out today and get back to us with a copy of the custom receipt
-----------------------------------------------------
Akinsulere Johnpaul
19 Irepodun street off ogundele street oko-oba
agege,lagos state
23401
-----------------------------------------------------
Feel free to contact us for any Question or Query.
Warmest Regards,
Facebook: https://www.facebook.com/1minute.story
Domain Name: 1kando.com Registry Domain ID: 1888768854_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.star-domain.jp Registrar URL: www.star-domain.jp Updated Date: 2014-12-04T23:01:43Z Creation Date: 2014-12-04T23:01:42Z Registrar Registration Expiration Date: 2015-12-04T23:01:42Z Registrar: Netowl, Inc. Registrar IANA ID: 1557 Registrar Abuse Contact Email: registrar-abuse@netowl.jp Registrar Abuse Contact Phone: +81.662928811 Domain Status: clientTransferProhibited - https://www.icann.org/epp#clientTransferProhibited Registry Registrant ID: Registrant Name: Xserver XSERVER Inc. Registrant Organization: XSERVER Inc. Registrant Street: GRAND FRONT OSAKA TOWER A 13F Registrant Street: 4-20 Ofukacho, Kita-ku Registrant City: Osaka Registrant State/Province: Osaka Registrant Postal Code: 5300011 Registrant Country: JP Registrant Phone: +81.662928811 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: info@xserver.co.jp Registry Admin ID: Admin Name: Xserver XSERVER Inc. Admin Organization: XSERVER Inc. Admin Street: GRAND FRONT OSAKA TOWER A 13F Admin Street: 4-20 Ofukacho, Kita-ku Admin City: Osaka Admin State/Province: Osaka Admin Postal Code: 5300011 Admin Country: JP Admin Phone: +81.662928811 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: info@xserver.co.jp Registry Tech ID: Tech Name: Xserver XSERVER Inc. Tech Organization: XSERVER Inc. Tech Street: GRAND FRONT OSAKA TOWER A 13F Tech Street: 4-20 Ofukacho, Kita-ku Tech City: Osaka Tech State/Province: Osaka Tech Postal Code: 5300011 Tech Country: JP Tech Phone: +81.662928811 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: info@xserver.co.jp Name Server: ns1.xserver.jp Name Server: ns2.xserver.jp Name Server: ns3.xserver.jp Name Server: ns4.xserver.jp Name Server: ns5.xserver.jp DNSSEC: Unsigned
ご注文品
3920円
MONSTER エナジー 無糖 2ケース
7920円
228000円
合計239840円
↓注文内容確認はコチラ↓
ttp://tbhb.w06ewk1h.com/vghe045b314xwo-e266c420JRIC1106sxk51bfa751.M0BaDbF89zW
↓キャンセル等お問い合わせはこちら↓
ttp://tbhb.w06ewk1h.com/Ke2b6389aKjz/341BaF48UYj+B311cQPCE28CDFC+Zn3C8857bbn
Amozon.com
---
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: W06EWK1H.COM
Registrar: GMO INTERNET, INC. DBA ONAMAE.COM
Sponsoring Registrar IANA ID: 49
Whois Server: whois.discount-domain.com
Referral URL: http://www.onamae.com
Name Server: TS02.WINKL-WW.COM
Name Server: TS2.WINKL-WW.COM
Status: ok http://www.icann.org/epp#OK
>>> Last update of whois database: Tue, 11 Aug 2015 15:07:03 GMT <<<
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
For more information on Whois status codes, please visit
https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en.
Domain Name: w06ewk1h.com
Registry Domain ID: 1916126422_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.discount-domain.com
Registrar URL: http://www.onamae.com
Updated Date: 2015-07-10 14:03:18
Creation Date: 2015-04-03 08:56:56.0
Registrar Registration Expiration Date: 2016-04-03 08:56:55.0
Registrar Abuse Contact Email: abuse@gmo.jp
Registrar Abuse Contact Phone: +81.337709199
Domain Status: ACTIVE
Registry Registrant ID:
Registrant Name: eiji ootani
Registrant Organization: eiji ootani
Registrant Street1: 3-14-12 Ozukanishi
Registrant Street2:
Registrant City: Asaminami-ku Hiroshima-shi
Registrant State/Province: Hiroshima
Registrant Postal Code: 731-3167
Registrant Country: JP
Registrant Phone: 080-1359-5214
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: ozmsasssss@yahoo.co.jp
Registry Admin ID:
Admin Name: eiji ootani
Admin Organization: eiji ootani
Admin Street1: 3-14-12 Ozukanishi
Admin Street2:
Admin City: Asaminami-ku Hiroshima-shi
Admin State/Province: Hiroshima
Admin Postal Code: 731-3167
Admin Country: JP
Admin Phone: 080-1359-5214
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: ozmsasssss@yahoo.co.jp
Registry Tech ID:
Tech Organization: GMO Internet Inc.
Tech Street1: 26-1 Sakuragaoka-cho
Tech Street2: Cerulean Tower 11F
Tech City: Shibuya-ku
Tech Country: JP
Tech Phone: 03-5456-2555
Tech Phone Ext:
Tech Fax: 03-5456-2556
Tech Fax Ext:
Tech Email: admin@onamae.com
Name Server: ts2.winkl-ww.com
Name Server: ts02.winkl-ww.com
DNSSEC: Unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2015-07-10 14:03:18 <<<
ソース：http://www.vgchartz.com/gamedb/
※後にシリーズ化されているものは1作目だけリストアップしました。
※キャラクターものとかはシリーズなのか微妙なので除外、ハード名がついたものは悩んだが入れた
※調べて気がついたけど、1作目はまあまあで2作目からバカ売れってパターン多いな
Wii Sports(Wii) 8244万本 ※ただしセットで格安で売られていた スーパーマリオブラザーズ(ファミコン) 4024万本 Nintendogs(DS) 2466万本 ※ネコ専用版まだですか？ ダックハント(ファミコン) 2831万本 ※欧米人この頃から射撃ゲーム好きなのか Wii Fit(Wii) 2269万本 ※体重計込みでこの記録だから恐ろしい Kinectアドベンチャー!(Xbox360) 2146万本 ※キネクト込みでこの記録だから恐ろしい 脳を鍛える大人のDSトレーニング(DS) 2012万本 ※いまならスマホでタダでやれそうなゲーム ザ・シムズ(PC) 1124万本 グランツーリスモ(PS1) 1095万本 Wii Party(Wii) 834万本 ゴールデンアイ 007(N64) 809万本 Myst(PC) 803万本 パックマン(Atari2600) 781万本 ※売れたけどクソゲーなので注意 マインクラフト(Xbox360) 726万本 ※低価格ゲームなので単純比較はできない Just Dance(Wii) 718万本 クラッシュ・バンディクー(PS1) 682万本 Zumba Fitness(Wii) 668万本 ※なにこれ初めて聞いた・・・ やわらかあたま塾(DS) 661万本 ゼルダの伝説(ファミコン) 651万本 キングダムハーツ(PS2) 640万本 レッドデッドリデンプション(PS3) 634万本 Driver(PS1) 627万本 ※タイトルのググラビリティ低すぎ！ Kinectスポーツ(Xbox360) 607万本 メタルギアソリッド(PS1) 603万本 ※ソリッドがついてこそのこのシリーズなので リトルビッグプラネット(PS3) 577万本 クッキングママ(DS) 561万本 ※これ海外版とかあったのか 大乱闘スマッシュブラザーズ(N64) 555万本 ラスト・オブ・アス(PS3) 550万本 アサシンクリード(Xbox360) 550万本 ※なおPS3版は484万本 レイトン教授と不思議な町(DS) 518万本 スパイロ・ザ・ドラゴン(PS1) 500万本 ※やべえ聞いたことねえ・・・ アンチャーテッド エル・ドラドの秘宝(PS3) 484万本 Destiny(PS4) 471万本 ※これはさすがにもっと売れて欲しかった所 トゥームレイダー(PS1) 463万本 ※ララ・クロフトは欧米人的には萌えキャラ Fallout 3(Xbox360) 456万本 ※一応1と2あるけどこのシリーズは3からなので ピットフォール(Atari2600) 450万本 God of War(PS2) 445万本 ソニック・ザ・ヘッジホッグ(メガドライブ) 450万本 ※あの頃は光かがやいていたなあ・・・ アステロイド(Atari2600) 431万本 ※知らん・・・ RESISTANCE～人類没落の日～(PS3) 429万本 ※え、そんなに売れてたのかコレ ナムコミュージアム(GBA) 424万本 アイトーイプレイ(PS2) 420万本 ※意外と売れてたんだー エキサイトバイク(ファミコン) 416万本 Half-Life(PC) 412万本 ※3早く出せよ Carnival Games(Wii) 404万本 ※なにこれ情報なさすぎなんで売れてんの？ ゴルフ(ファミコン) 401万本 ※これまたググれねえ名前だ Nintendo Land(Wii) 388万本 ※WiiUだってこれくらいは行ける モーターストーム(PS3) 385万本 ローラーコースタータイクーン(PC) 384万本 スポーツチャンピオン(PS3) 377万本 スタークラフト(PC) 374万本 ※韓国にはプロゲーマーがたくさんいます トモダチコレクション(DS) 367万本 ※なお日本での売上のみ ウォッチドッグス(PS4) 361万本 ※UBIのオープンワールドは2作目から化けるはず ゲッタウェイ(PS2) 354万本 ※すまん知らぬ Diablo(PC) 346万本 Borderlands(Xbox360) 334万本 ※洋ゲーだけどトゥーンレンダリングです ラチェット＆クランク(PS2) 333万本 Max Payne(PS2) 331万本 ※PS2版とかあったのかよ 鉄拳(PS1) 324万本 Wii Music(Wii) 323万本 ※思ってたより売れてる印象 ベースボール(ファミコン) 320万本 ※こういうタイトルやめてくれ キラーインスティンクト(SFC) 320万本 ※オリジナル版のほうね L.A.ノワール(PS3) 311万本 ※開発スタジオは消えました。戻ってきてくれー・ レイマン(PS1) 303万本 ※かってはUBIのマスコットでした Star Fox(SFC) 299万本 デビルメイクライ(PS2) 299万本 HEAVY RAIN 〜心の軋むとき〜(PS3) 297万本 ※まじヘビーで心が軋んだよ マスエフェクト(Xbox360) 288万本 ※欧米の人は勧善懲悪じゃないの好きだよねえ INFAMOUS〜悪名高き男〜(PS3) 288万本 ※欧米版無双 Doom(PC) 285万本 ※ここから俺の人生は狂った バイオショック(Xbox360) 279万本 ※全部生贄にしてしまったよ。 メトロイド(ファミコン) 273万本 ※FPSな新作でないかなあ。アレはなし。 鬼武者(PS2) 270万本 ※カプコンはシリーズ続けるの下手だよなあ モータルコンバット(メガドライブ) 267万本 ※最新作はありえないレベルの残虐さです Fable(Xbox) 266万本 ※モリニューさんはもう復活できないだろうな タイタンフォール(XboxOne) 259万本 ※忍者＆ロボットFPS。嘘はいってません。 クレイジータクシー(PS2) 252万本 ※ドリキャス版よりPS2版のほうが売れてるとは パーフェクトダーク(N64) 252万本 ※ある意味007の続編かもしれないけど ドラゴンクエスト(ファミコン) 252万本 ※ゆうべはお楽しみでしたね Pure(Xbox360) 246万本 ※こういうググるの不可能な名前マジやめて アイスホッケー(ファミコン) 242万本 ※同上 ディノクライシス(PS) 241万本 ※カプコンはシリーズ(以下略) uDraw Studio(Wii) 241万本 ※なおTHQ倒産の一因 プロレスリング(ファミコン) 242万本 ※もうググれないFCタイトルはのせない ギターヒーロー(PS2) 238万本 ※なお専用ギター付き デッドアイランド(Xbox360) 234万本 ※死の天国ではなくてバグ天国だった グランド・セフト・オート(PS1) 232万本 ※なお最新作は累計3300万本 クロノトリガー(SFC) 231万本 ※FF7の次はこれのガチリメイクお願いします セインツロウ(Xbox360) 217万本 ヒラメキパズル マックスウェルの不思議なノート 214万本 ※タイトル長！もう揃えたくない。 ダークソウル(PS3) 197万本 ※ブラッドボーンも100万本を突破！ デッドスペース(PS3) 197万本 ※3作目で課金アイテム入れてオワコン化 The 7th Guest(PC) 195万本 アレイウェイ(GB) 194万本 デモンズソウル(PS3) 177万本 ※一応ダクソとは別扱い 黄金の太陽(GBA) 176万本 ※4作目まだですか？ 光神話 パルテナの鏡(ファミコン) 176万本 ※スマブラでしか知らないけど State of Emergency(PS2) 176万本 ライオットアクト 173万本 ドラゴンズドグマ(PS3) 171万本 ※オンライン期待してます！ タイムクライシス(PS1) 168万本 Dishonored(Xbox360) 167万本 ファミリースキー(Wii) 167万本 ※バンナムだって頑張ってるんだよ！ ディグダグ(Atari2600) 164万本 ※ 魔界村(ファミコン) 164万本 ※カプコンはシリーズ(以下略) Heavenly Sword 〜ヘブンリーソード〜(PS3) 163万本 ※なんでSCEは和名に～をつけるんだ？ ピクミン(ゲームキューブ) 163万本 ※歌詞を貼りたいけどジャスラック怖い サルゲッチュ(PS1) 163万本 アーミー オブ ツー(Xbox360) 162万本 BEYOND: Two Souls(PS3) 162万本 ※和名に～をつける人辞めちゃったのか？ Sled Storm(PS1) 162万本 DRIVECLUB(PS4) 162万本 ※なお評価は微妙 あつまれ!ピニャータ(Xbox360) 161万本 サイレントヒル(PS1) 160万本 ※コナミはマジでP.T.製品化してお願い Rage(Xbox360) 158万本 ※FPSの父カーマックが最後に手がけたゲームに CRAZY BUMP'S 〜かっとびカーバトル!〜(PS2) 156万本 ※～付ける人この頃からいたのか Twisted Metal(PS) 156万本 ファイナルファイト(SFC) 156万本 ※なおストリートファイターと同世界観 Stuntman(PS2) 155万本 ダーククラウド(PS2) 154万本 ※あの頃のレベルファイブはコアゲームだった ゼビウス(ファミコン) 152万本 ※ゼビ語で語ろう アイスクライマー(ファミコン) 150万本 ゼノギアス(PS1) 146万本 サイコブレイク(PS4) 145万本 ※まだ和ゲーも世界でやれる！
※もう疲れたしこれ以上入らないのでここで終わります。ざっと見た限りあと61個くらいありました。
※なお、任天堂のタイトルは長期にわたってじわ売れすることが知られている。
※なお、http://www.vgchartz.com/game/82965/splatoon/ で世界累計0本。ここは情報は多いが反映が遅いので。
Registry Domain ID: 1735502527_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2014-05-04T01:24:36Z
Creation Date: 2012-07-24T17:44:15Z
Registrar Registration Expiration Date: 2015-07-24T17:44:15Z
Registrar: GoDaddy.com, LLC
Registrar Abuse Contact Email: abuse@godaddy.com
Registrar Abuse Contact Phone: +1.480-624-2505
Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Registry Registrant ID:
Registrant Name: Randi Shannon
Registrant Organization:
Registrant Street: PO Box 570263
Registrant City: Miami
Registrant State/Province: Florida
Registrant Postal Code: 33257
Registrant Country: United States
Registrant Phone: +1.3054914597
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: randishannon@gmail.com
Registry Admin ID:
Admin Organization:
Admin Street: PO Box 570263
Admin City: Miami
Admin Postal Code: 33257
Admin Country: United States
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: randishannon@gmail.com
Registry Tech ID:
Tech Organization:
Tech Street: PO Box 570263
Tech City: Miami
Tech Postal Code: 33257
Tech Country: United States
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: randishannon@gmail.com
Name Server: NS11.DOMAINCONTROL.COM
Name Server: NS12.DOMAINCONTROL.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
For more information on Whois status codes, please visit
https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en
DR-1 Statement of Organization
Randi Shannon
Marketing Director, Youngevity Life Sciences
319-804-9163 – RandiShannon@Gmail.Com
例えば、こういうクラスがあったとする
/** ** ゲームキャラのクラス **/ class Character { /** * 歩行の状態にする。 * @param $place 歩行する場所。 */ private function _walk($place){ $this->_state = Const::STATE_WALK; $this->_place = $place; } /** * 山を歩いている状態にする。 */ public function walkInMountain(){ $this->_walk(Const::PLACE_MOUNTAIN); } }
「walkIn～～ってメソッド名長くね？」
「良く使うメソッドだから、あんまり書くと、ソースが読みづらくなるんだよね。」
という突っ込みが入ったとする。
対応として、
walkInMountain → walkInMt
とかやってもいいけど、逆に分かりづらくなる。mtってなんやねんと。
/** ** 歩行クラス **/ class Walk { private $_chara = null; public function __construct($chara){ $this->_chara = $chara; } /** * 歩行の状態にする。 * @param $place 歩行する場所。 */ private function _walk($place){ $this->_chara->state = Const::STATE_WALK; $this->_chara->place = $place; } /** * 山を歩いている状態にする。 */ public function mountain(){ $this->_walk(Const::PLACE_MOUNTAIN); } }
とすれば、呼び出し元からは
$chara = new Character(); $chara->walk->mountain();
みたいに、
主語->動作->述語
という構文で記述できるので、すっきりすると思う。
before) $chara->walkInMountain(); after) $chara->walk->mountain();
でも、やりたいことはそういうことだ！
つたわれ！俺の思い！
int write() { int numberWritable = 0; : }
こんなのは、
int write() { int number = 0; : }
にしてしまえ！
みたいな。
荒川マラソンが前代未聞の理由で開催中止に → 返金の連絡先が『振り込め詐欺に利用された要注意住所』と一致して大炎上ｗｗｗｗｗ
http://www.kimasoku.com/archives/7982053.html
http://fields.canpan.info/organization/detail/1026339646
Content-Type: application/pdf Creation-Date: 2014-11-20T10:23:34Z Last-Modified: 2014-11-20T10:23:34Z Last-Save-Date: 2014-11-20T10:23:34Z created: Thu Nov 20 19:23:34 JST 2014 date: 2014-11-20T10:23:34Z dc:format: application/pdf; version=1.5 dcterms:created: 2014-11-20T10:23:34Z dcterms:modified: 2014-11-20T10:23:34Z meta:creation-date: 2014-11-20T10:23:34Z meta:save-date: 2014-11-20T10:23:34Z modified: 2014-11-20T10:23:34Z pdf:PDFVersion: 1.5 pdf:encrypted: false producer: Microsoft® Excel® 2010 xmp:CreatorTool: Microsoft® Excel® 2010 xmpTPg:NPages: 2
http://hill.xsrv.jp/3minute-essence/nomi-479
Domain Name:ATDAWN.TOKYO Domain ID:GMOREGISTRY-DO186691 WHOIS Server:whois.nic.tokyo Referral URL:http://nic.tokyo Updated Date:2014-11-28T03:59:43.0Z Creation date:2014-09-26T13:07:28.0Z Registry Expiry Date:2015-09-26T23:59:59.0Z Sponsoring Registrar:GMO Internet, Inc. Sponsoring Registrar IANA ID:49 Domain Status:ok http://www.icann.org/epp#ok Registrant ID:15981FC9FAA55F Registrant Name:MORIYO MOMOHRA Registrant Organization:MORIYO MOMOHRA Registrant Street:Saitoaominami6-8-3-102 Registrant City:Mino-shi Registrant State/Province:Osaka Registrant Postal Code:562-0028 Registrant Country:JP Registrant Phone:+81.08085010056 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email:domain@onamae-server.com ...
Domain Information: [ドメイン情報] [Domain Name] POTUS.JP [登録者名] 桃原 守代 [Registrant] MORIYO MOMOHRA [Name Server] dns02.gmoserver.jp [Name Server] dns01.gmoserver.jp [Signing Key] [登録年月日] 2014/11/13 [有効期限] 2015/11/30 [状態] Active [最終更新] 2014/11/13 01:39:04 (JST) Contact Information: [公開連絡窓口] [名前] 桃原 守代 [Name] MORIYO MOMOHRA [Email] munokokoroha@gmail.com [Web Page] [郵便番号] 562-0028 [住所] 大阪府箕面市 彩都粟生南6-8-3-102 [Postal Address] Mino-shi Saitoaominami6-8-3-102 [電話番号] 080-8501-0056 [FAX番号]
http://v.hitomachi-kyoto.genki365.net/gnkk14/mypage/mypage_group_info.php?gid=G0000921
http://ark.npo-marathon.jp.net/service.html
Author: FJ-USER Content-Length: 464992 Content-Type: application/pdf Creation-Date: 2014-10-02T02:37:57Z Last-Modified: 2014-10-02T02:37:57Z Last-Save-Date: 2014-10-02T02:37:57Z created: Thu Oct 02 11:37:57 JST 2014 creator: FJ-USER date: 2014-10-02T02:37:57Z dc:creator: FJ-USER dc:format: application/pdf; version=1.5 dcterms:created: 2014-10-02T02:37:57Z dcterms:modified: 2014-10-02T02:37:57Z meta:author: FJ-USER meta:creation-date: 2014-10-02T02:37:57Z meta:save-date: 2014-10-02T02:37:57Z modified: 2014-10-02T02:37:57Z pdf:PDFVersion: 1.5 pdf:encrypted: false producer: Microsoft® Excel® 2010 resourceName: santa.pdf xmp:CreatorTool: Microsoft® Excel® 2010 xmpTPg:NPages: 4
最近よく来る迷惑メールに書かれているホームページのドメインの whois から情報を切り出して uniq してみた結果。
1 Name:akira masuda
1 Name:akira yano
1 Name:aoi higashitani
1 Name:aya yuuki
1 Name:ayumi yokoyama
1 Name:hajime miyashita
1 Name:haruka nishioka
1 Name:haruzou nishikawa
1 Name:hiro takayama
1 Name:hiroki shimamura
1 Name:hiroshi matasuoka
1 Name:hitoshi wada
1 Name:itaru koube
1 Name:jirou nakamura
1 Name:kazuyoshi miyoshi
1 Name:keiko ueda
1 Name:kimie uehara
1 Name:kouji sekine
1 Name:kouta yokomine
1 Name:maeda maeda
1 Name:makoto takahashi
1 Name:mitsugu ooe
1 Name:miwa shiraishi
1 Name:naomi ueda
1 Name:norio ishikawa
1 Name:satomi tsuyama
1 Name:tadashi hara
1 Name:takaaki uehara
1 Name:takami jingai
1 Name:takumi mimura
1 Name:tarosuke iida
1 Name:tatsuo shiokawa
1 Name:teruo gouhara
1 Name:tomo sano
1 Name:tomoki miyauchi
1 Name:toshiyuki nishida
1 Name:yoshio kanou
1 Name:youko kakitani
1 Name:yukio chin
1 Organization:akira masuda
1 Organization:akira yano
1 Organization:aoi higashitani
1 Organization:aya yuuki
1 Organization:ayumi yokoyama
1 Organization:hajime miyashita
1 Organization:haruka nishioka
1 Organization:haruzou nishikawa
1 Organization:hiro takayama
1 Organization:hiroki shimamura
1 Organization:hiroshi matasuoka
1 Organization:hitoshi wada
1 Organization:itaru koube
1 Organization:jirou nakamura
1 Organization:kazuyoshi miyoshi
1 Organization:keiko ueda
1 Organization:kimie uehara
1 Organization:kouji sekine
1 Organization:kouta yokomine
1 Organization:maeda maeda
1 Organization:makoto takahashi
1 Organization:mitsugu ooe
1 Organization:miwa shiraishi
1 Organization:naomi ueda
1 Organization:norio ishikawa
1 Organization:satomi tsuyama
1 Organization:tadashi hara
1 Organization:takaaki uehara
1 Organization:takami jingai
1 Organization:takumi mimura
1 Organization:tarosuke iida
1 Organization:tatsuo shiokawa
1 Organization:teruo gouhara
1 Organization:tomo sano
1 Organization:tomoki miyauchi
1 Organization:toshiyuki nishida
1 Organization:yoshio kanou
1 Organization:youko kakitani
1 Organization:yukio chin
7 Address:01
8 Address:02
9 Address:03
7 Address:04
8 Address:05
39 Address2:
39 Address3:
7 City:01
8 City:02
9 City:03
7 City:04
8 City:05
8 State/Province:Akita
8 State/Province:Aomori
7 State/Province:Hokkaido
9 State/Province:Iwate
7 State/Province:Miyagi
39 Country/Economy:JP
39 Postal Code:000-0000
7 Phone:+81.0300010001
8 Phone:+81.0300020002
9 Phone:+81.0300030003
7 Phone:+81.0300040004
8 Phone:+81.0300050005
39 Phone Ext.:
39 FAX:
39 FAX Ext.:
どう見ても偽名偽住所です本当にありがとうございました。
http://netserc.blog63.fc2.com/blog-entry-170.html
上記より。
これが起こった場合はとりあえず10Mの古いハブのせいっと・・・。
覚えておこう。
日付、時間: %PM-4-ERR_DISABLE: loopback error detected on Fa0/21, putting Fa0/21 in err-disable state
日付、時間: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to down
日付、時間: %LINK-3-UPDOWN: Interface FastEthernet0/21, changed state to down
あと、ココも見た。
http://www.cisco.com/cisco/web/support/JP/100/1008/1008405_errdisable_recovery-j.html