May 31, 2007

Paper: Grow and Know: Understanding Record-Keeping Needs for Tracking the Development of Young Children

Grow and know: understanding record-keeping needs for tracking the development of young children,
Julie A. Kientz, Rosa I. Arriaga, Marshini Chetty, Gillian R. Hayes, Jahmeilah Richardson, Shwetak N. Patel, Gregory D. Abowd
Human Factors in Computing Systems(CHI2007), pp.1351 - 1360
ACM Digital Library

5才までの子供の成長と学習はそれ以降の人生に大きく影響する.定期的に小児科医にかかり、子供の成長経過を詳細に記録することは、知恵遅れや障害の早期発見に役立つ.しかし、新人の親は新たなに生じる責任に圧倒されそれどころではない.そこで技術がそれを支援できないかと考えた.この論文では、親と子供を世話する人たちによる成長記録とその解析を支援するための要件を調査した.インタビューを通じて、親が持っている根拠に関する仮定を確認するとともに、記録継続のための技術要件を調べた.

以下は論文内容のメモ書き


■ Introduction and Motivation
- 障害や知恵遅れといった問題の兆候は2才から6才のあたりのどこかで現れてくる
- 早期発見すれば、治癒可能性が高い
- 一つの方法は、成長過程で何らかの問題や遅れが見られたら、小児科にかかることである
- Centers for Disease Control and Prevetion(CDC)は、新米の親向けに、250ものマイルストーンを提供し、成長過程が正常かどうかを確認できるようにしている.

- すべての子供にとって成長記録をつけるのは、公衆衛生(?)上非常に重要だが,それは親にとって無理難題
- ま何を記録すべきか、何がいつまでに達成されなければならないか、どうなったら成長尾が遅れているのか?といった知識もない

- 感傷的な理由に基づく記録はすでに行われている.(写真や動画,歯が生えたことなどを成長日記に書き留めるなど)
- 技術によってこれを拡大し、退屈な作業を簡単化し、そして感情的記録としても有効なことを示して記録を動機付けできないか?
- 子供の成長記録を記録可能にする技術支援手法とその設計要件を探求する
- インタビューによる調査
-- 新米の親
-- すでに子供のいる親
-- 子供の世話をする人たち
-- 医療関係


■ Related Workd
心理学や教育分野で研究が進んでいるが、HCIではまだ

□ Supporting New Family Needs
家族の感傷的記録を残すためのシステムという研究はある.
健康診断を目的とした成長記録システムはない
□ Early Detection of Development Delay
成長障害の特定を目指した多くのシステムは、特定の兆候を識別することに注力している
□ Coordinating Care
子供の世話は共同作業.チーム作業の支援が必要
Computer Supported Cooperative Care(CSCC)という言葉もある
老人介護の研究がある(The Digital Family Project)
□ Understanding Needs for Health and Wellness
健康管理技術に関する設計要件、老人介護における設計要件、認知障害者支援のための設計要件などの研究あり
□ Persuasive Technology
親がきちんと子供の記録を残せるような技術には、ある程度の動機付けが必要「Persuasive Technology」
子供の健康的な成長と、老人の健康的な老いには共通点あり


■ Study Design
- 利点と必要性、現行システムの欠点を確認するためにインタビュー
■ Target Stakeholders
□ New or Expecting Parents
新米の親、または近いうちに親になる人
□ Experienced Parents
すでに子供を育てた経験のある人
□ Secondary Caregivers
ベビーシッター、乳母、デイケア
□ Mediacal Professionals
医療関係者


■ Interview Paticipant Details
■ Focus Group Details
□ Daycare Focus Group Participants
□ Medical Professional Focus Group Participants
■ Analysis Methods and Results
■ Analysis Method
なぜ親が子供の記録に関して技術的支援を必要とするか? その根拠として6つ
R1. 成長過程を記録する時間がない
R2. できるだけよいよい成長をとげて欲しい
R3. 記録時刻を後で知る必要があるため
R4. 観察していたイベントを記録し忘れる
R5. 子供の記録を残さなければという動機があるため
R6. 成長記録や写真を他人と共有したいため

