「効率的」を含む日記 RSS

はてなキーワード: 効率的とは

2016-05-25

最近ブログが楽しくなくなってきた

当方、読む専のネットユーザなのだが、最近ブログを見るのがつまらなくなってしまってきた。



「今月はアクセス数○万いきましたー」とか「○円もうかりましたー」やらの記事は、

「同じような記事ばっかで飽きたよー」とはおもったけどそれまでだったんだ。



効率的クリックさせる広告の置き方」とか「SNS連携ボタン作りました」とかの話ばっかになってるのも、

まらないし、それはそれで技術記事かなと思って読んではいたんだ。



でも、最近は「30分で1記事書く方法」とか「○年続けないといけない」とか「1日○記事」とか「量産」とか「1000文字」とか

およそ読ませることを考えてない、読者が苦痛に感じようとなんだろうとbotがそれっぽく判断すればそれでいいという話ばかりで、読まされてる感じが強くて心が折れたというか、「読む意味あるのかな」ってつい思ってしまった。

その手のノウハウって昔から色々あったんだろうし、botの方を向いてブログ書いてる人の記事もいっぱい読んできたとは思う。

でも、おおっぴらに「読者を騙せ!」なんて記事が連日ピックアップされちゃ、読む側としても気分悪いよね。

大手新聞社以外のメディア記事も増えてきているし、ブログはまとめて読むのをやめようと思う。

その方が新しい気づきもありそうな気もするし。

正直付き合ってられないと思った。

2016-05-23

http://anond.hatelabo.jp/20160523174008

麻雀も運の要素で点数が変わるから派手そうに見えてな、あれも何回もまわすなら効率的に打ったやつが勝つって決まってるんだわ

もちろん人間同士読みが入るけどツモ自体人間が関与できるわけじゃないから結局効率重視が一番強い

2016-05-22

握手会は無くならないよ

莫大な利益を生み続けるコンテンツから

 

 

無くなるとすれば、ほかにもっと効率的に集金できるコンテンツ誕生した時さ

「Reactは大規模SPA用途以外はコスパ悪い」っていう先入観意味不明

しろweb制作入門用に最適だと思う。

個人的な考えは以下の通り。


UI構造がおおよそのコード構造と一致する

そもそもコンポーネント指向ライブラリからチュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。

だって初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ?

もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、

DOM操作抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?


しろ小規模案件にこそ導入して「構造化とコード再利用」を意識づける

ライブラリ自体構造化を念頭に置いてるから自然とパーツごとに作るようになって、

その次の段階として自分の作ったパーツの再利用を考えられると思う。

