Hebikuzure's Tech Memo

2011年12月16日

IE10 の相互運用性のある Quirks モード

Filed under: IE Blog — hebikuzure @ 10:31 午後

Interoperable HTML5 Quirks Mode in IE10
http://blogs.msdn.com/b/ie/archive/2011/12/14/interoperable-html5-quirks-mode-in-ie10.aspx


IE10 の Platform Preview 4 に関するIE Blog の記事です。IE10 の Quirks モードに関する大きな変更についての情報です。
これもいずれ Microsoft 公式日本語ブログでも翻訳されると思いますが、とりあえず日本語で読みたいという方のために掲載します。

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


IE10 の相互運用性のある Quirks モード

2011年12月14日 午前9時21分

IE10 platform preview 4 には、HTML5 で規定されている動作に基づいた相互運用性のある quirks モードを利用した HTML5 サポートの拡張が含まれています。この HTML5 ベースの quirks モードは IE10 の既定の quirks モードです。

ユーザーも Web 開発者も、サイトがどのブラウザーでもちゃんと動作する事を求めています。そのため、どのような実装でも HTML や CSS、JavaScript が同じように動作する事が求められます。Web 基盤の中で以前には未定義のまま残されていた部分を定義する事で、HTML5 はクロス ブラウザーの一貫性を容易にしました。これには主に HTML5 解析ルール が含まれていますが、それだけでなく quirks モードでブラウザーが どのように ふるまう べきか についても含まれています。

IE10 の HTML5 quirks モードは DOCTYPE が無い場合と HTML5 で定義されているレガシーな DOCTYPE の場合に使用されます。HTML5 仕様や他のブラウザーと同様、IE10 の quirks モードの動作は、限定された特異な (quirks な) 動作が含まれるだけで、それ以外は標準モードと同一です。これは <canvas> や <audio>、<video> などの機能は quirks モードでも利用可能だという事を意味しています。最も重要なのはこれにより IE10 の quirks モードの動作が他のブラウザーと揃う事で、そのため DOCTYPE の無いページの動作が実装に関わらず同じになりました。

開発者は F12 開発者ツールを利用して、ページでどのモードが利用されているのか簡単に判別できます。最新の HTML5 標準と quirks モードはそれぞれ StandardsQuirks としてリストに表示されるようになりました。レガシーなモードは引き続きそれに対応した IE のバージョンで表示されます。以前の IE の quirks モードは Internet Explorer 5 quirks として参照されます。


F12
開発者ツールのドキュメント モード メニュー

IE10 でも引き続き DOCTYPE の無いページの互換表示モードおよび X-UA-Compatible により指定されたページでは Internet Explorer 5 quirks を利用します。

<meta http-equiv="X-UA-Compatible" content="IE=5">

皆さんへのお願い

HTML5 は互換性と相互運用性のために quirks モードを定義していますが、新しいサイトではページの先頭に <!DOCTYPE html> を指定して標準モードを利用するようにしてください。また IE10 の HTML quirks モードが適切に動作するよう、 Connect 経由でのレポートをお願いします。

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

2011年12月3日

アプリケーションのための HTML5: IE10 Platform Preview 第四版

Filed under: IE Blog — hebikuzure @ 2:47 午後

HTML5 for Applications: The Fourth IE10 Platform Preview 
http://blogs.msdn.com/b/ie/archive/2011/11/29/html5-for-applications-the-fourth-ie10-platform-preview.aspx


IE10 の Platform Preview が更新されて Platform Preview 4 になりました。IE Blog にもそれに関連した記事が掲載されましたので、私訳してみました。いずれ Microsoft 公式日本語ブログでも翻訳されると思いますが、とりあえず日本語で読みたいという方のために掲載します。 

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


アプリケーションのための HTML5: IE10 Platform Preview 第四版

2011年11月29日 午前11時23分

Windows Developer Preview 向け IE10 platform preview のアップデートがダウンロード可能になりました。この IE10 のプレビュー版には、よりリッチでパフォーマンスも著しく向上した Web アプリケーションが可能になる、より多くの HTML5 テクノロジーのサポートが追加されました。IE10 の SGV や CSS3 トランスフォーム、CSS アニメーションのようなハードウェア アクセラレーション技術は、他のブラウザーに比べて高速なレンダリングを実現しています。これについては以下の短いビデオで特徴的に示しています。

image
pp4_blog_demo.mp4

IE10 HTML5 関連の新機能とパフォーマンスの向上をご覧ください

この四番目の Platform Preview により、開発者の皆さんは実際のサイトですぐに利用可能なより多くの HTML5 テクノロジーについての作業を開始する事ができます。すべてのリストはこちらの IE10 開発者ガイドで確認できます。

  • ドメイン間で安全に XMLHttpRequest を利用するための Cross-Origin Resource Sharing (CORS)
  • スクリプトやブラウザーで large binary object を操作可能にする File API Writer の blobBuilder サポート
  • 型付データの効率的な操作とストレージのための、JavaScript の Typed Arrays (型付配列) のサポート
  • Web ページやアプリケーションでエンドユーザーが選択した要素をコントロールするための CSS user-select プロパティ
  • タイムコード、再生位置情報、キャプション ファイル フォーマットを含む HTML5 Video の字幕のサポート

これらの基礎的な能力は、バイナリ データとファイルの操作、選択範囲のコントロールやアプリケーション UI のテスト、字幕付きの利用しやすいビデオ コンテンツの提供など、ネイティブ アプリケーションの開発者が依存してきたものです。今回の platform preview の機能によりこれらの能力が Web ページと、Metro スタイルの Windows 8 アプリケーションでも利用可能になりました。

HTML5 アプリケーションの構築

今回の IE10 プレビュー版では、開発者の皆さんが異なるドメイン上のアプリケーション間でリクエストや共有、データの移動を安全に行うために、XMLHttpRequest を利用できるよう CORS (cross origin resource sharing) をサポートしました。開発者が異なるアプリケーションからデータやサービスを集めて一緒にする事は、一般的なやり方です。この Test Drive のデモでは、CORS を XMLHttpRequest や File API、HTML5 progress と共に利用し、複数のファイルを異なるドメインにアップロードする際のスムーズなエクスペリエンスが提供されている事が確認できます。

ここをクリックすると、XMLHttpRequest と CORS の利用によるドメイン間でのアップロードが確認できます。

バイナリ データとファイルを扱えるようになった事で、開発者の皆さんは Web 上で新しい種類のアプリケーションとエクスペリエンスを構築する事が可能になりました。今回の IE10 プレビュー版では、large binary objects (blobs) を扱うための File API: Writer の blobBuilder と、JavaScript の typed arrays (型付配列) がサポートされました。こちらの Test Drive のデモでは、様々な種類のファイルが、PCX ファイルのようなブラウザーではネイティブにサポートされていないファイル タイプを含めて、読み取り、レンダリングし、さらにその内部的なコンテンツの表示もできる事が確認できます。

ここをクリックして JavaScript の typed arrays (型付配列) と File APIs によるバイナリ ファイルの読み取りと表示が確認できます。

開発者の皆さんがより洗練されたアプリケーションを Web 上で構築するには、エンド ユーザーがページ内のどの部分をどのように選択しているのか、正確に制御する必要があります。IE10 では CSS User select のサポートにより、アプリケーションを利用しているユーザーがどの要素を選択しているのかを開発者が特定できるようになりました。この Test Drive のデモでは、サンプルのブログ アプリケーションにおいて CSS rule で user-select プロパティを使用する事により、選択された部分を制御する様子が確認できます。

ここをクリックして、CSS user-select によるエンド ユーザーの Web ページ内の選択範囲の制御をお試しください。

HTML5 の同一マークアップの向上

私たちは継続的に HTML5 標準化団体によるテスト スイーツの開発に寄与しており、118 個の新規のテストを提供し、相互運用性と同一マークアップを目標としてきました。これらのテストは IE Test Center でも見る事ができます。私たちはすべての開発者の皆さんに、まず HTML5 の doc type <!DOCTYPE html> を皆さんの Web ページで常に使用して、HTML5 標準に沿って記述される事を強く推奨します。