技術的支援が必要とされるか? 9つの機能概要
F1. 入力データにリマインダー(注意喚起)を付与するため
F2. 子供の健康や成長を監視し、異常時に警告させるため
F3. 記録の自動化のためにセンサーを使用する
F4. なんとか記念を作ったり写真を撮り,友人や家族と共有する
F5. 心配事がある場合に、健康情報を提供して相談するため
F6. 子供に関する健康記録と感傷的記録を一元管理するため
F7. 複数の介護人が、情報入力できるようにするため
F8. 健康ならびに感傷的記録の双方の目的で写真や動画を記録するため
F9. 親に情報や経験の共有機会を与えるため、また信用できる情報源からの情報を得るため


■ Results - Emergence of Trends
- 新米の親、経験ありの親、介護する側の3つのグループでデータ集計
- 根拠には、平均して61-83%の割合で賛同
- 3つのグループで差異は見られない
- 基本的に、どのグループでも技術的支援は必要だと思っている
- 介護者はR2(親はよりよい成長をとげて欲しいと思っている)に強く賛同
-- 親は介護者が潜在的な問題を発見してくれれば,よりよい成長になると思い込んでいる
-- 働いている親は、そういった兆候を見落としがち
- コンピュータによる記録支援は、新米の親よりも経験ありの親や介護者に強く指示されている
-- R3, R4の結果がそれを示している
-- 新米の親は楽観視しているが、経験ありの親と介護士は現実を知っている
-- F7の結果もそれを示していると言える


■ Results - Emergence ot Themes
- 想定外のテーマや根拠、機能がないかを調査
- 8つのテーマを抽出

□ Customized Records for the Individual Child
- 子供に応じて,男女差、文化的違いも考慮してカスタマイズできるように
- 「この子は三週間も早く生まれているので、まだそれができなくても問題ないです...」
□ Supporting Interactions with Pediatricians
- 医者としては成長記録を取って欲しいのだが,それは難しいらしい
-- 「成長記録チェックシートを用意していて、親に渡すのだが,チェックをしなかったり、持って帰らない親すらいる」
□ Difficulties with Capturing Records
- 時間がない、写真や動画をとっても整理できない、動き回るようになると...、二人目三人目は記録する動機がなくなってくる
- 写真や動画の共有も簡単でない、またプライバシー問題の懸念もある
□ Record-Keeping is Not for Everyone
- 必要とも欲しいとも思わない、マイルストーンに固執し過ぎもどうかと、動画記録はプライバシーの問題もあるし、そもそも気分が悪い、介護者は親に監視されていると思い、負担になる.経済的理由でそういった機材を導入できない家庭はどうするのか?
□ Knowing What, When, and How to Record
- 記録をとっても、それから何が異常で何が正常かがわからない、信頼できる情報源がないと、誤った判断をしてしまう、よりより成長マイルストーンと、混乱した場合の信頼できる情報源が必要、マイルストーンの回答がyes/noだけというのも変ではないか?
-- 「おもちゃを想像力豊かに使って遊ぶ...ってどんなことをしたら達成とみなすの?」
□ Reflection and Analysis on Childhood Records
- 記録したデータの解析や確認方法に対していくつかの提案を持っていた.
□ Pros and Cons of Computerized Recording
- 記録の電子化には賛否両論だった.簡単化されるだろうが,不安点も.整理の方法が不十分、データ消失の可能性も.成長記録が物理的に残せない不満.
□ Diagnosing Disabilities and Disorders
- 子供の障害診断には驚かされるらしい.そんなことまで知っていなければいけないのかといった情報を提供しなければいけないことをその時初めて知る.医者の診断でも適当のようにみえることも? 「男女差だから... / しばらく様子を見ましょう」.記録が電子化されることによって、異常の判定があまりにも敏感になりすぎるのも問題があるかも


■ Discussion and Potential Prototypes
■ Key Design Considerations
□ Take advantage of existing motivations
健康目的というだけでは記録は続けられない.感情的記録には動機があるのだから、それを利用せよ
□ The computer should not replace the pediatrician
医者との良好な関係を築き、定期的に診断にかかるのは重要.医者と親の関係を改善するために技術を適用するようにすべきであり、診断を技術ベースなどですべきではない
□ Provide a reliable information source
信頼できる情報を提供し、かつ二者択一的であってはならず、それはカスタマイズできるようにせよ.
□ Provide for effective communication for the child's caregiver
子供を取り囲むいろいろな関係者がデータを入力できるようにせよ.また情報共有を可能にし、かつなんらかの変化を通知できるようにすべき.また遠隔地の親戚や友達と情報交換できるような通信機能も備えるべき


