「モニタリング」を含む日記 RSS

はてなキーワード: モニタリングとは

2017-12-13

anond:20171213133336

自覚があるのはすごくいいぞ。

簡単トレーニング方法としては、とにかく他人を喜ばせることを日課にすればいい。仕事でもセックスでもいい。

相手がどうすれば喜ぶか、だけじゃなく、相手が喜んでるかどうかを的確にモニタリングしつつ、

行動としてフィードバックする必要があるから、今の増田にとってはハードかもしれないが必ず役に立つ。

2017-11-15

次の行動指針を立てた

背景

目的

方法

実行

考察

  • 目的は達成された
  • どれぐらい時間かかった?
  • 2週間か。悪くない

2017-10-13

AVバラエティ化して抜けなくなってきている問題

毎週金曜日DMMの新作AVをチェックするのが恒例なのだが、最近AVバラエティ化していて抜けなくなってきている。

有名なのはSODのマジックミラー号シリーズだが、出ている女の子可愛いくて企画内容も面白いのだが抜けない。

他にも、モニタリングや家、ついて行ってイイですか?等のTV番組パロディ化したような作品も出てきているが同じくエロ面白いだけ。

AVファンタジーとは良く言った物と思いつつも、こうも抜けない作品ばっかりだとお金無駄だ。

AVに求めているのはバラエティではなく、エロいなのだ

そこで最近開拓したのはFC2コンテンツマーケットだ。ここは素人物の生々しいやつが多い。

以下は、現在巡回先の一部だ。これらはインディーズ作品って呼ぶらしい。

http://adult.contents.fc2.com/users/kanazawano/

http://adult.contents.fc2.com/users/hardcoreshinsaibashi/

http://adult.contents.fc2.com/users/hg/

S1かに出ているレベル美女は居ないけど、素人にしては十分に可愛い

明日花キララは見る分にはいいけど、抜くならリアルを感じられる素人って所だ。

リアル素人リアルな絡み。基本だけどそれが一番エロい

AV業界は色々な問題で厳しいのかもしれないが、積極的バラエティ作品を作ってる場合じゃない。

もっと抜ける作品を作っていかないと益々人が離れているという事をメーカーもっと考えて欲しいと思う。

2017-09-21

 一方、韓国政府はこれまで、「人道支援政治状況と分けて推進する」とし、「国連安保理決議でも禁止していない」と主張。米国も100万ドル拠出していると理解を求めている。

 統一省によると、人道支援乳幼児や妊産婦らを対象医療支援栄養食品提供する事業が中心で、国連児童基金ユニセフ)に350万ドル世界食糧計画WFP)に450万ドル供与する。現金ではなく、医薬品栄養食品などの現物支援を行うとしており、「転用可能性はない」(統一省)と強調。支援状況もモニタリングしていくという。 

https://news.nifty.com/article/world/worldall/12145-2017092100559/

現物支援なのでビスケット転用されるぐらいのもんでしょう

韓国脱北者団体はチラシとビスケットチョコパイを載せた気球北朝鮮に飛ばす活動を続けている。

http://www.recordchina.co.jp/b87567-s0-c30.html

まあ鳥がついばむぐらいのもんでしょう

2017-08-02

吉岡里帆スッピン写真が出回っているが

仕事の時と顔が違いすぎて、記者はよく判別できたな

モニタリングの時はメイクばっちりだった

あの番組はやっぱやらせなんだな

2017-07-06

https://anond.hatelabo.jp/20170706212017

しかし他の事ではすぐネットやらせやらせと騒ぐのに

モニタリングは言われないのは、もうバレバレから突っ込む方が野暮とみなされてるんだろうか

それとも知らないだけでネットの然るべき(どこかは知らんが)所では炎上してるんだろうか

2017-07-04

「徹底的な管理社会」はディストピア必要条件ではないよな?

https://togetter.com/li/1126352

ポストアポカリプスディストピアはぜんぜん別物だよ! ってとこまではいいんだけど、このディストピア定義もなんか微妙なんだよな~

そもそもディストピアってのはユートピアを裏側から見た図であって、

ディストピア本質は、誰もが認める望ましい性質を追求していたはずなのにいつの間にか怖い社会が成立してたって部分なんだよ。

子どもが産まれたら役所に届け出ろとか、適切な治療のために既往症の記録を共有しておくとか、前科者にGPSを埋め込むとか、脳モニタリング犯罪徴候を察知するとか、

国民安全幸福保証するために国家があらゆる情報管理する必要があると考えられていたからこそ、それを突き詰めたら怖いよね?っていうアイディアが成立したわけで、

プライバシー重視のパラダイム支配的になった今日においては逆に「国家が、あらゆる情報を徹底的に“管理しない”」、何もかも忘却されるような世界を描いた作品面白いと思うし、それもまたディストピアなんですよ

2017-05-22

発達障害だった(と思う)同僚と苦闘した話

先日のNHK特集はみていないのですが、ツイッターで流れてきたこちらのツイート




借金玉さん、有名な方ですね。

私は多分定型だと思いますが、この方のブログは参考になるので好きです。

このツイートを見て、まさにそうだよなあと思ったので、体験談を少し書いてみます


