GMail Trashメソッド

最近、メールはとにかく一切合切GMailで受け取るようになった。リアルの主なメールはGMailに転送しているし、さらに気が付く限り、ネットのサービスの「メールアドレス」欄をGMailのメールアドレスに変更した。すると、数々のニュース、メールマガジンなど、以前から購読しているものも含め、すべてGMailに集約される。

そういう環境の基本機能として、SPAM判別機能、Report SPAM機能は大変便利だ。SPAM判別情報が他のユーザとシェアされているかどうかわからないが、そこそこ学習してくれているようだ。体感的には、POPFileより少し落ちる程度の精度だ。購読申込した覚えのあるメールニュースと、メールニュース仕立てのSPAMを正確に判別してくれる。

しかし、業務メールと違い、これらメールニュースは溜まっていく一方では役に立たない。後者の賞味期限は短いのだ。そう、昔は、インターネット上に情報が十分ではなく、有料のメールニュース（?Watchなど）を溜め込んでおいて、それを検索することでリサーチに役に立ったこともある。しかし今は、Ask Google!で済むから個人が溜め込んでおく意味合いは低い。

当初、newsというラベルを作ってフィルターでラベリングしてみた。それでも、読まないメールはどんどん溜まる。news(256)のように、未読数カウントがみるみる増えていく。不思議と、未読数は多くなればなるほど見たくなくなる。読んだことにして消すのもかなり大変。

そこで、sakurayuta師匠曰く、「メルマガ系は、フィルターでTrash(ゴミ箱)に放り込んでしまえ」、というものだ。どんな効能があるのだろうか。

・Trashフォルダへのリンクの横には未読数の表示はない。
・30日で自動消去がすばらしい。無限に溜まっていくということはないからね。
・検索の対象だ！30日以内のニュースだけならピックアップ価値も低くないねー。
・SPAMとはごっちゃにはなっていないので、フォルダを開いたときの汚れ感も低い。
・GMail Notifier、Google Desktop2を入れていても、Skip inboxしていれば何も表示しない。
・デフォルトで捨てる、任意で見る、というのはいかにもポジティブセキュリティ風味だ。
・「リアルでゴミ箱の新聞を読む習性(sakurayuta氏談)」なんてシュール感もある。

ふふーん、スバラシイ。超整理法的だ。（コーヒーをずずっと

気が向いたときに、Trashをおもむろに見る。見たくなったものだけ見ればいいから、悪くない。毎日何通も来るのはわかっているが、仕事をトラップされないというのはむしろ快適だ。inboxに戻れば、現実の世界にすぐに戻ってこれる。

GMailで言うところの「ラベル」の属性として、expire指定ができればいいのにな。確かにソフトウエア原理的に削除系はリスキーだが、それでも、メーラーのフォルダの属性、フィルタの属性などにexpire機能があるといいなあ。是非メーラーに実装してほしい。メール単体に実装する、でもいいけどね。「このメールは自動的に消滅する･･･」みたいな（ｗ

そうそう、OSのファイルシステムにもそういう機能があればいいんだ。いやまてよ、そんな機能はこれまた悪用しがいがありそうだ･･･それに悪意のあるコードにもさくっと実装されそう･･･それに、コンプライアンス的にはSOX法と真逆の論理じゃないか･･･。悩ましい。

でも、それでも、Keep it simple and special.古い、使わないものは捨てるに限る。超整理法的機能なのだから、ぜひ実装してもらいたい。あれ、捨てるんならTrashでいいのか･･･。

てわけで、これ、すなわち「GMail Trashメソッド」と命名。

手帳のアーキテクチャー。

こういうことで悩むのは昔から好きだ。手帳は、毎日の生活の文化に影響するから、というだけの理由ではないと思うが、行動指針を見直すいい機会になる。

ほぼ日手帳
http://www.1101.com/techo/

2005年は「ほぼ日手帳」を使ったが、このリピートは残念ながら、ない。シンプルで書きやすかったが、わたしにとって手帳に求める意味合いは日記形式でクローズするものではなかった。書きなぐったタスクやメモなどは他の日程ともリンクした横断的なものであったし、それゆえに日次のTODOよりも、時系列を自在にまたぐものとして管理しなければならないことを痛感したからだ。