■ Potential Technology Designs
- 二つのシステム実装例

□ Developmental Milestone & Media Repository
- 親は子供の健康に関する様々な情報や画像,動画をシステムに追加可能
- 介護者はそれを見て、マイルストーンに到達しているかを確認
- 信頼できる情報源からの情報提供
- 通信機能付き
- 親への警告と詳細なチェックリスト、ならびに小児科医への予約をすすめる
- 写真や動画の一元管理
- マイルストーン毎のデータ抽出支援
- 介護者によるデータ入力も可能
- 医者への詳細情報の提供
- バックアップ
kid11.png

□ Smart Baby Monitor with Specialized Toys
- Smart baby monitor
- ビデオ録画は後で解析/確認するのが困難
- handtop computerで最近15分間の子供の様子を常にビデオ録画
-- 親や介護者が大事だと思われる兆候を見つけた時にのみ、そのビデオ記録を残しておく

- Wireless sensor-enabled toys
- 子供がそのおもちゃを使って、特徴的な行為をしたときにそれを通知する
-- 「おもちゃを持って、それを振る」といった行為 - 7ヶ月児
kid12.png


■ Conclusion
- インタビューから、子供の記録を取り続けるのに何が必要かを調査した
- 我々の想定した仮定の多くが、インタビューワーによって支持された
- 成長過程を評価するために、子供の成長記録をつける必要があるということと、それがなんらかの形で支援されるべきだということがわかった
- 記録を続けるための動機付けに関して問題があることと、解決されるべき懸念もあることがわかった


よくも悪くも「調査して、必要要件を明らかにしました」論文である.ライフログの一種とも言えるかもしれない.

Posted by z at 02:33 AM

May 30, 2007

ウイルス情報iPedia(ウイルス情報データベース)をIPAが公開

IPA(情報処理推進機構)が、ウィルスやボットに関する動作内容や対処法に関する情報をデータベース化して公開したそうです.

Webデータベース「ウイルス情報iPedia」
https://isec.ipa.go.jp/zha-virusdb/web/Top.php

これ自体は有意義なことだと思うが、このニュースを見て、そして実際にほんの少しだけiPediaを使ってみて思ったことは「このままでは、このシステムを有効活用できる人はごく一部の人に限られるのではないだろうか?」ということである.

このシステムを利用するには、ウィルスの名前を利用前に知っていることが大前提になっているように感じる(もちろん、そうでない可能性もあるが、少なくとも当方が受けた印象はそうである).だとすると、ウィルスに感染したが、それがなんのウィルスかを調べたい人にとって、このシステムは有用ではないように感じたのだ.

また、ウィルス名かそのウィルスに関するなんらかのキーワードを得ていれば,iPediaでなくてもそのウィルスに関する調査は可能である.製品を作成しているウィルスベンダーのWebを調べた方が、情報の公開も迅速だと思われるし、その内容も詳細ではないかと思ってしまった.

とすると、このiPediaがターゲットとするユーザは一体誰なんだろう? と疑問になったのである.

もちろん、「ウィルス博物館」としての意義はあるかもしれない.が、セキュリティ対策としての価値は疑問に思う.少なくとも既存のウィルス対策ソフトですでに対策済みであり、Do not careになっているウィルスの情報を検索してまで知ろうという人がどれだけいるのかも疑問である.
# まったくいないとは言わないが...

ただ、これがウィルスではなくボットになると話は変わってくるも思う.
できればウィルスとボットは情報を分割し、別の形で情報提供をして頂ければなと思う.

■ 関連記事
IPA、ウイルス情報データベースの公開を開始 (ITPro)
「このウイルスってどんなの?」を簡単検索できるデータベース、IPA (ITmedia)
IPA、独自の解析システムによるウイルス情報データベースを公開 (Internet watch)
IPAが「ウイルス百科事典」、対処法は「今後追記」 (@IT)


Posted by z at 03:22 AM

May 29, 2007

Paper: Protecting people from Phishing: The Design and Evaluation of an Embedded Training Email System

Protecting people from phishing: the design and evaluation of an embedded training email system
Ponnurangam Kumaraguru, Yong Rhee, Alessandro Acquisti, Lorrie Faith Cranor, Jason Hong, Elizabeth Nunge
Human Factors in Computing Systems(CHI2007), pp.905-914, 2007
ACM Digital Library

