Flash Player 10のUIA（ユーザ主導型アクション）要件におけるユーザ操作の義務化について

Adobe Flash Player 10には数々の変更点が実装されていますが、この中には全体的なセキュリティ強化とともに、他のWebクライアント（ブラウザなど）に実装されつつある新たなWebセキュリティモデルとの円滑な連携を目的とした、ユーザ主導型アクション（user-initiated action、以下「UIA」）の義務化に関する変更が含まれています。この記事では、Flash Playerに対するUIAの義務化、つまりUIA要件の適用によって何が制限されるのか、なぜこの制限が必要なのか、そして、どのようにすればこの義務化に対応したコンテンツを作成できるかなど、この最新要件の理解を深めるための情報を紹介していきます。

ActionScript APIの特定の機能にUIA要件が課されている場合、当該機能は、マウスクリックやキータッチといったUIAに基づいてのみ呼び出すことができます。今回Flash Player 10に追加されたUIA要件は、既存のActionScript 2.0 APIおよびActionScript 3.0 APIの一部だけでなく、Flash Player 10から搭載された新機能およびAPIの一部に対しても適用されます。

UIAに関する今回の制限は、ユーザコンピュータへのファイルのダウンロード、ユーザコンピュータからのファイルのアップロード、フルスクリーンモードの起動、ユーザコンピュータのクリップボードへの書き込みといった、潜在的なリスクを伴う処理が、キータッチやマウスクリックなどのユーザによる意図的な行為なしに実行されることを防ぐためのものです。

UIA要件の適用対象

Flash Player 10でいうUIAとは、キーボードまたはマウスの、いずれかのイベントのことです。つまり、キーボードのキーを押す、あるいはマウスのボタンをクリックすることが、UIAにあたります。今回UIA要件が適用されるのは、以下に挙げる操作・処理です。

ユーザ操作の義務化による今回の制限は、ユーザコンピュータへのファイルのダウンロード、ユーザコンピュータからのファイルのアップロード、フルスクリーンモードの起動、ユーザコンピュータのクリップボードへの書き込みといった、潜在的なリスクを伴う処理が、キータッチやマウスクリックなどのユーザによる意図的な行為なしに実行されることを防ぐためのものです。

ユーザによる意図的な操作の義務化

Flash Player 10でいう「ユーザによる意図的な操作」とは、キーボードまたはマウスの、いずれかのイベントのことです。つまり、キーボードのキーを押す、あるいはマウスのボタンをクリックすることが、この操作にあたります。ユーザによる意図的な操作が義務づけられる対象には、以下の処理・操作が含まれます。