また、各プロジェクトは数日、数週間、数ヶ月と様々だが、それをごっちゃにして時系列で並べては混乱する。むしろそれごとにスレッド化して管理すべきである。いかに書きなぐりがしやすい手帳でも、製本として閉じてしまう方式はなじまないように感じている。

全ページがばらばらにでき、かつ任意の順番でオーソライズできるのであれば、それはそれでアリかもしれないが・・・、それでは、ほぼ日手帳ではなくなる。そこで、手帳を模索するプロジェクトが発足したのだ。


FlanklinPlanner
http://www.franklincovey.co.jp/

Tokyu Handsで見た、フランクリンプランナー。「7つの習慣」とか有名な本があるが、その実行ツールと言っていいだろう。最近はとうとう「8つ目の習慣」が出たんだそうだ。詳細なプロジェクトや思考のテンプレートや、「7つの習慣」の名言がちりばめられているのはそれなりに教訓的。

しかし、私に言わせればfortune　cookieと大差なく、それほどありがたいものではない。皮肉めいた言い方をすれば、自分の行動指針を持たず、朝のTV番組や安っぽい週刊誌の占いに頼っているような - そう日本人とは概してそういうものだが - そういう人の意識にはもしかすると教育的効果はあるかもしれない。

テンプレートは、プロジェクト管理の思考を身に付けたい人にはいいんだろうが、私にはウルサく感じられるし、むしろ窮屈だ。私には、軽い小話を書いているほぼ日手帳のほうが面白い。その部分だけ携帯に毎日配信してもらいたいくらいだ。


Time/System
http://www.timesystem.jp/c/catalog.html

伊東屋で、kumikumiが言及していた、TimeSystemを見てみる。ほほう、なるほど、たしかにFPほども鬱陶しくない。基本はA5。他のサイズもあるようだが、この大きさは書きやすそうだ。プロジェクトテンプレートは1年間ずどーんとあるにしてはデイリーは細かい。ウィークリーで十分な気もする。

マインドマップ、マトリックスなど、FPよりすっきりしたテンプレートがいろいろあるのは面白い。それに、FPと異なり、汎用性のあるリフィルがあるので、A5サイズを基本とした場合には「つまみ食い」可能だ。

ここまでくると、もう趣味の世界だな（ｗ　もちろん、脳内スイッチを入れるのにデザインは重要だ。しかし、やはり致命的なのは、これは（他と同様）TODOを時系列を越えて継承することができない。使わない欄がでてくるのはもったいない。


さあ、どうしたものか

まてよ･･･。とりあえず、やりたいことは、議事録、講義準備、プロジェクト計画、アイデアスケッチ、マインドマップ、マンダラート・・・。碁盤の目さえ下敷きとして書いてあれば、自分には十分なのではないか？ 大きさは、RHODIAの#16がちょうどよい。あれを持ち歩き、どんどん書いていき、開穴してA5のシステムファイルにスレッド化してオーソライズすればいい。

スケジュールはできるだけライトウェイトなカレンダーだけあれば十分なんじゃないかな。サイボウズやGoogle Calendarなどのサービスに依存しそうな気もするから、できるだけ単純なものを持ち歩いたほうが得策だ。TODO管理については、今のところRHODIA #11に勝るものはないし、これを携帯しなくなることはなさそうだ。

これでしばらくやってみようか。

フィッシングリスク軽減のためのヒント

「ポジティブポリシー重要！」といったそばから「べからず集」、すなわちネガティブポリシー的なのも何なのだが（苦笑）、こういう記事がでた。

日経BP ITPro 記者の眼「“フィッシング時代”のメール「べからず」集」。

紋切り型のセオリー集としてではなく、リスク軽減のヒントとして捕らえていただきたい。サイトによってリスクはさまざまだし、防衛方法もさまざまなので。かといって、「他社様」の選択が正しいわけでもないのに、ダメなほうに横並びなのはあまりに嘆かわしいしね。

こういうのは、ともすれば一人歩きしてしまいがちな「セオリー集」になってしまいがちだが、適用を自分で考えることができるよう、微妙なニュアンスを表現に加味してくださった勝村氏のご苦労に感謝したい。欲をいえば、やや過剰ギミな名前の連呼はご勘弁願いたいところだが。

