リスクコミュニケーションちょっと面白かった論文

リスクコミュニケーションのアプローチを提案した論文、

Why Rules Are Not Enough: A problem-Solving Approach to Risk Communication, Katherine E.Rowan, Risk Analysis, Vol. 14, No.3, 1994

を読んでいて面白い部分を見つけた。リスクコミュニケーションとは、災害などのリスクを行政機関などが発信する方法や、被害者との間で対策方法などを調整することを研究する学問のこと。

この論文の中ではリスクコミュニケーションの具体的な戦略がいくつか記述されていて、面白かったのは2番目（4.1節 OptionB）。

• 聴衆が不安になっていることを理解し、尊重しているそぶりをみせる
• 発表側と聴衆側の相互が協力して問題の解決に取り組めるようにする（事前に策定された計画を無理強いしない）
• 様々な情報源に対して公平に耳を傾けてくれるようにお願いする
• 対策のメリット・デメリットをきちんと議論する

この2番目は、「あなたがなんとかしなければならない事故」から「わたしたちがなんとかする事故」へと変える働きがあると思う。そして、このはたらきは被害者と対応者の間に信頼と納得をもたらすのではないだろうか。

---

この論文は、リスクコミュニケーションに必要な段階を示した「CAUSEモデル」を提案していることで有名。このモデルに興味があれば筑波大のリスク工学の講義資料がわかりやすくて惚れ惚れ。

MSDNの警告のガイドラインが「Windowsの警告は過剰」ってdisってて吹いた

MSDNの警告のガイドラインに、下のように書かれていた。

Microsoft® Windows® プログラムは、警告が過剰です。Windows プログラムは、一般的に、あらゆる場面で警告が表示され、あまり重要ではない事柄についての警告も表示されるという印象があります。

Oh...

Gets！！！ （ほんとにあった怖いコード in jQuery）

納涼！ほんとにあった怖いコード（by CodeIQ×はてな）

jQueryのcore.js内の意味不明なコメント。問題のコメントがあるのはcore.jsの705行目。

      // Gets           

Gets？？？もう、もう意味が分からないです。いったい何をGetsするんですか。