Phishing対策として、ユーザ教育をするための"Embedded Traning"システムの設計とその評価に関する論文である.
対象となるユーザに対し、Phishingメールを投げ込み、実際にPhishingされた場合に、「画像と文字」と「漫画調」の2つの方法でユーザに「このメールはこういう仕組みでPhishing mailだから、こういうのにはひっかかってはいけませんよ」と教示するシステムである.またユーザによる実験結果から、embedded training systemの設計原則を導く

sec31.png
sec32.png

以下は論文内容の走り書き


■ Introduction
- "Semantic attack" 人間における弱点を突いた攻撃手法
- phishing もsemantic attackの一つ
-- 最近ではemailやweb siteの偽装だけでなく、Webブラウザの偽装までやってのける

- 既存のphishing対策研究は、以下の二種類に注力されてきたが、それらはユーザがphishingメールにひっかかるのを防ぐことにはならなかった
1. Webブラウザでphishing攻撃を検知するアルゴリズムの開発
2. anti-phishing用のwebブラウザ用ツールバーのインタフェース評価

- 本研究では、phishingの危険性とその見分けかた/回避の仕方を教えることに注力する
-- "embedded training"の提案
--- 通常のE-mail利用を通じて、phishingの脅威と対策を教育
---- 定期的に、ニセのphishingメールをユーザに送りつける
---- phishingに引っかかってしまったら、即座にシステムが介入し、何が起きたかと、どうしたらこういった攻撃から自身を守ることができるかをfeedbackする

- 二種類のembedded training systemを提案
-- 文字と画像による警告
-- 同じ内容の情報を漫画調にて提示
- ユーザ評価の実施、既存のメールによる通知との比較


■ Related Work
- Phishing対策には3つのカテゴリ

1. 脅威の除去
- ユーザに何も提示せず「寡黙に」その脅威を排除する手法
-- しかし、100%排除できるものはまだ存在しない
-- Phishing webサイトの存在時間は短い(平均4.8日 from APWG報告)

2. ユーザへの警告
- 明示的な警告または疑わしいサイトであることを通知するためのインタフェース提供によるユーザへの警告
-- "Trusted path"というプロトタイプや、いわゆる信号メタフェーによるWebブラウザツールバーなどがある
--- しかし、3つの問題点がある
---- 専用のソフトウェアをインストールしなければならない
---- 警告や通知の意味が理解できない
---- phishing検知の性能が悪い

3. ユーザ教育
- ユーザ教育は重要.上記の二種類の手法と並行して行われるべき
- 基本的な手法は、既存のphishingサイトの情報提供
- Webベースの試験による、phishingに関する知識検査と強化

- ニセのphishingメールをユーザに投げ込み、それをphishing教育前と後で行って、教育効果を測定する研究もある

- この研究では、phishingの脅威を教育するにあたってどんな介入方法が最も効果的か? その設計手法をユーザ評価を通じて探求する
- 特定のphishing手法の教育目的のみに限定されない、汎用的なものを目指す


■ Ratoinale for Email Intervention
- E-mailによるphishingに特化
-- E-mailによるphishingが一番Major
-- Webサイトではユーザがそれに触れる機会が少ない
-- mailによる教育は、end-userを実践で教育できる

- ゲーム形式のphishing教育システムも実装した
-- これはembedded trainingシステムと相互補完することになる
-- 平時はembedded trainingをし、さらに学びたいとユーザが思った時にはゲーム形式の教育システムを利用する


■ Early Design
- 紙ベースのプロトタイプでアイデアを練った

- 結論としては
- メール中のリンクを押した後すぐに警告を見せるのが一番効果的
- リンクを押した後、なぜリンク先のWebサイトが見れないのかを明確にわかるような警告にする
- 一般的な警告ではなく、どうすればよいのかを指示するような内容の警告にすべき
- 正確な警告と混乱を避けるため文字と画像で簡潔かつ視覚的に情報伝達すべき


■ Current Design
- 二つの警告方法
1. 文字と画像
2. 漫画調
- 漫画調を採用した理由は、1では文字を読まなければならず、結果として警告を読まずにウィンドウを閉じてしまう恐れがあるため

