CSSを微調整

CSSを微調整

CSSを微調整している場合ではないのですが同じスキンを使っている方のページを見てドキっとしたので色だけ変更してみました。作るときには手間ですがCSSになっているとやっぱり便利ですね。

CSSは便利なのですが中小プロジェクトでは標準に従ったWebページ作成に必要なコストを無視されるケースが多々ありますね。

別にCSSを使っていなくても他人に迷惑はかかりませんが、最低限必要なセキュリティ対策コストさえ予算に入ってない場合も多々あります。セキュリティに対する意識が低く無視されているケースさえあります。セキュリティ対策が不十分なサイトはそのサイトの信頼を損ねるばかりでなく非常に迷惑です。セキュリティに脆弱なWebサイトはフィッシングセッションIDを盗む為に利用されるからです。 実際に小さいプロジェクトでなくても「こことここにセキュリティーホールがあります!」「外部からサーバ上の任意ファイルの取得と書き換えも可能」と指摘しても一切無視していたケースもあるくらいですから…

危ないWebサイトが氾濫している大きな原因の一つはWebシステムのセキュリティ確保に必要な予算がプロジェクトに無いことにあります。根本的な原因はマネージメントの意識の低さにあります。特に中小規模サイトの場合、セキュリティ対策などより見積り価格優先の場合が多いように思えます。CSSやHTML標準は良いとしてもセキュリティ確保の予算を取れない場合、開発会社のセキュリティ対策に関する知識や対策意識を見極めれない場合、Webサイトは作るべきではないでしょう。

もうすぐ個人情報保護法も施行されますが準備が不十分なところが多いのではないでしょうか?

セキュリティ対策、情報保護で問題になるのは管理者/経営者の意識が一番問題な場合が多いですがこれはその典型的な例でしょう。

白黒をカラーに!

# mixiのさわださんの日記で知りました。
試していませんが、これはすごいですね。

http://www.cs.huji.ac.il/~yweiss/Colorization/

色ということでほんの少しだけ関連(?)してtoy2さんの日記からたどって「目はどうして色が分かるの?」

http://www.kiriya-chem.co.jp/q&a/q52.html

# 詳しすぎ?!
# q&a.html と “&”をファイル/ディレクトリ名に使っていますから、残念!

b2evolutionゲストアカウント

随分前にguestアカウントを作った、と書いたのですが権限が不足のためログインしても何もできない状態でした。b2evolutionはマルチユーザブログなのでアカウントを足すだけでOKなのですがチェック不足でした。
# ツッコミいれて下さい :)

http://blog.ohgaki.net/index.php/guest

ユーザ:guest、パスワード:guest でログインすると次の様な画面になり、投稿やblogger権限の管理が行えます。
blog記入画面

適当に使ってみて下さい。SPAM等の行為がある場合、ブログ自体を予告無く削除します。念のため。

日本語がうまく取り扱えない部分2箇所にものすごく場当たりなパッチを当てているのですが、もし欲しい方いらっしゃる場合コメントに「欲しい」と書いておいて下さい。メールでも良いです。好きな方でどうぞ。

ちなみにApahce 2.0.50+security fix/PHP 4.3.10で次のような環境で動作しています。

php_admin_value default_charset "utf-8"
php_admin_value script_encoding "utf-8"
php_admin_value http_output "utf-8"
php_admin_value mbstring.internal_encoding "utf-8"
php_admin_value mbstring.func_overload 7

追記: b2evolution使っている方が増えているかな、とググって見ると詳しくコードを見ている方がいました。何かの役に立つ(!?)かもしれないのでトラックバックしておきました。
http://cha.s57.xrea.com/blogs/index.php/2005/03/14/p61

カーネルrootkit

最近カーネルrootkitがまた話題になっています。カーネルrootkitへの対処策ソリューションを提供し始めたからの様です。

First Winternals/Sysinternals did their RootkitRevealer
Then Microsoft started fear-mongering
Now F-Secure jumped on the bandwagon with their Blacklight Beta

rootkitとはバックグラウンドで動作してシステムの利用状況を記録したり、バックドアを開けてリモートから管理者権限でシステムを使用できるようにするプログラムの総称です。

