Hebikuzure's Tech Memo

2011年6月30日

Internet Explorer 10 Platform Preview 2

Filed under: Internet Explorer — hebikuzure @ 5:51 AM


Internet Explorer Test Drive
http://ie.microsoft.com/testdrive/


本日早朝に Internet Explorer 10 Platform Preview 2 がリリースされました。 Internet Explorer 10 Platform Preview 1 の公開が 4/13 で、12週ごとに更新すると予定とアナウンスされていましたから、予定よりちょっとだけ早い公開となったようです。
Platform Preview 2  では以下のようにバージョンが 10.0.1008.16421 になります。

image 

Internet Explorer Platform Preview Guide for Developers に Platform Preview 2 での Update が以下のように記載されています。

  • Positioned Floats
  • CSS3 Gradients (on all image types)
  • CSS stylesheet limit lifted
  • CSSOM Floating Point Value support
  • Improved hit testing APIs
  • Media Query Listeners
  • HTML5: Support for async attribute on script elements
  • HTML5 Drag and Drop
  • HTML5 File API
  • HTML5 Sandbox
  • HTML5 Web Workers
  • Web Performance APIs:
    • requestAnimationFrame
    • Page Visibility API
    • setImmediate

この中での目玉は File API のサポートでしょう。他のモダン ブラウザーでの実装が進んでいましたが、IE でも HTML5 Labs を卒業してIE 本体に実装されました。また CSS3 FloatHTML5 Drag-dropMedia Query Listener、さらに Web Worker も実装され、HTML5 Forms についても一部の実装が開始されています。
またセキュリティ面では HTML5 Sandbox と iframe の分離が含まれており、Web アプリケーションの脆弱性に対するユーザーの安全確保が図られています。それ以外にも全般的なパフォーマンスの向上、performance API の強化など、IE10 のリリースに向けた性能向上と標準仕様の実現が進められています。

Internet Explorer 10 Platform Preview 2 は http://www.ietestdrive.com/ からダウンロードでき、Windows 7 に以前のバージョンの Internet Explorer (IE8 / IE9) と共存してインストールできます。また http://www.ietestdrive.com/ には Platform Preview 2 の新機能を含む IE10 の機能とパフォーマンスが確認できる多数のデモ ページが用意されています。 さらに開発者向けの詳細な情報は Internet Explorer Platform Preview Guide for Developers で参照できます。

2011年6月28日

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

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

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年6月26日

古い記事をメンテナンスしました

Filed under: Information — hebikuzure @ 9:30 PM

元々このブログは今は亡き Windows Live Space を使っていたのですが、Wordpress に移行する以前の記事を WordPress にインポートする際、一部のコンテンツで画像へのリンクが Windows Live Sky Drive 内の画像のままになっていたり、特定の文字 (“\” など) が欠落してしまったりしていました。その辺りをチェックしてメンテナンスしています。

もし古い記事でリンク切れや画像が表示されないなどの問題がありましたら、この記事にコメントしていただくか、Twitter で @hebikuzure につぶやいていただくか、hebikuzure.com に記載しているメール アドレス宛ご連絡ください。

2011年6月24日

Windows 7 では共有フォルダのアイコンが変化しない

Filed under: Windows Tips — hebikuzure @ 7:46 PM

The shared type icons do not appear when you use Windows Explorer to view the sharing status of some shared folders in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2291175/en-us


以前からなんとなく気になっていた事なのですが、Windows 7 や Windows Server 2008 R2 で共有フォルダーを作成した場合、エクスプローラーで表示されるフォルダのアイコンが変化しません。Windows XP や Windows Server 2003 では手のひらのようなマーク、Windows Vista や Windows Server  2008 では下のような人のマークがアイコンについていたのですが、

image

Windows 7 と Windows Server 2008 R2 ではこちらのようにアイコンは変化しません。

image

その代り、エクスプローラーの下部の詳細ウィンドウに以下のように共有フォルダーである事が示されます。

image

この変更について “Shared folders in Windows Explorer” という TechNet の記事に書かれている事を最近になって気づきました。さらにこれではいちいち詳細ウィンドウを見なければならず、詳細ウィンドウを非表示にすると確認できなくなってしまうため不評だったようで、Service Pack 1 で修正が入っています。
これについて説明したのが上掲のサポート技術情報です。