IE10 Preview 4 では、より一貫性があり、Firefox や Chrome、Safari、Opera などの他のブラウザーの quirks モードでの動作と相互運用性の高い、quirks mode の更新が含まれています。更新された quirks mode では以前と同様の (quirks な) ページ レイアウトがサポートされるのと同時に、audio や video、canvas などのHTML5 要素のより今日的な標準機能もサポートされます。

開発者の皆さんが利用可能な新機能の完全なリストはこちらの IE10 開発者ガイドにあります。Windows 8 developer preview をダウンロードし、IE10 を更新してください。私たちは引き続き開発者のコミュニティーや皆さんの Connect からのフィードバックを心待ちにしています。

—Rob Mauceri, グループ プログラム マネージャー, Internet Explorer

2011年9月2日

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

Filed under: IE Blog — hebikuzure @ 12:46 午前

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

2011年8月10日

より深い防御: HTML5 Sandbox によるマッシュ アップのロックダウン

Filed under: IE Blog — hebikuzure @ 6:33 午後

Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox
http://blogs.msdn.com/b/ie/archive/2011/07/14/defense-in-depth-locking-down-mash-ups-with-html5-sandbox.aspx


昨日に引き続き IE Blog の記事から IE10 で追加された HTML5 Sandbox についての記事を私訳しました。 iframe でホストされるコンテンツに対してサンドボックス機能を提供する事で、外部のコンテンツを安全にマッシュアップて゜きるようにする、という狙いの機能です。

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


より深い防御: HTML5 Sandbox によるマッシュ アップのロックダウン

2011年7月14日 午前9時14分

開発者が各々のサイトでより安全なエクスペリエンスを構築できれば、Web はより良いものになります。これまでの Internet Explorer のリリースごとに、私たちはブラウザー エクスペリエンスが安全セキュアになるようブラウザー向上する事で、その方法を提供してきました。IE10 Platform Preview 2 には、開発者が各々のサイト内のマッシュアップ コンテンツをより強力にロックダウンできる HTML5 Sandbox の全面的サポートが取り入れられています。

HTML5 Sandbox は開発者がページ内の各部分の権限を強力に制限できるようにします。これを利用するには、iframe 要素に sandbox 属性を追加するだけです。

<iframe src="untrusted.html" sandbox></iframe>

sandbox 属性により、フレーム内のコンテンツには以下が許可されなくなります:

  • プラグインのインスタンス化
  • スクリプトの実行
  • ポップアップ ウィンドウを開く
  • フォームの送信
  • ストレージ (HTML5 localStorage, sessionStorage, cookie など)
  • XMLHttpRequest の送信
  • 親ウィンドウの DOM へのアクセス
  • HTC, バイナリ ビヘイビア、データ バインディングの使用

これらの制限により、フレーム内のコンテンツの機能はうまく制限されます。もしこれらの制限が皆さんのサイトでは過剰であれば、属性値のトークンを利用して、コンテンツが利用するために復活させたい機能を示す事もできます。例えば、以下のマークアップでは、フォームの送信とスクリプトの実行以外の上記の制限が行われます:

<iframe src="untrusted.html" sandbox="allow-forms allow-scripts"></iframe>

許可のためのトークンの動作のすべてを確認するには、HTML5 Sandbox Test Drive demo をご覧ください。sandbox 化された iframe 内でブロックされる動作の詳細については IE10 Developer’s Guide をご覧ください。

マッシュアップのセキュリティー問題は Web にとって新しいものではありません; 開発者は自分のサイト内の広告やウィジェット、フォーム、コメント投稿欄などをより安全にするよう、数年来取り組んでいました。これらのコンテンツは、クロス サイト スクリプティング攻撃 (XSS) や情報の漏洩、ユーザー エクスペリエンスの乗っ取りなどの標的となり、それをホストしているサイトにとって危険となる場合がありました。サイトの持ち主はそれに対して以下のような緩和策を取ってきました:

  • サーバー サイド / クライアント サイドでのコンテンツの検証、フィルタリング、エンコーディング
  • 望ましくない API へのアクセスの JavaScript ライブラリを利用したオーバーライド
  • 既存のクロス オリジン ポリシーの動作を期待してコンテンツを別ドメインでホストする
  • IE のレガシーな security="restricted" attribute を利用する

Sandbox のサポートを検知する

私たちは開発者に向けて IE10 Standards Mode (IE10 標準モード) をターゲットにするよう推奨しています。しかしユーザーがうっかり互換表示ボタンをクリックしても sandbox の機能が失われないよう、IE10 ではすべてのドキュメント モードでこの属性をサポートしています。

ユーザーが sandbox をサポートしているブラウザーを利用している場合にのみ表示させたいコンテンツがあるでしょう。そうした場合は、いつでも私たちが推奨しているように、機能の検知をそのために利用してください。HTML5 Sandbox は以下の JavaScript で検知できます:

if ("sandbox" in document.createElement("iframe")) {
window.alert("HTML5 Sandbox is supported!");
}

優秀でセキュアなフォールバック

HTML5 Sandbox をサポートしていないブラウザーでは、この属性は無視されます。これは追加のセキュリティー制限なしにコンテンツが表示される事を意味しています。HTML5 Sandbox は深層防御のテクノロジーですから、上記のようなこれ以外のセキュリティー テクニックに追加する形で利用するべきです。

標準の強化

この機能を実装する過程で、私たちは標準規格がいくつかの分野で強化されるべきだと認識しました。

第一に、ブラウザーは既定で sandbox 内のポップアップをブロックします。しかしながらこれを許可した方が望ましい場合もあります。例えば、 ではサイトは Bing マップのウィジェットを sandbox 化した iframe として表示しますが、大きなサイズの地図や道案内、鳥瞰図などのポップアップ リンクからのポップアップが許可されています。IE10 ではこうした正当なケースでのポップアップの許可を、ms-allow-popups によってサポートしています。私たちはこれについて HTML ワーキング グループにフィードバックを行っています。仕様が更新され、安定したら、ベンダー プリフィクスは取り除かれるでしょう。

第二に、コンテンツを sandbox 化する事はサーバーにとっても重要です。sandbox 属性はコンテンツが iframe 内にある時だけ制限をかけます。もし sandbox 化したコンテンツがユーザーにそのコンテンツを直接ブラウズするよう誘導したら、信頼できないコンテンツは sandbox 化された iframe 内の存在ではなくなり、セキュリティー制限はまったく機能しなくなります。

実装しているブラウザーはありませんが、HTML5 ではサーバーが信頼できないコンテンツは text/html-sandboxed MIME タイプを付けて送信する提案しています。このアプローチには数多くの問題もあります—特に、MIME タイプからは必要な許可トークンを取得できません。HTML5 からこれを削除する提案から生じた議論の後で、私たちは X-Content-Security-Policy HTTP ヘッダーの sandbox ディレクティブに続ける形でサポートする事としました:

X-Content-Security-Policy: sandboxed allow-forms allow-scripts;

最後に、私たちは HTML5 Sandbox のために 26 個のテスト ケースを開発し、W3C に提出しました。

IE10 の HTML5 Sandbox について皆さんのフィードバックを歓迎します。IE10 Platform Preview 2 をダウンロードして、Connect を通じて発見したバグを報告してください。

—Jacob Rossi, プログラム マネージャー, Internet Explorer

2011年8月9日

IE10 における Web Workers のデバッグ

Filed under: IE Blog — hebikuzure @ 8:35 午後

Debugging Web Workers in IE10
http://blogs.msdn.com/b/ie/archive/2011/07/12/debugging-web-workers-in-ie10.aspx


今日は IE Blog の記事から IE10 で追加された Web Workers のサポートに伴う F12 開発者ツールの新機能についての記事を私訳しました。

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


