<前の日記(2003年11月01日) 次の日記(2003年11月03日)> 最新 編集

高木浩光@自宅の日記

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

2003年11月02日

日本はまだ「レベル0」の段階

CNETの記事「英当局、企業に対して「なりすまし」の警告」によると、

先月、NatWest、Lloyds TSB、Barclays、Citibank、Halifaxの各銀行で、各々のインターネットバンキング利用者にある電子メールが届いた。利用者の目には、口座を持っている銀行から来たように見えるその電子メールには、銀行公式サイトに模した偽造サイトに利用者を導くためのリンクが貼られていた。そして、さらにその偽造サイトは、利用者のユーザー名とパスワードを聞き出すためにつくられたものだった。

CNET, 英当局、企業に対して「なりすまし」の警告

のだそうで、6月2日の日記7月19日の日記にも書いた脅威が、英国では烈しく現実の事態となっているようだ。日本では当分先のことなんだろうか。日本はまだ、架空請求とかオレオレ詐欺とかいう、「レベル0」の段階。それに誰もひっかからなくなったときに起きはじめるのだろうか。

ちなみに、「乱数表があるから大丈夫」というのがあてにならないことは、7月22日の日記で書いたとおり。自分の使っている銀行の乱数表システムが大丈夫かどうかは、誰でも自分で確かめられるので、やってみるとよい。

「なりすまし」に対する基本的な予防措置として、各社が手始めにできることは、社名を使ったあらゆる組合せのドメイン名を手に入れることだ。

CNET, 英当局、企業に対して「なりすまし」の警告

それはなんだか違うんでないか? ドメイン業者はますます儲かりますな。

NCISの報道官は、ZDNetUKに対して、ユーザーは郵便システムと同じくらいは電子メールシステムについての知識を持つことが必要だと語った。「切手にはミシン目が入っていることや、業務用封筒の外見的特長については皆が知っている。だから、もし企業から届いた封筒が手書きだったら『ちょっとおかしいぞ』と考える。ところが電子メールの場合は、異常を知らせる目印があるのに、皆はその目印の見つけ方をまだ習得していない」(同報道官)

CNET, 英当局、企業に対して「なりすまし」の警告

目印って Received: のこと? そんなのを見るより、メールを信用しないことを徹底して、WebにアクセスしてSSLのサーバ証明書を確認するようにすればよい。

関連記事: 「新生銀行ネット・バンキング、Google新サービスの影響で意外なトラブル」だそうだが、そもそもポップアップでログイン画面を出すような銀行は、顧客を上のような詐欺に騙されやすくしている。このことはもう何年も前から言っているのに、いっこうに改善されない。新生銀行が今回のGoogleツールバー対応として、小手先の修正にとどめるか、ポップアップウィンドウをやめてアドレスバーを隠さないという本質的な解決を図るかが見ものだ。日経コンピュータにもそのくらいまで突っ込んで欲しいところ。まあ、事件が起きてからしか書かないだろうけど。

メールマーケな人々はOutlookに敵対心を抱くか

「顧客に選ばれるEメールマーケティング」という本の著者として知られる(と聞く)鶴本浩司氏から、「読めないメールが続出!?最新の「Outlook 2003」とその応急対策」という記事が出ていた。6月14日の日記にも書いた、Office 2003のOutlookではデフォルト設定で外部コンテンツの参照が遮断される件が、いよいよ現実になってきたという話だ。さて、この事態をメールマーケティングのコンサルタントはどのように語るだろうか。

ついに「あの新機能」を搭載したソフトウェア「Outlook 2003」がリリースされた。...(略)

気になっていた「あの新機能」とは、「プライバシー保護機能」である。本来、HTML メールは、開封したりプレビューした際に、 Web サーバーから画像やロゴをダウンロードして表示する。ところが今回リリースされたバージョンの既定(デフォルト設定)では、このダウンロードを阻止する設定になっている。

これはどういうことかというと、メール本文中の画像部分は表示されないということだ。それがたとえ許諾を得た(オプトイン手続きを経た)メールでも、 HTML メールである限り例外ではない。その代わりにその画像部分に次のようなメッセージが表示される。 (略)

鶴本浩司, 「読めないメールが続出!?最新の「Outlook 2003」とその応急対策」, Japan.internet.com Webマーケティング

「これはどういうことかというと」に続く説明は、期待される「なぜプライバシー保護なのか」ではなく、結果としてどのような現象が起きるかが書かれているにすぎない。はたしてこの著者がこの機能の意義を理解しているのかどうか、この文面からではわからない状態になっている。むろん、その道のプロなのだから理解なさっていると解釈するのが妥当だろう。単に、わかりきったことだから書いてないということなのかもしれない。

しかし、この記事の読者であるマーケティングに携わる人たちもそれを理解しているかは疑問だ。消費者あってのマーケティングであることは鶴本氏も説いてきたところだと思うが、現場でマーケティングに携わる人たちが、わけもわからず「プライバシー保護機能」に反感を覚え、ユーザに適切な説明をすることなく機能をオフにすることを推奨したりしないか、心配になる。鶴本氏の記事にも反発の感情が見え隠れする(「唖然とする」「ふう…」「文章にするだけでもウンザリする作業だが」「例の憂鬱な文字列」などの表現から)だけに心配だ。ちなみに、冒頭の「リリース」の部分でリンクされている記事「『Outlook 2003』でメール開封率はどう変わる?」という海外記事では、米国のメールマーケティング業界が冷静に受け止めていることがうかがえる。

