「「秘密」」を含む日記 RSS

はてなキーワード: 「秘密」とは

2019-07-26

CoCエモいうちよそが嫌いだ

タイトルの通りである

私が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タイマンしてきた〜♥恋仲になりました♥」と心底嬉しそうな報告ツイートに、ふぁぼも祝電リプも送れない意地悪な自分に嫌気が差すし、かといって界隈から離れるには横の繋がりが多すぎて村八分状態になってしまうのが寂しいと抜かす、ただのかまってちゃんで我儘なプレイヤーだ。

2019-06-24

anond:20190624162054

オカルトってのは、古代言葉「秘密」意味すんだけどさ

まあ例えば「簡単に火を起こす方法」ってのがあったときそれを「秘密」にすることで魔術になるんだよね。

なに増田ってオカルト信者だったの?

そいやギリシャの話かいたからついでに書いちゃうんだけど

ドラコン」さんってギリシャ人がいてさ。

この人、立法っていう難しい芸をした人なんだよね

いやたとえばね「法律」ってものがあったとき今日本だったら e-govとか見ればすぐみれるじゃん?

それをみて、何が犯罪になるか、何が犯罪にならないか、どうやったら潜脱できるかを自分で考えれるわけだ(これは識字率一定以上あるからできる芸でもあるけど)年金だってそうだよ?見ればちゃんとわかるようになっている。

当然古代にはそんなものなくてさ、「お前は犯罪者だー」って、慣習法を知っているちょっと頭のいい人に言われた時、対抗できなかったんだよね、知らない人

この頃の知らない人ってのは庶民で知ってる人ってのは貴族なんだけどね

ルールが明文化されていないから、何がダメで何がいいかからない、これをなんとかしたのがドラコンさんって人だったんだ、庶民にも生きるためのルールを明文化して、誰でもわかるようにするって、とても大事なことをなした人なんだよ。

ちなみにちょっとした犯罪でも重罰にしちゃう人だったので、そこらへんはあとで修正されました。

2019-05-02

anond:20190502082818

セワシ問題の解答候補セワシタイムパトロール隊員説」まとめ・その2

https://anond.hatelabo.jp/20190502082818 の続き

.

ドラえもんの所有するひみつ道具は「未来デパート商品」などではなく、政府機関軍隊・T・Pなど、公権力だけに製造・所有・使用許可されている非買品であるドラえもんがその所持を許されているのは、前述の通り英雄特権であり、その使用はT・Pによって絶えず監視されている。

そもそも未来デパート」というブランド名おかしい。22世紀の人間にとって、22世紀は「現代なのだから。余談だが韓国には現代グループ資本現代百貨店というのがあるそうだ。

お店で買えるのに「ひみつ道具」とはこれいかに

危険ひみつ道具民間所有、特に個人所有が許されているはずがない。特に時間犯罪可能にするタイムマシン製造・所有・使用が厳しく制限されているはずである

ドラえもんひみつ道具を「注文」をすると、T・Pによる審議を経て許可されたひみつ道具けが未来デパートから配送された」という体裁をとって送られてくるシステムだろう(許可されなかった場合在庫切れとかなんとか口実をつけて購入できない)。ドラえもんも騙されている可能性が高い。この裏舞台こそがひみつ道具「秘密」だろう。

ヒーローマシングラフィックがショボかったのも官制品だからかもしれない

そもそもセワシの家が貧しいなら、いくつもひみつ道具を持っているのはおかしい。

ドラえもん危険ひみつ道具の所有が許されているのは、前述の通り、それが歴史の安定に必要判断された故。

他の未来人がひみつ道具タイムマシンを利用しているような描写もあるが、ドラえもんたちほど無制限には使えないはずだ。

ドラえもんひみつ道具使用についても、T・Pよって24時間監視されており、深刻な影響(少数人命の被害程度は容認)があると判断された場合ひみつ道具強制機能停止か、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も無制限ドラえもんたちの行為容認しているわけではなく、歴史に深刻な影響(少数人命の被害程度は容認)があると判断された行為にはストップをかけている。空想動物徴収など。

おそらく24時間ドラえもんたちの行為監視分析されているはず。

.

セワシT・P隊員説が正しいとすると、「ドラえもん」は「SF(すこしふしぎ)生活ギャグ漫画」の皮をかぶった「時間旅行系ハードコアSFサイエンスフィクション漫画」ということになるだろう。

作者・藤子・F・不二雄大人向けSF短編集の内容や、彼の幅広い文学に対する造詣と関心を考えれば、そういう背景設定があったことは想像に難くない。

T・Pぼん藤子・F・不二雄先生SF短編集は面白いからみんな機会があったら読んでみてね♪

.

セワシT・P隊員説というのは詰まるところ「ドラえもんギャグ漫画であって、のび太世界を救うヒーローじゃない」というのはやっぱり嘘だったという話だ。

世界を救うのはもうやめた」マリーのアトリエでも結局魔王倒してるし(任意だけど)、「俺たちは、正義の味方、なんかじゃない」リジョイスも結局魔王倒してるし、つまりそういうこと。

その点「もう勇者しない」moon有言実行である

※返答2

https://anond.hatelabo.jp/20190503093926 "「恐竜狩りはスポーツとして大人気なんだ」と「恐竜狩りは犯罪TP捕縛される」の矛盾はどうなんだ"

この説で言うと、「恐竜狩りは犯罪TP捕縛される」が真実で、「恐竜狩りがスポーツとして大人気なんだ」の方がウソだったということになりますドラえもんに与えられた「子ども騙し」設定の一種でしょう、そういう話をすればのび太が喜ぶだろうと考えての。その後都合が悪くなったので、全員の記憶改竄が行われたはずです。

id:islecape ご注意ありがとうございます。 そうですね、書いてあるから正しいとは限りませんしね。 ただ、「天気決定表」のドラえもんセリフに22世紀では気象庁が天気を決めているというような趣旨のものがあるらしいので、もしそうならそれも傍証になると思います

https://www.nikkei.com/article/DGXDZO45715160U2A900C1MM8000/ 孫引きすみません

"Web等で喧伝される極端なドラミあげドラさげって片倉設定由来みたいな気がする" なるほど。

