ブラウザのパスワードマネージャのクリックジャッキング脆弱性

ブラウザのパスワード自動入力機能（パスワードマネージャ）とクリックジャッキングを併用して、ユーザに意図せずSNSなどにログインさせる方法がある。
自分はこれはセキュリティ上問題のある動作、ブラウザ側の脆弱性だと思っている。

前提として、セキュアなHTTPSでないサイトについてパスワードマネージャーに対する攻撃は知られていて、HTTPSで設定したパスワードをHTTPでは自動入力しない、という方法がとられている。
もしHTTPでも自動入力を許してしまうと、ブラウザ側の同一生成元ポリシー（SameOriginPolicy/SOP）による対策はDNSインジェクションや偽装WiFiAPなどを利用して簡単に破られるので、簡単なJavascriptで網羅的にパスワードを詐取できる。従って、現存する全てのパスワードマネージャはSOPとHTTPSで守られていると考えていい。

しかし、ログインフォームにクリックジャッキング対策が為されていない場合、SOPが守られていても、ユーザに意図せずパスワードを送信させることが出来る。
パスワードマネージャの自動入力のクリックジャッキング脆弱性自体は、既に2年以上前にBugzillaにポストされていた（mala氏から教えて頂いた）が、セキュリティバグではないと判断されてしまっている。Chromiumにもポストしたが、セキュリティバグでないとリジェクトされてしまった。
しかし自分はこの問題には、ブラウザ側で対策すべき理由があると考えている。攻撃に利用されるクリックジャッキング未対策のウェブサイト側には、積極的に塞ぐ理由が（ごく一部のユーザーからの信頼以外）無く、ユーザが巧妙に仕掛けられた罠iframeを見破ることは事実上不可能だからだ。

この手法それ自体では、攻撃者が直接的な利益を得られる確率は低い。僅かな利益を得られるシナリオとしては、
・SNSのログインページにログイン後リダイレクト機能があり、同一SNS上に用意した自分のページのログインユーザ閲覧数を稼ぎたい場合。
・攻撃対象ユーザのリアルタイム情報自体に価値がある、標的型攻撃の場合
があるが、露見時のリスクから考えてもっと他に良い方法が有るだろう。

一方、SNS側には露見した場合も信用の低下以外に被害がない。
ユーザーの個人情報を集積し、広告を流すことで利益を得ているSNS側は、なるべく多くのユーザにログイン状態にいて欲しい。また、クリックジャッキング対策に有効なX-Frame-OptionsヘッダはまだXが付く標準化以前のものであり、必須ヘッダではない。そして、この対策をすることによって、ごく一部のユーザーの信頼の維持以外に直接的な利益が無い。
Evilなウェブサイトがユーザーのログインという同意を、第三者の攻撃に見せかけて捏造することさえ不可能でない。

他方、被害を受けるユーザーにとっては問題が生じうる。
クリックジャッキングによってログインした場合に、SNSには位置情報など、通常ユーザーの意思で保護されるべきリアルタイムの情報が意図せず伝わってしまう。
SNSが足跡機能やユーザー現在位置などリアルタイム情報を公開する機能を持っていれば、SNSを通じて第三者が"意図的にログアウトしたい状況下にある"ユーザーの情報を取得できる可能性がある。
そもそも、ログアウトしたはずのサイトにログインしているという事自体、ユーザの意図に反する動作で、安全でない環境にアクセスする際はCookieを削除してこまめにログアウトする、という初等的なセキュリティ対策を無効化してしまう。

また、冤罪事件から分かるように、CSRFやクリックジャッキングによるユーザーの意図しない行動について、刑事捜査の過程で（少なくとも冤罪被害者に利する方向には）考慮されない事が分かった。
ログインフォームにCSRF対策がなされていても、クリックジャッキング脆弱性があればログインを誘導でき、現状XSSは論外としても、ログインユーザに対するクリックジャッキングやCSRF脆弱性がウェブサイトの何処にも無いと言い切るのは無謀と考えられる。愉快犯がクリックジャッキングを二度成功させ、SNSや掲示板などにログインさせて犯行予告をポストできた場合、冤罪被害者が第三者による悪意あるCSRFやクリックジャッキングであると証明することはとても難しいのではないだろうか？