jQueryで場当たり的に(以下略


抽象化の高いレイヤーから入って抽象化の低いレイヤー学習範囲を伸ばすべき

jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど

やっぱ初心者には逆に指針がぶれやすいと思うんだよね。

チュートリアル書く人にもそれぞれ別の方法論があって、

しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。

正解が沢山ある問題をいきなり解かせるんじゃなくて、

まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。


jQueryWebフロントエンド界隈のアセンブラだと思う

最初に手を出すには抽象化の度合いが低すぎるというか、

ある程度経験を積んだプログラマーこそが手を出すべきと言うか。

だってアセンブラ機械語がなくなってないのと同じように

webからDOMの直接操作不要になることもないと思う。

どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから

でも、大事な基礎技術からといって、それだけで済ませて技術革新放棄するべきではないでしょ

しろ抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。


から初心者や小規模案件にこそReactを!

と、私は考えます

2016-05-18

http://anond.hatelabo.jp/20160518122600

デモやるなら、効率的大衆アピールする方法について電通さんに相談したほうがいいよ!

2016-05-17

みんなどうやって効率的増田を利用しているの?

はてブホッテントリに上がっている増田はよく読んでいて

なかなかおもしろ文章もあるしって増田を開いて色々読もうとすると

まり玉石混交ぶりというかノイズみたいな糞ポストの多さにげんなりする。



みんなどうやってホッテントリに入るような面白い増田を見つけるのだろう?

ポストうんざりしながらも増田の海を漂って、一粒の真珠のようなおもしろ増田を見つけ出しているんだろうか?

2016-05-15

なぜ女性向け同人誌男性向け同人誌では圧力負荷が異なるのか

同人やめました - おとなになりたくなかった


要するに、オナニーのあり方の違う。


男性向け同人誌は最悪書き手自身がシコれればあとはどうでもいい。賢者モード爆睡しておけば満足だ。

しか女性向け同人誌は前提として(感情としての)「共感」と(行動としての)「共有」が求められる。

女性向け同人誌という戦場には、コミュニケーション強制ビルドインされている。

そしてコミュニケーション強制は太古の昔から存在した。

リンク先の主が回顧する「古き良き時代」のサークルのあり方についての記述を注意深く読めばそのことがわかっていただけると思う。


ただ昔は共有手段限定されていた。腐女子同士がコミュニケーションを取れる場はマーケットしかなかった。

あらゆる情報オープンだった。

ところが、インターネットの普及で状況は一変する。

マーケットや紙媒体以外で「共有」の場が無数に開拓された。


腐女子の行動原理は「共感」の最大化だ。

共感」を増やすためには「共有」の場を増やすに限る。

SNSというサービスはまさに共感エネルギーを最大限効率的に生み出すための原発のようなものだった。

腐女子インターネットの各所に共感原発を立てまくった。

ところが、核施設運用は核燃料廃棄物を伴う。腐女子にとっての核廃棄物に当たるのが、リンク先のブログで列挙されていたコミュニケーション地獄である


そもそもSNS共感や共有を増殖させる方向で発達してきた。

それがインターネットのあらゆる場所戦場に変えた。

他人を褒めるために生み出されたはずのSNS評価機能戦場では武器となる。

インターネット人口の増加にともない、頭のおかしい人や悪意を持った人間も増えた。

そうしたゲリラが各地で評価機能悪用してテロを起こす。

その代表pixivの点数制だ。

男性向け同人作家にとっては「点数=俺TUEEEの値」でしかないが、腐女子にとっては「誰かの意思表示」、つまりコミュニケーションの道具だ。

善良なもの同士であれば良い互助会の肴だが、テロリストが用いるとなると凶悪兵器と化す。

ブログ主も、その「汚い兵器」に打ちのめされた一人なのだろう。


我々のインターネットは今や20世紀の頃とは違う戦争を戦っている。

どこに敵がいるのかわからない。誰が味方なのかわからない。

にこやかに握手を求める手を差し出してきた人間自爆テロ犯なのかもしれない。

もはや我々に安眠は訪れない。

共有と共感の交換あるところすべて戦場なのであり、そして今やインターネット共感や共有のない場所など存在しないのだから

2016-05-10

共働きしないのはそこそこ豊かだからじゃないかと思う

ちょっと前まで(サザエさん時代)の首都圏にしても、福岡にしても

1人分で生活費を賄える環境だってことなんじゃないか

あと、都会であること、サラリーマン仕事が多いこと

農業だと基本的家族総出の仕事になるし

自分実家北陸で、女性仕事をしている率が高いと昔から言われてたが

別に意識が高いわけではなく、単に貧しかたからだと思ってる

しかし近年、というか自分の友人は主婦が多い

別に皆が家庭的でコンサバ価値観の持ち主というわけではなく、単に仕事がないからだ

薄給で遠方に働きに出るよりは、旦那のそこそこの稼ぎ内で生活するほうが効率的から

そんな時代実家結婚してなお共働きしてる姉

旦那の家がドがつくレベル貧乏らしい

すべての理由は金なのだ

2016-05-09

http://anond.hatelabo.jp/20160509111723

甘過ぎ。

子供絶対作るべきでは無い。

体力が落ち、産休を取った時点でキャリア落ちの可能性がある。



フルタイム共働き及び非正規夫持ちの家事を夫が半分以上分担している割合は、厚生省統計で3割。

まり夫は妻とは違い家事をしないので、女と同棲するか家政婦が効率的



専業主婦を抱えるコスト年収1500万で外注の方がコスパ良くなる。

だが専業主夫子供を生まず、生まない場合育児労働力ととして必要なく、家事能力も低いためコスパが悪すぎる。

また女性年収が高い夫婦離婚率はなんと8割。

離婚コストを考えると仕事で輝きたい女性こそ高収入男性(子供不要)と結婚するか非婚ベストだ。

2016-05-08

カステラパイプライン

今やカステラは時たま頂くおやつというより、様々な栄養素を含む生活に欠かせない国民食になった。そんな国民需要に応えるべく国はカステラ供給するインフラ整備を模索し始めた。もはや店頭に並んだカステラを買いに行くのすら非効率的。そこでぶち上げられたのが「カステラパイプライン構想」だ。読んで字の如しだが、カステラ水道管のように各家庭に配管で供給するものだ。カステラのような弾力性のある固形物をどのように供給するのだろうと思うだろう。まずカステラの幅を5切れ分を1パケット策定した。これが最小単位である

2016-05-07

http://anond.hatelabo.jp/20160507084347

保守自己責任を掲げるのは100歩譲ってまあわかるとして、朝日新聞のような左派自称する勢力も自己責任を是としていたんだよ。ほんと日本経済思想は狂ってるとしか言えない。

 「スリム効率的政府の下で自由闊達(かったつ)な競争が展開され、新しいビジネス新規産業が次々と勃興(ぼっこう)する ― 」

 「国民一人ひとりが保護規制から一人立ちし、自己責任自助努力ベースとして自由な発想と創造性をいかんなく発揮する ― 」

 いずれも、2年前の戦略会議答申提言された構造改革が断行された後の社会として書かれている。いまこそ実行の時だ。

http://d.hatena.ne.jp/tonmanaangler/20091025/1256448739

2016-05-05

http://anond.hatelabo.jp/20160504151503

ちきりんに限った話ではないけど、あれ見てると、人が大人になって「若いころの貯金効率的に食っていく」方向にシフトした瞬間から人間堕落が始まるんだなってつくづく思う。

しょうがないことなんだけどね。家庭を持ったり情熱が尽きたて若者突き上げられたりして若いころみたいに頑張り続けるのがしんどくなっちゃうもんだから

「30ウン歳を超えたら貯金で食えるようにならないと」と言う人は多いけど、その結果がこれなんだよなあ…とは思っちゃうよね。

2016-05-04

なんだかんだ言って宅間守ってやっぱ神だわ

選挙だなんだ欺瞞だらけで非効率的システムなんかに従わなくても、社会を変革する事ができるって身を持って教えてくれたのが宅間守という人間

宅間のおかげで学校セキュリティって向上したじゃん?今お前らが安心して学校行けるのも宅間のおかげなんだよ



自殺するぐらいならこの腐りきった世の中に鉄槌食らわしてやれって宅間は俺達に示してくれたんだよ

それだけでも宅間守は神

2016-05-02

就活の前倒しって全く効果ないと思うんだが

せっかく4月頭には内定が決まっても11月から2月にかけて内定取り消し普通にやってくるじゃない。

前倒ししても良い企業以外はやるべきじゃないし、

難ならこれから内定取り消し企業にはペナルティを与えてリクナビとかマイナビとかの合説に

一切参加させない位の処置はするべきだと思う。

就活生にしても一生懸命準備して臨んだのに採用企業の態度一つで変わるんじゃ可哀想だし、

卒論の為とかいうけど、卒論って半年そこらで出来ると思ってるのか不思議だ。

逆に就活なんて1か月もあれば出来るんだから、前倒しじゃなくて卒論提出後の1か月で後倒しっていうの?

後倒しでやればいいじゃんか。

そっちの方がよっぽど効率的だよ。

2016-04-29

スマホで見る増田ページの挙動について

スマホ増田を見ると、http://anond.hatelabo.jp/touchトップページになる。

ここでは「注目エントリー」と「新着エントリー」が閲覧できる。

まあ大抵の人は増田をチェックする時はこの「注目エントリー」の方を閲覧するかと思う

だがこれとは別に、「エントリー一覧」という画面もある。

http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fanond.hatelabo.jp%2F

上記と似たような画面だが、「人気」と「新着」とに分かれていて、

人気の方は過去増田すべての中でブクマを集めたもの

新着の方は、上記の「注目エントリー」と同じような感じのものだ。

だがこの「注目エントリー」と「新着」で表示される、最近ブクマを集めたエントリー一覧が微妙に違う。

まあごちゃごちゃした説明より、

http://anond.hatelabo.jp/touch

の「注目エントリー」と、

http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fanond.hatelabo.jp%2F

の「新着」を読み比べて見てくれ。

後者の方がより多くのエントリーを拾っているのが分かるはずだ。



なぜこのような違いが生じてくるのだろうか?

何より、「人気」機能不要だと思わないか。

いつまでたっても「急がばまわれ式・堅実で一番効率的英語勉強法」が表示されるだけで、

情報としての価値ほとんどないようにおもうんだが。

2016-04-27

http://anond.hatelabo.jp/20160427033638

じゃあ起承転結で分解してみましょうか。

  1. 道徳教育方向性に対する言及
  2. 優位に立ってしま不条理無気力化する道徳心
  3. 道徳方向性を据え置きにして拡張性で考える
  4. 自らのマニュアル思考について

元増田は上のようにしかいってなくて、虚無感を持つ云々を元増田により解決できるとは書いていないように見える。

と言うよりそもそも俺のは誤読じゃなくて単なる道徳肯定している態度への反論なんだけど。

肯定しようがすまいが一緒でしょ、という無政府主義的な諦観を述べてるだけです。

あなたが言うところの善処の一つとしても中道をとっている非常に保守的もので、

それこそ国家的な洗脳プログラムの中に組み込んだほうがマシ。

全体主義かもしれないけど今の喧嘩ばかり頻発している増田に対する回答もそんな所あるよ。

本当は各人が各人に無理解なところから災いが発生してるんだけど、生まれつきミラーニューロンが乏しいサディストもいるわけで。

お互い様々な人間の生を推し量ることができればそれは素晴らしいユートピアでしょうよ。それができてやっと画一的道徳適用できる。

だけどそんなことが絶対に実現しない社会においては、自分で考えさせているように錯覚させたほうが効率的

要するに思想誘導して平和な国にしましょうね、ということです。

もう少し言及すれば学習性無気力根本原因は挫折感であって、家族すら除いたコミューン限定している語り口はさすがに恣意的です。

からあえてすっ飛ばし気味に定義反論してるのですけど。

2016-04-26

街頭募金に冷たくあたる

自分の中にあるタチが悪い部分が存分に刺激されるものがいくつかあって、そのうちのひとつが街頭募金である

歩く道すがら、箱を抱えて佇む人や、声高に募金への協力を叫ぶ声に触れてしまうたびに「けっ、くそが」のような悪態心中で吐き、もちろん小銭すら投じることはないのである特に東日本大震災関連のものか、大の大人雁首そろえて並んでいる場合は私にとって最悪で、これらにはなんとしてもびた一文、絶対募金に応じる気はないのであった。

かつて、まだ義務教育も中頃に届かぬ頃の時分には、私もこのような街頭募金活動に参加したことがあった。とある地方政令指定都市でのことであり、それは赤い羽根募金ではないものの、かなり著名な団体が手伝って(主催して? 後ろ盾にいて? なんにせよ関わって)いたものだった。子供をずらりと並べて「ご協力お願いしまーす!」と叫ばせる類のものである。どこの都市でもそうなのかは知らないが、私が住んでいたその町では、該当募金といえばここ、ここにはいつも街頭募金がいるね、というような場所があり、私もそこに集合したのだった。

当日の朝、募金活動を始める前に、責任者っぽい大人がわれわれ子供たちにしっかりと言い聞かせたことがある。

「もらったお金がどの団体に行き、どのようなことに使われるか、質問されたら答えられるようにしなさい。それができないなら参加してはいけません」

もちろん、その質問の答えとなる内容もセットで教えてくれた。◯◯という団体に渡され、◯◯のために使われるのだよと。

わりと真面目な子供たちが集合していたこともあってだろう、みなふんふんと素直に聞き、街頭募金は開始された。やってみると、子供から見ると意外なほどに大金が集まる。紙幣を投じていく大人もいた。意味もわからず感激して、「ありがとうございまーす!」と声を大きくしていたような記憶がある。

始めて数十分だか、一時間超だかした頃、私の前に成人男性が立った。そして、こう言った。

「この募金って、何に使われるの?」

そう質問されたのだ。

どきっとしたものの、朝に教えられた通り、「◯◯◯◯に渡します、◯◯のために使われます」と言った。緊張と動揺でつっかえつっかえではあっただろうが、間違った答えはしなかったはずだ。「間違い」というのは、まあつまり、その瞬間の私にとってはクイズに答えるような感覚の問答だったということでもある。テストの答えのらんに確信を持って答えを書くときに似ていた。

男性は「そうか」と納得した様子で、募金に応じるにしてはやや高めの金額を投じてくれた。千円だったか、五百円だったか、そういう額だ。緊張で視線を伏せていたのだったかその男性がどういう表情でそうしてくれたのか、印象すらない。


まるで仕込みのような展開だとすら思う。けれど、あれ以来、自分にとって街頭募金神聖ものになってしまった。気軽な気持ちで行ってはいけないものになってしまった。


Wikipediaで「街頭募金」の記事を読んでみたら、「問題点」の項目があり、「街頭募金においては募集団体寄付者が一過的にしか接触しないケースが多く、せっかく寄付をしても使途をそのお金が本当に目的通りに使われたのか追跡できない場合もあり、悪質な場合には募金詐欺であることもある」とあった。あのとき大人がわれわれに教えた内容は、なるほど、これに対するアンサーである説明するのがわかりやすい。

そう、つまるところ私は、街頭募金の実行者に、資格のような、覚悟のような、そういう面倒なものを求めるようになってしまった。だからそれを持っていなさそうな人には訊ねてやりたくなる。あの男性と同じような内容を、しかしあの男性とは違って、ただ相手を咎めたいがためにだ。なんて底意地が悪いのだろう。


それに加えて、今の自分出来高制で働いているせいで、街頭募金で集まる金額と、自分の時給とを照らし合わせてしまう癖がついた。大の大人が実際にその場に集結してまで、生産もせずに他者の余剰を集めるのは非効率的に感じられて見ていられない。そのぶん何かを生産して対価をえるか、もっと効率のよい方法でことにあたれないものかと、詰め寄ってしまいたくなる。

なお、東日本大震災に関わる募金特に見たくないのは、もうすでに20万円ほどをチャリティに投じているかである。これ以上はキリがないのでもう応じないと決めている。


そんなわけで、街頭募金はもう見るのも嫌である。彼らから目をそらして歩く速度を早めるとき、私は心中悪態をついてしまうのだ。

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

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

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

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

OAuth とは

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

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

おことわり

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

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

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

記事の構成

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

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

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

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

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

責任ある情報公開

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

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

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

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

想定する利用形態

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

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

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

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

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

問題点

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

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

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

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

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

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

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

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

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

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

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

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

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

さらに

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

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

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

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

OAuth サービスに偽装

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

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

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

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

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

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

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

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

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

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

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

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

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

2016-04-24

anond:20160423145512

クリエティティが欠落しているという自覚があるのであれば、自閉症スペクトラム障害の可能性を疑ってみるのもありではないかと思う。

とにかく、何かを作ろうとするときに手がピタリと止まり頭が働かなくなる
およそクリエティティというものが完全に欠落しているのでコピペ適当でっちあげることすらできない
とにかく手を動かせと言われてもそのスタートラインにすら立てない

自閉症スペクトラム障害と思われる(正確な病名は明らかにされていないが、上司から配慮しろと言われている症状・対策がそのもの)同僚に似てるなぁと。

プログラマ怠惰であれとは真逆存在ではあるのだが、残業耐性もあり上司の指示に従うので「設計は任せられないが、ソルジャーとしては有用」みたいな扱いに…。

2016-04-22

http://anond.hatelabo.jp/20160422153133

なるほどなー

適格に僻地効率的に物を大量に送る必要があるな。

多分交通の便のいい所には大量に物資が過剰にあって

毛細血管の先端でものが足りないって感じなんだと思う。

道路崩壊しているし、ヘリコプターくらしか思いつかない。

2016-04-20

クリエイターが役に立つフィードバックを得ることはまずない

http://gigazine.net/news/20160420-creativity-10000-hours-practice/

試験特定技術の取得など、組織立てられた分野においてフィードバックは得られやすく、有効であることが多いのですが、クリエティティの分野で役立つフィードバックが得られることはまれです。作品を送りだした作者を待っているのは純粋賞賛や拒絶のみ。作品に対して批評が行われることもありますが、批評する人の嫉妬愚鈍さ、辛らつさが含まれていることが多々あるので、クリエイターにとって「本当に役に立つフィードバックは何か」を見分けるのが困難なのです。

俺が前から言っていたことが立証されたな。客の意見など大半が役に立たないと。

よく分かっていない人たちは自分たち意見を聞かないやつは成長しない、とそれこそ増長した意見をまくし立てたが、実際のところはこんなもんだ。

しかったらかじる程度でもいいからやってみてから言えばいいのに。的外れで失礼な上、まったく参考にならない意見のなんと多いことか。

ちなみにこれは有名な10時間法則を述べた人らしい。

都合のよいところだけ利用して努力至上主義を吹聴する非効率的な人たちも消えてなくなることを望む。

2016-04-14

便利って怠惰でいいってことだよね

怠惰に生きれるなら怠惰に生きたいというのが人間本質なのだと思う

世の中が便利になるにつれ、計画を立てる必要がなくなり、約束を守る必要もなくなってきている

まり、できる限り頭を使わずに済む社会が、つまり、便利ってことなんだろう

しかし、これっていいことなんだろうか?



スーパーコンビニ24時間開いているのは便利だ

でも、一定期間に必要ものを、必要なだけ考えて、どこかで時間を作って買いに行くことだって本当はできるはずだ

1週間分、日曜に買い溜めときゃいいだけの話

平日なら、夜8時に閉まる店に行くためには、週に1度か2週間に1度くらい、頑張って仕事早く終わらせて早く帰れるように計画すりゃいいだけで、無理な話じゃない



あとは待ち合わせ

携帯がここまで普及する以前、と言ってもつい15年ほど前までは、待ち合わせというのは時間場所をきちんと決め、それに必ず間に合うようにきちんと予定を終わらせて向かうものだった

今は、ごめん、1時間遅れる、ってメールときゃいつ行っても大丈夫って思ってるやつばかりになった



電車もそう

人口が多すぎて輸送できない都会はガンガン電車走らせる必要があるけど、スカスカ電車が5分に1本も走る必要があるか?

時刻表見て、計画的に駅に向かうようにすれば、15分に1本で充分なエリアはたくさんあるはず

時刻表見る手間を省くためだけに、スカスカ電車が走るのってどうなのよ



欲した時に、いつでも、欲したことができるというのは、便利なようで、人を堕落させ、そして社会としては非効率

スーパーコンビニも、営業時間でさっと終わって、エネルギー人件費節約して、店員は勤務後に別の仕事したり、消費行動をしたり、すりゃいいと思う

営業時間内に行けるように、世の社畜たちも効率的仕事終わらせて勤務以外の活動をすべきと思う



もちろん、本当に激務で少しの時間も取れない人も中にはいるのも知っている

でも、そういう人はごくごく一握りだし、残りの圧倒的多数の人は怠惰暮らしてるだけなんだよ

そこまでの激務の人の仕事は、怠惰で暇な人に振り分けた方がいいと思うし、それに、激務の人も本当は激務な自分に酔いたいだけの人も多い

同業で同種の仕事やってるのに、メリハリつけて帰る人も、ダラダラ泊りこんでる人も、両方いるのが大概の激務な職場だと思う

もちろん例外的に、本当の本当に全員過労死していく職場もあるんだとは思ってるが

とにかく、忙しくて計画が立たない、忙しいんだから怠惰で仕方ない、というのはほとんどの場合で甘えだし、怠惰であることは疑いようがない




世の中全体が、怠惰にダラダラ生きられて、無計画に非効率に暮らせることが便利だと思っているなら、そんな社会は衰退するしか未来はない

少年スポーツ漫画ブラック思考

1)指導者選手意味不明トレーニングをさせる