なんというかドラミちゃん自体が、結構微妙ポジションな気はします。例えばジャイ子なんかは出番が多い文、初期の役割を脱した、キャラの深みを与えられたのに対して、ドラミちゃんは出番が少なくて、「劣等生な兄と比べられる優等生な妹」という初期に役割として与えられたキャラ付けを脱せなかったんじゃないかな~、なんて思います関係ないけど私は「ミニドラSOS」が他のドラ映画と比べてもかなり好きです。子どもだけの冒険って雰囲気がして。

https://anond.hatelabo.jp/20190506045507 すみません"真相"は不適切なので、各論に変えました。あと筆者、男です。

2019-05-01

anond:20190501132816

そのうちもっと簡単に、例えばウェアラブルカメラを世の中のみんながつけるようになったら、もう「秘密」と言う概念のものが崩れて行くのかな。

2018-02-03

録画してたアンナチュラル一気見した

久々にドラマ見てすっげーワクワクした。

自体全然違うんだけど、清水玲子先生「秘密」を読んだ時のワクワク感に似てた。

あー、秘密実写版どうして脚本野木亜紀子さんじゃなかったんだろうな…連ドラじゃなかったんだろうな…

2018-01-13

東野圭吾「秘密」って完全にNTR小説だと思うんだが

これって男特有感覚なんかな

2017-11-15

「秘密」をしゃべってしまう人←私。

言ってはいけないといわれた」ことはしっかりと覚えているのだが

「この人になら言ってもいいかな」や「この雰囲気なら言っても大丈夫だろう」というその場の自分認識でつい言ってしまう。

いままでに、それで大きく信頼を失い友人関係を壊してしまたこともある。

すごく仲良い子には「わたし秘密はしゃべらないでほしい。つい話すから」と言っている。

だが私のもといんはたまに「秘密」がぽんとやってきて、

わたしはそれをふいにしゃべってしまう。

そもそも仲良くなればなるほど

人はどうしても秘密を分かち合いたくなる瞬間がやってくる模様。

今年すでに大きい失敗を二回した。

ひとつは、AちゃんとBちゃん同士でしか知りえないことを

Aちゃんが私に不満として漏らしたため、

2名しかいない場所で私がそれについてはっきりと名言たこと。

これはBちゃんがそもそもAちゃんに「秘密」として伝えたことを

Aちゃんが私に言ったためAちゃんも私も悪いとい言っていたのだが

まあ私が言わなくてもよかったと思う。そもそも2人の関係のことだし。 

もうひとつは、ある人がある女性に誘われたという下衆いお酒の席での話。

バーテンと仲良しの人しかいないか大丈夫かなと思ったら

そのバーはそもそも件の女性テリトリー内だった。

二つとも人間関係に関する秘密

そして冷静になると「別にあの場で言わなくてもよかったな」と思う。

調子にのっておしゃべりをしてしまうのだろうか。

想像力がないのだろうか。

本当は他人に興味がないのだろうか。

自分勝手なのだろうか。

自己中心的な考えなのだろうか。

すべてに当てはまる気がする。

あ、思いついた。

逆に今年ちゃんと秘密にできていることもある。

・○○さんは彼女のいるあの人とセックスしたが、

 煮えきらない態度にだんだんと愛想つかしてるようだ。

これはそれを誰かに話すとコミュニティ崩壊するため。

私の考える「さすがに言ったらだめ」ライン=わかりやす崩壊なのだろうか

さらに私が言われたら嫌な秘密を書いてみよう

・もとSM風俗嬢である(いまのところ誰にも言っていない)

・新しいコミュティでは恋愛に関してまじめぶってみるが、

 実際は選んでいるだけで誰とでもセックスできる。

友達の家で初対面とセックスした(これはバレているっぽいが、その友達は何も言わずいまでも友達でいてくれている。ありがたい。)

バレたらどうなるかも考えてみよう

・かなりだらしない人として見られるかも。

・友人をやめる人もでてくるかも。

・それを知られているところでまともな恋人はできないだろう

やめたい、とは思ってる~~~~~~~~思ってます

2017-03-23

ウィークリーマンションで夢の同棲生活かと思ったら何もかも踏みにじられた話

最初は私の片想いだった。SNSで知り合って、LINEも交換して、個人的な話をしていくうちに共通点がたくさんあって、話せば話すほど惹かれていった。

私があなたを好きだって言ったら「会ったこともない相手と付き合えるの? 俺は付き合えない。でも相手はしてあげる」みたいな、そんな返事。

それから毎日ひっきりなしにLINEしてくれて、毎日寝る時は通話してくれて。私の声が好きだって言ってくれて、通話しようって誘うのは私の方からだけではなかった。「会いたいね」とか「仲良くしようね」なんて言い合ってた。

から、一週間の同棲の話を私に持ちかけてくれたのはすごく嬉しかった。私のことを特別だって言ってくれたし、とうとう彼も私を好きになってくれた、そう思った。

彼がTwitter取り巻きの女と性的なやり取りをしているのが嫉妬の種だった私にとって、共通フォロワーにそのことを隠しているのが嬉しかった。

私が嫉妬やすい女なのは彼に伝えてるし、彼も嫉妬やすタイプだって言ってた。「嫉妬されて嬉しいなら好きなだけ嫉妬するし、付き合ってもいない私を気遣うことなんてないから好きにしていいよ」とも言った。

あとで「実は○○さん(共通の友人)に話しちゃった」って言われたり、最後の日には「お前ら、俺が東京にいるぞ」って出会い厨してるのを見た時は唖然とするしかなかったけど。

嫉妬やすい者同士、少しは私の気持ちを分かってくれてるって思ってたのにな。

同棲の始まる日をすごく楽しみにしていたし、お互いに「楽しみだね。でも大丈夫かな」「私たちならきっと大丈夫だよ」って言い合ってた。

家にいる時間は私の方が長かったし、家事基本的に私の仕事だった。

今か今かと彼が帰ってくるのを待ち続けて。帰ってきたらまた会えるのが嬉しくて笑顔で「おかえり」って抱きしめ合って。

でも、途中からは「ただいま」って笑ってくれなくなった。

帰ってきてから時間は私を無視してノートパソコンモニタばっか見てるし、同じベッドに入っても私に画面が見えないようにスマホにかじりついてLINEしてて。

次の日、あなたが家を出てから私がどれだけ苦悩したか分かる? あなたが不機嫌になった理由が分からなくて、何も手につかなくて、気付いたら泣いてて。またいつ不機嫌になるのか分からないのが怖くて。もしかしたら今晩は帰ってこないんじゃないかって。それでも笑顔で接してたんだよ。