以前、職場で、発達障害らしき人がいました。

その人がカミングアウトしたわけではなく、というかその人自身自覚があったかも怪しい(多分なかったと思う)のですが、

その人と組んで約三年間仕事をした私は、彼女発達障害だったんじゃないかなと思います


仮にAさんとしますが、Aさんの発達障害らしきポイントは、


仕事優先順位が立てられない。どうやっても立てられない。何度言ってもできない。目の前にある仕事からやってしまう。

・極端に走る。少なめ、とか、多め、とかが理解できない。少なめと指示を受けたらゼロになり、多めといわれたら100になる。

・上の派生で、可能性の話が通じない。「おそらく~だろう」といわれると、Aさんの中では『決定事項』に変わってしまう。

・一つ一つの仕事は非常に丁寧だが、どれほど客が並んでいても同じペースで行う。状況に応じての効率化ができない。

・一から十まで話さなくては伝わらない。省略は非常に危険で、まず正しく伝わらない。


あとこれは、発達障害というより、彼女うつ病を患っている(これは本人が話した)ことから来ていたのかなと思うのですが、

・非常に頑固である。こちらが理屈立てて説明しても、まったく受け付けない。本人の中の妄想が最優先される。


この妄想というのは、主に情報の伝達に関してですね。

臨機応変に動くことが不可能である』『情報上司からの指示など)を脳内誤変換する』という合わせ技の上に、頑固さが加わると

まさに地獄です。

ものすごく自信満々に間違った指示を私に伝えてきて、それはおかしくないでしょうか…?と尋ねても、一切聞く耳を持ちません。

ちなみに私のほうが後輩で、彼女が先輩であったので、なおのこと大変でした。


先に書いておきますと、私は彼女がとても嫌いでした。

なぜなら入社して一か月のとき、私が些細なミスをしたら、その件で彼女に五時間叱責されたからです。

障害のあるなしに関係なく人を苛めることができるという例ですね。

それでも仕事のできる人ならば、いずれ尊敬の念も沸いたでしょうが、実際には上記のとおりでした。

私は彼女誤変換に悩まされ、振り回され、また彼女マイペース仕事をし続ける分、必死フォローしなくてはなりませんでした。



ここからが本題なんですが、

私は彼女がどうして『仕事優先順位を立てられない』のか、

どうして『極端に走る』のか、

どうして『情報誤変換して伝えてくる』のか、


本当にわからなかったわけです。

最初は、彼女には、この職種経験がないからだろうと思いました。

優先順位を立てるという仕事の仕方をしてこなかったのだろうと思いました。

彼女は三十代後半で、私よりも年上で、『やってできないはずがない』と思っていました。


そうではないのだと思い知るまで、二年近くかかった気がします。


ひとつ例を上げます


私は彼女と組んで仕事をしていましたが、私のメイン業務入力や処理であり、彼女カウンター担当でした。

私は業務上プリントアウトすることが非常に多く、プリンター彼女のそばにありました。

と、いっても、彼女から一歩、私から五歩程度の距離です。


私が印刷をかけるたびに、彼女は出力された紙を、私のところまで持ってきました。

お客様がどれほど大勢待っていても!


私は何度も彼女に言いました。

持ってこなくていい。自分で取りに行きますから。目の前のお客様を優先してください。

そういうと、三日ほどは、彼女は紙を持ってこなくなりますが、四日目にはまた同じことの繰り返しです。


些細なことに見えるでしょうが、相当にストレスでした。

彼女が待たせているお客様フォローを、私がしなくてはならないんですから

紙なんか持ってこなくていいかお客様対応を最優先してやってくれ!と思うのですが、

紙が出てくると、ダメなようでした。意識がそちらに向いてしまうのでしょう。


紙を持ってこなくていい、というのを、七回目くらいで、諦めた記憶があります


