Google Analyticsとタイムゾーン
Google Analyticsのタイムゾーンのデフォルト設定はEST（アメリカ東部時間）のようでそのまましばらく使っていました。
さすがに使いづらいのでJSTに変更したのですが、アクセスログのデータはUTCで記録されていないのですね。時差分の時間がアクセス0として間が開いてしまいました。普通はタイムゾーンの設定を初めにすると思うのでこのような問題にあう事は無いと思いますが、使い始めの時にはタイムゾーンの設定をお忘れなく。
CSSXSS健在…
CSSを文字列として見れないようにしたMSの対策は不十分だったようですね… と言うよりリンク先の情報からすると確信犯で直していなかった（直っていなかった）ようです。
ということで、ユーザは自衛として他のブラウザを使う、サイト運営者はバグがあるブラウザに対するCSRF対策も行う必要がありますね…
Firefox/Mozilla/SeaMonkeyユーザのアップデートをお忘れなく。使えるMozillaプロジェクトの製品はFirefox 1.5.0.2、1.0.8およびSeaMonkey 1.0.1です。
http://www.mozilla-japan.org/projects/security/known-vulnerabilities.html#firefox1.5.0.2
ちなみにOperaは危険な脆弱性が有るので8.54が使えるバージョンだそうです。
http://www.itmedia.co.jp/enterprise/articles/0604/14/news069.html
Googleが音声検索コマンドで特許
多分、特許で訴えられない対策の意味合いが大きいとは思いますがGoogleが音声検索コマンドで特許を取得したそうです。
Googleでカレンダー
カレンダーが使えるようになったようです。
googleアカウントが必用です。タイムゾーンを設定するだけで利用できるようになります。
2006年はIEが安全に使えた日はまだ0日!?
【追記】
他のWindows XP+IE6の最新環境で試してみました。
ダウンロードした.htmファイルを開いてJavaScriptが実行されてもクッキーは表示されませんでした。表示しなかった環境はほとんど何も触っていない状態のWindows XP+IE6環境です。クッキーを表示するのは普段使っているノートPCのWinXP+IE6最新環境です。何か原因があるはずですが今のところ動作の違いの原因は分かっていません。参考までにIE関連で何が入っているかというと
-Google Toolbar (page rank付き）
-Norton Internet Security
-Java（JRE1.5）
が入っています。これらはクッキーを表示しないPCの環境には入っていません。少なくとも手元の環境では脆弱性が再現するWinXP PC1台と再現しないWinXP PC1台がありました。
そこでVMWare5でWinXP SP2をインストールした直後の状態のクローンを作成して試してみました。Windows Updateを全て適用、全ての更新が正しく適用されている事を確認後、「ファイルを開く」でJavaScript付き.htmを開いてみたところクッキーが表示されました。クッキーにアクセスできる脆弱な状態が普通なのか?それとも普通(?)はクッキーにはアクセスできないのかどちらなのでしょうね?
他にCSSXSS脆弱性が直っていないらしいので、どちらにしろ結局IEが安全では無い日は昨年から続いていますが。
———–
IEで意図しないJavaScriptが実行される問題の話です。
この問題は4月の定例パッチの直前に明らかになったので修正できなかった問題と思われます。結果として昨年末から既知の脆弱性があるままの状態が継続しています。
IEが拡張子ではなくデータの内容によって適当（と言うより不適切）に処理してしまう事は有名ですが、この問題は拡張子を優先してしまって問題になったケースと言えると思います。.htmを拡張子に持つファイルを送信する際にContent-Dispositionにattachment指定しても、これを無視してinlineでhtmlとしてファイルを処理してしまい(?)クッキーが漏洩してしまいます。今月のMSの定期更新にはこの件に関する修正が無いようだな、と思っていましたが修正されていないようです。
Googleはこの問題の為に.htmファイルをzipに圧縮するようにしたようです。
脆弱性のデモサイトがあります。
http://xs.vc/content-disposition/
にどのような動作になるかテストでるようになっています。
まず、ここにアクセスすると
SECRET=12456767890
とサイトが設定したクッキーがJavaScriptのAlartダイアログボックスで表示されます。ページ中の添付ファイル（Content-Disposition: Attachment）の.htmはAttachmentであるのでダウンロードされ、サイトが設定したクッキーを表示できるべきではありません。しかし、パッチ適用後のIEでも添付ファイルを開くと添付ファイル中のJavaScriptが実行され
SECRET=1234567890
とJavaScriptのダイアログが開いてしまいます。（Firefoxをデフォルトのブラウザにしている方はIEをデフォルトブラウザに変更してから試してください）
つまりこの脆弱性を利用すると、.htmファイルを添付できるサイトのクッキーを盗めてしまいます。.htmファイルを添付できる仕様のサイトはGoogleの様にzipに圧縮する等の対策を行わないとクッキーを盗まれます。ユーザとしての自衛は簡単で.htmファイルは「開かず保存してから見る」と大丈夫です。
この仕様（というかバグ）はWebメールや添付ファイルをサポートする掲示板、CMS、Wiki、バグ管理システム等で影響があります。私が現時点で把握している最新版IEのセキュリティ上の問題はこれだけです。IEセキュリティのリサーチをしている訳ではないので他にも脆弱性があるのかも知れません。他にあったら是非教えてください。
とにかく、私にが知る限りでも2006年になってからIEが安全に使えた日（攻撃可能な既知の問題が無かった日）はまだ無いです… 残念…
4月のIEのパッチ
MS06-013 Cumulative Security Update for Internet Explorer (912812)
では
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
に対応となっているので直ると思っていて良いのでしょうか?多分今度はきちんと直っているのでしょうね。
直るとされているセキュリティホールは次の通り。
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
CVE-2006-1245 – Multiple Event Handler Memory Corruption Vulnerability
CVE-2006-1388 – HTA Execution Vulnerability
CVE-2006-1185 – HTML Parsing Vulnerability
CVE-2006-1186 – COM Object Instantiation Memory Corruption Vulnerability
CVE-2006-1188 – HTML Tag Memory Corruption Vulnerability
CVE-2006-1189 – Double-Byte Character Parsing Memory Corruption Vulnerability
CVE-2006-1190 – Script Execution Vulnerability
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
CVE-2006-1192 – Address Bar Spoofing Vulnerability
出典：eEye Digital Security
かなり強力な穴ぞろいなのでユーザ全てが直ぐにパッチを当てて欲しいです。しかし今度のアップデートは「Flashが動かなくなる」という噂が先行しているのでアップデートしないユーザも多数でそうな気がします。
数がどれくらいになるか分かりませんが、
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
のお陰でスパイウェアをインストールされてしまったユーザはかなりの数になると思います。
IEは今年に入ってからリモートから攻撃可能な既知のセキュリティホールが無い状態が1日も無いですが、今度のアップデートで全部直っているのかな?
「重さ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日朝ごろまで色々問題があったようです。