Hebikuzure's Tech Memo

2013年12月25日

これからの Internet Explorer

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 9:22 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 25 日目です。


Advent Calender の最後に Internet Explorer のこれからについて予測を含めて書いてみます。

リリース サイクル

Intenrnet Explorer のリリース サイクル (メジャー バージョン アップの間隔) はだんだん短くなっています。この傾向はしばらく維持されるのではないかと思います。もちろん Chrome や Firefox のように 6週間おき、というほどには短くならないでしょうが、1年以内に次のメジャー バージョンがリリースされるというサイクルは続くでしょう。そして Windows 8.1 と Internet Explorer 11 の組み合わせのサポート ポリシーのように、サポート ライフサイクル的にも常に最新バージョンの Internet Explore へのアップグレードが必要になっていくでしょう。

これは多くの (特に日本国内の) 企業内 IT 管理者、イントラネット システム開発者に今までの習慣の変更を迫るのではないかと思います。企業内 IT 管理者やイントラネット開発者は Internet Explorer (とそれを含む Windows 製品) のリリース前の段階から検証やテストをするのではなく、製品リリース後に自社への導入計画が出た時点で初めて検証やテストを開始していた場合が多かったでしょう。
しかしこれからの Microsoft の Internet Explorer を含む製品のリリース サイクルでは、そうした悠長な事をしていると導入した製品がすぐに、最悪の場合は導入完了前にサポート期限切れになってしまいます。どのタイミングで新しい製品の導入を開始しても良いよう、製品のプレ リリース段階からベータ版 (開発者プレビューやカスタマ プレビュー) を利用して、検証やテストを行い、自社のシステムが新しい製品でも問題なく機能するよう、必要なメンテナンスを継続的に行っていく必要が生じてきます。

これは一見管理者や開発者の負荷を増やすように考えられますが、Internet Explore 自体は Web 標準に準拠した動作と機能が利用できるようになってきましたので、管理者や開発者は標準として確立している機能や動作にフォーカスしていけば、自ずと新しいバージョンの Internet Explorer でも問題なく動作するシステム / Web アプリケーションを維持していく事が可能です。管理者や開発者が注意すべき事項が明確かつ限定されるという点では負担軽減になるのではないでしょうか。

後方互換性

Internet Explorer 7 以前との後方互換性は維持されなくなると考えられます。つまり (Good Old) IE6 とその互換モードでのみ動作するようなシステム / Web アプリケーションは、動作させる事自体ができなくなる時期が近づいているという事です。

実際に Internet Explorer 11 ではドキュメント モードが非推奨になっています。つまりサーバー ヘッダーやページ内の指定で後方互換モードでページを表示するよう指定する事が推奨されなくなったのです。Internet Explorer (に限らず Microsoft 製品、と言うよりソフトウェア製品の一般的傾向として) では非推奨となった機能は、将来のバージョンで機能自体が廃止されるのが通例です。という事は、Internet Explorer の今後のバージョンでは、ドキュメント モードを利用して後方互換モードでページを表示させる事自体ができなくなってしまうと考えられます。

前掲のリリース サイクルの高速化とサポート ポリシーの変化でも述べたように、企業内 IT 管理者、イントラネット システム開発者もその労力をシステム / Web アプリケーションの後方互換性の維持に費やすのではなく、Web 標準への準拠に費やすべき時期に来ていると思います。

高速化

現在のブラウザーは、いずれも高速化を競い合っています。高速化を図る領域はページのレンダリングであり、JavaScript の実行速度であり、(JavaScript では限界がある場合は) アクティブ コンテンツの高速実行環境の実装 (ex. NaCl) であり、ネットワークのパフォーマンス (ex. SPDY) です。

Internet Explorer もその例に漏れず、この数年で大幅な高速化を図ってきました。この流れはこれからも続くでしょう。その中でも特に企業内 IT 管理者にとって注意が必要なのは、ネットワーク関連の高速化です。例えば Internet Explorer 11 でサポートされているプリレンダリングとプリフェッチ機能は、ユーザーが利用するページによってはネットワーク トラフィックを増大させます。こうした機能がさらに強化されれば、ネットワークの管理に影響を及ぼす可能性もあるでしょう。

また Windows 8.1 上の Internet Explroer 11 で SPDY がサポートされたように、高速化のための新しい Web プロトコルへの対応も進むでしょう。次のバージョンでは HTTP 2.0 がサポートされるかもしれません。こうした新しいプロトコルも企業内ネットワークにインパクトがあるでしょう。例えばプロキシの構成によってはこうした新しいプロトコルが正しく通らなかったり、また (SPDY や HTTP 2.0 のような暗号化を前提としたプロトコルが普及すれば) DPI (Deep Packet Inspection) を行うようなセキュリティ システム (情報漏えい防止など) の動作に問題が生じるかもしれません。

こうした観点からも、企業内 IT 管理者は早期に Web 標準の動向を掴み、それに準拠した新しいバージョンの Internet Explorer の検証とテストを (プレリリース版の利用を含めて) 継続的に行っていく事が重要になるでしょう。

ユーザー インターフェイス