- ユーザに教えるべき点は次の4つ
1. メール中のリンクをクリックするな
どれがphishingサイトへのリンクで、どれが問題のないリンクかを知識のないユーザが判断するのは困難.まずは簡単な規則として教える

2. 自らコンタクトを取れ
メール中のリンクをクリックするのではなく,自分でURLを入力するか、Bookmarkを使え

3. カスタマーサービスに電話連絡せよ
もし自分のアカウントに問題があるのなら,networkを通じてではなく電話をして問い合わせよ.これはサービス提供側にとっても、顧客からの電話問い合わせが増えることで、なにかおかしなことが起きていることに気づくという意味でも有益である.

4. 決して個人情報を入力するな
ほとんどの正規のサービス提供者はそのような情報入力を要求しない.そして、phishingの目的のほとんどは、こういった情報だからである

- 最新の警告画面はhttp://cups.cs.cmu.edu/trust/et_design.phpで見ることができる


■ Result
- メール中のphishingサイトへのリンクをクリックしたら攻撃にひっかかったと判定

□ Security Notice Intervention
- 2回の警告の前後でphishingにひっかかる割合に変化は見られなかった
- 文が長くて読む気がしない
- 何を伝えたいのかわからない
- 2回の警告を受けた後に3つのphishingメールがあったのだが,そのphishingメールにひっかかった割合は平均で63%だった

□ Text and Graphics Intervention
- 画像と文字による情報提示はいい!
- phishingから身を守る方法を段階を追って教えてくれるのがよい

□ Comic Strip Intervantion
- これが一番教育効果があった
- ストーリにのめり込むことで、言いたいことが伝わってくる
- 参加者の一部には、文字と画像の方がよいという人もいた.
「子供には漫画の方がよいだろうが、私は文字と画像の方がよいな」


■ Comparison
- phishingを見分ける能力については、通常の警告と漫画調の警告では有意な差が見られた.しかし、通常の警告と文字/画像による警告との間には有意な差が見られなかった
- 文字/画像による警告と漫画調警告との間にも有意な差が見られた
- 警告後のphishingメールに引っかかった数は漫画調警告の場合が一番少なかった

- どちらの警告が良いかについて尋ねたところ、9人が漫画調、11人が文字/画像による警告が良いと答えた
- 通常の警告の場合、「これがニセのWebサイトやメールを見分けるのに役に立つか」という質問に対して役に立つと答えた人はいなかったが、embedded trainingの警告については全員が役に立つと答えた


■ General Observation
- アカウントを持っていない組織からのメールなのに、それを確認せず、phishingメール内のリンクを押してしまう人がいた
- 80%の参加者が、リンクの上にマウスカーソルを置くとリンク先を知ることができることを知らなかった
- 一度オンライン詐欺に引っかかってしまった人は、どのメールのリンクにも反応しなかった
- またphishingサイトへの対応として、無意味なでたらめの個人情報を入力する人もいなかった
- 二人は検索エンジンを使って、そのメールに対応すべきかどうかを決めていた
- 友達に尋ねる人もいた

- 間違った情報を基に判断を下している人がいた
-- phishing webサイトのprivacyアイコンを使って本物かどうかを判定
-- ロゴの画像が本物だから、これは本物のWebサイトだ
-- 数日前に訪れた時と見た目が同じだから本物のWebサイトだ
-- 個人情報を入力した後に、アカウント情報が更新されていたからこれは本物だ


■ Discussion
- 単なるセキュリティ警告は、phishing攻撃に対する教育目的には効果がない
- 漫画調警告が一番効果的だった
-- 文字が少なく、絵が多い.また内容がストーリー化されている
- もしかしたら、漫画よりも、ストーリ化された短篇ビデオの方が効果的かもしれない

- phishing対策のための警告に関する設計原則
1. 教育目的のための訓練を、日常行為の中で行うべき
2. なぜ警告されたのか? その理由を明確にすべき.例えば、何のリスクがあり、何がこの警告を引き起こしたのかをはっきりする
3. 警告は即座に行う.
4. 同じ内容の警告メッセージを使え.
5. 文字だけでなく、ストーリーベースの画像や注釈を使え
6. 警告メッセージは簡潔かつ短いものであること
7. 自身を守るために何をすべきかを明確に与えること


■ Conclusions and Future Work
- embedded training systemの設計と評価
-- 通常の電子メール利用を通じて、phishingの脅威と見分けかたを教育
- 二種類の教育法を設計
- 研究室内で評価、通常のphishingに関するセキュリティ通知とその効果に関して評価