2)選手たちに動揺が広まる「俺たちはこんなことをやっていていいのか」

3)主人公「(俺も指導者真意は知らんけど)信じてついていこうぜ」と根拠なく団結

4)本番の試合トレーニングの成果が発揮されて「あの特訓にはこういう意味があったのか!」と納得

この展開がスポーツ漫画定番で、今ジャンプでやってる相撲漫画でもでてきたわ。

でも実際は、指導者は練習はどういう目的やってるか選手理解させたうえでやらせないといけないよな。

意味なんて知る必要はない。言われたとおりにやれ」より、本人が理解したうえでやったほうがトレーニング効果高いし。(現実でもそんな指導者はなかなかいないかもしれんけど)

企業新人に、非効率的意味不明仕事を下積み的にやらせるのに通じると思う。

2016-04-13

めもてきなかきちらし

コンテンツ思い入れがなければダメだという日本商業的にもまかり通ってきた俗説を鑑みるに)、やっぱりひとつ創作にこだわりがあると全くダメで、こだわりがなければないほど商業性や一般性というクオリティに貢献できるので商業的には大変有意義な結果を出せるんじゃないかなと思う。GoogleとかAmazonも、多分自分のやってる「コンテンツ」に興味がなくて、プラットフォームとかどうすれば効率的かみたいなことに注力してるんじゃないかと思う。

