「重さ1キロから2キロ」で「1.2kg」を検索できる技術
沖電気が開発した技術は、まず、テキストの数字周辺に現れる単位文字列や単語を、「金額」「時間」「長さ」「重さ」「速度」の5つの属性を判定。判定した属性の代表単位で数字の大きさを換算し、数値情報として抽出する。長さの場合であれば、「インチ」や「尺」といった単位で記述された数値はすべてメートルに換算する。
1キロ(Kg)のキロをKmと間違える事もあるそうですが、これは仕方ないですね。
マイクロソフトの「WPF/E」
このWPF/Eは2007年前半には登場するはずだが、その目標は次期Windowsクライアントソフトウェア「Vista」の洗練されたルック＆フィールのかなりの部分を、別のOSや他社製ブラウザでも再現できるようにするというものだ。
Flashの代わりにもなるらしい。
WindowsとLinuxを標的にする脆弱性実証コードが出現
WindowsマシンとLinuxマシンの両方を標的とする悪意のあるソフトが新たに出現した。
同ウイルスは、LinuxのELFフォーマットとWindowsのPEフォーマットの両ファイルへの感染力を持つ
だそうです。
To infect ELF files, the virus uses INT 80 system calls and injects its body into the file immediately after the ELF file header and before the “.text” section. This changes the entry point of the original file.
Infected files are identified with a 2-byte signature, 7DFBh, at 0Bh.
The virus uses the Kernel32.dll function to infect systems running Win32. It injects its code to the final section, and gains control by again changing the entry point. Infected PE files contain the same 2-byte signature as ELF files; the signature is placed in the PE TimeDateStamp header.
3畳液晶
ソニーとサムスンが約2200mm×2500mmの第8世代アモルファスTFT液晶ディスプレイパネルの製造ラインを新たに作ることに合意したそうです。
大きさにすると1.6坪ちょっと、つまり畳3帖分以上!（もちろん標準サイズで）
空港の到着便などのパネルとして使えるとは思います。しかし、ここまで大きくなるとほとんどの日本の家には合いませんよね… という前にこれだけ大きいと大きすぎて設置さえできない家も多いかも知れません。標準の家の天井までの高さは2400mmでドアの高さは1800mm、窓があっても高さ2200mmの窓はそう多くないです。横に寝かせれば幅が2400mmくらいの窓があれば足や枠があっても何とか入りそうです。しかし、仮に設置したとして床から天井くらいまであるテレビは相当な違和感があるよう気がします。どちらにしてもここまでデカイ物は一般家庭用の製品ではないので心配する必要ないですけど。
それとここまで大きくするとフルHDの解像度くらいでは近くで見るとドットが目立つような気がします。スムージングなどもするのかも知れませんね。絶対に買わない&超高級車が軽く買える値段だと思いますが、このパネルを使ったテレビの値段は気になります。
ウィルスで高性能バッテリ – 3倍容量!
./J的なネタですが、ウィルス（コンピュータのウィルスではなく本物のウィルス）を使って高性能バッテリを作れるそうです。
Researchers at Massachusetts Institute of Technology (MIT) are using viruses to create tiny batteries that can store up to three times as much energy as conventional power systems.
リチウムイオンバッテリの容量が3倍はうれしいですね。
燃料電池はノート等ある程度の大きさの物には良いですが、携帯電話などは普通のバッテリの方が向いていると思えます。ワンセグでテレビを見る等には容量3倍は大きな意味があると思います。はやく実用化しないかな。もしかしてtiny batteriesと書いてあるので超小型のみかな?
電池マニアではないので普段電池情報をチェックしている訳ではないのですが「
NTTドコモがケータイ向け燃料電池を改良，クロスオーバーを半減して通話時間を3倍に」という記事をTechONに見つけました。
NTTドコモと富士通研究所は共同で，通話時間が約6時間と長い携帯電話機向けの外付け燃料電池を開発した。
とあります。なんとこちらもたまたま3倍ネタです。（驚）
リンク先の写真を見ると分かりますが結構大きいです。6時間通話とはいってもこの燃料電池ユニットを持ち歩くより、3つくらいバッテリを持っている方が良いかなと思えます。（例えば、901シリーズのスペック上の連続通話時間は2～3時間）どちらがどうなのか判断する情報ももっていないのでなんとなくですが、ウィルスによる改良型リチウムイオンバッテリより燃料電池が超小型になることに期待するほうが合理的ですかね?
個人的には電話の電池容量には十分満足しているのでノートPCのバッテリが重要です。燃料電池が早く普及してほしいです。
このブログの障害の件
個人ブログの障害などはどうでも良いことですが書いておきます。
このブログのWebサーバが使っているDBサーバへのネットワーク接続が断続的に切れる問題がここ2,3日かなりの頻度で断続的に発生していました。頻度は別にして以前から同様の問題があったと思われます。DBサーバのNICの交換で様子を見ていたのですが原因はHUBだったようです。安物HUBとは言え1年経ってないように思うのですが… とりあえず別のHUBに交換し、ついでにケーブルも交換しておきました。これで直っているとは思うのですがしばらく様子をよく見ないといけないですね。
中途半端に壊れたH/Wは性質が悪い…
エントリの更新やページの表示に時間がかかる場合があるな、とは思っていたのですが最近になるまで問題があるとは気が付きませんでした。
MySQLからPostgreSQLに乗り換えた理由。MySQLより10倍速かったから?!
hackers-jp@ml.postgresql.jp に掲載されていたメールの話です。
色々興味深いです。
MyISAM -> InnoDBで容量が約10倍。InnoDBとPostgreSQLを比べても約3倍。
キャパシティプランニングはDB設計の重要な要素ですが、知らないと困ったことになりますね。
MySQLであまり大きなDBを取り扱ったことが無かったので知らなかったですがMyISAM->InnoDBで10倍にもなるケースもあるとは…
JPUGのMLに書かれていた以外の理由としては1/3のメモリで3倍速く、データのパーテションニング、パーシャルインデックス等のPostgreSQL機能を近い将来利用する事が出来ることもスイッチする理由だそうです。
For an application like FeedLounge, the faster counting and smaller row size of PostgreSQL are compelling reasons to use it instead of MySQL with InnoDB tables. Add that it runs in 1/3 the time, using 1/3 the memory (making it essentially 10x faster for us) and that we can start taking advantage of other Postgres features, like data partitioning and partial indices in the near future, and you have the reason we decided to make the switch.
軽くて速いPostgreSQLは彼らにとって「10倍速い」と言っています。何だか一般的に言われていること（MySQLは軽くて速い）と反対ですね。
どのDBを選択するか?は利用条件、要求事項によって最適な選択が異なります。MySQLの方が自分にとっては「10倍速い」と考えるユーザも多いと思います。どちらにしてもこの事例は参考になります。
以下、メール本文のコピーです。
—–
寺本＠横須賀 です。
最近メールがないので…
雑談ですが、ちょっと面白いのでご紹介です。(via Planet Postgresql)
FeedLoungeという、RSSフィードのオンラインリーダーを提供している（らしい）サービスがあるのですが、そこがDBをMySQLからPostgreSQLに乗り換えた、という話です。
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/
何が理由で乗り換えたのかに興味があったので読んでみたんですが、
—-
Some of the reasons we decided to make the switch to PostgreSQL: * Database size - when we switched from MyISAM tables to InnoDB tables in MySQL, the size of our database grew from ~1GB to 10+GB! When we made the switch this weekend, the MySQL InnoDB database was using 34 GB, and the same data in a PostgreSQL database is only 9.6 GB - this should keep our hardware costs down a bit. * Load time - The current MySQL setup takes over a day to restore the current database, the load of the data into the PostgreSQL database took just over 4 hours.
—-
という今まで聞いたことも無い理由で乗り換えたとのことでした。
# PGよりも3倍も容量が多くなっちゃったなんて！
その後にPG派とMy派でいろいろコメントがついてます。
どうもでっかいPrimary Keyがついてるらしく、それがまずいんじゃないのか？的話になっていうように読めました。（斜め読みです）
— Junji Teramoto / teramoto.junji (a) lab.ntt.co.jp Master Yoda : Don’t think…feel…be as one with the Source. Help you, it will.
Google Analytics事始
Google Analyticsはサービスが開始されて少し経ってから利用申請をしたのですがその時既に「規制中」でした。やっと個人的に利用できるようになりました。申請した時には日本語ページも無かった(?)ような気がしますが、現在は日本語ページも用意されています。
当たり前の機能で紹介するまでもないですがGoogle Analyticsによるとこのブログにアクセスする方の6割ちょっとがIEを使用されているそうです。Windowsは約9割、1024×768の解像度が5割弱となっています。キャンペーンの効果が判ったり、特定の日付や期間で比較したり、GeoIPで何処からのアクセスか地図などで判ったり、このブログを見ている方は圧倒的にOCNユーザが多い事が判ったりします。
IEユーザが多いのは仕方が無いとして、気になったのは脆弱性があるFlashを使われている方も結構多いことです。フラッシュのバージョンは多いので正確な数字は足し算してみなければ分かりませんが、脆弱なFlashを使われている方が3～4割くらいになるようです。
データはWeb上で見るだけでなく、TSV、CSV、XMLでダウンロードできます。商用サイトで役立つのはもちろん個人でブログをしている方も見ていて面白いと思います。
言い古されていますが一言で言うと「これがあれば並のアクセス統計サービスは無用」です。商用サービスレベルの機能が付いています。一応だれでもインビテーションコードの予約が可能らしいので興味がある方は是非どうぞ。（Googleのアカウントが必用です）
CNet Japanの障害
CNet Japanの障害情報メールも来ていましたがまだ正常に動作していないようですね。メンテナンスで問題発生、とメールには書いてありましたがバックアウトできないようなメンテナンスだったのかな?
追記：こんなメールが来ていました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2006年4月6日 CNET Japan・ZDNet Japan をリニューアルします！ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本日深夜、CNET Japan およびZDNet Japanは、リニューアルをします。 サイトのデザインを刷新し、新しいコーナーや機能を追加して読むだけでなく より使えるサイトになります！ 新しくなるCNET Japan・ZDNet Japanにぜひ、アクセスしてください！
その次
4月7日、サイトメンテナンス作業時に発生したシステム障害により、長時間にわた りCNET Japan・ZDNet Japanがご覧頂けない状態が続いておりますことを、お詫び 申し上げます。 サイトメンテナンスは終了しておりますが、現在も、サイトにアクセスしにくい 状態が続いております。
9日朝ごろまで色々問題があったようです。
Webにポップアップは必要か?
備考：かなり古いブログですが公開し忘れしてい分です。
銀行サイトにアクセスすると偽のログイン用のポップアップを掲載するトロイの木馬が現れたそうです。機会があるたびに「ポップアップはしない方が良い」「アドレスバーを隠すのは最悪」と言っていましたがIT Proの写真を見ると「Window」としてポップアップするのではなく、「レイヤー」としてポップアップしているようにも見えます。Windowの部分にはアドレスバーが無いので画面全体のWindowsがポップアップとして表示されるのかも知れません。このようなトロイの木馬は予想はしていましたが実際に現れるのは困ったものです。
以前からログインにポップアップは有害と言っていましたが、海外とは言え実物が出てくるとリスクは以前より大きくなったと言えると思います。例え自分のサイトが価値の高いサービスをしていなくてもWebのデザインとしてポップアップは避けるべきと思います。普通のユーザがポップアップに慣れてしまうと偽のポップアップが開いたときに少しは「あれ?」と思っても偽のポップアップに重要な情報を記入してしまうかも知れません。
# トロイの木馬がインストールされている時点でほとんどアウトですが。
# しかし、こんな事をするよりキー入力をログした方が簡単に思えます。
# キー入力をログするより見つかりづらい、と思ったのでしょうね。多分。
随分前にも書きましたが、例えば振込みなど資金の移動が伴うような処理の場合、別のセキュアなデバイスで送金情報を表示してデジタル署名するような仕組みにしないと、オンラインバンキング等は攻撃対象になり続けるのでしょうね。PCやブラウザは信用できないですかね…
今思いついたのですがより簡易な方法として2重にメッセージダイジェストを取る方法だと、PCと携帯が通信しなくても安全性を確保できますね。
トランザクションのメッセージダイジェストをPCに表示
携帯のアプリでメッセージダイジェストをさらに共通の秘密情報含めた値でメッセージダイジェストを計算
利用者はダイジェスト値も入力してトランザクションを送信
と言った感じで処理すればよいですね。実際にPCと携帯が通信しなくてもよい分、今すぐにでも実装できますね。
Netcraft Web Server Survey
Apacheのシェアが落ちてIISが増えてきていますね。
Microsoftのオープンソースラボ
オープンソースと対決、とは違う路線を模索というところでしょうか?
またNHKニュースでウィルス
昨日の夜7時のNHKニュースで山田オルタナティブウィルスの件が報道されていました。IPAの方（多分IPAの方）が「基本に立ち返る必要があります。出所が不明なファイルを開いてはなりません」と言われていました。何故今頃このような報道が?と思ったら、1日300台のペースで感染が広がっているいるようです…
PCがWebサーバになってしまってHDDの中身が丸見えになる様子、リモートデスクトップ機能を無条件に許可して操作状態がわかってしまう様子が報道されていました。
ところで今山田オルタナティブの感染が拡大しているのは「ウィルスに感染しないためにはWinnyをPCにインストールしない」という対策を啓蒙した事が原因で
「WinnyをPCにインストールしなけれウィルスに感染しない」
↓
「WinnyをインストールしていないPCでファイルを開けば安全！」
と勘違いしたユーザ増えた?!という事なのかも知れませんね。
少しコンピュータに詳しい方には笑い話なのですが、ブラックボックスとして使用している方がどう対応する可能性があるか理解した上でセキュリティ教育をしなければならない良い例なのかもしれません。
【追記】
数日前（4/11ごろ）の朝のNHKニュースで「映画等の不正コピーの90%以上はWinnyではなくShareで行われている」と報道していました。これを見て「Shareに乗り換えよう」と思った人も多いのではないでしょうか…. この報道も「なんだかなぁ」と思わされました。
クロスドメインのHTML読み取り(IEのバグ CSSXSS）とCSRF
追記：このブログを記載する理由となったURLを記載された方が内容を削除されたようです。「間違っている」と言われるのは心外である、と思ったことは確かですがページの内容が削除されるのは私の本意ではありません。書かれていた情報はとても役に立つ情報だと思います。非常に残念なので再度掲載されることを望みます。（本当
—–
セキュリティ対策ではよくあることですが、条件の見落としによりセキュリティ対策を行っていても脆弱性が発生することがあります。「Webアプリセキュリティ対策入門」に書かれているCSRF対策にも「クロスドメインのHTML読み取り(IEのバグ）」の問題が修正されていない為、書籍に記載した対策を行ってもバグを持つIEに対してはCSRFに脆弱になります。
しかし、このバグの影響を持って「Webアプリセキュリティ対策入門」のCSRF対策を「間違った対策」と書かれても困ります。妥当な表現はバグがあるブラウザに対して「不十分な対策」ではないでしょうか。
このブログを書くきっかけは以下のURLです。
http://www.jumperz.net/texts/csrf.htm
問題点を整理してみます。（IEのCSSXSSバグ問題として知られる問題）
IEはスタイルシートとしてCSS以外のファイル、例えばHTMLファイル、を外部サイトから読み込めてしまうバグがある。
↓
つまり、HTML等に埋め込まれた情報は第三者のサイトから盗む事が可能となる。
↓
つまり、HTML等に秘密情報（トークン等）が記載されていると意図しないフォーム送信（CSRF)を行える。
同じくIEのバグが原因のXST(Cross Site Tracing)に似ている問題と言えると思います。
汎用性（複数のページを開いている場合）の考慮はされていませんが
http://www.jumperz.net/texts/csrf.htm
に利用可能な対策が紹介されています。重要なのは以下の2つです。
- HTMLにトークン（フォーム送信を一意に特定できる値）を書かない
- トークンをセッションIDと紐付ける
この2つを実行することでIEのバグを回避し、CSRFを防止することがWebサイト側で可能になります。
ところで、この問題の本質はセキュリティの基本中の基本であるCIAをブラウザが守れない事に原因があります。(Confidentiality, Integrity, Availavility – の内のConfidentiality(機密性）が守られていない。)マイクロソフトも直すつもりはあるようで
http://d.hatena.ne.jp/hoshikuzu/20051204#P2005204MATANGILLON
に、直すつもりがある旨が記載されています。実際現在のIEはCSSファイルのように見えなければHTMLの中身が読み取れない状態らしく半分直した(?)ような状態になっているようです。（前にSJISは使わない方が良い、とブログで書きましたがこの件でもSJISをページのエンコーディングに使うのは危険なようです）
jumperz.netの対策はバグを持つIEユーザ向けCSRFの対策としては使用できますが、ページに表示されている情報を盗み見れて困るのはCSRF（CSRFの場合、hiddenタグのトークン情報）だけではありません。様々な情報には他人に見られるだけでも困る物も多くあります。例えば、メールや銀行／証券／保険会社の口座情報を広く公開しても気にしない、と言う人は少ないと思います。
セッションIDをページに記載する手法は、キャッシュ制御をしっかりしないとプロキシ等のキャッシュ（どんなヘッダを送ってもキャッシュする、しないはプロキシ次第ですが）にセッションIDが記録されるので簡易な対策として紹介しています。この方法はCSRF対策を行っていないアプリが、普通のブラウザと環境においてCSRF対策を行う場合、問題も少なく、最も対策が簡単だからです。
本来外部サイトのHTMLページはコンフィデンシャルな情報であり、それが守れない状態であるIEが根本的な問題です。重要な情報をページに表示できないのであれば、重要な情報を表示するアプリはインターネットに公開する事はできません。
CSRFだけ考えても、数え切れないほどの開発者が開発しているWebサイトより、MSが開発しているIEのバグを直す方が速いのは明らかと思います。この手のバグに対する対処は仮りに書籍に書くとしても注意事項として小さく書く程度が限界かと思います。出版した頃にはもう解決済みの問題となっている可能性も高いですから。このあたりは紙メディアの限界ですね。
マイクロソフトはPassportアカウントのメールアドレスがvbscriptでどのサイトからでも参照できるバグを長期間放置していた実績があり、今回のバグが長い間放置される可能性も少なくありません。もしかしてIE7では直っている、とアドバイザリを出すつもりなのかも知れません?!火が付けばパッチ出す!?と言うことで、広く知れた事なので騒ぐが勝ちかも知れません。
とは言っても、MSは昨年に分かっていた問題に対して未だに完全なパッチを提供していない事は事実なようです。このような状況ではWebサイト側でも対策しないとMSがいつ対応してくれるか分かりません。情報を盗み見られるも困りますが情報を改竄される方が大きな被害である事に議論の余地は無いと思います。jumperz.netにはクッキーとJavaScriptを使った対策が紹介されていますが、これにはもう少しスマート（汎用的）なやり方もあります。
JavaScriptの使用を前提とするなら「Webアプリセキュリティ対策入門」書かれているフォームID(フォームのトークン – hiddenタグに記載）とセッションID(クッキーに保存）でMD5でメッセージダイジェストを取り、フォームにセットして送信します。サーバ側ではCSRFが行われていないかメッセージダイジェストを比較するロジックを追加するだけでOKです。この手法の場合、複数のページを同時に開いても問題無く処理でき、同じフォームの複数回送信も防げます。
作業量はさておき、この変更自体は簡単ですよね? フォームの方はhiddenタグの追加と簡単なJavaScriptを追加するだけ、サーバ側はMD5の値を作って追加されhiddenタグと値を比べるだけです。hiddenタグの値が無い場合は、CAPTCHAまたはパスワード入力方式にfallbackしても良いかも知れません。本を読んだ方でこの説明で対処方法がよく解から場合はコメントをお願いします。
# MD5関数はJavaScriptにはありませんが、探せば沢山実装が見
# 付かります。
#
# 個人的には、自前のフォームクラスを使っているアプリの場合、
# 上記の修正を加えるにはを少しフォームクラスを修正するだけ
# で対応できました。
#
# ところで.NET ASPで作ったWebサイトはViewState等の為(?)
# このIEのバグによるCSRFの影響は受けないのでしょうか?
# MSの腰が重い理由はこのあたりあるのかな?と疑いを持って
# いる次第です。識者の方、コメント頂ければ幸いです。
Web開発者としては過去のブラウザバグまで考慮して開発するのは困った物です。ユーザとしてもJavaScriptとクッキーを使ったフォーム送信がデフォルトになるとFirefoxのNoScript拡張を使っていると面倒が一つ増えます、IEでもActiveScriptを無効に設定している人も同じ面倒が増えます。仮りにIEのバグが直ったとしてもまた同じ問題が他のブラウザや新しいIEでも発生する事も考えられます。直したハズの問題がまた表れるのもよくある事です。
多分少しするとIEのバグも修正されると思います。JavaScriptとクッキーを使ったCSRF対策を次の書籍等の著作物に入れるべきなのか、省略すべきなのか、悩ましい所です。
蛇足：
Session IDのクッキーに非標準のHttpOnly属性を使いたい方は、Sessionを初期化する場合に別のCSRFチェック用のHttpOnly属性無しクッキーを初期化して使用します。
蛇足2：
時々「IEを使うのは止めときましょう」と、このブログにも書いていますがこの問題もIEを使わない理由の一つですね。2004年はIEが安全に使えた日は7%日しかなかったという調査もあります。2005年は多少まし(?)かも知れませんが、2006年は2004年に似たような数値になるのかも知れませんね。
蛇足3：
PHPの透過的セッション管理（trand_sid）は利用しない、といつも言っていますがtrans_sidを行っているサイトの場合、フォーム送信ページをリクエストする事によりセッションIDを簡単に盗まれます… セッションIDをフォームに記載したCSRF対策も同様にセッションIDを盗まれます。念のため。