全てのrootkitが良くないか、と言うとそうでは無い場合もあります。システム管理者がネットワーク上のコンピュータを管理する為に開発されたrootkitもあり、これらのツールはネットワークシステム管理者にとって非常に便利です。

問題なのはadware、malwareと呼ばれるプログラムにユーザが意図しないrootkitが含まれていたり、ウィルスに含まれていたりする事です。これらのrootkitはSPAMメールの送信に利用されたり、ユーザがどのようなWebページをブラウズしているか記録する為に利用される事がほとんどです。しかし、その気になれば銀行のWebアカウントへログインする為のユーザ名とパスワードを盗む事も簡単です。

通上のrootkitの検出はプロセスの一覧を見ることで簡単に検出できます。ファイルシステム上を検索する事により不審なファイルを捜す事によっても検出できます。しかし、カーネルレベルrootkitの検出は簡単ではありません。カーネルレベルrootkitは文字どおりカーネルレベルで動作しプロセスの一覧、ファイルの一覧などを取得するシステムコールを横取りし、rootkitのプロセス、ファイルの存在を隠してしまいます。この隠蔽はカーネルレベルで行われているため、一旦インストールされてしまうとユーザレベルで実行されるアンチウィルス対策は全く役に立ちません。

snort等のIDS(Intrusion Detection System)を使えばネットワークトラフィックから検出できると思われるかも知れませんが、例えばHacker Defenderの場合、135番ポートで通信し他のWindowsアプリも正常に動作するため通常の状態ではsnortで検出できません。

Microsoft Resarchの場合、カーネルrootkitもCross View Diffと呼ばれるテクニックで検出するようにしたようです。詳しい、説明はリンク先を見て頂くとして、より低いレベルでのスキャンとAPI出力の差分からrootkitを検出するという手法です。現在確認されているrootkitは検出可能ですがどのような方法を取ったとしてもイタチごっこの様な気もします。

ちなみにこの手のカーネルrootkitはWindows用ばかりではありません。当然ですがLinux用のカーネルrootkitも多数存在します。

今すぐrootkitが入っていないか確認したい!と言う場合、検査するシステムのHDDを取り外し、信頼できるシステムにマウントしてrootkitファイルが無いか確認すると良いでしょう。

とりあえずWikiを復旧

Webサーバのコンテンツはsubversionで管理しているのですがWikiはデータがWebサーバ上にあったためバックアップ対象から外れていました。この為、先日のHDDクラッシュでWikiデータは消滅してしまいました。とりあえずほとんど空のWikiとして公開を再開しています。

Pukiwikiを使っているのですが前からコンバート後にpreに変換させる為の行頭のスペース追加がめんどうでどうにかしたかったのですが、時間がなくて放っていました。

今回、再インストールするにあたってインデントボタンくらいは付けよう、とhttp://pukiwiki.org/ の自作プラグインpreedit.inc.phpというプラグインを見つけましたが、Mozillaで使えないこと(致命的)と現時点での最新版Pukiwiki 1.4.5-1では編集ページ表示の仕様が変わった(?)為か動作しませんでした。と言うことでパッチで作ってしまう事にしました。

http://www.ohgaki.net/wiki/index.php?Pukiwiki

基本的に編集ページを生成するスクリプトにボタンとJavaScriptの出力を追加するだけのパッチです。手動で別のバージョンのPukiwikiで使うのも難しくはないと思います。 必要な方はご自由にお使い下さい。
# 一応IE、Mozilla両方で動作しますがMozillaの方がまし
# に動作します。早くIEは捨てましょう!(本当に)

パッチを適用すると下の画像のように「インデント」ボタンが追加されます。マウスでインデント(アンインデント)する範囲を選択し、ボタンを押すと行頭にスペースが追加されます。

pukiwikiのインデントボタン

AJAX – ダイナミックWebコンテンツ

JavaScript/DOMを使ったメニュー生成やフォーム選択状況に応じて適切なメッセージを表示するダイナミックコンテンツは多くありましたが、よりインタラクティブなHTMLコンテンツがどんどん増えそうです。

