  |
はてなキーワード: サイファーとは
17章より18章のほうが盛り上がってるなと感じた、理由は分からない。
ビートの音のバランス悪かったような気がした。ビートチェックの時、聞こえるかな？と不安になることもあった。二階席だからかもしれなかった。
二階席は今回完全自由席だったけど、形式的には前回の先着順の指定席のほうが安心できるなと思った。二階を選ぶのはある程度環境的にリラックスしたいからで、時間的余裕もそこ(環境)に含まれているから、ギリギリにきて席が無い人はかわいそうだなって思った。数的には足りてても結局一席開けて座ったりしてるから座れない人とか居た。
毎回毎回八文字って本当に有能だなって思った。ラッパーへのリスペクト、進行のリズム(めちゃ大事)、観客のコントロール、ラップバトル(ゲーム)としての筋を曲げないなど、とか挙げるとキリがない。
トーナメント人数しぼったのは正解だった。時間的余裕と試合のクオリティ確保の面からみて。次もこれでいい。
梅田サイファーのショーケースは全然良くなかった。ドイケンだけめちゃ上手かった。ただ韻踏の曲一番長くやってどうすんねんと思った。ならERONEだせよ。
一番良かったのはSAM対IDだった(一回戦)
初戦(NAIKA対MAVEL)から会場があがっていたのは間違いないけど、このバトルが会場の盛り上がりを決定づけたと思う。
正直ビートはローテーション形式だった時点で当たりはずれがあるなと思っていたけど、
ワズゴックビーツが一番シンプル(三人の中で)でバトルビートぽかったのもかなり良かったと思う。
1バース目のID良すぎてびっくりした。wrepも聞いていたからIDの肩を持つ形でバトルを聞いていたけど、最後はSAMに声をあげてた。どっちも最高だった。
智大キマりすぎて目がうつろだったの笑った。
GOTIT強く感じた、パパラッパー的なポジションで勝つにはバイブス以外にもなんか寂しさとか悲哀があればなあって思った。一回は勝てるけど連勝するのは苦しいかも。でも強い、格好いい。
だーひーが頑張ってた主人公ポジをゲットしてた、もう少しタレント性(キャラクターかビジュアル)があれば勝ち上がってたかもしれない。芋臭さが抜けない。
SIMONJAPが昔のSIMONJAPだった、ちょうどいい俺様感とフロウ、ただ最後しゃしゃりすぎて負けてた。
GILに貫録がついてきた。喋れば喋るほど対戦相手との格の差を見せつけるようだった。昔の比較的韻を重視したスタイルから韻というよりも内容重視なところもスタイルチェンジだと思った。17章一回戦のときのGILはかなり喋りにフロウも混ぜあってた印象があった分、18章はかなりその差が気になった。語尾EEAで踏んでばかり。
HIBIKIめっちゃラップ良かった、一番音源が聞きたいと思った。
SAMは過去大会の中でめちゃめちゃ良かった分、後半の失速が残念だった。ラップしながら言葉を探してる様子も見受けられたのも観客から見て苦しさが目立った。それでもめちゃ強かった。今回獲るかと思った(①)
漢は強かった。いつも通り頭韻踏みまくって対話で圧倒してた。相手に恵まれたのもあると思うけど、勝ち上がっていく姿は痛快だった。
上野さんはもっとエンタメで戦うことのカッコよさを語ってたらmol53にも余裕で勝ってたかもって思った。バトルじゃなくても戦ってるのさ的な、残念。
JAKE本当にプロップスについてきたなって思った。会場があの余裕な表情から出る相手へのマウントと話の落とし方にすごく期待してたように感じた。ついでに対輪入道のとき言った妖怪倒すのは鳥取県って決まってるみたいな最後の話の落とし方もよかった。
とにかくmu-tonのプロップスヤバすぎた。今回獲るかと思った(②)
前から思ってたけど9forがやっぱり《高校生ラップ》の完成形だと思う。ビジュアルかキャラクターさえ決まればR指定に余裕で匹敵しても全然おかしくない。こういう言い方は良くないけど、良いブレインが付いたら化けると思った。
GOLBYは草むしりのおじさんみたいな格好してた、頑張ってた。好き。
mol53は負けた後のフリースタイルがとてもカッコよかった、文字書こうって思った。
じょうはキャップかぶってたほうがいいと思った。ビジュアルからでも今までの立ち位置と変わってるってことを観客にわからすことも大事かなと思った。浪人生みたいな格好で対戦相手を茶化すスタイルから、少しタイトめにビジュアルから締めていくと、みてる側の印象も変わるなあって思った。2016のkokからうっすらそう感じてたけど、今回は単純にキャップ似合ってた。
呂布カルマは対GILで、最後のバースで「GILと真っ向対立して観客にどちらが勝者か問う」という試合運びは呂布カルマのほうが後攻だからこそ出せた内容だったと思うし、言い切った格好よさがあった。
他はわりといつも通り。
18章は最高だった。
「○○持ってないやつおる？」
「○○は人権」
クソである。
こいつらが課金を促して日本のガチャはアクティブユーザーを取ることに躍起になった。
アクティブユーザーが多い所におおよそ「人権」になりえそうなキャラを投入するだけでガチャが回るものだからチョロいものである。
もちろん、常に「人権」になりえそうなキャラを出してしまうと某猫みたいに「インフレゲー」に突入するので、実際に弱いキャラも混ぜ込む。人権になりえそうな事を書いて。
あとはユーザーが勝手に「○○は人権」と論調を合わせて宣伝してくれるのだから。
ごもっともだ。でも、残念ながらそんな強い心を持った人間は結局強い心を持ってしてゲームをやめられるので必然的にゲームに残るのは心が弱い、今までの課金を無駄にできない、そういう人間なのだ。今までの課金を無駄にしないために。思考が完全にパチンコをやめられない人間だということをガチャゲームのユーザーは理解しなければならない。
君たちが運営をクソの象徴として掲げる。なんとか本社爆破、指定暴力団○○。君たちがずっと期待をしてそれらに接しているのは理解できる。だけど、いまの何をやってもガチャがまわる現状をやめない限り、なんとかゲームスはグランサイファーを作るし、なんとかワークスは不具合も直さずイキるし、コンシューマーゲームなのにガチャみたいなのが実装され続ける。
自分たちガチャゲーマーこそ、日本のゲームの癌だということを認識しないといけない。
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か？主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
境内は神域であり原則畜獣立入禁止なんだが、ごく普通に「散歩中ですよ」みたいなさわやかな顔して犬連れて入ってくる奴が非常に多い。
とはいえ地元の人間は殆どいなくて、他地域から来る人間や旅行者が大多数を占める。
常連にも犬連れが居るのかというとこれが一人もおらず、犬連れて入ってくる奴らはと言えば見た事もない連中ばかりだ。
しかしそれでも境内に犬の姿が絶えないんだから年間どれだけ一見さんが来てるのかっていう話でもある。
まあ私も犬は割と好きな方なんで、犬来ても仏頂面で「かわいい」と思って眺めるだけなんだが、流石に立場上あまりよろしくない。
境内での犬どもはいきなり知らない場所に連れて来られたせいか大抵おとなしいので問題が起きる事もないが、放置するのもまずい。
たまにリードすらつけずに飼い犬を野放しにしているとんでもない奴も来るが、犬も飼い主も問題起こさないので注意しづらい。
まあ犬嫌いの奴にとっちゃその犬がかわいいか無害かなんて関係ないわけだから、リードつけてないだけで十分な迷惑行為とも言えるんだが。
ただ、犬連れて旅行とかするくらいだし飼い主も感覚が麻痺してるのか、普通に犬連れて受付に来たりする。
受付者「…すみません、ワンちゃんはお外で待っていて頂けますでしょうか？」
夫「（気付く）ん？何で外行く？」
妻「犬は外で待てって」
こちらは常識を説いただけなんだからわざと悪意にまみれた翻訳をして夫を焚き付けるんじゃねえよクソ飼い主。
こういうのがあるので、犬連れの受付はスルーするようにしている。
他にも、
断られるのがハッキリわかってる質問を敢えてして一度断られたのにそこでまだ食い下がるんじゃねえよ常識考えろクソ飼い主。
というのがあったり、
飼い主「〇〇、〇〇、〇〇、タマ…」
受付者「…。（まあお婆ちゃんの名前かもしれないし…）」
飼い主「ジョン…」
受付者「……。（もしかしたら外人の家族がいるのかもしれないし…）」
飼い主「ミケ…」
ですが～じゃねえよ家族の名前言えって言われてんだから自己判断でペットの名前付け加えてねえで言われた通り家族の名前だけ言ってりゃいいんだよクソ飼い主。
というのがあったりするので、
どちらかというと大人しいペット達よりも無理難題を言い立てる飼い主の方が普通に畜生に見える。
人間の飼い主達よりもペット達の方が神社ではずっといい子にしている。
で、こういう事が続いたりしたので職場でも犬連れの参拝者に口頭注意するようになったんだが、これがまるで効き目が出ず、犬の数が一向に減らない。
そんなやり方では、口頭で注意した飼い主が、その後家に帰ってから口コミで「あの神社で犬連れてたら注意された」と広げ、やがて犬連れてくる人が減るのを期待するくらいしかない。
こりゃ長期戦を覚悟しなきゃならないか…と思っていたところ、ある日突然、境内をうろつく犬の数が激減した。
“景観保持の為こんな無粋なモノを張りたくない”としぶる向きも多かったが、ダメモトで、入り口に張り紙を一枚張る事に。
「境内に犬を連れて入らないで下さい」
あっさりと、犬の数が激減した。
要は、「犬連れて入っちゃダメ！って書かれてないから入ってオッケーなんじゃね？」って思われてたって事なんだろうな。
そういう事じゃねえんだがなあ。
【重要】BookLive!Reader for Windows PCの不具合について
平素よりBookLive!をご利用いただき、誠にありがとうございます。
本メールはサービスに関わる重要なお知らせのため、メール配信を受け取らない設定にしているお客様へもお送りしております。
弊社が提供している電子書籍閲読アプリ「BookLive!Reader for Windows PC」とMicrosoft Visual StudioやCyberLink PowerDVDなどのソフトウェアを併用した際に、使用状況によってはお使いのパソコンがフリーズする（再起動が必要になる）可能性がある不具合が報告されております。
「BookLive!Reader for Windows PC」ご利用の皆さまにはご不便・ご心配をお掛けし、誠に申し訳ございません。
以下に、本件の状況と対策についてご報告をさせていただきます。
【問題が発生する可能性のある環境】
BookLive!Reader for Windows PCがインストールされているパソコンで、以下の操作を行った場合に問題が発生する可能性があります。
a）Microsoft Visual Studioでのデバッグ実行中に比較的ファイルアクセスの多い処理を実行する
b）CyberLink PowerDVDでBlu-rayディスクを再生する
※iOS・Androidのアプリケーション、Lideo、ブラウザビューアでは本問題は発生いたしません
【発生する可能性のある事象】
上記環境・条件でBookLive!Reader for Windows PCをご利用されている場合、下記の事象が発生する可能性があります。
１）Windows OSが動作を停止し、強制的に再起動を行う以外に復旧することができなくなる
２）上記の副次的な事象として、Windows OSが動作を停止する直前に書き込みを行っていたファイルが破損する
【原因】
上記の問題は、BookLive!Reader for Windows PC内で書籍の複製防止の為に利用しているサイファー・テック株式会社提供のソフトウェアに起因しております。
具体的には、暗号化された電子書籍を閲覧時に復元するプログラムにおいて、特定ソフトウェアの処理との競合により本問題が発生いたします。
より詳しい情報につきましては、サイファー・テック株式会社のホームページをご覧くださいますようお願い申し上げます。
http://www.cyphertec.co.jp/news/cymon_issue.html
【対策】
BookLive!Reader for Windows PC Ver2.4.0以前のアプリケーションでは、インストール直後から問題が発生する可能性がありましたが、最新版の2.4.1では「BookLive!Reader for Windows PCをインストールしているだけで問題が発生する」という状況は回避でき、問題の発生する可能性のある期間が、BookLive!Reader for Windows PCで書籍を開いてからパソコンの電源を切るまでの間に限定されます。
（BookLive!Reader for Windows PCで再度書籍を閲覧された場合は、問題が再び発生しうる状態になります。この場合でもパソコンを再起動いただくことで、問題が発生しない状態に戻すことが可能です）
つきましては大変お手数ですが、対応版アプリケーションがリリースされるまでは、以下の最新版アプリケーション（BookLive!Reader for Windows PC Ver2.4.1）をダウンロード・インストールしてご利用いただきますようお願いを申し上げます。
BookLive!Reader for Windows PC Ver2.4.1ダウンロード
http://booklive.jp/download/win
弊社としましては、引き続きサイファー・テック株式会社と連携して恒久的な対策を講じてまいります。
また、対応の内容については、更新があり次第、弊社ホームページにて随時ご報告をさせていただきます。
本件に関してご不明点などございましたら下記よりお問い合わせください。
お問い合わせフォーム
http://booklive.jp/index/contact
ソフトウェアのアップデートで解決するならともかく、修正されていないのだったら、最善の解決法はアンインストールじゃないのか？
被害を出しておきながら、そのプログラムを使い続けさせる神経が理解できない。
重大な欠陥を含んだプログラムをなんの説明も無く今でも平気で配布している。
http://booklive.jp/download/win
しかし同人誌という存在すら知らない高校時代にコミケに関連した強烈な出来事に出くわしたことがある。
それは高校３年生の１２月３１日、大晦日だった。
その日は代ゼミ慶大模試なる模試があったから友達と代ゼミ横浜校まで行ってきた。
模試の内容は散々なもので、慶応が第一志望校だっただけにすごいショックを受けながら京急に揺られて帰っていた。
ﾀﾞｧｼｴﾘｲｧｽ
京急に乗ったら車内の端に特大サイズの紙袋を５、６個も持っている男の人がいた。
この人は髪の色が銀色でオールバック、黒いマントを着ていて、雰囲気はFF8のサイファーに似ていた。
サイファーはドアにもたれながら、目を細めて窓の外を見ていた。
大晦日でみんなスーパーの袋にカニだのを買っている中、すごい浮いていた。
友達と俺も窓の外を細目で見て「線路は、続くよ、どこまでも・・・」と言い合っていた。
上大岡駅に近付くアナウンスが流れるとサイファーは全部の紙袋を両手に掛け、持ちあげようとした。
その時一番大きな紙袋（半畳くらいのサイズ）の取っ手から中ほどまでビリビリッと音を立てて切れてしまった！
そこから溢れでてくる同人誌の山。出てくる表紙は全てロリ系。車内の真ん中まで滑っていった表紙は幼児が裸でマ◯グリ返しをしている絵。
サイファーは冷静にマントを抑えつつ溢れ出る同人誌をかき集めた。しかししゃがんだところで別の紙袋からも同人誌がこぼれだす。
ﾀﾞｧｼｴﾘｲｱｽ
次の停車駅の金沢文庫までの10分間はいたたまれなくて見れなかった。
ﾀﾞｧｼｴﾘｲｱｽ
金沢文庫で慌てながらも上りのホームにかけていくサイファーを横目に模試の結果とかどうでもよくなって、ただ大晦日にあの人災難だなと思いました。
家に帰ってネットを開けばコミケまとめの記事。ああ、あの人はコミケに行ってたんだ、と。
これが俺のコミケの思い出です。
痛紙袋とかが出回っている今、同人誌が公共の場で公開されるのに抵抗の無い方もいるかも知れませんが周りの人がとても気を使ってしまいます。
同人誌の持ち帰りにはどうぞ注意してください。
ttp://sofusha.moe-nifty.com/series_02/2010/03/post-eac7.html
たとえば『マトリックス』では、裏切り者、つまり悪役側のサイファーという人物がこんな言葉を口にします。
「俺はな、このステーキが存在しないことは知ってるんだよ。口に入れると、マトリックスが俺の脳味噌に、これが肉汁たっぷりで最高にうまいと教えてくれるんだってこともな。9年かかって俺がなにを理解したか、アンタわかるか？ 無知の至福さ。」
現実よりも仮想現実を選択するという判断が「悪役」のものであるということ。この描写が象徴するように、「現実＞仮想」あるいは「三次元＞二次元」という価値観は、もはやハリウッド映画の強迫観念ですね。虚構産業の自浄作用のようなものでしょうか。まあそれはともかく。
『アバター』で、主人公ジェイクは、あらゆるハリウッド映画的伝統に逆らって、なんと仮想現実に生きることを選択します。この部分、あまりにもあっさりと描かれているので気づかれにくいようですが、これは二重の意味で画期的なことです。
前衛映画ではありません。超娯楽大作の主人公が、地球（＝現実世界）に還らず、仮想空間（パンドラ）のヒロインと生きることを選ぶということ。なんともオタク的な「ネイティリは俺の嫁」宣言です。すいませんわかりにくかったですね。これは一般には、漫画やアニメのキャラクターにリアルな恋愛感情を喚起されてしまった漢（おとこ）たちが口にすべきテンプレートとされています。
さらにいえば、キャメロンはこの映画で「もう現実とか仮想とか区別しなくてもよくね？」と提案しているようにもとれます。アメリカでは本作を観た観客のなかに、「パンドラから帰りたくない」という思いが高じて、うつ状態におちいった人々がすくなくなかったと報じられています。もしこれが事実なら、キャメロンの目論見は見事に当たったといえるでしょう。なにしろハリウッド映画に連綿と受けつがれてきたプラトニズム（イデア＞現実＞虚構）の伝統を、根底からくつがえしちゃったんですから。
