フェンス付きフレームの概要

クロスサイト データを共有することなく、コンテンツをページに安全に埋め込むことができます。

実装ステータス

このドキュメントでは、新しい HTML 要素 <fencedframe> について説明します。

• Chrome で一般提供されています。
• Chrome プラットフォームのステータス。

フェンス付きフレームが必要な理由

フェンス付きフレーム（<fencedframe>）は iframe と同様に、埋め込みコンテンツ用の HTML 要素です。iframe とは異なり、フェンス付きフレームは埋め込みコンテキストとの通信を制限し、埋め込みコンテキストと共有することなく、フレームがクロスサイト データにアクセスできるようにします。一部のプライバシー サンドボックス API では、特定のドキュメントをフェンス付きフレーム内でレンダリングする必要がある場合があります。

同様に、埋め込みコンテキストのファーストパーティ データは、フェンス付きフレームと共有できません。

たとえば、news.example（埋め込みコンテキスト）が shoes.example の広告をフェンス付きフレームに埋め込む場合、news.example は shoes.example の広告からデータを抽出できず、shoes.example は news.example からファーストパーティ データを学習できません。

ストレージ パーティショニングでクロスサイト プライバシーを強化する

ウェブを閲覧していると、あるサイトで見た商品が、まったく別のサイトの広告に表示されることがあります。

現在、この広告手法は主に、サードパーティ Cookie を使用してサイト間で情報を共有するトラッキング技術によって実現されています。

Chrome では、サイトごとにブラウザ ストレージを分離するストレージ パーティショニングに取り組んでいます。パーティショニングがない場合、shoes.example の iframe が news.example に埋め込まれ、その iframe が値をストレージに保存すると、その値は shoes.example サイトから読み取ることができます。ストレージがパーティショニングされると、クロスサイト iframe はストレージを共有しなくなるため、shoes.example は iframe によって保存された情報にアクセスできなくなります。iframe が *.shoes.example から配信され、*.shoes.example に埋め込まれている場合、これらは同じサイトと見なされるため、ブラウザ ストレージが共有されます。

ストレージ パーティショニングは、LocalStorage、IndexedDB、Cookie などの標準ストレージ API に適用されます。パーティショニングされた世界では、ファーストパーティ ストレージ間の情報漏洩が大幅に減少します。

クロスサイト データを操作する

フェンス付きフレームは、トップレベル サイトがデータをパーティション化することを提案するプライバシー サンドボックスの機能です。プライバシー サンドボックスの提案や API の多くは、サードパーティの Cookie や他のトラッキング メカニズムを使用せずに、複数のサイトにまたがるユースケースに対応することを目的としています。次に例を示します。

• Protected Audience API を使用すると、プライバシーを保護しながらインタレスト ベースの広告を配信できます。
• Shared Storage を使用すると、安全な環境でパーティショニングされていないクロスサイト データにアクセスできます。

フェンス付きフレームは、Protected Audience API と連携するように設計されています。Protected Audience API では、ユーザーの興味 / 関心は、広告主のサイトでインタレスト グループに登録され、ユーザーが興味を持つ可能性のある広告も登録されます。その後、別のサイト（「パブリッシャー」と呼ばれる）で、関連するインタレスト グループに登録された広告がオークションにかけられ、落札された広告がフェンス付きフレームに表示されます。

パブリッシャーが落札した広告を iframe に表示し、スクリプトが iframe の src 属性を読み取れる場合、パブリッシャーはその広告の URL から訪問者の興味 / 関心に関する情報を推測できます。これはプライバシー保護ではありません。

フェンス付きフレームを使用すると、パブリッシャーはサイト訪問者のインタレストに一致する広告を表示できますが、src とインタレスト グループはフレーム内の広告主のみに認識されます。パブリッシャーはこの情報にアクセスできませんでした。

フェンス付きフレームの仕組み