AJAX = Asynchronous JavaScript + XML

XMLHttpRequestを使った方法ですが、非常に新しいと言うことではないのですが最近急に注目されはじめました。

はやりgoogleのせい?

ここここが参考になります。

新しいドメインの仕組や新ドメインは必要か?

私は国際化ドメイン名(IDN)は前から必要無いと考えています。そしてフィッシング(Phishing)の流行のおかげ(?)で国際化ドメインは過去の物となることは決定的となったと思います。何故ならほとんどのブラウザはIDNが無効な状態がデフォルトになると思われるからです。

もともと国際化ドメイン名が提案されていた頃から似た文字を使用した紛らわしいサイト名について議論されていました。今日のように組織的にフィッシングが行われ、数百億単位の損害であると言われている状態では国際化ドメイン名は百害あって一利なしとまでは言えなくても、百害あって一利がある程度と言わざるを得ないと思います。国際化ドメイン名で「商品名.jp」の様に簡単に必要なサイトにアクセスできる、ことがメリットとして紹介されていますが、フィッシングを行っている犯罪者にも好都合です。ありとあらゆる商品やサービス名を使って個人情報を盗むには好都合です。今日のように検索サイトが高機能化している場合、「商品名.jp」などと言うサイトが無くても検索サイトで検索すれば良いだけです。そして検索サイトの検索結果の上位にフィッシングサイトが載ってしまう、と言うことはあまり考えられません。国際化ドメイン名は本当に必要なのでしょうか?

新しいトップレベルドメイン名についても色々議論されていますが、これらの不必要です。.infoや.bizなどの比較的新しいドメインは作られはしたものの.infoや.bizドメインを持つサイトは怪しげなサイトに思えてしまうのは私だけでしょうか? 私だけでは無い証拠(?)に.infoや.bizドメインはほとんど使われていない様に思えます。少なくとも私は.info/.bizドメインのURLを見た場合「本物かな?」と疑ってしまいます。

結局、国際化ドメイン名も新しいドメイン名もドメイン登録業者だけが喜ぶだけではないでしょうか? 念のために自分が保有している名前と同じドメイン名を取得しているだけ、と言う会社がほとんどではないかと思います。

会社等のサイトの場合でフィッシングに対抗したり責任のある対処をとるのであれば、複数のトップレベルドメインの使用は控えるべきと思います。フィッシングに対抗すると言う理由ではありませんが、多くのグローバル企業が.comドメインのみを使用するようになっています。例えば、IBMのサイトの場合は必ずドメイン名がibm.comで終わる、とユーザが解かっていれば仮にibm-newservice.comと言うフィッシングサイトが在ったとしてもユーザは本当に「IBMのサイトか?」思う可能性が高くなります。基本的には組織や団体は一つのドメイン名のみを使用するべきです。

「組織や団体は一つのドメイン名のみを使用するべき」と言う考え方に多少関連していますが、私が特に気になっているドメイン名に地方公共団体の組織で.go.jpドメインが利用できるにもかかわらず.jpドメインを使用しているサイトがある事です。.go.jpドメインであればドメイン登録の仕組上、どのような組織であるかは決まっていますしユーザも解かっている確率が高くなります。しかし、ドメイン登録が面倒なのか(それとも.jpドメインの方がカッコいいとでも思っている!?のか).go.jpドメインではない.jpドメインを使用しているサイトが非常に目に付きます。地方公共団体による不必要な.jpドメインの乱用が続けばフィッシングに利用されるようになることは簡単に想像できます。偽サイトを本物の公共団体サイトである、と信じさせる事が出来れば「オレオレ詐欺」に簡単に引っかかってしまう日本人なので個人情報が盗み放題になってしまうかも知れません。

.jpドメインが不必要とは思っていませんが、更に新しいドメインの仕組や新ドメインは必要か? 答えはNOではないでしょうか?

国際化ドメイン名のフィッシング詐欺はブラウザの責任ではないとJPRSが見解

CNET Japanから。