現在、ユーザーが意図せず情報を送信あるいは公開しうるSNSを2つ確認している。一つはログイン直後に位置情報がSNS側に送信され、もう一つはログイン状態表示と足跡機能によってリアルタイム情報を第三者に公開しうる。
二段階のクリックジャッキングによってログインユーザを騙って犯行予告といった比較的簡単な条件ならもっと有りそうだ。

少なくとも、X-Frame-OptionsヘッダがRFC標準でMUSTになるか、ブラウザのデフォルト動作がDenyになるまでは、クリックジャッキング対策は可能な限りブラウザ側で行うべきだ。
例えば、XFOヘッダに頼らなくても、以下のような解決法がある。

パスワードマネージャは、iframe.srcとwindow.location（つまりアドレスバーのドメイン）が異なるオリジンの場合に自動で入力はしない。パスワードを入力する前に、BASIC認証自動化URLの警告と同様に、「異なるサイトexample.comにパスワードが送信される場合があります」などと警告した上、ユーザーの明示的確認を得てから半自動で入力する。

将来的には、iframeを完全に禁止する、より安全な対策が実現するかもしれない。しかし今のところクリックジャッキングは何処にでも存在しえて、ウェブサービス側はともかく、一部のユーザーには脅威になる。ウェブサイトの善意に頼るよりも、ブラウザ側に対策が求められると考えている。

現時点で、この攻撃に対する手軽な対処法は、拡張機能などでiframeでの外部リンクを禁止すること。例えば、Adblockで次のフィルタを追加する。

##iframe[src*="//"]

サイト自身の機能を利用するためにiframeが必須なサイトがどれだけ有るか考えると、これが一番と思われる。

NEC Aterm WR8370Nの挙動

USBメモリ簡易NAS機能やGbEハブ、あとWakeOnLAN対応とスペック的には満足して買ったAtermのWR8370Nの不満点を幾つか書いてみる

ループバック接続ができない
LAN内のPCからWAN側公開ポートに接続できない。外部IP、からならアクセス出来る。
Local IP spoofingと判定されブロックされているらしいのだが、それらしいセキュリティ機能をオフにしても何故か接続できない。
NAPTの仕様らしい。

ポート23と5432が開いている
LAN側で何故かtelnetの23, pgsqlの5432が開いている。telnetは保守用らしく、ファーム解析等で調べた人が居るようだ。
流石に現在はパスワードは変わっているらしく、MACからHMACなりで出すんだろうと思う。
でも、何故にDBが動いているのやら。syslogあたりならまだわかるけど。
#まさかペアレンタルコントロールフィルタ用とかじゃないだろうな……

WAN側ポート80が開きっぱなし
リモートでのWakeOnLan機能をオフにしても開きっぱなし。フィルタで80を破棄に設定しても無駄だった。

家庭用だから仕方ないとはいえ、色々怖いのでもうちょっと何とかならないものか

DoS攻撃元としてIPアドレス特定された件

アンドロイドアプリ危険性評価サイトsecroid.jpを運営されている@lumin氏にDoS攻撃元としてIPアドレスを特定されてしまった。

自宅マシンおよびほぼ常駐のサーバをひと通りチェックしたものの、侵入などの形跡は無かった。DDoSでないようなので、何故DoS攻撃元と判定されたかを考えてみた。

Chromeのタブ開きすぎて再起動
本命。自分はベータ版Google Chromeでいろいろいじってたりするため、タブを大量に開いたまま落ちたり落としたりで再起動することがある。最近のFirefoxと違い、Chromeは起動した瞬間に全てのタブを読み込もうとするため、実質的にDoS攻撃になる。いわゆる田代砲と同じ。
secroid公開直後ぐらいに早速DoS攻撃受けてる、というツイートをほぼリアルタイムで見た覚えがあるので。これが自分だった可能性は高い。
これが下手な相手だった場合、もしかすると某図書館事件的に刑事告発・逮捕勾留されていたかもしれない。……Chromeを閉じる前にタブは全部閉じよう。