ユーザー インターフェイスについては、デスクトップ版の Internet Explorer については当面大きな変化はないのではないかと思います。既に IE6 –> 7 –> 8 –> 9 と大きく変化し、削れるものはすべて削った、という状態になっているからです。またデスクトップ版のキーボードとマウスを前提にした操作体系も、もうあまり変更する余地は無いような気がします。
これに対してタッチ対応の Internet Explorer はまだまだ改良の余地があると思います。よりタッチで使いやすく、さらにタッチ以外のナチュラル インターフェイス (Kinect とか Leap Motion とか) の利用も含めた多くの操作手段の提供など、しばらくはバージョン アップの度に新機能が搭載されるのではないかと思います。

他のプラットフォーム

Internet Explorer 11 の正式名称から「Windows」が外れた、という事で以前のように Windows 以外のプラットフォームへの Internet Explorer の提供が復活するのでは、という推測も成り立ちますが、Internet Explorer を Internet Explorer たらしめている多くの機能が Windows 自体の実装と密接に関連しているだけに、他のプラットフォームへの提供はやはりあり得ないと思います。むしろ噂されている Windows Phone と Windows (ARM) のカーネル共通化などを通じて、Microsoft 製品内での共通 Web プラットフォームとして Internet Explorer が活用される、というシナリオの方が考えられそうです。

また以前はブラウザー間の相違や独自機能が多かったため、それらを利用した Web サイトのユーザー ベースを増やすためにも他プラットフォームへの提供が必要であったと考えられますが、現在の Internet Explorer は Web 標準に準拠する事を何よりの目標としており、他のプラットフォームの他のブラウザーと、Windows での Internet Explorer がまったく同じように動作する事が理想ですから、敢て他のプラットフォーム用に提供する意味はないでしょう。

おわりに

25 日間の Advent Calender はこれで終了です。この 25 日間は Internet Explorer について改めて勉強しなおし、また最新の情報を確認しなおす良い機会でした。この 25 日間に投稿した内容が多くの皆さんの役に立てば幸いです。

2013年12月24日

Internet Explorer のセキュリティ ゾーン

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 8:37 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 24 日目です。


Internet Explorer では Web サイトがネットワーク上のどのような場所にあるかによってセキュリティ関係の設定が変更される、「セキュリティ ゾーン」という機能が搭載されています。例えば一般的なインターネット上のサイトでは多くの Web ページの表示に支障がない程度にアクティブ コンテンツ (スクリプトや ActiveX など) の動作を制限しつつ、企業の LAN 内に存在するイントラネット サイトでは業務用 Web アプリケーションが円滑に動作するようより少ない制限に設定する、といった事ができます。これはは他のブラウザーでは類似の機能が無い、Internet Explorer の独自の機能です。

セキュリティ ゾーンは以下の4つに分けられています。

image

  • インターネット ゾーン
    通常のインターネット上のサイトです。安全でない可能性のあるコンテンツのダウンロードや実行には制限があります
    Windows Vista 以降では保護モードが既定で有効です
  • ローカル イントラネット ゾーン
    イントラネット内のサイトです。既定ではほとんどのコンテンツが警告なしに実行されます
    Windows Vista 以降では保護モードが既定で無効です
    Internet Explorer 8 以降では、このゾーンのサイトを互換モードで表示させる事ができます (IE8-10 では既定で有効、IE11 では既定で無効)
  • 信頼済みサイト ゾーン
    既定ではどのサイトも属してしません。
    ユーザーがサイトを登録する事で、インターネット上のサイトをより少ない制限で動作させる事のできるゾーンです
    Windows Vista 以降では保護モードが既定で無効です
  • 制限付きサイト ゾーン
    既定ではどのサイトも属してしません。
    ユーザーがサイトを登録する事で、インターネット上のサイトをより強い制限の下で動作させる事のできるゾーンです。安全性の低い機能は無効になります
    Windows Vista 以降では保護モードが既定で有効です

それぞれのゾーンのセキュリティ設定の詳細は、以下の資料を参照してください。

Internet Explorer 7 以降では、ドメインに参加している場合などを除き、既定の設定ではローカル インターネット ゾーンは利用されません。その状態で (インターネット上ではない) イントラネット内の Web サイト (“.” を含まない URL) にアクセスすると、「イントラネット設定は既定でオフになりました」という情報バーまたは通知バーが表示されます。
イントラネット ゾーンがオフになっている場合、信頼済みサイトまたは制限付きサイトに登録されていないサイトはすべてインターネット ゾーンに割り当てられます。
ローカル イントラネット ゾーンを有効にするには、以下の操作をします。

  1. [インターネット オプション] を開き、[セキュリティ] タブを表示します
  2. [ローカル イントラネット] アイコンをクリックし、[サイト] ボタンをクリックします
  3. [イントラネットのネットワークを自動的に検出する] のチェックを外します
  4. 他のすべてのチェック ボックスをオンにし、[OK] を 2 回クリックします

    image