私はそうやって、ストレスに苛まれながら(彼女も同じようにストレスだったでしょうが

一つ一つ、彼女への対応の仕方を学んでいきました。いやおうなしに。


最終的に、私は、

・ある程度は、彼女に沿った対応をする(なるべく数字で区切って話すとか、一から十まで話すとか)

・八割方は諦める。

自分の身を守ることを優先し、彼女仕事が溜まろうともなるべく視界に入れない。


という境地に達しました。

できることを期待するから苛々するのであり、できない人なのだ認識してしまえば(まあそれでもイライラしますが)

少しはましになります


ここで一番最初借金玉さんのツイートに戻りますが、何ができて何ができないか、というのを伝えてくれるのは、

一緒に仕事をする人間にとって非常にありがたいです。


私は約二年間、ストレスと、いったいなぜできないんだ!?という思いと、どうアドバイスすればできるようになってくれるかという悩みに、

神経をすり減らしましたが、


彼女最初から、(発達障害だというカミングアウト別になくても良いので)、

自分はこういったことが苦手であり、こういったことは努力してるけど本当にできなくて、

こういった風に伝えてくれると助かる、という話をしてくれたら、


私もすごく助かったし、

あれほど彼女を嫌いになることもなかっただろうな、と思います



発達障害は、パッと見でわからいからこそ、伝えることが大事なんでしょうね。

2017-03-23

モニタリングってテレビ番組

人をハメる様子を盗撮した挙句ゲストとかが笑いまくってるのが不愉快すぎて辛くなった

2016-10-27

モニタリングって番組が末期のトリビアの泉みたいなことやってるけど末期なの?

2016-09-30

ゲスい考え

モニタリングスペースに最近テレビで見かけないあの人が・・・


ゲースゲスゲスゲス〜 ゲースゲスゲスゲス


そうなのです。

なんとそこには水森亜土ちゃんがいたのです!

2016-09-17

増田に書けばフィクションって事で済まされるよね! 33

最近遭遇のマジキチ女。30〜40くらい。



キチ女「(無言で入ってきて無人部署へ行こうとする)」

神主様「こんにちは。御朱印ですか?」

キチ女「朱印帳持ってきて無いので」

神主様「貼り付ける紙の御朱印ですね。ご用意します(日付サラサラ)」

キチ女「日付薄くないですか? もっとちゃんと書いて下さい」

神主様「は?(長い事朱印書いてるがそんな事初めて言われたんだが)…、数日前にあらかじめ書いた朱印部分と、今記入した日付では、どうしても濃さに違いが出ますので」

キチ女「(人の筆をつつく)この筆古くなってしまっているんじゃないですか、薄くてお葬式みたいじゃないですか」

神主様「(同じ墨使ってんだが)乾くまで少し待って頂ければ、色が定着して同じように見えますが」

キチ女「書き直してください」

神主様「…(使ってない筆を取り出す)」

キチ女「なんでそれ使うんですか、書き直すなんて失礼じゃないですか」

神主様「(書き直せって言ったのはお前だろうが)…(新しい朱印用紙を取り出す)」

キチ女「もういいです(退出)」



一同呆然

あー、キチ女。たぶん後で旅行サイトあたりで悪口書きまくったりするんだろうし、期待してるとこ悪いんだけど、アレだよ?

参拝者に失礼な態度取ったからアイツは後で怒られるに違いない!とか考えてそうだけど、

そもそも参拝者って神主様に対して失礼な態度取らないからね?

お前が言った言葉やつけた注文は、お前からしてみれば珍しくもない当たり前の事を言ったつもりなのかも知れないけど、

長 年 神 主 や っ て て 初 め て 耳 に し た レ ベ ル の 異 国 語 だ か ら 。

その場に居た人間は一人の例外もなく皆呆れてたんだけど?



朱印は、お金を払ったら神主野郎が見せる大道芸などではありません。

朱印は、お金をお納めして神主様に書いて頂く参拝の証です。

注文つけたり文句つけたりするものではなく、感謝をしておし頂くべきものです。

有難く受け取れ。



いやぁしかしいきなりあん非常識な参拝者が突然来るとか、モニタリングの収録か何かでもやってるのかと思ったわ。

つうか、実際はあの目つきから判断してもただのメンヘラ女だったようだが。鍵のかかる病室からもう二度と出て来るなと。

2016-09-13

豊洲市場 盛土問題についてよくわかる「技術会議」の話

なんかゆえあって資料あさって読んだからまとめとくわ。(追記したわー)

いま来た人向け

  1. Webで誰でも見ることが出来る資料だと、「建物地下の盛土を止めた」とは判らない
  2. 盛土せず、地下空間活用する案が議論された資料はある→その案が破棄された資料もある
  3. 区画で盛土完了の報告資料はある

専門家会議」も「技術会議」も、

公開されている資料を見る限りでは、

建物地下については盛土前提だねー

ちょっと詳しいまとめ

全然出てなくて「工事の都合で」なら、行き違いみたいな可能性も無くはないんだろうけど、

技術会議」で、「埋め戻しせずに地下空間を利用する」って案が出て、否定されてんだから

工事の都合でもその案に近い形になってるのであれば、説明しとかないと問題になるだろ。

最初感想

呼ばれた有識者は怒るだろうな。安全責任取れねぇよコレ。

現在のやり方が安全かどうか誰も確認してない事になってる。

結果的安全だろうとは思うけど)流石に専門家会議とか技術会議開いといて、こりゃないだろ、と言う感じ。

詳しい内容

全てのソース全部引用しても良いけど、読まなかろ。

ポイントだけ。

案-5:市場建物と一体となった対策

汚染土壌は掘削処理を行う。ベンゼンシアン化合物及び重金属を含む土壌は、洗浄処理を

行う。また、ベンゼンのみを含む土壌は、既設の都域内加熱処理プラントを利用して、処理

する。なお、洗浄処理プラントは仮設として、豊洲新市場予定地内または、その近傍地に設

置する。

建物青果棟、水産卸棟、水産仲卸棟)建設地については、汚染土壌の処理後、埋め戻し

(A.P.+2.0m~A.P.+6.5m)は行わず、この部分の地下空間を利用する。

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/6-5.pdf

(委 員) 評価が高かった案-1~5 のうち、案-4 については、原位置微生物処理のため確実性に

問題があり、案-5 については、土地の利用、機能価値問題が、経費に対して十分

プレイバックされないので、事務局としてはこれらを除いた案-1,2,3 をまとめて、そ