- 単なる通知では非効率
- 提案した二つの手法は、phishingとその回避方法の教育に有用
-- 特に漫画調の手法はもっとも効果的であった

- 教育対象者のスキルレベルにあわせた、より対話的な手法を設計する予定

Posted by z at 03:13 AM

May 27, 2007

Paper: Pictures at the ATM: Exploring the usability of multiple graphical passwords

Pictures at the ATM: exploring the usability of multiple graphical passwords,
Wendy Moncur, Grégory Leplâtre,
Human Factors in Computing Systems(CHI2007), pp.887-894, 2007
ACM Digital Library

複数の暗証番号を覚えるのと、複数の画像パスワードを覚えるののどちらが実現可能性が高いかを調査した.また画像パスワードの記憶を強化する二つの戦略について調査した.その結果、複数の暗証番号を覚えるよりも、複数の画像パスワードを覚える方が実現性が高いことがわかった.

sec-11.png

以下は論文内容のメモ書き


■ Introduction
この研究の目的
- 画像パスワードの記憶可能性の検証
-- 人は複数の画像パスワードを保持できるのか?
-- 記憶保持を改善する方法はあるのか?


■ Background
- パスワードの安全性は「覗き見可能性」「推測可能性」「記録可能性」に依存する

- 画像パスワードは大きく3種に分類
1. Locimetric system (画像内の場所による秘密)
* Cued recallとも言われる.画像内の特定位置とその選択順を秘密情報として使用する.
* 観察可能性/推測可能性/記録可能性の3種の脆弱性がある
* どの程度正確に位置を選択させるかというあいまいさもある
* 事前練習は必要

2. Drawmetric system (秘密画像を描くことによる秘密)
* 好きな画像を自分で描き、それを秘密として利用
* 認証時には、秘密にした画像を描くことで認証
* 正確に描けないといけない.どの度合いにあいまいさがある
* そもそも、人間にとって同じ絵を繰り返し描くことは容易なことではない

3. Cognometric system (画像そのものによる秘密)
- 事前に秘密として設定した写真を、複数の画像群の中から認識し、選択する認証手法
- 想起よりも認識
- イラストを利用し、それを利用してストーリ付けする手法が"PicturePIN"として提供されているが,記憶可能性には限界があるという指摘がある[18]
- ランダム画像は記憶維持に問題があり,個人所有の写真は推測可能性に問題がある[17]


■ Study
- 複数の画像パスワードをどれだけ記憶保持できるか
-- 各ユーザに5つの画像パスワードを与え,四週間後に検査
- さらに二つの実験要素を追加
-- ニーモニック(複数画像によるストーリー付け)が想起を支援するか?
-- 色彩による効果 (画像のbackground色)

- 評価軸
H1: 複数の画像パスワードは複数の暗証番号より記憶維持が可能か?
H2: 複数の画像パスワードはストーリー付けにより想起支援されるか?
H3: 複数の画像パスワード記憶は、パスワード/おとり画像の背景色をつけることで改善されるか?

- 結果
-- H1とH2は有為.
-- H3は有為とはならなかった
-- 背景色による記憶支援は逆効果のようだ.が、それが有為な結果とまではならなかった

- Errorについて
- エラーは三種類に分類
-- 選択順序の間違い: 選択した物はあっているが,その順序が異なる
-- 同じ物を二度選択: 同じ回答肢を二度選択
-- 選択間違い: 回答を間違ってしまった

- 暗証番号のエラーは、選択間違いがほとんど
- 画像パスワードは、選択順序間違いがほとんど
-- 選択順序を順不同にすれば、画像パスワードの正解率は向上する可能性がある.が、安全性とのトレードオフになる

- 「ニーモニック(ストーリー付け)によって、画像自体は記憶できるが,その選択順序までは記憶できない」というユーザーからの回答があった


■ Conclusion
- 5つのパスワードを覚えなければいけない場合において画像パスワードは暗証番号よりも記憶可能性が高いことがわかった
- 長期間の調査により、画像パスワードの場合は暗証番号の場合よりも成功率が高かった.
- 画像パスワードの想起支援のためにニーモニック(記憶術/連想記憶)を使用したら、その成功率はさらに改善された