IE10 における Web Workers のデバッグ

2011年7月12日 午前11時34分

Web Workers を利用すると長時間動作する複雑なJavaScript アルゴリズムをバックグラウンドで動作させるオフロードにより、Web アプリケーションはより応答性が良くなります。IE10 には Web ページおよび Web worker の両方で実行される JavaScript に対する完全で動作予測のしやすいデバッギング エクスペリエンスが含まれています。

IE10 ではすべての Web worker で生成される新規のスクリプト コンテキストに対応できるよう F12 開発者ツールが拡張されています。デバッグを開始する (F12 ツール内で [デバッグ開始] ボタンをクリックする) と、Web ページのスクリプト コンテキストにアタッチされるのと同様、現在の (そして将来の) すべての worker のコンテキストにもアタッチされます。これが完全で動作予測のしやすいスクリプト デバッギングという事の意味です: 従来のシングル スレッドのスクリプト対する F12 ツールのすべてのデバッグとプロファイリングの機能は、workers に対しても同様に利用できます。

他の製品では、エミュレーションを通じた限定的なデバッグをサポートしています。現在、多くの開発者向けツールは Web Worker のデバッグにまったく対応していません。そうでなければ、iframe を使って workers をエミュレートするような、シミュレートされた環境でのサポートを提供しているだけです。残念ながら、シミュレーションは開発者をミスリードするでしょう。デバッガーが正しくないシナリオを許容してしまい (例えば DOM アクセスなど) 、デバッグしている間はスクリプトの動作継続のための通常の実行中に失敗してしまうからです。

実行時の挙動が一定しないデバッガーを使うと、混乱を招く “ハイゼンバグ” が生じがちです。これは特に既存のコードを workers を使うように移行している際に顕著です。さらに、UI のスレッド コンテキスト内で実行されるシミュレートされた環境では、アプリケーションがデバッグ中応答しなくなる危険性も存在します。これら両方の陥穽を考えると、Web Workers を利用しようとするアプリケーションに対する真のデバッグ機能のサポートは開発者にとって重要です。

既存の知識に基づいて

F12 開発者ツールは普通のスクリプトと同様の機能を Web Workers でもサポートしますから、皆さんはそのデバッグ方法の大半をすでにご存じという事になります。Workers の実行コード内でブレーク ポイントを設定する事や、すべてのローカル変数を確認する事、ウォッチ リストを構成する事、コンソールを経由して worker を操作する事、コードをステップ実行する事などが可能です。こうした機能によりスクリプト デバッグに通じている開発者であればすぐに Web Workers でも高い生産性が得られるでしょう。とは言え、worker のデバッグに関しては、ここでお知らせしておいた方が良い、注意すべき点もいつくかあります。(以下のすべてのスクリーンショットは、Web Worker Harness for test262 のデモ アプリを使用しています)

スクリプトで新しい Worker オブジェクトが生成され、worker のコンテキストが初期化されると、実行されているスクリプト ファイルがスクリプト リソースのリストに表示されます。ここからファイルを選択し、通常と同様にデバッグを開始できます。


F12
開発者ツールのスクリプト タブと利用可能なスクリプトのメニューのスクリーン ショット

Web Worker のスクリプト内のブレーク ポイントに達すると、その変数またはスコープを調査している場合、通常のスクリプトとは異なる重要な相違に気づくでしょう: スクリプトは通常の Window オブジェクトではなく、 WorkerGlobalScope 型のグローバル オブジェクトを持っています。これはWeb workers が (DOMのような) UI スレッドの共有メモリへのアクセスを制約する新しいオブジェクトであり、通常の実行中はそうしたアクセスは許可されていません。これは self へのウォッチを追加するだけで確認できます。


F12
開発者ツールのウォッチ タブのスクリーン ショット

複数のスクリプト コンテキストのデバッグ

F12 ツールは現在動作しているすべてのスクリプト コンテキストに対応しているため、ブレークポイントに留まっている間は、他のすべてのスクリプト エンジンに停止するよう要請できます。このため現在デバッグ中のスクリプト コンテキストが他のコンテキストから操作される事が防げるので、予期しやすいデバッギング エクスペリエンスが作り出されます。

さらに、一度に単一のスクリプト コンテキストをデバッグする事に限定されません。(worker 内であれ UI スレッド内であれ) ブレークポイントからの実行継続を行うと、すべてのスクリプト コンテキストが再開され、別のブレークポイントにヒットする (または debugger ステートメントまたは例外に遭遇する) まで実行されます。これにより worker のスクリプト コンテキストから UI スレッドのコンテキストへの “フォーカス” の切り替えが自動的に行われる事になり、これらの相互作用のデバッグが容易になります。

Worker を背後で利用しているアプリケーション内のブレークポイントに留まっている間、コール スタック ペインには (実際のコール スタックに加えて) どれだけの worker インスタンスが動作しているか表示されます。各 “Root” は個別の JavaScript 実行コンテキストを示しています。Root #0 はWeb ページの通常のスクリプトを動作させているメインの JavaScript の UI スレッドを示しています。Root #1 は現在動作中の worker (スクリプト ファイルで識別) を示しています。それ以外にも worker が実行されていれば、Root #2 や Root #3 などのようにリストに表示されるでしょう。


F12
開発者ツールのコール スタック タブのスクリーン ショット

Worker のアクティビティーとネットワーク リクエストをプロファイルする

デバッグに加えて、他のスクリプトと同様に、動作している worker のパフォーマンスを確認するためプロファイラーを使用する事もできます。F12 ツールでプロファイラー タブを選択し、プロファイリングの開始 をクリックしてからプロファイルしたいスクリプトを実行します。実行が終了したら、F12 ツールで プロファイリングの停止 をクリックします。以下は 現在のビュー ドロップダウンから 呼び出しツリー を選択した際の表示です。


F12
開発者ツールのプロファイラー タブのスクリーン ショット

URL カラムでは個々のアクティビティーがどのスクリプトによる物なのかを示しています。例えば、上の例では worker 内のテストの実行 (worker 内の execute 関数) に使用された時間は、UI スレッドでのテストの実行に使用された時間 (UI スレッド内の run 関数の消費時間) に比べて少ないという事が指摘できます。

Workers は全体としてのネットワーク アクティビティーにも関連しています。何故ならブラウザーは worker が実行するスクリプトを、ブラウザーが依存しているすべての子スクリプトと同様に (importScripts を経由して) ダウンロードする必要があるからです。必要なのは、ネットワーク タブを選択し、キャプチャの開始 ボタンをクリックするだけです。以下は worker に由来するスクリプトのリクエストを含む、キャプチャのスクリーンショットです。


F12
開発者ツールのネットワーク タブのスクリーン ショット

worker.js ファイルへのダウンロード リクエストが記録されていますが、さらに注目すべきは Initiator カラムでなぜそれがダウンロードされたかが記録されている事 (この場合は Web worker のため) です。さらに、15.2.js ファイルはworker によってインポートされていますが、同様に表示されており、importScripts メソッドの呼び出しによりインポートされたことが示されています。

皆さんのフィードバックを歓迎しています! IE10 での Web Workers の利用やそのツールの機能に関して何か問題を見つけられましたら、ぜひ Connect を通じてお知らせください。

—Jonathan Carter と Gaurav Seth, プログラム マネージャー, Browser Programmability & Tools

2011年7月12日

IE10 の HTML5 解析

Filed under: IE Blog — hebikuzure @ 10:29 午後

HTML5 Parsing in IE10
http://blogs.msdn.com/b/ie/archive/2011/07/06/html5-parsing-in-ie10.aspx


IE Blog の記事も IE10 Platform Preview が出て以降、IE10 についての記事が増えてきています。今回は IE10 での HTML 解析の変更点についての記事を私訳しました。条件付きコメントの廃止や DOM 解析の変更など、開発者に影響のある変更もされるようですね。

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


IE10 HTML5 解析

2011年7月6日 午後2時47分

