Hebikuzure's Tech Memo

2011年3月25日

IE Blog: IE9 に向けたサイトの準備

Filed under: IE Blog — hebikuzure @ 8:58 PM

Preparing Your Site for IE9
http://blogs.msdn.com/b/ie/archive/2011/03/18/preparing-your-site-for-ie9.aspx


今日は Web 開発者向けの、サイトを IE9 に対応させるために必要な情報の記事を私訳しました。この分野では去年「Internet Explorer 9 Cookbook」の私訳を公開していますが、その後追加されたアーティクルも多いので、私訳についても順次追加・更新したいと思います。

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


IE9 に向けたサイトの準備

2011年3月18日 午前10時42分

私たちが何度も繰り返しこのブログに投稿してきたように、IE9 の最上位の目標の一つは開発者が同じマークアップとコード (HTML、CSS、JavaScript) をモダン ブラウザーでも利用できるようにする事です。同一のマークアップを可能にするという事の一部には、相互運用性と標準準拠のために既存の Web プラットフォームの動作が変更されるという意味も含まれています。私たちはプラットフォームへの変更について、プラットフォーム プレビューの期間中に開発者が早期にかつ何度も新しい機能を試してテストできるよう、IE9 Guide for Developers (訳注: 日本語版はこちら) にて公開し更新してきました。

私たちは岐山のサイトが IE9 の標準モードでも動作し続けるよう、新しいプラットフォームの機能を慎重に設計しました。その結果、多くの Web 開発者にとっては IE9 への準備のために特別の作業は必要ありません。

更新が必要なサイトのために、機能と動作の検知 (feature and behavior detection) を利用していない既存のサイトに最も影響のある変更をまとめました。これらの変更については IE9 Compatibility Cookbook (訳注: hebikuzure による一部記事の私訳はこちら)に資料があります。この資料は皆さんからのフィードバックを基に更新し続けています。皆さんの便利を考えて、特に影響の大きい変更については以下にリストアップしました。これらの変更についてのより詳しい情報は IE9 Compatibility Cookbook をご覧ください。

標準モードでの IE8 と IE9 の相違
全てのドキュメント モードにおける IE8 と IE9 プラットフォームの相違

もう一つの IE9 の重要な目標は、レガシーなドキュメント モードのコンテンツが以前のバージョンの IE と同じように動作し続ける事です。これについての唯一の例外は、セキュリティーのような領域での製品の品質を全般的に向上するための物です。

もしサイトを IE7 モードから更新するのであれば、Tony の Site Compatibility and IE8 の記事も参照する必要があります。

皆さんのために

もし互換性の問題で不明な点があったり、追加の情報が必要であれば、IE9 Compatibility Cookbook のサイトを通じてご投稿ください。

—Tony Ross と Marc Silbey, プログラム マネージャー, Internet Explorer

広告

2011年3月24日

IE Blog: Web 追跡防止: 最低基準と技術革新の機会

Filed under: IE Blog — hebikuzure @ 10:01 PM

Web Tracking Protection: Minimum Standards and Opportunities to Innovate
http://blogs.msdn.com/b/ie/archive/2011/03/14/web-tracking-protection-minimum-standards-and-opportunities-to-innovate.aspx


今回もオリジナルの公開日付が前後していますが、Internet Explorer 9 の「追跡防止」 (Tracking Protection) 機能や、Fierfox 4 に搭載されている “Do Not Track” 機能などについての記事です。この辺りの機能は、有用な効果とその影響のバランスについてまだまだ成熟しているとは言えない分野なので、各ベンダー間の議論と競争でより良い形に進めばと思いますね。

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


Web 追跡防止: 最低基準と技術革新の機会

2011年3月14日 午後4時25分

この記事では、なぜ Microsoft が自主規制を強くサポートしているのか、IE9 の最終版では第二の方法としてトラッキングの拒否 (Do Not Track User Preference) をどのように実装しているのか、そしてなぜ私たちがユーザーが自分のプライバシーと安全をコントロールし続けられるような最低基準を超える機能を提供し続けているのかについて説明します。

業界の複雑さと自主規制

Microsoft は業界としてのソリューションを提案するとともに、業界の自主規制能力を強化するための外部からの提案に応えるため、オンライン プライバシーと Web 追跡防止の分野に熱心に取り組んできました。

私たちはオンライン プライバシーと広告の持つ複雑さから業界の自主規制を強く支持しています。下に掲げる業界地図には、消費者が広告付きの Web サイトを訪問した際に関与するサードパーティーが示されています。これには広告代理店、広告サーバー、データー アグリゲーターとデーター サプライヤー、広告取引市場、需要側プラットフォーム、供給側プラットフォーム、検証サービスや分析サービスの企業が含まれています:

消費者を追跡から保護するために: 第一と第二の方法

消費者を追跡やその他のオンラインでのプライバシー上の問題から保護するためには、技術的な方法及び非技術的な方法の両方が必要です。私たちはこの問題に対する私たちの技術的アプローチである追跡防止 (Tracking Protection) を W3C に提案しています。W3C ではこの領域における Web 標準のための作業の次のステップについて議論するためのワークショップを 4 月に開催する準備をしています。

追跡防止 (Tracking Protection) はユーザーを追跡から保護するための、IE9 での第一の技術的方法です。完成版の IE9 には第二の方法として、幅広く議論されてきたトラッキングの拒否 (Do Not Track User Preference – W3C への提案に示されているように、DOM プロパティーと HTTP ヘッダーのいずれからも) も実装されます。

追跡防止は追跡に利用されるコンテンツをブロックする事により、消費者にプライバシー上の選択が確実に行える手段を提供します。追跡防止は規制や法的な介入なしに、(同意した) 消費者の役に立ちます。消費者は、信頼できる組織や個人の提供する追跡防止リストを選択できます。追跡防止リストの実例はここで確認できます。オンライン業界がより優れた – 調整力のある行動が推奨されるような – 透明性を持つ事により、消費者のための追跡防止機能はさらに向上するでしょう。追跡防止リストの作者がどのコンテンツが消費者にとって好ましくない追跡を行うのか容易に識別できるようになれば、消費者に代わってそのコンテンツを対象にできるでしょう。

業界の多数が、トラッキングの拒否 (Do Not Track User Preference) の意味は曖昧であると指摘しています。例えば Wall Street Journal は以下のように伝えています:

双方向広告協会 (Interactive Advertising Bureau 訳注: IAB) は、オンライン広告主を代表して、広告主がトラッキング拒否の通知を受け取った際にどのようにすれば良いのかの “基準は現在存在しない” と語っています。“マンハッタンの真ん中で狼煙を上げるように、それは多くの注意を引くでしょう。しかし誰もそのメッセージの読み方を知らないのです” と協会の副会長 Mike Zaneis 氏は語っています。

これら二つの方法は相互補完的な物です。ユーザー選好の意味をより明確にし、また執行と検証のプロセスを実行するのにどのようなプロセスと資金が必要なのかを政府が理解できるよう、W3C のプロセスを通じてこの二つの提案を高い品位の Web 標準として完成させるべく、私たちは幅広い業界のパートナーと共に作業を進めていきます。数多くのまた幅広い提案が行われるほど、権威ある、W3C のような合意のための作業部会がより重要になります。

追跡と広告、プロファイリングは重なり合う分野ですが、同一ではない事に気を付けるのは重要です。追跡の合意された定義は、業界と政府の幅広い議論の重要な成果物です。追跡防止や幅広く議論されたトラッキングの拒否 (Do Not Track User Preference) は広告や広告コンテンツに特有の物ではありません。

最低限の標準と技術革新

私たちはどんな場合も最低限以上の事ができる余地があると信じています。トラッキングの拒否 (Do Not Track User Preference) だけでは現在のワールドワイドの多数の消費者にとって十分では無いでしょう。

消費者が自身に見合った高いレベルのオンライン プライバシー保護を利用しコントロールできるようにする事で、私たちは Internet Explorer を際立った物にしていきます。

—Dean Hachamovitch, 副社長, Internet Explorer

2011年3月22日

IE Blog: HTML5 Video についての更新情報—WebM for IE9

Filed under: IE Blog — hebikuzure @ 5:36 PM

