  |
はてなキーワード: ワンタッチとは
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for Businessは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 サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの 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
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
というか今のスマホは俺が今まで使っていたスマホにあった便利な機能が全部削ぎ落とされた。
来月でスマホ歴10年だが今のスマホは昔（iPhone3G以前）に比べて本当に不便になった。
いや便利にはなったと思うがそれはそういうアプリがあるからっていうだけの話で
OSレベルやそれに伴うハード周りの変遷では確実に不便になったと思う。
まずタッチパネルが全部静電式になった。この時点からスマホに価値を見出せなくなった。
俺にとっては感圧式タッチパネルがスマホのスマホたる絶対条件だった。
スクロールバーはどこへ消えた。小さいボタン押すのに爪が使えないとかアホか。テキスト選択するのに長押し？ふざけろ。
キーボードショートカットが使えないことに絶望した。ソフトウェアキーボードにCtrlがないとかなんだよそれ。
Ctrl+A Ctrl+C Ctrl+X Ctrl+V Ctrl+Z 最低でもこの5つくらいは使わせろ。
ショートカット使えるか調べてもiPhoneもAndroidも、Windows 10 Mobileまでもがアプリのショートカットしか検索結果に出してこない。違う、そうじゃない。
ハードウェア画面ロックがいつの間にかなくなっていたときにはもうだめだと思った。
ロック設定してもポケットに入れてて着信あると何かの拍子にロック解除されてアプリ誤起動するのホント頭来る。
何のための画面ロックだよ。画面を操作してロック解除できる仕様じゃ画面ロックの意味ねえだろ。
あとスマホじゃなくてガラケーで使ってた機能だけど、スマホ汎用の日本語T9入力はいまだにないのか。
ドコモのNスマホ？あれはAndroidの時点で却下だ。それ以前にキャリアのゴミアプリ満載の時点でさようなら。
今はFSKAREN使ってるけど、あれのワンタッチ変換は辞書が貧弱すぎて文節区切りまくらないといけないから到底使いものにならない。
今のスマホはOSとして持っているべき機能をサードパーティーのアプリに頼ってるアプリありきの設計思想が気に入らない。
自作スマホが手軽にできるようになれば少しは欲しいスマホも出てくるだろうに。
ワイモバイル、次の機種が消去法で何も残らない。iPhone5sが使えるようになった今日の時点でだ。
どうするかなこれ。
最近スマホではてなを見ることが多いのだけどエントリー長押しメニューに出てくる「あとで読む」という項目が邪魔で仕方がない。
既にブクマコメントをつけている状態でこれを押すとななななななんんととととととブックマークが上書きされコメントが消滅してしまうのだ。
伸びそうな記事にブコメを付けていざ伸びたらシメシメ俺のコメントは人気に入っているかなーなんて思いながら「コメントを見る」を押そうとしたらフィルムに付着した指の油が電界を歪めて「あとで読む」ボタンをポチッ。頭を捻って書いたコメントはあわやデータの塵に。
はてなさん、設定で「アレ」消せるように出来ませんかね？
個人的な意見ですがブクマするときはコメントする派の人間としては「とっても使いにくくなっただけ」です。
いや「アレ」があったら便利に感じる人がいるのは分かるんですよ。
ブクマするけどコメントなんて一切しないよ派の人とかワンタッチでサクサクですもんね。
不快だった話をかく。
理系にいかにも女慣れしてないような。
自分がそういうめにあったらという恐怖的な意味でもそういうノリは好きじゃないし、
彼には同情し、少し仲間意識さえあった。
しかし、その仲間意識が彼に伝わったのか、なにやら雲行きが怪しく感じたのがこの間の飲み会。
・やたら接近してくる。
・飲み会場のはしご中、帰り道、どさくさにまぎれて二回も肩を抱かれる。
・電車での別れ際、ハイタッチのつもりなのか、こっちは何もアクションしてないのにつり革をつかむ私の手をポンっとワンタッチしてから去る。
喪女のくせにこんな言葉使っていいのかわからないけど、これってキモイだろ。
キモイって感じても許されるよね？
私的に連絡をとったこともなく、会社以外で全く話したことない間柄なんだよ？
私喪女だからわからないんだけど、世の中の男女ではこれって普通のやりとりなわけ？
決して酒で酔ってたからとかじゃないんだ。
明らかに確信犯的に一連の行動をとってる。
いや悪気がないのはわかるんだ。
いかにも女慣れしてない！って感じのアッパー系の空気読めないくんだしね！！
なんて考えてたら、だんだん「こんな奴に肩抱いていいと思われてる自分」への自己嫌悪がすごくなってきた。
リア充女子とか手も届かないような美人とかにだったら絶対やらないだろ？
私も喪女のくせに彼を見下す周囲の人間と変わらなかったわけかと反省しそうになりつつ
いや、でもこんなキモイことされたんだから嫌うの当然だろとも思う。
待機電源だのにしても気になる人は気になるし、そんなもん微々たる金額で意味ないって人もいるでしょう。
いや、気になるのは良いと思うんだけど、過剰に気にしてる割に、それが一体どれくらいの節約になってるのか
分かってない人が多いのが問題なんでしょ。
もちろん、ただただその金額だけ浮く、って言うならやらない意味はないけど、
まず、残り湯を使える、っていう洗濯機をわざわざ選ばないといけないし、
あれだけ便利にワンタッチで出来るようになった洗濯機でわざわざ給水ホースとか設置して入れないといけないし、
給水器もそもそも結構場所とるからひとり暮らしなら結構場所とるし、
その辺りの労力で10円しか得しない、って考えるとあれじゃない？
その一方で、部屋の電気は光々とつけっぱなしにしてたりしたら意味ないし。
かと言って、そういうのほんとに隅から隅まで気をつけられるか、っていったら無理なわけで。
思ったこと。
はてなブックマーク - ガンホー、『パズドラ』に色弱向けオプションを近日実装 | インサイド
元よりこんな感じの色使いをしてて（参照）見難いって思ってたから、作り手にそういうところに頭が回る余地あったんだなって意外だった。色弱ではない自分はギラギラした文字列を見難いと常日頃思っていたけど、こういうきわどい色使いって今風のスマホゲームなのかな、という具合に不満を押し殺してた。はてなでも微妙にうっすい色流行ってんじゃんしね。
まあこういうバリアフリーな対応をしてきたということは、それだけユーザーが増えたということですね。最初からしろってのもあるけど。
（「ギラギラしてて見難い」のと「色弱で特定の色の判別が困難」なのは、解決方法としては別だけど、結果見難いって部分では同じなので、ぐるぐる考えるのはやめておきます。）
あとぷよぷよと違って（参照1、参照2、参照3）パズドラは明確？にアイコンの模様が変わってるので、色弱はそれほどハンデにならないのではと勝手に思ってた。パズドラみたいな盤面をずらして崩しまくる系だと、形の視認性だけじゃ追っつかないのかもしれない。というかぷよぷよの後の方も「ぷよ」というブロック（黄色の）が目をつぶったりしてて、作り手も頑張って色以外の差異を出そうとしてる風にも読み取れる。
http://mobile.gungho.jp/news/pad/dungeon/1401/ss3_d6o0dm.jpg
この中央下の横に長いバーの色の判別、これかなネックは。ゲームとしては割りと重要な情報。（このバーが敵の体力ゲージで、半分に減るまでは敵の属性が赤、それ未満に減ると緑になる。）
面積が小さいとそれだけで色の判別が難しくなるんですよね。色弱関係ない。左半分を青と見るか緑と見るか、みたいな。
そんなことする時間があるならそれを他に回せ、ということを言いたいのではない。
あとあれだ、
色覚異常の方でも問題なく視認できるように、絵の形だけでなんとかするってやり方の「色に対する後ろ向きさ加減」？
色の問題なんだから色でなんとかするのがスジだろって話とか。
他には、
あらゆる映像を入力としてワンタッチで色覚異常向けに出力できるって感じっていうか。
だけどそれって、
「ある分野で黄色と赤と青の区別が絶対。別のある分野では黄色と赤は似た意味で緑と青の違いに重大な重みがある。」とか、
そういう分野ごとの重み付けを適用できないから、ワンタッチでなんとかは難しいんじゃないかなーっていう。
思ったよ。
商品紹介
本品はジョークグッズですので、その他の目的でご使用された場合の責任は一切負いません。
デリケートな部分に潤いを！！ワンタッチ注入式潤滑ゼリー！！女性にやさしいデザインです。ウエットトラストは、注射器型ローションなのでスムーズかつ、スマートに使用することが出来ます。本体を膣内に挿入してピストンを軽く押すだけで潤滑ゼリーがでます。
注射器型ローション
注射器型ローションなのでスムーズかつ、スマートに使用することが出来ます。
商品の説明
「WetTrustPRO(ウエットトラストプロ)60本入」は、ワンタッチ注入式だから、スムーズかつスマートに使用することができる潤滑ゼリーです。本体を挿入して、ピストンを軽く押すだけで使用できます。
海外サッカーが好きだ。しかし当然のことながら、生で観戦したことはほとんどない。
地元でユナイテッドが見られるチャンスということで、私は迷わずチケットを手に入れた。
横浜市民であるが、ここ数年のマリノスには良いイメージがない。
数年前、若手主体のチームを作ると言って山瀬、坂田、松田らをリストラし、その後監督交代があったとはいえ、千真、小野を手放し、ドゥトラをはじめとするおっさん回帰のチーム作りを見るにつけ、あのリストラは何だったのかと思っていた。
斎藤、栗原も東アジア杯でいないし、アーセナルよろしく前半でユナイテッドが試合を決め、後半に新戦力を大量投入みたいな展開になると思っていた。
そんな予想は開始早々にマルキーニョスのゴールで外れた。
俊輔を中心にワンタッチツータッチでテンポ良くパスを回し、サイドチェンジを多用して守備を左右に揺さぶり、中央のあいたスペースにパスを通すマリノスのサッカーは小気味良かった。
そしておっさん達が走る走る。俊輔とかあんながっつりプレスかけるキャラだっけ？と驚いた。
俊輔が怪我？でいなくなってからの前半はパスのテンポも鈍り、ジョーンズ、エヴァンズを相手にサイドからクロスを多用する微妙な展開になってしまった。しかし、後半ユナイテッドが二列目の新戦力に代えてヤング、香川、ギグスを投入したのに対し、マリノスはあれだけの謎交代をしたにも関わらず、グダグダにならず最後まで攻めきる姿勢はとても良かった。
GKも代わるなら飯倉だろとか思ってたけど、この第三キーパーがまたいいセーブするんですわ。
私は最早アウェイ側にいながら、ユナイテッドのサポーターではなかった。
最後MVPもらってたけど、出場しなくてももらっていたのではなかろうか。
とにかく思わぬマリノスの健闘ぶりに感動し、最高だった。マリノスファンも嬉しかったのではないかと思う。
とまあ久しぶりのサッカー観戦で楽しかったが、試合以外は微妙だった。
入場時にひどい雷雨に襲われパンツの中までぐっしょり濡れ、警備員になぜかみんな座って観戦するよう言われ(指定席ならともかく、自由席で座って観るように言われることとかあるの？？)、帰りの小机と新横浜に向かう人が交差する適当な導線でもみくちゃになり…
きっと多くの人は、香川やファンペルシーを生で見られたことに感動し、良い試合内容だったことに満足し、雨や人の多さに閉口し、そして再び日産スタジアムに来ることはないのだろう。
雨が降っているのでうちわではなくゴミ袋(ポンチョにしても、シートとして下にひいても、荷物が濡れないよう入れても良しとユーティリティ性が高い)を配る気配りとか、次回以降のリーグ戦で使えるクーポンのような次につなげる仕掛けとか、試合以外で満足できるものが欲しかった。
マリノスに興味を持ってくれるきっかけは、香川でもユナイテッドでも何でも良いではないか。
今日の集客力を、マリノスの選手の健闘を、試合の感動を、次に活かそうとしないマリノスというクラブはやはりどうかしていると思う。
http://page4.auctions.yahoo.co.jp/jp/auction/d136209792
↑あまりにも読みにくいのでついかっとなってソースからひろってタグつけた。
なお、三行に要約すると
ということだそうだ。
実際に検索して見ると結構自作していると言う情報があるから対抗してこう言う書き方をしているのだろうなあとは思う…。ただ、実際に売り文句通りなら優れているんだろうし、自作情報が出回っているものを自前で作って売るって商売はそれなりにあるんだからこんなに並べなくてもいいんじゃないかと思った。売り文句が伝わりにくいのならば、Youtubeにでも動画一発上げりゃ馬鹿売れじゃないのと思うのだけれど。スペック通りなら、確かに安いようだし。新品のこのスペックのポンプ、Monotaro見ると25万ぐらいしてるし。真空脱泡機も、真空ポンプも詳しくないんだけどさ。
無駄に時間をついやして今は後悔している。そっとしておいてください。
さて、大型装置は最後のご案内です。
この値段だと中古整備済のポンプさえ買えませんよ。（＾＾
今回購入が無理であれば、もう皆さん自作で間に合わせを試してみてはいかがでしょうか？(^ ^)
いくつか重要な点を知って頂いての簡単操作なので
カタチだけ真似ても、どうにもならないと思います。
扱い方というものは、何でもあるものです。（＾＾
あくまでも老婆心という観点からです。
実際、１台自作して２台目を作ればコレ以上の価格になり
それでも希望通り・それ以上の装置にはならないというのが現実です。
自分も始めてから希望通りの装置に行き着くまでは20台も替えましたから。
一度で済む値段で納得できなければ自作を選択すべきです、何度失敗し何度散財・何度徒労してでも自分でやらないと
気が済まないタイプの方も居ると思います、否定的な方に多いタイプです。是非いろいろ試して散財も仕方ないと思います。(^^;;
面倒が嫌でトライ＆エラーを数万から始めたものの気が付けば何十万円以上
（機械・機材・材料でそれ以上になりますよね＾＾；）と
何カ月もの時間をオカネを無駄にしたくなければコレを買ってしまった方が安いのです。
その道の皆さんが納得している装置がウチのコレですから。（＾＾
コチラの予定ですので、欲しい時には都合が合わなければ意味がないと思います、購入予定・使用予定のある方は事前に質問へ。
小型とは、まったく別世界の大型真空装置をお届けします。
その道のプロが行き着く！！！
３００～３６０L引き大型真空脱泡機、最後１台です！！
デシケーターは縦横３３ｃｍ円筒。
このクラスは限られたプロのみ御愛用いただいております。
最後の１台、早いもの勝ちです。
★観ているだけの方は随分長い間検討されてきたと思います。
使えるものなのか使えないものなのか考えて頂く必要のない装置です。
モデル別に随所にコツがあるのでバラす・組むだけではどうにもならず面倒で繊細、怪我も要注意で本当に大変なので。
それ以降は、大型は特別大変で部品も重く怪我の危険もあり面倒極まりないので出品ないです、他が３００、４００、５００、６００、１０００の装置を作れないのは、そういう点もあり、分解したら組み立てるだけではどうにもならないのも大型装置なので５０位のポンプで真空装置、ウチはプロですなんて言っていた者は新品のミニポンプで商売しているものです、修理が出来ないから新品なのです。少し考えればわかる事ですが無知ですから仕方ありません、そういう悪状況をどうにかしてあげたい・・・そういう理由ではじめました。ただし限りはあります。
御求め後のメンテナンス・修理・質問等も随時賜れます、御気軽に。
★他にないポンプスピード関東は３００～関西は３６０Ｌ/分！！！
あと少し予算があれば450～550を用意できるかも、相談下さい。
★デシケーターサイズ最大深さ３３ｃｍｘ直径３３ｃｍ！！！３０ｘ３０ｃｍでも製作可能
★操作は減圧レバーとスイッチの２タッチのみと超簡単！！！
★プロならコレしかありません！！皆さんが行き着くのもコレです！！
★希望価格でアクリル板付き。
★排気はホースによる屋外排気で健康・安全。
★真空計 別途５０００円必要です、部品代だけです。
先日ラストの４５０が出ましたので３６０もラスト１台です。
細かな希望を賜り、部品注文から始めますので
納期は３週間～１カ月必要です。
メーカーのメンテナンスキット取り寄せは２カ月待ちなので
制作は早い方です。
色々案件がありますので納期には希望的観測を持たないようお願いいたします。
２月のイベントで使うなら最後のチャンスですね！
大型装置の製作も最後の１台です。もうこのあたりでいいと思います。
小型とは部品１つ１つ重く細心の注意と精度が必要で
まったく勝手が違うので納期が２～３週間掛かります。
納期は譲れませんので計画期間前倒しで検討・御求めください。（＾＾
2月に使うなら
練習兼ねて今回手にするべきです。
早い者勝ちでラスト1台。(^_^)
近年までは
５０Lエアコンミニポンプで脱泡機が、この１４万円の値段だったと思います。
情報過多の時代の為
なぜか５０Lポンプが定説という情報があり皆さんが随分苦労していた現状を当方で変えてきました。
当方の大型のクラスのポンプを機械屋さんから買うとメンテ済みで１７～２０万円はします。
メンテナンスキットが５万円し作業も１週間掛かりなのでそれでも安い世界です！
デシケーター代やアクリル板代も確保できませんよね（＾＾
自作も良いでしょうが１万円近い様々な工具が１から要るので
数万円で作った真空装置などでは足元にも及ばないのは理解できると思います。
ポンプもバラして組めば性能が出る物ではありません！！！
メーカー・機種ごとに様々な組上げのコツがあります！！！
中古を使い捨てで使っては、いつかコノ金額を超えるでしょう！
性能も１２０％でないでしょう！
どの機種もマイナス０．１に到達して当然のポンプばかりですので
自作のノーメンテポンプが到達しなくて当然なので
皆さん誤解無いようお願いしますね！！！（＾＾
模型の趣味は元々御金の要る趣味です、キッチリやろうとすれば使う物はプロと同じ物ばかりです。
近年では原型もデーター出力機に掛けるなど
もはや一人で玩具メーカーでも出来てしまうような大変面倒極まりない世界です。
模型のイベント会場では、装置・機械を用いない作品作りでは
ライバルに差をつけられるばかりでしょう。（模型の情的には、さみしいばかりですが＾＾；）
イベントの売り上げ１度程度で
今までの外注複製代金の負担を軽く出来るのも魅力でしょう！
製作期間もギリギリまで組めるのも魅力でしょう！！
仲間みんなで購入して、みんなで使うのも楽しいでしょう！！
模型イベントに！
仕事に！
というのなら
最後に辿り着くのは
コチラの装置なんですよね！(^ ^)
操作は簡単でも挌は違います。
同じ装置を使い、10年は愛用でき、年間1000個生産は当たり前に
こなしていますので、すでに実証済みのマシンです。(^ ^)
他では全く出来ないシロモノです
自作の皆さんも300～550クラスからは
流石に始められずに、うらやましく思えたと感じます。
正直、別世界ですよ(^_^
知らずに真空装置なんて語れません。
ウチでは私自身が1000クラスを使っています。
流石に大人二人分の重量120kgを超えるクラスなので
設置を考えてしまうのが現実問題でしょうね。
しかし大型は確実安心な性能と引き換えに
装置製作は凄く大変で
部品一つでも数kgあれば組立時の怪我も怖いものです…苦笑
小さいもの、薄いもの、細いものの型取りは当たり前！
大きいもの！複雑な形状！カタマリのような体積のあるもの！！は
別格！プロ用！全てをこなす！デシケサイズ直径＆深さ３３ｃｍもの大型・
安心のコチラのマシンです！！！（＾＾
心強い生涯の相棒になる事間違いなしで、皆プロフェッショナル御用達の機種です！！！
真空装置・・・さっぱりワカラナイ・・みんなそうでした。（＾＾
情報過多に
惑わされずに
本当のところの使い方・型取＆生産トラブル回避なども満載です。
簡単で面白いように生産できますよ！（＾＾
当方でもメインで使っている機種です。
年間１０００回以上の運転をこなす頼れる相棒ですよ。（＾＾
一昨年前では相場で１２～１５万円を出して皆さんがなぜか
極小５０Lポンプにコップ一杯程度のシリコン型しか入らない程度の装置を
買われていたと思います。
良い時代になったと思います。皆さんが
「もっと以前からコレがあれば・・・」と、おっしゃって下さいます。（＾＾
模型の展示即売会などのイベント向けのフル生産にはコレっ！！とプロの皆さんが大満足の装置です！（＾＾
特に
プロのなかのプロの皆様が
好まれるクラスですっ！！！
もちろん、使い方はガッチリ、バッチリお教えしておりますので
初心者の方でも
イキナリ使いこなせます！！（＾＾
在庫切れの場合は、中型をオススメいたします。
お急ぎください！！！
ポンプを１からバラしての装置製作も大変なのですが、空き時間の都合もありましてご紹介最後になります。(^ ^)
丁寧に空き時間でゆっくり作りますので御届けまで最大二週間掛かります。
大型のポンプはポンプ自体が４５ｋｇと人一人分ほどの重量で
各部品も５ｋｇ、モーターが１１ｋｇと重厚で重く
ケガなども気を付け、細心の注意を払いながら組上げ作業を行います。
20万円で落札の場合は排気速度60秒450～500リッターもの
ポンプでおつくりします。 もう別世界ですよ。（＾＾
空いた時間を使って、御希望の部品で装置を最後に「１台」だけ御作りできます。
レジンキャストでデシケーターが汚れた場合はアセトン液でウレタンを
柔らかくして除去できます。他にデシケーター内にシリコンやフッ素塗りつけておいても良いです。（＾＾
デシケーターサイズや真空計の有無など
ご希望賜り部品が来るまで一週間かかります。
納期の期間は十分みて御求め御急ぎ下さい。
真空装置ときいて・・・どのようなイメージをお持ちでしょうか・・・？
真空になれば、どうにかなる‥…
答えは
どうにもなません(^ ^)
大抵どうにでもなると思うでしょうが実際
知らなければどうにもならない場合はどうにもなりません。
装置だけ真似てみても
何かが１つでも違えば
やっぱり成功しないのが真空脱泡機です。（＾＾
他の方で
１～１０まで徹底してフォロー、レクチャー、サービスしてくださる奇特な方が
近くにいれば良いでしょうが、現実問題は「素人面倒極まりない」で
門前払いだったと思います。
そのへんも含め御助けいたします。
過多な情報に惑わされていた方は
「自分なりに考えて思っていた事とは全然違い、簡単に扱えた！！」と
毎度、御好評頂いております。（＾＾
落札されてから
用途・目的に合わせて
御相談と
仕様の変更出来ますので御気軽にどうぞ。＾＾）
たとえば
専門業者などで
ポンプ、メンテナンス、デシケーター、アドバイス料を
除いて・・・
装置製作の作業代だけでも１０万円出せたとしても
門前払いでしょう。
本来は
何千万円という企業・工場向けの御仕事だからです。
面倒な素人や個人など相手にしてくれません。
結局、新品のポンプが４０万円前後で
ポンプはとりあえず手に出来ても
真空装置・・・としては、まだまだ御付き合いに御金が必要でしょう！笑
かといって
ご自分でされるにしても
間に合わせ・・・のものにしかならないのは当然です。
いい加減な組み合わせと
ノーメンテナンスの
調整の出ていない
ポンプでは
数値が出ずに
「このメーカーのポンプが悪い・・・」など発してしまうのがオチです（笑
ポンプは中古でも
★新古のようなメンテナンスがなされなければ数値は出ません。
そのような
面倒・ウェブで飛び交う誤認・誰にも聞けない・誰も知らない・知っているという者に限って知らない世界を
この
１度の機会で全て解決できます。
以後のメンテナンス・修理・作業の質問なども
随時賜っております。（＾＾
それでは
装置の御案内です。↓
ポンプは
本格工業用真空計で
マイナス０．１を指すほどの物で
（ポンプが温まり本調子になると振り切ります。＾＾）
排気速度は６０秒で
関東で３００リッター、関西で３５０リッターも排気スピードのある
工業用
高真空ポンプです。
モーターは
家庭で使える１００ボルト仕様です。
（たとえば中古ポンプだけを購入し
整備に出しても
モーターの載せ換えや
配線・スイッチ・吸気管系や排気系までは
金額が折り合わず
面倒がられますし
先ずは
門前払いだと思います。）
そのあたりも
御時間だけ頂き丁寧にみて破格で作業しております。
デシケーターは縦横３０ｃｍか縦横３３ｃｍを
お選びいただけます。
真空と聞くと
どうにでも出来そうですが
実際、部品一個から見て整備したポンプでしか
きちんとした数値などでません。
真空度も大事ですが
引きに時間が掛かっていては意味がありません。
必要以上と思われるような
排気速度が
１/６フィギュアや、カーモデルの生産では
重要となります。
いままで小さいポンプで
失敗した方、いろいろなことが
信用できなく
疑問かと思います。
そんな悩みを今回、この１台で解決できます。
様々な情報が混在する昨今、
他人の意見に流され
何が本当のところなのか
解らなかった方や、初めてで失敗が嫌な方、
本業の造形師の皆さんに
御使いいただいているものですので
オススメです。（＾＾
釣り具、フィギュア、カーモデル、人形ドールなどなど
様々な
作品作りの御役にたちます。
真空装置で、お悩みの方是非最後の１台をどうぞ。
フィギュアをされる方には
イベントに向けてスケジュール的に
今回がラストチャンスですね。
装置で作品作りの御手伝いに貢献できれば幸いです。
★超大型は、これで最後になります。★
併せて 最後の 御案内になります。 ありがとうございました。
今後は、御求めになられた皆さまのメンテナンス・修理になります。
★出品しているもので装置販売は最後ですので御了承ください★
カーモデルや
人形ドール
６分の１フィギュアや
釣り具のルアーなどで秋刀魚ほどのキャスティングを
行うのであれば
こちらの装置が適合致します。
真空であれば
どうにかなると思われがちですが
エアコン工事向きの真空ポンプの低真空と、
工業用の高真空では
全然違います。（＾＾
ポンプは今までの
どのメーカーよりも丈夫に作られており
部品の厚みも十分で
使い方さえ間違わなければ
シール部品の交換だけで長年大丈夫と思われる
素晴らしい作り込みになっております。
数多くのポンプの扱いで
１、２位を争うほどの良い工業用高真空ポンプです。
縦３３ｃｍ横（直径）３３ｃｍのデシケーターで
関東３００（関西３６０）リットルの排気スピードもの
組み合わせで
立体作品に必要な
真空装置本来の性能と機能をお届けいたします。
・コンパクトで少油量の直結型のポンプです。（＾＾
・メンテナンスもオイル交換くらいです。
・オイル使用油量もベルト掛けの５～６分の１で済み経済的です。
カーモデルはもちろん
アクセサリー
ボリュームのあるフィギュア
１/１００メカ・ロボット
戦艦・船舶模型
ルアーキャスティング
などの
製作・
型取り・
量産・
生産が
可能に
なるアイテムです。
【ヤフー簡単決済】の
カード決済
も利用可能に
しております。
後で必要と
御考えの方も
必要な頃には
無くなっております！！！
ゆっくり御考えの方には大変申し訳ないのですが
当方の時間都合で
行っていることなので
装置が有る
この機会にに是非、御求めください。
真空ポンプ３００Ｌ（関西３６０L）と
デシケーター（内径３３ｃｍｘ深さ３３ｃｍ）のセットです。
真空計＆配管を別途・５０００円実費で取付可能です。
アクリル板があれば
即使用可能です。
アクリル板別売です。
板は格安購入先教えます。
【必ず 板厚 ３ｃｍ（３０ｍｍ） です！！】
★小さいポンプでも２ｃｍ厚は厚壊事故につながります！！御注意ください★
★５０～８０リッター引きのポンプで
ガラスデシケーター、
ポリカデシケーターは
圧壊させてしまう事故が出ているので
そういったセットで
１０万円ほどのものは買わないのが無難です。
使い物になりません笑★
当方の装置では
プロの造形師さんたちに愛用されておりますので
性能も１分で３００～３６０リッター引く驚愕のポンプです。
今回手にされる方は本当にラッキーだと思います。（＾＾
ここまでやるところは他にないですからね。（＾＾
大きいフィギュア
ドール人形
デザイン関係
カーモデル
釣り具
などを
される方に最適です。
静かなほうですが
重量がありますので
★「一軒家向き」になります。
もう
★大きい装置はありませんので
この辺でお決めになっていただければ幸いです。笑
★ポンプは安心の日本国内メーカーです。
★モーターは
１００ボルト一般家庭用コンセント使用に
載せ替えて
調整しています。
料金は落札価格に込みですので
安心下さい。
組み換え御時間は部品取り寄せから
組み込み・テストまで１週間必要です。
装置の占有場所は
１５インチノートを２台広げたスペースがあれば設置可能です。
とにかく
丁寧にやっておりますので
早め早めの
落札お願いいたします。
★別売のアクリル板は３ｃｍ厚です。
２ｃｍ厚だと１００L/minのポンプでも圧壊・粉砕します。御注意を！
購入先御教えします。（＾＾
★使い方で解らないことがあればメール・電話・
いつでも質問頂けます。
★初心者でも丁寧に御教えします。
★ポンプのメンテナンス等も賜れます。お任せ下さい。（＾＾
何も知らなくても
いきなり使えてしまう！！
そこは
とても重要な点です！
自分で装置を作る方もいると思いますが
知らずに
とりあえず自作してしまった方に
ありがちなのが
せっかく御金をかけて作ってみた装置で
シリコン型に数万円の御金をかけて
ウレタンキャストにも数万円使って
生産するも
失敗してしまう・・・ケースです。
ただ ただ
デシケーターにポンプを接続している物に
見えますが
それぞれ「理由」があってのものなので
ただの一つの
装置・ 工程 ・用意するもの ・型作り ・見るべき点など
間違えていれば
自分で真空装置を自作して何度も失敗し
永遠と失敗を繰り返す・・・・・
そんなことになりかねません。
私でも
散々苦労した結果
唯一、
スマートフォンに変えてからキャリアメールのアドレス宛にスパムが大量に来るようになった。
原因がわからないのでかなり気持ちが悪いのだけどどうしようもない。
ところで sp モードメールに twitter でいうところの report for spam の機能をつけるわけにはいかないのだろうか？
ワンタッチで匿名でのスパム報告と削除ができて、docomo がその情報を元にフィルターを作ってくれればかなりよい精度でスパムがはじけると思う。各キャリアメール以外をすべてフィルターするみたいなほとんどばかげた設定よりもかなりましになると思う。例えば、いわゆるスパムではないのにわざとスパム報告をするといった嫌がらせが起きたとしても、報告数の閾値を1000くらいにしておけば十分だと思う。
現在ではスパムメールはトラフィックのうちわずかな部分しか占めていないと予想されるので、docomo がそういうシステムを作るメリットがないのだろうと思うけど何とかならないかなと思う。
・庭で飼っている犬の側に、あげた覚えのないサバ缶の空き缶が転がっている。
うちのばあちゃんが、野良猫がシーチキンの缶詰を盗んでいくから困る！
といって激怒していたのを思い出した。
すごい形相で野良猫をおっぱらってるから、多分猫は缶詰なんて盗まないよ、って言ったら
猫は魚が好きなんだから間違いない、と言って
見ての通り缶も開いていて、中身も綺麗にない！と断言。
でも、猫はあの通りの猫手なんで、ここまで運べないよ、と言うと
シーチキンの缶は丸いでしょ？だから転がしてるの！とか
細長い缶とか果物缶は盗まれないもの！とか。
どうやって猫がシーチキンの缶を開けるんだとか
（昔なんで今みたいなワンタッチじゃなくて缶きりが必要）
猫がシーチキン缶を転がしている姿とか
色々楽しかったけど、それ以上突っ込まなかった。
ちなみにばあちゃんは叔父さんと住んでた。
fenrirを呼び出して(デフォルトではCapsLockキー)キーワードを入力して検索。これだけです。
fenrirを実行しても検索窓がひとつ現れるだけですがこのシンプルな外観の中に多くの可能性を秘めたソフトなのです。
ランチャってけっこう登録が面倒くさかったりしますよね。ファイルを移動すればまた登録しなおしたり。
fenrirにはファイルもフォルダも登録する必要がないです。(もちろんスキャンは必要ですが。)
ユーザーが登録していくのではなく、PCにあるすべてのファイル、フォルダをインデックスしその中から絞り込んでいくという新しい発想のランチャです。
ファイル名かだいたいの場所さえわかれば縦横無尽にアクセスが可能です。
名前で絞込んで探すのはもちろんファイルの名前は分からないけどだいたいの場所だけ分かるという場合。
簡易ファイラとして上位ディレクトリ、下位ディレクトリに移動可能。もちろんフォルダ内のファイルも一覧でき、絞込みもできます。
もちろんファイルを探してから実行するというアプローチだけではありません。
インスタントコマンドという特定の文字列を入力することで特定のアプリ、ファイルを呼び出すことも可能。
私のfenrirを例に挙げると /fを入力すれば即座にFirefoxが。/oを入力すればOperaが起動します。
この機能を応用してファイルのリネーム、ファイル名のコピー、ファイルパスのコピーなどができます。書く場所間違えてた…orz
ぜったい使わないファイルが候補に出てきてうっとうしい？お任せください。
スキャン設定も充実。スキャンするファイルの種類、除外したいフォルダなどが設定可能です。
当然のことながらインデックスするファイルを絞り込んだほうが動作も速くなります。
「fenrirScan」という外部ソフトを使えばさらに細かい設定が可能。
例えば普段動画プレイヤーで開く動画を編集ソフトに送りたいという場合そのファイルを選択しSHIFTとENTERを同時に押すことで動画編集ソフトに渡すといったことが可能になります。
もちろんこのキーは自由に変更可追加可です。
CTRL,SHIFT,ALT,Windowsキーに対してENTER,A-Z,数字,ファンクションキー,クリック,右クリックまで割り当てられるため自由度はかなり高いです。
この機能を応用してファイルのリネーム、ファイル名のコピー、ファイルパスのコピーなどができます。
前述したインスタントコマンドを応用することでfenrirからGoogle検索も可能。（結果はブラウザで開きます）
実用性は微妙ですが外部スクリプトと連携することでfenrirからTwitterにポストすることも可能です。
どこまで有能なんだfenrir
便利そうだなと思った方はぜひ使ってみてくださいね。
http://www.forest.impress.co.jp/lib/dktp/desktop/launcher/fenrir.html
分かりやすい解説
こんなすばらしいソフトを作ってくれた作者さんありがとう。
既に日付が変わってるが、少し前に晩飯を食ってたらテレビで流れてた。何ともなしに漫然と見ていると、とあるクイズが出題された。
アウトドアで女性に人気のタオルに施してある工夫とは？とかいうやつ。
正解は「フードとしても使える」というものだった。真ん中あたりがフードの形状をしており、首にかけておけばそのまますっぽりと頭が隠れる。
なるほど、日焼けが気になる女性には魅力的な商品なのだろう、と、そう思った。
で、回答者の中の、二人組のお笑い芸人みたいなのの回答が「ワンタッチで濡れタオルになる」というものだった。俺には「？」な理屈だった。
そして次の出題。何千円もする団扇が大人気だという。普通の団扇よりも涼しい風が発生するその理由は何か？というものだった。
正解は「水に濡らして扇ぐ」だった。細かい水の飛沫が顔の辺りにかかって涼しいらしい。
・・・おや？
もしかしてこの芸人、この問題の正解を「タオル」の方に間違えて書いてしまったんじゃないか？
そして次だかその次だかの出題。「鮫(サメ)」という漢字の「つくり」に「交」があてられているのは何故か？というものだった。
頭の中がアレな事で有名な我らがサッカー協会会長様から、先日このような提案がなされた。
すでに地方協会訪問の際に、「１０-１５歳の育成世代でバックパスをさせてはいけない」と地方協会幹部たちへ指導方針の通達を始めている犬飼会長。ドイツのような“ルール化”まで視野に入れる。育成世代の試合でバックパスを出した場合は警告を出したり、プレーをその場で止めるなどの特別規則が導入される可能性まである。
http://www.sanspo.com/soccer/news/081108/scg0811080504000-n2.htm
なにをもって『バックパス』と見なすのか定かでないが、仮に記事後段にあるようにラグビーの逆、「後方へのパス一切禁止」という事であるのならば、これはもはや別の競技である。
よって、このルールの元で行われる競技をア式蹴球ならぬ犬式蹴球と定義し、そこでの戦術を考察したい。
犬式蹴球においては、縦方向のパスコースが切られるのは鉄板である。さらに横パスのインターセプトも常に狙われる。そこがアタッキングゾーンならばドリブル突破を狙うべきではあるが、そうではない低い位置ならばどうか。横方向へドリブルしつつ縦を空け、前方へのパスの相手を探るのが正解となるだろう。守備者の圧力を受ける為、実質は斜め後方へのドリブルとなる。
この、「進行方向に対して斜め後方を見ながらのドリブル」というのは基礎練習に組み込むべき基本動作と言っていい。
マイナス方向へのクロスが入れられない為、コーナー付近やゴールライン近くは完全なデッドゾーンとなる。えぐればえぐるほどパスコースがなくなってしまうのだ。
サイドでボールを受けた選手は、早いタイミングでアーリークロスを入れるか、中へドリブルで切り込んでいくしかない。
上記デッドゾーンに追い込まれない為に必要となるのがこの「逆ウェーブ」だ。
本来のサッカーにおける「ウェーブ」とは、ボールホルダーの後方内側にいる選手が、ボールホルダーの後ろを通り外へ回り込んでいく動きを言う。これによってサイドの数的有利とマークのずれを生じさせる戦術である。しかしながら、犬式蹴球においてはむしろデッドゾーンへ誘い込まれる危険性が増すため有効とは言いがたい。
有効なのは全く逆の動き。ボールホルダーの前方外側にいる選手が後ろから内側へ回り込んでいく。この動きで横パスを受ければ前を向いてボールを持てる可能性が増える。
トップの選手へのパスはスルーパスでなくてはならない。マークに付かれている状態で足元へ入れてしまうと次の手がなくなる。『落とす』ことが出来ないのだから。（よって、3人目の選手が飛び出すという動きも無意味である。）トップの選手はむりやり振り向き突破を狙う他ない状態となり、これはかなり困難を伴う。
それでは、犬式蹴球においてポストプレイヤー・ターゲットマンが不要であるか、というとそうでもない。相手最終ラインの選手は自分の後方へボールを落とされる事を嫌う。キーパーに返せないのだから、後ろ向きでボールを追う形となればタッチかコーナーに逃げるしかない。よってフィードボールは無理にでも跳ね返さざるを得ず、そのセカンドボールを狙う戦術が有効となるだろう。深い位置からボールを繋ぎ組み立てていくのはあまりにリスクが大きいというのもある。極論すれば、相手センターバックにわざとボールを渡し、そこを奪いに行くほうが効率的なくらいだ。
深い位置でスローインを得た場合、近くの選手に入れてしまうと手詰まりとなる。よって、直接フィニッシュが狙える位置まで投げ入れられる選手が、チームに最低1人は必要。
上記した通り、ゴールキーパーとの間にボールを落とされるのは避けたい。また、ワンタッチで入れ替わられるのを防ぐ為にも、ある程度距離を取っておく事が必要だろう。最終ラインの選手は無理にインターセプトを狙わず、いったん楔を受けさせ、その後詰めて振り向かせない形が有効か。
犬式蹴球の守備は基本的に縦方向のパスを警戒する形となるが、サイドだけは例外となる。ある程度の深さからは縦へ縦へ繋がせ（あるいはドリブルさせ）、デッドゾーンへ追い込むべし。
ドリブルが大きくなった相手に対し、ボールと相手の間に体を入れる。これは決して良い奪い方とはいえない。プレッシャーがかかった状態で後ろ向きにボールを持つ事となり、手詰まりとなる。
これはむしろ守備というより攻撃か。上記のように最終ラインの選手が後ろ向きでボールを持たされた場合、バックパスができないのだから、ゴールキーパーはエリアを大きく離れて（少なくとも横並びの高さまで）ヘルプに向かう必要がある。
犬式蹴球は放り込みやパワープレイ、力任せのドリブルをベースとした大味な競技となる事が予想される。また、その特殊性により、場合によってはサッカーと正反対の戦術的セオリーを持つ事となる。
よって、犬式蹴球の習熟は、少なくとも「サッカーの強化」には不適であると考える。ゴールキーパーの足元の技術に関してのみ効果があるかもしれない。
まあ、彼が言ってるのは「後方へのパス一切禁止」という事ではないのだろうさ。「前へ仕掛けるべき状況で仕掛けなかった選手にペナルティを」って事なんでしょうよ。でもね、そんなのを『ルール』として明文化できると思う？主審が一定の基準でジャッジできると思う？若年層指導者は『消極的プレー』に対して今まで全く指導をしてこなかったと思ってる？
彼が言ってる他の寝言、秋春制だとか『最強チーム』だとか含め、彼は自分が銀の弾丸を撃てると思い込んでるんだろうな。自分の一言で状況が劇的に改善される、と。他の奴らは何もしてこなかったし何も考えてない、と。