鶴本氏は、

それがたとえ許諾を得た(オプトイン手続きを経た)メールでも、

鶴本浩司, 「読めないメールが続出!?最新の「Outlook 2003」とその応急対策」, Japan.internet.com Webマーケティング

と述べているが、許諾といっても、単なるオプトインとは話が違う。Webバグによる個人特定を含めて許諾しているかどうかは疑問だ。そこまで説明して同意を得ているメールマガジンがどれだけあるだろうか。

「開封率」について次のようにある。

もし読者(ユーザー)にとって関係性の薄いメールだったとしたら、果たして前述のような煩雑な作業をしてくれるかは大きな疑問だ。それは今後、加速的に低下していくであろう開封率からも読み取ることができるだろう(向こう1年間でマーケティング担当者が愕然とする場面でもある)。

鶴本浩司, 「読めないメールが続出!?最新の「Outlook 2003」とその応急対策」, Japan.internet.com Webマーケティング

開封率が低下していくというよりも、今までの「開封率」と称するものが真の開封率ではなかったというだけだろう。なにしろ、プレビューしただけで開封としてカウントされていたのだから。「Webバグを使った開封率計算」という、ITバブル期に発明されたメールマガジン業者の武器が、じつは実態からかけ離れた計算だったことが露呈して、ようやく正しい開封率に近づくということだ。

いよいよ、いかにして顧客のエンゲージを得るかが重要になってくる。保有するアドレスの絶対数(クアンティティ)崇拝の時代は終わり、これからは質(クオリティ)重視の時代である。

鶴本浩司, 「読めないメールが続出!?最新の「Outlook 2003」とその応急対策」, Japan.internet.com Webマーケティング

そんな時代があったことに唖然とする。人々のプライバシーはそういう人たちの手に預けられている。

関連記事: 「ウェブパーソナライゼーションを酷評するレポート発表

「Beyond the Personalization Myth(パーソナライゼーション神話を超えて)」と題する米Jupiter Researchによるレポートは、収集した情報に基づいて顧客毎に提供する情報を変えるウェブサイト・パーソナライゼーションについて、「高価で非生産的だ」とこき下ろしている。...(略)

同レポートは、パーソナライゼーションには効果がないだけでなく、驚くほどコストがかかると批判している。 ...(略)

同レポートには、パーソナライゼーション計画が期待外れに終わった企業の逸話が散りばめられている。

CNET, ウェブパーソナライゼーションを酷評するレポート発表

という話もある。

温泉のRFID腕バンドは回収する方式のままがいい

日経コンピュータの「温泉でのICタグ応用は確立、今後は温泉の外にも展開」という記事には、以前から実用化されていたRFIDタグの公衆浴場での利用について、

腕時計型のICタグは現在回収しているが、今後はそれを利用者に持ち帰ってもらい、会員カード代わりにする。

日経コンピュータ, 温泉でのICタグ応用は確立、今後は温泉の外にも展開

とある。

公衆浴場でRFIDタグを使うのは合理性が高い。元々、ロッカーの鍵を腕に巻くのであるから、それをコーヒー牛乳などの決済にも使うのは都合がよい。浴場を出るときに返却するのであれば、個人追跡はその場限りで途切れるのでプライバシー懸念は最小限に抑えられる(入場時や退場時に住所氏名を書かないのであれば)。

それを「持ち帰ってもらい会員カード代わりにする」という。それをやって本当に利益があるのだろうか。

ちなみに、ロッカーの鍵としてRFIDタグを使う場合、リプレイ攻撃によるなりすましを防ぐ必要がある。現在のところリーダ関連製品が普及していないからさほど問題にならないが、そうした機器が普及した暁には、そうした攻撃の可能性が無視できなくなるだろう。この記事には、

ソニーのFelicaをベースにアプリケーションを構築している。

日経コンピュータ, 温泉でのICタグ応用は確立、今後は温泉の外にも展開

とあるので、リプレイ攻撃を防げるような暗号技術が使われているのだろう。RFIDタグとRFIDカードとの境界がなくなってきているということだろうか。

さらには、

「腕時計型ICタグを施設内だけでなく、他の箱根にある施設でも使えるようにしたい。小田急などの乗車券も兼ねられるようになっても面白いと思う」と講演の最後に述べた。

日経コンピュータ, 温泉でのICタグ応用は確立、今後は温泉の外にも展開

とある。FeliCaを使うのであれば、カードアプリケーションを別々にすれば、温泉利用と小田急利用をまたがってトラッキングされないようにできるかもしれない。ただし、FeliCaがアンチコリジョン用に固定のIDを使用していないのならばだが。

検索

<前の日記(2003年11月01日) 次の日記(2003年11月03日)> 最新 編集

最近のタイトル

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|
<前の日記(2003年11月01日) 次の日記(2003年11月03日)> 最新 編集