日本場合自分で作ったもの」にこだわりすぎて身動きがとれない。また、プラットフォームを作ろうという人達自分たちの作ったサービスの動き方にとらわれすぎている。自分の決めたことにとらわれすぎている。

そういうのは作家に任せておけばいいのであって、フォーマットだけ作ればいいんじゃないかなと。

アメコミヒーロー社会情勢によって変革できるフォーマットをとっている。だからとてつもない時間を生きながらえている。そういう作品って日本あるかなと考えたら、多分ない。長く居続けているのはサザエさんアンパンマンくらいで、前者は何も語りはしない。語るけど、せいぜい時代錯誤なことか持っている機器の変化くらい。アンパンマンは設定が普遍性がなく、大人向けに落としこむことが出来ないので(全身タイツ超人/一般人と、頭がアンパンの人造人間の、どちらが感情移入できるかは明白)いついかなる時代の空気を落とし込めることは出来ない。社会性のある、そしてなおかつエンタテイメント性のある作品は作れない。作ったとしても、アンパンマンでは世界全体に届かない。

ドラゴンボール孫悟空という人格破綻した存在と、世界を脅かす悪役が魅力的だから日本以外の国にも受けている。しかし、ドラゴンボール鳥山明以外が作ったら受けるかと言ったらそんなことはない。それはドラゴンボールエボリューションでも明らかなことだと思う。ファンが作ったものが最高だというけれど、それは商業には成り得ないし、社会性は得られない。ドラゴンボールという作品自体社会性は得られない、鳥山明個人的世界を描いた作品しかない。日本作品はそういうものしかないと思われる。