万が一だったとしても、同棲生活の末に結ばれることがあるのかもしれない。同棲相手に選んでくれたんだから可能性はある。そう思ってた。

最後の日は、上に書いた通り私がギャン泣きしてあっさりフられて。「最後に良い夢を見させて」ってセックスして。帰り道、改札まで一緒に行く道中のエレベーターとか車内でキスされたり手を繋がれたりして。

そんなことされたら諦めつかないよ。やめてよ。

でも、こうやって別れを惜しんでくれているならこれから先も接してくれるのかな、なんて思ってた。

一週間の同棲生活が終わったら、どうやら私の存在は彼の脳内から綺麗さっぱりいなくなってしまったらしい。

ひたすら無視。せめて既読がつくだけ。

最初は「私をフったから気まずいのかな」なんて思ってた。でも、数日経っても返事は何もなくて。

スマホの通知が鳴るたびに、ようやく来たか。嬉しい。画面を見る。違う。がっかり。胸が締め付けられる。そんなことばかり繰り返してた。

帰り道、必死あなたを諦めようとしてる私に対してキスしてきたり手を繋いできたり、もしかしたらちょっとでも私に情とか望みがあるのかと思ったよ。まさか会話すらされなくなるなんて思わなかった。弄ばれてただけなんだね。

わざわざマンションを借りて同棲する相手に私を選んでくれたこと、すごく嬉しかった。でもそれは、家賃も半分払ってくれて、甘やかしてくれて、股も開いてくれるヒマな女が、たまたましかいなかっただけだったんだよね。私は必死に頭を下げてお休み取ったんだよ。

結局、私のLINEリプライも全部無視して、私もフォローしたままのTwitterで「相手感情に流されるセックスばっかりしてたことを後悔してる」とか被害者ぶって。お前ノリノリで腰振ってただろ。

これは消されたかうろ覚えだけど「『セックス相手内面を知るための行為であって、それに特別感情を持たれたら困るんだよね』って飲み会で話し込んじゃった笑 みんなに引かれたかも笑」とか。うん、最高に気持ち悪いよ。お花畑勘違いしててごめんなさいね、本当に。

このあたりで何もかもが虚しくなって、LINEで「今までごめんね、さよなら」みたいなことを綴った文章を送ったと思う。当然それにも返事はなく、既読がついただけ。

いつも気持ち悪いツイートを全消ししてからフォローを増やしてるけど、いつかあなたは私に「自分をよく見せようとしてもいつかボロが出るからやめようね」って言ったよね。投げたブーメランが返ってきてる自覚はあるのかな? まあ、あん関係ないけど。

「私のツイートなんて全然見てないんだろうな」ってちょっと煽ってみたら速攻で私をブロックして鍵垢に。なんなんだよ。いっそのこともっと早くブロックするかミュートにでもしておけよ。期待させんなよ。

あなたが鍵垢にしたあと「人間って本当にめんどくさい」とか「言いたいことを言えないツイッターって……」とかツイートしてるの、別垢からちゃんと見てるよ。

Twitter取り巻きの女にチヤホヤされ続ける良い子であり続けるには「冴えないオタク女と同棲してセックスしまくってたの本当に無理」とかとても言えないもんね。一人で苦しむといいよ。

相手感情に負をもたらすなら死にたい」なんてこともツイートしてるけど、問題解決することに全く目を向けようとしない人間が偉そうに私に講釈垂れてたと思うと笑っちゃうね。「苦しんでる俺」を取り巻きに見せてチヤホヤされたいんだよね。

別垢を動かすのは盗み見してるようで嫌だったけど、自分のことを棚に上げて被害者アピールし続けてるのを見たら罪悪感なんてどっか行っちゃった。

私を褒めてくれたこと、泣いてる私を慰めてくれたこと、楽しかったって言ってくれたこと、全部本当の気持ちでしたか? 私にはもう信じられません。

あ、最後の日に偉そうに講釈垂れてくれたお返しに私もいくつか言っておくね。

いくら私があなたにとってどうでもいい女だからって、人前でかゆいとこボリボリ掻くのやめようね。不潔としか思えないよ。

あと、通話元カノセックスがどうだの今までのマンコがどうだの延々と自慢してたよね。嫉妬やすい私からしたら聞いてて本当につらかったし、そうじゃない人からしても気持ち悪いと思うよ。

過去マンコ自慢をされて私が機嫌を損ねた時、あなたは私の話を全く聞こうとせず、ひたすら無視しようとしたよね。しかも、Twitter取り巻きと絡むさまを私に見せつけながら。その時に少しでもこういう未来が待ってるって気付ければよかったな。

セックスは知り合いとするものじゃなくて知らない相手とするものだと思ってる」なんて言ってたけど、あなたの生い立ちが特殊なことを鑑みてもやっぱり異常だよ。歪んでる。

でも、そういう他の人なら受け付けられないようなところでも、私なら変えることができるかもしれないし、私なら受け入れられるよ、だから愛して、って思ってた。

もっと世界を広げた方がいいよ」って言ってくれたことだけは感謝してる。

相手気持ちをとことん踏みにじって、自分の性欲と好奇心承認欲求を満たすことしか考えてないあなたみたいな人の相手なんてもう二度としたくないし。独りよがりオナニーみたいな人生だね。

相談に乗ってくれた人があなたのことをたくさん罵ってくれたから私もようやくあなたろくでなしだって気付けたよ。

断片的にしか伝えてないから「いいところを知ってるのは私だけなんだな」って思うとちょっと複雑だけど。相談するって大事だね。

いい経験させてもらったよ、どうもありがとう

追記

「囲われはしたいし女オタクメンヘラ女も好きだけど、ガチ恋愛感情持たれても絶対辛辣に扱うからお互い(都合の)いい関係を築こうな」ってツイートしてるの見て追記を我慢できなくなった。

あの、それ直接言ってくれませんか?

取り巻きに何アピっちゃってんの?

同棲生活の後半、急に仕事先とか将来の話とか真面目な話を避けるようになったから聞いたら「秘密」って言われたけど、一方的無視して縁を切る予定があったから話す必要ないってことだったのかな。

私を同棲相手に選んだ理由「秘密」って同じ言葉で返してたけど、今こうやってこっぴどくフって悦に入るためだったのかな?