Windows 7 や Windows Server 2008 R2 に Service Pack 1 をインストールすると、エクスプローラーを詳細表示にした際の列見出しに以下の項目を表示する事ができるようになります。

  • 共有
  • 共有ユーザー
  • 共有状態

手順は以下の通りです。

  1. まず列見出しの部分で右クリックし、[その他] をクリックします
    image
  2. 設定画面で必要な項目にチェックを入れます
    image
  3. [OK] をクリックすると、項目として表示されます (共有ユーザー欄ののユーザー名は消しています)
    image
  4. 項目を非表示にする場合は、同じ手順でチェックを外します

どのような共有状態の場合にどのような表示になるのかについては技術情報 2291175 に詳しく書かれていますが、共有フォルダーがユーザー プロファイルの中にあるのか外にあるのかによって動作が異なるので注意が必要です。

2011年6月23日

MS11-043 (KB2536276) をインストールすると、Samba サーバーに接続できなくなる

Filed under: Windows トラブル — hebikuzure @ 10:36 PM

MS11-043: Vulnerability in SMB Client could allow remote code execution: June 14, 2011
http://support.microsoft.com/kb/2536276/en-us


今月のセキュリティー更新プログラムとして公開されたSMB クライアントの脆弱性に関する修正プログラムをインストール後、一部の Samba サーバー (Linux ベースのサーバーや、NAS) のネットワーク共有にアクセスできなくなる現象が発生する場合があります。この問題はクライアントとサーバーが平文のパスワードを利用するように構成されている場合に発生します。(Bug 8238 -Windows security patch KB2536276 prevents access to shares)
この現象とその回避策はサポート技術情報 2536276 に記載されていますので、もし修正プログラムのインストール以降 Samba ベースのネットワーク共有にアクセスできなくなった場合、以下の回避策を試してみましょう。

回避策
Samba サーバー側

構成ファイル (通常は smb.conf) に

Encrypt passwords=Yes

を追加する

クライアント側

以下のレジストリ値を構成する (レジストリ値が存在していれば下記のデータに修正し、もし存在していなければ作成する)

キー : HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\LanmanWorkstation\Parameters
名前 : EnablePlainTextPassword
種類 : REG_DWORD
データ : 0

構成後、コンピュータを再起動する

さらにドメイン名またはワークグループ名が UNICODE で 3 文字未満の場合に問題が発生するので、最低でも 3 文字以上の名前とする

2011年6月20日

IE9 の固定サイト(Pinned Site) にホームページを追加する

Filed under: Internet Explorer — hebikuzure @ 8:11 PM

Internet Explorer 9 では Web サイトへのリンクとして、従来からのショートカット (拡張子 .url) に加えて固定サイト(拡張子 .website) が利用できます。固定サイトは Windows 7 でのタスクバーへのサイト アイコンの表示にも使われていますが、デスクトップに作成する事もできます。
(固定サイトの機能については色々と情報が公開されているのでそちらも参照してください)

従来のショートカットと固定サイトの IE9 でのその機能について簡単にまとめると

  • ショートカット
    • 作成方法
      • アドレス バーのファビコンを Shift キーを押しながらデスクトップなどにドラッグ&ドロップ
      • [ファイル] メニュー – [送信] – [ショートカットをデスクトップへ]
    • 機能
      • ダブルクリックなどで開くと、現在開かれている IE9 内に新しいタブとしてサイトが表示される
        (IE9 が起動していない場合は、IE9 が起動して通常のタブとして表示される)
  • 固定サイト
    • 作成方法
      • アドレス バーのファビコンをデスクトップなどにドラッグ&ドロップ (タスクバーにドロップするとタスクバーに常に表示される)
      • タブをタスクバーにドラッグ&ドロップ (タスクバーに常に表示される)
    • 機能
      • ダブルクリックなどで開くと、現在開かれている IE9 とは別に固定サイトのモードの IE9 ウィンドウが開き、その中のタブとして表示される

という事になります。

さて、上記のような方法で固定サイトを作成した場合、当然その固定サイト アイコンからは作成した時に表示していた一つの Web サイトだけが開かれます。ところがある方法を使うと固定サイト アイコンから複数の Web サイトを同時に開く事ができます。その方法は以下の通りです。

  1. 開きたい Web サイトのうち一つの固定サイト アイコンを上記の方法で作成する
  2. 1. で作成した固定サイト アイコンを開き、固定サイト モードの IE9 を開く
  3. 2. で開いた IE9 でツール ボタンをクリックし、[インターネット オプション] をクリックする
  4. [全般] タブの [ホームページ] 欄に、追加で表示したい Web サイトの URL を入力して (複数可) 、[OK] をクリックする

