<前の日記(2004年08月28日) 次の日記(2004年08月31日)> 最新 編集

高木浩光@自宅の日記

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

2004年08月29日

フィッシング詐欺防止のためMUAのS/MIMEユーザインタフェイスの改良を

8月7日の日記「事業者が今すぐできるフィッシング詐欺対策」で、事業者のニュースレターやメールマガジンに電子署名してはどうかと書いたが、

MUAがもう少し、署名の証明書の発行先をわかりやすく表示するよう、ユーザインターフェイスを改善しないと、phishing詐欺に遭うような人たちには本物確認が難しすぎるかもしれない。

とも書いた。

Outlook Expressの場合、8月7日の日記にも書いたように、正しく署名されたメールと、署名されていないメールとの違いは、署名されていることを示すマークの有無だけであるが、メールが改ざんされている場合や、無効な証明書で署名されている場合は、背景が黒のギョッとするような警告画面が現れるようになっている。

以下の図は、署名者のメールアドレスと異なるメールアドレスを送信者として偽っている場合の画面だ。「送信者と署名者が合いません」と表示されている。

別のMUAではどうか。

Becky! 2.11.02 に付属の「Becky! S/MIMEプラグイン Ver.1.01」では、以下の図のように、「正当性が検証されました」と表示されるだけで、From: のアドレスとの一致検査は行っていないようだ。ユーザが自力で目視確認する必要がある。これは改善の余地があると言える。

Winbiff Version 2.43 PL1 では、以下の画面が現れた。

2行目に、「電子署名に使われた証明書のメールアドレスとメッセージの発信者がことなります」と警告が出ているのだが、ウィンドウの幅が狭すぎて右端が切れており、スクロールしないと肝心の言葉を読めない。また、これが警告であることがちょっとわかりにくい。いちおう×印はついているが、もう少し結論だけわかりやすく表示することはできるのではないか。

また、Becky!もWinbiffも、ユーザが自力でメニュー操作をしない限り、署名の検証は行われない。Outlook Expressのように、メールを表示しただけで署名検証が行われるようにすることはできないだろうか。

また、Outlook Expressのように署名の有無をマークで示すだけでなしに、ヘッダ表示部の色をかえて、署名なしならば赤、署名ありならば緑にするといった工夫*1もできるのではなかろうか。

最小限の責任だけで済ます携帯電話会社たち

こういう記事が出ていた。

出会い系サイトなど一部の携帯電話サイトにおいて、携帯電話の機種などを識別する個体識別番号や製造番号をサイト内に表示し、あたかもユーザー個人を特定したように見せかけて架空請求を行なうケースが確認されているとして、携帯電話各社が注意を呼びかけている。(略)

NTTドコモは次のように述べている。

  • 個人情報を入手していると偽って請求行為を行うサイトについて, NTTドコモ

    弊社のシステムにおいては、携帯電話の製造番号(FOMAをご利用の場合はFOMAカード識別番号を含み、以下、「携帯電話情報」と呼びます)が接続先に送信される場合、必ず事前に確認画面が表示されますので、お客様がこれに承諾されない限り、「携帯電話情報」が接続先に送信されることはありません。

これはその通りで、NTTドコモは他の携帯電話事業者に比べて、プライバシー配慮への考え方が(相対的に)しっかりしていると言える。

しかし、続く説明はこうなっている。

また、お客様の承諾のもと「携帯電話情報」が送信されたとしても、その中にはお客様の携帯電話番号、メールアドレス、住所、氏名など、お客様の連絡先についての情報は含まれておらず、また弊社から開示することもありません。

嘘を書かないよう慎重に書かれているが、書くべきことがあえて書かれていない。本当に顧客の安全を想う企業ならば、次のように説明するはずだろう。


お客様の承諾のもと「携帯電話情報」が送信されたとしても、その中にはお客様の携帯電話番号、メールアドレス、住所、氏名など、お客様の連絡先についての情報は含まれていません。