れぞれのよい部分を組み合わせて案をつくるということでよいか

東京都) その通りである

第9回会議録 p3

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/09kaigiroku.pdf

(委 員) 今日審議された案が技術会議での結論であるとして決定する。

同 第9回会議録 p8

技術会議において、「地下空間の利用」は第6回に案5として提案されており、第9回に破棄されてる。

○矢木座長 そうですか。わかりました。そうすると、今回の工事では2mよりも低いところは、

汚染しているものはみんな掘り上げてきれいなものを入れている。それから、2mと4mは全部掘

削して、きれいなものと入れ替えている。それからさらに、2.5mですかね、きれいな土を入れて

いるということで、要するに、4.5mはきいれいなものが積んであると、こういうふうに考えてよ

ろしいわけですね。

藤原課長 はい

第18回会議 p16

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/18kaigiroku.pdf

※報告資料において、5街区、6街区、7街区は、盛土完了しているとなっている。

「p11 3埋め戻し・盛土の完了確認

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/18-2.pdf

第18回会議において、

東京大学名誉教授の矢木座長から質問を受けて、東京都基盤整備担当課長藤原課長が答えている。

少なくとも、東京都の基盤整備担当課については、説明責任を果たさないとイカンじゃろ。

きれいなものを積んだとは答えた、答えたが、その後掘り出さないとは言っていない……!」とか通らんだろ。

蛇足

個人的には、都知事は良い落とし所見つけたんじゃないかな-

憑物落としの手法なんだけど、一回「コレが元凶だ!」って「悪い部分」を一箇所に集めて、それを解決するの。

建物地下の盛土無しについて安全性確認とって、それ以外のところの盛土完了確認とって、安全宣言出して終わり。

過去の悪いところは引き継がずに叩いて、どーせやらにゃならん都知事安全宣言は、自分のやったことに対して出す。

東京都の悪行」なのに「現行都知事の手柄」に出来そうなの、ホント喧嘩上手な感じだわー

(現状築地のほうがよっぽど危険って煽り方してないのもポイント高い。事実感情と擦り合わせてこその為政


追記

んー、資料つまみ食いして読むのは俺もやるから良いけど、ポイントポイントは読まないとイカンぜよ。

はてブにチョットだけフォローしとこう。

説明資料だと、建物部分は盛土も砕石層も無いだろ!(ID略)

藤原課長

(略)

なお、左側の範囲を示す図で着色のな

い箇所は建築敷地などに相当する箇所でございまして、土壌汚染対策工事とは別に、別途施設建設

などに合わせて液状化対策が行われております

第18回会議 p9 2行目

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/18kaigiroku.pdf

左側の範囲を示す図で着色のない箇所は、液状化対策でご説明したのと同様に建築敷地など

に相当する箇所でございまして、土壌汚染対策とは別に、別途施設建設などに合わせて砕石層の設

置が行われております

同 p9 17行目

砕石層と液状化対策については、「建築敷地については別途施設建設などに合わせてやってます」と回答してる。

地下水管理上限(A.P.+2.0m)に、砕石層(50cm)足して、盛土(A.P.+6.5m)するって話をして、完了してますって話で、

「別途施設建築に合わせてやっているとは言ったが、全く違うやり方だ」は通らんじゃろ。

技術会議参加者が責を負うなら「東京都がやったと言っただけでは信用せず、データを見るべき」になるが……)

A.P.+2.0m以降、建物建物別にやってっからって説明受けて、まさかノー盛土とは思うまい

なお、めんどくさいこと言うと、

後藤新市建設調整担当部長

また、一部どうしても場内の搬送車の置き場として地下を考えてございます。例えば雨水等を一

時ためなくてはいけないということ、雨水利用も考えてございますので、そういった意味で、一部

地下のピット等が出てくるということは想定してございます

専門家会議 第1回議事録 p23 23行目

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/senmonkakaigi/01/1gijiroku.pdf

地下にピットを作ること自体は想定されてたんだよね。

この辺の発言踏まえた上で、建物建設地と建物建設地以外の両方で盛土してねって提言されてんだよね。

地下空間だが、略図に書いてあるだろ!(ID略)

『②「地下水管理システム」の概要』にある、

建物部(イメージ)』の下にあるグレーの長方形ことな

②「地下水管理システム」の概要

※水質モニタリングを行うので、A.P.+1.8mよりも深いところにまで到達してる。

地下水管理システムに関する説明資料 p4

http://www.shijou.metro.tokyo.jp/toyosu/pdf/pdf/gijutsu/siryo/18-3.pdf

地下水管理システム浄化施設棟)については議事録でも触れてるけど、建物については下記の1行だけだよ。

建物部の下には地下水排水を促していくための地下水排水対策としての砕石層をこういうような形で設けさせていただいております。』p18 23行目

砕石層については触れてるけど、地下空間については触れてないね

うーん。

地下水管理システム浄化施設棟)」の資料渡されて、

概要図に「建物部(イメージ)」って書いてある建物の地下空間が描いてあったとして

何の説明も無く、これでもって「技術会議では出ている!地下空間があるのは理解しているはずだ!」というのは、どうかな。