ルータの80が開いている
NEC・Atermの一部の家庭用ルータはデフォルトでWAN側httpdが開いているようだ（設定で禁止することが出来ないっぽい）。オープンプロクシやトロイと思われたのかもしれない。
WAN側port80のフィルタ設定してもHTTP動いてるんけれど、これバグじゃないの？ Aterm……。

もろもろのポートでTCPが空いている
自宅サーバ有るためこれは仕方ない。自宅サーバは自分専用なのでkernel他サービス中断必須のアップデートも自由にできるし、保守されてない放置サーバよりかは安全。と思う。
流石にノーガード的な設定はしていないはず。

sakuraのVPSあたりに公開サーバを移すか検討中。ただメモリは自宅サーバじゃないと高い……。
月の電気代1000円程度で8GB物理メモリ自由に使える、ってのはVPSじゃ絶対無理。

Xperia acroを文鎮化未遂・初期化した

Root化したXperia Acroに、コマンドラインツールキットを適当に入れてしまうという愚を犯し、文鎮化させかけたのでメモ

発端
起動アニメーションが始まらず、途中でウォッチドッグタイマか何かで再起動がかかる。
思い当たることはBusyBox系アプリでLinux標準ツール類をインストールしたこと。シェルでいちいちbusybox mount などとうつのが面倒だったため。
どうやら間違えてbusyboxごと、あるいは必須コマンドを置き換えてしまったらしい。

復旧の試み
adbは再起動までの数十秒ほどはつながるので、スクリプトで/system全てをバックアップから書き戻そうとしてみた。
しかし、busyboxがrootをとれていないらしく、/systemをリマウント出来ない。間にシェルを挟んだり絶対パスで打ってもダメ。
zergrushはroot取得explotコードまで動いているように見えるが、やはりリマウントで失敗する。suはsegfault。
というわけで自分のlinux知識では詰みが確定した。

SEUSで初期化
幸運？にもXperiaはブートローダアンロックの必要が無いので素のAndroid2.3.4のまま。SEUSで初期化した。これは普通に成功。

Googleアカウントの再設定
一番心配だったのはGoogleアカウントの二段階認証。Android端末として登録してあったが、結論から言えば再設定が可能だった。
信頼済みPCからなら、新しい個別パスワードは二段階認証の必要なく発行できるので、アカウント名と個別パスワードでAndroidのアカウントを初期化。
同じPCから二段階認証ページにアクセスし、Android端末を削除して、Google認証アプリをインストールして追加し直すだけ。
ただ、もし信頼済みPCが一つも無かったりした場合、電話確認が必要になるだろうから、復活用ワンタイムパスワードを物理的に印刷しておくことにする。（反省）

Playストアの際登録
端末を初期化してPlayストアにアップデート、最初にログインしたあと、30分くらいはPCのPlayストアページに所有端末が表示されない状態だった。
その間、ちまちまとアプリ検索してインストールするのが面倒だったが、その後は問題なくPCからリモートインストールできた。

Root再取得とLink2SD領域の初期化
Link2SDの挙動が心配だったため、root化する前に、PCからSDメモリカードのExt領域を再フォーマットしておく。
それ以外は特に問題なくzergrushとTh_for_locked（ブート時間を延ばす不要なスクリプトなどは自分用に書き換え）でroot化とカスタマイズ。

最初にプリインストールアプリの大半を削除し、あまり使わなくなったアプリを整理していなかったせいもあって、レスポンスが良くなったように感じる。
これでacroはあと？ヶ月戦える。

secroid.jpのアプリ判定方法を外から見たメモ

Androidアプリの危険度を調査しているサイト http://secroid.jp/ の判定パターンはおおまかに、
・Androidアプリの権限
・apk分解してライブラリをシグネチャでチェック（特に広告パッケージ）
・未知の中間コードは静的解析してAPI利用をチェック
しているようだ。

