FlashなどをIE仕様変更に対応させる

それにしても、世界中のユーザーとWeb制作者に多くの苦痛を強いるだけのこの裁判の成り行きには、疑問を感じざるを得ません。

同感…
500億くらい、もっとでしたっけ?Eolasの請求額。

日本でもあった某社のコンテクストヘルプもですが、これも特許?!と思わせる内容です。特許が技術革新に必用な仕組みであることは明らかですが「何これ!?」と思われる発明の権利が認められすぎではないでしょうか?

特にソフトウェア特許系は最悪で発明に値しないと思われる事例が多数です。結局、

誰でも思いつく技術を特許データベースで検索

無かったのでとりあえず特許として出願

特許になった

大手が技術を使っている。儲かりそうなので権利を主張してみる

の様な流れになっていると思います。

ブラウザに「オブジェクトを埋め込んで自動的に再生をする事」と「イメージファイルを埋め込んで自動的に表示する事」の違いは500億円の価値に値する発明、独占的に使用が出来る発明として認められべき特許なのでしょうか?

何れにせよ、基本的にはソフトウェア特許は認めるべきではないと思います。
ソフトウェアは著作権で守られているのですから。

PHPを5.1.3RC3相当にバージョンアップ

最近このサーバのPHPをPHP 5.1.3RC1相当バージョンアップしていたのですが、バージョンアップ前のPHP 5.0.5(+パッチ多数)と比べると明らかにApacheがクラッシュする回数が増えていました。とりあえずPHP5.1.3RC3相当にバージョンアップしました。NEWSファイルを見ると分かりますがRC1->RC3だけでもかなりの変更・修正があります。クラッシュがどの程度直っているかな…

K-Lite Mega Codec Pack

Real Playerはインストールしたくないのでインストールしていなかったのですが、そうも言っていられない状況になったので少しWindows Mediaで使えるCodecを探してみました。(Quick TimeはiTunesがインストールするので諦めてインストールしています。

K-Lite Mega Codec Pack
というCodecを集めた製品を見つけました。Codecのコレクションになっていて色々そろっています。

私にとってはこれだけCodecがサポートされていても無意味なのでRealPlayer Alternativeだけインストールしました。

inconsistent types deduced for parameter

久々にPostgreSQLの話です。プリペアードクエリのprepare文のエラーで次のようなエラーに出くわす事があります。

ERROR: inconsistent types deduced for parameter $8 DETAIL: timestamp without time zone versus text

パラーメタの番号は振り直している、と思い込んでいたのでこのエラーメッセージを見ても何故だろう状態なり、しばらく悩んでしまいました。ググってみても役に立ちそうなページが一つも無かったので書いておきます。

create table test (
t text,
i int
);

のテーブルの場合に

pg_prepare(‘testplan’, ‘select * from test where t = $1 and i = $1;’);

等とすると(pg_prepqreはPHP 5.1の関数)

ERROR: inconsistent types deduced for parameter

エラーが発生する、はずだったのですがこの例の場合はPostgreSQL 8.0.7で試してみてもエラーが発生しませんでした。自動的にキャストしてしまうのかな?調べてません。

とにかくこのエラーはプリペアードクエリの同じパラメータが互換性のコラムに利用された場合に発生するエラーです。

エラーメッセージが読んで字の如しなので有用なページが無いのでしょうね。

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アカウントが必用です。タイムゾーンを設定するだけで利用できるようになります。

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/

何が理由で乗り換えたのかに興味があったので読んでみたんですが、

—-

—-

という今まで聞いたことも無い理由で乗り換えたとのことでした。
# 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の障害情報メールも来ていましたがまだ正常に動作していないようですね。メンテナンスで問題発生、とメールには書いてありましたがバックアウトできないようなメンテナンスだったのかな?

追記:こんなメールが来ていました。

その次

9日朝ごろまで色々問題があったようです。

Webにポップアップは必要か?

備考:かなり古いブログですが公開し忘れしてい分です。

銀行サイトにアクセスすると偽のログイン用のポップアップを掲載するトロイの木馬が現れたそうです。機会があるたびに「ポップアップはしない方が良い」「アドレスバーを隠すのは最悪」と言っていましたがIT Proの写真を見ると「Window」としてポップアップするのではなく、「レイヤー」としてポップアップしているようにも見えます。Windowの部分にはアドレスバーが無いので画面全体のWindowsがポップアップとして表示されるのかも知れません。このようなトロイの木馬は予想はしていましたが実際に現れるのは困ったものです。

以前からログインにポップアップは有害と言っていましたが、海外とは言え実物が出てくるとリスクは以前より大きくなったと言えると思います。例え自分のサイトが価値の高いサービスをしていなくてもWebのデザインとしてポップアップは避けるべきと思います。普通のユーザがポップアップに慣れてしまうと偽のポップアップが開いたときに少しは「あれ?」と思っても偽のポップアップに重要な情報を記入してしまうかも知れません。

# トロイの木馬がインストールされている時点でほとんどアウトですが。
# しかし、こんな事をするよりキー入力をログした方が簡単に思えます。
# キー入力をログするより見つかりづらい、と思ったのでしょうね。多分。

随分前にも書きましたが、例えば振込みなど資金の移動が伴うような処理の場合、別のセキュアなデバイスで送金情報を表示してデジタル署名するような仕組みにしないと、オンラインバンキング等は攻撃対象になり続けるのでしょうね。PCやブラウザは信用できないですかね…

今思いついたのですがより簡易な方法として2重にメッセージダイジェストを取る方法だと、PCと携帯が通信しなくても安全性を確保できますね。

トランザクションのメッセージダイジェストをPCに表示
携帯のアプリでメッセージダイジェストをさらに共通の秘密情報含めた値でメッセージダイジェストを計算
利用者はダイジェスト値も入力してトランザクションを送信

と言った感じで処理すればよいですね。実際にPCと携帯が通信しなくてもよい分、今すぐにでも実装できますね。