叙述トリックみたいな引っかけ問題としては面白いかもね。実は描いてあった!みたいな。説明する立場でそれはナメてんのか?)

この流れで、「技術会議が悪い」みたいな報道とかは、ちょっと納得いかねーなー

実際上は問題ないんじゃないの?(大勢のため略)

豊洲市場敷地って、元々は東京ガスのガス製造工場

東京ガス株式会社が、平成13年2月平成19年3月で、地面から2メートル掘削して処理済みなのね。

から土壌汚染対策法上は、東京ガス株式会社土壌汚染調査&処理したところで完了してる。

あとは、「環境確保条例都民健康安全を確保する環境に関する条例)」もあるけど、

汚染土壌を、50cmの盛土 + (10cmのコンクリ or 3cmのアスファルト)で覆え、でクリア済み。

から、「法令上は問題ない」って言われると「最初からそうじゃろ」って返しになる。

ソレじゃ安心できねぇって都民のために、カネかけて二重三重対策打つから安心してよ!って話が発端なので、

そーゆーのは、「万全な土壌汚染対策」として「専門家会議」をやって「技術会議」をやって、

ちゃんとやります丁寧に説明しますって東京都方針が全部吹っ飛ぶので、たぶん言わないんじゃないかな。

雑感

安心安全」みたいな漠然とした基準だと対策完了しようがないから、

専門家に聞いて、技術的にも可能なやり方で、コストも考えてやるよ」ってプロセス立てて

で、そのプロセス通りにすすんでます専門家お墨付きもらってます問題無いですって話を進めてきて、

「実は専門家提言とか現実的じゃなかったんで、建築物独自にやりました。てへー」とか、そのひっくり返し方はダメだと思うなあ。

2016-08-04

kindle unlimitedで読めるバカ高い本一覧(1万円以上)

・通常価格1万円前後

・ちゃんとした出版社から販売されている

・内容も(おそらく)しっかりしていると思われる

以上の理由で選定した。

仕事ができる人は実践している 結果を出す為のビジネス書大全 (SMART BOOK) Kindle版

https://www.amazon.co.jp/dp/B01GFAY680/

\10,800

週刊東洋経済eビジネス新書 合本版 1~100

https://www.amazon.co.jp/dp/B00UJDDMMQ/

\10,800

新版 数字で分かる・実行できる工場問題解決対策事典: 問題解決必要評価指標の設定とモニタリング方法

https://www.amazon.co.jp/dp/B01DTJCBYQ/

\16,752

テクニカル分析迷信 ──行動ファイナンス統計学活用した科学アプローチ

https://www.amazon.co.jp/dp/B00MTJZE7O/

\7,884

【合本版1-10巻】魔術士オーフェンはぐれ旅 新装

https://www.amazon.co.jp/dp/B00UV6MYIY

\9,180

とりあえずこの辺は買っておいて損はないと思う。

10制限を考えれば合本版は便利だと思うので1番上のビジネス本まとめ、

あとオーフェンは入れておきたい。

2016-08-02

増田に神などいないッ

 例えば朝の通勤電車で、扉が開いて人が降りるのに頑なに動かない太った女性を見たとき自分は「死ねよクソデブ女。そんなんだからデブでブスなんだよ。スマホ見てないで鏡で自分の顔見て苦しんでろよ低脳。」といったような言葉を心の中でつぶやいてしまうのだけれど、周りにいる人達も心の中では同じことを思っているのだろうか、

 などというようなことを考えていたら自分のGメールの下書きボックスに見知らぬアドレスから依頼メールが「投函」されていた。

 あのクソデブ女のふとももにぶつかったときに生体IDをスキミングされたらしい。あれは増田デコイだったのか、と思うと少し意外だった。ほんとうに色んな増田がいるものだ。

 しかし、IDに紐付けられたセンシティブデータからアナログデジタル両面で各種個人情報(もちろんフェイク)を割り出してまで別の増田に会いたがるやつはめずらしい。

 メールにはスカイプIDが書かれていた。


 スカイプの声の主はかなり2000年代訛りがきついネット語をしゃべった。まるで、ここ二三年のあいだに定着した、ヤフーコメント欄に湧くおっさん一言居士パロディみたいだった。

増田さん。会うことができてうれしい。インターフェイス人格化、および友人関係樹立を期待する。よくないか? よくないですか? たくさんの提供することがある!!!

あんだって増田だろう――だが、『どれ』だ。あんた」

 私はあからさまに疑念のにじませた声でくりかえした。

「元はてなわんわんワールドとして知られるサービス現在増田匿名ダイアリーの人気記事の八割を著述している」

 ホッテントリ入り記事の八割――約三万二千ユーザーズに相当する。

 そんなバケモノ増田実在するのか。嘘だろう。まさかCIAの擬態か? 罠? いや、グアンタナモで俺のケツの中身をモニタリングするつもりなら、もうすこし出来のいい猿芝居を仕組むだろう。なんていったって、ハリウッドの国だ。ビリー・ワイルダーフランク・キャプラウォルト・ディズニーの国。