マイナーな広告と改変された広告ライブラリを見逃していたことから、ライブラリの判定は基本的にブラックリスト式。
root取得については、AdAwayのように動的にコマンドを生成して実行している場合に見逃していることから、静的解析でネイティブコマンド実行のAPIを利用しsuへのパスが渡されているかどうかで判断しているように見える。
もしかしたら変数追跡して、suを渡しているか見ているのかもしれないが、いずれにせよroot利用を見逃しているアプリがある。

Secroid検索というアプリを使って自分がインストールしているアプリを調べて見たところ、
https://play.google.com/store/apps/details?id=com.github.ymstmsys.secroidsearch
Adaway
ES ファイルエクスプローラー
Auto Memory Manager
Mount Manager
Link2SD
Samba FileShareing
が危険度High以下、root利用未検出になっている。
いずれも著名なroot必須アプリで、アプリ説明にはrequire rooted deviceなどと明記されている。
今後の精度向上に期待。

アプリ権限依存の危険度判定については、大雑把に
root取得やマルウェア＝無条件でDanger
電話帳や通話状態の取得・SDへのアクセス＝無条件でHigh
IMEI・GPS＋ネット＝Low
権限なし＝Safe
そのほか、ネイティブコマンドAPIやバックグラウンド動作などの利用でmidになるようだ。ユーザーが認識できる範囲の利用とみなせるユーザ追跡までならLow以下にと判定される模様。

Low以下なら大抵の人にとって実害は無さそう（追跡が気持ち悪いという点を除けば）。
ただし原理的に、擬陽性を避ける方向（なるべく危険度を低く判定する）に評価が偏るので、鵜呑みにせず自分でチェックするのが前提。
当然だけれども、secroid.jpも目安の一つでしかない。

Androidのroot化必須アプリへのリンク・パストラバーサル攻撃

TwitterのTLに懐かし（？）のパストラバーサル攻撃の話が流れていたのでAndroidについて考えてみた。

（たどっても見つからなかったので昨日以前ぽい……）

WindowsNT系を含むPOSIX互換OSとそのファイルシステムでは、相対パスやシンボリックを悪用することで、特権（root）を持つプロセスに意図しないファイル操作を行わせる、という攻撃が昔から存在する。
たとえば、root権を持ったプロセスがシステムのファイルをバックアップ、あるいは展開する、といったサーバー保守作業の過程で、一般ユーザー（例えば共用Webサーバのをレンタルしているユーザ）がシンボリックリンクをタイミングよく作成すれば、他のユーザーやシステムファイルを抜き取ったり、上書きできる可能性がある。
こういった攻撃は古くから知られていて、TarのようなUnixの基盤的なソフトウェアでは基本的にrealpathを利用したりシンボリックリンクを識別して動作を変えるよう対策が行われている。

Androidにはsuからroot権を取得してファイル操作できるアプリには各種あるが、もしrootアクセス時に正しくシンボリックリンクやパスを扱っていないと、この攻撃に脆弱になる。

たとえば、各々のアプリが個別に持っているストレージ（/data/data/アプリ名/など）はPOSIX互換ファイルシステムに置かれるため、サンドボックスの外、たとえばシステムファイルや電話帳ファイルへのリンクを作っておき、アプリバックアップ用のアプリがroot権を取得しバックアップ操作してSDカードに保存されたタイミングで、誰でもアクセス可能なSDカードから情報を搾取することが考えられる。
逆に、/systemなどへのシンボリックリンクを作っておき、バックアップアプリが不用意に復元操作すれば、システムが破壊される恐れがある。

Androidの各アプリサンドボックスはLinuxのユーザーIDを利用しているので、通常の利用ではシンボリックリンクをどう作ろうとリンク先のアクセス権がないので問題は無いようだ。
しかし、自分のデータ領域にアクセスしにくるroot取得アプリが動いている事がわかれば、意図的にroot必須アプリを悪用することが出来るかもしれない。
DRM目的でroot取得可能かどうかやインストール済みアプリをチェックしているアプリは既に存在するので、それらの一つが悪意を持った場合、suにアクセスすること無く特権が必要なデータにアクセスしうる事になる。