最近話題になってきた、古くて新しい(?)国際化ドメインの似ている文字や表記の問題についれJPRSがコメントしているようです。日本語ドメインは安全と主張しているようですが、JPRSが「日本語ドメインは危険です」とは言えないでしょう。

JPドメインはICANNガイドラインに基付いてDNS登録のルールを運用している。日本語文字列でも英数字でもない文字ではJPドメインのDNS に登録できないのである。さらに、例えば「A」と「a」と「A」と「a」はすべて「a」に変換してから登録するなど、文字の正規化を図っている。以上のルールにより、JPドメインでは似た文字問題が起こらない。異なる言語圏の文字を混ぜた場合、そもそもDNSに情報が登録されていないためだ。

/.でも記載されていましたが、日本語ドメインではカタカナの「へ」とひらながの「へ」は区別が付きづらいです。ICANNガイドラインRFC3743の様にドメイン登録にはルールがありますが、RFCがあれば安心できる、と言うものではないと思います。RFC2505にはOpen Relayはいけません、とありますがこれがあるからと言ってOpen Relayが無くなる訳ではありません。ドメイン登録はSMTPサーバと違い、誰でも自由に設置できないので国際化ドメイン名の登録とは事情が異なるのは明らかですがそれでも問題は残ると思います。

JPRS社長室広報の渡辺俊雄氏はIDNのフィッシング詐欺への影響に関して2つの見解を示した。1つは、フィッシング詐欺はJPドメインではそもそも起こり得ない問題であること。2つ目は、COMドメインではフィッシングが起こり得るが、それはCOMドメインの問題であり、ウェブブラウザの機能を制限する論調になっていくのはよくないということ。

ここでのJPRSの見解は支離滅裂と言えると思います。JPドメインは安全なのでCOMドメインの問題はJPドメインの問題ではない? フィッシング(Phishing)は全てのユーザを「釣る」必要は無く、より多くの攻撃対象を釣るためにIDN機能は好都合ということが問題なのです。HTMLメールに金融機関のURLを付けリンク先はIPアドレスの別サイト、と言うフィッシングは「普通」に行われています。「COMドメインの問題でJPドメインでは問題は起り得ない」と言う考え方は暴論としか思えません。例えば「日本銀行.jp」を偽る「日本銀行.com」を本当のサイトと思うユーザは「10.231.87.12」というIPアドレスのサイトよりもかなりの多い数になる事は容易に推測できます。.jpドメインのIDNであればフィッシング詐欺が起きない、と言うの見解はどすれば出てるくのか理解不能です。

CNET Japanの記事にはこう書いてありました。

ブラウザの機能をOFFにしてIDNを使えなくすることは簡単にできる一方で、IDN が使えれば「商品名.jp」といったURLを使って情報にアクセスできる。IDNによるフィッシング問題をどう捉えるかはユーザーの判断に任せられている。

IDNは「必ず」無効にするべき機能、責任あるサイトはIDNのサイトは作るべきでは無いと考えています。ブラウザベンダーはIDN機能はデフォルト無効に設定するべきで、ほとんどのベンダーは正しい方向に修正すると思われます。

Say NO to IDN!!

NTTの局で障害発生 part2

結局、Bフレッツが回復したのは障害発生(2005/2/9 16:33)から約29時間(2005/2/10 9:22)後でした。しかし、未だに(2005/2/11 16:10)障害情報のページは更新されていません。

http://www.ip-nw.com/nwc/kagawa/trouble.html

今回の障害は局全体+一部の地域が影響範囲と聞いています。Bフレッツのみでなく一般電話回線であるISDNも使えない状態でもこのページを更新するに値する障害と考えていない?!のかただ更新を忘れていただけ?!なのかどちらでしょうか?

イチローのCMが虚しく響きます。

# NTT西日本はイチローをCMに起用して最高以上のサービス提供する云々
# と言っていました。残念ながらNTT西日本ホームページのCMライブラリ
# にも映像ファイルが無いようです。

NTTの局で障害発生

このサーバが設置されている事務所の電話局(さぬき三条)で2月9日 16:33頃に障害が発生したらしく、複数のISDN回線とBフレッツが回線エラーでダウンしました。