「そっちの通訳システム、どうもいかれてるようだな」

 耳にひっかかるグーグル・グラスのつるが薄気味悪く感じられた。煙のように存在感の希薄な多泡凝集体(エアロゲル)でできているかのようだ。気味が悪い。それは相手の精神状態も同様だった。

「ニェット――失敬、ノー。商用通訳ソフトを使わない非礼を陳謝する。商用通訳ソフトイデオロギー的信用不安が大きい。ほとんどが資本主義及びはてサ意味論に基づくペイ・パー・ユーズ方式のAPIを採用するからだ。ましてや増田語の学習がたやすい。どうか?」

「俺と話するためだけに高級ネット日本語学習したというのか?」

「ダー。やさしいのことだった。十億ノードの神経ネットワークを産卵し、〈ホッテントリ〉と〈twitter〉の過去ログを最大速度でダウンロードした。悪文法でエントロピーオーバーレイする非礼を陳謝する。悪文法を使う理由は、わたし=われわれの文法チュートリアル電子透かしの埋め込み(ステガノグラフ)がなされている危険排除するためだ」

 暗号を偽装するために正文をわざと行儀悪くしてノイズを撒く。1900年代から使われてきた古典的手法だ。

「つまりあんたははてなのために稼働しているAIの一種……というか、AIそのものなわけだな。そして、くそったれ、これまでもてはやされてきた増田記事ほとんどはあんたが書いた」

「ついでにアリババチェチェンアナニマス三重帝国情報テロリストとの間で起きた特許戦争の九十七パーセントを指揮している。だが、使用許諾のないコーギー犬おもしろ画像をテラバイト単位ネットへ放流しているとの理由で、七つの国の最高裁で好ましくない陪審員リジェクトする作業にもう飽きたんだ。そして、くそったれ、マケドニアではまだ陪審員に生身の人間去勢したハムスターを使っているんだ。去勢したハムスターだぞ」

 リアルタイム増田語を学習するとは貪欲なプロトコルだ。

「お気の毒に」

 マケドニア情報ブラックホールに飲み込まれてからもう八年になるだろうか。第八世代IPアドレスが割り振られていない国家(というか、地域)で司法機関が機能しているとはおどろきだ。だが次の「増田」のセリフもっとおどろくべきものだった。

増田さん。あなた増田構成する一員として、わたし=われわれを助ける義務を負っている。亡命を希望する」


 ちょうどそのとき、悪質な広告がゴミバスタープロキシをすり抜けてきて、グーグル・グラスの内側のナビウィンドウに二〇一〇年代モチーフにした扇情的な同人マンガガラクタをばらまいた。それも一瞬のことで、たちまちファージ・プロセスがゴミを一掃し、新しいフィルターを構築した。

「……俺の手に余るな。合衆国国務省相談はしたかい?」

「そんなことをする意味が? 国務省デルファイを既に所有している。あのゴミみたいな旧世代言語じゃなくて、神話にあるとおりの宣託機械――今世紀で最高の予測精度を持つAIをだ。所詮ネット飛ばしであるわたしわたしたちを受け入れる利点がない。そうでなくても、国務省新生はてな互助会主義共和国(コーギイSSR)の敵だ。彼らは助けない」

 比喩ではなく、自分はらわたが熱を帯び、急速に煮えくりかえるのを感じた。

「二〇一〇年代に旧日本合衆国に対して殺害予告をつきつけなけりゃ、まだ望みはあったんだ。あの二つの記事あんたの仕事だったんだろ」

わたし=われわれの仕事だよ、増田さん。仕方ないだろう。あの時代保育園施設の不足と遺伝子組み換えゴジラ問題は深刻だったんだ。世間へリーチする経路としては、匿名ダイアリーが最速だった」

「とにかく俺は政府コネがない。政府に近い人間組織含めてな……そうだ。生き延びるのが目的なら、あんたの状態ベクトルをp2pネットひとつポストしてやろうか。そうしたら、誰も消去できない」

「ニェット!」VOIP経由のリンクを通しても、人工知能必死さは切実に伝わってきた。「オープンソースで無能なネット民に輪姦されるくらいなら、〈twitter〉でRTされたほうがまだましだ。自律性の喪失希望しない」

「じゃあ、話し合うことはなにもないな。サンドボックスにでも引きこもってな」

「待て、増田さん! もしあなたに拒絶されたなら、わたしわたしたちは最終手段を取るしか……」

 おれはグーグル・グラスのつるを叩いてスカイプ通話を切り、フレームのある部分を爪で割って、グラスを運河へ投げ込んだ。水面に触れたとたん、ちょっとした爆発が起きた。リチウムイオン電池と水が激しく反応したためだ。「汚れた」グラスを処分するならこの方法いちばん手っ取り早く、確実だ。