好きでいてくれるなら、最後に私のところに帰ってきてくれるなら都合のいい奴扱いでもいいって思ってた。

もしこの同棲生活円満に終わっても、好きだって思ってもらえない、受け入れてくれない、って薄々感じてた。

でも、流石にこの仕打ちはひどすぎるよ。

から、せめてものお返しに洗いざらい書いておくことにしたの。あなた取り巻きが少しでも減って、あなたが少しでも顧みてくれたらと思って。

取り巻きがずっとチヤホヤしてくれるといいね。かわいそうな人。

2016-10-23

落ち込んでいるとき、元気が出る映画3選(あらすじ付)

チェンジリング

ある日突然愛する息子がいなくなってしまった!?

数日後、家に帰ってきた「自称息子」はどう見たって別人!

もしかして、私の息子とニセ息子が入れ替わっちゃったの〜!?

シングルマザーとニセ息子の、ニセの親子生活が始まる——!

ロサンゼルスでの実話を元に作られたドタバタ!?ドラマ

レクイエム・フォー・ドリーム

ちょっとワルな主人公ハリーは、陽気な黒人友達美人彼女楽しい毎日を送る。

そんなある日、ハリー母親・サラがダイエットを始めて……!?

ちょっとママ、そのダイエット何かおかしくない!?

ハリー友情愛情、そして母親との絆を取り戻すことができるのか!

ダンサー・イン・ザ・ダーク

女手一つで息子を育てるセルマは、工場で働く女性

お仕事だけじゃなくて、ミュージカルお稽古も全力で取り組むセルマ。

働きながら、工場機械音に合わせて踊る妄想をしちゃう日も☆

そんなセルマには、みんなにナイショのある「秘密」があって……!?

2016-05-02

離婚理由

おたがいの「秘密」をうまく共有出来るかどうかが夫婦円満のカギ。

「秘密」と書くと甘美で良いものにも聞こえるが、これを「恥」と言い換えても同じこと。

相手性癖パンツの汚れっぷりまで共有することになる。

秘密(恥)にも大小さまざまあって、それらが慣れによって気にならなくなるものならよいが、どうしても気になって仕方ないものが出てしまうとOUT

おいらは共依存強要されたので離婚した。

きもちわるい。

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、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 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ 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のことを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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

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

2015-07-29

実写化バカにしてまじごめん

実写化でわーわーヤメローメローあほかい作者にもお金入るし経済回ってるしあほかい、と思っていて本当にごめんなさい。

大好きな作品の帯に、「実写映画化!」って書いてあってこりゃ下手したら人類全員敵にまわすなって勢いで怒りが沸騰した。

こんなにも怒りに震えるなんて、あれ、わたしはもしやスーパーサイヤ人?「クリリンのことかーーーー!!」っていうサイヤ人?くらい怒った。

はてなにいるひとの多くは知らないディープディープ少女漫画世界だ。

清水玲子さんの、「秘密」映画化されるんだと。

ひどいよ。

ひどい。

清水玲子漫画の良さを簡潔に伝えると、「百合ホモLOVEもある美しい絵の生物学化学的な漫画」なの。

もう一介のお腐れ女にはごちそう。

美しいし理論的(若干ストーリーが弱いけどいいの)。

男も女も美しい。あんなに綺麗な絵の漫画はなかなかない。美しい。

それを??

実写??岡田なんちゃら?????

だめーーーーーーー!!!

だめ!!!だめ、やめてーーーー!!

やめて!!やめて!!!

あの美しさにリアル人間を重ねるのは犯罪だ!!いかに岡田なんちゃらがイケメンか知らねぇけどお前は毛が生えてるしチンコもあるしやることやってるただの男だ!!!

清水玲子さんの漫画の男は、そりゃそういうやつもいるけど、主役の男はそんなこと微塵も感じない。

美しさ、紳士さ、まるで女性のような物腰…

そう、私たち世代ベルサイユの薔薇なんだよ…。

せめて実写なら宝塚でやって…

女の美しい世界でやって…

毛の生えたチンコ野郎に用はねぇんだよこちとら…

2015-02-26

ラノベの「よく出来た」ボーイミーツガールテンプレート私論(中編)

さらにこの遭遇の多段階化は、それが単なる素朴な設定の開示であっても十分な効果をもたらしうる。『小説秘密をめぐる十二章』において河野は谷崎の「少年」を例にあげ、少年が穏健な家庭の子であることがほのめかされることによってこそ、のちの異常性愛への没入のインパクトが強化されるのだ、と指摘しているが、ラノベはこれをより極端かつわかりやすく行っていると言ってもいいだろう。

例えば『マリみて』における第一の遭遇が「印象的な絵面」であるとは述べた通りだが、そこで一度教室の場面を挟んで理想の素敵な女性像として有名なヒロインの評判が語られ、お礼を言いに行ったところで第二の遭遇が生じる。そこで描き出されるヒロインは、自分の嫌なことから逃げ出すためになりふり構わず主人公を利用し、スールになるよう強要するというものであり、主人公(ならびに読者)のヒロインに対する見方は大きく変わることになる。設定だけを見ればこれは新規性のあるヒロイン設定とは言い難い。が、筆者はこの遭遇から十分な意外性を受けており、それは河野が指摘した例と同じ効果によるものと考えている。

同じく例えば『イリヤの空、UFOの夏(以下イリヤ)』の深夜の学校プールにおける第一の遭遇は単純なものであるが、ヒロインの手首に埋まったものに気づいたところで物理的異質さが、そして「なめてみる?」「電気の味がするよ?」において精神的異質さが明かされる。なぜそれがインパクトをもたらすかと言えば、それはヒロインの設定の奇抜さではなく、それまでの描写彼女の異質さを感じさせるものではなかった、という一点に尽きると筆者は理解している。

溺れて必死主人公にしがみつきビート板を使って恐る恐る水泳を教わり、やっと少し泳げるようになる、という一連の「普通女の子であることの描写こそがこの急転直下を強力無比なものにしているのであり、だからこそ「なめてみる?」の異様さが際立つのである。もしここで気まずそうに手首を隠してヒロインうつむき押し黙るといった、つまり普通女の子」がしそうな行動がなされていたとすると、全くつまらない遭遇と化すことはすぐにわかることと思う。