電話は23:30頃には回復したようですが、Bフレッツは今現在(2/10 9:00)でも不通です…
電力会社の光とも契約しようとしていた矢先の長期間にわたる障害になってしまいました…
個人的には最悪電話は携帯が使えるのでネットワークの回復を優先してほしいです。NTTの問い合わせ先を調べるのにAirH”を使いましたが、遅すぎて本当に辛いです。

気になったのは http://www.ip-nw.com/nwc/kagawa/trouble.html でフレッツの障害情報を公開しているはずですが、今現在も載っていません。これだけ長期間の障害ですから障害発生中に状況や復旧見込など載せるべきと思います。

たしか去年だったと思いますが高松市の中心部でまる1日Bフレッツがダウンした障害もありました。フレッツだけならまだしも今回は電話もですから何が起きたか説明くらいは欲しいものです。

MySQLはバグが少ない–ソースコードの分析で判明

CNET Japanの記事によるとMySQLのコードは商用製品に比べバグがするないらしい。どのような「商用製品」と比較したのか気になりますが単独で動作するWindowsアプリケーション、つまりサーバアプリケーションでないアプリケーション、と比較したのであれば少なくて当り前のような気がします。この結果をだした会社の顧客には大手IT企業が名を連ねているので意地悪な見方をするとこれらの会社の製品のクオリティーが悪いとも読めます。深読みし過ぎでしょうか?

この記事で使われているソースコードバリデーションツール類似したもので私のブックマークには次のリンクが入っていました。(サイトの中まで確認していないので関係無い物もあるかもしれませんが)

http://www.splint.org/
http://www.dwheeler.com/flawfinder/
http://www.securesoftware.com/resources/tools.html
http://www.astree.ens.fr/
http://www.cleanscape.net/products/lintplus/
http://spinroot.com/uno/

少なくともどれか一つくらいは使った方が良いとは思いますが、使ってないですね。今度、時間があったらPostgreSQLとPHPくらいはチェックしてみます。

しかしMySQLはさすがに会社としてきちんとマーケティングしてますね。PostgreSQLのサイトもデザインが洗練されたり、今まで弱かった関連ツール情報を提供したり、実際に開発する場所(GNUForgeのpgfundroy.org)等を提供しています。でも、こういったマーケティングはなかなかボランティアベースでは難しいですね。私はニュースとかまるまる信じるタイプではなくまず疑ってみるタイプですから、「本当に?」と思ってしまいますが、この手のマーケティングは効果があるのでしょうね。

PukiWiki vs Hiki

具体的な数値はさておきkazuhikoさんから「PukiWikiよりHikiの方が3倍くらい速い!」と聞きました。実際、モジュール版PHPとmod_ruby版Rubyで比較するとそれくらいの差が出るようです。

PukiWikiが遅いのは生成したページデータのキャッシュをほとんど全く行っていない事が原因と思います。Hikiの作りは良く知らないのですが、PukiWikiより多くキャッシュをしているようです。

print(‘ABCDEFG’);

と言う簡単なスクリプトをPHP, mod_rubyで実行し、abで比較するとPHPの方が3倍くらい速かったのでmod_rubyはリクエストの初期化にもう少し改善できる余地があるようです。個人的にはPukiWikiの速度に全く不満は無いのですがアクセス数が多いサイト様にもう少し性能アップしても良いのかも、と思いました。

そこでwikipediaなどで使われているMediaWikiを試しにインストールしてabでベンチマークしてみました。結果は悲惨なことにPukiWikiの半分以下の性能でした… MediaWikiはMySQLにデータを保存しているのでオーバーヘッドが大きいとは言えますが、それにしても2リクエスト/秒弱(AthlonXP2500+)とは遅すぎです。

最後にmod_rubyはスクリプトをキャッシュしている(?)らしいのでphp-eacceleratorをインストールするとPukiWikiの速度は2倍くらい(10リクエスト/秒)になりました。それでもHiki+mod_rubyの方が50%くらい速い事になります。

注意:いい加減なベンチマークなのであまり具体的な数値は書きませんが、イメージは解かると思います。コメント歓迎します。