HTML5 Video Update—WebM for IE9 
http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx


オリジナルの公開日付が前後していますが、Internet Explorer 9 の HTML5 video がサポートするコーデックについての更新情報です。WebM コーデックのサポートが OS にインストールされていれば、IE9 で WebM の HTML5 vidieo は再生できるようになるという予告通り、実際に IE9 で WebM をサポートするコーデックがリリースされています。

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


HTML5 Video についての更新情報—WebM for IE9

2011年3月16日 午前11時59分

本日 (3 月 16 日) 、IE9 は業界標準の H.264 フォーマットに加え新規に WebM フォーマットでも HTML5 video が再生できるようになりました。WebM ProjectWebM Components for IE9 (Preview) のリリースにより、IE9 を使っている Windows の利用者は Web ページ内の WebM ビデオを再生できます。IE9 は現時点で両方のフォーマットの直接サポートに関与している唯一のブラウザーです。

新たに公開された IE Test Drive サイトの Video フォーマット サポート デモ では、双方のビデオ フォーマットを含む Web ページを色々なブラウザーを使って自分自身で試せます。また Web サイトの作者が訪問者の利用しているブラウザーとオペレーティング システムに応じてページのエクスペリエンスを調整する方法についても確認できます。さらに HTML5 video がサイトの作成者に対して、特に完全にハードウェア アクセラレーションされている場合には、ビデオを Web エクスペリエンスの一環として統合する機会を与えている事についても確認できるでしょう。


WebM コンポーネントをインストールする前のデモ ページの IE9 での表示


WebM コンポーネントをインストールして更新 (F5) した後のデモ ページの IE9 での表示

未解決の疑問

HTML5 video に関する以前の記事で利用者と作成者が直面している現在の状況について説明し、またその他の業界への対応によって WebM 支持者への質問を反映させました。状況を要約すると:

  • IE9 は、高品質で幅広く利用されておりWeb のために現時点で非常によく機能する H.264 を利用した HTML video をサポートしますMicrosoft はWindows 上の Firefox と Chrome の両方のために HTML5 video で H.264 をサポートするアドオンをリリースしました。“(このアドオンは他のブラウザーでの利用者の基本的なビデオ再生をサポートしていますが、追加の HTML5 ビデオ シナリオをサポートするには、他のブラウザーがより優れたビデオ コーデック拡張をサポートするか、または OS が提供するビデオ コーデックの直接サポートをする必要があります。)”
  • IE9 は サードパーティーの WebM サポートをインストールしている Windows の利用者に対して、WebM を使った HTML video をサポートします。
  • 業界として、我々は WebM の法的責任、リスク、サポートについての正当かつ未回答の疑問に直面しています。例えば:
    • 司法システムが知的所有権の問題を解決するまでの間、誰が消費者、企業、開発者の法的責任とリスクを負担するのか?
    • Google はいつどのようにして、真にオープンな Web 標準のコミュニティーが関与できる余地を作るのか?
    • デバイス、Web サービス、そして PC を通じた一貫性を復元するプランはどのような物か?
前進しよう

Web を利用し構築している皆さんにはイデオロギーではなく現実的で一貫したビデオ サポートが相応しいのです。このような疑問について取り組むことは、Web を前進させる作業の一環です。オープンな Web は開かれた対話と合意の産物です。この記事は Web を前進させるための対話の一環です。

—Dean Hachamovitch, 副社長, Internet Explorer

IE Blog: Internet Explorer 9 のネットワーク パフォーマンス向上 (その2)

Filed under: IE Blog — hebikuzure @ 4:13 PM

Internet Explorer 9 Network Performance Improvements
http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-explorer-9-network-performance-improvements.aspx


昨日の投稿に引き続き、Internet Explorer 9 の IE9 のネットワーク パフォーマンスに関連する動作変更についてのIE Blog 記事の後半を私訳しました。バックグラウンドでのコネクション確立やイメージの先読みなど、ネットワーク管理者にとって考慮すべき動作変更もあります。またキャッシュ動作の変更についても要注目でしょう。

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


Internet Explorer 9 のネットワーク パフォーマンス向上 (つづき)

(承前)

並列化によるネットワーキングの高速化

DNS 事前解決のセクションで説明したように、より多くの動作を並列化する事は全体のパフォーマンスを改善する重要な方法です。ブラウザーの動作のうちのいくつかの部分は本質的にシーケンシャルではなく、複数のスレッドで同時に動作させる事で時間を節約できます。

例えば、事実上すべてのサイトは最終的に一つのホスト名に対して複数の HTTP 接続を行うので、最初の接続が確立された際に “バックグラウンド” の接続を開始しておけば時間を節約できるはずです。このバックグラウンドの接続は、最初の接続が利用可能になるのを待たずに次の HTTP リクエストで利用可能となり、新しい接続を開始するための遅延なしに “ジャスト イン タイム” の接続が行えます。一つのホストに対して一つだけバックグラウンドの接続が開始され、この改善によりページの読み込み時間が数十から数百ミリ秒節約できます。

次に、接続のハンドリングに関して特定の状況で行われるブロック動作がありました。これはサーバーに対して複数の (例えば 3) 接続が開かれている際、ホストごとの接続数の上限である 6 に達しておらず正常に接続が開始できるはずであるのに、サーバーへの別の接続 (4 番目の接続)が、先行するリクエストが完了するまで遅延されるという動作です。動作の並列化を進めるため、この制限は削除されました。

最後に、イメージ ファイルのダウンロードを開始するための先読みダウンローダーが有効になったため、イメージのダウンロードのリクエストがネットワークに対してより高速に行える事を確認できました。HTML5 仕様のサポートにおいては、空のソースのイメージ (例えば <img src=”” /> のような) でネットワークへのリクエストが発生しないよう、イメージのダウンロードに関するコードを変更しました。

キャッシュ機能の拡張によるネットワーキングの高速化

もちろん、ネットワーク パフォーマンスを優れたものにする最も効果的な方法は、ネットワーク時間全体を減少させる事です。インターネット一時ファイル (Temporary Internet Files) のキャッシュは一度ダウンロードしたコンテンツを、ネットワーク越しに再ダウンロードする事なく利用できるようにします。私は昨年の夏、ブラウザーがキャッシュをより効率的に利用するための数々のキャッシュに関連した IE9 での改善について説明しています。本日は、これらの記事を踏まえて、キャッシュ機能に関するその他の拡張について説明します。

キャッシュ サイズ

Internet Explorer 6, 7, および 8 では Web コンテンツのキャッシュ サイズが既定ではディスク容量の 1/32 に制限されており、さらに IE7 と IE8 では既定のサイズは 50 メガバイトの上限が設けられていました。現実的には現在利用されているすべてのハード ディスクは 1.6 ギガバイトより大きいので、IE7 と IE8 のほとんどすべてのユーザーは 50 メガバイトのコンテンツ キャッシュの上限でブラウジングしていた事になります。

Internet Explorer 7 の既定の 50 メガバイトのキャッシュ サイズは、Windows Vista のタイムフレームの分析によりブラウザーのキャッシュがヒットする割合はキャッシュのサイズの増加により顕著には向上しない事が分かったために導入されています。

IE9 では、キャッシュ サイズの増加がヒット率の改善にほとんど寄与しないという驚くべき発見についてさらに研究するため、私たちのキャッシュ動作についてより詳細に調査しました。そこで私たちは、IE が何かをキャッシュ可能と判断し、またキャッシュを削除するアルゴリズムの動作に関連して、機能的な問題が多数ある事を発見しました。こうした問題を修正したところキャッシュ サイズの増加がより良いヒット率に結びつくようになったため、既定のキャッシュ サイズがより大きなサイズとなるよう、既定のサイズ決定のアルゴリズムを変更しました。

Internet Explorer 9 では既定のキャッシュ サイズは全体のディスク容量の 1/256 に制限されており、併せて 250 メガバイトの既定の上限が設けられています。この新しい割合は、小サイズのソリッド ステート ディスク (SSD) を持つローエンドのネットブックが (相対的に) 巨大なキャッシュにより影響を受けず、かつ大きなディスクを持っているデスクトップでは IE8 に対して 500% 大きくなるように設定されています。16 ギガバイトより小さなディスクでは既定のキャッシュ サイズが IE8 の50 メガバイトから IE9 では 64 メガバイトに増加します。64 ギガバイトより大きなディスクでは既定の上限の 250 メガバイトに設定されます。どのバージョンの Internet Explorer でも、ツール > インターネット オプション > 全般 > 閲覧の履歴の設定ダイアログ ボックスで、(8 メガバイトから 1 ギガバイトまでの範囲で) キャッシュ サイズの上限を手動で調整できます。