この手順により、次回から最初に登録したサイトとともに、ホームページに追加したサイトも一緒に表示されるようになります。
※ 20011/6/24 追記 : この他、2. で開いた固定サイト モードの IE9 に新しいタブとして追加したいページを表示し、固定サイトを作ったページ (元のページ) のタブを閉じてから 3. のように [インターネット オプション] を開き、[現在のページを使用] ボタンでホームページを追加しても良い。この場合、固定サイトとして登録した最初のページのタブは閉じておくのがミソ。
※ ただし固定サイトをタスク バーやスタート メニューに表示した際の機能であるジャンプ リストについては、最初に固定したサイトのみ有効で、ホームページとして追加したサイトのジャンプ リストなどは有効になりません。

この方法を使えば、一つにまとめておきたい情報がある複数のサイトを、一度に一つのアイコンから開く事ができるので、便利でしょう。
例えば複数の辞書サイトや翻訳サイトをこの方法で一つのアイコンから開けるようにしておけば、色々なサイトでの検索結果を比較する際に便利です。また関連のある情報 (例えばお店の Web サイトとそのお店に関する複数の口コミサイトのページなど) を一つのアイコンにまとめる事もできます。


なお、この方法は次のような IE9 の動作によって実現できています。
通常 IE のホームページの設定はユーザーごとの設定としてレジストリに書き込まれるのですが、固定サイトとして開かれた IE9 内で追加したホームページはレジストリではなく固定サイト ファイル (.website ファイル) に記録されます。そのため固定サイトでホームページを追加すれば、他の固定サイトや通常の IE9 に影響を与えることなく、その固定サイトでだけホームページを増やす事ができるのです。

2011年6月18日

IE9 で正しく表示されないページを報告する

Filed under: Internet Explorer — hebikuzure @ 6:14 PM

IE9 Site Compatibility Feedback
http://mymfe.microsoft.com/Internet%20%20Explorer/Feedback.aspx?formID=647


今まで知らなかったのですが、表題のように Internet Explorer 9 で正しく表示できないページを Microsoft にフィードバックするページが用意されていました。

IE9 Site Compatibility Feedback
http://mymfe.microsoft.com/Internet%20%20Explorer/Feedback.aspx?formID=647