それと、もうひとつ。core.jsの658行目。

  // Multifunctional method to get and set values of a collection
  // The value/s can optionally be executed if it's a function
  access: function( elems, fn, key, value, chainable, emptyGet, raw ) {

引数が7つもある香ばしい仕上がり。Multifunctionalにした結果がこれだよ！引数の意味の資料とかはもちろん存在しない。

これがJSで最も有名なライブラリか……誰か助けて…

Chromeに必要だったのはマスターパスワードではない。OSによる脅威の表現だ。

Chromeに保存したパスワードを見る方法はご存じだろうか。

知らない方は、一度 Chromeのヘルプ をみて体験してみることをオススメする。実は、この過程のなかでマスターパスワードによる認証はおこなわれない。巷では、マスターパスワードによる認証がないことが問題視されているようだ。しかし、本当にChromeが問題なのだろうか？

持論

OSベンダーが、パスワードロックされていない状態での脅威をユーザーが認知・理解できるようなインターフェースを用意するべき。

え、結論飛びすぎだって…？

ま、まあ、そこに行き着くまでの流れを見てから判断してほしい。

発端

自分がこの問題を最初に目にしたのはITmediaによる記事だった。これによると、どっかの開発者がクレームをいれたらしい（ITmediaによる記事）。

ITmediaで取り上げられる前からも、各所で不満はくすぶっていたようだ。 というのも、Safari・Firefoxではマスターパスワードによって保護できるオプションが存在するからだ（Safariはキーチェーンによって保護、Firefoxは独自マスターパスワード）。

なるほど、彼らはChromeに保存されているパスワードをマスターパスワードによって保護しろと言っているようだ。 しかし、本当に必要なことは別にあるのではないか？

まず、この問題にある背景を考察してみる。

この問題の背景には

本来はOSに用意されてるパスワードロックを使うのがベストなはず。 Chromeはもちろん、アドレス帳など個人情報が詰まったものも防御できるからだ。 しかし、これを嫌がる人が多いのも実情。

なぜ、OSのパスワードロックは嫌なのか。

1. 面倒
2. ブラウザ以外のものは見られても大丈夫そうという認識

の2つだろう（他にもあったら是非教えてほしい）。

実際、これまでの議論ではChromeに保存したパスワードが見られてしまうことばかりが叩かれていた。では、マスターパスワードなしで見られるであろうメールクライアントやTwitterクライアントはどうなのだろうか？実際はChromeに保存されたパスワード以外にも見られては（あるいは触られては）はまずいものがあるのではないか？

アプリケーションで個別にマスターパスワードを実装しても「面倒」を場当たり的に解決しているに過ぎない。本当は「ブラウザ以外のものは見られても大丈夫そうという認識」への対策をしてOSのパスワードロックを使わせるべきなのだ。

そういう意味では、ChromeでSafariに保存されているパスワードをインポートすると、平文で簡単に閲覧できる ことはChromeが悪いのではない。パスワードロックを使われないままにした OSが悪い のだ。

本当に必要だったのは何なのか

「ブラウザ以外のものは見られても大丈夫そうという認識」に対策が必要なのはお解りいただけただろうか。ではどのようにして、この認識を防げるのだろうか。

最も簡単なことは、攻撃者が何をどこまでできるのかということを理解させてあげることだ。要するに、 「あなたが席を外している間、誰もがあなたのメール、連絡先、Facebook、Twitterにアクセスできます」と。

たとえば、メール・連絡先・ブラウザにこっそりアクセスしている攻撃者のアイコンをスクリーンセーバーなどで表示してあげることができる。これに「ぎょっ！」としたユーザーは、文句も言わずにパスワードロックを使ってくれることだろう。Chromeにマスターパスワードが実装されていないことなど、気にならなくなるに違いない。

Promise/A+仕様の邦訳

Promise/A+仕様を翻訳しました。最後のほうは難解だったなぁ…。

Promise/A+仕様

quickrunのためにnodeunitからmochaに乗り換えた #vim

Node.jsで動作するユニットテストツールをnodeunitからmochaに乗り換えた。理由はquickrunとの相性が悪かったためだ。

いままでは、VimShellでnodeunitを叩いていたんだけど、あんまりに面倒なのでquickrunを使ってみることを決意。しかし…

• nodeunitの結果表示はエスケープシーケンスによる色づけが多く、quickrunのバッファ表示がきちゃない
• quickfixでの表示にしてみたら、エラー箇所のファイルパスがnodeunit本体を指すことがあってロケーションリストが正確じゃないことが判明（nodeunitのmachineoutレポ—ターの問題）
• テストケースの名前に空白が含まれるとエラー行の正規表現がバグる
• quickrunは絶対パス使うのだが、nodeunitは絶対パスのファイルをテストできない（pull req送った）

挫折… orz

なので、nodeunitに変わるユニットテストツールを探してみた（他の候補についてはNode.jsのテストフレームワークについてが参考になります）。んで、今イけてるらしいmochaを使うことにした。少し非同期のテストケースの構文にとまどったけど、概ね好感触。

mochaのインストールはnpm install -g mochaでOK。

quickrun側にmochaの設定を追加するために、vimrcに以下の設定を追記する（前にlet g:quickrun_config = {}が実行されているの前提）。

let g:quickrun_config['javascript/mocha'] = {
      \ 'command': 'mocha',
      \ 'tempfile': '%{tempname()}.js'
      \ }

あとは:QuickRun javascript/mochaでquickrunされる。

できればquickfixに引っかかった箇所を表示したいのだけれど、mochaのレポ—ターを書かないといけないっぽいので保留。時間があったらやろうかなぁ。

---

一応nodeunit用のquickrunの設定も書き残しておく。

let g:quickrun_config['javascript/nodeunit'] = {
      \ 'command': 'nodeunit',
      \ 'cmdopt': '--reporter machineout',
      \ 'tempfile': '%{tempname()}.js',
      \ 'outputter': 'quickfix',
      \ 'outputter/quickfix/errorformat': "%EFail:%s:%f:%l:%c:%m,%Z,%IError:%s::::%m,%Z"
      \ }

nvm から nodebrew に乗り換えた

Node.jsのバージョンを管理するツールnvm から nodebrew に乗り換えたので作業メモを残しておく。

乗り換えた理由はVimShellとの相性が悪かったためだ。 なにやらnvmはbash環境むけに作られているらしく（Node.jsとnvmを初めてインストールするときのハマりポイントと対策）、VimShellでは動作してくれなかった（そのときVimShellはwhichできない病になっていたので、nvmだけが原因でないかもしれない。ちなみにこの病気はPC再起動で直った（謎））。

nvmのアンインストール

さて、まずはnvmのアンインストールから。 やり方を公式から探してみるが見つからない…

(1) ~/.bash_profileの下の行を削除。

[[ -r $NVM_DIR/bash_completion ]] && . $NVM_DIR/bash_completion

(2) ~/.nvm以下を削除。下のコマンドを実行。

rm -rf ~/.nvm

これで大丈夫だと思う。

nodebrewのインストール

nodebrew をインストールする。公式のとおりにやれば問題ない。

(1) nodebrewをインストールする。下のコマンドを実行。

curl -L git.io/nodebrew | perl - setup

(2) 安定版のNodeをインストールする。下のコマンドを実行。

nodebrew install-binary stable

こんなもんだろうか。

ちなみにinstall-binaryオプションにしないと、延々とビルドされてしまうので注意。 （自分はnodenrew install stableをしてしまい、MacBookのCPUが焼かれたorz CPU温度：82℃）