- 画像パスワードは、複数のパスワードを記憶しなければいけない場面においてUsable Securityとして意味のある技術である


非常に興味深い.複数のパスワードをどうやって記憶管理するかは、認証のおける大きな問題だが,画像パスワードが暗証番号よりも複数の秘密記憶が容易だというのはなんとも言えない部分であった.しかし、5個のパスワードの記憶比較だけでは、まだ何とも言いがたいとも言える.現実的に5個ですむのか? という問題もあるし、そもそも、やはり複数個覚えなければいけないのか? という点もある.

Posted by z at 11:53 PM

May 26, 2007

Paper: Password Sharing: Implications for Security Design Based on Social Practice

Password sharing: implications for security design based on social practice:
Supriya Singh, Anuja Cabraal, Catherine Demosthenous, Gunela Astbrink, Michele Furlong,
Human Factors in Computing Systems(CHI2007), pp.895-904, 2007
ACM Digital Library

現実問題として、パスワードや暗証番号は共有されている.それをふまえた上で、銀行のセキュリティシステムに対するあらたな設計基準(要件)を提案する.という論文.
オーストラリアでの社会学的調査を基にしている.USER-CENTERED Securityの提案でもある

以降、論文内容の走り書き


■USER-CENTERED Security

- ユーザはセキュリティに興味があるのではなく、それをどうやって成し遂げるかに興味がある.だから利便性に目がいくのだ
- 安全性と利便性の「調整」はUser-Centered Securityの本質的な問題
- セキュリティにおける問題の根本は、もはや技術的な問題ではない.むしろ、技術をどう使っていくのかという問題なのである.

- User-Centered Securityの研究は、セキュリティから信用(Trust)へ移りつつある
- 信用の定義は難しいが、人々は信用が損なわれた時に「信用」って大事だよねと口にする

- PrivacyとSecurityは同意語のように扱われることが多いが、User-Centered SecurityにおけるPrivacyは、個人情報の共有を所有者が制御できることを意味する

- 障害者にとってインターネットバンキングを利用する際の最初の問題は口座の開設時に起きる.それは自身を証明する証明書がないことだ.障害者の多くは運転免許証を持ってない.また、身分証明書を得るためにパスポートをとるのも費用がかかりすぎる.


■ Summary and Design Implications

○ Findings from the qualitative study
結論として、3つのグループ(結婚または同棲生活者/原住民/障害者)を対象に調べた結果、ユーザ名と暗証番号/パスワードは共有している

- 結婚又は同棲者の場合は、互いの信頼を表すためにそれらを共有
- 原住民の場合は、容易に銀行にアクセスできない.よって仕方なく共有
- 障害者の場合も、やむをえず介護者や店員と共有

- これらは、3つのグループだけに限定されるものではないようだ
- 遺産相続の問題としても指摘されており、この共有はもはや必要
-- あなたにとって必要なのは、あなたが十分信頼できる「人」である、そういう人がいるなら,その人に自分のパスワードを預けられる.それで十分だ

- 電子メールや携帯電話を共有する場合にも、パスワードの共有は必要であり、それ自体が必要であることが当り前になりつつある

○ Design implications for banking security systems
- Security Systemは、ユーザ名やパスワードが共有されることを前提に再評価すべき
- Security systemは、社会的また文化的な慣習を考慮し、パスワードの共有を可能にするべきであり、その設計においてはパスワードの共有が個別に設定できるようにすべき

- 包括的なアプローチとして、社会的/文化的慣習を基にして設計すべき
- 5つの原則
1. 同意を得ている複数の人が、アカウント情報にアクセスできるよう柔軟であるべきだ
2. personalizeできるようにすべきだ
3. 遠隔地の人が銀行を利用することを配慮すべきだ
4. 障害者のためのアクセシビリティを配慮すべきだ
5. 社会的状況を利用したセキュリティシステムを設計する際には、物理セキュリティと情報セキュリティの連続性を配慮すべきだ

- 経験則に基づく社会学的研究は、文化的な境界を越えたシステムの構築においてますます重要になるだろう
- 多くのコミュニティでは、携帯電話やパソコンの共有(Internet Kiosk)があたりまえになっていく.そういう状況を考慮したセキュリティシステムの設計が重要になる
- セキュリティシステムの設計では、社会的または文化的な慣習を配慮する必要があり、それなしに設計したシステムでは、設計と現実のギャップから安全にならないセキュリティシステムとなってしまうであろう