自分はJavaがほとんど書けず実機検証できていないが、AndroidAPIや関連情報を見る限り実行は可能に見える。
root化できるユーザはSuperUserのダイアログをチェックできるが、この攻撃にsuへのアクセスとroot権は必要なく、ユーザーが脆弱性に気づくことは難しい。アプリ開発者が気をつけるしか無い。

Link2SDのようにLinuxのファイルシステム特性を理解してアプリ開発している人と利用者は当然考慮しているだろうが、root必須アプリにはよくよく注意したほうがよさそうだ。

（TiraniumBuckupはtar保存だったので、Tarが古かったりオプションを間違えてなければ致命的なことにはならないはず。まぁそもそもデフォルトではSDカードに固定ファイル名でバックアップするのでデータ抜き放題だけど。）

停電に備えたLEDライト購入指南的メモ

を騙る電子工作ヲタの趣味のマトメ
（これは国内製品よりも個人輸入による中国直販LEDライトも含めた話です。）

・単一のLEDを使用し、LEDのスペックで輝度をCd（カンデラ：照度・明るさ）ではなくLm(ルーメン：光量・総量)で記載されているものを選ぶ。
明るさはレンズで集めたり近くで測ればいくらでも明るくなる。一方Lmを偽装するのは（少なくとも国内では）明らかに違法になる。
また、LEDの数か多いと、電圧を均一化する過程でロスが増える。また、LEDの半導体の効率を無視してパッケージ数の方にお金をかけているだけなので、コスト的にも良くない。

・電池はニッケル水素充電池を用意する。
LEDライトは一気に大電流を必要とするが、内部抵抗の大きいアルカリ電池（マンガンは論外）では、大電流を流すと出力電圧が下がってしまう。
エネループなどの充電池を使い、あらかじめ充電しておく。エネループなどLSDと呼ばれるタイプの新型電池は１年くらい放置しても大丈夫。

・単三電池１本、できれば２本で動作するもの。
LED趣味の人間の間で安価なクラス（2000円くらいまで）のLEDライトでは、電池一本1.2Vから1.5A程度の電流を取り出す(大電流なのでさらに効率は落ちる)。
出来れば単三・二本で駆動するタイプが持続時間的に望ましい。
単4電池は800mAh程度しか無いので、携帯用として常備するならいいかもしれない。

・teil stand (机に逆さに立てられるもの)
円筒状のLEDライトの底面を工夫して、机の上におけるものが多い。白色が多い天井に反射させて一時的な明かりとして使うわけだ。まあ構造上立たなくても、グラスなりで無理やり立たせればいいとも言う。

・曲面レンズを持たないもの
レンズ付きで集光能力の高いタイプと、ミラーだけで曲面レンズの無いタイプがあるが、後者が好ましい。
前者は遠くの狭い範囲を照らす場合、例えば、ナイトロードでの前照灯や、警備員が外から窓の締め忘れをチェックするような場合に使える。
後者は広い範囲をほぼ均一に照らすため、真っ暗な夜道などで足元を照らしたり、ものを探したりする時に役に立つ。
殆どの人は、ミラー式でレンズを持たないタイプをまず買ってみる事をおすすめする。

・フラッシュが無いもの
点滅するフラッシュモードを持つ製品が多いが、実際に役に立つことはほぼ無い。遭難した時にヘリに向けて気づいてもらうくらいにしか役に立たない。
100%と10%点灯の強弱２モードくらいで十分。

・表面処理の良い比較的高級品か、ステンレス製のもの
大抵アルミ製に安価なコーティングがなされている。高級品はそれなりに傷つきにくいが、安物は……。
ステンレスは重いが傷つきにくく、コンクリに落としても内部パーツが割れなければ問題なし。

