DELLの20′ UXGAモニタ
送料込み5万5千円弱の特売でDELLの20インチのUXGAモニタを1台買いました。非常に満足しています。EIZOのL565のデュアルヘッドだったのですが、このDELLのLCDの画質はL565より良いです。これを2台かっておけばよかったと後悔しています… また安くなるまで待つか…
追記：DELLはUXGA(1600×1200)とEIZOはSXGA(1280×1024)なので同列で画質を比較するのは多少問題ですね。
カードの暗証番号入力を拒否できるか?
これのつづきです。
世の中は防犯カメラが100%設置されている銀行のATMでさえ暗証番号入力は危ないので生体認証を採り入れようか、という時にも関わらず加盟店のレジでクレジットカードの暗証番号を入力させるという時代錯誤の加盟店が急増中に思えます。
レジで清算する際には真後ろや真横に他人が待っていて暗証番号を見るのは非常に簡単です。レジには防犯カメラが付いている事も多いと思いますが、その映像の管理は銀行等のATMに比べて十分安全に管理されているか?には大きな疑問符が付くと思います。
# 通上、利用規約上は暗証番号の入力を伴う取り引きの全て責任は
# 利用者にある、と書かれているはずです。ただし、判例などでは
# 明らかに不正利用と思われるケースでは暗証番号の入力があって
# も被害が保証される場合もあるようです。
そこで三井住友VISAカード、セゾンMASTERカード、ニコス郵貯VISAカードで暗証番号を拒否しサインで利用することは可能か聞いてみました。3社ともカードの暗証番号入力を拒否してサインで利用できます、と回答がありました。
セゾンにはより詳しく調べて頂き、判っている限りではJRのみどりの窓口以外は暗証番号を入力せずに利用できる、と詳しい回答を頂きました。答えて頂いた方の説明によるとJRのシステムが暗証番号無しで取り引きが出来ないように作られてしまった事が原因のようです。
# これは許される間違い(?)なのかな…
クレジットカード利用時に無意味かつ不必要な電話番号の記入を強要する加盟店でも電話番号を書いたことはほとんどないのですが、こんどは暗証番号入力を拒否する手間が増えるとは…
多分他のカード会社も同じ様に取り引き時の暗証番号入力は拒否できると思われます。クレジットカードの暗証番号記入に不安を覚える方はどんどん暗証番号入力を拒否しましょう。
英国では建築家が不幸?
建築家が不幸(幸福ではない)とは意外でした。
英国の雇用確保のための教育・訓練・資格取得の推進団体である「City & Guilds」の実施した2005年の「幸福度」調査で、建築家は最も幸福でない職能という結果が出た。
IT関係の職能はどうだったか気になりますね。この記事の出どころはここだったので見てみると、
IT Specialistsは満足度5%で堂々の下から4位… よく見ると同じ5%でも僅差で6位のようですね。弁護士よりましなようです ;)
「非常に満足している」人の割合なので感覚的には日本でアンケートしてみても同じかも知れませんね。
このサイトに載っていたTipsが気に入りました。
How to be happy in the workplace
* Start off by being positive
* Remember that every problem can be solved
* Enrich your working environment with photos
and flowers
* Have a laugh
* Start the day with a natter or gossip
仕事場で幸せになるには *楽観的にはじめよう *どんな問題も解決可能な事を覚えておこう *写真と花で仕事場を飾ろう *笑いましょう *無駄話か噂話からその日をはじめよう
カード暗証番号入力の問題
クレジットカード利用時に不必要な電話番号の記入を強要するカード加盟店は昨年の記入された電話番号を悪用した事例のおかげでやっと無くなりました。カード規約には書名でサービスを利用できると明記されているので私はいつも電話番号記入は拒否していました。電話番号の記入を求める加盟店はまずカードの署名と伝票の署名が一致しているか確認していませでした。海外では署名を確認しない、ということはあり得ないのですが日本では確認しない加盟店の方が今でも多いくらいです。署名を確認されないと私は非常に不満なのですが、署名を確認されると不満に感じる利用者も多い(?)ということかも知れません。
@Wiki
とりすがりに@WikiというWikiを見付けました。
IEだけでなくMozillaでもしっかりWYSIWYG出来ているところが素晴らしいです。
http://www1.atwiki.jp/test/?cmd=edit&page=NEW
このWikiは無料サービスですが、よく調べるとダウンロードできるようになっているのかも知れませんが、オープンソースでは無い(?)ようです。
グーグルで検索するとJavaScriptのWYSIWYGエディタは結構オープンソースであるようですね。GPLの物もあるのでPukiWikiに付けるのはよいかも知れませんね。
http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html
@WikiはソースコードみるとGPLのEpozを利用しているようです。Epozのデモサイトも用意されています。こんど使ってみよう :)
# @Wikiは学生さんが作られたサイトの様ですがWikiのベースはPukiWikiの様に
# 思えます。GPLの場合、完全なソースコードの公開義務があることを認識した
# 上で作られているか多少不安…
# epoz自体がi18nを意識した作りになっているのですが、日本語のメッセージ
# ファイルはEpoz 0.9.0には無いですね。是非コントリビュートして欲しいで
# すね :)
リファラスパム
このブログはそれほど人気がある訳でもないのでトラフィックは月あたり数百MBくらいでした。しかし先月から度重なるリファラスパムにあっています… その結果、トラフィックが1.5GBくらいになってしまいました。
私が受信するスパムメールは毎日数百通(webmaster等の管理用のメールアドレスからの転送、MLからのメール含む)です。しかも最近はHTMLメールにイメージファイルを埋め込んで送って来るスパムがかなり増えました。スパムメール、リファラスパムで相当なネットワークトラフィックが無駄に消費されていると思います。P2Pは使った事が無いのでどの程度トラフィックが発生するかは知りませんが、スパムだけでも膨大な無駄になります。
このブログのリファラ表示機能も無効化することにします。
はじめてのPHP言語プログラミング
まだいつ発売になるか私も知りませんが「はじめてのPHP言語プログラミング」(技術評論社)というタイトルでPHP入門書を書きました。4月末から5月に書店に並ぶと思います。
Webサイト構築の為の入門書ではなくプログラミング言語の入門書、読み終わった後もリファレンスとして使える本になるように書いたつもりです。どちらかと言うと既にプログラミング言語を習得されてPHPもマスターしたい方向けかもしれません。320ページで全て説明するのは難しく、ばっさり説明を省略している部分もありますが、言語仕様の解説部分では出来るかぎり妥協しないようにしています。どんな本を書く場合も同じと思いますが「自分が欲しい」と思える書き方、内容になったと思っています。
宣伝にはまだ早すぎですが、書店で見掛けたら買ってください :)
DNSキャッシュ汚染
BINDのバグの多さに辟易して2000年にdjbdnsに乗り換えてからBINDを使っていないのですがDNSキャッシュ汚染問題はまだまだ続いているようです。
DNS ‘pharming’ attacks target .com domain で広範囲なDNSキャッシュ汚染攻撃があったとニュースになっています。
SANSのブログによると
1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)
と、1,300以上のDNSキャッシュ汚染(DNS cache poisoning)エントリが見つかったと書いています。
セキュリティに詳しい方には古い問題ですがなかなか改善されていません。私自身も昨年、日本のあるISPにDNS設定の問題を連絡したのですが、知合いのシステム管理者からISPから変更の連絡あったと聞いていないのできっとまだ改善されていないと思います。ISPでさえもこのレベルなので日曜DNS管理者(私もDNS管理を専門としていないので日曜DNS管理者ですが)が設定したDNSサーバに問題があっても当然かもしれません。
これから書く事を理解するためにはDNSサーバとDNSキャッシュを明確に区別する必要があります。example.comドメインを例に説明します。example.comのDNSサーバはexample.comドメインに権限を持ち、www.example.com, ftp,example.com等、example.comのサブドメインにホストを登録できます。一方、DNSキャッシュはDNS問い合わせをクライアントに代わって行うサーバです。DNSキャッシュサーバはトップレベルドメインから目的のホストのIPアドレスを取得するまで再帰的にDNS問い合わせを行い、結果をキャッシュします。ISP等が”DNSサーバ”と呼んでいるのは通上はDNSキャッシュサーバです。BINDでは再帰問い合わせに答えるサーバがDNSキャッシュサーバになります。
DNSサーバを構築する場合、DNSサーバとDNSキャッシュは別サーバとしなければならない、のですがBINDの悪いデザインのためDNSサーバとDNSキャッシュが同じサーバに設定できるようになっています。しかも、古いBINDではデフォルトで全てのクライアントから再帰問い合わせを受け付けるように設定されていました。このため、間違ったDNSサーバ設定方法ドキュメントが大量に再生産／再利用され現在でも間違った設定のDNSサーバが大量に存在します。
example.comドメインでDNSサーバとDNSキャッシュが同じDNSプログラム(BINDなど)で実行されていると、DNSキャッシュが汚染されるとexample.com以下のwww.example.com,ftp.example.comヘのアクセスを別のIPアドレスのサーバに誘導する事が可能です。SSLのサイト証明を使用していないと http://www.example.com/ へアクセスしたユーザは意図しているサイトにアクセスしているか、偽サイトにアクセスしているか全く区別がつきません。
# HTTP Response Splitting Attackでも同じ効果をHTTPキャッシュを汚染し
# 偽サイトを表示させることも出来ますが、DNSキャッシュ汚染に比べると
# DNSキャッシュ汚染の方が強力な攻撃方法です。
DNSが安全でないことはqmailとdjbdnsの作者として有名なDan J. Bernstein氏が詳しく説明しています。
DNSを安全に利用する為には
- DNSサーバとDNSキャッシュは必ず別サーバにする
- DNSキャッシュサーバは必要なクライアント(社内クライアントなど)のみ問い合わせを受け付ける
- ISPが提供するDNSキャッシュ(DNSサーバ)は利用しない
- DNSキャッシュサーバは権限のあるDNSサーバ(Authoritative DNS)からの応答のみをキャッシュするサーバ(djbdnsのdnscacheなど)を使用する
などの対策が必要です。これらの対策を行ってもDNSサーバとDNSキャッシュを同じサーバプログラムで実行しているサイトでDNSキャッシュ汚染があると偽ホストにアクセスしていても普通は気が付かないでしょう。
The importance of separating DNS caches from DNS serversの中で指摘されているようにBINDのマニュアルでもDNSサーバとDNSキャッシュを必ず別するよう書いてあます。DNSキャッシュとDNSサーバを同じサーバに設定しても構わない場合は、分離されているネットワークシステムの実験環境などでDNSを使えるするようにする、など非常に限定された状況しかありません。本来、DNSサーバプログラムはDNSサーバとDNSキャッシュは別プログラムとして提供されるべき物です。djbdnsではDNSサーバ(tinydns)とDNSキャッシュ(dnscache)プログラムは別プログラムになっており、DNSサーバとDNSキャッシュは別サーバとして動作します。当然ですが最近作られたDNSサーバプログラムはDNSキャッシュとDNSサーバは別サーバととして動作します。
個人的にはsendmailの様に捨てられるサーバプログラムになっても構わないのですが、ISCはいつになったら壊れたBINDのデザインを修正するつもりなのでしょうね?
追記：念のために書いておきますがDNSキャッシュ汚染はdnscacheを使っていても可能です。dnscacheの場合汚染がより難しいだけです。DNSキャッシュ汚染は仕組の問題であるためプログラムでは修正できません。通常、ISP以外の組織がDNSキャッシュを公開する必要はなく、また公開DNSキャッシュを運用するべきではありません。
名前のローマ字表記
たまたま私の名字(おおがき)をローマ字表記で初めてグーグルで検索してみると、「ohgaki」と表記されている方も結構いる事が判りました。
「おおがき」をパスポート等で強制的に使用されるヘボン式で書くと「ogaki」になります。ほぼ100%「おがき」と発音されます。「oogaki」と書くと「うーがき」と読まれる可能性がかなり高くなります。そこで自分でローマ字表記が指定できる場合は「ohgaki」と書いています。多分、他の「おおがき」さんも同じ理由で「ohgaki」と表記されていると思います。
別のローマ字表記でも記述できる氏名の場合困った事になることもあります。例えばJALマイレージグラブです。カードのローマ時表記とJALに登録されているローマ字表記が異なるので自分名義のクレジットカードであるにも関わらず登録できません。(しかも、記憶が正しければ、JALはローマ字表記はヘボン式を使う規則と思いますが「oogaki」と登録されています)
最近カード利用での問題が多くなって来ているのでカード番号をウェブサイトで覚えさせることは少なくなっていく方向性かもしれませんが、このブログを読まれている方で、もしローマ字表記の氏名を取り扱うサイトを構築される場合、氏名のローマ字表記には複数の方法があり場合によっては個人の自由にならない事があることに留意してください。
追記：ヘボン式の表記を調べてみると2000年4月から正式にパスポートでも”OH”が利用できるようになったようです。JALのマイレージバンクでも電話をかけて簡単に修正できました。
知的財産高等裁判所が開設
2005.04.01
知的財産高等裁判所が開設されました。
と言うことらしい。
内部エラー：2755
最近、ノートPCにインストールしているWindows XP Professionalにアプリをインストールしようとすると内部エラー2755と表示されインストールできない。このノートPCはXP Homeがプレインストールされていた代物で、しかも非常に重要なデバイスドライバがメーカサイト(Sony)では公開されていません。なおさら再インストールは避けたい状況なので、このエラーについて少し調べて見ました。
さすがにMicrosoftのサイトを検索すると色々出てきます。どうも2755番のエラーはアクセス権限が原因の様です。
ここまでで思い当たる節がありました。ノートPCを紛失した場合の安全性強化の為にプロファイルディレクトリのApplication Data等も暗号化した事が関連しているかも知れません。現在、暗号化を解除中ですが非常に時間がかかるので結果はまた書くことにします。
追記：
思いのほか速く暗号の解除ができました。推測は正解でした。プロファイルディレクトリのMy Docuementsのみ暗号化し、他のファイル(Application Dataなどの隠しファイルも含む)の暗号化を解除するとアプリケーションがインストール出来るようになりました。どのディレクトリ／ファイルのアクセス権限に問題があったのかは判りませんが、プロファイルディレクトリ中のファイルには紛失した場合に参照されたくないデータが多数ありますが暗号化すると問題があるようですね。
試していませんが別の管理者権限を持つユーザを設定しインストールするとインストール出来たのかもしれません。どのファイルへアクセス出来なかったか判ればもっと早く問題を解決できるのですが…
追記：検索エンジンからのアクセスが多いので補足します。私の場合、プロファイルディレクトリのテンポラリディレクトリを暗号化したため、アプリケーションインストール時に切り替わったユーザIDから暗号化されたファイルにアクセスできなかったため、2755エラーが発生しました。
これ以外にも、ディレクトリが無くなっている、アクセス権限が無いなど、2755エラーと言っても原因はいろいろあります。アプリケーションがエラーに対して適切に処理していればどのファイルにアクセスできなかった表示される場合もあります。この場合はそのファイルへアクセスできるか確認すると良いでしょう。表示されなかったら勘を頼るしか無いです。
不正アクセスとは?
個人的にはACCSの訴えに合理性を全く感じられなかったのですが、日本のコンピュータセキュリティ上非常に影響が大きい判決が出てしまった様です。
個人的には関連性を見出してしまう発言が政治家からありました。片山元総務大臣はインターネットも放送と同じく公共性を持たせ規制するべき、と言う旨の発言があったようです。
自民党の片山虎之助参院幹事長はフジテレビの番組で、「放送とインターネットは（役割が）似てきた。法的な環境の整備も含めて考える必要がある」と述べ、【インターネットにも放送法のような公共性を求める法規制を整備する必要があるとの認識を示した】（日経）
http://www.janjan.jp/media/0503/0503285040/1.php
一見全く関係ないようですが、ACCS裁判の裁判官と片山幹事長は同じ間違い、国境さえもない完全にボーダーレスなインターネットの世界に無理矢理現在の都合のよい(?)世界観を適用させようとする間違い、をしていると思います。
考え方を変えないと録画サーバサービスの例もあるように色々な問題が発生し、その度に騒ぎになると思います。
野放しがよいとは思いませんが、なんらかの規制を行う場合はその必要性と実効性をよく検討し、既得権益を持つ者の道具にならないような形で規制してもらいたいものです。
「ＯＳＳの性能・信頼性評価／障害解析ツール開発」の成果を公開
OSCでもこの手の発表が聞けると思えますが、聞けなくて残念。
開発基盤ワーキンググループに関するドキュメントで、一般公開可能なドキュメントをダウンロードすることができます。
他のワーキンググループや日本ＯＳＳ推進フォーラム全体に関するドキュメントは、左のメニューから選択してダウンロードしてください。
ダウンロードは下記ドキュメントのタイトルをクリックしてください。「ＯＳＳの性能・信頼性評価／障害解析ツール開発」の成果を公開しました
http://www.ipa.go.jp/software/open/forum/DevInfraWG.html