参考 イントラネット セキュリティ設定の変更 (http://windows.microsoft.com/ja-jp/windows-vista/changing-intranet-security-settings)

上記の説明と少し重なりますが、Web サイトは以下の方法でインターネット ゾーンまたはローカル インターネット ゾーンとして認識されます。

  • コンピューターが接続しているネットワーク内に Active Directory ドメイン コントローラーが存在する場合、イントラネットのネットワークが自動的に検出され、ネットワーク内のサイトはイントラネット ゾーンと判定されます
  • [イントラネットのネットワークを自動的に検出する] のチェックが外れている場合、他の設定に応じてイントラネットのサイトかどうか判定されます
    • 他のゾーンに含まれていないすべてのローカル (イントラネット) サイトを含める
      ドット (“.”) の含まれない名前が割り当てられてられているサイト (http://localhost など) はイントラネットとして判定されます。反対に、ドットが含まれるサイト名 (http://www.microsoft.com など) はインターネット ゾーンに割り当てられます。
    • プロキシ サーバーを使用しないサイトすべてを含める
      多くのイントラネットではプロキシ サーバーを使ってインターネットにアクセスし、イントラネット サーバーには直接接続します。この情報を利用し、プロキシ サーバーを利用しないで接続できるサイトはイントラネットとして判定されます。逆にプロキシ サーバーを経由するサイトはインターネット ゾーンに割り当てられます。プロキシ サーバーがこのように構成されていない場合はこの設定を利用せず、別の方法でローカル イントラネット ゾーンを指定する必要があります。プロキシ サーバーが使われていないネットワークではこの設定は無効です。
    • すべてのネットワーク パス (UNC) を含める
      ネットワーク パス (\\servername\sharename\file.txt など) でアクセスされるコンテンツをイントラネットとして判定します。
  • イントラネット ゾーンに割り当てられないサイトで、信頼済みサイトまたは制限付きサイトに登録されていないサイトは、インターネット ゾーンに割り当てられます。

前述のようにインターネット ゾーンとイントラネット ゾーンではアクティブ コンテンツの動作や表示モードが異なる場合があるので、Web サイトの動作が意図通りではない場合、適切なセキュリティ ゾーンとして認識されているかどうか確認する事が必要です。例えば同じサイトでも、ホスト名 (http://hostname) でアクセスすればイントラネットとして認識されますが、FQDN (http://hostname.company.jp/) や IP アドレス (http://192.168.100.25/) でアクセスするとインターネット ゾーンに割り当てられます。

参考 : FQDN または IP アドレスを使用すると、イントラネット サイトがインターネット サイトとして識別される (http://wp.me/p160Sl-2C)

2013年12月23日

Internet Explorer の「追跡防止」

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 11:12 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 23 日目です。


Internet Explorer にはいくつかのプライバシー保護機能が搭載されていますが、今日はその中から「追跡防止」について解説します。

ターゲッティング広告のようにインターネット上のユーザーの行動を調査し、それに基づいたマーケティングを行うのは現在では珍しくない事ですが、ユーザーからすると無制限に自分のオンラインでの行動を追跡される事は好ましくないと感じる場合があるでしょうし、過剰なターゲッティング広告にうんざりする場合もあるでしょう。
こうしたユーザーの行動追跡は主に、Web ページに埋め込まれているさまざまなサードパーティー (つまり Web ページをホストしているドメイン以外のドメインでホストされている) のコンテンツによって行われています。例えば Web ビーコンと呼ばれるごく小さな画像であったり、特定のスクリプトであったり、また Flash のコンテンツなどを通じて、ユーザーが表示したページやそのページを表示した際のリファラー (直前に表示していたページ情報)、ページを検索した際のキーワードなどの多くの情報がサードパーティーのサーバーに送信され、収集されます。そのような情報を通じてユーザーの行動が分析され、ターゲッティングが行われます。
Internet Explorer では特定のルールに基づいてこのようなサードパーティーのコンテンツをブロックできます。これが「追跡防止」機能です。

Internet Explorer の追跡防止の機能は二つの部分に分かれています。一つは外部から提供される「追跡防止リスト」に基づいてサードパーティーのコンテンツをブロックする機能、もう一つはユーザーの表示した Web ページに含まれるサードパーティのコンテンツを記録し、そのリストからユーザーがブロックまたは許可するコンテンツを選択できる「個人用リスト」の機能です。
これらの機能は Internet Explorer の「アドオンの管理」から設定できます。「アドオンの管理」を開き、[アドオンの種類] で [追跡防止] を選択すると、利用可能な追跡防止リストが表示されます。ここで [追跡防止リストをオンラインで取得] をクリックすると、Internet Explorer ギャラリーのページが開き、追跡防止リストを追加する事ができます。また追加済みの追跡防止リストを選択すると、リストの有効 / 無効を切り替える事ができます。

Internet Explorer ギャラリーのページは日本語版より英語版の方が提供されているリストの種類が多いので、必要に応じて英語版に切り替えて利用すると良いでしょう。

image
リストを追加できる

image
リストの有効 / 無効の切り替えやリストの削除ができる

追跡防止リスト

ダウンロードできる追跡防止リストの仕様やブラウザーの動作については、Microsoft が W3C に標準化を提案しており (http://www.w3.org/Submission/2011/SUBM-web-tracking-protection-20110224/)、その提案の中で詳しく解説されています。具体的には、リストには有効期限やブロックするドメイン、許可するドメインを単純なテキスト形式で記述します。以下は Google が提供しているユーザー追跡機能をブロックするリストの記述例です。

msFilterList
: Expires=1
# Blocks 3rd-party Google tracking
# Last Modified: 11/07/2013
#
-d news.google.com
-d youtube.com
- apis.google.com/*plusone*
-d plus.google.com
-d googleadservices.com
-d googletagservices.com
-d googlesyndication.com
-d googleadservices.com
-d google-analytics.com
-d doubleclick.net
-d doubleclick.com
-
http://google.*/api/sclk?
-
http://google.*/client_204?
-
http://google.*/gen204?
- google.com*/lh/ajaxlog?
- google.com*/uds/stats?
- google.com*/bin/stats?
- google.com*/log?
- google.com*/buzz

「-」はブロックする事を、「d」はドメイン全体を対象にする事を示しています。この中にはありませんが、「+」は許可する事を示します。
追加された追跡防止リストの情報は、以下のレジストリ キーに登録されます。

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Safety\PrivacIE\Lists

個人用リスト

個人用リストはユーザーが表示した Web ページに含まれているサードパーティーのコンテンツの履歴を元に、ユーザーの設定でブロックや許可を行う仕組みです。

個人用リストを利用してサードパーティーの追跡用コンテンツをブロックするには、まず [アドオンの管理] の [追跡防止] で [個人用リスト] を有効にします。この状態で普段通りに Web ページのブラウジングを行っていくと、そこで利用されている追跡用コンテンツを提供しているドメインが記録されていきます。
次に [アドオンの管理] の [追跡防止] で [個人用リスト] の設定をクリックし、[個人用追跡防止リスト] を開きます。

image
[個人用リスト] の [設定] を開く

[個人用追跡防止リスト] には、閾値以上の複数のサイトで検出されサードパーティー コンテンツとその提供元ドメイン (プロバイダー) が一覧で表示されます。[自動的にブロックする] を選択すれば、リストに表示されたコンテンツが全てブロックされ、リクエストされず表示されなくなります。閾値は [この数の訪問済みサイトで使われているプロバイダー コンテンツを表示します] の欄で設定できます (既定値は 5 です)。

ちょっと分かりにくいのですが、[この数の訪問済みサイトで使われているプロバイダー コンテンツを表示します] の「表示します」は上のリストに表示します、という意味で、リストに表示されたコンテンツがブロックされれば、そのコンテンツは (Web ページ上には) 表示されなくなります。

image

また [ブロックまたは許可するコンテンツを選択する] を選択すれば、リストに表示されたドメインを個々に選択して [許可] または [ブロック] を指定する事ができます。
またこの方法で手動で設定した許可 / ブロックの設定は、[自動的にブロックする] の設定より優先します。つまり下図のように特定のコンテンツのみ手動で許可し、それ以外のコンテンツは自動的にブロックするよう構成する事が可能です。

image

これらの機能で、Web ページ内のコンテンツがブロックされて非表示になった場合、アドレスバーに image ボタンが表示されます。このボタンをクリックするとその Web サイトに対してのみ追跡防止を無効にすることができます。

なお個人用追跡防止リストの履歴データや設定は、[インターネット オプション] – [全般] タブ の [閲覧の履歴] セクションの [削除] から削除できます。

image

2013年12月22日

Internet Explorer のプロキシ設定覚書

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 11:01 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 22 日目です。


Internet Explorer でのプロキシ設定についての覚書です。

Internet Explorer のプロキシ設定は「システム プロキシ設定」

Internet Explorer の Web アクセス機能は、Windows のシステム モジュールでもある wininet.dll が担っており、プロキシの設定もこの wininet.dll の動作に対する設定となり、「システム プロキシ」と呼ばれます。そしてこの wininet.dll の機能は WIN32 API の WinInet API として公開されています。そのためこの AIP を利用するアプリケーションは Internet Explorer のプロキシ設定と同じプロキシ設定を利用する事になります。
また Web アクセスに WinInet API を利用しないアプリケーションでも、WinInet の設定を読み取って同じ設定を利用できるようになっている事があります。

プロキシ設定は「インターネット オプション」から

Internet Explorer のプロキシ設定は「インターネット オプション」から行います。[接続] タブで [LAN の設定] をクリックすると、設定画面が表示されます。
自動構成を行う場合は [設定を自動的に検出する] (WPAD を利用する場合) または [自動構成スクリプトを使用する] (自動構成スクリプト ファイル、.pac ファイルの URL を指定する場合) の何れかにチェックを入れます。手動構成の場合は [LAN にプロキシ サーバーを使用する] にチェックを入れ、プロキシ サーバーのアドレスとポートを入力します。プロトコルごとに異なるプロキシ サーバーを利用するなどの設定をする場合は、[詳細設定] をクリックして画面を開きます。

なおプロキシが無いネットワークを利用する場合、自動構成のチェックを外すと (WPAD の検出などの動作が省略されるため) Internet Explorer を起動してページが表示されるまでの時間が少し短縮できます。

image

※ 上記ダイアログで [詳細設定] をクリックするとこの画面が開きます
image

手動構成と自動構成は排他では無い

ダイアログボックスにも書かれている通り、自動構成と手動構成は排他的ではなく、両方を指定する事が可能です。両方を有効にした場合は、手動構成の設定が自動構成の設定で上書きされます。動作が分かりにくくなるため、両方ともに指定するのは止めた方が良いでしょう。

自動検出の仕組み

自動構成で [設定を自動的に検出する] を有効にした場合、Internet Explorer はWPAD (Web プロキシ自動発見) に基づいて自動構成スクリプト ファイルを検出し、利用します。WPAD は以下のような方法で機能します

  1. Internet Explorer は起動後最初に Web アクセスする際、利用しているネットワーク接続が DHCP を利用しているか確認します
  2. ネットワーク接続が DHCP を利用している場合、DHCP サーバーに DHCPINFORM メッセージを送信し、自動構成スクリプトのアドレスを要求します
  3. DHCP サーバーがオプション 252 で自動構成スクリプトの URL を返信すると、Internet Explorer はその URL にアクセスして自動構成スクリプト ファイルを取得します
  4. Internet Explorer はファイルが取得でき、そのファイルが自動構成スクリプトとして有効であれば、その内容に基づいてプロキシを構成します
  5. DHCP サーバーが利用できない場合、あるいは DHCP サーバーが DHCPINFORM メッセージをサポートしていない、オプション 252 を構成していないなどの理由で自動構成スクリプト ファイルの URL を返さない場合、Internet Explorer は “WPAD” というホスト名を DNS サーバーに問い合わせます
    ※ 実際には「WPAD というホスト名 + 利用しているネットワーク接続の DNS サフィックスのドメイン名」が問い合わせされます
  6. WAPD というホスト名が名前解決できると、そのホストのルートにある “wpad.dat” という名前のファイルを HTTP プロトコルでリクエストします
    ※ 例えばクライアントの FQDN が pc.hebikuzure.lochal であれば、http://wpad.hebikuzure.lochal/wpad.dat がリクエストされます
  7. “wpad.dat” ファイルが取得でき、そのファイルが自動構成スクリプトとして有効であれば、その内容に基づいてプロキシを構成します

参考 : 自動検出 (http://technet.microsoft.com/ja-jp/library/gg699445.aspx)

なお、他のブラウザーの自動検出の動作はこれと異なる場合があるため、クロス ブラウザーで自動構成を行うためには、以下のような設定をしておくことが良いようです。

  1. Web サーバーで “http://wpad.(ドメイン名)/” というサイト (ドメイン名はそのネットワークのドメイン名) を作成しておき、そのルートに同じ内容の “wapd.dat” と “proxy.pac” という二つの自動構成スクリプトファイルを配置する
    ※ ブラウザーによって優先して取得するファイル名が異なるためです
  2. DNS で “wpad.(ドメイン名)” が正しく名前解決できるよう構成する
  3. DHCP を利用していて DHCP サーバーが DHCPINFORM をサポートしている場合は、オプション 252 で自動構成スクリプトの URL として上記の “http://wpad.(ドメイン名)/proxy.pac” を設定する

自動検出、自動構成は標準化されていない

上記でブラウザーによって動作が異なる事を説明しているように、プロキシ自動構成と自動検出の方法は標準化された仕様がありません。そのためブラウザーやサーバーが準拠すべき明確な規格はありません。

WPAD についてははるか昔に「Web Proxy Auto-Discovery Protocol」というドラフトが IETF に提案されていたのですが、そのまま標準化される事なく現在に至っています。また自動構成スクリプト ファイルの書式も標準化されていません。

自動構成スクリプトの書式

自動構成スクリプトは JavaScript の文法で記述する事になっていますが、この書式は元々 Netscape Navigator で利用されていた物が現在でもそのまま使われています。以前は Netscape 社の Web サイトにリファレンスがあったのですが、現在はページが無くなっているのでアーカイブを見るか、“FindProxyForURL” の Web サイトにあるリファレンス、The Practical Proxy PAC File Guide にあるリファレンスなどが参考になると思います。

また IE6 リソースキットの記事「Chapter 26 – Using Automatic Configuration, Automatic Proxy, and Automatic Detection」や Internet Explorer 8 展開ガイドの「付録 B : 自動プロキシ構成スクリプトの例」も参考になると思います。

2013年12月21日

HTML5 と JavaScript で作る Apps for Office

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 10:03 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 21 日目です。


今日は「Apps for Office サミット」という勉強会に参加してきました。その復習を兼ねて、Apps for Office についてまとめてみたいと思います。

Apps for Office (日本語だと Office 用アプリ) は Microsoft Office 2013 から加わった、新しい Office アプリケーションの自動化の仕組みです。Microsoft Word や Excel などの Office アプリケーションの自動化 (オートメーション) の方法としては、古くから利用されている VBA (Visual Basic for Application) や、Office 2003 以降で利用可能な VSTO (Visual Studio Tools for Office) がありましたが、Apps for Office はそれに追加される機能です。

Microsoft は Apps for Office は VBA や VSTO と競合する機能ではなく補完的な機能であるため、将来的にも VBA や VSTO にゆるソリューションをサポートしていく事を表明しています

タイトルにも書かれていますが、Apps for Office は HTML5 とJavaScript で作成します。と言うより、HTML5 + CSS3 + JavaScript で構成されるモダンな Web アプリケーションが Office アプリケーションの中でホストされ、Office アプリケーションのデータと連携できるようになっていると言っても良いでしょう。実際に Office アプリケーション内で動作している Apps for Office の画面は Web ページです。

以下に VBA、VSTO、Apps for Office を簡単に比較してみました。

 

開発言語

目的

備考

VBA Visual Basic 6.0 風専用言語 ユーザーのアドホックな作業オートメーション Office アプリケーションに
組み込み
VSTO Visual Basic .NET / C# UI のカスタマイズ
Office アプリケーションの機能拡張とオートメーション
.NET Framework
アセンブリとして作成
Apps for Office HTML5 + JavaScript Office アプリケーションの軽量な機能拡張 Web アプリケーション
として作成

より詳しい比較表がこちらの記事中にあります

Apps for Office は XML ファイルとして記述されたアプリ マニフェストと、Web サーバーでホストされる Web ページから成り立っています。

Office 用アプリはマニフェストと Web ページによって構成
(http://msdn.microsoft.com/JA-JP/library/jj220082.aspx から引用)

アプリ マニフェストにはそのアプリの実体となる Web アプリケーションの URL の他、利用可能な Office アプリケーションの種類 (Word 用とか Wxcel 用とかの指定)、アプリに許可される権限などを記述します。ユーザーがこのマニフェストをドキュメントに挿入することで Apps for Office がインストールされ利用可能になります。アプリ マニフェストは Microsoft が運営している Office ストアに登録して公開する他、組織内で独自のアプリ カタログを (Sharepoint やファイル共有により) 公開することもできます。そのため一般向けのアプリとして広く公開する (場合によってはストアの機能を利用して課金する) 事、企業内で独自のアプリを展開する事、どちらも可能です。

Office アプリケーションはアプリ マニフェストがドキュメントに挿入されると、その内容を確認して Web アプリケーションの URL にリクエストを行います。取得された Web アプリケーションは、HTML と JavaScript (と CSS) が Internet Explorer のレンダリング エンジン (Trident) と JavaScript エンジン (Chakra) によってレンダリング / 実行されて動作されます。もちろん Trident や Chakra は Office アプリケーションが作成するサンド ボックス内で実行され、他のアプリケーションや他の Internet Explorer のインスタンスとは分離されます。

Web アプリケーションとして動作する際の機能とパフォーマンスを確保するため、 Apps for Office の利用には Internet Explorer 9 以上が必要です。Windows 7 に Office 2013 をインストールする場合、標準の Internet Explorer 8 ではなく、Internet Explorer 9 以上にアップグレードする必要があります。
また同じ Windows 7 でもインストールされている Internet Explorer のバージョンにより、Apps for Office で利用可能な HTML / CSS / JavaScript の機能に違いが生じます。

このような仕組みで動作するため、Apps for Office では Internet Explorer で利用可能な Web 標準の HTML5 や JavaScript の機能を基本的にすべて利用する事ができます。もちろん jQuery などのライブラリを利用する事も可能です。そのため既存の Web アプリケーションを Apps for Office に再構成する事も難しくありません。

(明日以降続きを追加します)

2013年12月20日

IE10 以降では「Internet Explorer のメンテナンス」が廃止されている

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 11:17 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 20 日目です。


企業内、組織内で利用している Internet Explorer の設定を統一したい場合があります。一番よくあるのがネットワークの設定でプロキシ設定を統一したい、というかプロキシ必須のネットワーク下であれば統一して管理者が設定しておかないと Web に接続できないユーザー続出という事になりますね。それ以外にも利用している Web アプリケーション / ネットワーク アプリケーションの都合で詳細設定やセキュリティ設定を特定に統一する必要がある場合も多いでしょう。

こうした設定の統一にはいくつかの方法が利用できます。Internet Explorer 6 以降で利用可能であった仕組みを示すと以下のようなものがあります。

  • IEAK (Internet Explorer 管理者キット)
  • グループ ポリシーの「Internet Explorer のメンテナンス」(Active Directory のグループ ポリシー / ローカル ポリシー共に利用可能)
  • グループ ポリシーの「管理用テンプレート」(Active Directory のグループ ポリシー / ローカル ポリシー共に利用可能)
  • グループ ポリシーの「基本設定」(Active Directory のグループ ポリシーでのみ利用可能)

この内、グループ ポリシーの「管理用テンプレート」の Internet Explorer に関する機能は Windows Vista (Internet Explorer 7) 以降で搭載され拡充されてきた機能、グループ ポリシーの「基本設定」は Windows Server 2008 以降で搭載された機能のため、Internet Explorer 6 を含む環境では引き続き IEAK やグループ ポリシーの「Internet Explorer のメンテナンス」を使って管理する場合が多いのではないかと思います。

しかし Internet Explorer 10 以降のバージョンでは、グループ ポリシーの「Internet Explorer のメンテナンス」が利用できなくなっています。そもそも Internet Explorer 10 をインストールするとグループ ポリシー エディターから「Internet Explorer のメンテナンス」の項目が削除されます。また Windows クライアントが参加している Active Directory のグループ ポリシーに「Internet Explorer のメンテナンス」が含まれていても、Internet Explorer はその構成には設定されません。
またグループ ポリシーの「基本設定」にも Internet Explorer 10 以降のバージョンは対応しません*。ここで設定しても、クライアントの Internet Explorer は構成されません。

Windows 7 + Internet Explorer 9 のグループ ポリシー エディター
Windows 7 + Internet Explorer 9 のグループ ポリシー エディター

Windows 7 + Internet Explorer 10 のグループ ポリシー エディター
Windows 7 + Internet Explorer 10 のグループ ポリシー エディター

* : グループ ポリシーの基本設定の使用 (http://technet.microsoft.com/ja-jp/library/jj822320.aspx) に「グループ ポリシーの基本設定を使用して、Internet Explorer 10 の設定を構成することはできません。」との記載があります。
グループ ポリシーの基本設定を使用して、Internet Explorer 10 の設定を構成することはできません

従って、現在「Internet Explorer のメンテナンス」を利用して Internet Explorer を管理している企業や組織では、今後の Internet Explorer 10 以降への移行に伴い、管理方法を変更する必要があります。

「Internet Explorer のメンテナンス」で利用できた設定のほとんどは IEAK で代替できますが、Internet Explorer 10 以降では一部設定できなくなっている項目もあるので注意が必要です。また IEAK の場合はカスタム インストール パッケージを作成してクライアントに配布・インストールする必要があり、クライアントへの配布・インストール自体は Active Directory のグループ ポリシーを利用して可能とは言え、手間が増えます。項目によっては管理用テンプレートで設定した方が簡単なものもあるため、必要な設定とその実現方法については十分に検討する必要があるでしょう。

Internet Explorer 10 以降設定できなくなっている項目は以下のようなものです

  • ブラウザーのツール バーの背景のカスタマイズ
  • カスタム ロゴと動画ビットマップ (IE のロゴのカスタマイズ)
  • Authenticode の設定

「Internet Explorer のメンテナンス」の代替手段については「Internet Explorer のメンテナンスの代替機能 (http://technet.microsoft.com/ja-jp/library/jj890998.aspx)」のページに詳しく解説されています。また管理用テンプレートで設定できる Internet Explorer の構成については「Group Policy Settings Reference for Windows and Windows Server (http://www.microsoft.com/en-us/download/details.aspx?id=25250)」からダウンロードできる資料が参考になります (Excel ブックなので、Administrative Templates シートを File Name 列の inetres.admx でフィルタしてください)。

IEAK については、「Internet Explorer Administration Kit (IEAK) Information and Downloads (http://technet.microsoft.com/en-us/ie/bb219517)」のページから必要なバージョンの IEAK をダウンロード / インストールして利用します。ただしインストールする IEAK のバージョンと同じバージョンの Internet Explorer が Windows にインストールされている必要があります。そのため複数のバージョンの Internet Explroer を IEAK を利用して管理する場合は、そのバージョンの数だけ IEAK をインストールする環境が必要になります (現実的には仮想マシンを利用すると良いでしょう)。

IEAK の利用方法や設定方法については、別途このブログでまとめたいと思います。

2013年12月19日

ユーザー設定互換表示リストが消える

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 11:31 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 19 日目です。


Internet Explorer の互換表示リストの機能についてはこちらの記事でも紹介しましたが、Microsoft が提供する互換表示リスト (CV リスト) だけでなく、「ユーザーがユーザーごとの互換表示リストに登録する」方法でも互換表示の設定をする事ができます。
この機能について、某 NDA なメーリング リストでユーザーが登録した互換サイトのリストが突然消えてしまったという話題が盛り上がっていましたので、これについて簡単に解説します。

IE8 ~ 10 ではこちらの手順で、IE11 ではこちらの手順でユーザー自身が登録した互換リストは、登録と逆の操作で削除できる他、閲覧の履歴を削除した際にも削除されます。この事があまり知られていなかったようで、そういえばこのブログでも紹介したことがなかったなあと思った次第です。
この動作については We know IE! ブログの 2009年5月23日の記事「Understanding Compatibility Modes in Internet Explorer 8」に書かれています。その部分を引用すると

Web sites that are late in adopting to IE 8 Standards need a way to be easily removed from user’s Compatibility View Lists. IE 8 has several ways in which a site can be removed from this list:

  1. Deselecting the “Emulate IE7” button
  2. Directly editing the compatibility list
  3. Deleting the browsing history
  4. Overriding from the site

となっています。という訳でインターネット オプションなどから閲覧の履歴を削除すると、ユーザー登録の互換表示リストが削除されるのは、IE8 から IE11 まで共通の既定の動作です。

2013年12月18日

Internet Explorer のライフサイクル

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 8:32 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 18 日目です。


Microsoft の製品には「サポート ライフサイクル」が定められています。これは製品の出荷時点からどれだけの期間、どのようなサポートが提供されるのかを示した物で、あらかじめ定められたポリシーに従ってそれぞれの製品のサポート ライフサイクルが決められます。

ビジネス製品、開発製品、およびマルチメディア製品の場合、ライフサイクルは提供されるサポートの種類によって、製品出荷から 5 年間の「メインストリーム サポート」と、その後の 5 年間の「延長サポート」に大別されます。それぞれで提供されるサポートは以下の通りです。

サポートの種類

メインストリーム サポート

延長サポート

仕様変更/新機能のリクエスト

×

セキュリティ更新プログラムの提供

セキュリティ以外の修正プログラム (バグ修正) のリクエスト

無償サポート

×

有償サポート

| 〇 : 提供されます | × : 提供されません | △ : 事前に特別なサポート契約が必要 |

延長サポートが終了すると、セキュリティ修正プログラムの提供も終了します。ただし最短でも 1 年間は以前に提供されている修正プログラムやサービスパックのダウンロードは引き続き可能で、またサポート技術情報、オンライン製品情報、オンライン サポートなど、オンライン コンテンツを参照することも可能です。

Internet Explorer は Windows のコンポーネント (一部分) として提供されるため、Internet Explorer のサポート ライフサイクルはそれがインストールされている Windows のライフサイクルに準じます。Windows 製品は「ビジネス製品」の位置づけのため、5 年間の「メインストリーム サポート」と 5 年間の「延長サポート」が利用できます。

正確には、メインストリーム サポートは製品発売後 5 年間または次期製品 (N+1) の発売後 2 年間のどちらか長い方の期間提供されます。メインストリーム サポート終了後 5 年間または次々期製品 (N+2) の発売後 2 年間のどちらか長い方の期間延長サポートが提供されます。

現在利用可能な Internet Explorer のサポート ライフサイクルは以下の通りです。

製品名

サポート開始日

メインストリーム終了日

延長サポート終了日

Microsoft Internet Explorer 6.0 2001/12/31 2009/04/14 2014/04/08
Windows Internet Explorer 7 2006/10/18 2009/04/14 *1
2012/04/10 *2
2014/04/08 *1
2017/04/11 *2
Windows Internet Explorer 8 2009/06/17 ————— *1
2012/04/10 *2
2015/01/13 *3
2014/04/08 *1
2017/04/11 *2
2020/01/14 *3
Windows Internet Explorer 9 2011/03/15 2012/04/10 *2
2015/01/13 *3
2017/04/11 *2
2020/01/14 *3
Windows Internet Explorer 10 2012/10/30 2015/01/13 *3
————— *4
2020/01/14 *3
————— *4
Internet Explorer 11 2013/11/13 2015/01/13 *3
————— *4
2020/01/14 *3
————— *4

*1 : Windows XP にインストールされている場合
*2 : Windows Vista にインストールされている場合
*3 : Windows 7 にインストールされている場合
*4 : Windows 8 / 8.1 にインストールされている場合は下記参照

このように同じバージョンの Internet Explorer でもインストールされている Windows のバージョンによってサポート期間が異なるので注意が必要です。

さらに注意が必要なのは、Windows 8 / 8.1 の場合です。Windows 8 には Internet Explorer 10 が、Windows 8.1 には Internet Explorer 11 が含まれていますが、Windows 8.1 は Windows 8 に対する Service Pack と同等の扱い のため、サービス パック ポリシーが適用されます。サービス パック ポリシーは以下のような内容です。

  • サービス パックがリリースされる際、その 1 つ前にリリースされたサービス パックは、製品ファミリー (たとえば、Windows、Office、サーバーまたは開発者ツール) によって異なりますが、12 か月間、または 24 か月間サポートが提供されます。
  • サービス パックのサポートが終了した場合は、そのサービス パックに対する新たなセキュリティ アップデート、修正プログラム、およびその他の更新は提供されません。

Windows 製品での一つ前のサービスパックに対するサポート提供期間は 24 か月なので、Windows 8 のを利用している場合は、引き続きサポートを受けるために Windows 8.1 更新プログラムの一般公開後 24 か月以内に Windows 8.1 に移行する必要があります。したがって Windows 8 上の Internet Explorer 10 のサポートも、2015年11月には終了します。 つまり Windows 7 上の Internet Explorer 10 よりも Windows 8 上の Internet Explorer 10 の方が先にサポートが終了してしまうのです。
また Windows 8.1 上の Internet Explorer 11 についても、今後 Windows 8.1 の後継となる更新プログラムが提供され、それにより新しいバージョンの Internet Explorer が含まれていれば、同様に更新プログラムの提供から 24 か月でサポートが終了します。

このように Internet Explorer のサポート ライフサイクルは少し変則的になっており、やや分かりにくくなっているので、長期間に渡って利用するシステム動作要件を決める際には注意が必要です。

参考
マイクロソフト サポート ライフサイクル (http://support.microsoft.com/lifecycle/)
Windows 8.1 サポート ライフサイクル ポリシー FAQ (http://support.microsoft.com/gp/lifecycle-Windows81-faq)

2013年12月17日

IE11 の正式名称

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 8:59 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 17 日目です。


今更気づいた事なのですが、Internet Explorer 11 は、正式な製品名称が「Internet Explorer 11」になっているようです。

え、何を言っているのかわからない、という人のために解説すると、IE7 以降、Internet Explorer の正式名称は「Windows Internet Explorer」でした。

IE6 以前の正式名称は「Microsoft Internet Explorer」でした。

そのため例えば Microsoft の Web サイトでも以下のように「Windows Internet Explorer 〇」という表記がされていました。

Windows Internet Explorer 7 という表示

Windows Internet Explorer 8 という表示

またバージョン情報にも「Windows Internet Explorer」という表示があります。

Windows Internet Explorer 9 のバージョン情報

ただし Internet Explorer 10 ではバージョン情報から「Windows」という表記が無くなっていました。

Windows Internet Explorer 10 のバージョン情報

とは言えサポート技術情報やサポートライフサイクルでの製品名表記は「Windows Internet Explorer」のままでしたので、正式名称自体は変更されていなかったと考えられます。

サポート技術情報の表記

ところが IE11 のリリース後にサポート技術情報やサポートライフサイクルでの製品名表記を確認すると、IE11のみ「Internet Explorer 11」と “Windows” 抜きの表記になっています。

サポート技術情報の表記

もちろんバージョン情報も “Windows” 抜きの表記になっています。

Internet Explorer 11 のバージョン情報

以上から、Internet Explorer 11 から製品の正式名称が “Windows” 抜きの「Internet Explorer」に戻っていると考えられます。IE のブラウザーがX-box でも提供されるようになったので、Internet Explorer = Windows という訳に行かなくなったから…なのでしょうか?

2013年12月16日

IE12 大予想

Filed under: Yet Another Internet Explorer Advent Calendar 2013 — hebikuzure @ 11:03 午後

この記事は “Yet Another Internet Explorer Advent Calendar 2013” の 16 日目です。


本日開催された HTML5 とか勉強会で「IE12 大予想 – きっとこうなる Internet Explorer 12」というタイトルでライトニング トークをさせていただきました。
そのスライドを公開しますので、ご覧下さい。

なお内容についてはあくまでも個人的な予測であり、結果を保証するものではありません。

Older Posts »

WordPress.com Blog.