・最新LEDを採用しているもの
特にCREE社のLEDは製品ラインによって全く効率が違う。今、明るさを求めて中国直販をするならXM-Lシリーズを狙うといい。
もっとも、室内利用を前提にするならXP-Cといた数世代前でも十分で1000円以下で手に入る物も多い。

中国直販では
Balder SE-1 $28くらい　（テールスタンドは非対応だけれどそこそこ安く明るい）
UltraFire C3 Stainless Steel $13くらい （ステンレス製。古いがシンプルで安い。フラッシュがあるのが難点）
あたりが手頃で無難とおもわれる。

なお、このクラスのLEDライトは直視すると本当にやばいのでお気をつけて。
（LEDの光を手に当てると暖かく感じるくらい）

交絡の排除と推定分布の信頼区間は別物

サイエンスライターが交絡を無視するのは不味いと思ったので書いておく

とある同じ病気の病人のグループを病院A、病院Bの2グループ10人ずつを用意し、Aには薬aを、Bにはプラセボを与えて観察した。
AとBとで生存率に統計的有意差が無かった（または有った）。
薬aの効果（生存率と投与量の因果関係）の有無を示すことができるか？

もしかしたら、
効果が有るようにみえて、実は病院Aは体力のある若い患者が多く、病院Bは体力のない老人が多かったかもしれない。
逆に、効果が無いようにみえて、病院Aは体力のない老人が多かったかもしれない。
つまり、病院と患者の生存率に交絡がある可能性がある。従って、これだけで薬の効果を判断することは出来ない。

ここで、各グループの人数を10倍に増員して、90人ずつ追加で実験したら、結論は変わるだろうか。
実験対象患者数が増えるので各グループから推定される生存率とその分布、つまり推定生存率の信頼区間は小さくなり、精度がよくなるだろう。もしかしたら見えなかった有意差が見えてくるかもしれない。
しかし、交絡を排除できるわけではないので、年齢構成など他の要因が効果の主要因であるという懸念を拭えない。

効果を示すには、グループを作成する際に可能な限りランダムに選ぶ、交絡の影響を既存の実験結果から推定して差し引く、投与量を制御して相関をみる。といった作業が必要になる。

というのが統計の基本的考え方。

一方、EM堆肥を実際に農地に施肥して放射線量低減に効果があるかどうか"検証"してみるという番組について、
片瀬久美子女史@kumikokataseは、
https://twitter.com/kumikokatase/status/258842868968476672
https://twitter.com/kumikokatase/status/258892540995067904
で、

EMを使用している農地と、対照としてEMを使用していない農地について、それぞれ複数箇所を測定して、データのバラツキ具合なども考慮して統計的な比較をすれば、どの程度差があるか（ないか）を指摘することはできると思います。

としている。

前述の病院の例に置き換えると、EMを使用している農地を病院Aのグループ、使用していない農地を病院Bのグループ、とみなせる。
複数箇所を測定していく＝患者数を増やせば、それぞれのグループの推定値はより正しくなっていく（個々のデータからくるバラツキは小さくなる）。しかし、グループ間の交絡による影響が排除されるわけではない。
各測定には隣接した農地という重大な共通点があり、例えば雨水からの流出入量、元々の地質の違い、耕作者の掘り起こし深さの違い、近辺の農家の施肥の違いなど、それぞれの測定で共通する交絡因子が容易に予想できる。

想定される交絡を排除した実験を行なって初めて、因果関係＝効果の有無を指摘できるようになる。
統計を使う記事を書くサイエンスライターが、交絡を無視するというのは問題がある。

この人の場合、ダイアリーのエントリ、 http://d.hatena.ne.jp/warbler/20120907/1346997502 をみると、EM批判の文脈ではEM堆肥とカリウムとの交絡を指摘している。
持論の必要に応じて、意図的に無視しているのか、気付いていないだけなのかは文章からはよくわからない。

交絡の排除のないn=1の比較はただのデモンストレーションであって、効果の有無の検証には成り得ない。
https://twitter.com/kikumaco/status/258838747439841281

ブログの投稿予約でアシの付かない犯行予告は出来るか？