多段階化していつつも見方が変わらない遭遇だとどうなるかの例としては『IS』が挙げられる。教室でのヒロインとの再会という第一の遭遇ののち、寮が相部屋であることが発覚するという二度目の遭遇が発生するが、出会前後主人公ならびに読者によるヒロインへの見方に全く変化がない。『マリみて』や『イリヤ』と比較して意外性が無く、筆者にとってはひどく印象の薄い遭遇である

最後見方は変わるものの一拍置いていない(つまり段階化されていない)例について触れておきたい。冒頭で触れた『俺ガイル』は最初の遭遇から間髪入れずにその「意外性のある性格」が開示されるものであり、多段階化されていない。なるほど『俺ガイル』におけるヒロイン毒舌はそれだけで魅力のあるものであり、それは単独で読者の興味を引くことができるものだとは言えるだろう(筆者も決して嫌いではない)。しかしそれは「レイアウトの仕方」ではなく「描写の仕方」による効果であり、ヒロイン毒舌がそれ単独で魅力を得られるほどのものではなかった場合、実に陳腐でつまらないものだと筆者は考える(逆に言えば描写力が優れていればなんとかなる、ということの証左でもあるだろうが)。

余談

念のため補足しておくと、陳腐な遭遇しか用意できない作品は全て駄作である、と述べたいわけではない。例えば『狼と香辛料』は荷台にもぐりこんだ裸の美少女が狼の化身だと明かすという意外性に乏しい遭遇であるが、ではこの作品が駄作かといえば筆者はそれほど悪くない作品だと思っている。ただし、その遭遇にインパクトを受け、興味を抱くことは無かったことも確かである。ここで張った伏線クライマックスで回収しているため最後まで読んでみればなるほどと思えるが、もし立ち読みで眺めたのであればその場で本を置いていたと思う。

関係構築のための行為類型の整理

ボーイミーツガール」の関係構築では、主人公ヒロイン恋愛感情が醸成されることは必須ではない(例えば『トリニティ・ブラッド』では恋愛感情は仄めかしすら無い)。一方で両者間の信頼関係の構築は必須と言っていいと筆者は考える。また信頼と似た効果を持つものとして敬意も有効機能する。

さて、関係構築とは主人公ヒロインの一方が他方に何かをすることによって培われるものと言っていいだろう。その内容は小説それぞれによって様々であるが、一段階抽象化してみると次のような行為類型化が可能であると思われる。下記で全ての行為類型化されているわけではないが、いくつかまとめた上で、それらをどう組み合わせることが効果的な演出になりうるのかを述べたい。

秘密の共有

遭遇の類型として「秘密漏洩」を上げたが、あれが当人の意に沿わざるものであるのに対し、「秘密の共有」は意図的に自らの秘密を相手に共有するものを指す。

秘密の共有」は信頼の表明がなされたという暗黙の読者の認識が得られる点で効果的であり、そして「秘密」は多くの場合プライバシー同義である。軽度な秘密から徐々に重大な秘密吐露へと段階を踏まえて内容は変化する。軽度な秘密の典型例は電話番号を教える、住所を教える、そこから一歩進んで自室に入れる、といったものが挙げられるが、最も多用される「秘密」は「過去」であり、昔の笑い話といった軽いものから過去トラウマまで「過去」は幅広く使える便利な「秘密」であり、重さを任意コントロールできるという点で優れている。

こうした秘密の共有は信頼の表明であると述べた通り、一定の信頼があった上でなされることで読者に違和感なく受け入れられるものと考える。十分な信頼がなされたと読者に理解がされていない状態でいきなり重い過去吐露を始めるヒロインなどは、自己陶酔中のメンヘラ設定を明らかにしたいのでもない限り慎むべきだろう。

観察による発見

涼宮ハルヒの憂鬱』における曜日髪型の関連の指摘や、『俺ガイル』における主人公ヒロイン友達がいないだろうという指摘など、観察によりヒロインのなにかに主人公が「気づく」ことを指している(ヒロイン主人公のなにかに気づくことも含む)。これはヒロイン主人公評価を改め敬意を抱くきっかけとして、また主人公ヒロインに対する評価を改め、敬意を抱くきっかけとしても効果的に機能する。

余談ながら観察力のある主人公であることを印象づけることは、特にバトルものにおいても有効機能するように思われる。例えば『禁書』や『バカとテストと召喚獣』、『エスケヱプ・スピヰド』はいずれも勝利をつかむきっかけとして敵に対する観察と気付きを用意しており、そこから作戦を練っている。最終的に単なる力比べになり、最強能力である主人公必然的に勝利するという陳腐さは、しかしそうした観察と気付き、そこから作戦演出が事前になされていることで読者に対する一定の納得感を与えるように思われる。もちろんそうしたものがなくとも最強主人公が敵を圧倒する物語に興奮できる読者がいることは事実だが、それにウンザリする読者も相当数いることも事実である。より幅広い読者を意識するのであれば、そうした演出一つを入れておく価値は十分にあると考える。

共通点の発覚

秘密漏洩、共有や観察による発見など、なんらかの情報が得られる行為類型の結果として、共通点、すなわち似た者同士であることが発覚することは相手に対する親近感を惹起する。これは読者にとっての共通点でも同様であり、感情移入共感を誘う要素と言っていいだろう。

親切

素朴な行為であるがゆえに、信頼と好意を「少しだけ」喚起する点で高い効果を持つ。例えば大きな好意が得られる「救助」は大仰なものであり、特に好意や信頼を寄せてもいない赤の他人に対してそうした行為をする人物は、十分な理由けが無い限り胡散臭いヤツという認識を与えるだけだろう。

これに対して「親切」はそれが当人にとって大した手間でない場合に実行されるものであり、人間関係破綻していない限りは合理的な行動として読者に受け入れられ、その結果ほんの少し信頼と好意が得られることが自然に読者に認識されることになる。『シャナ』において主人公ヒロインコーヒーを持って行ったこと、『とらドラ!』において主人公が朝食をヒロインにも分けてやったことなどはこの好例と言えるだろう。

呼称の変化

相手を名字で呼ぶのか、名前で呼ぶのか、といった呼称の変化は古典的ながら現在も極めて強力にその認識の変化を読者に理解させる。『僕は友達が少ない(以下はがない)』におけるあだ名であったり、また『デート・ア・ライブ』のようなヒロイン名前を付ける、という行為も同じ効果を持つと言えるだろう。