Web 開発者が同じマークアップと同じコードを使い、異なるブラウザー間で同じ結果が得られる時、より良いものになります。2番目の IE10 platform preview は HTML5 解析アルゴリズムを全面的にサポートする事で、この領域に進歩をもたらしました。

先のリリース以降の IE の HTML パーサーを強化するこの継続的な取り組みは、より多くの HTML が異なるブラウザー間で同じように “うまく機能する” 事を目指しています。その主な例には、HTML 内の SVG のサポート、HTML5 のセマンティック要素のサポート、未知の要素の構造の保存、ホワイトスペースの取り扱いの改善などが含まれています。こうした取り組みの結果として、多くの HTML 解析は IE9 と他のブラウザーの間で同じになりました。

適正な動作にする

この取り組みの目標は、どのモダン ブラウザーでもすべての HTML 解析が同一となるのを確実にする事です。 HTML5 は、ほとんど起こりそうにないエッジ ケースやエラー条件に至るまで、HTML 解析ルールを全面的に定義した初めてのバージョンの HTML となったので、この目標が可能となりました。もしも皆さんのマークアップが不正であっても、HTML5 では依然としてそれをどのように解析するのか定義されており、IE10 はそれらのルールに従います。以下の例は、これらの改善の一部として修正されたケースを示しています。

HTML

DOM ( HTML5 + IE10 )

DOM ( IE9 )

<b>1<i>2</b>

|- <b>
    |- "1"
    |- <i>
        |- "2"

|- <b>
    |- "1"
    |- <i>
    |- "2"
|- <i>

<p>Test 1
<object>
    <p>Test 2
</object>

|- <p>
    |- "Test 1\n"
|- <object>
    |- "\n "
    |- <p>
        |- "Test 2\n"

|- <p>
    |- "Test 1\n"
|- <object>
    |- "\n "
|- <p>
    |- "Test 2\n"

相互運用性のある innerHTML

innerHTML には以下のような変更がされています。これらの新しいコード パターンは IE10 で皆さんの期待通りに動作するようになります:

var select = document.createElement("select");
select.innerHTML = "<option>one</option><option>two</option>";
var table = document.createElement("table");
table.innerHTML = "<tr><td>one</td><td>two</td></tr>";

開発者のためのより良いエラー報告

HTML5 はマークアップが一貫性をもって解析される事を確実にします。開発者にとって、最初から不正なコードを書かないようにするというのは依然として良いアイデアです。適正なマークアップを記述する事は、皆さんのサイトが期待通りに動作し、かつ古いブラウザーとの互換性をより高めるのに役立ちます。

開発者をこの面で支援するため、IE10 では F12 開発者ツールを通じて HTML 解析エラーを報告するようになりました。

レガシーな機能の削除

古いバージョンの IE のいくつかの機能は HTML5 解析と互換性が無いため、IE10 モードからはそれらの機能を削除する事にしました。そのようなレガシーな機能に依存しているサイトも、依然としてレガシー モードで動作します。この方法により、現在動作しているサイトは、開発者が更新する時間をまったく持てなくとも、IE10 で引き続き動作します。

条件付きコメント

<!–[if IE]>
This content is ignored in IE10 and other browsers.
In older versions of IE it renders as part of the page.
IE10 やその他のブラウザーでは、このコメントは無視されます。
以前のバージョンの IE ではページの一部として描画されます。
<![endif]–>

これは条件付きコメントが依然として有効であるものの、古いバージョンの IE のみをターゲットにする事を意味しています。もしより新しいブラウザー間の識別が必用であれば、代わりに機能の検知を利用すべきです

エレメント ビヘイビア

<html xmlns:my>
<?import namespace="my" implementation="my.htc">
<my:element>
This parses as an unknown element in IE10 and other browsers.
In older versions of IE it binds to "my.htc".
IE10 やその他のブラウザーでは、ここは未知の要素として解析されます。
以前のバージョンの IE では “my.htc” にバインドされます。
</my:element>
</html>

XML データ アイランド

<xml>
This parses as <b>HTML</b> in IE10 and other browsers.
In older versions of IE it parses as XML.
IE10 やその他のブラウザーでは、この部分は <b>HTML</b> として解析されます。
以前のバージョンの IE では、XML として解析されます。
</xml>

フィードバックを歓迎します

私たちは (innerHTML を経由したものを含め)、すべての HTML 解析が異なるブラウザーを通じて一貫性を持つ事を確実にするため、皆さんのフィードバックを歓迎しています。IE10 platform preview 2 をダウンロードして、それを利用し、見つけたバグはどんなものでも Connect を通じて報告してください。

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

2011年6月28日

Internet Explorer 9 セキュリティ Part 4: ユーザーを悪意のある混在コンテンツから保護する

Filed under: IE Blog — hebikuzure @ 7:16 午後

Internet Explorer 9 Security Part 4: Protecting Consumers from Malicious Mixed Content
http://blogs.msdn.com/b/ie/archive/2011/06/23/internet-explorer-9-security-part-4-protecting-consumers-from-malicious-mixed-content.aspx


久しぶりに IE Blog の記事の私訳です。 HTTP のコンテンツと HTTPS のコンテンツが混在している場合に表示される警告の意味、そして混在する事の危険性についてまとめられています。

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


Internet Explorer 9 セキュリティ Part 4: ユーザーを悪意のある混在コンテンツから保護する

2011年6月23日 午後12時09分

Web ページ上の混在したコンテンツは、特に一般ユーザーが (コーヒー ショップや空港などの無料の無線 LAN 接続のような) 信頼性の置けないパブリック ネットワークからのブラウジングに多くの時間を使う場合には、一般ユーザーを中間者 (マン イン ザ ミドル) 攻撃のリスクにさらします。攻撃者は、一般ユーザーが安全に提供されていると期待しているページのコンテンツを見る事ができますし、一般ユーザーに知られることなくコンテンツの内容を変更できるのです。こうした事態は Web サイトが、安全な HTTPS ページ内に HTTP で提供されるコンテンツを含めてしまう事で、HTTPS でのセキュリティ規約を無効にしてしまうために起きています。IE9 は皆さんが安全であり続けるために役立ちます。もし HTTPS サイトがセキュアでない HTTP コンテンツを含んでいる場合、Intetnet Explorer 9 は皆さんの情報が安全に保たれるよう、セキュアでないコンテンツをブロックします。

私の IE Blog への初期の投稿の一つで、HTTPS の Web サイトで一般的な二つの致命的な失敗について解説しました。その記事を投稿してからの 6 年間で Web は大きく変わりましたが、残念ながら依然としてこうした問題を良く見かけるのです。

混在したコンテンツの危険性を理解する

攻撃者は安全なページであってもその上の保護されていない、セキュアでない HTTP コンテンツであればどれでも "毒された" バージョンに置き換える事ができます。例えば、色々なブラウザーで https://www.youtube.com/ を訪れた時に中間者攻撃の攻撃者が介在している場合、それぞれ異なった結果になります。多くの他のブラウザーは自動的に保護されていないコンテンツを表示し、なりすましや情報漏洩を許してしまいます。例えば Chrome 13 では以下のようになります:

Internet Explorer 9 は、ページのトップ レベルに含まれるセキュアでないフレームによるコンテンツの存在はページの安全を損なうので、ブロックします:

攻撃の仕組み

HTTP 経由で提供されるページは「葉書」に良く似ています – 送信の経路上の誰でもそれに何が含まれているか見る事ができ、さらにコンテンツのメッセージを棄損したり書き換えたりできます。HTTPS 経由の Web ページは「封函された封筒」に似て、その内側のコンテンツが書き換えられたり公開されたりするのを防いでいます。この比喩に従えば、ページ上で HTTPS と HTTP が混在しているという事は封筒に封がされていないようなもので、最初から HTTPS の利点を放棄しているのです。

これは、スクリプトであれスタイルシートであれオブジェクトであれフレームであれ、ページ上のどのような部分であっても、コンテンツを参照するために HTTPS ではなく HTTP を利用する際に発生します。悪意のあるコンテンツはページを書き換え、コンテンツを盗み取り、ユーザーをある種の安全でない動作に誘います (例えば実際にはマルウェアであるのに "プラグインのダウンロードが必要です" と表示するなど) 。

この種の攻撃については、IE Test Drive の Mixed Content Demo ページでより詳しく調べる事ができます。

セキュアでないイメージ

Internet Explorer は 10 年以上に渡り混在したコンテンツの脆弱性からユーザーを保護するのに役立ってきましたが、IE9 ではどのようなタイプのセキュアでない参照がページ内に存在しているのかを識別する機能が追加されました。HTTPS ページにセキュアでないイメージが含まれていた場合、既定ではイメージの表示は許可されます。私たちは、Web サイトが頻繁にイメージについてこの種の失敗を犯している事でもたらされるユーザー エクスペリエンスを良好にするため、このようにしました。

現実に人気のある Web サイト上にセキュアでないコンテンツが非常に多い状況ですが、私たちは多くの場合、セキュアでないコンテンツは単に一つか少数の小さなイメージである事を確認しました。セキュアでないイメージは、それに対して攻撃者ができるのはイメージの内容を書き換える事だけで、ページの他の部分を攻撃するようなスクリプトを動作させる事はできないため、混在したコンテンツの中でも最もリスクの少ないタイプです。場合によっては、それらのイメージは単なる追跡ビーコンです (これはこれで、混在したコンテンツを警告するまでもなく、 IE9 の追跡防止機能によってサイレントにブロックされます) 。とは言え多くの場合、そうしたイメージは製品のロゴや、記号のアイコンのような物です。

HTTPS にセキュアでないイメージが含まれている場合、ユーザーにすべてのコンテンツが安全に提供されているのではない事を示すため、鍵のアイコンがアドレス バーから消えます。例えば下図の左側のページ (リンク) は HTTPS で提供され、これもまた HTTPS で提供されているイメージを含んでいます; 右側のページ (リンク) はセキュアでないイメージを含んでいます。イメージは表示されますが、アドレス バーの鍵のアイコンは消えています:

ユーザーはこの動作を変更し、Internet Explorer がセキュアなページでのセキュアでないイメージの表示をブロックするようにできます。ツール > インターネット オプション > 詳細設定 で、セキュリティ セクションの 他の混在したコンテンツを持つセキュリティで保護されていないイメージをブロックする のボックスをチェックします。

子孫ルールによるより良い保護

Internet Explorer 9 には、仮にトップレベル自身がセキュアでない場合でも HTTPS で提供されるフレーム内のセキュアでないコンテンツをブロックする事による、混在したコンテンツの脆弱性に対するより強力な保護が含まれています。

この保護は、HTTPS サブフレーム内のセキュアでないコンテンツは依然として危険であるため、必要な物です。それは HTTPS で提供されるフレームの Cookie や HTML ストレージ を盗み取ったり汚染したりでき、クロス サイト リクエスト フォージェリー攻撃を行え、その他の有害な行為も行えるのです。Web 開発者は時に HTTP のページで “セキュリティで保護されたコンテンツのみ表示します” というメッセージに出会って驚くことがありますが、これは特にこのテスト ページのように HTTPS フレームが非表示になっている場合です:

これについての最良の考え方は、私が「混在したコンテンツの子孫ルール」と呼んでいる物です: HTTPS で提供されるフレーム内のすべての子孫リソースは、HTTPS 経由で提供されなければならない。そうでなければブラウザーの混在したコンテンツの警告が表示される。

残念な事に、この保護は、人気のあるソーシャル ネットワークからのウィジェットを利用している多くのサイトで一時的なちょっとした問題を引き起こします。これらのウィジェットは HTTPS サブフレームを使っているのに、それ自身は HTTP サブフレームを使っています – このアーキテクチャは初歩的なクロス ドメイン コミュニケーションのメカニズムの一部として利用されています。こうしたウィジェットはセキュアでないサブフレームを取り除いて、その代わりにウィジェットのフレームと親のページとのコミュニケーションのために HTML5 のpostMessage API を利用するよう更新されつつあります。

F12 開発者ツールによる混在したコンテンツのトラブルシューティング

Internet Explorer 9 は、F12 開発者ツール コンソールを使う事で Web 開発者が混在したコンテンツの警告の原因を発見するのに役立ちます。ブラウザーがセキュリティで保護されたページ内にセキュアでないリソースを見つけると、警告メッセージがコンソールに表示されます。このメッセージには問題のあるセキュアでないリソースの URL の表示も含まれています。

この機能はページ内のどのコンテンツがセキュアでないか発見するプロセスを劇的に単純化し、IE8 を利用していた Web 開発者の頭痛の種が解消されます。開発者はセキュアでない参照を取り除く事でコンテンツの問題を修正でき、ページがブロックされず確実に鍵のアイコンが表示されるようにできます。

ヒント: ページによっては HTTP と HTTPS のどちらからでもアクセスできます。Web 開発者はユーザーが HTTPS 経由でアクセスした場合以外は HTTPS を利用したくないかもしれません。そこで "//example.com/image.gif" のような形式の相対プロトコル ハイパーリンクを利用して、リソースのあるページの元々のプロトコルを特定するテクニックがあります。ユーザーがこのような参照を含むセキュリティで保護されたページ (例えば https://example.com/page.htm) を訪れると、結果的に URI は https://example.com/image.gif. のように評価されます。その一方、ユーザーが同じページを HTTP を使って訪問すると、結果的に URI は http://example.com/image.gif. に評価されます。この方法により、サイトの開発者は混在したコンテンツの脆弱性を招くことなく、 HTTP と HTTPS のどちらでも動作するページを容易に構築できます。

IE9 のセキュリティ保護についてのその他の情報について、このシリーズの過去の記事 (パート1パート2パート3) もご覧ください。皆様の Web を安全にする手助けに感謝します。

Eric Lawrence
プログラム マネージャー

2011年5月24日

IE9 の SmartScreen® アプリケーション評価

Filed under: IE Blog — hebikuzure @ 8:31 午後

SmartScreen® Application Reputation in IE9
http://blogs.msdn.com/b/ie/archive/2011/05/17/smartscreen-174-application-reputation-in-ie9.aspx


前の記事に続き、Internet Explorer 9 の SmartScreen のアプリケーション評価についての IE Blog の記事の私訳です。

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


IE9 の SmartScreen® アプリケーション評価

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

ユーザーを騙して悪意のあるプログラムを実行させるようなソーシャル エンジニアリング攻撃は、セキュリティー脆弱性に対する攻撃よりはるかに一般的です。IE9 のアプリケーション評価はこうしたソーシャル エンジニアリングによるマルウェア攻撃からユーザーを保護するのに有効です。この記事では現実の攻撃とこれらの防御がどのように機能しているのかについての詳細を提供します。

参考として、最近の研究 (このようなもの) は、ソフトウェアの脆弱性への攻撃が話題になっているにもかかわらず、Web ブラウジングをする人々はソーシャル エンジニアリング攻撃により多く直面している事を示しています。また最近の記事 (このようなもの) では人々を保護するための異なるアプローチについて比較しています。アプリケーション評価は、IE7 と IE8 で導入されたフィッシング サイトと悪意のあるプログラムを配布しているサイトをブロックする現行の保護機能への、自然な拡張です。

ソーシャルエンジニアリング攻撃と防御のテクノロジー

ユーザーによよってダウンロードされるマルウェアは巨大な問題であり、増大しています。

SmartScreen フィルターを通じて、IE は効果的にソーシャル エンジニアリング型マルウェア攻撃と悪意のあるダウンロードをブロックしてきました – IE は 1日に 200万から500万の攻撃を IE8 と IE9 のユーザーからブロックしています。IE8 のリリース以降、SmartScreen は 1.5億回以上のマルウェアと推測される攻撃をブロックしています。IE は依然としてソーシャル エンジニアリング型攻撃に対してこの種の保護を提供している唯一の主要なブラウザー製品です。こうしたサービスを大規模に稼働させている私たちの経験から、すべてのダウンロードされるプログラムのうち 14個に 1個は後からマルウェアと判定される事がわかりました。

元々、SmartScreen 保護は URL ベースでした。IE7 では統合されたクラウド ベースの URL 評価サービスによるフィッシング攻撃からの防御を導入しました。IE8 では別のレイヤーの保護を追加しました。URL (または Web アドレス) をベースにしている点は同じですが、悪意のあるプログラムを提供し、ソーシャル エンジニアリングのテクニック (“これを実行して無料で映画を見よう、貴方のコンピュータをクリーンにするためこのセキュリティー ソフトウェアをダウンロードしよう、格好いい顔文字を手に入れよう!”) を利用してユーザーにそれをダウンロードし実行させようとするサイトからユーザーを保護しています。ソーシャル エンジニアリング型マルウェア攻撃からの URL ベースの保護は、今日の Web 上の一般ユーザーのための防御にとって重要なレイヤーです。

とは言え、IE9 ではダウンロードされようとしているアプリケーションに注目した、ソーシャル エンジニアリング攻撃に対抗する今までとは異なった防御のレイヤーを追加しました – これが上記の URL ベースの保護に追加されています。この新しい保護のレイヤーは SmartScreen アプリケーション評価と呼ばれています。プログラムがダウンロードされようとする時、現行の他のブラウザーではすべてのファイルについて警告するか、まったく警告しないかのどちらかです。このどちらのアプローチでもユーザーがより良い判断をする助けにはなりません。アプリケーション評価ではまた、全てのブロック ベースのアプローチに存在する、Web サイトやプログラムに悪意があると識別される以前の、新規の攻撃に対する制限が改善されています。

評価システムの利用はユーザーを新規に公開された – 正規のプログラムであるように装った – 既存の防御メカニズムによって検知されていないマルウェア プログラムから保護するのに有効です。評価システムはまた、既に肯定的な評価が定まっているダウンロードに対しては IE9 が不要な警告をしないようにできます。発行者と個々のアプリケーションの両方について評価が構成されます。例えば、よく知られた発行者からのデジタル署名されたアプリケーションで幅広くダウンロードされているものは、新規に作成された Web サイトで公開されまだあまりダウンロードされていない未署名のアプリケーションに比べて、より良い評価を得ます。

現実の攻撃を解剖する

それではこの機能が現実の IE9 ユーザーをある攻撃からどのように防御するのか見てみましょう。以下の図は非常に大規模なマルウェア攻撃 (数十万ものダウンロード) のダウンロード トラフィックを示しています。アプリケーション評価機能は Web に現れたその最初の時点から、IE9 ユーザーにこの悪意のあるプログラムについて警告をしています。


実際のマルウェア攻撃のトラフィックとタイムライン

伝統的なブロック ベースの保護 (URL ブロックやアンチ ウイルス) は 11 時間後に機能しましたが、それは攻撃のアクティブな期間を過ぎた後でした。ユーザーにとってはアプリケーション評価が無い事についての IE のダウンロード警告が唯一の防御でした。この悪意のあるプログラムのダウンロードをクリックした IE9 ユーザーの 99% が、アプリケーション評価の不明なプログラムの警告からプログラムを削除するか実行しない選択をしました


SmartScreen
アプリケーション評価の未知のプログラムへの警告

この攻撃に対して、IE9 のアプリケーション評価は詐欺的な (言い方を変えれば非常に説得力のある) 攻撃を妨げ、多くのユーザーは自身で正しい判断ができました。この結果は、なぜ私たちが SmartScreen アプリケーション評価を IE9 に搭載したのか、その理由を示しています。99% のユーザーは感染を免れたのです。

これは現実での一例にすぎません。以下ではこの傾向を総体として強く維持する方法について検討します。アプリケーション評価は、現在の Web 上での大きなリスクとなっているソーシャル エンジニアリング攻撃に対する防御の大変革なのです。

速報: 評価は一般ユーザーのより良い判断に有益

IE9 ベータ版以来の IE9 利用者のデータを見ると、二つの大きなパターンがあります:

IE9 ユーザーにおけるマルウェア感染の劇的な減少
  • ユーザーは新しいアプリケーション評価の警告に対して 95% の割合でマルウェアを削除または実行しない事を選択しています
  • 私たちはアプリケーション評価が (既存の SmaerScreen URL 評価でのブロックに加えて) 1 か月あたりさらに 20万件以上の感染を防止したと推定しています。
高リスクの場合にのみ警告される洗練されたエクスペリエンス
  • プログラムと発行者は評価を確定する事ができるので、ユーザーが SmartScreen を有効にしている場合、ダウンロードされるプログラムの 90%でブラウザーからのセキュリティー警告は表示されません。
  • 私たちのデータによれば、警告は典型的なユーザーでは 1年に 2回表示されるだけです。
  • 任意の時点で、“未確認の警告” にも関わらずクリックした場合、25% から 70% の割合でマルウェアへの感染のリスクが生じます。

アプリケーションや発行者が現実の一般ユーザーから得られる評価は、この保護機能が機能するための中核です。ほとんどの人は見知らぬ人からオンラインで何かを購入する事については慎重になるでしょう。EbayEtsyAngie’s ListAmazon.com などのサイトでは、利用者がオンラインでの信頼についての判断に評価機能をどのように利用しているかが分かります。

IE9 ではユーザーがダウンロードするプログラムに対してコミュニティー評価の考え方を適用しています。ブラウザーでのユーザーのダウンロードについて私たちが収集したデータから、14個 のプログラムのうち 1個は後からマルウェアであると判断されました。一般利用者はより良い判断をするための情報を必要としています。

IE9 では、高いリスクをもたらすダウンロードは評価が未確立であるため、一般ユーザーに警告するのにアプリケーションの評価を利用します。評価の無いプログラムの 50% 以上は、その当日に Web 上に新たに登場したものです。1日単位で、IE9 でアプリケーション評価の警告を引き起こしたプログラムの 25% から 75% が、後にマルウェアであると判定されています。評価の確定しているプログラムと発行者では、警告は表示されません。

多くのユーザーはアプリケーション評価が確定していないプログラムを、ほとんど、または全くダウンロードしません。こうしたユーザーがそうする際、この警告は重要です。ユーザーは、この警告がめったに表示されないからこそ注意を払いやすいのです。私たちのデータでは、一般ユーザーはインフォームド チョイス (十分な情報を得たうえでの判断) をよく行っている事を示しています – ダウンロード元をチェックするのに時間を取り、またそれがダウンロードしようとしているものであるのか確認しています。SmartScreen アプリケーション評価により、ユーザーはマルウェアか正当なソフトウェアかを識別する作業をより良く行うことができます。

データを通じたより良いユーザー保護

私たちの目標は、一般ユーザーがダウンロードの際により安全で簡単なエクスペリエンスを得られるよう、Web 上のすべてのプログラムについて発行者の評価を確立する事です。IE9 ベータ版に至るまで、私たちは数十億のダウンロードを解析し、Web 全体にわたる信頼とアプリケーション評価の持続的なモデルを構成してきました。

こうした対応範囲の割合を維持するために、私たちは毎日数十億の情報要素を処理する、大規模で客観的な情報処理システムを構築しました。これらのシステムは継続的に新規および既存のアプリケーションと発行者への評価を構成しています。現時点で、有機的に確定された評価を持つ何万もの発行者と何百万ものアプリケーションがあり、さらに私たちはこれに日々刻々追加をしています。

一部のユーザーが、新規でまだ評価が確定していない正規のソフトウェアについて警告を目にする事があるかもしれません。私たちがコミュニティーから得た報告によれば、これは稀な例外です。確定した評価を持つ既存の発行者からの新規のプログラムは、発行者のコード署名証明書により発行者の評価を継承します。新規の発行者はダウンロードされる毎に自身のコード署名の評価を速やかに構築できます。現在までに一般ユーザーが目にした警告の 96% は未署名のプログラムが原因でした。残りの 4% の警告は過去にマルウェアと関連付けされた証明書か、評価を構成中の新規の証明書によるものです。一般ユーザーは、取引している相手を信頼してダウンロードしたい場合は、警告に関わらずクリックするというインフォームド チョイスができますし、そうしています。

開発者や発行者が評価を確立する方法

業界のベスト プラクティスに従うことにより、開発者は良い評価を得るプロセスを加速できます。たとえば、署名付きプログラムは未署名のプログラムに比べて典型的には二倍の速さで評価が定まります。私たちは Authenticode 署名によるプログラムへのデジタル署名を推奨しています。プログラムがマルウェアであると検知されないようにすることも同様に重要です。Windows Logo のプロセスもソフトウェア発行者の評価を確立するのに有効です。

安全は美

SmartScreen アプリケーション評価は日々一般ユーザーを保護しています。

皆さんの友人や家族に Internet Explorer 9 へのアップグレードを勧める多くの理由があります。安全であり続けることは、そうした理由の中でも大きなものです。

—Jeb Haber, 主任プログラム マネージャー, SmartScreen

SmartScreen® アプリケーション評価 – 評価の構築

Filed under: IE Blog — hebikuzure @ 8:17 午後

SmartScreen® Application Reputation – Building Reputation
http://blogs.msdn.com/b/ie/archive/2011/03/22/smartscreen-174-application-reputation-building-reputation.aspx


Internet Explorer 9 では、IE8 に搭載されていた SmartScreen の機能が強化され、サイトやダウンロード元の URL だけでなく、ダウンロードされようとしているファイル (プログラム) 自体の評価に基づくマルウェアのブロック システムが搭載されています。この SmartScreen のアプリケーション評価について、IE Blog の 3月の記事と 5月の記事の私訳を続けて掲載します。

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


SmartScreen® アプリケーション評価 – 評価の構築

2011年3月22日 午後5時01分

昨年 9 月の Internet Explorer 9 (IE9) ベータ版で私たちは IE9 の新たなアプリケーション評価機能を搭載し、さらに最近この機能がセキュリティーへの多層化アプローチの全体像に叶っている事についての概要を公開しました。IE9 の最終版がリリースされたので、アプリケーション評価について追加情報を皆さんと共有して、コード署名が IE のエクスペリエンスにどのように影響するのか明確にし、アプリケーション開発者が考慮すべき業界としてのベスト プラクティスについて繰り返したいと思います。

SmartScreen アプリケーション評価は一般消費者を対象とした安全機能で、消費者がダウンロードしたプログラムについてより良い判断をするのに役立ちます。ダウンロードされたファイルは、アンチウイルスの結果やダウンロード トラフィック、ダウンロード履歴、さらに URL 評価など多数の客観的な基準を考慮した複数のアルゴリズムに基づき、自動的に評価レイティングに割り当てられます。ユーザーが SmartScreen フィルターを有効にするよう同意している場合、確定した評価のないアプリケーションのダウンロードをするとファイルがコンピューターに有害である可能性について (以下のような) 通知の警告が表示されます。

この通知から、ユーザーはファイルを削除するか、警告を無視してダウンロードしたプログラムを実行するか、選択できます。典型的なユーザーでは、ダウンロードしたファイルを実行してマルウェアに感染するリスクは 25% から 40% です。私たちは長期に渡り評価を構築してきており、現在ではすべてのアプリケーションのダウンロードの凡そ 90% について、デジタル署名やハッシュに基づく確定した評価がされています。典型的なユーザーでは、この通知はあまり見ることの無いエクスペリエンスですがマルウェアの感染の危険性が高いものです。このリスクの程度を考慮すると、Internet Explorer でダウンロードされたファイルのうち凡そ 7% が後に悪意のある物だと確認されました。これらの攻撃の一部は SmartScreen URL 評価やアンチウイルス製品のようなブロックリスト ソリューションによって防がれています。しかし残念な事にこれらの攻撃からの防御に 100% 効果的なブロックリスト ソリューションは存在しません。IE9 ベータ版でアプリケーション評価が有効になって以降、この機能はダウンロード時点ではそれ以外の方法では検知されていなかったようか攻撃による感染率を劇的に減少させています。

未署名のダウンロード – IE9 アプリケーション評価の通知

署名されたダウンロード– IE9 アプリケーション評価の通知

IE9 のプログラム識別方法

ダウンロードのアプリケーション評価は以下によっています:

  • ダウンロード ファイルのハッシュ値
  • (署名されている場合) ファイルへの署名に利用されているデジタル証明書

ファイルのハッシュ値はダウンロードされたファイルの正確な識別子です。もしアプリケーションの一部が改変されたら、プログラムの識別子 (ファイルのハッシュ値) も同様に変更されます。定期的に更新される未署名のアプリケーション (例えば未署名のデイリー ビルド) は、ビルドごとに個別に評価される複数の異なるプログラムとして扱われます。

またデジタル署名されたダウンロードでは、ファイルへの署名に使用されたデジタル証明書に基づき評価されます。デジタル証明書を利用すると、評価は複数のファイルに渡る単一の識別子 (デジタル証明書) に割り当てられます。プログラムに署名が無い場合、評価は配布されるファイルのビルドごとに独自に行われます。それとは対照的に、署名付きプログラムはデジタル証明書の評価を継承します。

コード署名の利点

オンラインでアプリケーションを配布する開発者にとって、コード署名は評価の確立に不可欠ではありませんが、強く推奨されます。コード署名は、発行者の署名のあるファイルは発行者が配布しているファイルに間違いないと一般利用者が確認するための、業界でのベスト プラクティスです。署名は同様に、ファイルがサーバーに保存されている間やダウンロードの過程で、セキュリティー的な改竄がされていない事を確認するのにも役立ちます。デジタル署名が無い場合、ユーザーがファイルの真の作成者を確認する方法はありません。この脅威上の弱点は、ソーシャル エンジニアリング攻撃を通じてマルウェアの作者に利用されています。

もちろんデジタル署名の存在だけではそのダウンロードが悪意のある物ではないと証明できる訳ではありません。アプリケーションへのデジタル署名は直ちにそのダウンロードへの評価が確立する事を保証するものではありませんが、アプリケーションがそれに相応しい評価を得るのに重要な役割を果たすでしょう。

なお SmartScreen® フィルターが無効になっている場合でも、未署名のアプリケーションが実行される前にユーザーには次のような警告が表示されます:

Internet Explorer 9 – 未署名のファイルの通知

アプリケーション開発者のベスト プラクティス

アプリケーション開発者が行える、そのアプリケーションへの評価を確立し維持するために有効な業界のベスト プラクティスがいくつかあります:

  • Authenticode 署名でプログラムにデジタル署名する
    • 有効な Authenticode 署名用証明書を、Windows でサポートされている多くの証明機関 (CA) のいずれかから取得する
    • アプリケーションの配布前に、(signtool.exe のような) 開発者用ツールを使って署名する
    • コード署名のプロセスについての詳細な情報やステップ バイ ステップの説明については、Eric Lawrence の優れた記事 Everything you need to know about Authenticode Code Signing をご覧ください
  • ダウンロードがマルウェアと認識されないようにする。ダウンロードされたプログラムがマルウェアであると検知され確認されると、ダウンロードの評価だけでなくそのファイルへの署名に使われたデジタル証明書への評価にも影響します。
  • Windows ロゴ を取得する。Windows ロゴについての詳細は、MSDN の Windows 7 Logo Program のページをご覧ください。

デジタル署名とコード署名についての詳細は、以下をご覧ください:

皆さんが、一般利用者がより安全で、より洗練されたダウンロード エクスペリエンスを得られるようにされている事に感謝しています。

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

2011年5月1日

ユーザー エクスペリエンス: 私たちのデザイン プロセスについての考察

Filed under: IE Blog — hebikuzure @ 5:58 午後

User Experiences: An Insight into Our Design Process
http://blogs.msdn.com/b/ie/archive/2011/03/21/user-experiences-an-insight-into-our-design-process.aspx


病気のため間隔が開いてしまいましたが、今回は Windows 7 上の IE9 でタスクバーが画面の上や左右端にある場合の、タブのピン留めの動作についての改善に関する記事を訳しました。IE Blog にはこの後も多数の興味深い記事が掲載されていますので、引き続き私訳を続けていきたいと思います。

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


ユーザー エクスペリエンス: 私たちのデザイン プロセスについての考察

2011年3月21日 午前9時36分

皆さんのフィードバックは Internet Explorer を洗練させるのに非常に重要な役割を担っている事については以前にも記事にしました。また皆さんからのフィードバックに触発されて、IE9 製品候補版ではユーザー エクスペリエンスにいくつかの変更を加えたことについても説明しました。この記事では、私たちのデザイン プロセスについて、IE9 製品候補版に加えたタブをピン留めする機能の向上を例にしてより深い考察を行っていきます。

「サイトのピン留め」対「タブのドラッグ」

タブをピン留めする機能はIE9 の新機能です。皆さんは、アプリケーションをピン留めするのと同様に、よく表示するサイトをタスクバーにピン留めして簡単なアクセスを可能にできます。ピン留めされたサイトにより強い焦点が合わせられるよう、IE9 のフレームではサイトのブランディングが行えます。さらに Web サイトの開発者はジャンプ リストと通知をプログラムする事で、共通タスクの機能を強化できます。

私たちはユーザビリティー研究の初期のピン留めサイトの評価を行った際、ユーザーはしばしばタブをタスクバーにドラッグする事でサイトをピン留めできると期待している事に気づきました。サイトのピン留めの “物理的な” アクションとして、フレームの中のサイトの最もインタラクティブな表現がタブであるというのは理に適っています。そこで、サイトのファビコンをタスクバーにドラッグしてピン留めできるのに加えて、ベータ版ではタブのドラッグでもサイトのピン留めができるようにしました。

問題 – ユーザー意図のあいまいさを排除する

ところが、ベータ版でのタブを使ったピン留めの機能はタスクバーが画面の下端にあるときにだけ有効でした。タスクバーが画面の上端や両側にある場合にタブをピン留めしようとすると、スクリーン端へのウィンドウの位置合わせになってしまいました。ユーザーはこの機能がうまく働かない事に気づき、これはベータ版で最も多く報告された問題になりました。

これが皆さんから報告されたベータ版最大の問題である事を知って、Windows ユーザーの内タスクバーを既定の下端以外にして使っているユーザーは約 2% しか居ないという事実に照らし合わせて、非常に興味深く思いました。私たちにとって、この食い違いはリリース前のビルドをインストールするような人の大半は特に技術や IE に熱狂的で、こうした方はソフトウェアをカスタマイズして大多数の人々とは異なる方法で利用しているという事に、改めて気づかせてくれました。私たちは、より幅広いインパクトのあるユーザー エクスペリエンス上の問題と同様の熱意と注意深さをもってこの問題の解決にあたりました。

最大の困難は、利用者がタブをドラッグするのには複数の理由があるという事実に由来しています:

  • IE のウィンドウ内でタブを移動し、他の開いているタブとの順序を変更する
  • 別の IE のウィンドウにドラッグするか、ドラッグして新しい IE のウィンドウを開く
  • Windows 7 の Aero スナップ機能を使い、タブを画面の端に位置合わせする
  • サイトをピン留めする

ユーザーの意図を正しく解釈できないと、好ましくない結果を招くでしょう。

目標 – タスクバーが上端や左右にある場合でもタブのピン留めと Aero スナップを両立させる

上記のリストの一番目と二番目はタブをタスクバーまでドラッグする必要が無いので、これらのタスクは考慮しなくても良いでしょう。そこで私たちにはタブの Aero スナップとサイトのピン留めの仲立ちをする必要がある問題が残されました。タブをタスクバーの上にドラッグした時、ユーザーはタブをピン留めしようとしているのでしょうか、それともタブを画面の端に位置合わせしようとしているのでしょうか。

Aero スナップには画面の下端へ位置合わせをする機能は無いので、タスクバーが下端にある時に見解の相違は起きません。この場合はタブのピン留めがユーザーのできる唯一の動作です。一方でタスクバーが上部や左右端に配置されている場合、どちらの動作なのかの選択を常にさせるのは、すべてのユーザーにとっていつもうまく機能しないだろう事が、前述したようにベータ版へのフィードックからわかっています。そこで、タスクバーが上部や左右端に配置されている際にタブのピン留めと位置合わせを両立させることが私たちの目標になりました。

再確認 – 最上位の選択肢

ブレイン ストーミングとラフ スケッチを数回繰り返した後、私たちは最も有望そうな二つの選択肢について、あまり厳密ではないインタラクティブなプロトタイプを作成することにしました:

  1. 一番目の選択肢では、タブがドラッグされると同時にタスクバーの隣に目標となる UI を表示します。タブを目標の UI にドラッグするとピン留めされ、タスクバーのそれ以外の場所にドラッグするとウィンドウの端への位置合わせになります。
  2. 二番目のプロトタイプでは、単一の動作でピン留めとタブの位置合わせを切り替えられるようにしました。タブをタスクバー内のどこにドラッグしても、まずタブのピン留めの動作になります:

    もしタブをピン留めしたいのでなければ、一度タスクバー外にドラッグし、マウスを離さずもう一度タスクバー内にドラッグします。そうすればウィンドウは画面の端に位置合わせされます。

    このソリューションは意図的に Aero スナップよりタブのピン留めを優先しています。これは画面の端に位置合わせしたい場合には (特定のタブではなく) ウィンドウ全体をドラッグするだろうという前提のもとに、タブのピン留めは二つの動作のうちより頻繁に行われるだろうと予想したからです。

ソリューション – 単一の連続した動作

私たちは両方のアイデアの長所と短所を分析しました。同時に問題の領域に直接関係がないマイクロソフトの従業員に二つのプロトタイプを体験してもらい、どちらが望ましいか簡単にフィードバックしてもらいました。

異なるデザインの候補についての分析と、二つの主要なシナリオ (ピン留めと Aero スナップ) との比較を通じて、私たちはいくつかの理由から第二の選択肢が優れていると判断しました:

  • この方法は第一の方法より柔軟性があります。この方法ではユーザーがタスクバーの中で表示させたいと思うその場所にピン留めすることができます。これに対して一番目のデザインでは、ドラックの目標となる UI は常にタスクバーの中の同じ場所 (タスクバーに表示されているアプリケーションの最後) に表示され、サイトは必ずその場所にピン留めされます。
  • この方法はより目立たず、アプリケーション自体に注目を集めるのではなく Web コンテンツを目立たせるという私たちの包括的な目標に調和しています。この方法には追加の UI も無く、学ばなければならない新しいコンセプトもありません。ユーザーがタスクバーにピン留めしたいと思ってタブをドラッグした際に目標となる UI が表示されることもありません。単純に “うまく動作する” のです。
  • この方法はより柔軟です。単一の、連続的なアクションを通じて、ユーザーはピン留めと画面端への位置合わせの両方の動作ができます。

タスクバーが画面の下部にない場合でも、タブをタスクバーにピン留めする機能をリリース候補版の IE で利用してみていただきたいと思います。またユーザー エクスペリエンスを向上させる機会が存在するということを実感し、数百万人に影響する変更の実際のデザインを行うに至る私たちの過程を読んでいただきお役に立てていただければと思います。

IE9 を優れたものにするための、皆さんの継続的なご支援とご協力に感謝します。

—Mirko Mandic, プログラム マネージャー, Internet Explorer

Older Posts »

WordPress.com Blog.