ウィンドウ管理

1. はじめに

このセクションは規範的ではありません。

オペレーティングシステムは一般的に、ユーザーが単一のデバイスに複数の画面を接続し、それらを仮想的に配置して全体の作業領域を拡張できるようにしています。

さまざまなアプリケーションがプラットフォームのツールを使って、こうしたマルチスクリーン環境にコンテンツを配置していますが、Webアプリケーション開発者には従来のAPIの制約があり、多くは単一画面の利用を前提に設計されています。

マルチスクリーンデバイスやアプリケーションが、より一般的かつ重要なユーザー体験の一部となるにつれ、Web開発者が拡張された表示環境を活用できる情報やツールを提供することがより重要になります。

この仕様は、Window、 Screen、 FullscreenOptions のAPIを段階的に拡張し、新たにScreenDetails および ScreenDetailed インターフェイスを導入します。これらの変更により、Webアプリケーションは特定の画面にコンテンツを配置するなど、魅力的なマルチスクリーン体験を提供できるようになります。

1.1. 想定ユースケース

この仕様の目的は、複数画面を持つWebアプリケーションユーザーに、より良い体験を提供することです。以下は設計の参考となるユースケース例です：

• スライドショーアプリがプロジェクターで発表用画面を表示し、ノートパソコンの画面に発表者ノートを表示する。

• ファイナンシャルアプリが複数モニターにダッシュボードウィンドウを展開する。

• 医療用アプリが高解像度のグレースケールディスプレイで画像（例：レントゲン）を表示する。

• クリエイティブ系アプリがパレットなどの補助ウィンドウを別画面に表示する。

• 会議室アプリがタッチスクリーンデバイスでコントロールを、テレビでビデオを表示する。

• ゲーム・サイネージ・アートなど、各種アプリでのマルチスクリーンレイアウト。

• ウィンドウが複数画面をまたぐ際に、サイトがコンテンツやレイアウトを最適化する。

1.2. 利用概要

マルチスクリーン体験をサポートするため、APIはWebアプリケーションで以下を可能にします：

1. デバイスに複数の画面があるかどうか検出する

2. 特定の画面にコンテンツを配置するために必要な情報を取得する

3. 画面の追加・削除を検出する

4. 現在の画面やその属性が変化した場合に検出する

5. 特定の画面で要素をフルスクリーン表示する

6. ウィンドウを特定の画面に配置する

7. 単一の一時的ユーザー操作からマルチスクリーン体験を開始する

