<前の日記(2004年08月29日) 次の日記(2004年09月06日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 112   昨日: 2365

2004年08月31日

続・MUAのS/MIMEユーザインターフェイスの改良案

一昨日の日記「フィッシング詐欺防止のためMUAのS/MIMEユーザインターフェイスの改良を」では、電子署名されたメールと、署名されていないメールの区別を、色などでわかりやすく表示してはどうかと書いたが、それよりもいっそ、次の図のように、フォルダで振り分けてしまうのがよいのではないだろうか。

一昨日は「メールを表示しただけで署名検証が行われるように」とも書いたが、それより前に、メールの受信と同時に検証も実行してしまってよいのではないか。

同じメールに対して何度も署名を検証する必要がある場面はそう多くはない*1ので、受信時に検証して、フォルダに振り分けてしまってよいように思える。

また、8月7日の日記「事業者が今すぐできるフィッシング詐欺対策」では、VeriSignの発行するメール署名用証明書が「Class 1」であることの不十分さとして次のように書いた。

Class 1とは「電子メールアドレスのみを検証(メールでの証明書発行通知によって認証)」というものだそうだ。つまり、そのメールアドレス宛のメールを確かに受信できたという事実でもって、そのメールアドレスの利用権者本人であるとみなすというものだ。(したがって、(引用時補足:認証局から送信され、当該メールアドレスの到着先に届くまでの間で)メールを盗み取られる状況では、攻撃者がなりすまして証明書を注文し、受け取ってしまうリスクはある。)

(略)

メールの電子署名用にClass 3の証明書が使えるならば、ここに「Sony Marketing (Japan) Inc.」という表示ができる(ただし、受信者が、これがClass 3であることを確認しないと意味がないが。)のではないか。

このリスクを回避するため、受け取った署名メールの証明書を登録して、次回以降は「署名検証・署名者信頼確認済み」フォルダに振り分けるようにしてはどうか。

証明書の登録は、ユーザがメールの内容から本物だと確信したときに手操作で登録する。具体的には、たとえば、メールマガジンの配信を申し込んだときに、自動的に送られてくる配信開始通知メール(事業者側は、この通知メールの送信者アドレスをメールマガジンの送信者と同じにして、電子署名しておく)を受け取ったときに、「署名者信頼確認済み」として登録すればよい。その場合は、タイミングから言って、偽メールである可能性は十分に小さいと確信できるだろう*2

証明書の登録は、Windowsの証明書ストアに登録するのでもよいし、そこまではせずに、MUAがアドレスとフィンガープリントの組を記憶して処理するのでもよいだろう。

そうすると、フォルダ構成はこんな感じになる。

あるいは

署名の検証で問題点が見つかったメールは、別のフォルダに入れるようにするか、通常の受信箱に入れるようにするか、ゴミ箱に捨てるようにするという選択肢が考えられる。 また、メールを受信と同時にフォルダへ振り分ける設定で使う場合には、上の図の方法ではだめなので、次のどちらかの機能を設けることが考えられる。

  • 振り分け条件として「正しく電子署名されている」を選択できるようにする
  • フォルダごとの設定に「このフォルダでは電子署名されていないものは表示しない」を加える

このとき、フォルダへの振り分け条件にはFrom:アドレスを使うようにする。あるいは、署名の署名者アドレスで振り分けるのでもよい。

東京新聞の記事に補足

先週、勤務先で東京新聞の取材を受けたものが、一昨日記事になっていた。

私のコメントとなっている部分のうち、最後の段落(「外国人が作った」〜「と手厳しい」)は、やや私の本意からは外れているので補足しておく。

取材の終盤で、Winnyが日本で生まれたことは技術力の高さとして誇るべきことなのかといった話題になったと記憶している。そこで私が述べたことは次のような趣旨の内容だったと思う。


日本の著作権法は諸外国に比べて強いものだと聞いている。送信可能化しただけで刑事罰が科されるというのは日本とオーストラリアだけだと聞いた。米国では、現行法では民事で争うしかないために、法執行機関の強制捜査が可能なようにする法案が提出されているところだと聞いた。強制捜査ができない国では、IPアドレスが判明しても責任を逃れられる可能性が小さくないために、WinMXのような、IPアドレスを明かしてファイルを交換するソフトウェアであっても、十分にそうした目的の利用ができるのだろう。それに対して日本では、2001年にWinMXユーザが逮捕されたこともあって、そのようなソフトウェアでは、日本ではそのような目的で使うことはできないという認識が高まったのだと思う。そこで、「MXの次は何か」ということが議論されるなかで、Winnyが登場したようだ。米国等では、ここまでの仕組みを備えたものがまだ必要とされていないというだけのことではないか。Winnyの技術は必要がもたらしたものだと思う。


ただ、「法律関係のことは専門の方に確認してほしい」ということも伝えたので、上から法律の話を除いて、調整すると、記事のようになるのだろう。

また、「被告つまり47氏も盛んにこの点を宣伝していた」とあるが、それらの発言が本当に当人によるものであるかどうかは、裁判で争われるところであろうから、私から断定することは当然できない。あくまでも、「47氏による発言とされているものによれば」である。

「新しいビジネス展開などという理屈は後付けだ」というのは、INTERNET Watchの6月28日の記事にレポートされている以下の話と同じ趣旨のものだと思う。

Winnyの可能性についても意見が交換された。瀬川氏がWinnyを活用した分散型バックアップシステムのアイディアを示したほか、九州大学の岡村耕二氏はWinnyのキャッシュがIXに集中しがちなトラフィックを分散する仕組みにも似ていると指摘。合法的に使う技術が出てくれば、今後、Winnyに関連する問題が乗り越えられるのではないかと期待が寄せられた。

(略)

高木浩光氏は、Winnyを合法的に使う方法もあるという議論が47氏を養護(原文まま:擁護の誤記か)するために巻き起こっているが、「それは本当にWinnyでなければできないのか?」を問わなければならないという。(略)

“世界に誇るべきソフト”Winnyに合法的利用の未来はあるのか?, INTERNET Watch, 2004年6月28日

続・最高裁の最高ダサいホームページ

8月15日の日記「最高裁の最高ダサいホームページの続き。

Googleで検索したところ、こんなページが見つかった。

給与課長交渉では、専門業者にシステム監査を行った結果として「基盤となっているロータス・ノーツは、大量かつ複雑なデータ処理が要求される裁判事務と適合しない面があり、ユーザー数やデータ量の増加に伴ってレスポンスがさらに低下することが予想される。」「特大規模庁を含む全庁展開を進めることは再考すべきである」との評価がされたことを受けて、「ロータス・ノーツを基盤とする裁判事務処理システムを全国展開することは中止する」との経過と必要性を明らかにしました。

そのうえで「迅速なレスポンス確保、操作性に優れたシステムにするために、今後、大規模な改修を行う」との回答を行いました。(略)

全司法新聞, 民刑裁判事務処理システムを方針転換, 2004年6月5日

だそうだ*3。裁判事務処理システムの大改修が、最高裁ホームページの改修につながるかは不明だが、「courtdomino」はやっぱりまずいだろう。

判例をWebに掲載することは、論文や書籍にそのURLを記載されることにも意義があるのだから、例えばこういうURLで示せるようにするのがよかろう。

http://db.courts.go.jp/jd/SC/H16-0831-PB3-1/

というかそれが普通だ。たとえれば、書類の識別番号の様式を決めるのに、一人の末端職員の一存で決めるということはしないだろう。URLは、閲覧にあたって外部から指示される書類の識別番号であるのだから、その様式は組織の責任者の決済を経て決めるべきものだろう。

*1 時間がたった後に改めてこれが本物かと検証するという目的で、その機能は依然として必要ではあるが。

*2 もちろん、メールマガジン申し込みサイトからして偽だったらだめだが、それは既にフィッシング詐欺にひっかかっている場合だ。

*3 スケーラビリティに乏しいという理由はベンダーからすれば反論の余地もありそうな予感がするが。

検索

<前の日記(2004年08月29日) 次の日記(2004年09月06日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|
<前の日記(2004年08月29日) 次の日記(2004年09月06日)> 最新 編集