- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!!!Mark of the Web
WindowsXP SP2あたりからだったか、Internet Explorerでスクリプトを含むローカルのHTMLファイルを開くと以下のように警告されるようになった。
{{bq
セキュリティ保護のため、コンピュータにアクセスできるアクティブ コンテンツは表示されないよう、Internet Explorer で制限されています。オプションを表示するには、ここをクリックしてください...
bq}}
}}
これはマイコンピュータのセキュリティ設定が通常のインターネットゾーンのセキュリティ設定よりも厳しくなっているため。で、ローカルのファイルでも''強制的にインターネットゾーン（＝スクリプト動作可）として扱わせる''のが''Mark of the Web(MOTW)''。
その方法は簡単で、HTML中に
{{pre
<!-- saved from url=(0014)about:internet -->[CRLF]
}}
という記述をする（もちろん"[CRLF]"は改行）。[MSDN|http://msdn.microsoft.com/en-us/library/ms537628%28VS.85%29.aspx]と[kb833633|http://support.microsoft.com/kb/833633/ja]によると、この記述は''先頭から2048byte以内''にせねばならず、この行の''改行はCRLF''で無ければならない。"about:internet"の部分はURLであり、"http://up-cat.net/"等と記述すればセキュリティゾーンの判定上"http://up-cat.net/"のファイルとして扱われる。"(0014)"はこのURLの長さを表しており、"about:internet"が14文字であるためこの数値となる。
!!と公式では言っているが…
しかし、手元のIE8では''"(0014)"では動作しないことがあった''。"saved from url"で検索してみると、ここの数値に"(001'''3''')"にしている記述がいくつもある。他の考えられる可能性を様々試した後、「まさかね…」と思いながら
{{pre
<!-- saved from url=(0013)about:internet -->[CRLF]
}}
を試すと、''1発で成功''。しかもその後14に戻しても警告が表示されない。なんだなんだ？キャッシュか？NTFS副ストリームに何か書いてるのか？わからないが、とにかく動作した。
!ちなみに
IEでの保存やOutlookではこのシグネチャが自動的に入るとか、mhtではこの問題は発生しない、MOTWはXMLには効かない、等の話があるようだが、手元のXP SP3 + IE8ではXHTMLで上記の通り一応効いた。
!!そもそも…（愚痴）
ローカルをインターネットゾーンより厳しい制限にする意味が分からない。インターネットよりローカルの方が危険なケースって何だ？ 恐らくはメール''（しかもOutlookとかWindowsメールとか）''で受信したHTML等（主にspamのもの）を危惧しているのだろうが、添付にしろ本文にしろ、''その危険なHTMLメールを率先してデファクトスタンダードに仕立てたのは他ならぬMicrosoft''だ。えーと、こういうのを何と言うのだっけ。マッチポンプ？ MSには何の利益もないのに。
もっとそもそもで言ってしまえば、''HTML中のスクリプトは実行禁止にせずとも安全に実行できなければならない''。純粋なスクリプト仕様にはブラウザ外へのいかなるアクセス手段も用意されていない。純粋なスクリプトのみで危険性が発生するなら、それは''スクリプトインタプリタのバグ''なのだ。
''危険なのはIEのスクリプト拡張機能であるActiveXへのアクセスだけ''なはずで、これを禁止しておけば問題はない。つまりGetObject、new ActiveXObject、CreateObjectだけ禁止すればよい。それは当たり前の話で、だからこそHTMLをアプリケーション的に使う場合のために、''ActiveX使い放題なHTAという仕組みを別途用意''しているではないか。
UACや署名ドライバもそうだが、ユーザ操作と安全性に関してのマイクロソフトの方針はどこかおかしいように思う。それとも''両立させる設計力がないのだろうか？'' 安全性問題に対する上層部の圧力で現場は「不便な制限」を実装し、実作業では自分たちも「制限の回避設定」にしていたりしないだろうか。どう考えてもUAC有効の末端ユーザ権限で、効率的に作業できるとは思えない。個人的には、''各種の回避方法が存在することが、設計の悪さの証拠''になっているのではないかと思う。これらの制限が本当に良く設計されており回避が不要なら、そのような''回避方法の存在の方が、脆弱性に繋がる''からだ。