どんなにクールジャパンだとか政策として日本作品世界に輸出しようといっても、作られる物自体社会性の乏しいものだとしたら一般性は得られないだろう。進撃の巨人も、バットマンスーパーマンのように80年近く愛されはしない。

日本人世界に向けて「売れる」作品を安定供給しようとするなら、すべての自主規制的なものを取っ払い、個人的で、誰にも想像し得なく、そして少数の心に突き刺さるインディペンデント作品を大量に押し出していくしかないだろうなと思う。それは太宰治夏目漱石、それよりももっと前の作者にしてもそうだと思う。日本は今のところ個人的ものしか作れない。ライトノベルもそうだし、内需しか見えてない。ポリティカル・コレクトネスがどうこうではなくて、作る人間の数メートルしか見えてない。それは宮﨑駿もそうだと思う。

クールジャパン、あり得るけれどもそれが全世界普遍性のあるものなんて幻想だ。普遍性がないからこそ求められてる。新堂えるが、トレヴァー・ブラウン国外脱出した意味を考えるべき。自分のありようを考えるべき。どうしても日本人は、自分から自分の周辺から抜け出せない。あるいは自分を外部化出来ない。

から、この環境適応できるとサイコー楽園なんだけどね。

自分自分で終われるから。今の日本が苦しいのは、外部的な存在をきちんと認識できているのかもしれない。

http://anond.hatelabo.jp/20160413111155

西暦XXXX年。人口約1億人、医療技術科学技術、そして機械技術までもが恐ろしいほど発達し、他村と比べても全ての面でトップクラスを誇るとある村で、「増田」姓はついに500万人を突破した。

建村以来目立った戦争が起きていなかったが、先代の村長逝去し、次のn代目の村長即位してから状況は一変する。先代が早くこの世を去ったため、現在村長40歳。彼は自分勝手わがまま優柔不断性格であったため、窃盗強盗放火殺人まで起きるようになってしまい、村内は混乱と戦火に包まれしまう。看板娘が亡くなってからますますエスカレートする一方だが、村長は何の危機感も持たず、今まで通りただただ優雅な日々を送っていた。

そんなある日、村長は同じ姓を持つ人間がたくさんいることに怒りを覚え、「増田」を効率的抹殺するために「リアル鬼ごっこ」なる計画を発表する・・・