インターネット一時ファイル (Temporary Internet Files) が十分な空き領域を持つ大容量のディスクに置かれているのであれば、より大きなサイズのキャッシュにより恩恵が受けられるのではないかとお思いでしょう。これは確かに正しいのですが、調査の結果、上限値を 250 メガバイトより増大させても特定のブラウジング パターンでしか効果が得られない事が示されています。重要な点は、キャッシング システムで保持されるのは、内部的に凡そ 60,000 オブジェクトに制限されている事です。キャッシュのサイズとダウンロードしたリソースのサイズによっては、サイズの制限より先にオブジェクト数の制限に当たります。

技術ノート: Internet Explorer は二つのキャッシュを保持します。一つは保護モード (インターネット ゾーンと制限付きゾーン) で、もう一つは保護モード外 (イントラネット ゾーン、信頼済みサイト ゾーン、ローカル コンピューター ゾーン) で利用されます。それぞれのキャッシュごとに制限と上限が設定されていますので、キャッシュで利用される最大のディスク スペースの合計は、個々の制限の二倍になります。

キャッシュの削除

前述の通り、IE8 以前のキャッシュ削除アルゴリズムを分析したところ改善の余地が大きい事が分かっています。この分析の結果、Internet Explorer 9 のためにキャッシュ削除メカニズム (キャッシュ スペースを空けるため価値の低い項目を削除します) を大幅に書き換えました。新しいキャッシュ削除メカニズムは価値のある項目 (再利用される可能性の高いキャッシュ) を保持し価値の低い項目を削除するよう大幅に改善されました。

Internet Explorer のキャッシュ削除メカニズムはキャッシュの上限 (サイズまたはオブジェクト数) に到達すると起動します。その目的はキャッシュ内の価値の低い 10% (サイズによる) のオブジェクトを削除する事です。これはキャッシュ内のオブジェクトを列挙する事で動作します。最初のパスでは各オブジェクトに 0 から 66,000 のスコアを割り振ります。二回目のパスでは下位 10% のスコアにランクされた項目を削除します。

IE9 では最も価値の高い項目が確実に保持され、価値の低い項目が確実に削除されるよう、スコアの計算方法が大幅に改善されました。

66,000 ポイントの全体の内、40,000 ポイントはそのリソースがどれだけ最近に利用されたかにより決定されます。20,000 ポイントはそのリソースがどれだけ頻繁に利用されているかによって決められ、6,000 ポイントはリソースの更新期限が過ぎた後で条件付き再評価が行える検証情報 (Last-Modified や ETag のような HTTP レスポンス ヘッダー) の存在により決定されます。

さらに MIME タイプも計算に利用しました。スクリプト、CSS、HTML/XHTML リソースは得点の全てが利用されますが、他のリソース タイプ (例えばイメージやオーディオなど) は割り当てられた特典の半分しか利用されません。これによりページ読み込み時間に大きな影響のあるリソースが、影響の低いリソースに比べてキャッシュ中で長生きできるようになりました。

複数回利用されたキャッシュ項目は再利用ポイントが増加します。最大で 10,000 ポイントを獲得できますが、再利用は 12 時間以上の間隔で行われなければなりません。これにより短期間で頻繁に再利用されるようなリソース (例えば稀に訪問するようなサイトをブラウズした場合など) が、長期間にわたり頻繁に再利用されるリソース (例えば毎日訪問するサイトのスクリプトなど) と同じような得点を与えられる事が無いようになっています。

検証情報を持っている項目は検証ポイントを獲得しますが、検証の最大の効果はリソースの更新期限が経過した後にあります。有効期限付きでかつ検証情報が無いリソースの得点は 0 ポイントになります (再利用されないか再検証されないためです) が、検証情報を持つリソースではスコアの 70% が残ります。検証情報のある有効期限の過ぎたリソースは、キャッシュされたリソースが最新であるかブラウザーが簡単に再チェックできるため、スコアの大半が残るのです。再チェックの際にサーバーは、キャッシュされたコピーを再利用してよい事を示す少量の HTTP:304 レスポンス (ボディ無し) を返す事ができます。

キャッシュ削除メカニズムはその他のいくつかの特別な状況にも対応しています。例えば、どのようなコンテンツもダウンロードから 10 分間は削除されません。またキャッシュ サイズを超えるリソース (例えば 4 ギガバイトの ISO ファイルのダウンロード) は、ダウンロードが正しく行えるよう一時的に削除の対象外になります。

コンテンツ フィルタリングによるネットワーキングの高速化

Internet Explorer 9 には新たに追跡防止と ActiveX フィルターの機能が搭載されています。いずれの機能も不要なコンテンツのダウンロードと実行を防ぐ事によりブラウザー パフォーマンスを全体として向上させます。例えば、ある人気があるニュース サイトを読み込む際、ActiveX フィルターおよび一般的な追跡防止リストを一つ有効にすると、ページの読み込みが著しく高速化します:

HTTP リクエスト数 送信バイト数 受信バイト数 ページ読み込み時間
フィルタリング無効 168 98.5k 1.9M 7.5 秒
フィルタリング有効 138 71.7k 1.6M 3.6 秒

ブラウザーがページの表示に重要ではないコンテンツのダウンロードと実行を行わずに済むため、ページ読み込み時間は 50% 以上向上します。

まとめ

ご覧になったように、私たちは世界最速のブラウザーを作るという私たちの技術的目標を達成するため、Internet Explorer のネットワーク パフォーマンスの改善について幅広い取り組みを行ってきました。もちろん、利用しているネットワーク接続の速度は引き続き重要な要素ですし、Web 開発者はパフォーマンスのためのベスト プラクティスに従うべきでしょう。しかし IE9 のネットワーク パフォーマンスの改善は幅広い範囲の Web ページの読み込み時間を大幅な高速化するのに役立つでしょう。

—Eric Lawrence

2011年3月21日

IE Blog: Internet Explorer 9 のネットワーク パフォーマンス向上 (その1)

Filed under: IE Blog — hebikuzure @ 9:39 PM

Internet Explorer 9 Network Performance Improvements
http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-explorer-9-network-performance-improvements.aspx 


Internet Explorer 9 ではパフォーマンス向上のためにネットワーク関係の動作が色々と最適化 (変更) されています。DNS の先読み (事前解決) やプロキシ関係の動作変更、リクエストの並列化などは特に企業内のネットワーク管理者にとっては、ネットワーク全体の最適化を考える上で重要と思われます。今回はこうした IE9 のネットワーク パフォーマンスに関連する動作変更についてのIE Blog 記事の前半を私訳しました。後半も引き続き訳して公開しますので、併せてご参照ください。

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


Internet Explorer 9 のネットワーク パフォーマンス向上

2011年3月17日 午前10時03分

ブラウザーのネットワーキング サブシステムはハイ パフォーマンスの Web エクスペリエンスを提供するために決定的に重要なコンポーネントです。本日の記事では、これについていくつかの実際の計測値に基づいて、“高速” なネットワーク環境であっても、ネットワーク時間はページの読み込み時間に関係する他のサブシステムに対して大きな位置を占めている事を示したいと思います。次に、Web ブラウザーがどのようにネットワークを利用するのかについて簡単に解説し、高速なページ読み込みのため Internet Explorer 9 で実現された向上についての概要を示します。

現実のブラウジング パフォーマンスとネットワーキング

昨年、私たちはページ読み込み時間の全体がサーバーからコンテンツを取得するための時間にどれだけ関係しているのかを計測するため、主要なサイトについて調査を行いました。テストは “高速” と考えられる環境 – Intel Core2 2.4 ギガヘルツと 20MB/秒のケーブル モデムに接続する 802.11N ネットワーク – で実行しました。それぞれのサイトについて 4 回の測定で、ページ読み込み時間 (about:blank からトップ レベルのドキュメントの完了まで) を、PLT1 (キャッシュがクリアされた状態) と PLT2 (キャッシュ済みの状態) の両方について、“現実的な” 状況と “理想的な” 状況 (ネットワーク時間が 0 になるよう全てのリソースがローカル コンピューター上のプロキシから返される環境) で計測しました。