// デバイスに複数の画面があるか検出
if (window.screen.isExtended) {
  // 特定の画面にコンテンツを配置するため必要な情報を取得。
  const screenDetails = await window.getScreenDetails();

  // 画面が追加・削除された時の監視。
  screenDetails.addEventListener('screenschange', onScreensChange);

  // 現在の `ScreenDetailed` や属性の変更監視。
  screenDetails.addEventListener('currentscreenchange', onCurrentScreenChange);

  // プライマリスクリーンを探し、そこにコンテンツをフルスクリーン表示。
  const primaryScreen = screenDetails.screens.find(s => s.isPrimary);
  document.documentElement.requestFullscreen({screen : primaryScreen});

  // 他の画面を探し、その利用可能領域に新しいウィンドウを配置。
  const otherScreen = screenDetails.screens.find(s => s !== primaryScreen);
  window.open(url, '_blank', \`left=${otherScreen.availLeft},\` +
                             \`top=${otherScreen.availTop},\` +
                             \`width=${otherScreen.availWidth},\` +
                             \`height=${otherScreen.availHeight}\`);
} else {
  // レガシー `Screen` インターフェイス属性変化の監視。
  window.screen.addEventListener('change', onScreenChange);

  // 従来の単一画面環境でのレイアウト…
}

1.2.1. 複数画面の有無を検出する

マルチスクリーン体験を実現するうえで重要なのは、コンテンツを配置できる複数の画面がデバイスに存在するかです。これらの画面は（ラップトップのディスプレイパネルのような）内蔵タイプ、（HDMIケーブル等で接続された）外付けタイプ、（MacとiPadのSidecar機能のような）他の手段で接続されたもの、または仮想化によるディスプレイデバイスなどが含まれます。これはisExtended ブール値により提供され、パーミッションプロンプト無しでセキュアコンテキストから利用できます。

if (screen.isExtended) {
  // ユーザーのためにマルチスクリーンコントロールを提供。
}

1.2.2. Screen 属性の変化を検出する

レガシーScreen 属性の変化を監視することは、単一画面デバイスでもコンテンツを適応させる上で有用です。また、 isExtended を監視することで、単一画面からマルチスクリーン構成への移行も検出できます。ポーリングを避けるため、 change イベントがScreen オブジェクトで発火します：

screen.addEventListener('change', e => {
  // レガシー `Screen` インターフェイスの属性が変更された。
});

1.2.3. 詳細な画面情報を要求する

デバイスで利用されている画面の詳細情報は、getScreenDetails() メソッドで取得できます。このメソッドはパーミッションを求める場合があります。返されるScreenDetails オブジェクトでは、画面の列挙、属性取得、変化監視ができます。

try {
  // 画面詳細を要求し、即時に情報を処理。
  const screenDetails = await window.getScreenDetails();
  processScreenDetails(screenDetails);

  // 画面セットが変化した時に詳細情報を処理。
  screenDetails.onscreenschange = () => {
    processScreenDetails(screenDetails);
  };
} catch (err) {

  console.error(err);
  // パーミッション拒否やその他のエラー処理。
}

function processScreenDetails(screenDetails) {
  // 画面リストのUIを構築（補助関数利用を仮定）。
  clearScreenList();
  screenDetails.screens.forEach(screen => {
    addToScreenList({name: screen.label, screen: screen});
    // 個別画面情報が変化した場合にも再処理。
    screen.onchange = () => {
      processScreenDetails(screenDetails);
    };
  });
  selectCurrentInScreenList(screenDetails.currentScreen);
}

1.2.4. 特定画面にフルスクリーンコンテンツを配置する

マルチスクリーンで一般的な使い方は、特定の画面でコンテンツをフルスクリーン表示することです。画面はインタラクティブに選択する場合も、属性や事前選択に基づき自動選択する場合もあります。選択された画面は、requestFullscreen() メソッドに渡せます。

// 選択された `ScreenDetailed` インスタンスを返す補助関数を仮定。
const screenDetailed = getScreenForSlideshow();

// 選択画面で要素をフルスクリーン表示を要求。
slideshowElement.requestFullscreen({ screen: screenDetailed });

1.2.5. 特定画面にウィンドウを配置する

もうひとつの一般的なマルチスクリーン用途は、ウィンドウを特定画面に配置することです。これは、ScreenDetailed インターフェイスの座標と、open() や moveTo() など既存メソッドを用いて実現できます。

function openCenteredWindow(url, screenDetailed, w, h) {
  // ターゲット画面の中央にウィンドウを配置する座標計算。
  const l = screenDetailed.left + Math.round(screenDetailed.width - w) / 2;
  const t = screenDetailed.top + Math.round(screenDetailed.height - h) / 2;

  // 指定サイズでウィンドウを開く。
  return window.open(url, '_blank', \`left=${l},top=${t},width=${w},height=${h}\`);
}

1.2.6. マルチスクリーン体験を開始する

よくあるマルチスクリーン目的の一つは、単一のユーザー操作から魅力的なマルチスクリーン体験を開始することです。具体案のひとつは、サイトが単一ユーザー操作で § 1.2.4 特定画面にフルスクリーンコンテンツを配置 および § 1.2.5 特定画面にウィンドウを配置 の両方を行える形です。これは、マルチスクリーンデバイスの特定画面にフルスクリーンを要求し、同じイベントリスナー内で別画面にポップアップウィンドウを開くことにより実現できます。

initiateMultiScreenExperienceButton.addEventListener('click', async () => {
  // プライマリスクリーンを探し、そこにコンテンツをフルスクリーン表示。
  const primaryScreen = screenDetails.screens.find(s => s.isPrimary);
  await document.documentElement.requestFullscreen({screen : primaryScreen});

  // 他の画面を探し、その利用可能領域に新しいウィンドウを配置。
  const otherScreen = screenDetails.screens.find(s => s !== primaryScreen);
  window.open(url, '_blank', \`left=${otherScreen.availLeft},\` +
                             \`top=${otherScreen.availTop},\` +
                             \`width=${otherScreen.availWidth},\` +
                             \`height=${otherScreen.availHeight}\`);
});

2. 概念

本仕様の概念は、CSSOM-View-1 作業草案、 CSSOM-View-1 編集者ドラフト、 [HTML]、 [Fullscreen] を基にしています。

2.1. スクリーン

ユーザーエージェントをホストするデバイスには、単一のスクリーンまたは複数のスクリーンがあり、ビジュアルコンテンツの表示に使用されます。デバイスで利用されるスクリーンのセットは、ユーザーエージェント実行中にも、デバイスのハードウェアやソフトウェア構成の変化を反映して変更されることがあります。

Note: スクリーン構成が変わる基本例としては、ノートパソコンにHDMIケーブルでテレビやプロジェクターを接続する、ノートパソコンのふたを閉じて内蔵液晶パネルを無効化する、接続された液晶モニターの解像度を変更する、などがあります。

2.2. スクリーンピクセル

2.3. スクリーン領域

Note: グリッドの大きさは通常、<幅>×<高さ>で表現されます。例えば、1920×1080 のスクリーン領域は幅1920ピクセル・高さ1080ピクセルのグリッドです。

Note: CSSOM View § 2.3 Web公開スクリーン情報 で規定されている通り、ユーザーエージェントはユーザーのプライバシー保護のために出力デバイスのスクリーン情報を非公開にすることができます。この場合、スクリーン領域はビューポートと同じになることがあります。

2.4. 利用可能スクリーン領域

2.5. 仮想スクリーン配置

デバイスは 仮想スクリーン配置を持ち、これはデバイス全体の表示環境を構成するスクリーンの相対的な配置を定義します。配置は、一般に全方向に広がる2次元平面上に構成され、（x, y）座標はそれぞれ右と下方向に増加します。その起点はマルチスクリーン原点であり、これは 仮想スクリーン配置 の(0, 0)座標です。

よくある慣例として、マルチスクリーン原点を プライマリスクリーンの左上隅に設定しますが、仮想スクリーン配置内の任意の点が原点となりえます。あらゆるスクリーンのスクリーン領域は、仮想スクリーン配置の長方形サブセットへのビューです。

以下の図は、複数のスクリーンが仮想スクリーン配置内でどのように配置され得るか、またマルチスクリーン原点例を示しています：

Note: Second Screen Community GroupのForm Factors Explainedドラフトレポートは、関連する用語や概念モデルを詳述しています。

2.6. スクリーン座標

スクリーンは スクリーン座標 を持ち、これは仮想スクリーン配置の中でマルチスクリーン原点を基準としたスクリーン領域の(x, y)座標です。座標は負値となる場合もあり、通常は(x, y) の形式で表わします。

2.7. 利用可能スクリーン座標

スクリーンは 利用可能スクリーン座標 を持ち、これはマルチスクリーン原点を基準にした利用可能スクリーン領域の(x, y)座標です。座標は負値の場合もあり、通常は(x, y)の形式で表します。

2.8. プライマリスクリーン

ユーザーエージェントをホストするデバイスは、正確に一つのプライマリスクリーンを持ちます。それ以外のスクリーンはセカンダリと見なされます。

Note: プライマリスクリーンは、通常タスクバーやDockなど、OS自体のタスク管理UIをホストします。

スクリーンの プライマリ または セカンダリ 指定は、ユーザーエージェント実行中にも変化し得ます。

Note: 多くのOSでは、WindowsコントロールパネルやmacOS設定アプリのようなUIでユーザーがプライマリスクリーンを選択できます。

2.9. 内蔵スクリーン

各スクリーンは 内蔵 または 外部 と指定されることがあります。

外部スクリーンは、ビジュアル出力を提供するデバイスとは別に製造されます。外部スクリーンは別のデバイスに取り外して接続されることが珍しくありません。

Note: 例：デスクトップコンピューターは、HDMIケーブルで接続された外部スクリーンに表示します。HDMIケーブルは、コンピューター利用中でも挿抜可能で、その都度ハード構成変更に応じて表示環境を調整します。

内蔵スクリーンは通常、製造時にデバイスへ取り付けられます。内蔵スクリーンはユーザーによる取り外しを想定していません。ただし、内蔵 スクリーンでも、ユーザーエージェント実行中に有効・無効の切り替えが可能です。

Note: 例：ラップトップのふたを閉じると、内蔵スクリーンや入力装置が無効化されることがあります。この状態でも、外部スクリーン・入力装置を使って利用可能です。内蔵無効化スクリーンは、ふたを閉じている間はデバイスが利用するスクリーンとして報告されません。

2.10. 現在のスクリーン

Window コンテキストで実行されるスクリプトは、screen 属性にアクセス可能です。そのScreen オブジェクトは現在のスクリーンの特性を反映しており、これはそのウィンドウを現在表示しているスクリーンです。

Note: 多くのOSでは、1つのウィンドウが異なる特性を持つ複数のスクリーンにまたがって表示されたり、「隠し」状態でどのスクリーンにも表示されなかったりします。OSおよびユーザーエージェントは、例えばウィンドウと最も大きく重なるスクリーン等、そのWindowについて正準的なスクリーンを定義すると想定されます。

2.11. 観測可能なスクリーンプロパティ

スクリーンの基本的な観測プロパティは次の通りです：

• 幅 と 高さ（スクリーン領域）

• 利用可能幅 と 利用可能高さ（利用可能スクリーン領域）

• カラーデプス

• 向き

スクリーンの高度な観測プロパティは次の通りです：

• スクリーン座標

• 利用可能スクリーン座標

• デバイスピクセル比

• ラベル

• スクリーンがプライマリまたはセカンダリであること

• スクリーンが内蔵または外部であること

3. API

3.1. Screen インターフェイスの拡張

CSSOM View Module 仕様は Screen インターフェイスを定義しており、本仕様はそれを拡張します：

partial interface Screen /* : EventTarget */ {
  [SecureContext]
  readonly attribute boolean isExtended;

  [SecureContext]
  attribute EventHandler onchange;
};

Screen を EventTarget として CSSOM View § 4.3 The Screen Interface で継承させるべきか。

3.1.1. isExtended 属性

3.1.2. onchange 属性

onchange属性は、イベントハンドラーIDL属性であり、イベントタイプは change です。

基本の観測可能プロパティのいずれかがWindow windowの現在のスクリーンで変更されたとき、windowの関連するグローバルオブジェクト上でグローバルタスクをキューし、window placement task sourceを用いて イベント change を windowのScreen オブジェクト（screen 属性で参照）で発火する。

3.2. Window インターフェイスの拡張

[HTML]標準は Window インターフェイスを定義しており、本仕様はそれを拡張します:

partial interface Window {
  [SecureContext]
  Promise<ScreenDetails> getScreenDetails();
};

3.2.1. getScreenDetails() メソッド

getScreenDetails() メソッドは非同期に完了し、window placement task sourceで作業をキューします。

Window のインスタンスには 内部スロット [[screenDetails]] が作成時に undefined で設定されます。

3.2.2. Window 属性およびメソッド定義の変更

次のWindow の属性とメソッド定義は、マルチスクリーン原点を基準に値を返し・解釈するように更新されています:

• screenX および screenLeft は、クライアントウィンドウの左端のx座標をマルチスクリーン原点基準の CSSピクセル数で返す。該当しなければ0。

• screenY および screenTop は、クライアントウィンドウの上端のy座標をマルチスクリーン原点基準の CSSピクセル数で返す。該当しなければ0。

• moveTo() の手順はx, y引数をマルチスクリーン原点基準と解釈する。

• open() の手順は"left"および"top"フィーチャ値をマルチスクリーン原点基準と解釈する。

3.2.3. Window.open() メソッド定義の変更

Window のインスタンスは、データモデルがlast activation timestampと同等の[[targetScreenFullscreen]] 内部スロットを持つ。これは通常DOMHighResTimeStamp 値だが、2つの例外があり：正の無限大はまだ一度もアクティベートされていないこと、負の無限大はユーザーアクティベーションゲートAPI(詳細は HTML § 6.4.3)が最後のユーザーアクティベーションを消費したことを示す。初期値は正の無限大。

Window.open() の手順およびそのサブメソッドの手順は、オプションで次の動作を行うように更新されています：

1. 一時的アクティベーションの状態要件を免除可能とする（関連グローバルオブジェクトの 現在高分解能時刻 が this.[[targetScreenFullscreen]] 以上でかつ this.[[targetScreenFullscreen]] + 一時的アクティベーション持続時間未満の場合）。

2. this.[[targetScreenFullscreen]] をユーザーアクティベーション消費後、即座に負の無限大に設定する。

3.3. ScreenDetails インターフェイス

[Exposed=Window, SecureContext]
interface ScreenDetails : EventTarget {
  readonly attribute FrozenArray<ScreenDetailed> screens;
  readonly attribute ScreenDetailed currentScreen;

  attribute EventHandler onscreenschange;
  attribute EventHandler oncurrentscreenchange;
};

3.3.1. screens 属性

3.3.2. currentScreen 属性

currentScreenゲッターの手順は、現在のスクリーンを表すScreenDetailed オブジェクトを、screens 内から返すことです。これはWindow オブジェクトと関連付けられたthisの現在のスクリーンです。

Note: どのScreenDetailed オブジェクトが現在のスクリーンを表すかはOSやユーザーエージェントによって定義されます。これは Window.screen と合致し、例えばウィンドウと最も多く重なるスクリーンなどが該当します。

注: currentScreen は、screens のいずれかのエントリと===で比較可能であることが保証されています。たとえば screenDetails.screens.find(s => s !== screenDetails.currentScreen); のような比較を容易に実現できます。そのため、currentScreen を[SameObject]とすることはできません。関連して、change イベントリスナーをcurrentScreen に追加した場合、その特定のスクリーンの変更のみが通知されます。一方、currentscreenchange イベントリスナーは、ウィンドウの現在のスクリーンが別のスクリーンに移動したとき、そのどれに対しても変更が通知されます。

3.3.3. onscreenschange 属性

onscreenschange属性は、イベントハンドラーIDL属性であり、そのイベントタイプはscreenschangeです。

ScreenDetails オブジェクト screenDetails の screens のセットが変更されたとき、screenDetails の 関連グローバルオブジェクト 上で グローバルタスクをキュー し、window placement task source を使って イベント名 screenschange を screenDetails で発火する。

3.3.4. oncurrentscreenchange 属性

oncurrentscreenchange属性は、イベントハンドラーIDL属性であり、そのイベントタイプはcurrentscreenchangeです。

window の 現在のスクリーン がある スクリーン から別のスクリーンに変わったとき（例：Window が他のディスプレイへ移動した場合）、または window の 現在のスクリーン の 基本的な観測プロパティ または 高度な観測プロパティ のいずれかが変化したとき、window の 関連グローバルオブジェクト上で グローバルタスクをキューし、window placement task source を使って イベント名 currentscreenchange を window の内部スロット ScreenDetails オブジェクト（[[screenDetails]]）で発火する。

3.4. ScreenDetailed インターフェイス

ScreenDetailed オブジェクトはスクリーンを表します。

[Exposed=Window, SecureContext]
interface ScreenDetailed : Screen {
  readonly attribute long availLeft;
  readonly attribute long availTop;
  readonly attribute long left;
  readonly attribute long top;
  readonly attribute boolean isPrimary;
  readonly attribute boolean isInternal;
  readonly attribute float devicePixelRatio;
  readonly attribute DOMString label;
};

availLeftゲッターの手順は、このscreenの利用可能スクリーン座標のx値を返す。

availTopゲッターの手順は、このscreenの利用可能スクリーン座標のy値を返す。

leftゲッターの手順は、このscreenのスクリーン座標のx値を返す。

topゲッターの手順は、このscreenのスクリーン座標のy値を返す。

isPrimaryゲッターの手順は、このscreenがプライマリか否かを判定し、該当すればtrue, そうでなければfalseを返す。

isInternalゲッターの手順は、このscreenが内蔵ならtrue, そうでなければfalseを返す。

devicePixelRatioゲッターの手順は、このscreenのデバイスピクセル比を返す。

labelゲッターの手順は、このscreenのラベルを返す。

3.4.1. onchange 属性

onchange属性は、onchange 属性をScreenから継承したものです。

ScreenDetailed オブジェクト screenDetailed が表す 基本的な観測プロパティ または 高度な観測プロパティ のいずれかが スクリーンで変更されたとき、screenDetailed の 関連グローバルオブジェクト 上で グローバルタスクをキューし、window placement task source を使って イベント名 change を screenDetailed で発火する。

3.5. FullscreenOptionsへの拡張

partial dictionary FullscreenOptions {
  ScreenDetailed screen;
};

省略可能なFullscreenOptions のscreenメンバーは、特定のスクリーンで要素をフルスクリーン表示したいというアプリケーションの希望を示します。ユーザーエージェントは常にアプリケーションの希望よりユーザーの希望を優先できます。デフォルト値undefined はアプリケーション希望なしを意味します。

3.5.1. Element.requestFullscreen() メソッド定義の変更

Element.requestFullscreen() メソッドの手順は、オプションで次を含むように更新されています：

1. options["screen"] を考慮し、pendingDocのトップレベルブラウジングコンテキストのアクティブドキュメントのビューポート移動・リサイズ時に利用する。この手順でビュー ポートが指定のスクリーンへ移動されることもある。

2. もしoptions["screen"]が ScreenDetailed で、かつisExtended がtrueなら、現在高分解能時刻を this.[[targetScreenFullscreen]] 内部スロットに設定する。

3.6. Permission API連携

本仕様は既定のパワフル機能を定義し、その名前は "window-management"です。

[permissions]APIは パーミッション状態の取得方法をWebサイトに一貫して提供します。

Note: 旧バージョンでは "window-placement" という名前を使用していました。ユーザーエージェントは新しい window-management 文字列へ慎重に移行すべきです。#114参照。

window-management を[permissions]レジストリに追加すること。

パーミッションが取り消された場合のキャッシュ済みオブジェクトやメソッド手順の挙動定義。( #80 )

3.7. Permission Policy連携

本仕様は、"window-management" という文字列で識別されるポリシー制御機能を定義します。これによりisExtended 、getScreenDetails その他の機能使用可否を制御します。この機能のデフォルト許可リストは'self'です。詳細は[permissions-policy] および Experimental Featuresリスト参照。

Note: document のpermission policy は、そのドキュメント内の全てのコンテンツがisExtended で意味のある値取得、ScreenDetails へのアクセス、あるいは特定スクリーンへの配置可否を制御します。無効時はisExtended はfalse、getScreenDetails はpromise拒否、配置要求は現在のスクリーンへ制限される。

window-managementを Proposed またはStandardized 機能リストに掲載すること。

4. セキュリティに関する考慮事項

この仕様はサイトが特定の画面にコンテンツを配置できるようにするため、限定的な新たなセキュリティリスクを生む可能性があります：

1. サイトが予期しない画面にセンシティブなコンテンツを目立つように表示しようとする可能性がある

2. サイトが目立ちにくい画面にこっそり望ましくないコンテンツを表示しようとする可能性がある。例えば：

3. サイトがユーザーの注意を特定の画面に引きつけ、そこでの操作シグナルを使って別のあまり監視されていない画面に欺瞞的なコンテンツを表示し、OS・ブラウザ・他のサイトを詐称してフィッシング攻撃を行おうとする可能性がある

4. サイトがその他の方法で特定の画面にコンテンツを配置し、欺瞞的・虐待的・迷惑な振る舞いを行おうとする可能性がある

こうしたリスクを軽減するために、画面間配置機能はセキュアコンテキストで明示的な許可を必要とし、デフォルトで第三者アクセスを防ぐ[permissions-policy]の対象となります。

ユーザーエージェントは画面を跨いだ配置要求を検出し、潜在的な悪用からユーザーを保護するために介入できます。例えば、サイトが別の画面にコンテンツを配置したときや、画面間配置の後にウィンドウがユーザーの注意を引いたときに、ユーザーエージェントは顕著なセキュリティ表示を行うことがあります。さらに、画面間配置要求は拒否されるか、既存の一部ユーザーエージェントの振る舞いに合わせて current screenにクランプ（制限）されることがあります。

その他の注記：

• 一部のユーザーエージェントは既にウィンドウ配置要求をcurrent screenに制限していません。これらはopen() および moveTo() の座標を multi-screen origin 相対として解釈し、current screen以外の画面へのウィンドウ配置要求を尊重します。

• 一時的ユーザーアクティベーション（Transient user activation）は通常 requestFullscreen() や open() に対して既に要求されますが、moveTo()、 moveBy()、 resizeTo()、 および resizeBy() には要件がないことがあります。

• current screen以外の画面にコンテンツを配置することは、ユーザーのカーソルや指が通常はcurrent screenにあるため、追加的なクリックジャッキングリスクを生む可能性は低いと考えられます。

• レガシーな配置機能を指定されたパーミッションでゲートすることは実現可能かもしれません。

以下の追加的なセキュリティ考察も参照してください：

• W3C Security and Privacy Self-Review Questionnaire for the overall API

• 全体API向けExplainerの「Privacy & Security」

• "Initiating Multi-Screen Experiences"向けW3C Security and Privacy Self-Review Questionnaire

• "Initiating Multi-Screen Experiences"向けExplainerの「Security Considerations」

5. プライバシーに関する考慮事項

この仕様はデバイスに接続された画面に関する新しい情報をサイトに公開するため、限定的な新たなプライバシーリスクを生む可能性があります。特に異例の画面構成を持つデバイスでは、デバイスのフィンガープリンティングの表面が拡大します。

こうしたリスクを軽減するために、新しい情報は一般的な配置ユースケースで必要最小限に削減されており、ほとんどのアクセスはセキュアコンテキストで明示的な許可を要し、デフォルトで第三者アクセスを防ぐ[permissions-policy]の対象です。公開されるスクリーンのリストには相互運用性の問題を軽減しフィンガープリンティングを抑えるための順序が定義されています。ユーザーエージェントは、サイトが新しい情報を要求したときに計測やその他の介入を行うことが一般に可能です。

Screen.isExtended ブールは明示的な許可チェック無しで公開されます。これは単一ビットの最小情報であり、（例：「別の画面で表示」などのマルチスクリーンUIの表示/非表示のエントリポイントを示す）いくつかの重要な機能をサポートし、単一画面ユーザーに不必要な許可プロンプトを表示するのを避けるためです。これはデバイス列挙に関するTAGの設計原則（Web Platform Design Principles § device-enumeration）に概ね従います。

多くのユーザーエージェントは既に、セカンダリスクリーン上にあるウィンドウに対して複数画面の存在を事実上公開しています（window.screen.availLeft|Top が大きい場合）。このビットへのスクリプトアクセスは検出可能なアクティブフィンガープリンティング信号であり、ユーザーエージェントにより観測・ブロックされ得ます。さらに、未許可のウィンドウ配置要求を current screenに制限しないユーザーエージェントは、攻撃者が他の画面へプログラムで配置を試みることを許してしまい、そうした場合にそのwindow.screenに関する情報が露出します。

新しいScreen.onchangeイベントは、ephemeral fingerprintingを容易にすることでわずかなリスクを生みますが、スクリプトは既にwindow.screenの変化をポーリングして同様の結果を得ることができます。このリスクは、隠れたドキュメントに対してはイベントの送出を遅延させることで部分的に緩和できる可能性があります。

サイトにより少ない権限を与える別のAPI形状も検討されましたが、ユーザーと開発者にとって体験が悪くなるため不適当でした（例：ユーザーに画面を選ばせる度にプロンプトする、開発者に宣言的な画面ランク付けを要求するなど）。接続された任意のスクリーンへの非フルスクリーンでのアプリウィンドウ配置に対する実用的な代替はほとんど存在しません。本仕様のAPI形状は、より完全なマルチスクリーン環境をサポートするための既存APIの最も自然な拡張のように思われます。将来的には、サイトが任意で情報公開を最小化できるような、より限定的なマルチスクリーン情報を照会する手段を含める可能性があります。

指定されたアクセスモデルによって、ユーザーエージェントがスクリーンを選択的に公開する（例えばユーザーが指示したスクリーンに関する情報・配置機能のみを制限する）新しい公開モデルを実現できるように、API設計は考慮されています。

その他の注記：

• レガシーのスクリーンおよびウィンドウ情報を指定パーミッションでゲートすることは実現可能かもしれません。

以下の追加的なプライバシー考察も参照してください：

• W3C Security and Privacy Self-Review Questionnaire for the overall API

• 全体API向けExplainerの「Privacy & Security」

• "Initiating Multi-Screen Experiences"向けW3C Security and Privacy Self-Review Questionnaire

6. アクセシビリティに関する考慮事項

この仕様はサイトが特定の画面にコンテンツを配置できるようにするため、限定的な新たなアクセシビリティリスクを生む可能性があります。視覚的な提示、非視覚的なレンダリング、および支援技術がコンテンツ自体に与える影響は、コンテンツをどの画面に配置するかによって大きく変わることは一般的にありません。それでも、プログラムによるコンテンツ配置に関する既存のアクセシビリティ上の懸念は、配置可能な領域が拡大することで悪化する可能性があります。本仕様のパーミッションモデル、プロンプト方法、およびパーミッション関連UIに関する既存のアクセシビリティ考慮事項は、この仕様のパーミッションにも同様に関係します。

現時点で、APIによって公開される構造化されたスクリーン情報（およびそのアクセシビリティ機能）に関する文書化されたアクセシビリティ上の考慮事項はありません。

7. 国際化に関する考慮事項

現時点で文書化された国際化に関する考慮事項はありません。

8. 謝辞

以下の方々に本仕様の作成にご協力いただいたことに感謝します： Adrienne Walker, Anssi Kostiainen, Chris Terefinko, Domenic Denicola, Jonathan Garbee, Kenneth Rohde Christiansen, L. David Baron, Lukasz Olejnik, Marijn Kruisselbrink, Matt Giuca, Michael Ketting, Nadav Sinai, Peter Linss, Reilly Grant, Staphany Park, Theresa O’Connor, Thomas Nattestad, Thomas Steiner, および Victor Costan （本仕様の作成支援に感謝します）。

忘れている人がいないか確認してください！

また、本ドキュメントの作成に使用された仕様作成ツールである Bikeshed を作成・維持している Tab Atkins, Jr. と、その一般的な執筆助言に特別な感謝を表します。