  |
はてなキーワード: 「秘密」とは
私がTRPGというものに触れてから、もう8年近くが経とうとしている。
元々幼少期から存在自体は知っていたものの、それはダンジョンアンドドラゴンズなどに代表されるファンタジー系のものだった。当時愛読していたライトノベル「フォーチュン・クエスト」の影響もあるのかもしれない。
だが、ニコニコ動画でクトゥルフ神話TRPG（以下CoC）のリプレイ動画が莫大な人気を博したあの瞬間、それまで見向きもしなかったであろう層が、斜陽であったTRPG界に一斉に興味を示した。
それはとても素晴らしいことだと思う。前述のとおり、私もその流れに乗って本格参入したクチだ。消費税が8%になる直前にはいろんなシステムのルールブックやサプリを買い漁った。
発展したインターネットとTRPGの相性もすこぶるいいもので、遠く離れた人ともツールを使えばリアルタイムにロールプレイしあえてダイスの結果を共有できる。冬の時代を現役で感じていない私のような若輩者が口にするのは何様だともなるが、いい時代になったなと今でも痛感する。
とりわけメインで参加しているシステムはやはりCoCだ。人智を超えた生命体への恐怖という題材が好きというのもあるが、それよりも大きな理由は「プレイ人口が多いから」だ。界隈が違えばまた変わってくるのかもしれないが、私の周りには大体みんなCoCを知っていて、それ以外のソード・ワールド2.0やピーカーブーなどに目を向けるとプレイ人口は冗談抜きで半分を下回る。なんなら「CoC以外はやりたくない」と言う層もいるので、布教すらさせてもらえない。チャイム越しに追い返されるセールスマンの気持ちがなんとなくわかるような気がした。
そんな弊CoC村だが、ここ数年でやたらと所謂うちよそタイマンが流行りだした。KP側の作成したPCと、PLが用意したPCが濃密な関係を組み、愛と勇気の力で宇宙的恐怖を退けるアレだ。
TRPGの遊び方というのは千差万別、卓の数だけ物語がある。それは重々承知しているつもりだ。
けれど、私にとってのCoCは本来特別な力を持たない（ほんの少しだけ生業への専門知識を持っているかもしれない）ただの人間の探索者が知恵を絞り不可解な謎に挑み、その先で神と呼ぶのもおぞましい存在に圧倒され自らの矮小さに慄くシステムだと自己解釈しているために、どうも首をひねらずにはいられない。
pi●iv製のシナリオを見てみると「突然意識を失い、目が覚めたら見知らぬ空間にいて、そこには囚われたor記憶を失くしたKPCがいた。脱出するにはKPCを犠牲にしなくてはならないが謎を解き明かせば二人揃って無事に生還できついでに二人の絆を証明するアーティファクトが手に入る」的なものが5件に1件くらいの確率でねじ込んである。その中でもシナリオ背景に「ニャル様が暇つぶしに二人を試しました☆」だけしか書いてないものを目にしたときは頭を抱えた。
いやもうそれクトゥルフ神話要素ほとんどないやん？？？？バッドエンドで視界暗転する瞬間に「やれやれ、君たちにはがっかりだよ。さて、次のおもちゃを探しに行こうかな」だけ言い残すニャルラトテップ御大の化身だけでは？？？？
いやそれだけでも出てくるのならまだいい方だ。中には「自作世界観を再現したので神格も宇宙的恐怖も一切関係ありません」なんてシナリオもゴロゴロ転がっている。それなら“クトゥルフ神話TRPG”のタグを付けないでほしいし回すKPも事前に告知してほしい。こっちはいあいあしにきてるのだから。
なんだか本題からずれてきている気がする。
うちよそ自体は否定しない。最初はそのつもりじゃなくても幾度か同卓をして交流を積み重ねた結果恋仲や相棒になったPCたちもいることだろう。
ただ、うちよそありきでキャラメイクをしシナリオを選びとなると正直もっとうちよそに適したシステムは世の中にごまんとあるわけで、ただでさえロスト率や後遺症を貰ってくる確率の高いCoCに向いた遊び方ではないと思ってしまう。
例えばネクロニカやダブルクロスなんかはPC同士でロイスや未練といった感情を伴った絆を結ぶことでクソデカ感情生成システムを生み出している。これらはファンタジー色が強すぎるが、現代日本ステージであるならばインセインはPCそれぞれに「秘密」が割り振られ、その内容がPC同士密接に絡み合っていたりする。
これら以外にも、もっとうちよそに向いたシステムがあるのに彼女らは尚もCoCに拘っている。神話成分が微塵も残っていない話でオタク好みする都合のいい展開にエモいエモいと泣いて有難がっている。億が一ロストの道を辿っても、今度は「ロスト探索者専用シナリオ」を用意してきて死の淵から蘇ってきてまでうちよそをしようとしている。もはや執念だ。
結局のところ、システムは二の次なのだと思う。感動的なロールプレイをしたためたいだけなのだ。そこまできてしまったのなら、もう“テーブルトークRPG”というジャンルよりも“なりきりチャット”の方がいいだろう。私も中学生の時にオリキャラなりきりチャット掲示板で長ったらしい割にはわかりづらいロルを回してはよその子と交流を深め恋愛関係を結ばせていただいたことが何度かある。あちらにはほぼ“判定”というものがない分、よりPLにとって都合のいい展開に持ち込めていいんじゃなかろうか。
ここまで書いて、ただの自分の好き嫌いで解釈違いというだけのクレームまがいな文章になっていることに自分で引いた。
タイムラインに流れてくる「CoCタイマンしてきた〜♥恋仲になりました♥」と心底嬉しそうな報告ツイートに、ふぁぼも祝電リプも送れない意地悪な自分に嫌気が差すし、かといって界隈から離れるには横の繋がりが多すぎて村八分状態になってしまうのが寂しいと抜かす、ただのかまってちゃんで我儘なプレイヤーだ。
あれからすっかり参ってしまって、TRPG用のアカウントにログインしない日が続いていたら10月頭あたりに学級会になってたらしくびっくりです。たいたい竹流さんまで言及する事態になってるとは…。
2ヶ月越しに意見を漁りまくってたんですが、賛同や理解を示してくれる人もいれば口出しせずに放っといてくれって人もいて賛否両論でした。そりゃそうだ。タイトルが攻撃的だったのが燃え広がった原因なのかな？
「合わないなら離れればいい」という意見をとても多く目にしたのですが、当記事に言及ぶら下げてくださってる方が仰ってる「居場所が侵蝕されたがそれだけを理由に切れるような浅い間柄ではない」ってのがまさにその通りで、だからこそ苦しかった。こんなグチグチした恨み言を書くような性格してるから必然的に友達も少ないし、その少ない友達がそんなことになってさらに孤立してしまったような気分になってしまったというのが本当のところで。
一度恨んでしまえば対象が何を言っても気に障ってしまう性分で、そんなタイムラインを見続けるのも精神衛生上良くないと思ってひっそりミュートしてたら今現在その界隈とは疎遠になり、晴れてぼっちになりました。万歳！！
いやね、元から書いてたんですけどシナリオを経た結果うちよそに発展するのは全然いいと思うんですよ。それも一つのロールプレイだと思ってますし、なんなら私にもそういうルートを辿ったPCがいます。
過激派繊細ヤクザすぎて言語化がひどく難しいんですけど、うちよそすることを大前提にキャラメイクしたり、ただダラダラと中身のない会話をするだけで生還報酬1d10貰ったり、初対面から仲良くなり喧嘩したりなんだりで段々と惹かれ合い告白し愛を深め身体を重ね合わせプロポーズして結婚式！って流れを全ッ部「クトゥルフ神話TRPGのシナリオ」にして経験してて、お前は24時間365日神話的事件に巻き込まれてんのか？っていうようなやつが本当に本当にダメで…そこまで神格に寵愛を受けてるのなら今頃ドリームランドか外宇宙へご招待されてるのでは？ってなってしまうんですよね。
言ってしまえばこれもただのいちゃもんです。私が嫌いだから見たくない！っていう近頃流行りの“お気持ち案件”です。当時元身内たちに言いたくても言えなかったフラストレーションが積もり積もってキレ散らかしながら書いた散文だし、こうやって拾い上げられて学級会の議題に据えられることなんて想定してなかったし。
けど、こうやって苦しんでたのが私だけじゃなかったことがわかったことはちょっとだけ安心しました。
書かれそうだから先に書いとこう
まあ例えば「簡単に火を起こす方法」ってのがあったときそれを「秘密」にすることで魔術になるんだよね。
この人、立法っていう難しい芸をした人なんだよね
いやたとえばね「法律」ってものがあったとき、今日本だったら e-govとか見ればすぐみれるじゃん？
それをみて、何が犯罪になるか、何が犯罪にならないか、どうやったら潜脱できるかを自分で考えれるわけだ（これは識字率が一定以上あるからできる芸でもあるけど）年金法だってそうだよ？見ればちゃんとわかるようになっている。
当然古代にはそんなものなくてさ、「お前は犯罪者だー」って、慣習法を知っているちょっと頭のいい人に言われた時、対抗できなかったんだよね、知らない人
この頃の知らない人ってのは庶民で知ってる人ってのは貴族なんだけどね
ルールが明文化されていないから、何がダメで何がいいかわからない、これをなんとかしたのがドラコンさんって人だったんだ、庶民にも生きるためのルールを明文化して、誰でもわかるようにするって、とても大事なことをなした人なんだよ。
セワシ君問題の解答候補「セワシ・タイムパトロール隊員説」まとめ・その２
☆ https://anond.hatelabo.jp/20190502082818 の続き
.
◇ドラえもんの所有するひみつ道具は「未来デパートの商品」などではなく、政府機関・軍隊・T・Pなど、公権力だけに製造・所有・使用が許可されている非買品である。ドラえもんがその所持を許されているのは、前述の通り英雄の特権であり、その使用はT・Pによって絶えず監視されている。
▼
そもそも「未来デパート」というブランド名がおかしい。２２世紀の人間にとって、２２世紀は「現代」なのだから。余談だが韓国には現代グループ資本の現代百貨店というのがあるそうだ。
▼
▼
危険なひみつ道具の民間所有、特に個人所有が許されているはずがない。特に、時間犯罪を可能にするタイムマシンは製造・所有・使用が厳しく制限されているはずである。
▼
ドラえもんがひみつ道具を「注文」をすると、T・Pによる審議を経て許可されたひみつ道具だけが「未来デパートから配送された」という体裁をとって送られてくるシステムだろう（許可されなかった場合は在庫切れとかなんとか口実をつけて購入できない）。ドラえもんも騙されている可能性が高い。この裏舞台こそがひみつ道具の「秘密」だろう。
▼
ヒーローマシンのグラフィックがショボかったのも官制品だからかもしれない
▼
そもそもセワシの家が貧しいなら、いくつもひみつ道具を持っているのはおかしい。
▼
ドラえもんに危険なひみつ道具の所有が許されているのは、前述の通り、それが歴史の安定に必要と判断された故。
▼
他の未来人がひみつ道具やタイムマシンを利用しているような描写もあるが、ドラえもんたちほど無制限には使えないはずだ。
▼
ドラえもんのひみつ道具使用についても、T・Pよって２４時間監視されており、深刻な影響（少数人命の被害程度は容認）があると判断された場合はひみつ道具の強制機能停止か、T・Pによる被害の修復・隠蔽工作が行われているはずだ。秘密裏に。
▼
おそらく、ドラえもんのひみつ道具は遠隔操作で外部から機能停止できるようなバックドアが設けられており、いざというときはT・Pのオペレータが強制的に機能停止をしているはず（壊れた・電池切れという体裁をとって）。秘密裏に。
▼
コメントでもあったけれど、宇宙の彼方に飛ばされたバイバイン栗まんじゅうは、タイムパトロールが密かに回収し、解除薬剤のようなものを使って無害化しているはず。秘密裏に。
▼
時間犯罪者達の持つひみつ道具やそれに準ずるメカは違法開発・違法改造したものだろう。
▼
気になるのは「ドラビアンナイト」で船乗りシンドバッドが助けたというタイムトラベラーだ。彼はただの旅行者ではなく、任務中に遭難したT・P隊員か政府職員、あるいは時間犯罪者である可能性が高い。
もし彼がT・P隊員だったとすれば、彼がシンドバッドに多くのひみつ道具相当の"王様のコレクション"を与えたのは単なる謝礼ではなく、シンドバッドもまたドラえもん・のび太と同じく、歴史の安定に必要な因子と判断され、利用されているのだろう。
そうなると、絵本世界に入ったはずのしずかちゃんが、現実世界のバグダードに現れたのも、怪奇現象ではなくT・Pの差し金と考えられる。四人はしずかちゃんという餌に釣られて、まんまと呼び寄せられたということになる。
その目的はシンドバッドの保護とアブジルの打倒。アブジルはいわゆる時間犯罪者ではないが、歴史の安定にとって危険な存在なのだろう。歴代ヴィランの中でも、アブジルはずる賢く直接戦闘にも優れた強敵と評判である。倒されなければ歴史を揺るがすとんでもない事件を起こしていたのかもしれない。
▼
▼
※追記 islecape様の情報より。なんと、ドラえもんは「気象庁専用」と書かれたひみつ道具「天気決定表」を所有していた！そんなものが民間に出回っているはずがない。やはりドラえもんのひみつ道具は公権力に与えられたものとみて間違いないだろう。
※さらに追記 コメントでご指摘。「気象庁専用」というのは「子ども銀行」みたいなジョークかも。
▼
「セワシT・P説」とは相反するが、「未来デパート」は合法的な店舗などではなく、違法にひみつ道具の売買をしている闇マーケット・非合法組織の類であるという説もある。「未来デパート」とは正規の店の名前ではなく、T・Pによる捜査の目から逃れるための暗号名のようなものであると考えると、ネーミングのおかしさも納得である。ひみつ道具の外見が子供向けのオモチャのようで、その名前のセンスが小林製薬のようなのも、T・Pの目を欺くためのカモフラージュだろう。そして「ひみつ道具」の「ひみつ」とは「犯罪だからT・Pに見つからないように秘密にしなければならない」という意味ということになる。
当然、ドラえもんの違法行為にセワシが関知していないはずはないので、これは「セワシ時間犯罪者説」となる。その場合、ドラえもんが堂々とT・Pと会っている理由が謎だが。ひみつ道具を買うのに必要な資金も時間犯罪で稼いでいるのだろう。時間犯罪で金を稼ぎつつ、その金で次の犯罪に必要なひみつ道具を買うというサイクルだ。「セワシ時間犯罪者説」ではセワシの真の目的は自らの時間犯罪の協力者にのび太を仕立てることだろうか。
.
◇ドラえもんの耳と体色と声が修理できないということになっているのは、それらの欠損がドラえもんにとっての「英雄因子」であるとT・Pに信じられており、修理すると歴史に悪影響があると判断されたから。
▼
正史には「耳を失い、体色が変わり、声が変わってしまったネコ型ロボット」としてのドラえもんの活躍が書かれていたのだろう。そこを改変すると歴史全体に何かマイナスの影響があると判断したのだろう。
▼
なにかしらのトラウマ体験、肉体的な欠落など、人生に負債を背負っていることが英雄の条件と考える発想は古代からある（例えば英雄ヘラクレスは女神ヘラに気を狂わされ我が子を自分の手で殺してしまった）。耳をかじられたトラウマこそがドラえもんの英雄因子であるとT・Pや政府要人が判断しても不思議はない。T・Pのトップが合田一人みたいな人なのかも。
▼
修理工場の修理工達や製造メーカーはT・Pからの工作で「修理できない」と嘘をつき、全員で口裏を合わせている。非協力的な人間には抹消（T・Pぼん参照）処分があったかもしれない。
▼
賢いドラミちゃんは事の真相に気づいているが、T・Pの報復を恐れてドラえもんに真実を話せないのだろう。悲しいね。
▼
アンチ新ドラじゃないけどやっぱり大山ドラは味があっていいよね。
.
◇のび太とドラえもんが歴史の英雄であることは、トップシークレットであり、彼ら自身にも伏せられている。
▼
ビギナーズラックという言葉もあるように、未来世界や時間犯罪に無知である方がかえってプロの捜査官であるタイムパトロール(以下T・Pと表記)にはできない柔軟な発想ができるという考えなのだろう。
▼
「自らが英雄であることを知らないまま世界を救う英雄」というのはトリックスター的でもある。
▼
また、のび太とドラえもんがT・Pの協力者であることが暴露すると時間犯罪者に命を狙われる危険もある。
.
◇T・Pも無制限にドラえもんたちの行為を容認しているわけではなく、歴史に深刻な影響（少数人命の被害程度は容認）があると判断された行為にはストップをかけている。空想動物の徴収など。
▼
おそらく２４時間ドラえもんたちの行為は監視・分析されているはず。
.
◇セワシT・P隊員説が正しいとすると、「ドラえもん」は「ＳＦ(すこしふしぎ)生活ギャグ漫画」の皮をかぶった「時間旅行系ハードコアＳＦ（サイエンスフィクション）漫画」ということになるだろう。
▼
作者・藤子・F・不二雄の大人向けＳＦ短編集の内容や、彼の幅広い文学に対する造詣と関心を考えれば、そういう背景設定があったことは想像に難くない。
▼
T・Pぼんや藤子・F・不二雄先生のＳＦ短編集は面白いからみんな機会があったら読んでみてね♪
.
◇セワシT・P隊員説というのは詰まるところ「ドラえもんはギャグ漫画であって、のび太は世界を救うヒーローじゃない」というのはやっぱり嘘だったという話だ。
▼
「世界を救うのはもうやめた」マリーのアトリエでも結局魔王倒してるし（任意だけど）、「俺たちは、正義の味方、なんかじゃない」リジョイスも結局魔王倒してるし、つまりそういうこと。
☆
※返答２
https://anond.hatelabo.jp/20190503093926 "「恐竜狩りはスポーツとして大人気なんだ」と「恐竜狩りは犯罪でTPに捕縛される」の矛盾はどうなんだ"
この説で言うと、「恐竜狩りは犯罪でTPに捕縛される」が真実で、「恐竜狩りがスポーツとして大人気なんだ」の方がウソだったということになります。ドラえもんに与えられた「子ども騙し」設定の一種でしょう、そういう話をすればのび太が喜ぶだろうと考えての。その後都合が悪くなったので、全員の記憶改竄が行われたはずです。
id:islecape ご注意ありがとうございます。 そうですね、書いてあるから正しいとは限りませんしね。 ただ、「天気決定表」のドラえもんのセリフに２２世紀では気象庁が天気を決めているというような趣旨のものがあるらしいので、もしそうならそれも傍証になると思います。
https://www.nikkei.com/article/DGXDZO45715160U2A900C1MM8000/ 孫引きですみません。
"Web等で喧伝される極端なドラミあげドラさげって片倉設定由来みたいな気がする" なるほど。
なんというかドラミちゃん自体が、結構微妙なポジションな気はします。例えばジャイ子なんかは出番が多い文、初期の役割を脱した、キャラの深みを与えられたのに対して、ドラミちゃんは出番が少なくて、「劣等生な兄と比べられる優等生な妹」という初期に役割として与えられたキャラ付けを脱せなかったんじゃないかな～、なんて思います。関係ないけど私は「ミニドラＳＯＳ」が他のドラ映画と比べてもかなり好きです。子どもだけの冒険って雰囲気がして。
https://anond.hatelabo.jp/20190506045507 すみません"真相"は不適切なので、各論に変えました。あと筆者、男です。
「言ってはいけないといわれた」ことはしっかりと覚えているのだが
「この人になら言ってもいいかな」や「この雰囲気なら言っても大丈夫だろう」というその場の自分の認識でつい言ってしまう。
いままでに、それで大きく信頼を失い友人関係を壊してしまったこともある。
すごく仲良い子には「わたしに秘密はしゃべらないでほしい。つい話すから」と言っている。
だが私のもといんはたまに「秘密」がぽんとやってきて、
そもそも仲良くなればなるほど
人はどうしても秘密を分かち合いたくなる瞬間がやってくる模様。
今年すでに大きい失敗を二回した。
Aちゃんが私に不満として漏らしたため、
2名しかいない場所で私がそれについてはっきりと名言したこと。
これはBちゃんがそもそもAちゃんに「秘密」として伝えたことを
Aちゃんが私に言ったためAちゃんも私も悪いとい言っていたのだが
まあ私が言わなくてもよかったと思う。そもそも2人の関係のことだし。
もうひとつは、ある人がある女性に誘われたという下衆いお酒の席での話。
そして冷静になると「別にあの場で言わなくてもよかったな」と思う。
想像力がないのだろうか。
本当は他人に興味がないのだろうか。
すべてに当てはまる気がする。
あ、思いついた。
逆に今年ちゃんと秘密にできていることもある。
煮えきらない態度にだんだんと愛想つかしてるようだ。
私の考える「さすがに言ったらだめ」ライン＝わかりやすい崩壊なのだろうか
実際は選んでいるだけで誰とでもセックスできる。
・友達の家で初対面とセックスした(これはバレているっぽいが、その友達は何も言わずいまでも友達でいてくれている。ありがたい。)
バレたらどうなるかも考えてみよう
・かなりだらしない人として見られるかも。
・友人をやめる人もでてくるかも。
・それを知られているところでまともな恋人はできないだろう
やめたい、とは思ってる～～～～～～～～思ってます。
日本ミステリ史をまとめようとしている人を見たので自分でもやってみようと思った。
箇条書きでも大体分かるだろう。あと本格中心なのは許してくれ。
◆探偵小説輸入の開始
http://fuboku.o.oo7.jp/e_text/nipponbungakukouza_19270530.html
・神田孝平訳「楊牙児奇獄」1877
・須藤南翠『殺人犯』1888（『無惨』に先立つ創作） "まづ未成品で、単に先駆的なものとしか見られない"（柳田泉）
◆黒岩涙香『無惨』1889 "日本探偵小説の嚆矢とは此無惨を云うなり"
・「探偵叢話」連載開始（都新聞） 1893 ……探偵実話の流行
・谷崎潤一郎「秘密」1911「白昼鬼語」1918 「途上」1920 日本探偵小説 "中興の祖"（中島河太郎）
・『中央公論』「芸術的新探偵小説」企画（谷崎・芥川・佐藤春夫・里見弴）1918
・当初は翻訳を重視
・横溝正史(1921)、水谷準(1922)、甲賀三郎(1924)、小酒井不木(1925)、大下宇陀児(1925)、夢野久作(1926)、海野十三(1928)など登場
・乱歩「二銭銅貨」1923 "これが日本人の創作だろうか。日本にもこんな作家がいるであろうか"（森下雨村）
http://www.aozora.gr.jp/cards/001826/files/57173_58183.html
◆戦前探偵小説最盛期 "第二の山"（乱歩）"第一の波"（笠井）
・『ぷろふいる』創刊 1933
・蒼井雄『船富家の惨劇』 1935
◇「本格探偵小説」
http://d.hatena.ne.jp/mystery_YM/20081205/1228485253
・甲賀三郎「印象に残る作家作品」1925 が初出 http://kohga-world.com/insyouninokorusakukasakuhin.htm
・小酒井不木「当選作所管」1926 （「本格」「変格」使用）
・当時の「探偵小説」という語の広さ……「本来の」探偵小説detective storyとそれ以外を区別
・"理知的作品"と"恐怖的作品"、"健全派"と"不健全派" 1926（平林初之輔）
・本格・変格論争 1931（甲賀、大下）
◆戦時下の中断
◆戦後のミステリ復興 "第三の山"（乱歩）"第二の波"（笠井）
・横溝『獄門島』1948
・『宝石』第一回公募 1946（香山滋、飛鳥高、山田風太郎、島田一男）
・『宝石』第四回公募 1949（鮎川哲也、土屋隆夫、日影丈吉）
・清張『点と線』1958 （表紙に「推理小説」https://www.amazon.co.jp/dp/B000JAVVEU）
・講談社「書下ろし長編推理小説シリーズ」1959-1960?
参考…
・甲賀三郎『音と幻想』1942 http://iss.ndl.go.jp/books/R100000002-I000007753808-00
・"探偵小説を「お化屋敷」の掛小屋からリアリズムの外に出したかった"（清張）
◇「本格冬の時代」？
・謎解きの興味の強い作品は絶えていない……『本格ミステリ・フラッシュバック』
・清張は謎解きを排斥していない。「新本格推理小説全集」1966 "ネオ・本格"
・「現実離れ」の作品が世に出にくかった……らしい https://togetter.com/li/300116
・風俗を描いただけの謎解きの要素の薄い作品が氾濫していた……らしい？
"社会派ということで、風俗小説か推理小説かわからないようなものが多い。推理小説的な意味で言えば水増しだよ"（清張、1976）
◇複数の対立軸？ http://d.hatena.ne.jp/noririn414/20070314
・「おじさん」――「稚気」
・都会・洗練――土着
・歴史ミステリ、ハードボイルド、エスピオナージュ、「冒険小説」、伝奇小説、SF、……
◆「新本格」以前の非・サラリーマンリアリズムの系譜 "2.5波"（笠井）
・桃源社「大ロマンの復活」1968- （国枝史郎、小栗虫太郎、海野十三、久生十蘭、香山滋……etc）
・雑誌『幻影城』1975-1979（泡坂妻夫、連城三紀彦、栗本薫、竹本健治……etc）"探偵小説復権"
・江戸川乱歩賞の青春ミステリ……小峰元『アルキメデスは手を汚さない』1973、梶龍雄『透明な季節』1977、栗本薫『ぼくらの時代』1978、小森健太郎『ローウェル城の密室』(最終候補)1982、東野圭吾『放課後』1985
・「新本格」の公称は『水車館の殺人』から……講談社文三によるブランディングの側面
・鮎川哲也賞 1990-
・『競作 五十円玉二十枚の謎』1993
・『本格推理』1993-2008
最初は私の片想いだった。SNSで知り合って、LINEも交換して、個人的な話をしていくうちに共通点がたくさんあって、話せば話すほど惹かれていった。
私があなたを好きだって言ったら「会ったこともない相手と付き合えるの？ 俺は付き合えない。でも相手はしてあげる」みたいな、そんな返事。
それからは毎日ひっきりなしにLINEしてくれて、毎日寝る時は通話してくれて。私の声が好きだって言ってくれて、通話しようって誘うのは私の方からだけではなかった。「会いたいね」とか「仲良くしようね」なんて言い合ってた。
だから、一週間の同棲の話を私に持ちかけてくれたのはすごく嬉しかった。私のことを特別だって言ってくれたし、とうとう彼も私を好きになってくれた、そう思った。
彼がTwitterで取り巻きの女と性的なやり取りをしているのが嫉妬の種だった私にとって、共通のフォロワーにそのことを隠しているのが嬉しかった。
私が嫉妬しやすい女なのは彼に伝えてるし、彼も嫉妬しやすいタイプだって言ってた。「嫉妬されて嬉しいなら好きなだけ嫉妬するし、付き合ってもいない私を気遣うことなんてないから好きにしていいよ」とも言った。
あとで「実は○○さん（共通の友人）に話しちゃった」って言われたり、最後の日には「お前ら、俺が東京にいるぞ」って出会い厨してるのを見た時は唖然とするしかなかったけど。
嫉妬しやすい者同士、少しは私の気持ちを分かってくれてるって思ってたのにな。
同棲の始まる日をすごく楽しみにしていたし、お互いに「楽しみだね。でも大丈夫かな」「私たちならきっと大丈夫だよ」って言い合ってた。
家にいる時間は私の方が長かったし、家事は基本的に私の仕事だった。
今か今かと彼が帰ってくるのを待ち続けて。帰ってきたらまた会えるのが嬉しくて笑顔で「おかえり」って抱きしめ合って。
でも、途中からは「ただいま」って笑ってくれなくなった。
帰ってきてから数時間は私を無視してノートパソコンのモニタばっか見てるし、同じベッドに入っても私に画面が見えないようにスマホにかじりついてLINEしてて。
次の日、あなたが家を出てから私がどれだけ苦悩したか分かる？ あなたが不機嫌になった理由が分からなくて、何も手につかなくて、気付いたら泣いてて。またいつ不機嫌になるのか分からないのが怖くて。もしかしたら今晩は帰ってこないんじゃないかって。それでも笑顔で接してたんだよ。
万が一だったとしても、同棲生活の末に結ばれることがあるのかもしれない。同棲相手に選んでくれたんだから可能性はある。そう思ってた。
最後の日は、上に書いた通り私がギャン泣きしてあっさりフられて。「最後に良い夢を見させて」ってセックスして。帰り道、改札まで一緒に行く道中のエレベーターとか車内でキスされたり手を繋がれたりして。
そんなことされたら諦めつかないよ。やめてよ。
でも、こうやって別れを惜しんでくれているならこれから先も接してくれるのかな、なんて思ってた。
一週間の同棲生活が終わったら、どうやら私の存在は彼の脳内から綺麗さっぱりいなくなってしまったらしい。
最初は「私をフったから気まずいのかな」なんて思ってた。でも、数日経っても返事は何もなくて。
スマホの通知が鳴るたびに、ようやく来たか。嬉しい。画面を見る。違う。がっかり。胸が締め付けられる。そんなことばかり繰り返してた。
帰り道、必死にあなたを諦めようとしてる私に対してキスしてきたり手を繋いできたり、もしかしたらちょっとでも私に情とか望みがあるのかと思ったよ。まさか会話すらされなくなるなんて思わなかった。弄ばれてただけなんだね。
わざわざマンションを借りて同棲する相手に私を選んでくれたこと、すごく嬉しかった。でもそれは、家賃も半分払ってくれて、甘やかしてくれて、股も開いてくれるヒマな女が、たまたま私しかいなかっただけだったんだよね。私は必死に頭を下げてお休み取ったんだよ。
結局、私のLINEもリプライも全部無視して、私もフォローしたままのTwitterで「相手の感情に流されるセックスばっかりしてたことを後悔してる」とか被害者ぶって。お前ノリノリで腰振ってただろ。
これは消されたからうろ覚えだけど「『セックスは相手の内面を知るための行為であって、それに特別な感情を持たれたら困るんだよね』って飲み会で話し込んじゃった笑 みんなに引かれたかも笑」とか。うん、最高に気持ち悪いよ。お花畑な勘違いしててごめんなさいね、本当に。
このあたりで何もかもが虚しくなって、LINEで「今までごめんね、さよなら」みたいなことを綴った文章を送ったと思う。当然それにも返事はなく、既読がついただけ。
いつも気持ち悪いツイートを全消ししてからフォローを増やしてるけど、いつかあなたは私に「自分をよく見せようとしてもいつかボロが出るからやめようね」って言ったよね。投げたブーメランが返ってきてる自覚はあるのかな？ まあ、あんま関係ないけど。
「私のツイートなんて全然見てないんだろうな」ってちょっと煽ってみたら速攻で私をブロックして鍵垢に。なんなんだよ。いっそのこともっと早くブロックするかミュートにでもしておけよ。期待させんなよ。
あなたが鍵垢にしたあと「人間って本当にめんどくさい」とか「言いたいことを言えないツイッターって……」とかツイートしてるの、別垢からちゃんと見てるよ。
Twitterで取り巻きの女にチヤホヤされ続ける良い子であり続けるには「冴えないオタク女と同棲してセックスしまくってたの本当に無理」とかとても言えないもんね。一人で苦しむといいよ。
「相手の感情に負をもたらすなら死にたい」なんてこともツイートしてるけど、問題を解決することに全く目を向けようとしない人間が偉そうに私に講釈垂れてたと思うと笑っちゃうね。「苦しんでる俺」を取り巻きに見せてチヤホヤされたいんだよね。
別垢を動かすのは盗み見してるようで嫌だったけど、自分のことを棚に上げて被害者アピールし続けてるのを見たら罪悪感なんてどっか行っちゃった。
私を褒めてくれたこと、泣いてる私を慰めてくれたこと、楽しかったって言ってくれたこと、全部本当の気持ちでしたか？ 私にはもう信じられません。
あ、最後の日に偉そうに講釈垂れてくれたお返しに私もいくつか言っておくね。
いくら私があなたにとってどうでもいい女だからって、人前でかゆいとこボリボリ掻くのやめようね。不潔としか思えないよ。
あと、通話で元カノのセックスがどうだの今までのマンコがどうだの延々と自慢してたよね。嫉妬しやすい私からしたら聞いてて本当につらかったし、そうじゃない人からしても気持ち悪いと思うよ。
過去のマンコ自慢をされて私が機嫌を損ねた時、あなたは私の話を全く聞こうとせず、ひたすら無視しようとしたよね。しかも、Twitterで取り巻きと絡むさまを私に見せつけながら。その時に少しでもこういう未来が待ってるって気付ければよかったな。
「セックスは知り合いとするものじゃなくて知らない相手とするものだと思ってる」なんて言ってたけど、あなたの生い立ちが特殊なことを鑑みてもやっぱり異常だよ。歪んでる。
でも、そういう他の人なら受け付けられないようなところでも、私なら変えることができるかもしれないし、私なら受け入れられるよ、だから愛して、って思ってた。
「もっと世界を広げた方がいいよ」って言ってくれたことだけは感謝してる。
相手の気持ちをとことん踏みにじって、自分の性欲と好奇心と承認欲求を満たすことしか考えてないあなたみたいな人の相手なんてもう二度としたくないし。独りよがりでオナニーみたいな人生だね。
相談に乗ってくれた人があなたのことをたくさん罵ってくれたから私もようやくあなたがろくでなしだって気付けたよ。
断片的にしか伝えてないから「いいところを知ってるのは私だけなんだな」って思うとちょっと複雑だけど。相談するって大事だね。
追記
「囲われはしたいし女オタクもメンヘラ女も好きだけど、ガチの恋愛感情持たれても絶対辛辣に扱うからお互い(都合の)いい関係を築こうな」ってツイートしてるの見て追記を我慢できなくなった。
あの、それ直接言ってくれませんか？
取り巻きに何アピっちゃってんの？
同棲生活の後半、急に仕事先とか将来の話とか真面目な話を避けるようになったから聞いたら「秘密」って言われたけど、一方的に無視して縁を切る予定があったから話す必要ないってことだったのかな。
私を同棲の相手に選んだ理由も「秘密」って同じ言葉で返してたけど、今こうやってこっぴどくフって悦に入るためだったのかな？
好きでいてくれるなら、最後に私のところに帰ってきてくれるなら都合のいい奴扱いでもいいって思ってた。
もしこの同棲生活が円満に終わっても、好きだって思ってもらえない、受け入れてくれない、って薄々感じてた。
でも、流石にこの仕打ちはひどすぎるよ。
だから、せめてものお返しに洗いざらい書いておくことにしたの。あなたの取り巻きが少しでも減って、あなたが少しでも顧みてくれたらと思って。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
実写化でわーわーヤメローヤメロー、あほかい作者にもお金入るし経済回ってるしあほかい、と思っていて本当にごめんなさい。
大好きな作品の帯に、「実写映画化！」って書いてあってこりゃ下手したら人類全員敵にまわすなって勢いで怒りが沸騰した。
こんなにも怒りに震えるなんて、あれ、わたしはもしやスーパーサイヤ人？「クリリンのことかーーーー！！」っていうサイヤ人？くらい怒った。
はてなにいるひとの多くは知らないディープなディープな少女漫画の世界だ。
ひどいよ。
ひどい。
清水玲子の漫画の良さを簡潔に伝えると、「百合もホモもLOVEもある美しい絵の生物学的化学的な漫画」なの。
もう一介のお腐れ女にはごちそう。
男も女も美しい。あんなに綺麗な絵の漫画はなかなかない。美しい。
それを？？
だめーーーーーーー！！！！
だめ！！！だめ、やめてーーーー！！
やめて！！やめて！！！
あの美しさにリアルな人間を重ねるのは犯罪だ！！いかに岡田なんちゃらがイケメンか知らねぇけどお前は毛が生えてるしチンコもあるしやることやってるただの男だ！！！
清水玲子さんの漫画の男は、そりゃそういうやつもいるけど、主役の男はそんなこと微塵も感じない。
せめて実写なら宝塚でやって…
女の美しい世界でやって…
さらにこの遭遇の多段階化は、それが単なる素朴な設定の開示であっても十分な効果をもたらしうる。『小説の秘密をめぐる十二章』において河野は谷崎の「少年」を例にあげ、少年が穏健な家庭の子であることがほのめかされることによってこそ、のちの異常性愛への没入のインパクトが強化されるのだ、と指摘しているが、ラノベはこれをより極端かつわかりやすく行っていると言ってもいいだろう。
例えば『マリみて』における第一の遭遇が「印象的な絵面」であるとは述べた通りだが、そこで一度教室の場面を挟んで理想の素敵な女性像として有名なヒロインの評判が語られ、お礼を言いに行ったところで第二の遭遇が生じる。そこで描き出されるヒロインは、自分の嫌なことから逃げ出すためになりふり構わず主人公を利用し、スールになるよう強要するというものであり、主人公（ならびに読者）のヒロインに対する見方は大きく変わることになる。設定だけを見ればこれは新規性のあるヒロイン設定とは言い難い。が、筆者はこの遭遇から十分な意外性を受けており、それは河野が指摘した例と同じ効果によるものと考えている。
同じく例えば『イリヤの空、UFOの夏（以下イリヤ）』の深夜の学校のプールにおける第一の遭遇は単純なものであるが、ヒロインの手首に埋まったものに気づいたところで物理的異質さが、そして「なめてみる？」「電気の味がするよ？」において精神的異質さが明かされる。なぜそれがインパクトをもたらすかと言えば、それはヒロインの設定の奇抜さではなく、それまでの描写は彼女の異質さを感じさせるものではなかった、という一点に尽きると筆者は理解している。
溺れて必死で主人公にしがみつき、ビート板を使って恐る恐る水泳を教わり、やっと少し泳げるようになる、という一連の「普通の女の子」であることの描写こそがこの急転直下を強力無比なものにしているのであり、だからこそ「なめてみる？」の異様さが際立つのである。もしここで気まずそうに手首を隠してヒロインがうつむき押し黙るといった、つまり「普通の女の子」がしそうな行動がなされていたとすると、全くつまらない遭遇と化すことはすぐにわかることと思う。
多段階化していつつも見方が変わらない遭遇だとどうなるかの例としては『IS』が挙げられる。教室でのヒロインとの再会という第一の遭遇ののち、寮が相部屋であることが発覚するという二度目の遭遇が発生するが、出会う前後で主人公ならびに読者によるヒロインへの見方に全く変化がない。『マリみて』や『イリヤ』と比較して意外性が無く、筆者にとってはひどく印象の薄い遭遇である。
最後に見方は変わるものの一拍置いていない（つまり段階化されていない）例について触れておきたい。冒頭で触れた『俺ガイル』は最初の遭遇から間髪入れずにその「意外性のある性格」が開示されるものであり、多段階化されていない。なるほど『俺ガイル』におけるヒロインの毒舌はそれだけで魅力のあるものであり、それは単独で読者の興味を引くことができるものだとは言えるだろう（筆者も決して嫌いではない）。しかしそれは「レイアウトの仕方」ではなく「描写の仕方」による効果であり、ヒロインの毒舌がそれ単独で魅力を得られるほどのものではなかった場合、実に陳腐でつまらないものだと筆者は考える（逆に言えば描写力が優れていればなんとかなる、ということの証左でもあるだろうが）。
念のため補足しておくと、陳腐な遭遇しか用意できない作品は全て駄作である、と述べたいわけではない。例えば『狼と香辛料』は荷台にもぐりこんだ裸の美少女が狼の化身だと明かすという意外性に乏しい遭遇であるが、ではこの作品が駄作かといえば筆者はそれほど悪くない作品だと思っている。ただし、その遭遇にインパクトを受け、興味を抱くことは無かったことも確かである。ここで張った伏線をクライマックスで回収しているため最後まで読んでみればなるほどと思えるが、もし立ち読みで眺めたのであればその場で本を置いていたと思う。
「ボーイミーツガール」の関係構築では、主人公とヒロインの恋愛感情が醸成されることは必須ではない（例えば『トリニティ・ブラッド』では恋愛感情は仄めかしすら無い）。一方で両者間の信頼関係の構築は必須と言っていいと筆者は考える。また信頼と似た効果を持つものとして敬意も有効に機能する。
さて、関係構築とは主人公とヒロインの一方が他方に何かをすることによって培われるものと言っていいだろう。その内容は小説それぞれによって様々であるが、一段階抽象化してみると次のような行為に類型化が可能であると思われる。下記で全ての行為が類型化されているわけではないが、いくつかまとめた上で、それらをどう組み合わせることが効果的な演出になりうるのかを述べたい。
遭遇の類型として「秘密の漏洩」を上げたが、あれが当人の意に沿わざるものであるのに対し、「秘密の共有」は意図的に自らの秘密を相手に共有するものを指す。
「秘密の共有」は信頼の表明がなされたという暗黙の読者の認識が得られる点で効果的であり、そして「秘密」は多くの場合、プライバシーと同義である。軽度な秘密から徐々に重大な秘密の吐露へと段階を踏まえて内容は変化する。軽度な秘密の典型例は電話番号を教える、住所を教える、そこから一歩進んで自室に入れる、といったものが挙げられるが、最も多用される「秘密」は「過去」であり、昔の笑い話といった軽いものから過去のトラウマまで「過去」は幅広く使える便利な「秘密」であり、重さを任意にコントロールできるという点で優れている。
こうした秘密の共有は信頼の表明であると述べた通り、一定の信頼があった上でなされることで読者に違和感なく受け入れられるものと考える。十分な信頼がなされたと読者に理解がされていない状態でいきなり重い過去の吐露を始めるヒロインなどは、自己陶酔中のメンヘラ設定を明らかにしたいのでもない限り慎むべきだろう。
『涼宮ハルヒの憂鬱』における曜日と髪型の関連の指摘や、『俺ガイル』における主人公がヒロインに友達がいないだろうという指摘など、観察によりヒロインのなにかに主人公が「気づく」ことを指している（ヒロインが主人公のなにかに気づくことも含む）。これはヒロインが主人公の評価を改め敬意を抱くきっかけとして、また主人公がヒロインに対する評価を改め、敬意を抱くきっかけとしても効果的に機能する。
余談ながら観察力のある主人公であることを印象づけることは、特にバトルものにおいても有効に機能するように思われる。例えば『禁書』や『バカとテストと召喚獣』、『エスケヱプ・スピヰド』はいずれも勝利をつかむきっかけとして敵に対する観察と気付きを用意しており、そこから作戦を練っている。最終的に単なる力比べになり、最強能力者である主人公が必然的に勝利するという陳腐さは、しかしそうした観察と気付き、そこからの作戦の演出が事前になされていることで読者に対する一定の納得感を与えるように思われる。もちろんそうしたものがなくとも最強主人公が敵を圧倒する物語に興奮できる読者がいることは事実だが、それにウンザリする読者も相当数いることも事実である。より幅広い読者を意識するのであれば、そうした演出一つを入れておく価値は十分にあると考える。
秘密の漏洩、共有や観察による発見など、なんらかの情報が得られる行為類型の結果として、共通点、すなわち似た者同士であることが発覚することは相手に対する親近感を惹起する。これは読者にとっての共通点でも同様であり、感情移入や共感を誘う要素と言っていいだろう。
素朴な行為であるがゆえに、信頼と好意を「少しだけ」喚起する点で高い効果を持つ。例えば大きな好意が得られる「救助」は大仰なものであり、特に好意や信頼を寄せてもいない赤の他人に対してそうした行為をする人物は、十分な理由づけが無い限り胡散臭いヤツという認識を与えるだけだろう。
これに対して「親切」はそれが当人にとって大した手間でない場合に実行されるものであり、人間関係が破綻していない限りは合理的な行動として読者に受け入れられ、その結果ほんの少し信頼と好意が得られることが自然に読者に認識されることになる。『シャナ』において主人公がヒロインにコーヒーを持って行ったこと、『とらドラ！』において主人公が朝食をヒロインにも分けてやったことなどはこの好例と言えるだろう。
相手を名字で呼ぶのか、名前で呼ぶのか、といった呼称の変化は古典的ながら現在も極めて強力にその認識の変化を読者に理解させる。『僕は友達が少ない（以下はがない）』におけるあだ名であったり、また『デート・ア・ライブ』のようなヒロインの名前を付ける、という行為も同じ効果を持つと言えるだろう。
なお、呼称の変化は一度しか使えないものではない。ある呼称を用いたのち、それを使わなくなる、という演出はその呼称を用いるようになること以上にその変化を強調する。遭遇時においてではあるが、こうした「呼ばなくなる」ことを用いた好例としては『星界の紋章』があげられよう。
一方から他方へなんらかの依頼（命令を含む）がされ、受け入れられることを指す。このとき、その依頼は明示的なものであるとは限らない。「ボーイミーツガール」における両者間のほとんどはこれに該当するが、物語を先に進める意味合いが強く、関係構築に向けて目立った効果をもたらすものではない。
一方でこの行為類型が「期待に応える」を伴って実行された場合はまた異なった効果をもたらす。最初からヒロインが主人公に対して好意を表明していたり、信頼を寄せていることが暗黙に前提となっているような「ボーイミーツガール」は珍しいものではなく（『イリヤ』『ベン・トー サバの味噌煮290円（以下ベン・トー）』など）、また物語の途中でヒロインが全幅の信頼を主人公に対して寄せるようになるものも多い（『SAO』『ココロコネクト ヒトランダム（以下ココロコネクト）』など）。
こうした例においてヒロインから主人公へ強い信頼に基いて依頼がなされている場合、依頼の達成に失敗することが強力な効果を持つ。ヒロインから主人公へ依頼した仕事の達成に主人公が失敗し、しかしヒロインがもう一度仕事を依頼することは主人公に対する深い信頼の表明として機能する上、主人公が次こそヒロインの信頼に応えようと努力する様は概ね読者の共感と応援を得られると考えられる。
例えば『ソードアート・オンライン（以下SAO）』ではヒロインが主人公に仕事を依頼し、主人公は成功し続け、それをもってヒロインが主人公に惚れこむという構造を取る。一方で『とらドラ！』においてはヒロインが主人公に対して依頼した仕事は失敗し続けるが、ヒロインが主人公に失望することは一度としてなく、最後にヒロインから主人公に同じ仕事を改めて依頼するという構造を取る（定義を読んでいれば誤解は無いと思うが、本稿ではいずれも１巻の内容のみを対象としており、シリーズを通してどうかは検討の範囲外である）。両者を比較してみると、筆者は『とらドラ！』の方がよく出来ているという認識を持つ。
『AURA 〜魔竜院光牙最後の闘い〜（以下AURA）』で繰り返されるような単なる拒否は効果を持たないが、相手に対する尊重を以て拒否することは（一時的にはともかく）相手の不快を買うものではなく、むしろ信頼と敬意を勝ち得る効果を持つ。『マリみて』において主人公がヒロインからのスールの依頼を拒否したことは典型例と言ってよく、『のうりん』におけるデビークの手助けを（これまで助力を惜しまなかった）主人公がしない、ということもこの一形態と言っていいだろう。
この時、主人公にとってはその依頼を受けた方がメリットがあることが望ましく、そうした自分の利益を捨て、相手に嫌われる覚悟の上で拒否することはヒロインのみならず読者からの信頼も勝ち得る効果があると思われる。
単純な愛の告白のような直接的な好意の表明に限らず、嬉しそうに何かをする、微笑むといった行動によっても十分に好意の表明として読者に認識される。物語最後の場面においてヒロインないし主人公がこの行為類型を取ることが多く、ハッピーエンドとしての印象を読者に意識づけることで効果的と言えるだろう（『イリヤ』や『ALL YOU NEED IS KILL』がハッピーエンドか否かは意見の分かれるところであろうが）。
相手に伝わる形で行われるそれと、相手に伝わらない形で行われるものがあり、特に本人のいないところで信頼や好意を表明することは読者の理解と共感が得られやすいように思われる。好意の表明は繰り返し使うとむしろ好意の薄っぺらさを強調することになりかねないが、『ココロコネクト』のように相手に伝わらないところでそれがなされる段階を踏まえてから、相手に伝わる形でこれを行うことは効果を増すと思われる。
窮地に陥ったヒロインを主人公が助け出す、という行為類型は『禁書』『AURA』など非常に古典的ながら多くで用いられるものである。救助された側から救助した側に対する好意を含む感謝が読者に理解されやすい点で効果的だが、あまりにもわかりやすく、またありがちなものであるがゆえに陳腐な展開という印象を読者に与える危険性がある。
例えば『僕は友達が少ない（以下はがない）』におけるプールで絡まれたヒロイン２を主人公が助け、それによってヒロイン２が主人公に好意を抱く、という展開は筆者にとってひどく陳腐なものであった。
他方で『俺の彼女と幼なじみが修羅場過ぎる』におけるチンピラに侮辱されたヒロイン２を主人公が助ける展開や、『さくら荘のペットな彼女』におけるラブホに連れ込まれかけるヒロインを主人公が助ける展開はそれほど嫌いではない。
その違いはなにかといえば、おそらく単純にその救助行為が主人公にとってリスクの低いものか高いものか、という点と、救助の際に主人公が負傷している、すなわち自己犠牲を伴う点にあるように思われる。救助は主人公にとってリスクのあるもので、かつ、怪我を追ってまで勝ち得たものであるとき、救助された女性から主人公に対して寄せられた好意の大きさは「それだけの価値のあるもの」として裏付けられると考えられる。
その意味で、無傷でほとんどリスク無く救助したことで得られた好意はほとんど無いに等しいはずであり、にも関わらずヒロインが大きな好意を寄せる状態となり、そこにちぐはぐさと薄っぺらさを感じるように筆者には思われる。
『禁書』では記憶を喪失し、『AURA』では中二病を世間に露出し、『俺妹』では自分は変態だと言って父親へ立ち向かい、『タイムリープ』では自分の過去（未来）が変わろうが知ったことかと手紙を書く。自己犠牲は主人公がこれまで大事にしてきた何かを失ってでもヒロインを守ろうとする意思の明示としても機能し、ゆえにその対価として大きな好意と信頼が得られることに読者は納得がいくものであろう。
この1ヶ月、大妻、歯が無いお爺さん写メ、DS置き引き、マクドの無料券を500枚盗み配布、その他もろもろ、Twitterがバカッターとか馬鹿発見器とかよばれるようになりましたが、自分が思うに、「人は秘密を話したがる」と思うのですよ。
たまたま、手近なツールがTwitterだった、というだけで。
先日のAUのiPhoneの話も、どこぞの店の店長（？）とおぼしき人間が、発表前に情報を流していましたが、結局、「秘密」。やはり秘密は話したいのですよ。それと、「他人が知り得ないこういう秘密を俺は握っているんだ」という優越感に浸りたいのだと思う。
まぁ、私にとってはお祭りが多くて、傍から見てる分には楽しいですけどね。これも「他人の不幸は蜜の味」と言う事なんでしょうかね。それは否定はしません。
お祭りで攻撃する側も（犯罪自慢に対するお祭り以外にも）、「他人を攻撃するのは幸福」という原理からでしょう。自分が正しい、常識とか、そんな事から攻撃してるのでは無いと思うのです。単に「攻撃する事が快感」なだけで、ブログや告知などでいくら反論・訂正等しても、意味は無い。攻撃する側からみて、そんな事はどうでもよくて、「快感だから」ただそれだけだから。
写メとか、某所でのニコ生とか見てると、家から一歩外に出たら、プライバシーが存在しない感がありますね。誰かが自分を見て撮ってるかもしれないし、Twitterでつぶやいているかもしれない。
機密かどうか疑わしいんじゃなくて、それが機密だと言われれば機密として動かさないといけないの。
なお、国家公務員法第一○○条一項の文言及び趣旨を考慮すると、同条項にいう「秘密」であるためには、国家機関が単にある事項につき形式的に秘扱の指定をしただけでは足りず、右「秘密」とは、非公知の事項であって、実質的にもそれを秘密として保護するに値すると認められるものをいうと解すべきところ、
政府なり何なりが「これ、秘密扱いな」と何でもかんでも一方的に決定出来るわけではない。最初から非公知で、秘密にする価値のある情報でなければ「秘密」とはみなされない。例のビデオが上記の条件を全て満たすかどうかが最大のポイント。
それに加えてあの件では、政府は海保にいい加減な指示(公開するなとだけ)しかしておらず、職員はその気になればいつでも見られる状態だった(だからこそsengoku38は外部に持ち出せたわけだが)。
仮に政府が本気で隠匿したかったら、あの映像の取り扱いの管轄を外務省か内閣官房あたりに移すのが最も簡単で確実だった。しかし政府は「海保が勝手にやった事」という建前のためにそれを敢えてしなかった。
仮にあの件が法廷に持ち込まれたら政府側が負ける可能性が高いよ。だからsengoku38が「自主的に」海保を去って胸をなで下ろしてるんじゃないかな。もっと重大な問題は完全に棚上げされてるけど。
馬渕はむしろ「するべき事をしなかった」のが問題。
例のビデオの件で馬渕は何をしたかつーと、10月18日に海保に映像を金庫に保管するよう指示しただけ。こんだけ。衝突事件発生(映像撮影)から実に6週間後。その間例のビデオを機密扱いとする根拠は何も無い。単に公判前だから刑事訴訟法上証拠物件を公開出来ないってだけの状態だった。
本気で機密にしたかったら速攻で内閣なり外務省なりに移せばいいだろという話。そうすれば例のビデオは確実に「機密指定」が出来ていた。
何故そうしなかったのか？
実は9月30日の国会質疑で菅はビデオを見てるのかという質問に対して「見ていない」と回答している。
何故か？
「ビデオ非公開は那覇地検が勝手にやった事だから政府に責任はねーよ」というポーズのため。
でもって、国家公務員法に記載されてある「秘密」は、元々が非公知のものであり、且つ秘匿するに値するものである必要があるって最高裁判例があるんで、メディアやら他の議員やらに「中国漁船側の違法性が明白に記録されている」と公然と内容が漏れていて、しかも流出直前には一部の議員に映像の一部が公開されていた代物が果たして「非公知の秘密」なのかどうかもかなり微妙な判断になってくると思う。
これってさ、情報管理体制がどうこう以前の問題として、そもそもあの映像を機密化する事自体が無理筋だったって事なんじゃないの？
仮に逮捕するとなると、根拠となる法律はおそらくこの辺になるかと思われるが、
国家公務員法
第百条 職員は、職務上知ることのできた秘密を漏らしてはならない。その職を退いた後といえども同様とする。
じゃあ、あのビデオが「秘密」なのかっつーと、こんな最高裁判例がある。
http://www.courts.go.jp/search/jhsp0030?action_id=dspDetail&hanreiSrchKbn=01&hanreiNo=51065&hanreiKbn=01
なお、国家公務員法第一○○条一項の文言及び趣旨を考慮すると、同条項にいう「秘密」であるためには、国家機関が単にある事項につき形式的に秘扱の指定をしただけでは足りず、右「秘密」とは、非公知の事項であって、実質的にもそれを秘密として保護するに値すると認められるものをいうと解すべきところ、原判決の認定事実に寄れば、本件「営業庶業等所得標準率表」及び「所得業種目別効率表」は、いずれも本件当時いまだに一般に了知されてはおらず、これを公表すると、青色申告を中心とする申告納税制度の健全な発展を阻害し、脱税を誘発するおそれがあるなど税務行政上弊害が生ずるので一般から秘匿されるべきものであるというのであつて、これらが同条項にいわゆる「秘密」にあたるとした原判決の判断は正当である。
政府が「この物件今から秘密な」と一方的に指定するだけでは「秘密」とはみなされないので、それを公開した公務員も「秘密を漏らし」た事にはならないという事になる。全国の管区で閲覧出来ていたって事は、「この管区でこんな事をしたよ」と情報やノウハウを共有するためのデータとして扱われてた可能性もある。この辺は国会で突っ込まれてた。
とある同期の女性Ａが、同期の飲み会で集まると必ず、「一部の人にしか伝わらない話」をする。たわいもない内容で、単に「登場人物に知らない人がいる」「知らない土地が出てくる」、前の話題に係るちょっとしたエピソードだったりするのだが、わたしはそれが我慢ならない。
なぜ我慢ならないのかというと、彼女がそういう話を、解説ナシで終えようとするからである。わたしは彼女と距離を近しくしていたので、何の話かわかることのほうが多く、さらには同意を求められたりするのだが、こちらは同意もそこそこに、会話からなんとなく遠ざかってしまい、目の前の食事をぼんやりみつめはじめた他の同期たちに解説をしてしまう。めんどくせー。わたしもチヂミ食べたいよ。
これは何も飲み会に限ったことではなく、３人いればもう始まってしまう。「この前行った店の…」その店はわたしと彼女で行ったのだ。つづきが、「パスタがおいしかったんだよー。オススメ！由美ちゃんも今度行こうよ／由美ちゃんも最近どこか新しいお店みつけた？」など、第三者・由美ちゃんを取り込んで進めるなら全然問題ない。だが、Ａはそうしない。「この前行った店のパスタもおいしかったよね（わたしを見て笑うのみ）。」こうなったら由美ちゃんのツッコミ（いつ行ったの？／どこのお店？／だれと行ったの？）待ちとしか思えないんだが、そうじゃなかった。いちど解説もせず、由美ちゃんも突っ込まずで話題が流れても、Ａは発言しただけで満足なようすであった。なんなん。
思うにＡにとっては他人と何かを共有していた、という過去の体験がすごく重要なんだろう。ちょっとした思い出を積み重ねて、発言して確認する。前述のような、なんでもないエピソードならいいが（わたしがいやなだけで）、「当事者にとっては秘密にしておきたいことまで、人前でしゃべってしまう」ということも起こっている。これはあちこちで反感をかっているようだ。プライベートなできごとは、本人の口から語られるのを待つべきだという感覚、
そこまでいかなくても「察してあげる」感覚というのは、当たり前に誰もが持っていると思っていたので、面食らった。
Ａは中学時代、学校に馴染めず、ほぼ登校拒否のような感じだったらしい。思春期の女の子達は「秘密」に敏感だ。その時期に揉まれていないから今になっても利害関係がシュミュレートできないのかもなあ、などと想像してしまう。
とはいえわたしも、小学校・中学校ではたびたび仲間はずれにされて、やるせない気持ちを味わった。それが未だに、クスクスウフフの視線でかわされるやりとりに憤る原因なのかもしれない。
http://www.chunichi.co.jp/s/article/2009041501000342.html
奈良県の医師宅放火殺人の調書漏えい事件で、医師の長男（１９）＝中等少年院送致＝を鑑定し、供述調書などを漏らしたとして秘密漏示罪に問われた精神科医崎浜盛三被告（５１）に、奈良地裁は１５日、懲役４月、執行猶予３年（求刑懲役６月）の判決を言い渡した。 石川恭司裁判長は判決理由で「被告の行為は長男の利益を図るものとはいえない。取材に協力する正当な理由はない」と指摘。「調書を見せたのは軽率で公私混同だが、出版には関与していない」と述べた。 最高裁によると、統計がある１９７８年以降、秘密漏示罪の判決は初めて。極めてまれな罪を適用して取材源の責任のみを追及した捜査当局の判断を追認した形で、表現の自由や知る権利をめぐる論議が再燃しそうだ。 弁護側は（１）鑑定には医師が前提とする治療目的がなく、鑑定人は秘密漏示罪が守秘義務を課す医師に該当しない（２）供述調書は法廷で公開されるのが前提で秘密に当たらない（３）長男が殺人者でないことを社会に理解してもらうという正当な理由があった―などと無罪を主張した。 しかし、判決は「被告は法が規定する医師で、精神鑑定は業務に当たる」と指摘。調書も「秘密」に該当するとした。その上で、取材への協力であっても正当な理由がないので違法であることは免れないと結論づけた。
どこからどう見ても職務上知りえた情報を漏洩させているようにしか見えんのだが、
極めてまれな罪を適用して取材源の責任のみを追及した捜査当局の判断を追認した形で、表現の自由や知る権利をめぐる論議が再燃しそうだ。
こういう物言いになる理由がわからん。
元増田じゃないけど。
しょっぱなは「箱の中」「檻の外」をお薦めする。
痴漢冤罪で収監された男
「箱の中」asin:4883862925
「檻の外」asin:4883862984
死体を隠した男
「美しいこと（上）」asin:4883863360
「美しいこと（下）」asin:4883863433
肥満体型の男
「Don’t worry mama」asin:4862631134
