Hebikuzure's Tech Memo

2011年8月23日

第3回ブラウザー勉強会は無事終了しました

Filed under: Information — hebikuzure @ 12:47 PM

報告が遅くなりましたが、以前にこのブログでもお知らせした「第3回ブラウザー勉強会」は無事終了しました。

当日のセッションの模様は Ustream で録画していますので、ぜひご覧ください。(http://www.ustream.tv/channel/browserws-03)
またセッション資料の公開先などの情報は ブラウザー勉強会 Web サイト に掲載しています。(http://bws.hebikuzure.com/)

次回以降もブラウザー勉強会をよろしくお願いいたします。
なお次回の「ブラウザー勉強会」は番外編として、IE10 を一つのベースラインとして、開発者やデザイナーにとってモダン ブラウザーとはどのような意味を持つのか (具体的には [広義の] HTML5 とは何か)、モダン ブラウザーに対応するにはどうすれば良いのかを伝える場を持ちたいと考えています。まだ企画段階ですが、ご期待ください。

広告

2011年8月10日

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

Filed under: IE Blog — hebikuzure @ 6:33 PM

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 PM

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

WordPress.com Blog.

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