ふーんという感じ.気付いておかなければいけない点ということだろうが、やっぱり聞きたくなるのは「で、具体策は?」である.

Posted by z at 05:12 PM

reCAPTCHA: CAPTCHAによる人力の有効利用

人間による行為であることを確認する手法として著名なCAPTCHAが、書籍の電子化に応用されることになったそうです

reCAPTCHA: Stop Spam, Read Books

CAPTCHAによって行われている人による文字認識を、単にアクセす制御として使うのではなく、書籍の電子化において読み取れなかった文字の認識/修正にも役立てていこうという試みのようです.

recaptcha.png

CAPTCHAの開発者が主張していることだが、「人間の計算能力を利用した新しい技術「ヒューマンコンピューティング」というのは注目に値すると思う.また、計算機やネットワークはあくまで道具」というスタンスを持つ当方としては、こういった人間の能力をうまく利用する技術というのが今後重要になっていくと考える.

これに関する記事

カーネギーメロン大学,画像認証を書籍デジタル化に活用するサービス - 「reCAPTCHA」 (ITmedia)
「CAPTCHA」技術を応用して書籍のデジタル化を進める新ツール「reCAPTCHA」 (CNET Japan)

概要は以下の通り

- 「reCAPTCHAでは,通常のCAPTCHAによる認証時に,デジタル化できなかった不鮮明な文字画像を表示し,適切な文字を入力してもらう。認証用の文字画像と書籍デジタル化用の文字画像を並べて表示し,ユーザーに両方の文字列を入力してもらい,正しい認証用文字列が入力された場合には,書籍デジタル化用の入力文字列も正しい可能性が高いと判断する。この作業を繰り返すことで,書籍デジタル化における文字認識の精度を高めていく」
- 「reCAPTCHAは、従来のCAPTCHAテストで使われているようなランダムな文字列に加え、もう1語をユーザーに提示する。後者は、コンピュータによるOCRでは認識できなかった未知の単語だ。この仕組みは、ユーザーが従来方式の文字列を正しく解読できるなら、未知の単語のほうも判読できるだろう、という発想に基づいている。von Ahn氏によると、現在reCAPTCHAでは、3人の別の人間がある未知の単語を同じように識別した場合に、正しい読み方だと判断しているという。」
- 個人ユーザは無償で利用可能

CNET Japanの記事によると、Microsoftも「Asirra」と呼ばれるプロジェクトで、犬と猫の写真が並べられた中から、猫の写真を選ぶというシステムを提案しているらしい.


Posted by z at 01:46 AM

May 25, 2007

スパム(SPAM)がなくならない理由

CAN-SPAM法の功罪——スパム撲滅のためにすべきこと - Tmedia TechTarget

なぜ、スパムがなくならないか? その理由は簡単だ.それは経済的理由である。
格安の費用で大多数の人に広告を発信できるから以外のなにものでもない.
そして、もう一つあげるとするならば、その広告(?)内容が違法まがいのものであっても、それによって逮捕されることが極めて少ないという理由もあるだろう.

法律をいくら作っても、その法律の内容をいかに厳しくしてもスパムはなくならないと推測する.なぜならば、法律の制定によってスパムの発信をやめるような良心的なスパム発信業者がどれだけいるかを想像してもらえばよい.つまるところ、もとから「法律なんてくそくらえ」状態の人達に対して法律を新たに作ったり、厳しくしても効果はないのである.そう、法律は法律を破ることになんの疑問を覚えない人達にとってはまったく無力だからだ.

では、どうすべきなのか? 根本的な対策としては、スパムを送信することが経済的に負担になるようにするしかないのかもしれない.が、この実現方法が見つからないのが現状なのだ.
記事では、botnet(ボットネット)の撲滅と電子メールゲートウェイの監視強化が必要だと述べているが... ボットネットの撲滅は現時点では容易ではなく、電子メールゲートウェイを監視せよというのもあまり現実的な解ではないように見える.

その一方で、こんな記事もある

スパムはもう問題じゃない? - ITmedia

今利用できるスパムフィルタで多くのユーザはそこそこ満足しているようであり、あまり問題視しなくなってきているという話らしい.もしこれが本当だとすると、あとはISPや回線業者のみの問題になっていくのだろうか...

Posted by z at 11:17 PM