なお、呼称の変化は一度しか使えないものではない。ある呼称を用いたのち、それを使わなくなる、という演出はその呼称を用いるようになること以上にその変化を強調する。遭遇時においてではあるが、こうした「呼ばなくなる」ことを用いた好例としては『星界の紋章』があげられよう。

依頼に対する承諾

一方から他方へなんらかの依頼(命令を含む)がされ、受け入れられることを指す。このとき、その依頼は明示的なものであるとは限らない。「ボーイミーツガール」における両者間のほとんどはこれに該当するが、物語を先に進める意味合いが強く、関係構築に向けて目立った効果をもたらすものではない。

一方でこの行為類型が「期待に応える」を伴って実行された場合はまた異なった効果をもたらす。最初からヒロイン主人公に対して好意を表明していたり、信頼を寄せていることが暗黙に前提となっているような「ボーイミーツガール」は珍しいものではなく(『イリヤ』『ベン・トー サバの味噌煮290円(以下ベン・トー)』など)、また物語の途中でヒロインが全幅の信頼を主人公に対して寄せるようになるものも多い(『SAO』『ココロコネクト ヒトランダム(以下ココロコネクト)』など)。

こうした例においてヒロインから主人公へ強い信頼に基いて依頼がなされている場合、依頼の達成に失敗することが強力な効果を持つ。ヒロインから主人公へ依頼した仕事の達成に主人公が失敗し、しかヒロインがもう一度仕事を依頼することは主人公に対する深い信頼の表明として機能する上、主人公が次こそヒロインの信頼に応えようと努力する様は概ね読者の共感と応援を得られると考えられる。

例えば『ソードアート・オンライン(以下SAO)』ではヒロイン主人公仕事を依頼し、主人公成功し続け、それをもってヒロイン主人公に惚れこむという構造を取る。一方で『とらドラ!』においてはヒロイン主人公に対して依頼した仕事は失敗し続けるが、ヒロイン主人公失望することは一度としてなく、最後ヒロインから主人公に同じ仕事を改めて依頼するという構造を取る(定義を読んでいれば誤解は無いと思うが、本稿ではいずれも1巻の内容のみを対象としており、シリーズを通してどうかは検討範囲である)。両者を比較してみると、筆者は『とらドラ!』の方がよく出来ているという認識を持つ。

依頼に対する拒否

AURA 〜魔竜院光牙最後の闘い〜(以下AURA)』で繰り返されるような単なる拒否効果を持たないが、相手に対する尊重を以て拒否することは(一時的にはともかく)相手の不快を買うものではなく、むしろ信頼と敬意を勝ち得る効果を持つ。『マリみて』において主人公ヒロインからスールの依頼を拒否したことは典型例と言ってよく、『のうりん』におけるデビークの手助けを(これまで助力を惜しまなかった)主人公がしない、ということもこの一形態と言っていいだろう。

この時、主人公にとってはその依頼を受けた方がメリットがあることが望ましく、そうした自分利益を捨て、相手に嫌われる覚悟の上で拒否することはヒロインのみならず読者からの信頼も勝ち得る効果があると思われる。

好意の表明

単純な愛の告白のような直接的な好意の表明に限らず、嬉しそうに何かをする、微笑むといった行動によっても十分に好意の表明として読者に認識される。物語最後の場面においてヒロインないし主人公がこの行為類型を取ることが多く、ハッピーエンドとしての印象を読者に意識づけることで効果的と言えるだろう(『イリヤ』や『ALL YOU NEED IS KILL』がハッピーエンドか否かは意見の分かれるところであろうが)。

相手に伝わる形で行われるそれと、相手に伝わらない形で行われるものがあり、特に本人のいないところで信頼や好意を表明することは読者の理解共感が得られやすいように思われる。好意の表明は繰り返し使うとむしろ好意薄っぺらさを強調することになりかねないが、『ココロコネクト』のように相手に伝わらないところでそれがなされる段階を踏まえてから、相手に伝わる形でこれを行うことは効果を増すと思われる。

救助と自己犠牲

窮地に陥ったヒロイン主人公が助け出す、という行為類型は『禁書』『AURA』など非常に古典的ながら多くで用いられるものである。救助された側から救助した側に対する好意を含む感謝が読者に理解されやすい点で効果的だが、あまりにもわかりやすく、またありがちなものであるがゆえに陳腐な展開という印象を読者に与える危険性がある。

例えば『僕は友達が少ない(以下はがない)』におけるプールで絡まれヒロイン2を主人公が助け、それによってヒロイン2が主人公好意を抱く、という展開は筆者にとってひどく陳腐ものであった。

他方で『俺の彼女幼なじみ修羅場過ぎる』におけるチンピラ侮辱されたヒロイン2を主人公が助ける展開や、『さくら荘のペットな彼女』におけるラブホに連れ込まれかけるヒロイン主人公が助ける展開はそれほど嫌いではない。

その違いはなにかといえば、おそらく単純にその救助行為主人公にとってリスクの低いものか高いものか、という点と、救助の際に主人公が負傷している、すなわち自己犠牲を伴う点にあるように思われる。救助は主人公にとってリスクのあるもので、かつ、怪我を追ってまで勝ち得たものであるとき、救助された女性から主人公に対して寄せられた好意の大きさは「それだけの価値のあるもの」として裏付けられると考えられる。

その意味で、無傷でほとんどリスク無く救助したことで得られた好意ほとんど無いに等しいはずであり、にも関わらずヒロインが大きな好意を寄せる状態となり、そこにちぐはぐさと薄っぺらさを感じるように筆者には思われる。

禁書』では記憶喪失し、『AURA』では中二病世間露出し、『俺妹』では自分変態だと言って父親へ立ち向かい、『タイムリープ』では自分過去未来)が変わろうが知ったことかと手紙を書く。自己犠牲主人公がこれまで大事にしてきた何かを失ってでもヒロインを守ろうとする意思の明示としても機能し、ゆえにその対価として大きな好意と信頼が得られることに読者は納得がいくものであろう。

後編へ続く

2011-11-23

最近流行犯罪自慢

この1ヶ月、大妻、歯が無いお爺さん写メDS置き引き、マクド無料券を500枚盗み配布、その他もろもろ、Twitterがバカッターとか馬鹿発見器とかよばれるようになりましたが、自分が思うに、「人は秘密を話したがる」と思うのですよ。

犯罪だって「秘密」ですから、自慢したがるのも道理。