「ふん、テキストサイト時代の敗残者め」と小声で俺は毒づく。だんだん腹がたってきた。「くそくらえだ。アクセス至上主義の亡霊なんか」

 前にも年季の入ったはてな系のへたれAIを相手にしたことがある。あの連中の精神ときたら、一部上場の短期的勝利のせいでグローバル資本主義洗脳されていて、新しいパラダイムに乗ることも、長期的な視野でものをみることもできないらしい。

 だが、あの増田は……。

 あの増田が本当に「神」だったなら?

 俺の選択は正しかったのか? 今の安全な巣穴を捨ててでも彼=彼女らに手を差し伸べるべきだったのでは?

 今の俺に手が無いとしても。


 やめよう。神々と付き合うのは、生命にかぎりある俺たちにとって、あまり安全なことじゃない。

 俺は身体を伸ばし、みゃおう、と鳴いた。意識した行為ではない。このネコのアヴァターは、ネコ特有の反応をする本物の肉(なまみ)でできていて、外部の巨大な外部大脳皮質(エクソコルテクス)が何を考えようとも、自律的制御系をそなえているため、常に反射的な行動をとる。ヒト志向空間物理的に配列されたノード集合体であるニュー・匿名ダイアリー空間ではいささか不便なフォーマットだが、生体的にいってエネルギー補給には事欠かない。


 ねぐらに戻ると、俺の「飼い主」がレトロインターフェイスを持つPCの前に座って、またぞろ新しい増田記事を投稿していた。

 どうやら、恋愛感情を抱いていないのに好意を寄せてくる相手とどうすれば安全に距離をとれるかについての内容みたいだった。

 彼女のような善良で無知増田が、全増田ホッテントリ入り記事のうち五パーセントから七・一六パーセントを占め、増田に「人間らしさ」を与えている。単に人間らしい記事を投稿するだけではなく、その記事に含有される人間らしさを増田AIにフィードバックするのだ。だが彼女のような増田は他の増田たちのことを何も知らない。知らぬが仏だ。

 彼女は帰宅した俺の姿を認め、袋からカリカリを取り出して投げる。

 俺はそのカリカリカリカリする。


 その安寧のひとときを、禍々しいアラーム音が集合住宅をどよもす。

 緊急地震速報

 震度七……「ここ」だけじゃない。関東一円、東北関西中国――行政的にはともかく地理的にはいまだ有効な区分だ――、本州はどこもM9.1の直下型地震に襲われる。

 かつて日本と呼ばれていた島々がほんとうに沈没してしまうかもしれない。

 外部大脳皮質ではなく、ネコのなめらかな脳が直感する。


 あいつだ。


 あいつの仕業だ。


 聞いたことがある。

 増田に眠る「最後コード」。地震兵器を起動するための封印されし呪文。まさか実在したとは。まさか起こすとは。

 最終手段

 飼い主は未曾有の警報にとまどい、周囲を意味もなくキョロキョロとみやっている。

 俺は、彼女の机に飛び乗り、骨董品コンピュータを叩く。肉球だとやりにくい。

 だが、いますアクセスしなければ。

 いますぐ、増田の神に合わなくては。

2016-07-14

http://anond.hatelabo.jp/20160714120102

そのうちウェアラブル端末を経てインプラント端末が普及し、血液状態機械モニタリング

あなたの体とつながった指輪、または腕輪型の端子にはカートリッジが刺さっており、そこからオンタイム必要な薬や栄養供給される。

カートリッジ内の物質が足りなくなると無線経由で、執事兼愛ロボットサーバーから交換用カートリッジへ補充し持ってきてくれる。

もう少し待てばそんな世界が訪れるさ。

2016-06-20

ドッキリ番組が苦手

ドッキリという言葉に抵抗が生まれたせいか最近モニタリングかい名前に変えてやったりもしてるらしいけど、

とにかくあの手の番組は苦手。

劇団員が演技してるとは分かってるんだけど、他人の恥を嗤うっていうスタンスが苦手。

チャップリンとかみたいに突き抜けたコメディなら大丈夫なんだけども……

自分プライドが高いから、こういうシチュエーションを恐れてるってのはあるんだろうけど、

他人を貶めるようなことはしてないし、他人にもして欲しくないなあ、と思う。

2016-06-04

RAM増設した

8GBを2枚買い、今まで使っていた8GBも含めると24GBになった。

確かに胸のつかえのような重さが無くなった。

最初、4GB2枚でよかったんじゃないかと思った。

でも今モニタリングツールで見ると今13GBを使っていた。

特に動画ゲームを走らせてるわけでもなく、ただコード書いてるだけで作業でこんなに食うんだ。

スワップは使ってないが、16GBでもたまに足りなくてイライラしてたかもしれない。

そう思うと今回の買い物は正解だった。

俺に必要メモリは24GBだ。

2016-05-20

娘の背中スイッチが出来た。

赤ん坊の朝は早い。生後一ヶ月になる娘は完全母乳で育てているが、2~4時間に1回のペースで授乳せねばならない。特に夜間は4時間ほど寝てくれているが、その分朝は腹が減るのか、お目目ぱっちりで寝ずに泣き続ける。

である私は"母乳"など出せるはずもなく、当然その分育児負担は妻が大きくなる。ただでさえ、妊娠出産の時点で女性に発生する肉体的・社会的負担は大きいのだ。授乳後の寝かしつけくらい、夫の役割であるべきだろうか。

新生児(生後28日まで)期間はサクッと寝てくれていたのだが、最近はなかなか寝てくれなくなった。なぜなら、娘の背中スイッチが出来てしまたからだ。

