CSSを微調整

ソースコード泥棒

CherryOSがPearPCのコードを盗んでいる事はいろいろな所で書かれていますがこの分析も参考になります。

http://www.ht-technology.com/cherryos-pearpc/cherryos-pearpc.html

このように証拠があっても「盗んでいない」と主張する図々しい会社にはどう対処するべきなのでしょうね? 訴えられないとふんだ確信犯の様のに思えます。

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

私は国際化ドメイン名(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」に変換してから登録するなど、文字の正規化を図っている。以上のルールにより、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%くらい速い事になります。

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