ただし英語版しかない (見つからない) ので、フィードバックも英語で書き込む必要があるようです。最も正しく表示できない URL はアドレス バーからのコピー&ペーストで記入できますから、あとは例のように “menu’s aren’t working” (メニューが機能しない) とか “page layout is not as expected” (レイアウトが崩れる) とか “forms disappear” (フォームが表示されない) とか、”XXX button doesn’t work” (xxx ボタンが機能しない) とか書けばよいでしょう (http://www.excite.co.jp/world/english/http://www.microsofttranslator.com/Default.aspx みたいな翻訳サイトを使ってもよいですね) 。

フィードバックされた問題は Internet Explorer 9 側の問題なのかサイト側の問題なのか調査され、サイト側の問題の場合は可能な範囲でサイト運営者にマイクロソフトから働きかけるようです。

2011年6月16日

Internet Explorer 9 日本語版の自動更新での配布は 6/21 開始

Filed under: Internet Explorer — hebikuzure @ 11:03 PM


Internet Explorer 9 の自動更新による配布
http://technet.microsoft.com/ja-jp/ie/gg615599


World Wide では 3/15 に公開された IE9 ですが、日本語版は震災の影響を緩和するため 4/25 に延期されましたが、同様に IE9 の自動更新での配布も日本以外では 4/19 から開始されているのですが、日本では延期されていました。その自動更新での配布がいよいよ 6/21 (火) から開始されます。IE9 が自動更新で提供され、インストールされる事が (互換性などの問題で) 好ましくない場合、いくつかの方法でインストールされないように設定する事ができます。これについては「Internet Explorer 9 の自動更新による配布」という資料に詳細が記述されています。

IE9 の自動更新でのインストールを防ぐ方法として、上記の記事では以下の三つの方法が提示されています。

  1. Internet Explorer 9 Blocker Toolkit をダウンロードして展開する
  2. 更新プログラム管理ソリューション (WSUSMicrosoft System Center Configuration ManagerSystems Management Server 2003) を展開する
  3. 更新プログラムをインストールできることが自動更新から通知されたときに、Internet Explorer 9 のインストールを拒否するよう、ユーザーに指示する

「3.」が一番簡単なのですが、ユーザーが誤って IE9 をインストールしてしまう可能性もあります。ローコストである程度確実なのは「1.」の方法でしょう。
Internet Explorer 9 Blocker Toolkithttp://www.microsoft.com/downloads/en/details.aspx?FamilyID=a6169467-b793-4d17-837d-01776bf2bea4&displaylang=en からダウンロードできます。

2011年6月9日

IE9 のウィンドウ内に Office ドキュメントを表示する

Filed under: Internet Explorer — hebikuzure @ 4:27 PM

IE9 でダウンロードの際に通知バーではなくダイアログが表示される場合がある」の記事中で

現在のバージョンでは既定で無効なのですが、Web サイト上の Office の文書を Internet Explorer のウィンドウ内に表示される事ができる

と書いたので、IE9 でもこの動作ができるのか確認してみました。この動作については以下のサポート技術情報に解説されています。

簡単にまとめると、Office のドキュメントを IE から開く際、IE とは別のウィンドウで Office アプリケーションを起動して開くか、IE のウィンドウ内に開くかの制御はレジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Classes キー内の各ドキュメント種類ごとのサブ キーにある BrowserFlags 値で行われています。

そこで Interent Explorer 9 がインストールされているクライアントに上記技術情報 982995 で示されているレジストリ値を設定して、その上でテスト ページから Office ドキュメントのダウンロードを行ってみました。

  1. test.doc Content-Disposition:attachment なし” をクリックしてダウンロードを開始
  2. IE9 でダウンロードの際に通知バーではなくダイアログが表示される場合がある」に書いたようにモーダルなダウンロード ダイアログが表示される
    image
  3. [開く] をクリックすると、ダウンロード中の経過が通知バーで表示された後、以下のように IE のウィンドウ内で Word 文書が開く (クリックすると拡大表示)
    image

このように IE9 + Office 2010 の環境でも Office ドキュメントを IE のウィンドウ内に表示する事ができました。

ただしこのようにレジストリ値を構成しても IE のウィンドウ内で開く事ができるのは、content-disposition: attachment ヘッダーがついていない場合のみです。content-disposition: attachment ヘッダーは云わば「ダウンロードを強制する」指示なので、通知バーで [開く] を選択した場合でもインターネット一時ファイル フォルダへのダウンロードが優先され、その後一時ファイルにダウンロードされたドキュメントが (普通のローカルのファイルと同様に) 開かれる動作となります。そのため content-disposition: attachment ヘッダーがついている場合は、上記のレジストリ設定に関わらず IE とは別に Office アプリケーションのウィンドウが開き、そのウィンドウでドキュメントが表示されます (Office 2010 の場合は [保護されたビュー] で開きます)。

2011年6月8日

IE のトラブルシューター

Filed under: Internet Explorer — hebikuzure @ 11:02 AM

MSKB 2369119
初心者でもわかる! IE トラブル おすすめ対処法
http://support.microsoft.com/kb/2539119/ja


Internet Explorer でのトラブルはサポートやヘルプデスクに来る問い合わせの中でも大きな割合を占めていると思いますが、こうしたトラブルの多くは簡単なトラブルシュートで原因を確認し、回避できます。そのようなトラブルシュートが初心者でも簡単にできるようなトラブルシューターがマイクロソフトから公開されていますので、紹介します。

初心者でもわかる! IE トラブル おすすめ対処法
http://support.microsoft.com/kb/2539119/ja

大筋として、

  1. 互換表示を試す
  2. インターネット一時ファイルと履歴を削除する
  3. アドオンを無効にする
  4. IE をリセットする

という流れになっていますが、それぞれの手順がスクリーン ショット付きでわかりやすく説明されています。

なお対象製品はIE6、IE7、IE8 となっていますが、IE9 も IE8 と同じ手順でトラブルシュートできますので、ぜひお試しください。

Older Posts »

WordPress.com Blog.

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