  |
はてなキーワード: パネルとは
なんでも、
その単語訳せなくてもう「IKIGAI」って言っちゃうみたいよ。
私の生きがいは、
出汁って言うのも、
なんか訳しにくいわね「DASHI」でいいじゃないって。
第五の味覚としての「UMAMI」、
UHA味覚糖の「UHA」ってどういう意味なのかしらねって言うのも気になるわ！
鰹節に着いてる燻されてできる
黒い焦げみたいなのがタール扱いみたいになっちゃってるので
輸出出来なかったのよ。
現地生産ができるようになったので
フランス行ってみたいわね！
なんか最近食べ過ぎちゃってるので
朝食で調整リセット！
せっかくなので鰹だしで引いたおすまし汁、
またの名を鰹ウォーターとも言うわ。
ただのお吸い物よ！
すいすいすいようび！
今日も頑張りましょう！
彼らはヒエラルキーの頂点に立っている。
高校になると状況が変わってくる。
自分の場合は共学だが進学校だったので、そこまで男女交際は活発ではなかった。
ずっと補欠で一度も公式戦に出たことはなかったし、第一志望の大学には落ちた。
そして彼女を作ることすらできず、いや女の子とデートをすることすらできず高校を卒業した。
はじめて恋をした。アルバイトの同僚だった。福田沙紀に似た可愛い子だった。
慣れないながらも一緒にバイトから帰ったり、メールでやりとりをしたり。
ほんとに楽しかった。
めちゃくちゃ引いていた。
告白のタイミングも唐突だったし、自分のアプローチもウザかったのだろう。
「友だちとしてしか見てない」と言われ、あっさりフラれた。
死にたいと思った。
それが19歳の冬。
やがて20歳を迎えた。
「とにかくSEXをしたい。SEXをすれば変われるかもしれない。」
その一心だった。
ネットでいろいろと調べた。
ソープならSEXができ、デリヘル・ホテヘルはSEX禁止らしい。
いざ予約をしようとするが、ヘタレな自分はなかなか電話ができない。
そう、飛田新地だ。
20分1万6千円、顔を見て選べる、SEXあり、予約不要、モデル並みがゴロゴロ。
これだ。
そこはまさに楽園だった。
今まで縁のなかった、こんな可愛い女の子とたった1万6千円でSEXできるというのが、童貞には信じられなかった。
金を渡し、服を脱ぎ、フェラ。
そして、騎乗位での挿入。
一瞬だった。
こんなものか、と思った。
だが同時に、達成感を覚えた。ようやく男になれた気がした。
そして俺は風俗にハマった。
金さえ出せば、どんなタイプの女でも抱ける。
当時、サークルもしておらず、友だちも彼女もロクにいなかった俺はバイトばかりしていた。
趣味も特になかったので、バイト代が100万円近く貯まっていた。それを全部風俗に突っ込んだ。
飛田でモデル系やギャル系といったタイプを一通り抱くと、次は松島新地・信田山新地にも行った。
新地に飽きると、ピンサロ・ホテヘル・デリヘル・ソープ・M性感。
それにも飽きたらず、シンガポールのゲイランと香港の141に行った。
そんな豪遊の前に、100万の貯金なんぞあっという間に飛んだ。
だがいくら風俗で遊んでも、自分は素人童貞であるという事実からは逃れられなかった。
素人童貞を捨てたい。
実は風俗にハマりながらも恋はしていた。
何人かの素人の女の子とご飯にいき、セオリーにならって3回目のデートで付き合ってほしいと告げた。
だが全てフラれた。
たぶん自分には人として、男として、魅力がないのだと思う。
だから普通に女の子と付き合って、素人童貞を捨てるという考えは諦めた。
次に目をつけたのが出会い系だ。
ありとあらゆるナンパ本、ブログ、商材に目を通し、トークとエスコート術を学んだ。
なんかの商材に書いてあった通り、愚直にジムに行き、体を鍛えた。
はじめこそ不発だったものの、徐々に成果が出始めた。
当時俺は22歳だった。20歳で飛田新地で童貞を捨て、2年かけて素人童貞を捨てた。
1人だけ、合コンで知り合って彼女ができたが「つまんない」と言われ1.5ヶ月でフラれた。
やっぱり恋愛に向いていないのだと悟った。
今、俺はアラサーだが、たぶんこのまま彼女を作ることも、結婚をすることもなく、一生を終えるのだと思う。
多少の自信になったし、何なら飛田に行ってなかったらアラサーの今でも童貞だったかもしれない。
ウジウジと童貞であることに悩んでいるくらいなら、飛田なりソープなりで童貞を捨てた方がよいと思う。
だが、それと引き換えに、何か大事なものを失った気がするのだ。
･問題
自分のPCでだけ " Video Not Found " と表示される件。
･考えられる原因
PC (Windows) のインターネット接続が参照しているDNS鯖(プロバイダから指定されているもの)
のエントリが壊れていて、ドメインの解決が上手くいっていない可能性がある。
PC (Windows) が参照している DNS鯖 を手動で設定し直す。
ここでは、 Google Public DNS を使うことにする。
｢スタート｣ → ｢コントロールパネル｣ → ｢ネットワークと共有センター｣ → ｢ローカルエリア接続｣ → ｢プロパティ｣
→ ｢インターネット プロトコル バージョン4｣ を選ぶ → ｢プロパティ｣
ブラウザ (IE, Chrome, Firefox など) を閉じて、ブラウザを再起動する。
Xhamsterを開き、さきほど見られなかった動画を試してみる。
エクスプローラ内のファイルを開くとエクスプローラが全部落ちてしまう
こりゃいかんとコントロールパネルを開いて項目をクリックすると落ちてしまう
・・・など
ググるといろいろ対応策が出ていたが自分には効かず、街の中を奇声を挙げながら
走り回りたい気持ちになった
結局、ユーザーアカウントを新しく作り直しておかしいアカウントをポイしたら本来の挙動に戻った
ただ原因が分からないので恐怖は残ってるけど
これを機にまたおかしくなっても気軽にポイできるよう、またセキュリティのことも考え標準アカウントをメインに
使いたいと思う
--------------------------------------------------------------------------------
※ 自分用追記＆誰かの役に立てば
5年は使うつもりだったXperia Z3 Compactが壊れちゃった。
やっぱりノーカバーノーフィルムだったのがよくなかったのかな。自分が裸がユニフォームだからって、スマホにも同じプレイを強いちゃ駄目ですね。
で、言ってもまだ使えるんだけどね、思い切って買い替えるよ。
先月車こすって10万円なくしたし、親に冷蔵庫買って15万なくなったけど、それ、は、それ。
自分へのご褒美は惜しみなく。
でも何にするかなー新しいスマホ。7，8年前からずっとXperiaだったから、さすがにSonyは飽きたし。
iPhoneにしてみようかなと思ったけど、会社で気になってる女の子、彼女が反林檎ファナティックみたいだし（街でiPhoneの着信のあのメロディ聴いて「ひっ」て言った）。
何かおすすめあったら教えてください。
現在、月面基地は原子力発電で使用電力を賄っているわけだが、実のところこれがものすごく効率が悪い。
毎日毎日、何便も行き来する往復機の貴重な貨物エリアの一部を、この原子力発電に必要な資材が占めていることを考えれば、いかにももったいない。
月面基地の建設開始前は太陽光発電が考えられていたものの、いざ建築が始まれば大量の物資、人材、生活必需品を運び込む過程で往復機が頻繁に離着陸を繰り返したため、巻き上げられた大量の塵が太陽光を遮ってしまったのだ。
残念なことに、大きく舞い上げられた塵は静まる前に次の往復機を迎え、なかなか地面に戻れず、徐々に空中土量は増大していった。
と、まあ日光の遮光だけでもやっかいなこの塵なのだが、更にやっかいなのは太陽光パネルの上に堆積する事だ。
月面に風はなく、雨も降らない。火山灰の様に土砂が堆積した太陽光パネルは清掃するまで機能を果たさないが、この土砂除去をやるのは人力なのだ。
水は貴重なので洗い流す訳にはいかず、これも貴重だが、空気で吹き飛ばせばまた舞い上がって落ちてくる。
結局、刷毛で大まかな土砂を除去した後、掃除用の粘着ローラーで一枚ずつ掃除して行かなくてはいけないのだが、パネルの数は数万枚単位で、更に電力不足からまだまだ増設の必要があった。
これだけで貴重な人手を使い切る訳にもいかないので、太陽光発電はあえなく放棄されたわけだ。
ただし、急遽設置された（とはいえ、検証の上、数年がかりではあるが）原子力発電もかなり効率が悪く、かなりの資源を発電施設に投入せざるをえない状況である。
原子力発電を回すために往復機は更に増便せざるをえず、舞い上げられる塵は一層増大する。
しかし、実のところ、この塵も決して不利益ばかりをもたらすわけではない。
確かに、太陽光発電は妨げられる。その上、通信も妨害するし、往復機も傷だらけにして著しく寿命を縮めるが、それでも、人間が月面で常時活動可能になるメリットは大きい。
高熱に対してよりも極寒に対する準備の方がしやすい。
今までは直射日光が地面にあたる数日間はモグラのように基地に籠もっていることを強いられたが、現在では、かなり活動可能な期間が増えた。
今後の検討課題としては、現在の日陰を享受し続けるか、やはり日光を奪い返すかで協議が必要であろうが、我が研究室としては、課題の一環として月面の大部分に粘性のあるスライムを敷き詰める技術の開発に着手する予定である。
現時点では社名を伏せるが、太陽光パネル製作の大手と、有名オモチャ会社より研究支援の確約をえており、新技術は今後の宇宙開発において革新的な手法となると考えられることから、宇宙開拓史に名前を刻む勢いで頑張って欲しい。
（月面基地に駐在する研究者から、地上の助手達に宛てたメールより。なお、彼は日本の古いポップソングを愛好し、いつも口ずさんでいた）
Amazonに100万費やしてきた僕が「買ってよかったもの」をまとめて紹介する（おすすめ家電から雑貨まで） - Literally
http://tsukuruiroiro.hatenablog.com/entry/goodbuy
これを受けての物。
はてブでは100万という点に突っ込みが多いけど、どうも良いものが紹介されてるようには思えないので
www.amazon.co.jp/dp/B0001FTVE0
無難オブ無難。後継モデルはHD598（www.amazon.co.jp/dp/B0042A8CW2）。ほとんど変わらないらしい。
ボーカル向けとか言われてるけど、正直なんでも割と良い音すると思う。
www.amazon.co.jp/dp/B00J865EYY
寝室天井投影って単語にピンと来たら。解像度はWXGAなので注意。
FHD欲しいなら、最低限まともなものでこの1.5倍～する。
元記事の製品の自称"解像度1080×1920"は入力解像度であって、パネルの方は800*480。ほぼSD。
www.amazon.co.jp/dp/B00NYWALOQ
この辺の効果って実際には砂漠で砂粒洗うようなもんで、消臭効果は全て副作用で生成されるオゾンによるもの。
でも自分はオゾン生成器を生活空間で常時稼働する気にはなれないし、オゾン欲しけりゃ専用の生成器買うよね。
ということでシンプルな空気清浄器。部屋1つに1台で必要十分な感じ。
フル稼働するとうるさい。
www.amazon.co.jp/dp/B00238PCQY
睡眠の質は枕が決める。
あと、あのサイズのハンモック常用すると最終的に腰痛めるような。
ハンモックなら、大サイズのものに横向きに寝るならいいと思うけど、6畳間で対角の壁に張るくらいの大きさはいると思う。
www.amazon.co.jp/dp/B00LM3N5E2
国外製造輸入時代より味が落ちたという話もあるけど、干し肉自体がうまい。
ナッツ食いすぎると石できるよ。とてもいたい。
www.amazon.co.jp/dp/B005FM01HU
専門職用ウエスではキムワイプが定番だけど、日常における万能性はこっちのが上。
なんでも拭ける。
滅菌済みじゃないので、本職用途にはそのままじゃ使えない。
速乾とかマイクロファイバー布って肌触りが好きになれない。
www.amazon.co.jp/dp/4872574230
大抵のものはネットでデジタルで見られるようになったこの時代、本でしか得られない中の1冊。
www.amazon.co.jp/dp/B00FOHQZPI
普通安くならないこの手のものだけど、Amazonではたまにセールする。
この間は50%になって、これは通信教育+アカデミックのコンボとほぼ同額。
こういうリストって、趣味性とかこだわりとかを多少乗っけた方が、見る方も何か発見できるんじゃないのかなあ。
私も弊社のリフォームについて紹介させていただきたいと思います。
九州の小さい会社のやり方だから、業界全てに当てはまるわけではありません。
改めて書くと非定型商材にはよくある話です。
しかしリフォームを考える人はこういう裏事情も知って損じゃないと思います。
どういう仕組みの業界か？
どういう値段の決め方をしてるのか？
乱文ではありますが、お付き合いいただければ幸いです。
atk
・訪問契約率２０％のブラック企業の真っ黒な営業手法を書いてみる
http://anond.hatelabo.jp/20160526110823
・なぜ家電量販店で凄まじく値引ける（ことがある）のか教えてやる
(5/31 20:26 ブックマークありがとうございます。
罪悪感があるので明記いたします。
それを踏まえてどのようなお店で働いてるか、本文に追記しました。
ブコメに指摘ある通り、現場知識や管理手法を本当に身につけた営業は
値引以外でお客様を納得させます。職人からの信頼も厚い方がほとんどです。)
(そもそも匿名ブログですら度々追記するような営業って、不安になりませんか・・・？)
ハウスメーカーさんの子会社やデパートのリフォームコーナーではなく、
国道沿いにある「住まいのトラブル」といった看板を掲げたお店で勤務しています。
毎日お客様のお住まいを回り、無料見積や商談をさせていただいてます。
お住まいはひとつひとつ違い、お客様は様々な不満を抱えています。
同じマンションの同じ間取りであっても、家族構成が違うだけで、
そこにあるものを直すので、同じやり方は通じません。
私たち営業はプロとして、オーダーメイドの解決方法を提案しています。
ゆりかごから墓場までといった感じです。
6/1追記:弊社について
リフォームに用いられる施工知識は体系化が進んでいない分野ということもあり、
ではありません。
↓
であるといっていいでしょう。
では皆さんがリフォームを検討する場合、職人に直接声をかければ安くなるのでしょうか。
確かにその通りなのですが、職人に関する知識が無いと結構めんどくさいと思います。
建築職人は自身の職能分野且つ指示された内容の工事しかしません。
大工さんがペンキを塗ったり、電気工事屋が水栓を取り替えたりすることはまずありません。
「他人の仕事（＝専門）を奪わない」という前提ルールが職人の世界にあるためです。
例えば、水道職人にトイレのリフォームを直接お願いしたとします。
皆さんは、TOTOのHPを見て既設トイレの型番を特定し、楽天でリフォームトイレを買ったとしましょう。
ショップが親切でリフォーム用の配管アダプターもついてきました。
さて工事当日、水道屋さんがやることは、あくまでトイレを外して、付けるだけです。
工事中に、新築当初から使われていた排水管に問題が判明したとしても、
職人は直しません。指示をされてない仕事を勝手にやることはルール違反です。
また、床の痛みもクロスの黒ずみに気づいても教えてくれすらしません。彼らの専門外です。
まあ人が良い水道屋さんなら施主に教えてくれて、知り合いの大工さんを呼んでくれるかもしれません。
でもそれって、リフォーム屋さんとやってることは同じですよね。
上に上げた簡単な例でも分かるように、トイレの交換一つにしても不確定要素は多いものです。
中々定型化できません。だから私たちが売るサービスは定価が存在しないものになってるわけですね。
「お住まいによって施工方法が変わるから、正式な見積書を作るまではっきりした値段は言えない」
ただし、会社としては宣伝をする以上「値段は要相談」とはいかないので、
「トイレの交換技術料3万円！」「キッチンリフォームパック20万円！」
といったチラシが出るわけです。
まあ定価は無理でも参考価格くらいなら設定できる工事もあるのですが、大抵のチラシは客寄せのおとり価格じゃないでしょうか。
商品に関しては他の業種と同じです。
気になる工事費はご想像の通り、職人の日当に利益を載せているだけです。
弊社の場合、一人親方の職人とは「技術」ではなく「日当」単位で取引しています。
もちろんお客様に出す見積はお化粧します。「技術項目」にわけて書き直します。
| 施工 | 価格 |
|---|---|
| ◎水道工事 | /// |
| トイレ取り外し | \15,000 |
| トイレ取り付け | \25,000 |
| ◎内装工事 | /// |
| 既存内装除去 | \10,000 |
| 内装下地処理 | \12,000 |
| クロス貼り付け | \20,000 |
外すよりつけるほうが大変そうだから、取り付けを高くしよう。」
「あのお客さんはうるさそう。下地処理にお金をかけておけば納得するはず」
こんなものです。
実際に私の頭の中にある見積は
| 業者 | 原価 | 売値 |
|---|---|---|
| 水道屋1人 | \20,000 | \40,000 |
| 内装屋1人 | \15,000 | \42,000 |
こんな具合です。人数や日数を工程に併せて勘定して、自分が欲しい利益を載せます。
複雑な工事の場合、不測の事態に備えたリスクをマージンとして載せるときもあります。
(追記:ブコメで指摘を頂きましたが、大規模リフォームや知らない工事についてはさすがに職人と見積を詰めていきます。)
原価や売値はあくまで一例です。このトイレと内装工事は\82,000、
この値段だと、工事に詳しくないお客様でも、さすがに違和感があるでしょう。
私たちが商談する相手は、年配の専業主婦の奥様がほとんどです。
10%も20%もその場で値引きをしたらさすがに怪しまれそうなものですが、
事実なので、最初の値段が高くても疑われません。文句は言われますが。
「無料で見積！」をすれば、当然その手間をペイできる利益がたっぷり載っているんですけどね。
私はお客様の娘さんと同じくらいの年頃なので、それも有利に働きます。
結婚した娘と同じ年頃の営業が、私たちのために値引きしてくれている。そう思わせればしめたものです。
だから私たち営業は心置きなくドンブリ勘定で見積りを作成して、どんどん値引きします。
300万で売りたい工事の見積もりを400万で作り、50万値引きして契約できるときもあります。
(追記:ちなみに見積の技術を個別に発注しようとするお客様(上の例を用いればトイレの取り付けだけ頼む人)には、
職人のルール「他人の仕事を奪わない」に反する旨を説明します。
施工範囲がはっきりしない工事は、修繕というよりも破壊に近くなるためです。
それでもご理解頂けなければ危険な客と判断してこちらから手を引きます。)
皆さんがリフォームの見積をもらったときは、工期と人数について営業担当に質問するといいでしょう。
だいたいの原価がそれで把握できます。
大工、水道屋、電気工事屋、内装屋で工期は5日間。代わる代わる毎日3人の職人が出入りすれば、合計15人分。
彼らの日当を2万円として計算すれば、30万円くらいが工事の原価になりそうです。
リフォーム屋さんが利益を取るのは当たり前ですが、もうちょっと安くなる気もするものです。
チラシや競合他社を例にだして、どんどん値引きしましょう。見積書の「技術項目」の揚げ足を取るのも良いと思います。
粗利で30％ラインくらいが落としどころになるんじゃないでしょうか。
ただし、予期せぬトラブルが起きたとき、責任を取ってくれなくなるかもしれないので、
自己中心的で品の無い仮定になりますが、会社やサービスを潰してしまったら、
以上。
ポイントとしては
・工事内容の多様さと建築職人の気質を利用して適当に値段を決めている。
・値引きの幅に騙されない
って感じですかね。
(6/1 09:30 追記:
人工の例で出した日当2万円は一例です。地域や職能に大きく左右されますし、
期限までの工事完了に対して支払うこともあれば、本文の通り日当で支払うこともあります。
常用・請負、などで検索すると私より分かりやすく説明しているサイトがヒットすると思います。
地域によっては他の形式での契約や呼称があるかもしれません。)
(追記:リフォーム屋の言い値で契約=良い仕事をしてくれるとは限りません。
高すぎる利益はただリフォーム屋が喜ぶだけで、施工する職人の単価に影響するとは限らないからです。
逆に、値切すぎや急かしすぎは間違いなく悪影響を及ぼします。
日当が安い現場は早く終わらせて他の現場で巻き返す心理が働きます。
そして、痛い目を見た元請けの仕事に、職人は2度と近寄ってきません。
施主様と職人の情報の非対称性を解消することこそ、私たち営業の仕事なので、
適正価格の見積に納得いただけなければ、それは私の力不足です。
ただ、「良い仕事をする」「他人の良い仕事を褒める」といった文化も、建築職人の間に存在します。
この「良い仕事」はお金で動機付けされるわけではなく、お施主様の人柄であったり、
そのお住いを建てた当時の職人が残した「良い仕事」に影響しているようですね。
大工さんであれば、立派な木造建築の修繕には気合が入りますし、
水道屋さんであれば既設の無駄の無い配管に感銘を受けることもあるようです。
ですから、お互いが納得できる値段で契約して、出入りする職人さんときちんと接するのが、
一番「良い仕事」の恩恵を受けられると思います。お茶を出したりチップを渡す必要はありません。
彼らの仕事を尊重して、侮蔑しないだけでも十分良いお施主様です。
工事期間中、施主様と職人の関係を崩さず、職人から「良い仕事」を引き出していくことこそ、
(そのくせ、職人は愛想が悪いじゃないか！と言う方もいますが、
元請けをすっ飛ばして施主と仲良くなるのはルール違反、という考えの方も多くいます。
(注釈:本文の趣旨とは外れます。建築職人・一人親方といった、
家が建てられて維持されています。
少しの間だけでもその事実を頭に留めていただければ幸いです。)
おまけと言ってはなんですが、
A様宅は築35年の戸建住宅です。70代後半の奥様とご主人の二人暮らしです。
お約束いただいた時間に訪問し、名刺交換と簡単な自己紹介をします。
お電話で話したときの印象どおり、とてもにこやかなご夫妻です。
奥様が私を見て、東京に嫁いだ娘と同じ年頃だとおっしゃっていました。
雑談は親近感を上げるために重要ですが、この年代の奥様が結婚の話をするととてもめんどくさいです。
ほどほどに切り上げます。さっそくキッチンを見せていただきます。
キッチンの間口は2550mmサイズ、タカラスタンダード製です。キッチンに面した壁はタイルです。
部屋とキッチンの採寸をしていきます。ガスコンロや水栓の立ち上がりの位置も確認します。
ステンレストップはそのままで、スライド収納は絶対条件のようです。
奥様が饒舌な一方でご主人は寡黙です。カタログの値段を眼で追って表情がこわばっていきます。
「チラシはあくまで参考価格です。お住まいによって施工にかかる費用が全然違うんです。
A様の場合、40万じゃ厳しいです。」
チラシ商品は最低ランクのものであり、奥様のご要望に沿いません。
また、チラシのキッチンは6畳、壁はクロス仕上げで、ガスコンロの場合を想定しています。
広さはもちろん、壁の下地処理やIH用の電気工事が加われば値段は当然跳ね上がります。
奥様も顔色が曇りました。工事価格の変化は想像していなかったようです。
ご納得いただくために複数プランを提案させていただくつもりです。もちろん見積は無料です。」
「ですから、良ければ商品について、もう少しご要望をお聞かせいただけますか？」
私は食事はエンターテイメント性も重視するタイプで、例えば子供も喜んでくれる要素もそれはそれで商売としては大事なのはじゅうじゅう理解しているつもり。なので増田…というかブコメによく表れる本当にうまい●●を食べたことがない厨の人・寿司に●●万円出せない層は客ではない厨とは考えが合わないので、そもそもコメントは無用でござるが。
で、このかっぱ寿司の新しい形態の店は、外国人向けなのかどうだか知らんが、パネルだけで全部発注が出来るんだけどさ。ピンコーン、ウィーン、ご注文の品が届きます…。
一時過ぎぐらいに観光地のかなり人通りの多い店だったけど、あまり人が入ってない理由が分かった気がする。
まず、第一にそっけない。寿司屋に私が求めているエンターテイメント性（且つ味も美味しいとなおいいが）ではないのだ。
味は普通のかっぱ寿司より良いネタを使ってると店員に教えてもらったし、確かに値段も高め。
でもロボットサービスだけに高い値段払いたいか？と言われるとう～んだった。
なぜか、
知らぬ間にパソコンが勝手にWindows10になっちゃって、
何もしてないのによ！
何もしてないのに！
でも、こう言うのって私何かしちゃってるのよね。
なんかいろいろ調べたら元に戻せるらしいので元に戻して
次画面が開いたら、
あと15分後にWindows10にしますってカウントダウンが始まるじゃない。
なにこのまた勝手になる感。
戻している間にジャスコに買物に行こうと思ってたけど、
行かなくて良かったわ！
Windows10ってなにが良くないのかしら世間に総スカン食らってる感じがするわ。
ただ私に言わせたらWindows10は
あのために、パソコンを横向きにしておくのは負ける気がするわ。
この、押入から大量に出てきた8cmCDどうやったら取り込めるのかしら。
ホイミが売ってるらしいので
私もこのビッグウエーブに乗るわ。
そう！
ほいほいホイミ水よ。
きっと何かに効いて回復するわ、きっと。
きっと……。
私は信じてる。
すいすいすいようび！
今日も頑張りましょう！
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
続きです
私はZ君指名にしてO子ちゃんはフリー客ってことにしたので、いろんなホストさんがまわってくる。私はもう永久指名が決まってるので、名刺貰えなーい(笑)
永久指名ってなんだかすごいよね。結婚ですらいつまで持つかわからないのに、ホストさんを永久に指名するって。
口座とも呼ばれて、その人の裁量でツケにしてもらうことも可能らしい。私は「いつもニコニコ現金払い」をモットーにしてるのでツケで遊ぶのはあり得ないです。
☆他のホストさん
Z君が居なくなって最初に来てくれた子、S君がすごかった。顔は並（あとで見たら表に飾ってあるパネルの子だったんだけど、写真修正し過ぎて誰だかわかんない）で、若すぎるし好みでも何でもないって思ったんだけど、すぐに引き込まれた。物腰が柔らかで、騒音の中で酔っぱらって無茶苦茶な私の話をきちんと聞いて受け答えできて、発声が良いのか非常に話が聞き取りやすい。この人はどんな職業についても成功するんじゃないかと思った。っていうかまずは今やってるホストで大儲けだね！
そして目が普通の人と全然違う。カラコンのせいだけじゃないですよ。じーっと見つめる、清らかな赤ちゃんのような目だと思った。なんだか非常にやばかった。
なんで赤ちゃんを連想したのか、あとで気づいた。オキシトシンが分泌されたんだよ。母性本能、愛情、信頼が湧いてしまったのですね。うひゃ～
彼は指名ナンバー１の人だったようです。O子ちゃんが見せてくれた名刺、名前が筆ペンで手書きでめっちゃ達筆だった。S君、恐ろしい子！
こんな人が次から次へと来たらえらいことになる！と思ったのですが、あとは想定内に楽しいイケメン陣と、あまりお話もできない新人さんの玉石混合状態でした。ほっとした(笑)
他の賑やかなテーブルでシャンパンオーダー。「もう一本いっちゃう？よっしゃー２本！あともう一本？」とかマイクでわーわー騒いでて、結局女の子二人で５本はオーダーしてた。すごく楽しそうだったから良いのだけど、払えるのかなーと心配になりました。
その１ http://anond.hatelabo.jp/20160421233307
その３ http://anond.hatelabo.jp/20160423201058
元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
さて、この話をいつかはちゃんと記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。（またまた長文にて、失礼）
まず、1999年5月24日発表の郵政省資料「地上デジタルＴＶ放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください；
「また、昨年９月の暫定方式や既に答申がなされているＢＳデジタル放送方式、ＣＳデジタル放送方式の技術的条件において、実証実験を必要とする映像の表示方法とされていた720p（有効走査線数720本の順次走査による映像表示方法）について実験を行った結果、その性能が確認されたこと等が併せて報告されました。 この中で、720pは技術的にＨＤＴＶ放送と位置付けることが可能である、と結論付けられています。」（同上答申より引用）
関連記事は、日経産業新聞(1999年5月25日PP.3)、日本経済新聞(1999年5月25日PP.11)、電波新聞(1999年5月26日PP.2)などにも掲載されています。
今となっては、720pや1080pのプログレッシブ方式はプラズマや液晶テレビとの親和性、映画やCGなどの映像制作に有利なバリアブル・ピッチによる撮影、パソコンによる編集や再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年5月24日までの間、この720pを日本の放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。
私個人の主張、そしてマイクロソフトの立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。 米国の放送方式はATSCによるHD放送に向けた放送の標準フォーマットとして早くから1080i、720p、480p、480iが規定されていました。50年以上前に発明されたテレビ放送が米国に合わせてNTSC方式を日本は採用し、ヨーロッパ・中国・ロシアなどがPAL方式を採用してきた背景からすれば、日米のテレビ方式がデジタル・ハイビジョン（HD放送）の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマTVや液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつの映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視し映像を表現するフラットパネルの時代には、プログレッシブ（順次）方式が有利と思われました。さらに、映像圧縮に採用されたMPEG2方式においては、1080iは22Mbpsでは最高品質の映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像が破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらにMPEG2以外の圧縮方式MPEG4、H.264、WMV（現在のVC1）などを使えば8Mbpsから12MbpsでHD放送を伝送できるというのが、私たちの主張でした。
当時の私の主張をまとめると、「HD放送は1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人の認証、課金技術は特定技術一つに限らず、複数の技術をそれぞれもしくは組み合わせて提供可能とする。放送と通信の融合（連携）サービスを記述するメタ言語はHTMLをベースに各種プラグインそしてXMLに対応する。XHTMLをベースにしたBMLはそのサブセットとして組み込む。」
それに対して、1080i擁護派は、「1080iが優れた方式で、議論の余地は無い、プログレッシブの話をするなら帰れ!!」（実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん（E並氏）はとても紳士ですので、私は尊敬しております。決して誤解のないように）郵政省の会合でも何度となく放送のプロ達に諭（さと）されたものです。｢君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ｣「崇高な放送の世界を邪悪な世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。
将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。
当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業のHD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米の放送局でも沢山採用され、放送業界の権威あるエミー賞をDVC ProもHD D5も受賞されています。このD5というビデオデッキはNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタンを11個以上押さないと、（つまり二人の人間の指を駆使してボタンを押さないと720pの機能はアクティブにならないように細工がしてあったそうです。）..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類（たぐい）のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。
480pと720pの実験放送をやっていた日本テレビのSさんとKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術のトップの人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタル・ハイビジョンの映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果Sさん、Kさんは当然将来取締役が約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。
テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオ・スイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝と東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iのスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね？」という問い合わせが某局から入ったそうです。
TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画は純粋な技術的観点の選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro 720pを採択されたことが、唯一の救いと感じられました。
NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラを発見、JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネルの1080i/720pの文字列の720pの部分にはガムテープが張ってありました。
毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察の検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。
1998年のNABショウでマイクロソフトは初めて放送関連のコンベンションで技術展示をすることになりました（関連記事）。松下殿より当時500万円程したHD D5デッキをマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的な撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像に計算しなおし（アップスケール）、それをスダレのような偶数・奇数のフィールドに振り分け送出するという方式を取っていました（現在のデジタル・ハイビジョン放送の標準撮影方法です。）。そして同じ映像を1280x720の720p標準カメラで撮影しD5デッキに録画した映像をそのまま720ｐで再生するというデモ内容でした。映像の再生には当時の最高品質のCRTスタジオ・モニター(8000ドルクラスのSONY製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境で撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日のデモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトのブースを垣間見るや、とても渋い顔をしておられます。
私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員のホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人（私）が牢名主の親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。
そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか？何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下がマイクロソフトに協力して720pを推進するのはけしからんと、某放送局からお叱りを受けたと..それだけでも絶句の出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか？」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像をARIBの会員でもないマイクロソフトが勝手に使うのは如何なものか？」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明のパネルを書いて、某放送局の名前を実名で明らかにした上で、この名前の会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこのテープはここに置いて行きますが、夜中に誰かに盗まれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか？」と交渉は3時間を越える押し問答となりました。
その結果最後に明らかにされた背景は、某放送局の方から松下の役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!! それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当の役員がマイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当の役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープをマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネスの交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。
夜10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規に撮影を開始しますから、必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。 NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HDカメラ（当時は100kg以上あったと思います）とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオに見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラのライティング、撮影のオペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。
途方に暮れて困ったことは、深夜の12時にラスベガスのホテルで撮影できる生素材など有りはしないのです。それも著作権、肖像権を侵害せず、HD映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材（多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間に日中でロケハンに出かけることもできず、全てはラスベガス・ヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。
まず、深夜のルームサービスで果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてものを撮影しました。本格的なスタジオと違って光の回り方も映像のモニタを視ても、思ったような映像にはなりません。
夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌のカラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真を撮影してしまおうか？こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣を撮影すれば手彫りのエッチングで表現された人間の顔やお札の文様はHD撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣をビデオ撮影しても肖像権や著作権を主張する人もあるまい、という点が一番大事なポイントだったのです。
壁に貼り付けた50ドル札（私の持っていたピン札はそれしかなかったので）にバッチリとライティングを施し、撮影した結果は「キタ、キタ、キターッ」という感じ!!カメラをパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32
WINDOWS7をつかってたんですが、もう仕方がないので、WINDOWS10に
次から次へとOSやらなんやらを新しく作っていく必要があるのかなあ、と
思うんですが、なんなんですかね。
セキュリティーに問題があるなら、そこだけ変えるとかできないんでしょうか。
WINDOW10はWINDOWS7と比べて、コントロールパネルがどこにあるのかが
わからなかったことと、まったく必要ない無駄な機能がいくつか追加された以外は
どうやったら、こんな使いづらいブラウザ作れるんだ、というぐらい使いづらい。
と心底思いました。
なんていうか、前使ってたやつと根本的に使い方を変えよう、という
あと変換のやつも変わってて、予測変換がことごとく違うものがでてきて
いい加減に疲れてきた。
いろいろ変えるのは本当にやめてほしいです。
企業アナリストの同僚と話しててよく聞くのが「いくら政府が賃金上げろっつってもね、
ハシゴ外されたら責任取るのはこっちだから」っていう経営者の話。
よく引き合いに出されるのがシャープよ。
だいたい2006～2007年頃、第一次安倍政権や福田政権の頃だな。
「大企業は内部留保貯めこんでないで設備投資しろ」と政府からもせっつかれ新聞も煽り立てた。
しかしそこで「よーし、いっちょやったろか！」と立ち上がったのが、家電業界なら液晶や太陽電池パネルでイケイケだったシャープと、
景気に先行してまず瞬時に異常な信用収縮と円高が襲いかかった。
円高がひたすら進む3年間の始まり（円高自体はその前年からスタート）、その間シャープとパナソニックは
民間は信用収縮で誰も助けられない状態、政府は知らんぷり、円高なので海外資本も入ってこないし
株式市場も冷えきっている。優良企業でもPBR1倍割れが当たり前という恐ろしい市況。
よく分からない人は「100円玉が60円で売ってるのに誰も買わない意味不明な世界」を想像してくれ。
要するに政府を信用してないんだな。市況も見通せない。それはリスクそのものという認識。
そして消費者たる我々国民も空気が変われば石を投げてくる事を目にしてしまったんだな。
パナソニックは一時重体になりながらも耐え切りその体力で自力回復した。
ハイエンドのシェアは確保していてもいかんせん利益にはつながらない。
（ちなみに現在も4Kテレビ用パネルのシェアはシャープがトップだったりする）
誰も彼もが「コモディティ化」としたり顔で言い、性能は上でもわずか５千円高いだけで買わない。
といってもそういう認識ができるのは投資家くらいかも知れんが。
まぁこの辺りは株価のチャートに素直に現れているのでヤフーファイナンスとかで見てみるといい。
つまりね、政府が「賃金増やせ」と散々ケツを叩いたところで「よーし、やったるわ！」と
乗ったら負けなのをつい数年前に見てきてるわけよ。
逆にスルーした方が後で得するというインセンティブがあるわけよ。
給料上げても褒められないけどリストラしたら石投げられる（会社ではなく経営者はそう感じている）
何事にもそうあるべきと思う今日この頃なのです
http://japanese.engadget.com/2015/12/15/sun/の話。
（追記あり）
Woodland rejects solar farm
http://www.roanoke-chowannewsherald.com/2015/12/08/woodland-rejects-solar-farm/
まあ確かに変なことを言ってる人はいたけれども、それが議論の流れを決めたという根拠は特になさそうである。
これと比べるとEngadget Japan（及び本家Engadgetの記事）は明らかに盛っているというか
「田舎者を馬鹿にしてやろう」という意図で誇張があるようにしか見えない。
そもそも「太陽光発電が作られ始めてから、町の人間関係がどんどん薄れてしまっている」とか一言も出てない。
さて、大元の記事が12月8日に出た後で、アメリカの掲示板のいくつかでこの記事についての投稿がなされ、
「この元教師って創造説信奉者じゃねえの？」的な揶揄が行われたりといった事象は確認できたが、とりあえず12月9日までは大手メディアへの掲載は確認できなかった。
現時点で最初に大手メディアでこれに触れたのは12月10日付けの
https://www.rt.com/usa/325536-us-town-fears-solar-farms/
その後、英語圏の媒体（の信頼性の低いニュースが載るページ）に転載されたりするうちに尾ひれが付いていって、こんな形に育っていった模様。
しねばいいのに。
日本と異なり、アメリカには「郡に属するが市町村には属さない地域」がかなり存在する。
今回の発電所も、そういう形でウッドランド町の外に位置するものなので、町税対象にはならないようである。
ただし、そういう土地に公害を垂れ流す工場とかを勝手に建設されるても困るので、「域外管轄権Extraterritorial Jurisdiction」というものが自治体に認められている、ようである（流石に50州全部調べたわけではないので断定は避ける）。
ノースカロライナ州の場合、州一般法160章A第19条「開発計画及び規制」において区域外1マイル（人口に応じて拡大され、最大で3マイル）まで、自治体に権限が認められており、その域内であれば、制度上は、自治体内の土地と同じような開発の許認可権限を持っている。
http://law.justia.com/codes/north-carolina/2013/chapter-160a/article-19
ブコメ及びトラバで翻訳記事ではないかとの指摘があり原文を確認した。
http://www.engadget.com/2015/12/14/nc-town-fears-solar-farm-will-suck-up-all-the-energy-from-the-s/
…英語版もいい加減酷いけど、日本版はもっと酷いってことでいいんじゃないでしょうか。まとめサイトかよ。
ブコメとトラバで情報が得られたのでそれを踏まえて書き直しました。
追記前がどうだったか知りたい人は、誰かが魚拓とってくれてたんでそちらでどうぞ
http://megalodon.jp/2015-1216-0520-08/anond.hatelabo.jp/20151216033210
どのサイトを見ても楽しそうで現地の人も大歓迎ムード、町おこしに一役買っているとオタクを褒める内容ばかりだ。
実際そのアニメは出来がよく、普段アニメを見ることのない自分でも楽しめた良作だと思った。
当日はあいにくの雨だったが朝から現地入りし、会場まである地元民の車に同乗させて頂いた。
そこで何気なく「やっぱりアニメ効果は凄いですか。見渡す限り男性ばかりですね」と言うと、
事前情報として聞いていた地元民は協力的で喜んでいる、とは真逆の答えが返ってきた。
「そんなの、一部のお店と青年会だけですよ。
住むわけでもないのに騒ぐだけ騒いで、過疎化した町に何の恩恵もないです」
実際町を見ると、一部の商店街は所狭しとオタクが群がって歩いているが、店の方はただ店番が座っているだけ。
やる気のある？店もあるにはあるが、ほぼ八割の店がなんらアクションなく道行く人をじっと椅子に座って眺めている。
町おこしの観点から言えば、今売れるだけ売ってその資金を元手に改装をし事業展開をし、来たる日の為に延命を図るべきなのだろう。
しかし気まぐれに訪れ、いつ来なくなるともしれないオタクの為に借金を背負えるほど店主達は若くはなく、
跡継ぎがいるわけでもなく古い寂れた店構えのまま、ただ言われるがままにアニメキャラのパネルを置いて座っている。
オタクに迷惑はかけられることはあっても、金が入ってくるわけでも未来があるわけでもない。
そもそも本来こういった地方商店の休業日は日曜日なのだが、店の前を歩くオタクの為だけに、パネルを見せて写真を
撮らせるだけの為に日曜でも店を開けているという。
「知人の娘はコスプレしないんですか？とセクハラを受けるので接客業をやめました。今は水戸に住んでいます
このお祭りもこれだけオタクが多ければ地元民は誰も来ない。駐車場も使えないしステージは朝から占拠される」
雨合羽を着込んだファンが所狭しと並んで座っている。自分はそこの町の高校の演奏が聞きたかったが断念した。
「普通、地元の祭りなんて傘があれば十分なんですけどね…Aさんの町のお祭り、雨合羽持参で来る人なんています？
当然のマナーって言われるんですけど僕らのマナーはむしろ、見たいショー以外は退くのがマナーですよ」
もうこれは地元民の為の祭りではなかった。見渡す限りオタク。それもテンションの高い成人男性ばかり。
「税金を納めている地元民が楽しめない祭りなんですよ。儲かっているのはここに屋台を出している店と宿泊業と交通機関だけ。
それだけで後の364日を賄えると思いますか？364日を支えている地元民は今日一日じっと耐えるだけです」
早く去ってくれと願っていると彼は言った。
宿泊施設に勤める奥様からもお話を伺ったが、似たようなため息混じりの口調だった。
愛想笑いが辛いという。
「俺の嫁なんですよ！とか言われてもなんて返せばいいんです？気持ち悪いですねとも言えないし
この人たち全員独身なの？ってゾッとします。目がもう普通の人間の目じゃないです
ありがとうございます、と言うだけです。ここが好きと言われても好きなのはテレビの中のこの町でしょうに」
ましてやディズニーランドのキャストでもないし、演出を手伝う義務もない。
自分が見る限り、地元民の半数の目は死んでいた。愛想悪くふるまう住人も多かった。
でもそれはきっと彼らのせいではない。それだけの理由があるのだ。
聖地最高！と叫ぶのはいいが、本当に、本当にオタクが思うほど歓迎されているのか。