• FileReferenceの操作: FileReferenceオブジェクトのbrowse、download、saveメソッド、およびFileReferenceList.browseメソッドは、UIAの結果として生じるActionScript関数内（つまり、キータッチまたはマウスクリック時のイベントハンドラ）から呼び出された場合に限り、正しく処理されます。この制限により、特定のWebページがユーザの明確な同意なしに、ユーザマシンからファイルをアップロードまたはダウンロードするための呼び出しを行う問題が回避できます。UIA要件の適用によって、特に問題になる恐れのあるFileReference関連のケースとしては、ネットワークを起点としたcallback/eventハンドラの処理、およびExternalInterfaceを介した呼び出しが挙げられます。これまでのバージョンのFlash Playerでは、これらの位置から問題なくFileReferenceを呼び出すことができました。しかし、Flash Player 10では、これらの処理がUIAの結果として生じる呼び出しではないことが理由で、当該操作が処理されません。この問題が生じるアプリケーションにおいては、ワークフローの一貫として、UIAを受け付けるためのインタラクティブな手順を追加実装する必要があります。
• POST APIs: HTTPのPOSTを利用してターゲットサーバへのファイルアップロードにあたる処理を行う場合は、UIAに基づくものに限り、処理が正しく実行されます。このアップロード形式は RFC1867と呼ばれ、POSTのボディ部分の一環として「Content-Disposition」ヘッダに「filename」属性が含まれた、Content-Typeが「multipart/form-data」のHTTP(S) POSTで構成されています。このPOSTを介したRFC1867アップロードに対する制限により、SWFがユーザの明確な許可を得ることなく、当該SWFのホスティングされているサーバに無断でデータを送信する問題が回避できます。なお、SWFがPOST経由で、当該SWFのホスティングされているサーバ以外のサーバにファイルをアップロードすることを許可したいケースでは、アップロードを受け取る側のサーバにも適切なクロスドメインポリシーを設置し、クロスドメインのPOSTに対応できるようにする必要があります。（詳しくは、クロスドメインポリシーファイルの仕様を参照してください。）
• クリップボード: Flash Player 9およびそれ以前から用意されていたActionScript 2.0 / 3.0 APIのSystem.setClipboard()では、今後システムのクリップボードへの書き込みを行う際に、UIAが必要となります。なお、Flash Player 10から新採用のClipboard.generalClipboardオブジェクトは、システムクリップボードからの読み書き両方に対応できます。システムクリップボードの書き込み時にどちらのAPIを利用するとしても、当該書き込み処理はUIAの結果として生じる必要があります。また、ActionScript 3.0の新しいAPIであるClipboard.generalClipboard.getDataを使用してシステムクリップボードからデータを読み取る際には、この操作がペーストイベントハンドラの結果として生じない限り、処理が行われません。ペーストイベントハンドラは、マウスを使用してコンテキストメニューを有効化するか（右クリックまたはControl +クリック）、ペースト操作用のキーボードショートカット（Control+VまたはCommand+V）を利用してのみ呼び出すことができます。つまり、ペーストのハンドラ内で実行されるAPIは、必ずUIAの結果として生じるものに該当します。クリップボードに関するこの制限により、SWFがユーザの関知しないところでクリップボードコンテンツを設定できる問題が回避できます。
• フルスクリーンモード: Flash Player 9およびそれ以降でフルスクリーンモードを有効化するには、（ActionScript 2.0およびActionScript 3.0の）Stage.displayState APIが用いられます。今後、フルスクリーンモードを有効化できるのは、このStage.displayStateがキータッチまたはマウスクリックのユーザイベントハンドラから呼び出された場面に限定されます。この制限により、ユーザがフルスクリーンモードの有効化に気付くことなく、SWFが、ユーザ画面上の他のコンテンツを妨害できるようになる恐れを軽減できます。
• ポップアップウィンドウ: ブラウザ上で新たなウィンドウを開きたい場合は、以下のActionScript APIが利用できます。
  • NavigateToURL (ActionScript 3.0)
  • GetURL (ActionScript 2.0)
  • TextField anchors
  • ExternalInterface
  • FSCommand

上記のいずれかのAPIを利用して新規ウィンドウを開く操作は、ユーザイベント（キータッチまたはマウスクリック）のハンドラから呼び出された場面に限り、正しく処理されます。仮にこれらのAPIがユーザイベントハンドラ以外のActionScriptコードから呼び出された場合、ブラウザは、その環境設定にもよるものの、ポップアップウィンドウの表示を拒否することがあります。なお、ポップアップウィンドウの表示が試行されるかどうかは、Flashプラグインをホスティングするブラウザの種類および環境設定に左右されるため、動作はどのブラウザを使用するかによって異なります。新規ウィンドウが可能な限りすべてのブラウザで正しく開かれるようにしたい場合は、新規ウィンドウをUIAの結果としてのみ、開くようにしてください。ポップアップウィンドウを開く際のこの制限は、ブラウザのポップアップウィンドウ表示設定とFlash Playerの連携性を確保することを目的に設定されています。

UIA要件への対応

Flash Player 10のUIA要件に適合させるためには、SWFコンテンツ制作者が取り得る（場合によっては、取らざるを得ない）いくつかの手順があります。今回のUIA要件への対応策として肝心なのは、前出の各機能性が、ユーザによるキータッチまたはマウスクリック（つまり、UIA）の結果として発生するイベントハンドラ内で処理されるようにすることです。