フェンス付きフレームは、ナビゲーションに FencedFrameConfig オブジェクトを使用します。このオブジェクトは、Protected Audience API オークションまたは Shared Storage の URL 選択オペレーションから返される可能性があります。次に、構成オブジェクトがフェンス付きフレーム要素の config 属性として設定されます。これは、URL または不透明な URN が src 属性に割り当てられている iframe とは異なります。FencedFrameConfig オブジェクトには読み取り専用の url プロパティがありますが、現在のユースケースでは内部リソースの実際の URL を非表示にする必要があるため、このプロパティは読み取られると文字列 opaque を返します。

フェンス付きフレームは postMessage を使用してエンベッダーと通信できません。ただし、フェンス付きフレームでは、フェンス付きフレーム内の iframe で postMessage を使用できます。

フェンス付きフレームは、他の方法でもパブリッシャーから分離されます。たとえば、パブリッシャーはフェンス付きフレーム内の DOM にアクセスできず、フェンス付きフレームはパブリッシャーの DOM にアクセスできません。また、name などの属性（パブリッシャーが任意の値に設定して観測できる）は、フェンス付きフレームでは使用できません。

フェンス付きフレームは、最上位のブラウジング コンテキスト（ブラウザのタブなど）のように動作します。特定のユースケース（インタレスト ベースのリターゲティング広告など）では、フェンス付きフレームにクロスサイト データ（Protected Audience API のインタレスト グループなど）を含めることができますが、フレームはパーティショニングされていないストレージや Cookie にアクセスできません。フェンス付きフレームは、一意のノンスベースの Cookie とストレージ パーティションにアクセスできます。

フェンス付きフレームの特性については、説明で詳しく説明しています。

フェンス付きフレームと iframe の違いは何ですか？

フェンス付きフレームでできることとできないことがわかったところで、既存の iframe 機能と比較してみましょう。

フェンス付きフレームは、プライバシーを保護するために、外部通信オプションのサポートが少なくなっています。

フェンス付きフレームは iframe に置き換わるのですか？

最終的に、フェンス付きフレームは iframe に置き換わることはなく、使用する必要もありません。フェンス付きフレームは、異なるトップレベル パーティションのデータを同じページに表示する必要がある場合に使用する、よりプライベートなフレームです。

同一サイトの iframe（フレンドリー iframe とも呼ばれます）は、信頼できるコンテンツと見なされます。

フェンス付きフレームを使用する

フェンス付きフレームは、他のプライバシー サンドボックス API と組み合わせて、異なるストレージ パーティションのドキュメントを 1 つのページ内に表示します。潜在的な API については議論中です。

この組み合わせの現在の候補は次のとおりです。

• TURTLEDOVE API ファミリー（Protected Audience API の基盤）では、フェンス付きフレームは Shared Storage を使用してコンバージョン リフト測定と連携できます。
• もう 1 つのオプションは、フェンス付きフレームを読み取り専用にしたり、パーティショニングされていないストレージにアクセスできるようにすることです。

詳しくは、Fenced Frames のユースケースの説明をご覧ください。

例

フェンス付きフレームの config オブジェクトを取得するには、Protected Audience API の runAdAuction() 呼び出しまたは Shared Storage の selectURL() 呼び出しに resolveToConfig: true を渡す必要があります。プロパティが追加されていない（または false に設定されている）場合、結果の Promise は iframe でのみ使用できる URN に解決されます。

const frameConfig = await navigator.runAdAuction({
  // ...auction configuration
  resolveToConfig: true
});

const frameConfig = await sharedStorage.selectURL('operation-name', {
  resolveToConfig: true
});

構成を取得したら、フェンス付きフレームの config 属性に割り当てて、フレームを構成で表されるリソースに移動できます。以前のバージョンの Chrome では resolveToConfig プロパティがサポートされていないため、ナビゲーションの前に、Promise が FencedFrameConfig に解決されたことを確認する必要があります。

if (window.FencedFrameConfig && frameConfig instanceof FencedFrameConfig) {
  const frame = document.createElement('fencedframe');
  frame.config = frameConfig;
}

詳しくは、Fenced Frame と Fenced Frame config の説明をご覧ください。

ヘッダー

ブラウザは、フェンス付きフレームから行われたリクエストと、フェンス付きフレーム内に埋め込まれた iframe に対して Sec-Fetch-Dest: fencedframe を設定します。

