« 2005年11月 | メイン | 2006年02月 »
2005年。仕事納めです。
色々あった一年でしたが、ようやく形になって来たな、という実感です。
昨日と今日は社内セミナーでした。東京から大阪にスタッフを読んで、来年入社のスタッフの歓迎会と忘年会もかねて。
2日に渡って、どっぷりとWebに漬かる2日間。
来年は定期的にやりたい。Web屋としての基礎体力を強化するのが当面の課題だから。
と、いうことでタイトルと関係なく身内の話をしてしまいましたね。
今年お世話になった皆様に、この場を借りて厚く、熱く御礼申し上げます。
今年もお世話になりました。ありがとうございました。
来年もよろしくお願いいたします。
カテゴリー: ごあいさつ
例えば、WebArrow Center という製品がある。
http://www.namzak.co.jp/products/index.html
この製品が良いとか悪いとかを論じるつもりは全然なくて、コールセンター等においては素晴しいサービス提供が可能になるだろうと思う。
僕がちょっと「恐いなぁ」と思ったのは、こういった仕組みを実現する技術、システムやノウハウが進んでいくと、これを悪用しようとする輩が出てくるからだ。
この製品はもちろん企業が製品として開発したものだから、誰もが簡単に扱うことはできないのだろうが、こんなものもある。
どこまでの操作がリモートでできるのかはわからないが、少なくとも画面をモニタすることは出来るのだろう。
「Active Xや電子メールに添付したexeファイルを通じてユーザーのPCにインストールされる」→「攻撃者はターゲットのPCをモニタできるようになる」
そうなると、SSL証明書の確認だろうがソフトウェア・キーボードだろうが全く意味をなさなくなってしまう。もちろん、ユーザーのPCがウィルス/トロイ/スパイウェアに感染していないことが前提になっているとはいえ、現実的にこういった技術が存在するのだということを知っていますか?
知っているのと知らないのでは、利用の心構えが全然違ってくるのですね。
「感染していると何でもされてしまう」だけでは説明不足、理解不足で、技術的にこんなことが出来る可能性がある、ということはユーザーとして理解しておきたい。お読みの方にも伝えておきたいと思う。
カテゴリー: 駄文・雑文
よく読まないと何のことだかわからないんだが、「単に入力ミスは怖い」という話ではなかったようだ。
午前９時２７分、ジェイコム株式に対し、みずほ証券が６１万円で１株の売注文を、１円で６１万株として発注いたしました。その際、同銘柄は６７万２千円の特別買気配を表示中でしたが、当該売注文により約定成立要件が整い、売買が成立しました。ただし、今回の売注文が大量で初値成立後にも残っていたため、残存分は初値決定により設定された呼値の制限値幅の下限である５７万２千円の売注文として登録され（詳細は後述いたします）、大量の買注文と間断なく順次約定していくこととなりました。その過程で、みずほ証券から当該注文に対する取消注文が発注されましたが、そのような例外的状況において生ずる不具合が売買システムに存在したため、取消しができずにその後も連続対当により約定が順次成立することとなりました。
「不具合」と言い切っているのだから、これは「不具合」なのだろうが、とにかく「ユーザーはミスをおかすものである」前提で「ミスが致命的な影響につながる可能性がある」システムにおいては、あらゆる事態を想定しておかないといけない。
「こんな値が入力がされるわけがない」という凝り固まった考え方や「エラーは自動的に機械の側で修正し、ユーザーはそれを意識させないことがユーザビリティの法則なのだ」といった意識にとらわれること、また逆に「簡単に「警告」を出しすぎてユーザーがろくに読まない習慣がついてしまい、形骸化した「警告」になってしまう」ことなど、考えなければならないことは本当に色々ある。
人間はミスをする。
「ユニバーサルデザインの7原則」の5項目めにも「ミスに対して寛容」(Tolerance for error) という項目がある。何もユニバーサルデザインやアクセシビリティは障害者や高齢者の為だけはなく、あらゆる人間の助けになるのだということを改めて意識したい。
カテゴリー: アクセシビリティ
リダイレクタの存在は脆弱性か？＠高木浩光さん＠自宅の日記
http://takagi-hiromitsu.jp/diary/20051205.html#t
いつもなるほどなぁ、と思いながら読んでいるわけですが...
例えば、リンクがクリックされた時に記録 (ログ) を取りたいだけの場合、リンク先がサイト内にどれだけあるか、そのサイトにどのくらいのトラフィックがあって、どのくらいリダイレクタが叩かれるかにもよるが、例えばそこそこレベルのアクセスのサイトで、リダイレクタ経由対象となっているリンクが100くらいであれば、リダイレクタに渡されたURIをDBと照合してチェックするくらいのことは簡単にできるのではないだろうか?
まず、本当に「設定」で回避することができるのか。リダイレクタの大半は、 任意のサイトへのリダイレクトを目的としている。その場合、このような悪用 をされないようにするには、Refererをチェックするしかない。Refererが空の 場合は、機能しないようにする必要があるので、Refererの送出を止める設定 のブラウザを使用している閲覧者は、そのリダイレクタ経由でのリンクを使えなくなってしまう。
# 「あれ??」と思ったので覚悟して (!?) 反応してみた。
確かに「Referer」なんぞあてにならんから、明らかに違うドメインからのRefererが来たら弾いてもいいけど、あくまでも基本 (本質) は「リダイレクタに渡されたURLが本当にそのサイト内で設定されたリンクかどうかをチェックすること」だと思う。
トラフィックとかサーバー負荷の点でそれが叶わないならば、それこそ、その時にはじめて
だが、本当にリダイレクタが必要な場合はどうすればよいだろうか。
あたりを議論すれば良いのではないだろうか。
# 大抵の場合、それは要らないのだと思う。
カテゴリー: 駄文・雑文