6 つの代表的なサイトでの結果を以下のグラフでそれぞれのサイトごとに示しました。それぞれの円グラフは “非ネットワーク” 時間 (赤) と “ネットワーク” 時間 (青) の比率を示しています。外側の円は最初にページを読み込んだ際 (“キャッシュがクリアされた状態”) を、内側の円は二回目の訪問 (“キャッシュ済みの状態”) を示しています。

ご覧になれるように、幅広いネットワーク パフォーマンスの比率が見られます。キャッシュを良く利用しているサイト (具体的には三列目のサイト) では、大半のコンテンツがブラウザーのキャッシュにローカルにキャッシュされているため、PLT2 ではネットワークにごく少しの時間しか費やされていません。他のサイトでは、PLT2 の全体の読み込み時間は PLT1 より速くなっていますが、単一のネットワーク リクエストであっても相対的に長時間を要するため、ネットワーク時間が依然としてページ読み込み時間中最大の要素になっています。

これらの結果は、“高速” なネットワークであっても、ネットワーク時間はページ読み込み時間で支配的である事を示しています。最初のページ読み込みでは、ダウンロードはページ読み込みの 73% に上っており、その後の再読み込みでもページ読み込み時間の 63% はリソースの読み込み待ちに費やされています。

別の言い方をすれば、これらのサイトの最初の読み込みでは合計 17 秒かかっていましたが、ダウンロード時間を除くと 4.6 秒になります。再読み込みでは、これらのサイトは 6.7 秒で読み込まれ、ダウンロード時間を除いた時間は 2.5 秒でした。

以上のようにネットワーク パフォーマンスの “現実の” インパクトについて見る事ができましたので、ネットワーク遅延の原因について確認していきましょう。

ブラウザーのネットワーキング入門: どこがボトルネックなのか

ブラウザーが Web サイトを読み込むごとに、その動作の背後で複雑な手順が実行されています。この手順について簡単にまとめると以下のようになります:

コンピューターが Web プロキシ環境下で実行されていない場合は、ブラウザーは入力されたホスト名 (例えば http://www.microsoft.com) をネットワーク アドレス (例えば 65.55.12.249) に変換するため DNS 検索をネットワークを使って実行します。ブラウザーは目的のアドレスに対して TCP/IP コネクションを確立する必要があります。

コンピューターが Web プロキシ環境下で実行されている場合は、ブラウザーは最初にプロキシを検索する必要があります。プロキシはブラウザーの設定で直接指定されているか、Web Proxy Auto-Discovery Protocol (WPAD) と呼ばれるプロセスを通じて検索されます。プロキシのホスト名が確認されると、ブラウザーは DNS 検索を使ってプロキシのホスト名をネットワーク アドレスに変換します。その後ブラウザーはプロキシ サーバーとの間にネットワーク コネクションを確立します。

URL が安全な接続 (HTTPS) の場合は、SSL または TLS のハンドシェイクが必要となり、サーバーから示された証明書の検証が必ず行われます。その結果、証明書チェインに含まれる証明書のいずれについても無効になっていない事を確認する (“失効確認” と呼ばれる動作) ための、証明機関に対する一つまたは複数の追加のネットワーク リクエストが行われます。

接続の確立に成功したら、ブラウザーは HTTP リクエストをサーバーに送信します。リクエストを受信したサーバーは、リクエストされたファイルを読み込み (または生成) して、クライアントに送信を開始します。ドキュメントが HTML ファイルであれば、通常 Web ページを完全に表示するために読み込みが必要な別のリソース (例えばイメージ、スクリプト、スタイルシート) への参照が含まれています。ページ内のそれぞれのリソースへの参照ごとに、ブラウザーは必要なリソースのダウンロードのために前述の複数の手順を繰り返します。

こうした操作の多くは直列的 (シリアル) に実行される必要があります (例えば最初に DNS 参照を行って IP アドレスを取得しなければ TCP/IP 接続を確立できません) ので、一つの操作の遅延はページの読み込み時間を劇的に増加させます。

一部の場合、遅延のリスクを軽減するために操作を並列化 (パラレル化) したり、キャッシュしたりできます。Internet Explorer 9ではこの記事の後半で解説するように、パフォーマンスを向上するためこの両方のテクニックを使っています。

DNS 事前解決によるネットワーキングの高速化

ドメイン ネーム システム (DNS) によりクライアント ブラウザーはホスト名をネットワーク アドレスに変換できます。このプロセスでは数ミリ秒から数秒を要します。最近の研究ではアメリカでの中央値は凡そ 150ミリ秒であるとされていますが、この時間には大きな幅があります。ブラウザーはリモートのアドレスを確定しなければネットワーク接続を確立できませんから、DNS はネットワーク パフォーマンス上の最初のボトルネックです。

Internet Explorer 9 には DNS パフォーマンスを向上させるための三つの最適化が含まれています。これらの最適化は、複数の DNS リクエストが並列化できるという事実に基づいています。

アドレスバー DNS 事前解決

アドレスバーに 3 文字目が入力されたところで、Internet Explorer はドロップダウン リストにある上位 5 つのホスト名の DNS 解決を発行します。これらの名前解決の結果は、後から素早く再利用できるようローカル オペレーティング システムのキャッシュに蓄積されます。この方法により、上位のサイトに移動した場合ブラウザーは一歩先んじたスタートを切り、DNS の結果が返るのを待つ時間を節約できます。

訪問済みサイトでの投機的な事前解決

ページを訪問すると、Internet Explorer 9 はページによって利用されたコンテンツのダウンロードに利用されたホスト名のリストを、ページ履歴の項目に関連付けます。

例えば IE Blog を読み込むと、HTML では 5 つの他のサイト (i.msdn.microsoft.com, cdn-smooth.ms-studiosmedia.com, go.microsoft.com, ieblog.members.winisp.net, and silverlight.dlservice.microsoft.com) を参照します。

Internet Explorer 9 はこれら 5 つのホスト名を、履歴の IE Blog の項目に記録します。その後のブラウザー セッションで IE Blog に移動すると、Internet Explorer は blogs.msdn.com サーバーへの接続の確立と並行して、これら 5 つのホスト名の DNS 解決リクエストを直ちに発効します。これによりブログの HTML がサーバーから返ってきた時点で、ページに埋め込まれたリソースのために必要なネットワーク アドレスはローカルの DNS キャッシュに含まれています。

ページ始動の事前解決

Internet Explorer は Web 開発者が LINK REL=PREFETCH 要素で指定したホスト名をすべて解決します。例えば、以下のようなマークアップでは:

<link rel="prefetch" href="http://www.example.com/someresource.htm"&gt;

…Internet Explorer は http://www.example.com の DNS 解決を開始します。これにより、www.example.com への接続が後で必要になった場合、DNS 参照は既に行われており、ブラウザーはアドレスの解決を待たずに直ちにサーバーへの接続を開始する事ができます。

プロキシの改善によるネットワーキングの高速化

多くの企業ユーザーは Web のブラウズにプロキシ サーバーを利用するよう構成しており、プロキシはネットワーク パフォーマンスに影響を与えます。そのため、プロキシが必要となる環境のネットワーク パフォーマンスの向上のために二つの大きな変更を行いました。

第一に、Internet Explorer のプロキシ識別プロセスを、タブ プロセスから単一のフレーム プロセスに移動しました。これにより Web Proxy Auto-Discovery (WPAD) 機能の動作 (これには数十ミリ秒から数秒かかります) が、どれだけの数のタブを開くかにかかわらず、ブラウザー プロセスで 1 回だけになります。これにより同時にある程度のCPU 時間とタブ プロセスごとに 500 キロバイト位のメモリーも節約できます。プロキシ識別の向上は、新しいブラウザー タブでサイトを開く際に特に顕著な効果があります。

第二に、Internet Explorer 9 はプロキシごとの接続制限数を 12 に増加させています。これによりブラウザーは Web プロキシを利用する際 6 接続に制限されていた IE8 に比べてより多くのダウンロードを並行して行う事ができるようになりました。ブラウザーのホスト単位の接続数は 6 に制限されていますが、多くのサイトは複数のドメインからのリソースを利用しているので、このプロキシごとの接続制限数の増加にはメリットがあります。

(つづく)

2011年3月20日

IE9 のより速くより安全なダウンロード

Filed under: IE Blog — hebikuzure @ 7:49 PM

Safer and Faster Downloads in IE9 
http://blogs.msdn.com/b/ie/archive/2011/03/10/safer-and-faster-downloads-in-ie9.aspx


Internet Explorer 9 ではようやく他のブラウザーと同様のダウンロード マネージャーが搭載され、ファイルのダウンロードの手順が以前のバージョンから大きく変更されています。今回はその IE9 のファイル ダウンロードについてのIE Blog 記事を私訳しました。

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


IE9 のより速くより安全なダウンロード

2011年3月10日 午後3時50分

IE9 のダウンロード通知バーは、あなたがブラウジングに集中でき、ダウンロードが邪魔にならないようになっています。これは大半のダウンロードに対応できる “クイック ダウンロード” として合理化されています。

全体として、IE9 のファイル ダウンロード エクスペリエンスは以下のようになっています:

  • 合理化されたエンド ツー エンド ダウンロード フロー
  • ダウンロードの一時停止と再開が可能
  • SmartScreen アプリケーション評価を利用した信頼性と信用性の向上
  • シンプルな履歴表示によるダウンロード ファイルの容易な管理
フィードバックへの回答

長年の間、Internet Explorer のダウンロード エクスペリエンスについて (このブログを含む) 複数のチャンネルから熱心なフィードバックを頂いてきました。特に、ユーザーの皆さんはダウンロードの一時停止と再開及び過去にダウンロードしたファイルへの容易なアクセスを求めていました。これらの機能は不安定または低速のネットワークや従量制のネットワークで特に有益です。

このフィードバックに加え、ユーザーがダウンロードするファイルの種類は年とともに変化しています。現在多くのユーザーはファイルをダウンロードしてローカルに保存するのではなく、写真やビデオ、音楽などのコンテンツをオンラインで利用するようになっています。

こうした背景を基に、私たちは IE9 のダウンロード エクスペリエンスを、新しい通知バーを使った軽量で不要な要素の無い簡潔な物にする事を決めました。詳しい人のための詳細機能や追加のオプションは、ダウンロード マネージャーを通じて利用可能としました。

この記事では、新しいダウンロード通知バーと有害なダウンロードから皆さんの安全を守る Internet Explorer 9 のセキュリティー チェックについて説明します。またこの後の投稿でダウンロード マネージャーの詳細な機能について解説する予定です。

簡潔で素早く使いやすいユーザー エクスペリエンス

私たちはダウンロード マネージャーを、ブラウザーでの最も一般的な二つのダウンロード シナリオに最適化されるよう設計しました:

  • ファイルを保存したい (卒業写真、領収書、納税申告書など)
  • ファイルを一度だけ利用したい (転送された電子メールの添付ファイル、アプリケーションのインストーラーなど)

“保存” したいダウンロードに対して、IE9 は合理的な “保存” オプションを提供しています。このオプションではファイルはダウンロード フォルダーに保存され、ダウンロード マネージャーの履歴リストに項目が追加されます。これにより後でダウンロードしたファイルを見つけるのが簡単になります。

“一度だけ利用” したいダウンロードでは “開く” または “保存” をクリックできます。ファイルはダウンロード履歴には表示されず、インターネット一時ファイルのキャッシュから直接実行または開かれます。このモードは簡潔で動作が軽く、ファイルをすぐに利用したい場合に向いています。この動作により、ダウンロード フォルダーと履歴の表示には再度表示/利用しないアイテムが含まれず、不要な物の無い状態が保たれます。

次の短いビデオは通知バーによるファイル ダウンロードを合理化、SmartScreen アプリケーション評価のフィードバック、その他のダウンロード マネージャーの新機能について解説しています。

http://ie.microsoft.com/testdrive/IEBlog/2011/Mar/safdii-video1.mp4 (※ 動画ファイルへの直リンクです)

通知バーの制御によるサイトへの集中

サイトが目立つようにするという IE9 の目標のために、IE は最小限の邪魔しかしない事によりサイトに集中できるようにしています。ダウンロード プロンプトに対処するため現在見ているページから意識を切り替える必要はありません。

通知バーがダウンロードの進行状況を表示している間、ブラウズを続ける事ができます:

ダウンロードが完了すると、IE はそれを知らせてくれます:

そのため、通知バーに表示されるダウンロードの全段階で、余分なウィンドウがあちこちに表示される事はありません。ほとんどのダウンロードにおいて通知バーからコンテンツのダウンロードや利用が行え、ダウンロード マネージャーを表示する必要はありません。

最小のクリック数

ダウンロード エクスペリエンスを高速にするために、ダウンロードしたファイルを利用するために必要なクリック数を減少させています。まず以前のバージョンの IE でファイルを保存して開くのに必要だった手順を見てみましょう:

  1. 開始: ファイルのダウンロードを開始するためリンクをクリックします
  2. 開始: 継続するため情報バーで “ファイルのダウンロード” をクリックします
  3. 開始: ダウンロード ダイアログで “保存” をクリックします
  4. 指定: “名前を付けて保存” ダイアログで、保存先フォルダーを指定します
  5. 切り替え: ブラウジングを続けるために Web ページに切り替えます
  6. 通知: ダウンロードが管理用したらダウンロード ダイアログに切り替えます
  7. 開始: ダイアログで “開く” を選択します

通知バーへの統合及びその他の改善により、7 つの異なるユーザー アクションから手順と考え方を単純にできる事がわかりました。

  1. 開始: ファイルのダウンロードを開始するためリンクをクリックします (IE8 と同じ)
  2. 開始: ダウンロードバーで “保存” をクリックします
  3. 通知と開始: ダウンロード バーがダウンロードの進行状況と完了を表示します。完了したらユーザーは “開く” または “実行” をクリックします

以下のような最適化により、クリック数はさらに削減されます:

  • ユーザーが意図しないと思われるダウンロードをブロックするための情報バーとページの更新動作を取り除きました。新しい通知バーは同様の保護を、より洗練された方法で提供します。
  • 保存” を選択するごとに保存先のフォルダーを選択しなければいけない動作に代えて、IE9 ではファイルを既定のダウンロード フォルダーに保存します。既定以外のフォルダーに保存するには、“保存” ボタンのドロップダウン リストから “名前を付けて保存” をクリックします。

信頼と信用ができるダウンロードを行う

残念な事に、ダウンロードするファイルによってはコンピュータに有害であったり、個人情報を盗み取ろうとしたりします。Internet Explorer 9 には SmartScreen アプリケーション評価 と呼ばれる新機能が含まれており、これにより危険なダウンロードを避けると共に良い評価を持つファイルのダウンロードは便利に行えるようになっています。

既知の悪意のあるファイルは SmartScreen によってブロックされます:

潜在的に危険な、特殊なダウンロード ファイルでは、IE9 は危険性について警告します:

拡張された SmartScreen 機能に加えて、IE9 は引き続き Microsoft SmartScreen の利用、ダウンロードしたファイルのウイルス対策ソフトによるスキャンAuthenticode デジタル署名の検証による保護を提供しています。

私たちは、すべてのセキュリティー チェックの結果に基づく最終的な一つの推奨のみが表示されるよう、IE9 のセキュリティー警告を単純化しました。

向上したエクスペリエンス

新しいダウンロード エクスペリエンスは使いやすく邪魔にならないためブラウジングのエクスペリエンスを向上させます。ダウンロード マネージャーのさらなる機能について解説する予定の今後の記事にも注目してください。

IE9 の新しく洗練されたダウンロード エクスペリエンスをお楽しみください。そしていつでも皆さんからのフィードバックをお待ちしています。

—Ritika Virmani, プログラム マネージャー, Internet Explorer

IE Blog: Internet Explorer 9 セキュリティー Part 3: いつも表示するサイトでのブラウズのセキュリティー強化

Filed under: IE Blog — hebikuzure @ 12:51 PM

Internet Explorer 9 Security Part 3: Browse More Securely with Pinned Sites
http://blogs.msdn.com/b/ie/archive/2011/03/11/internet-explorer-9-security-part-3-browse-more-securely-with-pinned-sites.aspx


「Internet Explorer 9 Security」のパート 3 です。この後も IE9 リリース関連で公開された IE Bolg の記事の私訳を引き続き公開予定です。

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


Internet Explorer 9 セキュリティー Part 3: いつも表示するサイトでのブラウズのセキュリティー強化

2011年3月11日 午前9時49分

IE9 ベータ版で導入されたいつも表示するサイトの機能は、お気に入りのサイトを Windows 7 のユーザー エクスペリエンスに統合する優れた方法です。それだけでなく、オンライン バンキングのようなセキュアなアプリケーションについていつも表示するサイトを作成して利用する事に、5 つの大きなセキュリティー上の利点があります。

第一に、信頼しているサイトをタスクバーにいつも表示して、安全な利用のためにいつも表示されているアイコンを利用するように習慣づければ、電子メール内のリンクをクリックする事を避けられ、偽のサイトに誘導しようとするフィッシング攻撃の可能性を減少させる事ができます。この “安全な起動” の動作は不正なサイトに移動してしまうアドレスバーでの入力間違い (typo) を減少させる効果もあります。

第二に、いつも表示するサイトはデスクトップのブラウザー時独立した、独自のブラウザー セッションで実行されます。これは、いつも表示するサイトのブラウザー インスタンスでセットされたセッション Cookie が、通常の IE ブラウザーのウィンドウ内で実行されているタブからは潜在的に不正利用されない事を意味します。

第三に、いつも表示するサイトはアドオン ツールバーやブラウザー ヘルパー オブジェクト (BHO) なしに実行されます。これによりブラウザーへの攻撃対象領域が減少します。実行されているコードが減少すれば、悪意のある、あるいは感染を狙うサイトにとって攻撃の標的が少なくなります。

第四に、HTTPS サイトをタスクバーにいつも表示するようにすると、セキュアでない HTTP から HTTPS へのリダイレクトを避ける事ができます。例えば、bank.example.com とアドレス バーに入力したとしましょう。最初にリクエストはセキュアでない HTTP プロトコルを使って http://bank.example.com に向けてネットワークへ送信されます。通常の場合、このサイトは即時に https://bank.example.com サイトへのリダイレクトを返信してきます。しかしながら、もし HTTP プロトコルをセキュアでないネットワーク (例えば近所のコーヒー ショップ) で利用すると、経路上の攻撃者がセキュアでないリクエストを横取りし、本当のバンキング サイトではなくフィッシング サイトへ誘導する事ができます。

アドレスバーの URL および HTTP の鍵のアイコンの証明書情報の慎重な確認だけが、このようなマン イン ザ ミドル (中間者) 攻撃の検知を可能にします。けれども https://bank.example.com をタスクバーにいつも表示するようにして、いつも表示したバンキング アプリケーションを起動すれば、最初のリクエストから既に HTTPS プロトコルが利用され、マン イン ザ ミドル (中間者) 攻撃によるリクエストの横取りと悪意のあるサイトへのリダイレクトを防止する事ができます。

第五に、HTTPS サイトをタスクバーにいつも表示するようにすれば、HTTPS プロトコルを標的にしたマン イン ザ ミドル (中間者) 攻撃に対してもより良い保護が得られます。具体的には、もしブラウザーが Web サイトにコンタクトした際に提示されるセキュリティー証明書に問題があれば、接続は安全かつ即時に切断されます。

例えば、攻撃者が攻撃ツールを使い偽のセキュリティー証明書を用いて、バンキング サイトを表示しようとしたあなたのブラウザーを騙そうとした場合には以下のスクリーンショットのような画面が表示されます:

ご覧のように、“クリックして無視” したり個人情報のセキュリティーが侵害されたりするような、安全でない選択肢はありません。

もちろん、いつも表示するサイトも通常の Internet Explorer 9 ブラウザーにある数多くのセキュリティー テクノロジーや機能の恩恵を受けています。 Extended Validation 証明書 (EV 証明書) が有効なサイトを訪問すればアドレスバーが緑色で表示されますし、SmartScreen フィルター は悪意があると知られているサイトへの移動やダウンロードをブロックします。

簡単で安全なブラウジング エクスペリエンスのために、重要なサイトはすぐにいつも表示するようにしましょう。ありがとうございました。

—Eric Lawrence, 主席上級プログラム マネージャー, Internet Explorer

2011年3月19日

IE Blog: Internet Explorer 9 セキュリティー Part 2: ソーシャル エンジニアリング攻撃からの防御

Filed under: IE Blog — hebikuzure @ 12:41 PM

Internet Explorer 9 Security Part 2: Protection from Socially Engineered Attacks
http://blogs.msdn.com/b/ie/archive/2011/03/10/internet-explorer-9-security-part-2-protection-from-socially-engineered-attacks.aspx


「Internet Explorer 9 Security」のパート 2 です。引き続きパート 3 も掲載します。

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


Internet Explorer 9 セキュリティー Part 2: ソーシャル エンジニアリング攻撃からの防御

2011年3月10日 午前9時01分

今週初めに Eric がこの記事で紹介したように、Internet Explorer はユーザーが時に悪意のある Web を巡回する際に直面する三つの主な脅威のクラスのそれぞれについて、緩和したり保護したりするための多層的な防御を提供します:

  1. オペレーティング システムやブラウザーの攻略のための技術的な攻撃
  2. Web サイトの脆弱性を攻略するための Web 攻撃
  3. ユーザーの信頼に対するソーシャル エンジニアリング攻撃

本日の記事では、第三のクラスの攻撃・ソーシャル エンジニアリングに対して IE8 と IE9 がどのように防御を提供しているのかについて説明します。

ソーシャル エンジニアリング攻撃

ソーシャル エンジニアリング攻撃は、ユーザーに対して自身のコンピューターやデータを危険にさらす行動をするように納得させる事により、ユーザーの信頼を利用します。これには、説得力のあるフィッシング ページに個人情報を入力したり、コンピューターに感染するプログラムを実行したりするよう、ユーザーをだます事も含まれます。

Internet Explorer 8 と 9 共に SmartScreen® フィルターが、ソーシャル エンジニアリング型のマルウェアとフィッシング攻撃から、受賞歴もある保護を提供しています。IE8 の出荷開始から 1.5 億回のマルウェア攻撃がブロックされています

この経験と情報を基に、IE9 ではソーシャル エンジニアリング型のマルウェアに対する新しいアプローチと、IE9 での新しいレイヤーの安全を導入しました。この機能は SmartScreen Application Reputation (SmartScreen アプリケーション評価) で、IE9 の新しいダウンロード エクスペリエンスの一環です。URL 評価とアプリケーション評価は共にソーシャル エンジニアリング攻撃に対する著しい保護の向上をもたらします。

SmartScreen URL 評価

これまでも何度も SmartScreen フィルターについて解説していますが、この機能は常にソーシャル エンジニアリング型マルウェアとフィッシング攻撃からの防御の領域を先導しています。

説明したように、SmartScreen は URL を基に億単位のマルウェアとフィッシング攻撃から日々 IE8 と IE9 のユーザーのためにブロックし続けています。

こうした数字は印象的ではありますが、マルウェアの作者にはどのようなブロック リスト ベースの仕組みに対する回避策を継続的に取り続けるだけの時間と動機があります。数億回ものダウンロードが行われている事を考えれば、これは攻撃者が過去の既存のソリューションや私たちのユーザーに対する、悪意のあるプログラムを作成するのに成功するだろう事を意味しています。SmartScreen は URL を基に悪意のあるダウンロードの大部分をブロックし、アンチウイルス製品はそれらの共有をブロックしていますが、ブロックリストもアンチウイルス製品も共に遅延の問題に悩まされています。どちらもその時点で悪意があると知られている物をブロックする点については優秀ですが、新しい攻撃の第一波にさらされているユーザーに対する保護は不十分です。IE9 で機能するアプリケーション評価への注力は、こうしたギャップを埋め、未検知の攻撃からユーザーを保護します。

アプリケーション評価 (IE9)

Internet Explorer 9 のために、私たちはダウンロードに関する状況を非常によく観察しました。その結果ダウンロードの場所はほとんどのユーザーに対してほぼ適切に設定されている事が分かりました。そこで私たちは評価上問題の無いダウンロード (特定のファイルまたはデジタル署名) と、悪意があると考えられるダウンロードとを識別できるようなインテリジェントなシステムを構築するための手法について調査を開始しました。その結果が現在 IE9 のダウンロード エクスペリエンスの一環である SmartScreen アプリケーション評価です。

アプリケーション評価の目的はソーシャル エンジニアリング型マルウェアへの感染数を減少させることです。これは不要な警告を大きく減らす一方で、悪意があると考えられるプログラムを実行しようとするその時にユーザーに警告する事で達成されています。この時点で、ユーザーはプログラムを実行する事も、直ちにダウンロードされたファイルを削除する事も可能です。私たちはこの警告が、ユーザーが正しい選択をするのに非常に役立っている事を確認しています。

  • IE9 ベータ版と RC 版のユーザーの 90% には、評価上問題の無いプログラムしかダウンロードしないためこの警告は表示されていません
  • ダウンロードされたファイルの 20% から 40% には確立した評価が無く、最終的に悪意があると分類されています。これらはすべての既存のソリューションを回避しようとしたマルウェアのダウンロードで、警告が無ければユーザーが実行していたかもしれない物です。
  • 以前に検知されていないマルウェアの 95% はアプリケーション評価の警告が表示された時点でユーザーによって削除されています

これらのデータはこの機能が既存のソーシャル エンジニアリングへの保護を大きく補完するものであり、ユーザーの安全に長期にわたり顕著に貢献する事を示しています。SmartScreen アプリケーション評価についてのより詳細な情報とデータと、IE9 ユーザーをマルウェアのダウンロードから保護するのにどのように役立っているかについて、今後何週かの内に引き続き投稿する予定です。

—Ryan Colvin, プログラム マネージャー, SmartScreen チーム

2011年3月18日

IE Blog: Internet Explorer 9 セキュリティー Part 1: 拡張されたメモリー保護

Filed under: IE Blog — hebikuzure @ 12:23 PM

Internet Explorer 9 Security Part 1: Enhanced Memory Protections
http://blogs.msdn.com/b/ie/archive/2011/03/07/internet-explorer-9-security-part-1-enhanced-memory-protections.aspx


3 月 14 日 (日本時間 15 日) の Internet Explorer 9 製品版の公開に向けて、IE Blog にも多くの POST が上がっています。順次私訳しようと思っていたら震災と停電の影響でバタバタして、少し遅くなってしまいました。まず「Internet Explorer 9 Security」のパート 1 からパート 3 までを掲載します。

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


Internet Explorer 9 セキュリティー Part 1: 拡張されたメモリー保護

2001137 午前1153

Internet Explorer は、ユーザーが時に悪意のある Web を巡回する際に直面する三つの主な脅威のクラスのそれぞれについて、緩和したり保護するための多層的な防御を提供します:

  1. オペレーティング システムやブラウザーの攻略のための技術的な攻撃
  2. Web サイトの脆弱性を攻略するための Web 攻撃
  3. ユーザーの信頼に対するソーシャル エンジニアリング攻撃

本日の記事では、このうちの第一のクラスの脅威に対してブラウザーがどのようにメモリーを保護するのかについて解説します。

確度の高い操作を防ぐ

メモリー保護機能の目的は、メモリー関連の脆弱性に対して確度の高い操作を防ぐことです。以下の “アルファベット スープ” の頭文字で示されているテクノロジーのいずれも、悪意のあるコードが実行される前にブラウザーのタブを安全に閉じるための方法です。Internet Explorer 9 は、メモリー関連の脆弱性がブラウザーやそのアドオンに発見されても、攻撃者のコードが実行されるのを防ぐための最新のメモリー保護テクノロジーを利用しています。

DEP/NX (Data Execution Prevention [データ実行防止] / No eXecute) は Internet Explorer 8 および 9 で既定で有効になっており、ブラウザーにおけるメモリー保護の基盤です。DEP/NX はシステムのプロセッサーと共に機能してコードとデータを識別し、攻撃者によって配置されたデータからの実効を防止します。プロセッサーが適切にマークされていないメモリーのブロックからの実行の指示を検出すると、当該の命令が実行される前に安全にプロセスを終了させます

ASLR (Address Space Layout Randomization [アドレス空間レイアウトのランダム化]) はプロセスのメモリー スペースを予測不可能な方法で配置する事による防御です。ASLR は、“Return Oriented Programming” と呼ばれる攻撃者がブラウザーやオペレーティング システムの一部である関数を悪用して既存のコード ロケーションへのジャンプを攻撃としてセットアップする方法によって、容易に DEP/NX を回避する事ができないようにします。例えば、よくある仕掛けはメモリーをデータではなく “コード” としてマークできる VirtualProtect 関数へのジャンプを試みる物で、これが成功すると DEP/NX を効果的に回避できます。VirtualProtect やその他の関数が予測不可能な位置となるようにする事で、攻略コードは実行に成功せず、通常アクセス違反でクラッシュしてしまいます。

IE9 ではメモリー マッピングが予測可能とならないよう、メモリー レイアウトのランダム化を強化しています。しかしながら ASLR は個々の DLL ごとに有効化されるので、いくつかの古いブラウザー アドオンはこの緩和策を適切に受け入れません。SysInternals の Process Explorer ツールを使うと、プロセスに読み込まれている DLL のそれぞれについて DEP/NX 防護が首尾よく機能しているか確認するための調査が行えます。例えば以下に示すスクリーンショットのように、防御がされていない一つの ActiveX コントロールを除き、Internet Explorer のタブのプロセスに読み込まれたすべての DLL で ASLR が有効である事が確認できます。もとこの DLL が攻撃者にとって有益なコード セグメントを露出している場合、ASLR ランダム化の欠如はメモリー保護の回避への足掛かりとなり得ます。

注: 詳しい方であればプロセス中のすべての DLL に EMET (Enhanced Mitigation Experience Toolkit) を使って ASLR の適用を強制する事ができます。これは Microsoft Security Research and Defense によって提供されているセキュリティー ツールで、最先端のセキュリティー緩和策のプロトタイプです。ASLR を予期していない DLL にこれを強制適用すると、互換性の問題が発生する場合があります。そのためこのツールを利用する場合にはこの点に留意してください。

SafeSEH (Safe Structured Exception Handling [安全な構造化例外処理ハンドリング]) は、例外処理ハンドリング チェインに悪意のある構造化例外処理を挿入される事を防止するための、コンパイラー オプションです。すべての 64 ビット コード及びすべての Internet Explorer のコードは SafeSEH フラグを付けてコンパイルされています。ただし、ASLR と同様、この緩和策も DLL 単位で有効化されるため、包括的な防御のためにはアドオンもこのフラグを付けてコンパイルされている必要があります。

SafeSEH のこの限界は、Windows 7 上の Internet Explorer 9 では緩和されています。IE9 はプロセス単位で有効化される新機能 SEHOP (Structured Exception Handler Overwrite Protection [構造化例外処理の上書き保護]) が有効になっているため、個々の DLL でのオプト インは不要です。SEHOP は例外のディスパッチの前に例外処理ハンドリング チェインの整合性を検証する事で機能しています。これにより、SafeSEH が利用できるよう再コンパイルされていないような古いブラウザー アドオンを動作させているような場合でも、構造化例外ハンドリングが攻撃回路としてできない事を確実にします。

最後に、Internet Explorer 9 は Visual Studio 2010 に含まれる最新の C++ コンパイラーでコンパイルされています。このコンパイラーには Enhanced GS またはスタック バッファ オーバーラン検出と呼ばれる機能が含まれています。これはスタックの破損を検出し、そのような破損が発生した場合にもコードの実行を防止します。最新のコンパイラーでは、既存の GS 機能は幅広い領域の攻撃をブロックするよう拡張され、どのような機能が保護を必要としているのか判断するためにより良いヒューリスティック機能を利用します。この拡張により、Internet Explore のパフォーマンスへの影響は最小化され、保護は最大化されます。

詳細情報

ソフトウェア開発者は、自身の製品のセキュリティーを強化するためこれらの 3 つのテクニックをどのように利用するのかを含めた Internet Explorer の防御について、MSDN の Windows ISV Software Security Defenses whitepaper で詳細情報を得る事ができます。

Web を安全にするための皆さんのご助力に感謝します。

—Eric Lawrence, 上級プログラム マネージャー, Internet Explorer

2011年1月20日

IE Blog : サイトを「いつも表示」する機能との連動

Filed under: IE Blog, Internet Explorer — hebikuzure @ 6:34 PM

Working with Pinned Sites
http://blogs.msdn.com/b/ie/archive/2011/01/17/working-with-pinned-sites.aspx


“Pinned Site” の機能に関する解説と新規公開のドキュメントの紹介が IE Blog に掲載されましたので、私訳して紹介します。なお “Pinned” は「ピン止めする」という意味ですが、Windows 7 では「いつも表示」という訳語が使われているので、ここでもそれを使いました。どんな機能かすぐ分かる用語ではありますが、あまり洗練されていないような気もします。いかがでしょうか。

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


サイトを「いつも表示」する機能との連動

2011年1月17日 午後5:37

Internet Explorer 9 Beta では、Windows アプリケーションと同じ方法で Web サイトを Windows 7 のタスクバーに「いつも表示」させる事ができます。一度「いつも表示」にすると、Windows 7 の他のいろいろなものと同様に Web サイトを起動する事ができます。「いつも表示」させるには、IE9 のタブを Windows 7 のタスクバーにドラッグするだけの簡単さです。

以前には、Web サイトが PC のデスクトップに直接存在する事ができず、ユーザーは Web サイトにたどり着くのに事実上 “2回起動する” 必要がありました — 一度はオペレーティング システムを、そしてもう一度はブラウザーを — 。「いつも表示」したサイトでは、ユーザーはより素早くより簡単に、よく使う Web サイトにたどり着けます。

一度「いつも表示」にされれば、Web 開発者は「いつも表示」されたサイトについて、タスクバー アイコンのジャンプ リストに追加するタスク、通知アイコンを使ったユーザーへのお知らせ、サイトを制御するためのサムネイルのツールバー ボタンの生成などの、メタデータとメソッドを利用できます。Web サイトへのこうした機能を追加は少ない開発コストしか必要ありませんが、サイトの訪問者にはより良い Web エクスペリエンスが提供できます。開発者の皆さんはこれについてのより詳しい情報として、User Experiences: Customizing Pinned SitesPinned Sites: Windows 7 Desktop Integration with Internet Explorer 9、また PDC 2010 のセッション “Taking Advantage of Pinned Sites with Internet Explorer 9 and Windows 7” (10分目辺りまで早送りしてください) をご参照ください。

API のドキュメント

本日私たちは、Windows 7 の「いつも表示」サイトを見た目良く拡張し作成するための、「いつも表示」サイト (別名サイト モード) API をどのように利用するのかについて述べた開発者向けドキュメントを公開しました。このドキュメントでは IE Test Drive Site Pinning のサンプルから漏れた物をピックアップしており、サンプル サイトがどのように構築されているのかを示す多くのサンプル コードを含んでいます。

四つのシナリオが含まれており、それぞれで Internet Explorer 9 での「いつも表示」サイトの機能の側面を開設しています:

Channel9 ポッドキャスト プレーヤー サンプル: 基本編


静的なタスクを含むジャンプ リスト

Channel9 ポッドキャスト プレーヤーのサンプルに、ジャンプ リストの静的な項目を含む「いつも表示」サイトの基本的な機能を追加しています。またWeb サイトで「いつも表示」サイトの機能をユーザーに示す方法についても学べます。

Channel9 ポッドキャスト プレーヤー サンプル: リモート コントロール


ツールバーのあるサムネイル プレビュー ウィンドウ

Channel9 ポッドキャスト プレーヤーのサンプルの音声再生を制御するための、サムネイルのツールバー ボタンを生成します。

TweetFeed サンプル: 検索履歴


TweetFeed の検索結果がカスタム ジャンプリストのカテゴリーに追加されます

TweetFeed サンプルでのユーザーの操作を基に、ジャンプ リストのカスタム カテゴリーに項目を挿入します。

TweetFeed サンプル: 通知

 
通知アイコン

TweetFeed サンプルでのアクティビティーを示すために通知アイコンを利用します。

Introduction to Pinned Sites は「いつも表示」サイトの API についての最良の概説です。またこの資料にはテクノロジーの利点の説明や、この機能によりあなたの Web サイトへのユーザーの関わり方がどのように向上するのかについての解説もあります。

「いつも表示」サイトの機能を検出する

複数のブラウザーを通じて適切に動作するサイトを開発するためには機能の検出が重要です。特定のブラウザーを検出したり関連性の無い機能の存在をチェックしたりするテクニックとは違い、開発者は機能の検出により特定の機能を利用する前にブラウザーでその機能がサポートされているかテストでき、既知の問題の回避策を適用する前にその問題が存在するかテストできます (Same Markup: Writing Cross-Browser Code を参照してください) 。

「いつも表示」サイトの API でも違いはありません。私たちは「いつも表示」サイトの機能を利用する前に、これが利用可能か機能の検出を行う事を推奨しています。external の msIsSiteMode メソッドは「いつも表示」サイトの機能が利用可能か判断する最良の方法です。以下のコードは利用可能な場合には「いつも表示」サイト API を使って正しい動作を行い、利用できない場合には別のコード パス (catch 節) を起動します:

    try {
        if (external.msIsSiteMode()) {
            /*Code for when site mode is supported and active*/
        }
        else {
            /* Code for when site mode is supported, but inactive */
        }
    }
    catch (e) {
        /*Code for when site mode is not supported */
    }
Adobe Flash Microsoft Silverlight から「いつも表示」サイトをプログラムする

IE9 の中で Adobe Flash や Microsoft Silverlight のコントロールを利用している開発者も、JavaScript の「いつも表示」サイト (サイト モード) API を利用して、サイトを Windows 7 のタスクバーに統合できます。

例えば、Adobe Flash を利用してビデオやオーディオを再生しているページでは、ページのサムネイルにメディア コントロールを追加できます (下のスクリーン キャプチャーをご覧ください) 。開発者はここにあるドキュメントで示されている適切な Flash Player の再生機能を、Web ページの ‘msthumbnailclick’ イベント ハンドラーから呼び出せます。このメソッドは Flash Player の再生コントロール機能を呼び出すために JavaScript API を利用します。

Windows 7 のタスクバー サムネイルの中の Flash で生成したメディア コントロール

Web ページはここで説明されているように ActionScript を使い、ユーザーへタスクバーのカスタム ジャンプ リストを提示する事もできます。Microsoft Silverlight も同様のレベルの統合機能が利用できます。その方法の詳細はこの記事をご覧ください。この機能を Flash や Silverlight で利用するための唯一の前提条件は、コントロールがスタンドアローンのアプリケーションとしてではなく、IE9 ブラウザー内でホストされている事です。

開発者向けトレーニングが利用できます

本日、2011年1月17日から、Microsoft はアメリカ合衆国中部地区各地で Windows Development Boot Camps シリーズを開催しています。Boot Camp はクライアント開発についての奥深い 1 日間のクラスです。このイベントでは Windows 7、Internet Explorer 9 および Silverlight 4 のブラウザー外実行の開発についてカバーしています。このトレーニングの一環として、Windows 7 と統合するための「いつも表示」サイト (サイト モード) API の利用方法も含まれています。詳しくは http://www.windowsdevbootcamp.com/ をご覧ください。

「いつも表示」サイト機能によりもっともよく利用する Web サイトに簡単で素早くアクセスできるようになります。ここで説明した先進的な「いつも表示」サイトの機能を提供すれば、あなたの Web サイトは訪問者にとってより利用しやすくなるでしょう。

—Israel Hilerio, 博士, 主席プログラム マネージャー, Internet Explorer

« Newer PostsOlder Posts »

WordPress.com Blog.

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