ユーザ操作の義務化に向けた対応策

Flash Player 10におけるユーザ操作の義務化に向けて、SWFコンテンツ作者が取り得る（場合によっては、取らざるを得ない）手順はいくつかあります。今回のユーザ操作義務化に対応するためには、前出の各機能性が、ユーザによるキータッチまたはマウスクリックの結果として発生するイベントハンドラ内で処理されるようにすることが重要です。

例えば、クリップボードへの書き込みは、切り取りまたはコピーの一般的なショートカット（Control+X/Command+XまたはControl+C/Command+C）のイベントハンドラ内、または「クリップボードにコピー」などと記されたボタンのクリックを介してのみ、処理できるようにすることが可能です。このようにすることで、ユーザはクリップボードへのテキスト書き込み操作を明確に指示できるようになります。つまり、これでUIA要件がクリアされたことになり、書き込み処理が適切に行われるようになります。大半のケースでは、処理がUIAの結果として行われるようにするために、SWFにユーザインターフェイスコントロールを追加しなければならなくなります。例えば、これまでユーザからの入力なしに新規ウィンドウを開いていた場合、今後は新規ウィンドウを開くためのボタンを設置するなどの対策が必要になります。

一部のケースでは、他にも対応策として、デザインまたはコードの変更が必要になることもあります。次に示すシナリオがその一例です。あるアプリケーションが特定の処理を実行するためのコマンド（画像ファイルの形式変換など）を送信し、その処理後のデータが、ダウンロードで返されるようになっていたとします。従来、このようなアプリケーションはサーバでの準備が整い次第、ユーザのインタラクションなしにFileReference.download APIを自由に呼び出すことができました。しかし、これからはサーバの準備が整った段階で、「ダウンロードの準備ができたので、こちらをクリックしてダウンロード」といった、追加のインタラクティブUIをアプリケーションが提示する必要があります。つまり、アプリケーションのユーザワークフローに、インタラクティブな手順を追加実装しなければならないことがあります。

UIA要件が処理の妨げになっているかどうの判定作業を支援するために、SWFデベロッパーには２種類のデバッグ方法が用意されています。どちらの方法を利用するとしても、SWFデベロッパーの環境にはデバッグ版のFlash Playerがインストールされている必要があります。ActionScript 3.0を用いてSWFがオーサリングされている場合は、デバッグ版のFlash Playerが、UIAの欠落によって操作が拒否された際のActionScript 3.0例外をキャッチして表示することができます。一方、ActionScript 2.0を用いてSWFがオーサリングされている場合、クリップボードへの書き込みがUIAの欠落によって拒否された際には、Clipboard.setData APIがその旨をログのflashlog.txtに記録します。flashlog.txtファイルを用いたデバッグログ記録の使用法について詳しくは、Flash Playerテクニカルノートの「Flash Playerデバッグ版の構成を参照してください。このログ記録機能は、ActionScript 2.0のログ機能を拡張することと、今後リリースされるFlash PlayerでのUIA要件違反によって発せられるActionScript 3.0例外の処理精度を高めることを目的にしたものです。

Flash Player 10に実装されたUIA要件は、このバージョンのプレイヤーに読み込まれるすべてのバージョンのSWFに適用されます。つまり、バージョン９を対象にオーサリングされたSWFにも、Flash Player 10上ではUIA要件が課されます。今回のUIA要件に対応するためには、多くのケースにおいて、（この記事で紹介した）UIコントロールの追加またはワークフローの変更といった対策を講じるためのSWFコード編集を行い、コンテンツを再パブリッシュする必要があります。

次のステップ

デベロッパーの皆さんには、自らのSWFコンテンツが最新のUIA要件を満たしていることを確認するよう、お勧めします。この際、新規コンテンツのみを対象とするのではなく、既存コンテンツの更新も行うように注意してください。