たまたま、手近なツールがTwitterだった、というだけで。

先日のAUiPhoneの話も、どこぞの店の店長(?)とおぼしき人間が、発表前に情報を流していましたが、結局、「秘密」。やはり秘密は話したいのですよ。それと、「他人が知り得ないこういう秘密を俺は握っているんだ」という優越感に浸りたいのだと思う。

まぁ、私にとってはお祭りが多くて、傍から見てる分には楽しいですけどね。これも「他人の不幸は蜜の味」と言う事なんでしょうかね。それは否定はしません。

お祭りで攻撃する側も(犯罪自慢に対するお祭り以外にも)、「他人を攻撃するのは幸福」という原理からでしょう。自分が正しい、常識とか、そんな事から攻撃してるのでは無いと思うのです。単に「攻撃する事が快感」なだけで、ブログや告知などでいくら反論・訂正等しても、意味は無い。攻撃する側からみて、そんな事はどうでもよくて、「快感から」ただそれだけだから

写メとか、某所でのニコ生とか見てると、家から一歩外に出たら、プライバシー存在しない感がありますね。誰かが自分を見て撮ってるかもしれないし、Twitterでつぶやいているかもしれない。

しかし、発見能力と特定能力がはんぱねぇ、と毎度驚愕しております(笑)

2011-03-07

http://anond.hatelabo.jp/20110307152946

機密かどうか疑わしいんじゃなくて、それが機密だと言われれば機密として動かさないといけないの

違うんだなこれが。最高裁判例を紐解いてみると、

http://www.courts.go.jp/search/jhsp0030?action_id=dspDetail&hanreiSrchKbn=01&hanreiNo=51065&hanreiKbn=01

なお、国家公務員法第一○○条一項の文言及び趣旨考慮すると、同条項にいう「秘密」であるためには、国家機関が単にある事項につき形式的に秘扱の指定をしただけでは足りず、右「秘密」とは、非公知の事項であって、実質的にもそれを秘密として保護するに値すると認められるものをいうと解すべきところ、

政府なり何なりが「これ、秘密扱いな」と何でもかんでも一方的に決定出来るわけではない。最初から非公知で、秘密にする価値のある情報でなければ「秘密」とはみなされない。例のビデオが上記の条件を全て満たすかどうかが最大のポイント

それに加えてあの件では、政府海保にいい加減な指示(公開するなとだけ)しかしておらず、職員はその気になればいつでも見られる状態だった(だからこそsengoku38外部に持ち出せたわけだが)。

仮に政府が本気で隠匿したかったら、あの映像の取り扱いの管轄を外務省内閣官房あたりに移すのが最も簡単で確実だった。しか政府は「海保勝手にやった事」という建前のためにそれを敢えてしなかった。

仮にあの件が法廷に持ち込まれたら政府側が負ける可能性が高いよ。だからsengoku38が「自主的に」海保を去って胸をなで下ろしてるんじゃないかな。もっと重大な問題は完全に棚上げされてるけど。

2010-11-12

http://anond.hatelabo.jp/20101112074843

馬渕はむしろ「するべき事をしなかった」のが問題。

例のビデオの件で馬渕は何をしたかつーと、10月18日海保映像を金庫に保管するよう指示しただけ。こんだけ。衝突事件発生(映像撮影)から実に6週間後。その間例のビデオを機密扱いとする根拠は何も無い。単に公判前だから刑事訴訟法上証拠物件を公開出来ないってだけの状態だった。

本気で機密にしたかったら速攻で内閣なり外務省なりに移せばいいだろという話。そうすれば例のビデオは確実に「機密指定」が出来ていた。

何故そうしなかったのか?

実は9月30日国会質疑で菅はビデオを見てるのかという質問に対して「見ていない」と回答している。

何故か?

ビデオ非公開は那覇地検勝手にやった事だから政府責任はねーよ」というポーズのため。

でもって、国家公務員法に記載されてある「秘密」は、元々が非公知のものであり、且つ秘匿するに値するものである必要があるって最高裁判例があるんで、メディアやら他の議員やらに「中国漁船側の違法性が明白に記録されている」と公然と内容が漏れていて、しかも流出直前には一部の議員映像の一部が公開されていた代物が果たして「非公知の秘密」なのかどうかもかなり微妙な判断になってくると思う。

2010-11-11

http://anond.hatelabo.jp/20101111042936

これってさ、情報管理体制がどうこう以前の問題として、そもそもあの映像を機密化する事自体が無理筋だったって事なんじゃないの?

仮に逮捕するとなると、根拠となる法律はおそらくこの辺になるかと思われるが、

国家公務員法

第百条  職員は、職務上知ることのできた秘密を漏らしてはならない。その職を退いた後といえども同様とする。

じゃあ、あのビデオ「秘密」なのかっつーと、こんな最高裁判例がある。

http://www.courts.go.jp/search/jhsp0030?action_id=dspDetail&hanreiSrchKbn=01&hanreiNo=51065&hanreiKbn=01

なお、国家公務員法第一○○条一項の文言及び趣旨考慮すると、同条項にいう「秘密」であるためには、国家機関が単にある事項につき形式的に秘扱の指定をしただけでは足りず、右「秘密」とは、非公知の事項であって、実質的にもそれを秘密として保護するに値すると認められるものをいうと解すべきところ、原判決の認定事実に寄れば、本件「営業庶業等所得標準率表」及び「所得業種目別効率表」は、いずれも本件当時いまだに一般に了知されてはおらず、これを公表すると、青色申告を中心とする申告納税制度健全な発展を阻害し、脱税を誘発するおそれがあるなど税務行政上弊害が生ずるので一般から秘匿されるべきものであるというのであつて、これらが同条項にいわゆる「秘密」にあたるとした原判決の判断は正当である。

政府が「この物件今から秘密な」と一方的に指定するだけでは「秘密」とはみなされないので、それを公開した公務員も「秘密を漏らし」た事にはならないという事になる。全国の管区で閲覧出来ていたって事は、「この管区でこんな事をしたよ」と情報ノウハウを共有するためのデータとして扱われてた可能性もある。この辺は国会で突っ込まれてた。

だからおそらく、今後この件は「そもそもあのビデオって『秘密』だったの?」という論点に軸が移っていくものと思われる。

2009-07-10

「伝わらない話」をする彼女