弊社からそれらの情報を開示することはありませんが、お客様が、iモードサイトに対して正規の目的でそれらの情報を開示し、かつ、「携帯電話情報」を送信し、そのサイトがお客様に断りなくそれらの情報を第三者に提供していた場合には、その第三者のサイトにアクセスしたときに、「携帯電話情報」を送信することは、お客様の連絡先についての情報も第三者に知られることになります。

個人情報をiモードサイトに提供するときは、提供先が信頼できる相手であるかを十分に見極めるよう注意してください。

また、「携帯電話情報」を接続先に送信するか否かの確認画面が現れたときは、接続先の運営者が信頼できる相手であるかを十分に考慮して、信頼できない段階では、送信をキャンセルするようにしてください。確認画面は以下の図のようになっています。

(確認画面の写真)


ボーダフォンは次のように述べている。

  • 携帯電話の端末シリアル番号(製造番号)を表示して請求する出会い系サイト等にご注意ください。, ボーダフォン, 2004年8月26日

    このボーダフォン携帯電話の機種や端末シリアル番号は、Vodafone Live!ウェブの接続先コンテンツを正しく表示するために接続先ウェブサイトに通知している情報です。

    なお、この情報は、お客様自身がユーザーID、製造番号などの通知設定をしていた場合に限り通知されますが、これら通知される情報には、お客様個人を特定し得るような携帯電話番号、メールアドレス、住所、氏名などは含まれておらず、これらのお客様個人を特定し得るような情報を弊社から開示することはありません。

    (略)

    安心してボーダフォンをご利用いただくために、みなさまのご理解とご協力をお願いいたします。

顧客の安全を真に願う企業ならば、ここで「ユーザーID、製造番号などの通知設定」の確認・変更方法を説明するはずだろう。

ここで説明しないのはまことに理解に苦しむ。説明したくない事情があるのだろうか。

その設定をする方法の説明はサイトには見つからなかった。

なお、au、ツーカーからは、この件に関する告知はみあたらない。

携帯電話のコンテンツ業界はサブスクライバーIDをどう認識していたか

検索してみたところ、2001年に書かれたと思われる「モバイル・コンテンツ・フォーラム会員企業の意見整理」というページが見つかった。これは、「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書(案)に関する意見書として用意されたものだったようだ。

そこには次のような意見が出ている。

Q7(P65) 通信キャリアのコンテンツプロバイダ等に対するユーザIDの提供に関しては、問題解決の方向性は正しいか。

モバイル・コンテンツ・フォーラム会員企業の意見整理, モバイルコンテンツフォーラム

という問いに対し、

一部方向性をかえるべきである

ブラウザをcookie対応にする、IP接続にするなどの別の方向性を検討するべきである。


一部方向性をかえるべきである

IDの提供そのものは正しいと思うが、コンテンツプロバイダにそのまま提供する点には危惧を感じる。ID自体は、第三者機関(公益機関 等)が管理し、悪意のあるプロバイダからユーザを保護する等の手段を講ずるべきと感じる。


全面的に正しい

ユーザーIDの公開に関しては、ユーザー保護の観点から行くとあまり望ましくはない。しかし、コンテンツプロバイダーからすればもっともほしい情報であることは確かで、携帯コンテンツ市場が活性化する事が望まれる。


全面的に正しい

公式サイトの掲載しているコンテンツプロバイダ、一般サイトであっても個人情報の保護を適切に行っているコンテンツプロバイダに対しては、ユーザIDを提供することは正しい。

と、サブスクライバーIDの無条件送信の問題点を認識している意見が多い。しかし、

全面的に正しい

IDが判別可能になることで、様々な不正利用を防止する事ができるため、早く公開すべきだと考えている。

とかいう馬鹿もいたようだ。不正使用を増やすことにもなることに理解が及んでいない。

*1 色弱者への配慮として別の表現も併用するのがよい。


<前の日記(2004年08月28日) 次の日記(2004年08月31日)> 最新 編集

最近のタイトル

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|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
<前の日記(2004年08月28日) 次の日記(2004年08月31日)> 最新 編集