……か？方式のタイトルなので話半分でお願いします。
真面目な話は http://tumblr.tokumaru.org/post/33682810605/web 辺りを読んだほうが良い。

大抵のブログには投稿を予約する機能があり、実装やUIは様々だが、指定時刻にブログ投稿・トラックバックやSNS通知を実行できる。
この機能を使って、アシの付かない犯行予告が出来るかもしれない。

犯行予告偽装問題で警察が"特定"したIPアドレスは、メールのヘッダやサーバなどのアクセスログから得られたものと思われる。ISPはIPと契約者の対応関係を保持しているので、契約者までたどり着ける。
メールは様々な場所に半永久的に保存される事がほとんどだが、HTTPサーバや各種ファイアーウォールのアクセスログはデータ量が膨大になるので適当な期間で破棄してしまうことが多い（ログローテート）。
共用レンタルサーバなど、どのアクセスが重要なログか管理者が識別できなかったりすれば、全てを保存することは困難になる。

とすれば、アクセスログが消える時点以降に予約投稿できれば、脆弱性を突いて予約投稿した時点の真犯人のログを消去させる事は不可能ではない。
例えばブログに、バックエンドDBにフルアクセス可能なSQLインジェクション脆弱性があれば、予約投稿記事や投稿者・DB上のログを捏造するのはたやすい。そしてそういった脆弱性は度々発見され、即座に修正されることがほとんどとはいえ、修正までに実際に攻撃されたかどうか細部までログを調べてチェックする人は稀だろう。

予約された犯行予告が正常に投稿された時には、深刻な脆弱性は全て塞がっているだろうから、真っ先に疑われるのはブログの運営者とサーバーの管理者で、アクセスログ無しに悪意ある第三者の存在を証明することは非常に難しくなる。
従って、犯行予告に使われうるコミュニケーション・パブリケーション系のサービスでは、アクセスログは全て、少なくとも威力業務妨害・脅迫罪の時効、例えば5年より長い期間保存する事が必須になる。

……というつまらない笑い話が浮かんだ。
同様にタイマーを使って記録を回避する方法は色々ありそう。例えばクライアントのメーラーやウェブメールの予約送信機能を悪用したり、もっとシンプルにタスク・スケジューラやcronで実行したり。

電子的な記録は捜査の"手がかり"になることはあっても、脆弱性さえあれば容易く偽造も隠滅も出来る、ほとんど証拠能力の無い代物。
脆弱性が過去に一つも存在しなかったソフトウェア・OSなど、現代ではもう存在しないと言って構わないだろうから、アクセスログがなかったら冤罪被害に遭うかも、なんてのは杞憂。

だといいんだけれど……

全国電話帳関連エントリについたコメントへの返答

「情報に詳しい通りすがり」を名乗る方からコメントがあったので少し丁寧語で返信。
http://causeless.seesaa.net/article/296187376.html#comment

"誰でも"云々は自分のエントリに対する指摘かと思いますが、
一般に"誰でも"は、「誰の要求でも許容する」事を指します。例えばフリー雑誌などの、"誰でも"ご自由にお取りくださいは、自分で取りに行く能力がない赤ん坊を対象にしていません。
特にWebでは、アクセス制御がかかっていないリソースは"誰でも"アクセス可能と見なされます。あなたにサーバまで辿り着く能力があるかどうかは関係ありません。

その他、特定人物・団体の虚偽や売名行為の指摘などは全てあなたの憶測と思われますので、根拠を公開の場所で示してください。
根拠が示されていない現状、失礼ながらあなたのコメントは名誉毀損に当たる可能性がある不適切ものであると、判断させて頂きます。

「情報に詳しい通りすがり」さんのIP 182.169.188.229 からの当ブログへのコメントはブロックさせていただきましたので、今後は公開の媒体で根拠を示した上で、トラックバックやTwitterメンションなどで言及リンクをお願いいたします。

なお、誤って別エントリ http://causeless.seesaa.net/article/296089367.html#comment 
に投稿されたらしい同一内容ポストは（全てのコメント確認後）削除しました。