とある同期の女性Aが、同期の飲み会で集まると必ず、「一部の人にしか伝わらない話」をする。たわいもない内容で、単に「登場人物に知らない人がいる」「知らない土地が出てくる」、前の話題に係るちょっとしたエピソードだったりするのだが、わたしはそれが我慢ならない。

なぜ我慢ならないのかというと、彼女がそういう話を、解説ナシで終えようとするからである。わたしは彼女と距離を近しくしていたので、何の話かわかることのほうが多く、さらには同意を求められたりするのだが、こちらは同意もそこそこに、会話からなんとなく遠ざかってしまい、目の前の食事をぼんやりみつめはじめた他の同期たちに解説をしてしまう。めんどくせー。わたしもチヂミ食べたいよ。

これは何も飲み会に限ったことではなく、3人いればもう始まってしまう。「この前行った店の…」その店はわたしと彼女で行ったのだ。つづきが、「パスタがおいしかったんだよー。オススメ!由美ちゃんも今度行こうよ/由美ちゃんも最近どこか新しいお店みつけた?」など、第三者・由美ちゃんを取り込んで進めるなら全然問題ない。だが、Aはそうしない。「この前行った店のパスタもおいしかったよね(わたしを見て笑うのみ)。」こうなったら由美ちゃんのツッコミ(いつ行ったの?/どこのお店?/だれと行ったの?)待ちとしか思えないんだが、そうじゃなかった。いちど解説もせず、由美ちゃんも突っ込まずで話題が流れても、Aは発言しただけで満足なようすであった。なんなん。

思うにAにとっては他人と何かを共有していた、という過去の体験がすごく重要なんだろう。ちょっとした思い出を積み重ねて、発言して確認する。前述のような、なんでもないエピソードならいいが(わたしがいやなだけで)、「当事者にとっては秘密にしておきたいことまで、人前でしゃべってしまう」ということも起こっている。これはあちこちで反感をかっているようだ。プライベートなできごとは、本人の口から語られるのを待つべきだという感覚

そこまでいかなくても「察してあげる」感覚というのは、当たり前に誰もが持っていると思っていたので、面食らった。

Aは中学時代、学校に馴染めず、ほぼ登校拒否のような感じだったらしい。思春期女の子達は「秘密」に敏感だ。その時期に揉まれていないから今になっても利害関係がシュミュレートできないのかもなあ、などと想像してしまう。

とはいえわたしも、小学校中学校ではたびたび仲間はずれにされて、やるせない気持ちを味わった。それが未だに、クスクスウフフの視線でかわされるやりとりに憤る原因なのかもしれない。

2009-04-16

表現の自由

http://www.chunichi.co.jp/s/article/2009041501000342.html

 奈良県医師放火殺人の調書漏えい事件で、医師の長男(19)=中等少年院送致=を鑑定し、供述調書などを漏らしたとして秘密漏示罪に問われた精神科医崎浜盛三被告(51)に、奈良地裁は15日、懲役4月、執行猶予3年(求刑懲役6月)の判決を言い渡した。

 石川恭司裁判長判決理由で「被告の行為は長男の利益を図るものとはいえない。取材に協力する正当な理由はない」と指摘。「調書を見せたのは軽率で公私混同だが、出版には関与していない」と述べた。

 最高裁によると、統計がある1978年以降、秘密漏示罪の判決は初めて。極めてまれな罪を適用して取材源の責任のみを追及した捜査当局の判断を追認した形で、表現の自由や知る権利をめぐる論議が再燃しそうだ。

 弁護側は(1)鑑定には医師が前提とする治療目的がなく、鑑定人は秘密漏示罪が守秘義務を課す医師に該当しない(2)供述調書は法廷で公開されるのが前提で秘密に当たらない(3)長男が殺人者でないことを社会に理解してもらうという正当な理由があった―などと無罪を主張した。

 しかし、判決は「被告は法が規定する医師で、精神鑑定は業務に当たる」と指摘。調書も「秘密」に該当するとした。その上で、取材への協力であっても正当な理由がないので違法であることは免れないと結論づけた。

どこからどう見ても職務上知りえた情報漏洩させているようにしか見えんのだが、

極めてまれな罪を適用して取材源の責任のみを追及した捜査当局の判断を追認した形で、表現の自由や知る権利をめぐる論議が再燃しそうだ。

こういう物言いになる理由がわからん。

2008-05-13

http://anond.hatelabo.jp/20080513132239

元増田じゃないけど。

しょっぱなは「箱の中」「檻の外」をお薦めする。

痴漢冤罪で収監された男

「箱の中」asin:4883862925

「檻の外」asin:4883862984

HIV感染者の男

「リベットasin:4883863034

死体を隠した男

「秘密」asin:4883863190

女装趣味の男

「美しいこと(上)」asin:4883863360

「美しいこと(下)」asin:4883863433

肥満体型の男

「Don’t worry mama」asin:4862631134

2008-04-24

「秘密」というアニメを見ましたが、これはひどい

原作のよいところを全部とって、ひどいところを全部付け足した…。

これはひどい

キャラは全員性格破綻しとる・・・。なんだこのアニメ・・・。こういうのが原作レイプっていうの???

2008-02-27

http://anond.hatelabo.jp/20080227112913

とりあえず「42年組」とか書く人には別にドン引きでもいいよ。

↑と同じ30女だけど、普通24年組好きだし、入江亜季好きですよ。

つか入江亜季24年組時代の香りがするなぁって思うくらいなんだけど。

「秘密」はある程度知名度はあると思うけど、アニメ化=メジャーではまったくないし、

漫画に興味ない人にもまったくもってメジャーではないと思う。

世間が狭いね。

大島・萩尾好き」!?

悪いんだけど、ココにいる増田って40代とかなの?

大島・萩尾って30代である私の世代だと既に流行が終わってた人たちで

ぶっちゃけドン引きなのですが…。

萩尾望都も有名作はほとんど読んでるし、好きなんだけど、

やっぱり古くさい感じがして、そんなに人に「好き」とか言えるマンガではない。

それとも、みんな評論家っぽい感じで「ほほうー42年組は…」とか、マジメにマンガ読んでるの?

今でも結構マンガ読みのつもりですが、出てくるマンガが古いものばかりであることに驚きを隠せません。

清水玲子「秘密」だって、来期アニメ化するしメジャーマンガでしょ?

そう言う自分はおがきちかとか船戸明里藤たまき入江亜季あたりが好きなんだけど。

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