Hebikuzure's Tech Memo

2011年9月4日

Internet Explorer 9.02 への更新 – EricLaw’s IEInternals より

Filed under: Internet Explorer — hebikuzure @ 2:40 PM

Internet Explorer 9.0.2 Update 
http://blogs.msdn.com/b/ieinternals/archive/2011/08/12/internet-explorer-9.0.2-update-changes-file-protocol-and-cookie-naming.aspx


ちょっと前に Microsoft Answers話題になっていた EricLaw’s IEInternals の記事をを私訳しました。 8月の定例更新でリリースされた IE のセキュリティー更新プログラムをインストールすると、セキュリティー関連の二つの動作変更が行われるという記事です。詳しくは下記をご覧いただきたいのですが、HTTP/HTTPS プロトコルと File プロトコルのクロス プロトコル操作が制限される事と、Cookie の保存されるファイル名がランダム化される事の二つです。

以下の文章は EricLaw’s IEInternals の 8/12 の記事 Internet Explorer 9.0.2 Update を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


Internet Explorer 9.02 への更新

EricLaw [MSFT] 2011年8月12日 午前11時56分

火曜日 (訳注 米国時間8月9日) の Internet Explorer の更新により、IE9 の ヘルプ > バージョン情報 で表示されるバージョン番号が 9.02 に更新されます。この更新には複数のセキュリティーと機能の修正が含まれています; 修正内容の多くはKB2559049 の詳細セクションで解説されています。修正の内の一つにより、IE9 のダウンロード マネージャーはユーザーの権限が制限されているネットワーク ドライブに対して正常にファイルを保存できるようになります (訳注 http://support.microsoft.com/kb/2589171/en-us の修正)。別の修正では、IPv6 アドレスを広告しているサイトに対して、サイトまたはユーザーのネットワークの構成エラーのため Ipv6 で到達できない場合でも、IE8 で正しくアクセスできるようにします (訳注 http://support.microsoft.com/kb/2529406/ja の問題を含む修正)。

またセキュリティー関連の二つの変更により、サポートされているすべてのバージョンのブラウザー (IE6 から IE10 まで) で、Internet Explorer の目立たない動作に影響を与えます – 今回の記事では、この変更の両方について説明したいと思います。

HTTP/HTTPS ページは File:// プロトコルを利用できなくなる

この更新以前、Internet Explorer は HTTP – と HTTPS – で提供されるページは、file:// プロトコル スキームを利用して提供されるページをフレーム化 (例えば IFRAME の利用) したり、そのページに遷移したりできました。IE はリソースがローカル コンピューター (例えば file:///C:/temp/test.gif など) からの場合にのみ読み込みをブロックしていましたが、ローカル パスでないリソースは読み込みが許可されていました。このサンプル ページを IE 9.0.1 で表示すると以下のようになります:

同じページを IE 9.0.2 で読み込むと以下のようになります:

他のブラウザーも以前からクロス プロトコルの操作をブロックしています。以下に示すのはこのシナリオにおける Firefox 5、Chrome 14、そして Opera 11.5 の開発者コンソールの表示です:



既定では、この新しい制限は iexplore.exeexplorer.exe (Windows XP のサポートのため) のみに適用されます。またこの制限はインターネット ゾーンと制限付きサイト ゾーンで実行されている HTTP/HTTPS ページにのみ適用されます。

私たちは、影響を受けるゾーンには file:// によるコンテンツの利用に依存した一般的なサイトは存在しないため、この変更が互換性に関する深刻な影響を与えるとは考えていません。問題が発生した場合、ユーザーは HTTP/HTTPS のサイトを信頼済みサイト ゾーンに追加すれば、file プロトコルによるコンテンツはこの更新以前のように読み込まれるでしょう。

Cookie ファイル名のランダム化

通常のルールでは、Internet Explorer はインターネット サイトがコンテンツをローカル コンピューター上の予測可能な場所に保存できないようにしています。これは様々な種類の攻撃を避けるためです。一例として、このルールによりインターネット キャッシュはコンテンツをランダムに名づけられたサブフォルダーに保存しています。

この更新以前、Cookie はこの動作の例外でした—その保存場所は多くの場合十分にランダム化されていませんでした。一般的に、cookie のファイルは \AppData\Roaming\Microsoft\Windows\Cookies フォルダーに保存されており、ファイル名はユーザーのログイン名と @ 記号および cookie のドメインのホスト名の一部を使用していました:

ユーザー環境についての十分な情報があれば、攻撃者は所定の cookie の保存場所を推測でき、その情報を多段式攻撃に利用できます。

こうした脅威を軽減するため、Internet Explorer 9.0.2 では cookie のファイル名にランダムに生成された英数文字列を利用するようになりました。既存の cookie は更新により直ちにリネームされるではなく、cookie のデータが更新される際にリネームされます。この結果以下のようになります:

この変更についても、cookie のファイル名は今までもある程度動的であったため、顕著な互換性状の問題となるとは考えていません。Cookie ファイルを直接列挙したり読み取ったりする事は、今までもサポートされていません。その代り、cookie を取り扱いたいローカル アプリケーションは InternetGetCookieEx と IEGetProtectedModeCookie API を利用できます。また WinINET のキャッシュ列挙関数を利用する事も可能です。

-Eric

広告

2011年9月2日

プラグインなしでのブラウジング

Filed under: IE Blog — hebikuzure @ 12:46 AM

Browsing Without Plug-ins 
http://blogs.msdn.com/b/ie/archive/2011/08/31/browsing-without-plug-ins.aspx


マイクロソフトの日本語 IE ブログでも盛んに翻訳が掲載されているのですが、今日は最新の IE Blog の記事を私訳しました。標準の HTML5 の機能をできるだけ利用し、Flash などのプラグインが無い (または意図的に無効にしている) 場合でも正常に動作する Web サイト、Web アプリケーションを作成する事の重要性についての記事です。

以下の文章は IE Blog の 8/31 の記事 Browsing Without Plug-ins を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


プラグインなしでのブラウジング

2011年8月31日 午後5時

非常に幅広い種類のデバイスとその上のブラウザーでより多くのブラウジングが行われるようになっているため、より多くのユーザーがプラグインなしでのブラウジングを行うようになっています。Web プラグインを使わないブラウズをする利用者に優れたサイト エクスペリエンスを提供する事は、幅広い観衆にリーチしなければならないサイトにとって重要な課題です。HTML5 によって、モダン ブラウザーとサイトはプラグインなしでも優れたコンシューマ エクスペリエンスが提供できます。

“プラグイン” とはブラウザーの低レベル インターフェイスを利用してクライアントのネイティブ コードを実行するブラウザー拡張を幅広く意味しています。例えば、ここで示されているのは Webkit のアプローチで、IE では ActiveX コントロールとブラウザー ヘルパ オブジェクト (BHO) に相当します。Web サイトは幅広い種類のプラグインを利用しています; Adobe Flash は最も一般的なもののひとつです。

より一般的に

今日の Web ブラウジングの多くは単にプラグインをサポートしていないデバイスで行われています。プラグインをサポートしているブラウザーでは、プラグイン無しで実行する色々な方法を提供しています。IE9 では、一例として、ActiveX フィルタリングが含まれています。他のブラウザーでは、こちらこちらのような、プラグインを制御できるアドインが提供されています。プラグインは 64ビット版のブラウザー内で実行するようコンパイルできますが、多くの開発元は 32 ビット版ブラウザー内で実行できるバージョンしかリリースしていないので、64 ビット版ブラウザーの実行も、プラグイン無しのブラウジングを一般的にしている別の理由です。


64
ビット版 Windows 32ビット版と 64 ビット版両方の Internet Explorer を含んでいます

より良いエクスペリエンス

今日のサイトの多くは既に、プラグインが利用できない場合でも良好なエクスペリエンスを提供しています。例えば、Hotmail をプラグインが利用できない (64 ビット版のブラウザーのようにインストールされていないか、AvtiveX フィルタリングで無効にした) IE9 で表示しても、正しく機能します:


プラグイン無しの IE9 での Hotmail の受信トレイ

一部のサイトでは、プラグイン無しで機能させるために利用者の作業が必要です。例えば、YouTube をプラグイン無しで動作させるには、http://www.youtube.com/html5 にアクセスして “HTML5 試用版を有効にする” をクリックします。


プラグイン無しの IE9 での YouTubeHTML5 試用版を有効にする前 () と有効にした後 ()。右側のコンテキストメニューはビデオが HTML5 で再生されている事を示しています。

その他のサイトではプラグインが無効になっている場合、一部または全部の機能が無効になります。例えば、MSNBC.com と CNN.com ではビデオを除いて機能します。Gmail では現在の所、プラグインが無効になっている IE9 をブロックします。これは Gmail が IE7 以降利用可能な Web 標準の XHR を利用するのではなく、XHR ActiveX オブジェクトが利用可能かチェックしているためです。Web は IE7 の頃から相当に進化しているので、サイトは古いブラウザーや古いバージョンの標準規格に特化したコードに立ち戻り、再検討したいでしょう。


いくつかのサイトではアプラグインが無いと一部または全部の機能が無効になります。

機能の検知: サイト開発者が効率的に行う方法

多くのサイトはプラグインが利用できない場合でも良好なエクスペリエンスを既に提供しています。サイトがデバイスやブラウザーを特定する事によりこの動作が行われている場合、利用者にとって問題が生じます。例えば MSNBC.com のビデオは、PC 上のブラウザーがデバイスの User-Agent ストリングを送信するとプラグイン無しでも機能しますが、同じ PC 上の同じブラウザーが異なる User-Agent ストリングを送信すると機能しません:


Flash がインストールされていない Apple Safari と、iPad であると認識させた同じブラウザーによる MSNBC.com

利用者にとっては、開発者がブラウザーやその構成を特定するようサイトにハード コーディングするより、機能の検知とフォールバックを利用する方が望ましいでしょう。例えばプラグインが存在しない場合に HTML5 Video を利用する事は、利用者により良いエクスペリエンスをもたらすでしょう。多くのサイトは既に、プラグインが存在しない場合の広告の提供にこのフォールバックに相当する動作を行っており、それはこのソリューションが実用的でスケーラブルである事を示しています。

利用者のエクスペリエンスは、サイトが最初に標準規格ベースの機能のテストを行い、必要な場合にのみプラグインの利用にフォールバックするというベスト プラクティスに従う時、より良好になります。一例として、XMLHttpRequest の機能の検知についての良いパターンと悪いパターンを示します:

// BAD PATTERN: Don’t do this! (悪いパターン: このようにしない事)
var xhr = window.ActiveXObject
    ? new ActiveXObject("Microsoft.XMLHTTP")
    : new XMLHttpRequest();
// Best Practice: Use Native XHR, if available (ベスト プラクティス: 可能であればネイティブ XHR を利用する)
if (window.XMLHttpRequest) {
    // If IE7+, Gecko, WebKit: Use native object
    var xmlHttp = new XMLHttpRequest();
}
else if (window.ActiveXObject) {
    // …if not, try the ActiveX control
    var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}
else {
    // No XMLHTTPRequest mechanism is available.
}

別のコンテンツに手際よくフォールバックする事は、利用者のフラストレーションを高めないために重要です。例えば Gmail のビデオ チャットは Adobe Flash が存在しない場合に巧みにデグレードします。いくつかのサイトはユーザー エージェント ストリングやその他のブラウザー固有のプロパティーによりデバイスを特定する事でフォールバックを行っています。この短期的なソリューションはブラウザーや利用者のブラウズの仕方の変化に対応できません。(IMDB.com のような) デバイス上のブラウザーはプラグインをサポートしないとみなすアプリを構築するのは別のアプローチです。ユーザー エージェント ストリングは長期間にわたり提供すべき HTML やスクリプトを特定する方法としては信頼できるものでも、安定したものでもありません。

HTML5 の能力は、以前にも増してより多くのデバイス、より多くの構成で利用者が今日的な Web を体験する事を可能にしています。Web 開発者にとって、これはより多くの人々が自身のサイトを訪れる機会がある事を意味しており、プラグインが利用できない場合でも機能するようサイトを作成するモチベーションが大きくなっている事を意味しています。

—John Hrvatin, プログラム マネージャー, Internet Explorer

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。