紛らわしいメー ル
先ほど某大手銀行からメールが来た。まあ、口座を持っているので来ることに問題はないのだが題名が「便利なアプリのご紹介」となっている。当然、フィッシングメールを疑ったのは自分だけではあるまい。
注意して開いてみてテキストメールであることを確認し、リンク先や送信者（詐称できるが）を確認してみてどうも本物らしいと判断した。しかし、セキュリティがらみで問題になっている昨今、もう少し何とかならなかったのかと思う。自分がそういう業者ならこのメールをぱくって、ちょっと弄ったメールを送りつければ犠牲者をざくざく釣り上げられると思うがどうだろうか。
IDを保存できたり、明細が簡単にダウンロードできたり、いつもの振り込みが簡単にできるのは、顧客の利便性を向上させる経営努力とは思うが、その告知方法として電子メールはどうだろう。ログインした顧客にブラウザ上で表示するだけではいけなかったのだろうか。月に一度もログインしない顧客にとって明細が簡単にダウンロードできたり、振り込みが簡単にできるのは利便性の向上よりもセキュリティ上のリスクと思うのだが。
私は金融機関にとっての電子メールは単なる通知（ログインした、入金したとか）以上の機能を持たせてはいけない時代になったと考えている。どうしても電子メールで告知がしたいのなら、単なる通知メールの末尾に告知を追加すれば良い。入金をしていないはずの入金通知メールのリンクは（少なくとも今回の告知メールよりは）顧客の警戒を呼ぶだろう（と思ったが逆だろうか、意図しない入金はクリックを誘発するかもしれない、実際にはどちらであろうか。やはり通知以上の機能は無い方が無難だ）。
正直、電子メールはその設計思想の古さから今の時代にそぐわず、またその設計思想の古さ故にサーバーに対してそれほど負担がかからずお手軽便利だ。つまり、前者故に危険で、後者故に利用者はなくならないだろう。
以前、近い将来において社内システムに電子メールは使用しない方がいいという記事を書いた。そのときの予想は今のところ当たりそうにない。進むべき方向としては間違っていないと今でも考えているが、人は便利さを死んでも手放せないのかもしれない。
まとめ
１：重要情報（金銭など、今では金はただの情報だ）を扱う機関は電子メールの使用は単なる通知のみに絞った方がいい。
２：どうやら、ひとは便利さを死んでも手放さないものらしい。
３：電子メールが放棄されるには具体的な（以前書いたような）システムが出てこなければならない（積極的に放棄する動機付けはない）。
注意して開いてみてテキストメールであることを確認し、リンク先や送信者（詐称できるが）を確認してみてどうも本物らしいと判断した。しかし、セキュリティがらみで問題になっている昨今、もう少し何とかならなかったのかと思う。自分がそういう業者ならこのメールをぱくって、ちょっと弄ったメールを送りつければ犠牲者をざくざく釣り上げられると思うがどうだろうか。
IDを保存できたり、明細が簡単にダウンロードできたり、いつもの振り込みが簡単にできるのは、顧客の利便性を向上させる経営努力とは思うが、その告知方法として電子メールはどうだろう。ログインした顧客にブラウザ上で表示するだけではいけなかったのだろうか。月に一度もログインしない顧客にとって明細が簡単にダウンロードできたり、振り込みが簡単にできるのは利便性の向上よりもセキュリティ上のリスクと思うのだが。
私は金融機関にとっての電子メールは単なる通知（ログインした、入金したとか）以上の機能を持たせてはいけない時代になったと考えている。どうしても電子メールで告知がしたいのなら、単なる通知メールの末尾に告知を追加すれば良い。入金をしていないはずの入金通知メールのリンクは（少なくとも今回の告知メールよりは）顧客の警戒を呼ぶだろう（と思ったが逆だろうか、意図しない入金はクリックを誘発するかもしれない、実際にはどちらであろうか。やはり通知以上の機能は無い方が無難だ）。
正直、電子メールはその設計思想の古さから今の時代にそぐわず、またその設計思想の古さ故にサーバーに対してそれほど負担がかからずお手軽便利だ。つまり、前者故に危険で、後者故に利用者はなくならないだろう。
以前、近い将来において社内システムに電子メールは使用しない方がいいという記事を書いた。そのときの予想は今のところ当たりそうにない。進むべき方向としては間違っていないと今でも考えているが、人は便利さを死んでも手放せないのかもしれない。
まとめ
１：重要情報（金銭など、今では金はただの情報だ）を扱う機関は電子メールの使用は単なる通知のみに絞った方がいい。
２：どうやら、ひとは便利さを死んでも手放さないものらしい。
３：電子メールが放棄されるには具体的な（以前書いたような）システムが出てこなければならない（積極的に放棄する動機付けはない）。
HTC Sync Manager Update v3.1.13.0
先日、HTC Sync Managerのアップデートが来ていたので更新した。前回の更新では再び端末を認識しないようになりエンバグしていたのだが、修正されたようだ。前回のようなエンバグは何も考えていない担当者が以前のソースをコピペすると起こりやすいのだが、実際のところはどうであったのだろうか。
環境
HTC Sync Manager v3.1.13.0
HTC J Butterfly
Android v4.1.1
Software number v1.39.970.3
今回の更新はパスする必要がなさそうで何よりである。
環境
HTC Sync Manager v3.1.13.0
HTC J Butterfly
Android v4.1.1
Software number v1.39.970.3
今回の更新はパスする必要がなさそうで何よりである。
Firefoxが完全に止まるようになった件
以前、firefoxがjavascriptの処理待ちで止まるようになった記事を書いた。そのとき書いたように、Firefoxのweb記述は止まるのだが、処理待ちのウインドーが出てそこで処理を強制停止させれば問題ないと言うことも書いた。
先日Firefoxをupdateして（v30.0）、今度は処理待ちのウインドーも無限ループに入る（もしくは以前よりずっと長く待つ）様になったので記述しておく。
環境
Windows7 x64 Ultimate
Firefox v30.0
javascriptの処理待ちの話はその後、どこかでjavascriptの処理を自動で始めない内容に設定すると起こりやすいときいたのだが、確かに自分もその設定に変更している。最近は正規のサイトも改ざんされかねないし、こちらがちゃんとしていても変なところに飛ばされる可能性も否定できないから。そういうわけで、通常設定の人には発生しない話である可能性があることを始めに断らせてもらう。
現象は単純な話で、サイトに訪れる->（ある程度信用しているサイトでは）javascriptの処理が始まるがどうやら無限ループに->時間がかかっている旨を通知するウインドーが出る。->そのウインドーが応答しない。
プログラム的に言えばそのウインドーがDoModalになっていてこいつを消さないと先へ行けないようになっているのだがそれが無限ループに入る、という初心者的なプログラムになっている（実際のところはデッドロックしているのだと思うが）。
以前も書いたが、Firefoxは絶賛迷走中なので見切りたいのだが他に良いものがないのが現状だ。どうにかして欲しいのだが。
まとめ
１：Forefox v30.0は（設定次第で？）javascriptの処理でデッドロックする。
２：javascriptを自動実行するように（初期状態に）戻せば直るかもしれない。
2014.12.6追記
解決したのでこちらを参照。
先日Firefoxをupdateして（v30.0）、今度は処理待ちのウインドーも無限ループに入る（もしくは以前よりずっと長く待つ）様になったので記述しておく。
環境
Windows7 x64 Ultimate
Firefox v30.0
javascriptの処理待ちの話はその後、どこかでjavascriptの処理を自動で始めない内容に設定すると起こりやすいときいたのだが、確かに自分もその設定に変更している。最近は正規のサイトも改ざんされかねないし、こちらがちゃんとしていても変なところに飛ばされる可能性も否定できないから。そういうわけで、通常設定の人には発生しない話である可能性があることを始めに断らせてもらう。
現象は単純な話で、サイトに訪れる->（ある程度信用しているサイトでは）javascriptの処理が始まるがどうやら無限ループに->時間がかかっている旨を通知するウインドーが出る。->そのウインドーが応答しない。
プログラム的に言えばそのウインドーがDoModalになっていてこいつを消さないと先へ行けないようになっているのだがそれが無限ループに入る、という初心者的なプログラムになっている（実際のところはデッドロックしているのだと思うが）。
以前も書いたが、Firefoxは絶賛迷走中なので見切りたいのだが他に良いものがないのが現状だ。どうにかして欲しいのだが。
まとめ
１：Forefox v30.0は（設定次第で？）javascriptの処理でデッドロックする。
２：javascriptを自動実行するように（初期状態に）戻せば直るかもしれない。
2014.12.6追記
解決したのでこちらを参照。