ま、それもリスクヘッジなら仕方がないね ;-p

ネガティブポリシーからポジティブポリシーへの転換

6/29に第二回情報セキュリティEXPOの専門セミナーにてお話をさせていただく機会がありました。第一回のときは、OWASPの人とペアでしたので、「Webセキュリティ」の話一色でさせていただいたので、「フィッシングに利用されないようなサイト作りを」みたいなことを提言しました。今回は、アンチウィルスベンダーの方とペアで、どちらかというと企業がどのように防衛するか、という御題をいただきました。

Webにせよメールにせよ、セキュリティ防衛をする際に念頭におくべきことがあります。その一つは、「ネガティブポリシー(negative policy)」と「ポジティブポリシー(positive policy)」の違い。前者は、例えば「ブラックリスト」にのっとって受け入れられないものを排除する方式で、いうなれば悪いものをろ過する方式であり、前者と対照的に「ホワイトリスト」にのっとって受け入れられるものを厳密に定義する方式を解説しました。

ウィルス対策の場合、原理的に言ってウィルス定義ファイルはまさにブラックリストであり、それゆえにアップデートしつづけなければなりません。もちろん、ヒューリスティック検知方式などで補完することにより、ブラックリストに載っていないものも「それっぽい」ということで濾過することを可能にしています。SPAM対策でよく用いられる、ベイズ理論は、悪いものと良いものの両方の類推方法を学習していきますので、これら二つの方式の組み合わせと考えることができるでしょう。

WEBのフォームの入力データの場合、よく「サニタイズ(sanitize:「消毒」の意)」という言葉が用いられます。これは、ネガティブポリシーに基づく用語です。HTMLのタグや特殊記号などをフィルタリングするなり、クォーティングするなりという処理を行なうことを指します。しかし問題は、実際には入力データはそのアプリケーションの要件により毒にもなれば実にもなるわけですから、サニタイズという概念では完結しません。

また、危険の可能性がある文字なりパターンなりのすべてをプログラマーが知らない場合はどうでしょうか。見落としリスクがあるということです。そのアプリケーションは、そのプログラマーの腕に依存します。新たな脅威がでてきたら、そのプログラマーは直ちにサニタイズプログラムをアップデートしなければならないでしょう。それは現実的な方法ではありません。そういうわけで、WASForumのコンファレンスで高木さんが「サニタイズ排除キャンペーン」を発表されたのには全く同意です。

むしろ、正しいアプリケーション設計の観点から言うなら、本来すべきことはサニタイズではなく、入力の有効性検証(input validation)です。これはサニタイズに似ているようでも、実際には全く異なります。害のないデータでも無効なものはいくらでもあります。各々のフォームにおいて、「有効な(valid)」データを、桁数、文字種などに至るまできちんと定義し、そうでないものをすべて排除するという方式をとることです。

現場では、ポジティブリストの安全性を担保するため、あるいは、どんなリスクがすでに発生しているかを知るため、ブラックリストに該当する入力があった際にアラートを発生させるなどの方策を実装する場合などには、サニタイズプログラムは有効でしょう。しかし、根本的に、危険の可能性を知っていることだけを前提にした設計は、運用的にすぐに破綻しやすい、ということです。

今回の講演でこの話をしましたら、熱心に聴いてくださったメディアの方がサマリーを掲載してくださっていました。少しニュアンスが異なる部分もなきにしもあらずなのですが、シェイプアップしてサマライズしてくださっていますので、ぜひご覧ください。ご意見、ご感想も歓迎します。

ユーザを守る責任とスピード感

CNet Japanに、「カカクコム事件に見るセキュリティの本質とは」 という記事を寄稿しました。クラックされた他社の被害の手口に関する詳細情報は、セキュリティ維持の観点で不可欠だとはいえない。2ページ目では、EBサイトの攻撃から被害の拡散に至る情勢からすると、被害を想定した対応方針が必要で、そのポイントは「スピード感」 であることを示しました。最後に、WEBサイトの運営者の企業のCSR（社会的責任）に言及しました。

ご覧いただければ幸いです。