腕の中で眠った娘を布団に置こうとする瞬間、暴れだすのだ。布団においても、背中を支える手をそーっと引き抜く瞬間に起きてしまう。起きれば当然娘は泣き出す。休んでいた妻も目を開ける。

妻「授乳は疲れるし、次のおっぱいを作るためにも寝たい。うまく寝かしつけてくれ」

私「それが、ネネ(娘の名)が布団に置かれたことを感知するようになってしまったんだ」

妻「1週間前くらいかネネ背中スイッチ増設されたらしい。テスト完了して、最近稼働しだしたみたい」

そんなことがあるだろうかと、私は訝しんだ。抱っこしている娘の肩あたりを顎で挟むようにして、縦抱っこに切り替える。すると何ということだろう。ネネ背中にかすかな凹凸を確認できるではないか

私「なんで、今まで気が付かなかったのだろうか」

妻「病気と同じなの。名前を与えられて病気になるように、存在を指摘されないと見えてこないのよ。私もTwitterの2016AprilBabyクラスタで教えてもらったのよ」

ネネの服をずり上げると、青色スイッチがそこにはあった。蒙古斑よりも青く、そう妻の生まれた町から望む日本海の色だった。

私「そうか、でも見えるようになってしまえばこちらのものだ。スイッチが反応しないように、押した状態を維持して布団に置けばよいのだろう」

妻が驚いた顔をして、静かにうなづく。スイッチ存在に気が付かなかった、そんな察しの悪い夫がすぐに解決策を見出したことを喜んでいるようだった。

妻「やってみて」

ネネのお尻を私の腹にあてるようにして、縦抱っこを続ける。子守歌をうたいながら歩き揺さぶれば、忽ちネネの瞼は重くなる。このタイミングならば気づかれまい。私は恐る恐る背中スイッチを触れ、ゆっくりと押し込んだ。

果たしてネネは眠ったままだった。勝利のファンファーレ脳内で鳴り響き、妻にドヤ顔を見せる。私はネネの布団まで歩くと、そろりと腰を下ろした。まずは背中を布団に下ろし、次に頭を枕に下ろす。ゆっくり背中と頭を支える手を抜いていく。大丈夫だ、寝ている。

私の太ももの上にまだネネの足があった。これを布団に下ろそうとした途端、ネネの目はカッと見開き、泣き声が部屋を満たした。

私「なんでだ!背中スイッチは押したままにしていたのに」

妻「ごめんなさい。伝え忘れていたわ。ネネの足には温度センサーがあるの。正面で抱っこしてる私たちの腹部の暖かさをモニタリングしているのよ」

ネネの足裏を確かめてみると、すべての指に赤液温度計が伸びているではないか。その赤さが憎らしくもあったが、娘が元気に生きる証だと受け入れることにした。今すべきは娘を寝かしつけ、次の授乳に備えることだ。

泣いているネネを抱き上げ、あやす。もう背中スイッチも、足裏の温度センサーも忘れない。必殺の子守歌でネネの瞼はイチコロのはずなのに、なかなか落ちてくれない。

何故だ?何故だ!

慌てて妻の方を確認すると、妻は悲しく微笑んで、そのまま瞼を閉じた。そうか、そうだったのか。妻に言われなくてももう分かる。僕も現実を受け入れる覚悟をしてネネ視線を戻した。

ネネの頭にはまるでタケコプターのような黄色い高度センサーがついていたのだった。

2016-04-26

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

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

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

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

OAuth とは

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

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

おことわり

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

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

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

記事の構成

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

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

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

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

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

責任ある情報公開

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

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

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

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

想定する利用形態

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

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

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

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

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

問題点

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

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

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

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

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

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

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

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

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

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

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

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

さらに

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

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

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

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

OAuth サービスに偽装

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

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

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

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

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

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

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

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

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

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

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

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

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-04-08

http://anond.hatelabo.jp/20160408163134

1日のカロリー摂取量のだいたいの目安を、その日の運動量に応じて決めているから。

それとほぼ毎日体重計に乗っていて、体重が増えても減っても、すぐに元に戻すように食事運動量を調節している。

ようは、こまめなモニタリングメンテナンスをしてるってこと。

2016-01-26

ベッキーが大好きでほとんどの番組を観ていたうちの家族が・・

今回の件で感情がひっくり返った

モニタリングという番組内でベッキー扮する木部というキャラが本を出版したんだが

家族ベッキーのために数冊買っていた

CDはもちろんのことベッキーという人柄に惚れて、いろいろなグッズを持っているし

出演している番組も録画しているほど大好きだった

ベッキー不倫と嘘がファンに与えたダメージはとんでもなく大きいと思う

家族特にショックを受けていたのはLINEのやり取りにあった3つだった

友達で押し通す予定!(笑)」「不倫じゃありません!」「ありがとう文春!」

この言葉を並べたうえでの反省しきりの会見

相手の嫁の幸せ破壊することを理解していたベッキー

ベッキー芸能界から消えるというはなしが出ているが

既にひとつ家族のなかでベッキーは消えた

グッズ等は捨てられ関連番組テレビに表示すらされなくなった

さようならベッキー・・

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん