昨年の Windows 10 Anniversary Updateでは、Webアクセシビリティのための新しいアーキテクチャを導入し、Microsoft Edgeでよりアクセシブルな Web を実現しました。この劇的な改善により、EdgeHTML 15 と Windows 10 Creators Updateでは、より多くの経験を積むことができました。

この記事では、Windows 10 Creators Updateで EdgeHTML15 で導入されたWebプラットフォームのアクセシビリティの改善点について詳しく説明します。これらの改善は、開発者のエコシステム、支援技術コミュニティ、および標準化機関との継続的なパートナーシップによって実現され、よりアクセシビリティの高いユーザーエクスペリエンスを実現するために最もインパクトのある変更を特定して実装することができました。

Windows 10 Creators Updateでは、UIA Text Patternの高度なサポートと、Windows 10 Anniversary Updateで導入されたアクセス可能なWeb Platformコアの上に構築されたWebアクセシビリティパターンのサポートが強化されています。

サイトのテキストコンテンツを操作するための改善されたサポート

支援技術ベンダからのフィードバックに基づいて、Microsoft Edge の UI Automation TextPattern サポートに大幅な改善を実装しました。UI Automation TextPattern は、スクリーンリーダーやその他の支援技術がアプリケーションのテキストコンテンツにアクセスできるようにするために設計された特別な目的の API です。

TextPattern APIsの主な構成要素は次のとおりです :

• 開始点と終了点を含むテキストコンテンツビューのスパンからなるテキスト範囲と、移動操作
• テキスト単位: 文字、単語、段落など
• Getchildren メソッドと GetEnclosingElement のようにそれらを取得する方法と、テキスト範囲内に埋め込まれたオブジェクト

テキストやオブジェクトの表示については、特定のテキスト単位でナビゲートする際に注意すべき重要な事柄がいくつかあります。

文字単位

文字には、ページ上のテキスト、およびブロック区切り記号が含まれます。後者は <br> タグなどの要素でも、1　つのブロックの終点と別のブロックの終点で構成することもできます。

この例では、 "a"、 "</ div> <div>"、 "b" は文字単位です。 文字単位の移動では、単位とオブジェクトを示すために、（CompareEndpointsByRangeで示されるように）区切り記号を導入しました。

EdgeHTML 15 では、オブジェクトの境界間の人工的セパレータを削除しました :

EdgeHTML 14 では、これは "b"、""、"c" として読み取られます-空の文字に注意してください。EdgeHTML 15 以降では、これは次の文字として読み取られます: "b"、"c"

GetEnclosingElement や GetChildren などのオブジェクトTextPattern API の場合、複数の要素にまたがる文字単位（たとえば、上記の </ div> <div> など）は、文字単位の開始を含む要素に完全に含まれているかのように扱われるようになりました 。

単語単位

単語単位は個々の文字で構成され、常に末尾の単語区切り記号が含まれます。これらの文字は、オブジェクト取得 API の動作において一貫しています。オブジェクトの最後の単位への変更を含みます。

EdgeHTML 14 では、これは単語単位 ""、"link"、"\n" で表され、ユニットの対応する外側の要素は "<li>“, “<a>“, “<li>“。EdgeHTML 15 では、単語単位 "link \ n" の囲み要素は <li> 要素になります。 文字単位と一致して、単語はもはやオブジェクト境界によって壊されません。

フォーマット単位

フォーマット単位は、UIA フォーマット属性の同じセットを持つコンテンツの連続したブロックです。オブジェクトの境界によって、フォーマット単位が壊れることもあります。フォーマット単位には、画像のようなアトミックな子のみが含まれ、オブジェクトの境界にまたがっていません。

この例では、”<img>”、”<img>” および ”here” はフォーマット単位です。既存のクライアントとの互換性を維持するために、オブジェクトの端（たとえば、隣接するリンクや表のセル）間に空のフォーマット単位を引き続き導入します。

既存のクライアントとの互換性を維持するために、オブジェクトの端（たとえば、隣接するリンクや表のセル）間に空のフォーマット単位を引き続き導入します。

ライン単位

ライン ユニットは、ブラウザー エンジンによって画面のレイアウトは、Visual 行を表します。行単位が文字単位で開始または終了するとは限りませんが、常に少なくとも 1 つの文字単位が含まれていることに注意することが重要です。行単位の GetChildren は、その行に含まれるインラインオブジェクト（リンクなど）を常に返します。

この例では、 "link"、 " "、 "link"、 "</ div> <div> text </ div>"です。 行単位になります。

段落単位

段落単位には、ブロック区切り記号で分割された単語のグループが含まれます。

この例では "</div><p>" は、単一のブロックの区切り記号に結合されます。

段落は一連の単語で構成され、GetEnclosingElement や GetChildren などのオブジェクトAPIとの一貫した動作をします。

ページ単位、ドキュメント単位

EdgeHTML ページ単位はドキュメント単位と同じで、ドキュメントコンテンツ範囲全体をカバーします。

一般的なWebパターンのサポートの改善

EdgeHTML 15 は、アクセシビリティのための一般的な Web パターンの数のサポートを向上させます。これらのいくつかを以下に説明します。

参照された非表示要素の修正された名前と説明の計算

非常に一般的なアクセシビリティパターンでは、著者は aria-labelledby、aria-describedby　のリファレンスを使用して、名前と説明の計算に使用される要素をポイントします。Microsoft Edge は、hidden（visibility：hidden、display：none）要素の参照を正しくサポートするようになりました。

この例では、最初の要素は、アクセス可能な名前を「非表示、しかしアクセス可能な名前」に計算します。

HTML lang 属性のサポートを導入

EdgeHTML 15は、UIA Culture attribute にマップされた HTML の "lang" 属性を完全にサポートするようになりました。これにより、支援クライアントは UI オートメーションを使用して複数言語のドキュメントを正しく利用できます。

空の代替テキストを持つイメージがプレゼンテーションロールにマップされるようになりました

EdgeHTML 15 では、W3C HTML アクセシビリティ API マッピングごとに、空の HTML "alt" 属性を持つ画像がプレゼンテーションロールに正しくマップされるようになりました。これは一般的なWebパターンであり、支援技術のユーザーは、画面リーダーで特定のナビゲーションモードと探索モードを使用すると、純粋にプレゼンテーションイメージの停止頻度が低くなることに気づくはずです。

よりアクセスしやすいWebプラットフォームへの旅

最後に、アクセシビリティコミュニティのメンバーによって報告された多数の問題を修正しました。

• ナレータでコントロールを二重に読み取る問題が修正されました。この修正の結果、明示的なARIAロールと組み込みコントロールの名前と同じ値にアクセス可能な記述を計算することはもうありません。
• 改善されたスクロールパターンのサポートにより、すべてのWebページでナレータのスクロールエクスペリエンスが向上しました。
• モバイルでのWebプラットフォームの文字サイズのサポートを無効にし、すべてのWebページでピンチ/ズームのサポートを有効にしました。
• UIオートメーションによるUIA TextPattern操作の信頼性向上、ツリーのトラバーサル、フォーカス、選択操作の改善
• 既存のUIオートメーションAPIを使用するすべての操作のパフォーマンスが大幅に向上しました。

Web ページとのやりとりがより迅速かつ反応的であることが期待できます。私たちは、能力に関係なく、誰にでも働く Web について情熱を持っており、Windows 10 Creators UpdateとEdgeHTML 15では、支援技術の向上した経験を共有することに興奮しています。@MSEdgeDevのこれらの変更に関するご意見は、Twitterやオープンバグポータルでお待ちしておりますので、間もなくさらなる改善をお楽しみください！

– Bogdan Brinza, Program Management Lead, Microsoft Edge
– Rossen Atanassov, Software Development Lead, Microsoft Edge
– Peter Salas, Software Development Engineer, Microsoft Edge

Updated May 25, 2017 1:45 pm

最新の web ブラウザーで最も重要なセキュリティ機能の一部は Web を閲覧するときには実際に目にすることはないものです。これらのセキュリティ機能はバックグラウンドで動作し、ハッカーがデバイスや個人データを侵害する可能性があるブラウザベースの脆弱性からお客様を守ります。

以前のブログの記事やプレゼンテーションでは、この領域で Windows 10 とMicrosoft Edge　に加えられた最近の改善点について説明しました。今回は、脆弱性対策戦略を説明する 2 部構成のブログ記事を公開し、Windows 10 Creators Update で Microsoft Edge に提供される主要なセキュリティ強化について技術的な深い知識を提供します。

脆弱性軽減戦略の枠組み

Edge に提供される主要なセキュリティ強化について深く掘り下げる前に、Web ブラウザの脆弱性の問題に対するアプローチの概要について説明します。Microsoft Edge セキュリティ チームは、脆弱性を悪用する際に攻撃者がフォローするキルチェインに沿った重要なポイントに投資を重点を置く、階層型のデータドリブンの防御戦略を採用しています。

まず、この戦略では、攻撃面を減らし、特定の脆弱性のパターンを発見または緩和することによって、 脆弱性のクラスを排除する方法を紹介します。(use after free の問題などは、MemGC を参照してください)
このようにして、攻撃者と守備側の古典的な非対称性に対抗しようとします。例えば 攻撃者に必要なのは攻撃に有効なセキュリティの問題を見つけることだけですが、防御側はセキュリティ的な問題がないことを保障する必要があります。

依然、我々はすべての脆弱性を排除することができないと仮定してたるため、攻撃者がそれらを悪用するために使用できるテクニックを破る方法を探します。これは、攻撃者が脆弱性をデバイス上でコードを実行する方法に変換しようとする際に好まれるレシピを台無しにするのに役立ちます。これは、脆弱性が悪用される可能性のある基本的な原材料とプリミティブを削除することによって、非対称性にさらに対抗します。我々はすべての攻撃を破ることができないだろうと仮定しているので、脆弱性が悪用された場合、デバイス上のダメージを封じ込め永続性を防ぐ方法を探します。

我々は、これまでの2つの戦術を再度適用していましたが、今回は Microsoft Edge のブラウザー サンド ボックス内で実行されているコードからアクセス可能な攻撃面を管理します。これにより、攻撃者の能力を制限し、さらに目的達成コストを増大させることができます。

最後に、他のすべてが失敗したと仮定して、効果的なツールとプロセスを適切な場所に配置することで、攻撃者が 脆弱性を悪用する機会を制限します。プロセス側では、Microsoft Security Response Center (MSRC) のセキュリティインシデント対応プロセスを活用しています。ツール側では、我々はWindows Defender や SmartScreen のようなテクノロジーにより、悪意のある URL からの攻撃をブロックし、Windows Update を迅速に展開し、セキュアアップデートをインストールします。

我々は、これらのすべての面でセキュリティの改善に投資し続けており、この記事の残りの部分では、最新のブラウザでー最も一般的な種類のセキュリティ問題を悪用するために使用されるテクニックを破るために行った投資に焦点を当てます: メモリ安全性の脆弱性。 具体的には、次のセクションでは、任意のネイティブコードの実行を緩和するために構築したテクノロジを紹介します。

透明性

ブラウザのセキュリティは困難な問題空間です。すべてのブラウザベンダの最善の努力にもかかわらず、脆弱性が存在し、潜在的に悪用される可能性があります。Microsoft が現在、Microsoft Edge の脆弱性に対するバグ特典を最大 $15,000 ドル、迂回バイパスおよび防御バウンティの一環としての斬新な軽減バイパスおよび防御のために$ 200,000 ドルを提供しています。これらのバウンティプログラムは、脆弱性緩和戦略へのコミットメントを強化し、世界中のセキュリティ研究者の大きな仕事に報いる手助けをします。

任意のネイティブコード実行の問題を緩和する

最新のブラウザーへの攻撃では、メモリ安全性の脆弱性をターゲット デバイス上で任意のネイティブ コードを実行するメソッドに変換しようと試みます。この手法は、攻撃の各段階を柔軟かつ均一に実行できるようにすることで、攻撃者にとって最も抵抗の少ない経路を提供するため一般的です。防御側にとっては、脆弱性の事前知識を必要とせずに攻撃者の自由の範囲を実質的に制限する可能性があるため、任意のネイティブコードの実行を防止することが望ましい。この目的のために、Windows 10　Creators Update の Microsoft Edgeは、Code Integrity Guard（CIG）とArbitrary Code Guard （ACG）を活用して、最新のWebブラウザエクスプロイトで見られる最も普遍的なプリミティブを破るのに役立ちます。: 悪質なコードをメモリにロードする。

ハッカーもまた、開発者です

一般的な Web ブラウザの悪用チェーンは、次の3つの部分から成ります :

1. ターゲットデバイス上でネイティブコードを実行するために使用されるリモートコード実行（RCE）脆弱性の悪用
2. 特権を増やし、サンドボックスをエスケープするために使用される特権の昇格 (eop) の脆弱性を悪用する
3. 取得したアクセスを活用して攻撃者の目的を達成するペイロード (例: ransomware, implant, recon, etc).

これらの部品は、攻撃者がターゲットに基づいて異なる RCE, EOP,、およびペイロードの組み合わせを選択できるようにするためのモジュール設計に自然に変換されます。結果として、現代の悪用は普遍的、悪用の第 2、第 3 の各ステージを実行するために任意のネイティブ コードを実行するのに依存します。チェーン内のこの重要なリンクを壊すことによって、攻撃者のソフトウェア設計の前提を無効にし、リファクタリングコストを強制することによって、悪用経済(原文 exploit economics )に影響を与えることができます。

悪質なネイティブコードのロードを防止する

アプリケーションは次のどちらかによってメモリに悪意あるネイティブ コードを直接読み込むことができます。
1) 悪意のあるDLL / EXEをディスクからロードするか、
2) メモリ内のコードを動的に生成/変更します。
CIGは、Microsoft EdgeのDLLコード署名要件を有効にすることで、最初の方法を防止します。これにより、適切に署名された DLL のみがプロセスによってロードされるようになります。ACGは、署名されたコードページが不変であり、新しい符号なしコードページを作成できないことを保証することによってこれを補完します。

CIG : 正しく署名された画像だけを読み込むことを許可する

CIG は、Windows 10 1511 更新プログラムからマイクロソフトの Edge のために有効になっていました。以前のブログ記事では、Microsoft、Windows ストア、または WHQL-signed の DLL を必要とする Microsoft Edge コンテンツプロセスで、カーネル強制ユーザーモードコードの整合性 (UMCI) ポリシーが有効になっている方法を説明しました。このポリシーを適用すると、カーネルは適切に署名されていない DLL をロードしようとしても失敗します。実際には、攻撃は通常、ディスクから DLL の読み込みに依存しませんが、いくつかの悪用によって使用されており、我々 の目標を達成し、包括的なソリューションを提供するために対処する必要があります。Windows 10 1511 リリース以来、我々は、CIG を強化するために追加の改善を行ってきました:

1. 子プロセスの作成を防止する  (Windows 10 1607) : UMCI ポリシーはプロセスごとに適用されるため、攻撃者がより弱いまたは存在しない UMCI ポリシーを使用して新しいプロセスを起動することを防ぐことも重要です。Windows 10 1607 では、子プロセスが作成できないことを保証するコンテンツプロセスの子プロセスの緩和ポリシーが有効になっています。このポリシーは、コンテンツプロセスのトークンのプロパティとして現在強制されており、直接 (例: calling WinExec) および間接 (例: out-of-process COM server) プロセスの起動をブロックします。
2. CIG ポリシーを早期に有効化 (Windows 10 Creators Update) : UMCI ポリシーの有効化は、プロセスの初期化時ではなく、プロセス作成時に移動されました。これは、不適切に署名された DLL をローカルのコンテンツプロセスに注入するプロセスの起動時間のギャップを排除することによって、さらに信頼性を向上させるために行われました。これは、UpdateProcThreadAttribute API を利用して、起動するプロセスのコード署名ポリシーを指定することによって実現されました。

ACG: コードを動的に生成または変更することはできません

CIG は、適切に署名された DLL のみをディスクからロードできるという強力な保証を提供しますが、メモリまたは動的に生成されたコードページにマップされた後のイメージコードページの状態については保証しません。これは、攻撃者は、CIG が有効になっている場合でも、新しいコードページを作成したり、既存のものを変更したりすることで、悪意のあるコードを読み込むことができることを意味しています。実際には、ほとんどの近代的な Web ブラウザの悪用は、最終的に VirtualAlloc や VirtualProtect のような API の呼び出しに依存します。攻撃者が新しいコードページを作成したあとにネイティブコードペイロードをメモリにコピーして実行します。

ACG を有効にすると、Windows カーネルは、次のポリシーを適用することにより、コンテンツプロセスがメモリ内のコードページを作成および変更することを防ぎます :

1. コードページは不変です。既存のコード ページは、書き込み可能にすることはできません、したがって常に意図されたコンテンツがあります。これは、コードページが書き込み可能になったり、プロセス自体によって変更されないようにするために、メモリマネージャの追加のチェックで適用されます。たとえば、VirtualProtect を使用してイメージコードページを PAGE_EXECUTE_READWRITE にすることはできなくなりました。
2. 新しい符号なしコード ページを作成できません。たとえば、VirtualAlloc を使用して新しい PAGE_EXECUTE_READWRITE コードページを作成することはできなくなりました。

組み合わせると、ACGとCIGによって課せられた制限により、プロセスは署名されたコードページのみをメモリに直接マップすることができることが確認できます。これはセキュリティに最適ですが、ACG は深刻な合併症をもたらします: 最新の Web ブラウザは、ジャストインタイム (JIT) コンパイラに最適なパフォーマンスを期待します。どのように我々 は両方のニーズを満たすことができるでしょうか?

ジャストインタイム (JIT) コンパイラのサポート

最新の Web ブラウザでは、JavaScript やその他の高級言語をネイティブコードに変換することで、優れたパフォーマンスを実現します。その結果、本質的には、コンテンツプロセス内で未署名の若干の量のネイティブコードを生み出す能力に依存しています。JIT コンパイラが ACG 対応で機能するようにすることは、些細なエンジニアリングタスクですが、Windows 10 Creator Update で Microsoft Edge に対して行った投資です。これをサポートするために、我々は独自の分離サンドボックスで実行される別のプロセスにチャクラの JIT 機能を移動しました。JIT プロセスは、JavaScript をネイティブコードにコンパイルし、それを要求してくるコンテンツプロセスにマッピングします。このようにして、コンテンツ・プロセス自体は、それ自体のJITコード・ページを直接マップまたは変更することは決してできません。

攻撃者への影響

CIG と ACG は、Webブラウザの脆弱性を悪用する際に普遍的に使用される基本的なプリミティブに対して強力な保護を提供します。これは、攻撃者が悪用の段階を連鎖させる新しい方法を開発しなければならないことを意味します。

Windows 10 Creators Updateでは、Microsoft EdgeのデフォルトでCIGが有効になっていますが、これらのシナリオで互換性のない拡張機能 (IME など) が存在するシナリオを除き、CIG と ACG は現在デフォルトで無効になっています。

互換性の理由から、ACG は現在、WDDM 2.2ドライバ (Windows 10 Anniversary Update でリリースされたドライバーモデル) を実行するプライマリ GPU を搭載した 64 ビットデスクトップデバイス、またはソフトウェアレンダリングが使用されている場合にのみ適用されます。実験目的のために、ソフトウェアのレンダリングは、コントロールパネル->インターネットオプション ->”Advanced” を介して強制的にすることができます。現在の Microsoft デバイス (Surface Book, Surface Pro 4, and Surface Studio) と、ACG と互換性があることがわかっている GPU ドライバを備えた他の既存のデスクトップシステムのいくつかは、ACG 適用を選択しています。私たちは、顧客からのテレメトリとフィードバックを評価する際に、ACG GPU オプトインリストの適用範囲と精度を改善するつもりです。

CIG と ACG の制限の1つは、攻撃者が意図しない方法で有効な署名済みコードページを活用することを妨げないということです。たとえば、攻撃者は return-oriented programming (rop) のような既知のテクニックを使用して、悪意のあるコードをメモリに読み込むことに依存しない完全なペイロードを構築することができます。Microsoft Edgeは、署名付きコードを実行時に “on the rails” に維持するために、間接呼び出しに制御フロー整合性ポリシーを適用するCFG（Control Flow Guard）を利用します。将来的には、intel の制御フロー執行技術 (Control-flow Enforcement Technology : CET) を活用して、スタック上のリターンアドレスを保護するなど、制御フローハイジャックをさらに軽減することを願っています。

最後に、Edgeでの CIG および ACG の使用は、システム上で実行されている特権コードが、署名されていないネイティブコードをコンテンツプロセスに挿入することを完全に防ぐことを目的としていないことに注意してください。むしろ、これらの機能は、コンテンツプロセス自体が悪意のあるネイティブコードを読み込もうとしているシナリオを防ぐためのものです。

次へ

今後の記事では、Windows 10 Creators UpdateでMicrosoft Edge の隔離と分離を強化するために行われた主な改善点のいくつかに焦点を当てて説明します。これらの改良点は、Webブラウザの脆弱性があなたのデバイスや個人データを侵害するのを防ぐために、次の防衛策を提供しています。

― Matt Miller, Principal Security Software Engineer, MSRC

Updated February 23, 2017 10:04 am

これらの機能は、先週リリースされた Windows Insider Preview のビルド 15019 からデフォルトで有効になっており、Windows 10 Windows 10 Creators Update から安定したリリースになります。

その背景と Object RTC

マイクロソフト Edge は、EdgeHTML 13 (windows 10 バージョン 1511) で ORTC 開始のサポートを導入し、Edge でのリアルタイム通信の初期基盤を提供しています。WebRTC 1.0 API のサポートとの我々の優先順位は、既存の web サイト上のレガシー実装と相互運用性を提供することで、他のブラウザで以前にデプロイされた WebRTC API と同じように活用します。

私たちの WebRTC 1.0 API の実装は、2015 年頃の WebRTC オブジェクト モデルを追加する前の W3C WebRTC-PC API  のサブセットに基づき、ピアツーピア音声およびビデオをサポートします。この実装はレガシの相互運用性 (WebRTC.org ソースコードの初期バージョンから構築されたモバイルアプリケーションを含む) に重点を置いているため、このリリース以降のネイティブ WebRTC 1.0 API をさらに更新する予定はありません。

Microsoft Edge RTC スタックの最も高度な機能を利用するには、とくに、個々のトランスポート、送信者、および受信者のオブジェクトを直接制御することが望ましい場合やグループのオーディオおよびビデオ通話を設定する場合には、ORTC API を考慮することをお勧めします。

現在の WebRTC 1.0 API を使用してマルチストリームや同時放送などのオブジェクトや高度な機能をサポートする必要がある場合は、Microsoft Edge をサポートする adapter.js ライブラリをお勧めします。

コーデックの相互運用性

H.264/AVC と VP8 ビデオ コーデックは、Microsoft Edge RTC スタックでサポートされており、これは現在 Microsoft Edge とその他のメジャーな WebRTC ブラウザーおよび RTC サービスで、ビデオ通信などが相互運用が可能であることを意味しています。我々は、H.264/AVC と VP8 の両方のビデオコーデックのための次の輻輳制御と堅牢性のメカニズムを実装しています:

• absolute send time header 拡張をサポート(abs-send-time)
• Google Receiver の 推定最大ビットレート, "goog-remb” をサポート
• RFC 4585によるピクチャ損失表示（PLI）および汎用NACKフィードバックメッセージのサポート
• RFC 4588によるRTP再送信のサポート

これらの機能は、ORTC API とネイティブ WebRTC 1.0 API の両方で利用できますので、API とビデオコーデックの決定を個別に行うことができます。

Edge の H.264/AVC の実装では、エンコーダーとデコーダーの両方でハードウェア オフロードをサポートしますが、VP8 は純粋にソフトウェアで実装されているので、結果として高い消費電力と CPU 負荷を示す場合があります。VP8 アプリケーションを使用する場合は、許容範囲のパフォーマンスを確保するためローエンド デバイス上でのテストをお勧めします。

次は

リアルタイムコミュニケーションのロードマップを引き続き示していく中で、次の優先事項は、W3C Screen Capture 仕様のサポートとエンタープライズシナリオのサポートの強化です。作業の進行に伴い、更新とプレビュービルドの共有を楽しみにしています。一方、我々は WebRTC と私たちの現在の RTC のロードマップにあなたのフィードバックを楽しみにしています。今日、プレビュー ビルドで WebRTC 1.0 を試すことができ、バグが発生した場合には  Twitter @MSEdgeDev、または下のコメント欄で経由で、Microsoft Edge Platform の問題についてのフィードバックを共有することができます。

― Shijun Sun, Principal Program Manager, Microsoft Edge
― Bernard Aboba, Principal Architect, Microsoft Skype

Updated January 31, 2017 10:07 am]]> https://docs.microsoft.com/archive/blogs/msedgedev_japan/chakracores-first-anniversary Wed, 18 Jan 2017 21:55:08 GMT https://blogs.msdn.microsoft.com/msedgedev_japan/?p=475 この記事はマイクロソフト米国本社の Edge 開発チームのブログ Microsoft Edge Dev blog の記事、「ChakraCore’s first anniversary」 (2017/1/13) の記事の抄訳です。 この記事についてのご質問、ご意見は元記事のほうへお願いいたします。
その他についてはこちらの記事をご参照ください。
「Microsoft Edge Dev Blog の翻訳記事を Microsoft Edge Japan ブログで公開します。」

今日は、MITライセンスの下でChakraCore - Microsoft Edge を支える Chakra JavaScript エンジンのコア - をオープンソース化してから1年を迎えました。

私たちはコミュニティのすべての方々の貢献、援助、そして我々との連携に感謝します!

あなたの貢献とフィードバックは、私たちがコミュニティのためのより良い製品を改善し、作成するのに役立ちます。

この期間中、我々は内部と外部の両方に 70 人を超えるコントリビューターを抱え、ダイレクトに ChakraCore コードベースと、いくつかの私たちと関係のある JavaScript コミュニティのメンバーの個々の能力と組織に対して貢献しました。
(※うまく訳せていないかもしれません。原文 : During this period, we’ve had over 70 contributors, both internal and external, directly contribute to the ChakraCore codebase and several other members of the JavaScript community engaged with us, both in individual capacity and as organizations.)

TypeScript、Open Translators to Things、HoloJS などの新製品とサービスは、現在　ChakraCore を使用しています。そして、コア・エンジンの外で、WebKit に ChakraCore のテストスイートが搭載されたり、ChakraShim 上に SpiderNode がビルドされたりといったように、ミュニティにとって貴重なものであると証明されるのを見るのは素晴らしいことでした。

昨年は、ChakraCore に同梱されているいくつかの機能について、実際のユーザーエクスペリエンスに重点を置いた JavaScript 言語のサポートと現実界のユーザー体験におけるパフォーマンスの最適化へのフォーカスを含めてお話ししました。さらに、我々は、タイムトラベルデバッグや WebAssembly などの新しい技術をエンジンへ持ってきました。今日は、ChakraCore のクロスプラットフォームの進捗についてもう少し詳しく共有したいと思います。

Linux 上の ChakraCore パリティへの道

オープンソースの ChakraCore に設定した重要な目標の1つは、Windows 以外のプラットフォームで実行できるようにするため、Linux を皮切りに、アプリケーションやサービスが実行されるプラットフォームに関係なく、開発者が各自のニーズにエンジンを使用できるようにすることでした。昨年 7 月、我々 は ChakraCore インタプリタと x64 Linux　(Ubuntu 16.04 LTS and Clang 3.8+)、macOS 上のランタイムの最初の実験的実装を共有しました。この実装により忠実度の高い ChakraCore JavaScript インタープリターを Linux プラットフォーム上で実行することができました。

インタプリタはスループットのパフォーマンスに関してはよくないのですが、アプリケーションまたはサービスにサイズやメモリの制約がある場合や、エンドユーザーのフォーカスがスタートアップのパフォーマンスにある場合には、非常に便利な場合があります。これは、通常、インタプリタのフットプリントとスタートアップの待ち時間が少ないためです。それらは、JavaScript JIT コンパイラに共通する動的な最適化に基づいて作成される JIT 処理コードのコピーを保持する必要はありません。JIT された関数は、一般的なコンパクトのバイトコードと比較してサイズが大きいのです。また、インタプリタが解析された直後にコードの実行を開始することもできます。

スループットのパフォーマンスが重要なシナリオでは、昨年12月にマスターブランチに ChakraCore JIT を導入しました。しかし、あらゆるモダンな JavaScript エンジンの一部である JIT コンパイラー自体は、ガベージコレクタのパフォーマンスによってパフォーマンスがすぐにゲートされるため、スループットを向上させるのに十分ではありません

私たちは今日、ChakraCore のマスターブランチで Linux 用の、ChakraCore の同時および部分的なガベージコレクターを有効にするキーである software-write-barrier サポートを実装して共有したことを喜ばしく思っています。

ChakraCore には JIT と完全に機能するガベージコレクタが搭載されているため、Windows 上の ChakraCore の主要なアーキテクチャーは現在すべて Linux に移植されています。チームは現在、国際化サポートのような残りのいくつかの機能を追加することに焦点を当てています。バグの最後のセットを退治し、Linux 上での ChakraCore のパフォーマンス特性が Windows と同等となるように最適化します。

次は

私たちの次のステップは常に我々の roadmap で利用できます。今日、我々は意図的にロードマップを意図的にアップデートしていません。なぜならばロードマップ上の現在のアイテムは Linux 上の  ChakraCore のサポートとリリース品質にもっていくための短期的なフォーカスを示しているからです。引き続き我々は ABI のステーブルな Node API とともに盛り上がっている Node.js コミュニティに協力し、さらなる JavaScript と WebAssembly の機能、と現実界での使用パターンを向上します。

我々は今後数か月の間にクロスプラットフォーム関連部分にさらなる進歩を行います。より良い Linux のサポートとパフォーマンスと ChakraCore のリリースにご期待ください。しかし、Linux や MacOS で ChakraCore を試してみたい方、早期のご意見をベータ版でご提供したい方は、ここをクリックしてください。

もう一度、私たちはすばらしい JavaScript コミュニティに協力するチームとして謙虚になり、プロジェクトに貢献してくれた皆様に感謝の意を表します。我々はコミュニティとの更なる協力を楽しみにしており、ChakraCore でより多くの開発者がプロジェクトに貢献し、クールなものを構築することを期待しています。私たちはあなたの経験、あなたのフィードバック、あなたがなにをビルドしているのか学ぶのが大好きです。ぜひ共有してください! あなたは、常に gitter 経由で ChakraCore リポジトリ、または私たちに @ChakraCore を介してつぶやきを送って私たちに到達することができます。

– Gaurav Seth, Limin Zhu, and Brian Terlson; Program Managers, Chakra

Updated January 13, 2017 10:25 am

Microsoft Edge の Content Security Policy Level 2 (CSP2) のサポートをご紹介することを嬉しく思います。これは、Microsoft Edge をお客様にとって最も安全で、最もセキュアなブラウザーにするための継続的な取り組みの新たな一歩です。CSP2を適切に使用すると、クロス サイト スクリプティングおよびコンテンツのインジェクション攻撃に対する効果的な防御のメカニズムになります。

これは現在のインサイダー  ファーストリングの の EdgeHTML 15.15002 から使用を開始することができ、安定版ビルドは  Windows 10 Creators Update ともに出荷されます。

Microsoft Edge 15.15002 on the CSP Browser Test

Microsoft Edge のすべてのバージョンでサポートされている Content Security Policy により、Web 開発者が Web アプリケーションで使用できるリソースを制限し、Web の一般的な脆弱性のままであるクロスサイトスクリプティング攻撃を防ぐことを手助けします。ただし、Content Security Policy の最初のバージョンは、スクリプトソースまたはスクリプトを直接含むインラインスクリプト要素を使用して Web サイトに実装することは困難でした。

CSP2 は、スクリプトおよびスタイルリソースの nonce およびハッシュのサポートを追加することにより、これらのシナリオを容易にします。nonce とは、CSPポリシーとページ内のスクリプトタグの両方に表示される各ページの読み込みで生成される、暗号化された強力なランダム値です。nonce を使用すると、許可されたソース URL 値のリストの維持を最小限に抑えることができ、スクリプト要素で宣言した信頼済みスクリプトも実行できるようになります。

既存のテンプレートベースの Web アプリケーションで nonce を使用するために、開発者は信頼済みインラインスクリプトごとに nonce トークンを追加します :

ページがロード時に動的に生成されると、サーバーは nonce 値を生成し、ページ内の NonceToken に挿入して、Content Security Policy HTTP ヘッダーで宣言します :

この CSP 構成により、スクリプトをページ自身のドメインまたは https://example.com からダウンロードして実行できます。

ページ内のスクリプトソース宣言に正しい nonce 値が含まれている場合は、ソース URL に関係なく、そのスクリプトをダウンロードして実行できます。これらの要件を満たさないスクリプトは、Microsoft Edge によってダウンロードすらされません。

CSP2 は、次のサポートを追加します :

• 新しいディレクティブ directives base-uri, child-src, form-action, frame-ancestors と plugin-types がサポートされています。詳細は、サポートされている CSP ディレクティブを参照してください。
• バックグラウンドワーカースクリプトは、ドキュメントの読み込みのポリシーとは別に、独自のポリシーによって管理されます。ホストドキュメントと同様に、レスポンスヘッダーでワーカーの CSP を設定できます。
• 新しいイベント、SecurityPolicyViolationEvent は、CSP の違反によって発生します。同様に、effectiveDirective（違反したポリシー）、statusCode（ HTTP 応答コード）、sourceFile（問題のあるリソースの URL ）、lineNumber、および columnNumber     など、違反レポートオブジェクトにいくつかの新しいフィールドが追加されました。

私たちは、ChromeとW3C Web Platform Tests と密接に連携して相互運用可能な実装を構築し、Content Security Policy Level 3 の W3C Web Application Security Working Groupと密接に連携していきます。

次は?

CSP2 は、Web アプリケーション開発者のセキュリティスタンスと多層防御機能の向上を継続するための重要なステップですが、まだまだ沢山あります。次に、CSP3 スペックからの strict-dynamic のサポートの追加に重点を置いて、開発者とサイト管理者がホワイトリストに対する依存を減らしCSPの実装を強化できるようにします。

われわれのレーダーに関する別の CSP ディレクティブは、upgrade-insecure-requestsです。このディレクティブの意味はサイト管理者が、Web アプリケーションの URL 大量の更新を行うことをしなくても、すべてのセキュアなトランスポートを使用して移行をより簡単にするものです。

upgrade-insecure-requests による upgrade-insecure-requests の作業は、現在は将来のバージョンの Microsoft Edge について考慮されています。

より安全な Web は同様に開発者、ユーザーとブラウザー・ベンダー問わず、より良いものです、そして、我々はより多くの Web アプリケーションが CSP が提供する保護を利用しているのを見たいです。実装を考えるのための良いリソースは、コンテンツ セキュリティ ポリシーの実装です。ぜひお試しいただき、もし Microsoft Edge での実行に問題がありましたらお知らせください。

― Ted Dinklocker, プログラミングマネージャー, Microsoft Edge

EdgeHTML 15.14986 から、Microsoft Edge は、http コンテンツエンコーディング方式として Brotli をサポートしています。この変更は、来年の早い時期にリリースされる Windows 10 Creator's Update の安定版ビルドでリリースされますが、今すぐ Windows Insider Programでプレビューすることができます。このリリースの Brotli は、Microsoft Edge、Firefox、および Chrome の最新版でサポートされており、ブラウザ間で幅広く相互運用性があります。

Brotli は、以前は WOFF2 フォント形式の一部として定義されていた利用可能な RFC 7932 で定義された圧縮形式です。HTTP コンテンツ エンコーディング方法として使用する場合、Brotli は圧縮と解凍の速度が同じで圧縮比を最大 20% 向上します (PDF)。これにより、最終的にはユーザーのページウェイトが大幅に減少し、クライアント側の CPU コストに影響を与えることなく負荷時間が短縮されることになります。Deflate のような既存のアルゴリズムと比較して Brotli 圧縮は、ファイルのサイズと CPU 時間の面で効率的です。

現在のプレビューリリースでは、Microsoft Edge は HTTPS および HTTP 接続の Brotli をサポートしています。今後のプレビューリリースでは、HTTPS 接続でのみ Brotli サポートをアドバタイズするように、この動作を更新します。Chrome と同様に、我々は HTTP 接続で Brotli コンテンツをデコードしていきます。現在のプレビューリリースでは、F12 開発者ツールが誤ってエンコード応答ヘッダーを表示しないという既知の問題があることに注意してください。

いつものように、我々 は Microsoft Edge の Brotli へのあなたのフィードバックを歓迎します! ご質問や問題がある場合は、twitter や下のコメント欄でお知らせください。私たちは、Brotliを使ってWebを少し軽くすることを非常に楽しみにしています！

― Rob Trace, シニアプログラムマネージャー Microsoft Edge

Updated December 20, 2016 10:26 am

Microsoft Edge での Payment Request API のプレビュー実装を導入することに興奮しています。これは Windows 10 の PC や携帯電話で Web 上で簡単なチェックアウトと支払いを可能にします。安定したビルドでの Payment Request のサポートは、来年早々に更新される Creators Update の EdgeHTML 15 からです。

Payment Request は Windows 10 の PC や携帯電話上の Microsoft Wallet と一緒に動作し、e コマースを顧客や販売者むけに迅速でシンプルなものにします。Payment Request API の開発は現在、Windows Insider Preview build 14986 上の Microsoft Edge から開始することができます。エンドツーエンドのテストを可能にする Microsoft Wallet のユーザーエクスペリエンスは、近日中のインサイダービルドで利用できるようになります。

チェック アウト フローのコンバージョン率は、e コマース サイトのための重要な指標です。e コマースの買い物客の 46% は、支払い段階の間の複雑で冗長なデータの再入力や、支払い情報の追跡 への不満によりチェックアウトプロセスを放棄します。(翻訳者註: tracking down = 追跡としましたが他にふさわしい表現があるかもしれません)
チェック アウトの成功率がわずかな増加でも、顧客のショッピング体験を向上させ、サイトのボトムラインに直接影響を与えます。

Microsoft Edge では、Payment Request API は Microsoft Wallet (ユーザーの権限) に接続し、ユーザーの Microsoft アカウントに関連付けられた支払い情報に簡単にアクセスできるようにします。お支払い情報はデジタルウォレットに安全に保存されるため、買い物客は、従来のチェックアウトフローをナビゲートして、同じ支払いと配送先住所情報を繰り返し入力する必要はありません。ウォレットは、Web サイト間でより速く、一貫性のあるエクスペリエンスを提供し、保存された支払い情報を安全に共有できるようにすることで、買い物客の時間と労力を節約できます。

どのように動作するのか?

ユーザーのためのより良い経験と、単一の一貫した API を開発者に提供するために、販売者、ブラウザーと支払い方法全体でコミュニケーションを標準化することを目的として、マイクロソフトと W3C Web Payments ワーキング グループの他のメンバーはAPIを設計しました。

Payment Request API では、支払い情報は、Web サイトのチェックアウトフォームを介して収集されるのではなく、(ユーザーが承認を付与した後) wallet によって提供されます。ブラウザーは、wallet と販売者の間で渡されるすべての情報を仲介します。

Payment Request API をサンプルサイトに実装する方法を見てみましょう。

コンストラクタ

まず、コンス トラクタを使用します。Payment Request オブジェクトは、次のパラメータを渡すことによって構築されます。

• methodData: 支払方法の識別子と関連するデータを含むディクショナリの配列; 支払方法の識別子は、サポートされている支払方法を識別する文字列です。
• details: 注文の品目など、トランザクションの情報
• options: ウォレットが収集する必要がある追加情報

上記のスニペットでは、ユーザーが Visa、MasterCard、または Amex のネットワークに属するデビットまたはクレジットのいずれかで支払うことができます。詳細オブジェクトには、代金、消費税、および合計の支払額が含まれます。これらの詳細は、ウォレットのユーザーに表示されます。APIはアイテムを追加したり、売上税を計算したりしないことに注意してください - 正しい情報を提供するのは販売者の責任です。 この例では、我々は物理的な商品を販売しているので、顧客の配送先住所を収集するためにウォレットに尋ねています。

UIの表示、支払いの処理、結果を表示する

Payment Request オブジェクトが作成されると、request.show () でウォレットを表示するようにブラウザをトリガーすることができます。Microsoft Edge では、このユーザーに Microsoft Wallet からのチェックアウトダイアログボックスが表示されます。:

カスタマーは、適切な支払情報、送付先住所、およびその他のフィールドを選択し、準備ができたら [Pay] ボタンをクリックすることができます。この時点で、ユーザーは識別を確認する必要があるでしょう。成功した場合、これは request.show () プロミスを満たし、カスタマーがウォレットに提供したすべての情報をウェブサイトに返します。基本的なカード決済方法については、結果オブジェクトにカード名義、カード番号、有効期限、その他の関連項目が含まれます。販売者はバックエンドでトランザクションを処理するのにこの情報を使用できます。

応答がサーバーから戻った後、result.complete('success')を使用してウォレットに成功画面を表示し、失敗したトランザクションを示す result.complete('fail') を表示できます。

イベントのリッスン

価格は顧客が選択した配送先住所と配送オプションによって変わる場合があります。これらの変更を shippingaddresschange と shippingoptionchange イベントで聴くことができ、それに応じて価格を再計算します。

機能の検出

サイトは、Payment Request API の検出機能を備え、利用可能でない場合は従来のフォームベースのエクスペリエンスに転送することができます。

このコードの最小限の実装の例を次に示します。

テストと可用性

支払い要求 API は、電話とデスクトップで最新の Windows インサイダープレビューリリース (14986 以上) で始まるデフォルトでオンになっています。エンドツーエンドのテストを可能にする Microsoft ウォレットユーザーエクスペリエンスは、近日中のインサイダービルドで利用できるようになります。このプレビュー期間中、Microsoft ウォレットの基本的なカードの支払い方法の応答は、PCI の制約に対処することがなく初期統合テストを行う開発者を支援するための偽の支払いカードの応答になります。

来春から、API は実際の支払いカードの応答を返すようになります。最初に、ウォレットは米国の課金と配送先住所と英語 (en-US ロケール) をサポートします。その他の地域と言語のサポートは、2017 年に追加されます。

まとめ

Microsoft ウォレットと Payment Request API 組み合わせは、Web 上のチェックアウトのコンバージョンを改善し、顧客により快適で便利なショッピング体験を提供する強力なツールを販売者に提供します。この API は、Web プラットフォームのパワーと柔軟性の偉大な例であり、 Chrome  54 から始まる API をサポートした Android 用 Chrome との広範な相互運用性への道のりです。

Microsoft edge の Payment Request API の詳細と完全なドキュメントは、Microsoft Edge Dev の Payment Request デベロッパーガイド、および MSDN の Payment Request API リファレンスでご利用いただけます。Windows インサイダープログラムに参加するか、 Microsoft Edge Dev から PC 用もしくは Mac 用のプレビュー仮想マシンをダウンロードすることによって Payment Request やその他の EdgeHTML15 の新しい機能をプレビューすることができます。

問題が発生した場合は、bugs.microsoftedge.com にバグをファイルしたり、twitter の @MSEdgeDev で私たちとつながることができます。私達はあなたからのヒアリングを楽しみにしています!

― Andy Pavia, Program Manager, Microsoft Edge

Updated December 16, 2016 10:05 am

Adobe Flash は数十年にわたり Webの不可欠な部分となっており、HTML5 が導入される以前からブラウザーでリッチなコンテンツやアニメーションを実現しています。現代のブラウザでは、Microsoft、Adobe、Google、Apple、Mozilla などに開拓された Web 標準によって、多くの他のサイトが Flash なしでこれらの経験を超えたパフォーマンスとセキュリティを向上させることを可能にしました。Windows 10 のAnniversary Edition から、ページの中心ではない広告のような特定の Flash コンテンツを一時停止することで、ユーザーが Flash をより細かく詳細に制御できるようになりました。

次のリリースでは、Flash コンテンツの読み込み時に追加のユーザーコントロールを提供することにより、この機能を拡張し HTML5 の代替案への移行を推進します。Windows Insider は、今後のプレビュービルドですぐにこの機能の早期実装を試すことができるようになります。

ユーザーエクスペリエンスは、来年の Windows 10 Creator's Update で安定したリリースに移行するにつれ進化することでしょう。HTML5 をサポートするサイトは、既定でクリーンな HTML5 エクスペリエンスが設定されます。このような場合、Flash は読み込まれずパフォーマンス、バッテリ寿命、およびセキュリティが改善されます。Flash に依存しているサイトでは、ユーザーは Flash を読み込んで実行するかどうかを決める機会があり、その際の設定はその後の訪問でも保持されます。

(ユーザーがブロックされた Flash コントロールをクリックしたときのユーザーエクスペリエンスのサンプル)

我々は、フラッシュは、今日多くの Web エクスペリエンスの不可欠な部分であることを深く認識しています。HTML5 への移行を容易にするために、これらの変更は当初、今日の Flash に依存する最も人気のあるサイトには影響しません。今後数ヶ月には、我々はマイクロソフトEdgeでの Flashのコンサンプション(消費)を活発にモニターして、自動例外のリストを徐々に短くします。このプロセスが終了すると、ユーザーは制御されたままで、訪問したサイトに対して Flash を選択することができます。

我々は Web 開発者に今後数ヶ月で JavaScript や HTML5 暗号化メディア拡張機能 (Encrypted Media Extensions)、メディア ソースの拡張(Media Source Extensions)、キャンバス (Canvas)、Web オーディオ (Web Audio) 、および RTC のような標準化されたコンテンツ配信メカニズムに移行する web 開発者をお勧めします。

この変更により、すべてのユーザーがパフォーマンスを向上し、安定性を高め、セキュリティが強化されます。これらの変更は、我々の友人である Apple、Mozilla、および Google からの更新に似ています。

これらのパートナーおよびAdobeとの継続的な協力により、すべてのユーザーのWebの機能とセキュリティを向上させることを楽しみにしています。

― John Hazen, PM Manager, Microsoft Edge
― Crispin Cowan, Senior Program Manager, Microsoft Edge

Updated December 15, 2016 9:55 am

公開される順番は、より情報量が多いものからとさせていただきますので、時系列順ではありませんのでご了承くださいませ。

ドライブバイ攻撃からユーザーを守るべく機能強化された Microsoft SmartScreen

Microsoft Edge、Internet Explorer、Windows オペレーティング システムに統合されている Microsoft SmartScreen は、Internet Explorer 7 で導入されて以来、フィッシングやマルウェアのダウンロードなど、ソーシャルエンジニアリング攻撃からの保護に効力を発揮してきました。URL レピュテーション チェック (英語) と アプリケーション評価による保護を提供する SmartScreen は、この 8 年間で数十億件もの Web ベースの攻撃からユーザーを保護してきました。SmartScreen は徐々にその範囲を広げ、フィッシング攻撃とソーシャルエンジニアリング型のマルウェアからの保護だけでなく、偽装広告 (英語) の警告機能が加わり、詐欺サイトにも対応するようになりました。

本日 Microsoft は、最新の Windows 10 更新プログラム (英語) を発表しました。この更新において SmartScreen の機能を拡張し、Microsoft Edge と Internet Explorer 11 にドライブバイ攻撃対策を実装しました。

ドライブバイ攻撃とは

ドライブバイ攻撃は、一般的なソフトウェアに存在するセキュリティの脆弱性を狙った悪意のある Web 攻撃です。信頼されている Web サイトが攻撃の基点になる傾向があります。しかも、ユーザーの操作を必要としないことが多く、クリックやダウンロードする対象がないため、通常、気付かれることなく感染します。

ドライブバイ攻撃では、効果的に拡散できるよう、エクスプロイト キット (英語) (EK) と呼ばれるサービスが利用されます。EK はまず、ソフトウェアの脆弱性 (CVE (英語) により公的に追跡されている脆弱性) がないかユーザーの PC を調べて、見つかった場合、その脆弱性の悪用を試みます。この脆弱性は、新しく発見された脆弱性 (ゼロデイとも呼ばれます) であることも、一般的なソフトウェアの脆弱性で既に修正済みのものであることもあります。この 1 年間で、アプリの脆弱性修正プログラムが提供されてから攻撃に利用されるまでの期間が短くなり、ゼロデイ脆弱性を悪用するケースも増えていることが確認されています (英語)。

この傾向を踏まえると、セキュリティ更新プログラムの適用は、さらに急がれることになります。また、修正プログラムを適用すれば、EK 対策は万全とはいかなくなりました。さいわい、Microsoft では、Microsoft Edge、Internet Explorer、Bing、Defender、Enhanced Mitigation Experience Toolkit (EMET) などのソースから広範にわたるデータを利用して、このような攻撃が発生するとすぐに攻撃を認識し、その情報をインテリジェンスに変えて、ブラウザーの SmartScreen ドライブバイ攻撃保護機能に活かしています。

この全社を挙げてのインテリジェンスの取り組みでは、ブラウズ エクスペリエンスや Web インフラストラクチャについての情報だけでなく、Windows オペレーティング システム全体から収集された動作についての利用統計情報も加味されます。これは、Microsoft でなければできない取り組みです。こうして得られたインテリジェンスは、現在進行形での潜在的な攻撃の検出や、新しい脅威の検出に役立てることができます。 このしくみを説明するため、具体的な事例を見てみましょう。

SmartScreen のドライブバイ攻撃保護機能があれば、修正プログラムが提供されていない場合であっても、このような脅威を未然に阻止し、ユーザーを感染から保護できる可能性があります。

SmartScreen の保護機能はどう進化しているか

ソーシャル エンジニアリング攻撃を防ぐ既存の SmartScreen の保護とは異なり、ドライブバイ攻撃の場合は、Web コンテンツが解析およびレンダリングされる前に、検出し、阻止する必要があります。ブラウジングのパフォーマンスに影響しないよう、SmartScreen では、SmartScreen サービスが作成した、サイズの小さいキャッシュ ファイルをドライブバイ攻撃からの保護に活用しています。このキャッシュ ファイルは、ユーザーの安全を保つため、ブラウザーによって定期的に更新されます。また、ページに悪意のあるコンテンツが含まれている可能性が高いと思われる場合にのみ、SmartScreen サービスを呼び出すためでもあります。

SmartScreen が Web サイトを悪意のあるサイトの可能性があると判断した場合、Windows 10 の Microsoft Edge または Internet Explorer 11 には赤の背景で警告が表示され、サイトのコンテンツは表示されません。

Microsoft SmartScreen の警告画面

SmartScreen では、安全でない広告など、.悪意のある可能性があるフレームについても警告を表示できます。これまでは、安全でないフレームがページに含まれていた場合、コンテンツをホストしている Web ページ自体は安全であっても、フルページの警告が表示されました。今では、悪意があると疑われるフレームにのみ警告が表示されるようになり、ページの他の部分はそのまま操作できるようになりました。

Microsoft SmartScreen のフレームの警告

SmartScreen の警告ページで [詳細情報] リンクを展開して Microsoft にサイトが安全であることを報告するか、警告を無視できます。ただし、警告は無視しないことを強くお勧めします。フレーム内に表示された警告については、アドレスバーの [安全でないコンテンツ] バッジをクリックすると、同じオプションを表示できます。

注意: すべての既存の SmartScreen の設定と制御 (グループ ポリシーを含む) は、SmartScreen の新しいドライブバイ攻撃保護機能に適用されます。

その他にユーザーが実行できる対策

一般的なソフトウェアやブラウザー、オペレーティング システムで既に修正されている脆弱性を狙ったドライブバイ攻撃の場合は、セキュリティ更新プログラムが提供されたらインストールすることが非常に重要です。

また、安全でないと思うサイトを見つけた場合、次の手順で Microsoft に報告できます。

• Windows 10 での Microsoft Edge の場合: [詳細] メニューをタップまたはクリックし、[フィードバックの送信] を選択して、[安全でないサイトを報告する] を選択します。
• Windows 10 の Internet Explorer 11 の場合: [ツール] ボタン をタップまたはクリックし、[セーフティ] をポイントして、[安全でない Web サイトを報告する] を選択します。

これらの機能強化が皆様のお役に立てば幸いです。ぜひ、フィードバックをお寄せください。ご質問がある場合は、Twitter で @MSEdgeDev までお気兼ねなくお問い合わせください。または、下のコメント欄をご利用ください。

– OS セキュリティ、プログラム マネージャー、Jasika Bawa
– SmartScreen、シニア プログラム マネージャー、Ryan Colvin]]>