Sec-Fetch-Dest: fencedframe

サーバーは、フェンス付きフレームに読み込まれるドキュメントに対して Supports-Loading-Mode: fenced-frame レスポンス ヘッダーを設定する必要があります。ヘッダーは、フェンス付きフレーム内の iframe にも存在する必要があります。

Supports-Loading-Mode: fenced-frame

共有ストレージのコンテキスト

Private Aggregation を使用して、エンベダーのコンテキスト データに関連付けられたフェンス付きフレーム内のイベントレベルのデータをレポートすることが考えられます。fencedFrameConfig.setSharedStorageContext() メソッドを使用すると、イベント ID などのコンテキスト データをエンベダーから Protected Audience API によって開始された共有ストレージ ワークレットに渡すことができます。

次の例では、エンベダー ページで利用可能なデータと、フェンス付きフレームで利用可能なデータを共有ストレージに保存します。埋め込みページから、モック イベント ID が共有ストレージ コンテキストとして設定されます。フェンス付きフレームから、フレーム イベントデータが渡されます。

埋め込みページのコンテキスト データを共有ストレージ コンテキストとして設定できます。

const frameConfig = await navigator.runAdAuction({ resolveToConfig: true });

// Data from the embedder that you want to pass to the shared storage worklet
frameConfig.setSharedStorageContext('some-event-id');

const frame = document.createElement('fencedframe');
frame.config = frameConfig;

フェンス付きフレームから、フレームのイベントレベルのデータを共有ストレージ ワークレットに渡すことができます（上記のエンベダーのコンテキスト データとは無関係です）。

const frameData = {
  // Data available only inside the fenced frame
}

await window.sharedStorage.worklet.addModule('reporting-worklet.js');

await window.sharedStorage.run('send-report', {
  data: {
    frameData
  },
});

エンベッダーのコンテキスト情報を sharedStorage.context から、フレームのイベントレベル データを data オブジェクトから読み取り、プライベート アグリゲーションを通じてレポートできます。

class ReportingOperation {
  convertEventIdToBucket(eventId) { ... }
  convertEventPayloadToValue(info) { ... }

  async run(data) {
    // Data from the embedder
    const eventId = sharedStorage.context;

    // Data from the fenced frame
    const eventPayload = data.frameData;

    privateAggregation.contributeToHistogram({
      bucket: convertEventIdToBucket(eventId),
      value: convertEventPayloadToValue(eventPayload)
    });
  }
}

register('send-report', ReportingOperation);

フェンス付きフレーム構成オブジェクトのエンベダーのコンテキストについて詳しくは、説明をご覧ください。

フェンス付きフレームを試す

Chrome フラグを使用すると、chrome://flags/#enable-fenced-frames で Fenced Frame API を有効にできます。

ダイアログには複数の選択肢があります。*有効にする* を選択することを強くおすすめします。これにより、新しいアーキテクチャが利用可能になったときに、Chrome が自動的に更新されます。

他のオプションである [Enabled with ShadowDOM] と [Enabled with multiple page architecture] は、ブラウザ エンジニアのみに関連するさまざまな実装戦略を提供します。現在、[有効] は [ShadowDOM で有効] と同じように機能します。今後、[有効にする] は [複数ページのアーキテクチャで有効にする] にマッピングされます。

特徴検出

フェンス付きフレームが定義されているかどうかを判断するには:

if (window.HTMLFencedFrameElement) {
  // The fenced frame element is defined
}

フェンス付きフレームの構成が利用可能かどうかを確認するには: js if (window.FencedFrameConfig && frameConfig instanceof FencedFrameConfig) { // The fenced frame config is available }

ブラウザ サポート

• MDN
• Chrome プラットフォームのステータス

意見交換とフィードバックの提供

Fenced Frames は現在活発な議論の対象となっており、今後変更される可能性があります。この API をお試しになり、フィードバックがございましたら、ぜひお聞かせください。

• GitHub: 解説の確認、質問の投稿、意見交換を行えます。

関連リソース

• Chrome プラットフォームのステータス
• Blink プロトタイプを作成する目的