近頃、TVとWeb技術の融合というネタが再び盛り上がっているようです。
TVとWebの融合というのは、インターネットに多くの時間を使う消費者側の我々にとっても、インターネットに多くの消費者を奪われた放送業界にとっても、とても有益に見えます。アマチュアのコンテンツが蔓延るインターネットに、長年培われた技術により生み出される質の高いコンテンツが流入することで、イノベーションが起こるかもしれません。
しかし、これらを取り巻く環境は様々な政治的もしくは技術的な課題を抱え、今後の発展をネガティブに語らざる得ないほど、深刻な状況としてメディアから報道されています。このあたり、本職に絡むような絡まないような割りとホットなネタということもあり、私はかなり気になっています。今日は勉強も兼ねて、生のソースを参考に、私なりの解釈を交えて説明してみようかと思います。
まず本編に進む前に、いくつかの登場人物（キーワード）について紹介します。
1. DRMとEME
DRM(デジタル著作権管理：Digital Rights Management)
DRMとは、デジタルデータ・コンテンツの著作権を保護するため、利用や複製を制御・制限するための技術の総称です。TVコンテンツなどをDVDへ複製する際のコピープロテクト技術が有名でしょう。
コンピュータは言うまでもなく、デジタルデータのコピーが容易に行える仕組みを持っています。狭義でのDRMは、データの記憶や別媒体への複製を行うための機器側に制限を加える機能を付与することで、著作者の許諾を得ない違法な配布を防ぐという仕組み、そのシステムを総称になります。
インターネットの場合、ハードウェア端末をコンテンツプロバイダーの制限下に置きにくく、Webブラウザなどのソフトウェアに組み込むのが主流となっています。GoogleのYoutubeがFlashからHTML5に移行できない、要因の一つにもなっています。
EME(暗号メディア拡張：Encrypt Media Extensions)
EMEはW3Cで標準化を進めている、一言で言うなら、暗号化されたコンテンツを再生するための機能を実現するための"仕様"になります。W3Cのドキュメントを少し崩して説明してみましょう。
EMEは、Web技術で保護されたコンテンツの再生が行えるよう、既存の仕様であるHTMLメディア要素のAPIを拡張させる仕様になります。シンプルなキーの解読から、著作者・コンテンツプロバイダー側による制限が必要とされる高水準なビデオの再生に至るまで、サポートの範囲は及んでいます。
この標準では、"コンテンツ保護"もしくは"デジタル著作権管理"の仕組みの定義は含まれていません。より正確に言うなら、例えば、単純なコンテンツの暗号化システムを扱うかのように、システムに対する【探す】や【選択する】や【対話する】といった操作を行うための、共通なAPIの定義になります。デジタル著作権管理のやり方にまで、この標準の影響は受けません。単にシンプルなキーを扱うシステムだけが、この標準に準拠することを求められています。
この共通APIは、暗号化能力のシンプルな傾向・特性のみをサポートし、証明や認証のアプリケーション実装・機能は、ページの製作者に委ねられます。また、コンテンツ保護を行う上で必要になる、例えば復号を行うために必要となるような【暗号化システム】と【ライセンス/その他のサーバ】の間で行われる特有のメッセージのやり取りについては、そのコンテンツが置かれたページ上で行われるのでなく、媒体の異なる別の通信手段を用いて、その目的を達成します。
ここまでがW3Cドキュメントの内容です。原文を少し私なりの解釈で崩してみたものの、それでも微妙にわかりにくいところが残っていますね。ただ、技術的に見て定石の守られた妥当な設計に思えます。このあたり、少し突っ込んでみましょう。
技術的観点から見たEME
まずはじめに断らなくてはいけないことがあります。コンテンツのコピーは、量子コンピュータなりの新しいテクノロジーが大衆に広がり一般化しない限り、100%防ぐことはできません。DRM技術は、単に仕組みを複雑化させて、コピーを難しくしているに過ぎません。
また、暗号化技術についても、100%なんてものはありません。どんな暗号であっても、いつかは効率的な方法を用いて解読できるようになります。一説に、暗号化アルゴリズムは開発・普及に5年、利用は5年と、計10年程度の寿命とも言われています。SSLを使ったから絶対に人に内容が読まれないなんてことはあり得ないのです。
しかし、それではどうやったって、インターネット上でセキュアな通信なんて実現できません。「無理だ」なんて言っても前には進めないので、2013年の今の時点では、セキュリティシステム（※暗号化・復号・認証・電子スタンプなど、セキュリティ保護を行う仕組みの総称）の作りの面では、以下３つの観点で評価し、これらが満足すれば「使ってもまぁ大丈夫でしょう」という扱いを受けます。
- 機密性：メッセージが暗号化され読み取りが困難になっていること
- 真正性：その時通信している相手が、本物であることを証明していること
- 完全性：メッセージが読み取られる段階で、改ざんされていないことを証明していること
法律準拠を目的とした媒体の電子署名とか、暗号付きzipとか、用途は様々なセキュリティシステムではありますが、少なくとも「通信技術」に限定すると、後者２つはハードルが低い方です。その瞬間だけ守られたらOKなわけで、なりすましや改ざんはよほど効率的なアルゴリズムを発明しない限り、うまくいきません。
しかし1の「機密性」については、第三者に傍受された場合、いつかは解読されるというリスクを孕んでいます。機密性だけは、「瞬間」でなく「長時間」であっても許容されるんです。例えばパスワードなどの情報は、その瞬間に解読できなくても、時間をかけてじっくり復号できたら、その時でもかなり使える情報になったりします。セキュリティリスクの面で見ると、端末の共用利用の禁止やネットワーク・サーバ機器の隔離といった対策で真正性・完全性を保護するような運用対策を行いますが、機密性についても同様で、パスワードの定期変更を求めたりします。
ただそれでも、コンピュータというのは日々性能が上がり、また効率的に復号するアルゴリズムも考える人が出てくるわけで、通信技術における「機密性」は、時間とともにリスクが変化します。しかもそれは線形的なものでなく、突然蟻がライオンに進化するレベルで変化します。パスワードの変更期間が２週間だったとして、それよりも早く誰にでも復号できる方法が発明されたら、「機密性」は完全に失われたと言っても過言ではありません。だからこそ、セキュリティシステムには、暗号化・復号のアルゴリズムだけは「差し替え可能」な状態にすることが求められるんです。
EMEの仕様では、セキュリティ管理システムは完全にスコープ外としています。JavaScript側からCDM(Content Decryption Module)と呼ばれる、復号アルゴリズムへのアクセスをブラックボックスで扱えるAPIを定義し、コンテンツ利用者のなりすまし防止、違法な復号のリスクを、リスクの真因とも言える「アルゴリズム」を差し替え可能にすることで低減させました。
かつてMicrosoftは、PPTPと呼ばれるVPNプロトコルを作り提供しました。一方でオープン系では、IPsecと呼ばれるVPNプロトコルが出現しました。PPTPがIPsecと殆どの機能面で同じ能力を持っていましたが、PPTPはセキュリティアルゴリズムが固定という致命的欠陥があり、使い勝手は良いが10年も使えない仕様として扱われてしまいました。
EMEにはもうこんなミスはありません。セキュリティシステムの"普通な動作"が決まってきた。言うなれば、普遍的として扱えるAPIの仕様を作れるほど、多くのセキュリティシステムはある程度の定石に従い動くようになりました。最小公倍数レベルのシンプルな仕組みでも、十分高いセキュリティシステムが構築できると判断できるようになったわけです。
ただ、EMEには一つ特徴的な部分があります。暗号化・復号に必要になってくるメッセージ処理のプロセスにおいて、【媒体の異なる別の通信手段】、つまりは、復号の機能を持つセキュリティシステムを、そのままWebブラウザの外に出してしまおうというものです。
先ほどのVPNの例では、復号のメカニズムが単純なアルゴリズムの差し替えのみで終わる、プラットフォーム完結型のものでした。しかしEMEはもっと柔軟で、暗号化・復号のメカニズムをWebブラウザのようなプラットフォームからは切り離して外に置くことで、ソフトウェアに限らず、場合によっては物理的手段を介在させることすらも許容してしまおうというものです。
ネイティブアプリケーションのライセンス保護の仕組みにiLokと呼ばれる製品がありますが、これはUSBの中にプロテクションキーを埋め込むという仕組みを持っています。物理的に、ライセンス保護のメカニズムを実装したものです。
コピープロセスの複雑化により不正コピーを防ぐというのが現代のコンピュータの主流のやり方だと説明しましたが、こうした物理的手段を用いられるとそれはもう強固です。暗号化・復号化のメカニズムを外に出すということは、それだけ柔軟に保護の仕組みを作り込める可能性を秘めており、今後のテクノロジーの進化の中で、悪意を持ったユーザにより様々なコピー手段を発明されたとしても、それに対応する多くのメカニズムを実装するだけのポテンシャルを持つことになります。
2. EMEに対する要求、コンテンツ保護技術への期待
EMEについては、米Google、米Microsoft、米Netflixの3社が中心となり標準化を進めてきました。Googleの「Youtube」、Microsoftの「Xbox Live」、Netflixはそれぞれのコンテンツ配信サービスに関わっており、仮にこの標準化がうまくいけば、全員のビジネスが成長するという同一のエコシステムに属していることになります。今後彼らのコンテンツビジネスを大きくするためには、既存の放送系メディアからのコンテンツ流入が必要になり、既に確立されているDRMを、Web技術にも取り込んでいく必要があります。
発案は2012年の2月で、W3C HTML Working GroupでのMLでした。最初の提案者はMicrosoftの社員である、Adrian Bateman氏です。もちろん、彼だけでなく多くの人間との共同の検討の元仕様作成が進められたのですが、メールの中には彼自身の想いも含めて、以下のような問題提起と提案がされました。
「多くのコンテンツプロバイダ、アプリケーション開発者は、AudioタグやVideoタグは使えないと言い続けてきた。その理由は、HTMLには強固なコンテンツ保護が欠けているからだ。この機能性が欠けている限り、彼らのアプリケーションをWebプラットフォームへ移すことができない。多くのコンシューマーが利用する端末は、ビデオ再生やユーザインターフェースで高いアドバンテージを得られているにも関わらず、未だ彼らのコンテンツ保護のソリューションは決まって、特定のデバイスに強く依存している状況である。我々は全てのHTMLプラットフォームからこういった偏りをなくし、共通のソリューションを探っていけるものと信じている。」
Adrian Bateman氏いわく、元を辿ると、この問題定義はWeb＆TV Interestグループから持ち上がり、彼らからのフィードバックから得られたものだという。「我々はこの拡張標準が、[ISSUE-179]に対する反対意見になることを望む。つまりは、HTML5のMedia要素に対するこの追加拡張が、param要素みたいな仕組みを通じて実装されるような事態になってしまわないことを、望んでいる。」と、汎用的であったり後付けのような感じではなく、AudioタグやVideoタグの一つの拡張機能として入り込む形で実装される必要があると、HTML Working Groupへ訴えかけました。
何事も無く進めば、今頃放送業界はもっと違う形に姿を変えていたかもしれません。しかし現実はそうもいきません。その訴えに対し、Ian Hickson氏が反論したことで、コンテンツ保護技術の論争がスタートしました。
私が個人的に一番注目すべきと思う点、それは、一見Google・Microsoft・Netflixが表立って推しているように見えるこのコンテンツ保護技術は、元を辿ってみると、実は放送側（TV業界）からの要求で始まっているというところです。
Web and TV Interest Group
2011年2月に結成。Web and TV Interest Groupは、WebとTV技術に関するディスカッションの場を提供し、Web上のサービスとTVのサービス間にある既存の活動を調査。その要件、潜在的な解決方法を判別し、Webが今後TVと共に有効に機能していけるよう活動を行なっている団体と、公式に説明されています。
実際にこのグループには、以下のようなプレイヤーが参加することを推奨しています。
- TVに関連したWebブラウザを開発するベンダ
- TVの放送局、TVのサービスを提供するプロバイダ
- TVや関連機器を製造するメーカ
- 放送、WebとTV、またそれらを統合するようなソリューションを開発している企業
- 放送とWeb技術の融合を、調査し開発する企業
- 放送を制御するための記述方法としてXMLベースの言語を活用しているソフトウェアベンダ、オープンソースプロジェクト、またこれらの言語を活用する利用者
- 放送とWeb技術の融合関連で、標準化を調査したいと考えている政治団体
- Web技術、放送、PC以外のデバイスを、スマートな方法で融合させることに興味を持つ学術研究者
当然、Webによる「通信」とTVによる「放送」の融合で、どのような標準化が行われるか意識する必要のある殆どのプレイヤーが、この団体の動きに関心を持ちます。議席には、Tomo-Digi、NTT、Opera Software、LG Electronics、Comcastの社員が座っています。まさしく、上記の一覧に適合した業界人です。
活動の主はMLなのですが、外には公開されていないため、一体彼らがどのような議論を行い、どのような標準を作ろうとしているかは、団体に所属していない人間には見えません。彼らの活動の概要についてはWikiなどのソーシャルツールに纏められていますが、情報としては少なく、詳細な動きまでは追えません。
Wikiをみる限り、現時点では、
- Testing TF
- Media API TF（具体的な実装部分の要件を整理）
- Stereoscopic 3D Web（他の3D等技術など標準技術に対する影響を監視）
- Timed Text（字幕関連）
また、過去には、
- Media Pipeline TF（メディアのフォーマット関連）
- Home Network TF（ホームデバイスとの連携）
- Web Media Profile TF（TVの開発に関するプロファイルの議論）
があるようです。ただし、それは本当に最新化されているか、外の人間である私にはわかりません。
彼らは、TVがWebの標準を活用する重要性を、強く主張しています。このことは、「W3C: Internet TV Needs Standards」というドキュメントに纏められています。
「インターネットTVはもはや、単純にインターネットコンテンツをテレビの画面に表示することを意味しません。インターネットTVはもはや、居間の巨大スクリーンでメールを送りたいなんていう発想で活用されるものではありません。インターネットTVは、多くのデバイスで利用可能な、単なるインターネットが利用できるデバイスから、統合サービスへと変化しました。今世界は、単なるデバイスとしてのTVから、あらゆるデバイスから利用可能なサービスとしてのTVへ移行しつつあります。W3Cは期待しています。TVのユーザエクスペリエンス向上のため、ローカル(例えばホームネットワークデバイス)からグローバル(例えばソーシャルネットワーク)へ結びつけるというシナリオが、ユビキタスなWebテクノロジーを創造すると。」
Media Pipeline TFとEME
Media Pipeline TF(MPTF)は、先ほど説明したWeb and TV Interest Groupのサブセットです。その目的は、WebとTVの間で使われることになるメディアフォーマットを活用するため、HTML5のvideo、audio、mediaのインタフェースについて、その要求事項を議論することです。また、APIの要求事項についても提案を行なっています。
既に、HTMLにおける【Adaptive bit-rate streaming】と【Content Projection】についての要求事項の整理は完了しており、MPTFは終了の状態にあります。メールは未だ盛んに、LCバグの解決と関連したトピックスに関する議論が行われていますが、定例会議は行われることがありません。
このTFは、以下２つの標準化を進めました。
- Adaptive Bit-Rate Control in Script (model 3) ：スクリプトによる適用ビットレートコントロール
- Content Protection：コンテンツの保護
後者のContent Protectionで行った標準化は、まさしく先に説明したあの「Encrypted Media Extensions(EME)」です。標準化自体はWeb and TV Interest Groupですが、先ほども言いました通り、このグループのMLは非公開です。
公式にこの仕様を標準化したいなら、当然ですが公で議論する必要があります。なので、この提案をHTML Working GroupのMLへ投稿しました。標準化が正式に決定する民主的プロセスについて、私はあまり理解していませんが、仕様にせよOSSにせよ、コミュニティにはキーパーソンがいるわけで、当然その人の了承を得る必要があるでしょう。
仕様の内容については、既に利害関係者の中だけで十分に検討が進んでいたようです。実際に最初に投稿されたEMEの仕様には、Adrian Bateman氏以外にも、GoogleのDavid Dorwin氏、NetflixのMark Watson氏の名前があり、まさしく彼らのエコシステムの実現のための明快な解が書かれていました。これがもし一社で進めていたら、クローズドなプロプライエタリな製品と何も変わらないはずですから、共同で進めてくるのは当然のプロセスでしょう。
しかしその初投稿で、Ian Hickson氏は技術的側面で批判しました。傍から見て、これが原因となり検討が遅れることになるわけで、そりゃもうステークホルダから見たら厄介なことこの上ないように見えます。日本のメディアでも、これはどうなんだろうという感じで取り上げました。しかし、標準化のプロセスから見てこれは大きな問題とは思えません。Ian Hickson氏のこの対応は、織り込み済みと言うべきかもしれません。このあたりの話は、もう少し後で語ろうかと思います。
3. EMEへの反発と戦いの終焉
Electronic Frontier Foundation
EFF(電子フロンティア財団：Electronic Frontier Foundation)は、デジタルコンテンツから著作権を廃す運動を行う財団です。彼らのサイトのaboutページを訳すと。
「インターネットからiPodに至るまで、テクノロジーは我々の社会を変形させ、テクノロジーは、スピーカー、大衆、クリエーターおよび消費者である、我々に力を与えてくれます。ネットワークの世界で、我々の自由が脅かされそうになった時、EFFは最初の防衛ラインとなります。EFFは1990年に設立され、のちにインターネットは殆どの人々にとってのレーダーとして機能し、言語の自由、プライバシー、イノベーションおよび消費者の権利を守るため、先端の課題に対峙し続け、その基盤を開拓してきました。黎明期から、EFFはあらゆるデジタルの権利に影響する重要な戦いで、公益を擁護してきました。」
彼らは、デジタルコンテンツの著作権のあり方に異議を申し立てる、右翼的立ち位置の団体なのかもしれません。だとすれば、彼らから見れば、EMEはまさしく攻撃すべき敵になるはずです。実際に彼らは、政治的観点からEMEの標準化に強く反発しました。
EMEを取り巻く政治的課題と行く末
技術側面ではIan Hickson氏が反発し、政治的側面ではEFFが反発を行いました。しかし最後、W3CはEMEの標準化にGOサインを出しました。戦いの最後、そこでは何が起こっていたのでしょうか？
先に政治的面で見てみましょう。カナダのジャーナリストCory Doctorow氏(@doctorow)のブログに「EFF files formal objection against DRM's inclusion in HTML5」という記事が投稿され、ここに解りやすく説明されています。一部を訳してみようと思います。
Cory Doctorow at 3:09 pm Wed, May 29, 2013
もう既にご存知の方も多いと思うが、W3Cによって標準化が進められている次バージョンのHTMLにDRMを含めることへ、強い反発が起こっている。EFF(Electroic Frontier Foundation)はW3Cに参加し、この活動に対する異議を記録してきた。EFFのDanny O'brienの記録は、この状況を非常に上手く説明している。
~~~~~~
EFFだけが、この状況に関心を持つグループでは無いんだ。キーとなる標準の開発者や2万を超える科学技術者、そういったEFFを含む多くのグループが不満を持ってて、それでもその反発をはね退けて、最終的にEMEはHTML Working Groupのスコープに含めると、W3Cのトップ陣によって決定されてしまったんだ。
W3Cの外部ではその決定に対する失望は、それはもう広大なものだけど、その一方でコンソーシアム内でのWebプラットフォームのDRM問題に対する議論は、沈黙の状態。W3Cの諮問委員会のメンバーたちは戦略的で、今もなお議論の場では沈黙を続けてて、無視されたコミュニティの多くは、密かに懸念を示しているよ。
~~~~~~
この件、W3Cのトップ陣が激しく非難されていますが、結局のところ、Webの実装プラットフォームを持つ者、今回のケースでは、Webブラウザを握っているMicrosoftやGoogleが、強い力を持っているというのが実情なのでしょう。
W3Cはビジネスを嫌ったりせず、むしろWebの発展のためにビジネスが入り込むことを許し、歓迎しているという話を聞いたことがあります。果たしてどこまでが事実かはわかりませんが、W3Cの議席に座っているのはまさしくGoogleなどのプラットフォームを持つベンダ企業なわけで、彼らの思惑についてはもはや自明なものに思えます。AdobeもPhoneGapの買収が完了した直後にスマートデバイスのFlashを捨てたくらいですから、この世界、標準化の力を持つのは標準化団体というよりも、実質的には【仕様の評価が可能なプラットフォーム】を持つ者だと言えるでしょう。プラットフォームを持つものが神と言っても、過言では無いのでしょう。
EMEを取り巻く技術的課題とその行く末
技術側面ではIan Hickson氏の批判が一番の波紋になっています。Ian Hicksonは、HTML5の仕様策定全般に多くの影響を与える人物です。現在はGoogleに所属していますが、かつてはOpera Softwareに所属していました。HTML5という企画の原案となるWeb Applications 1.0や、WHATWG設立にも関わっていたらしく、その前はNetscapeに所属していたという経歴を持ち、HTMLの標準化について、技術的課題からその本質まで熟知した人物でしょう。
で、そんなIan Hickson氏が口出ししてしまっては、当然、話はこじれます・・・が、実はこれはいつものこと。
前の政治的課題にも書きましたが、標準化で一番力を持つのは、プラットフォームを持つ者なわけで、標準化こそしたが実装が現れなかったら、せっかくドラフト化させてもすぐさまNote行きしてしまいます。特にHTML5は実装の中で課題を見つけて改善を行うという方法を行うので、実装があってこその標準です。実装ができないようであれば意味が無い。すぐに実現することが困難なほど実装に多くの労力を要するようでも、またパフォーマンスに影響を与えるものでもいけない。様々な複雑な背景を持つ中で、彼は、何を標準化すべきか、そしてそれは標準化するのに相応しいものなのか、十分に吟味する必要があります。だからこそ彼は、素直に仕様を通したりはできない。
そして、EMEについて、彼はWebの思想から外れていると考えたのでしょう。
彼は改善案を提示したのですが、その実装は、鍵交換にURIを利用し、暗号化アルゴリズムにAESを採用するというものでした。あくまで、Webブラウザの外にセキュリティシステムを出さないという方法です。Webブラウザで完結させたいという彼の想いが、この改善案から読み取れます。（もしかしたら翻訳や、その解釈に間違いがあるかもしれませんので、その際は私に一報下さい。）
しかし当然ですが、この方法には限界があります。AESで暗号化方式を縛るという時点で仕様には寿命があるのが明白ですし、悪意を持ったユーザによりプロテクト解除手法を発明されたとしても、それに対応するだけのポテンシャルがあるか未知数、可能性を閉じてしまっています。
この後どういった形で議論が進んだのか、私はMLを追えていないのでわかりません。私はセキュリティの専門家ではありませんので、現代における一般的なセキュリティシステムの考え方しか理解できておらず、その範囲内で問題点を語ったに過ぎません。セキュリティの専門家なら、もっと違う異論を唱えたかもしれません。Ian Hickson氏はこのことを理解してて、それでもこの方法を提示したのかもしれません、、が、果たしてれを、固いコンテンツ保護を求める放送業界が許してくれるのか。
2013年6月現在、W3Cの最新のドラフトの内容を確認しましたが、現在「ワーキングドラフト」の状態にあります。議論も継続的に行われているようですが、内容について大きな変化もなく、Ian氏の提案は受理されていないようです。このあたり、詳しい方がいれば聞きたいところ。私がMLを追えてその結末が理解できたら、この記事に追記することになると思います。
前編の最後に
っということで、この話もある程度は落ち着き、むしろそこそこに順調な感じで進めるようにも見えるこの議論ですが、国内で言う所のJASRACと同様、コンテンツの著作権に対して様々な反発の意識を持つ者は消えないわけで、今後も水面下で色んな政治的課題を抱え続けることになるのでしょう。技術面でも、セキュリティはイタチごっこなので、どこかでまた抜本的な見直しが必要になるタイミングが必ず来ることはほぼ決定事項だと思います。その時までHTML5という仕様が続いていれば、、ですが。もしかしたら、EV SSLのような別レイヤーでの課題かもしれません。今現段階で、その課題を我々に認識する術はどこにもありませんが。
さて、EMEなどコンテンツ保護技術に関する論争については、ひとまずこれで終わろうと思います。サクッと終わらすつもりが、なかなかの長文になってしまいましたね。
次回は国内の動きや世界的な動きも含めて、その状況を説明しようかと思います。来週末になるかな？？乞うご期待。
★参考 --------------
W3C：Encrypted Media Extensions
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Web and TV Interest Group
http://www.w3.org/2011/webtv/
W3C: Internet TV Needs Standards
http://readwrite.com/2011/03/28/w3c_internet_tv_needs_standards
Media Pipeline TF
http://www.w3.org/2011/webtv/wiki/MPTF
EFF files formal objection against DRM's inclusion in HTML5
http://boingboing.net/2013/05/29/eff-files-formal-objection-aga.html
IAN氏によるEMEの改善案
http://html5.org/tools/web-apps-tracker?from=7011&to=7012
