Présentation des Fenced Frames

Intégrez du contenu de manière sécurisée sur une page sans partager de données intersites.

État de l'implémentation

Ce document présente un nouvel élément HTML : <fencedframe>.

Proposition État
Modifications de l'API Web pour la conversion d'un code urn en configuration
Explication
Disponible dans Chrome au 1er trimestre 2023.
Macros de création dans les cadres délimités pour les rapports sur les annonces (FFAR)
Problème GitHub
Disponible dans Chrome au 3e trimestre 2023.
Envoyer des balises automatiques une fois
Problème GitHub
Disponible dans Chrome au 3e trimestre 2023.
Configurations de cadres délimités sérialisables
Problème GitHub
Disponible dans Chrome au 3e trimestre 2023.
Option de format supplémentaire pour les macros de taille d'annonce Protected Audience
Problème GitHub
Disponible dans Chrome au quatrième trimestre 2023.
Envoi automatique de balises vers toutes les URL enregistrées
Problème GitHub | Problème GitHub
Disponible dans Chrome au quatrième trimestre 2023.
Activer les groupes de centres d'intérêt des annonces quittant les iFrames Urn et les cadres de composants d'annonces
Problème GitHub
Disponible dans Chrome au 1er trimestre 2024
Introduction de reserved.top_navigation_start/commit
Problème GitHub, Problème GitHub
Disponible dans Chrome au 1er trimestre 2024
Ne pas désactiver le paramètre de cookie dans ReportEvent jusqu'à 3PCD
Problème GitHub
Disponible dans Chrome au 1er trimestre 2024
Ajout de la compatibilité avec les balises automatiques dans les sous-cadres inter-origines
Problème GitHub
Disponible dans Chrome au 1er trimestre 2024
Autoriser les sous-cadres inter-origines à envoyer des balises reportEvent()
Problème GitHub
Disponible dans Chrome au 2e trimestre 2024
En-tête Referer dans les balises
Problème GitHub
Disponible dans Chrome au 1er trimestre 2025
Compatibilité automatique des données cross-origin avec les balises
Problème GitHub
Prévu dans Chrome au 2e trimestre 2025

Pourquoi avons-nous besoin de cadres clôturés ?

Un fenced frame (<fencedframe>) est un élément HTML pour le contenu intégré, semblable à un iframe. Contrairement aux iframes, un fenced frame limite la communication avec son contexte d'intégration pour permettre au frame d'accéder aux données multisites sans les partager avec le contexte d'intégration. Certaines API Privacy Sandbox peuvent exiger que certains documents s'affichent dans un cadre clôturé.

De même, aucune donnée first party dans le contexte d'intégration ne peut être partagée avec le cadre clôturé.

Par exemple, si news.example (le contexte d'intégration) intègre une annonce de shoes.example dans un cadre clôturé, news.example ne peut pas exfiltrer de données de l'annonce shoes.example, et shoes.example ne peut pas apprendre de données first party à partir de news.example.

Renforcer la confidentialité multisite avec le partitionnement du stockage

Lorsque vous naviguez sur le Web, vous avez probablement consulté des produits sur un site, puis vous les avez revus dans une annonce sur un site complètement différent.

Aujourd'hui, cette technique publicitaire est principalement réalisée grâce à une technologie de suivi qui utilise des cookies tiers pour partager des informations sur différents sites.

Chrome travaille sur le partitionnement du stockage, qui sépare le stockage du navigateur par site. Sans partitionnement, si un iFrame provenant de shoes.example est intégré à news.example et que cet iFrame stocke une valeur dans le stockage, cette valeur peut être lue à partir du site shoes.example. Lorsque le stockage est partitionné, les iFrames multisites ne partagent plus le stockage. Par conséquent, shoes.example ne pourra pas accéder aux informations stockées par l'iFrame. Si l'iFrame est diffusé depuis *.shoes.example et intégré à *.shoes.example, le stockage du navigateur sera partagé, car ces domaines sont considérés comme appartenant au même site.

Comparaison de l&#39;état du partitionnement du stockage avant et après.

Le partitionnement du stockage sera appliqué aux API de stockage standards, y compris LocalStorage, IndexedDB et les cookies. Dans un monde partitionné, les fuites d'informations dans le stockage first party seront considérablement réduites.

Utiliser les données multisites

Les cadres clôturés sont une fonctionnalité Privacy Sandbox qui suggère que les sites de premier niveau partitionnent les données. De nombreuses propositions et API de la Privacy Sandbox visent à répondre aux cas d'utilisation multisites sans cookies tiers ni autres mécanismes de suivi. Exemple :

  • L'API Protected Audience permet de diffuser des annonces basées sur les centres d'intérêt tout en protégeant la confidentialité.
  • Shared Storage permet d'accéder à des données intersites non partitionnées dans un environnement sécurisé.

Les cadres clôturés sont conçus pour fonctionner avec l'API Protected Audience. Avec l'API Protected Audience, les centres d'intérêt d'un utilisateur sont enregistrés sur le site d'un annonceur dans des groupes d'intérêt, ainsi que les annonces susceptibles de l'intéresser. Ensuite, sur un autre site (appelé "éditeur"), les annonces enregistrées dans les groupes d'intérêt pertinents sont mises aux enchères, et l'annonce gagnante est affichée dans un frame isolé.

Si l'éditeur affiche l'annonce gagnante dans un iFrame et que le script peut lire l'attribut src de l'iFrame, il peut déduire des informations sur les centres d'intérêt du visiteur à partir de l'URL de cette annonce. Cela ne préserve pas la confidentialité.

Avec un frame cloisonné, l'éditeur peut diffuser une annonce correspondant aux centres d'intérêt des visiteurs, mais le src et le groupe d'intérêt ne seront connus que de l'annonceur dans le frame. L'éditeur n'a pas pu accéder à ces informations.

Comment fonctionnent les cadres clôturés ?

Les cadres clôturés utilisent l'objet FencedFrameConfig pour la navigation. Cet objet peut être renvoyé à partir d'une mise aux enchères de l'API Protected Audience ou de l'opération de sélection d'URL de Shared Storage. L'objet de configuration est ensuite défini comme attribut config sur l'élément de cadre clôturé. Cela diffère d'un iFrame où une URL ou un URN opaque est attribué à l'attribut src. L'objet FencedFrameConfig possède une propriété url en lecture seule. Toutefois, étant donné que les cas d'utilisation actuels nécessitent que l'URL réelle de la ressource interne soit masquée, cette propriété renvoie la chaîne opaque lorsqu'elle est lue.

Un Fenced Frame ne peut pas utiliser postMessage pour communiquer avec son intégrateur. Toutefois, un cadre clôturé peut utiliser postMessage avec des iFrames à l'intérieur du cadre clôturé.

Les cadres clôturés seront isolés de l'éditeur d'autres manières. Par exemple, l'éditeur n'aura pas accès au DOM à l'intérieur d'un cadre clôturé, et le cadre clôturé ne pourra pas accéder au DOM de l'éditeur. De plus, les attributs tels que name, qui peuvent être définis sur n'importe quelle valeur et observés par l'éditeur, ne sont pas disponibles dans les cadres clôturés.

Les cadres clôturés se comportent comme un contexte de navigation de premier niveau (tel qu'un onglet de navigateur). Bien qu'un frame cloisonné puisse contenir des données multisites (comme un groupe d'intérêt de l'API Protected Audience) dans certains cas d'utilisation (comme les annonces de retargeting basées sur les centres d'intérêt), il ne peut pas accéder au stockage ni aux cookies non partitionnés. Le frame clôturé peut accéder à une partition de stockage et de cookies unique basée sur un nonce.

Les caractéristiques des cadres clôturés sont décrites plus en détail dans l'explication.

Quelle est la différence entre les cadres clôturés et les iFrames ?

Maintenant que vous savez ce que les cadres clôturés peuvent et ne peuvent pas faire, il est utile de les comparer aux fonctionnalités d'iframe existantes.

Fonctionnalité iframe fencedframe
Intégrer du contenu Oui Oui
Le contenu intégré peut accéder au DOM du contexte d'intégration Oui Non
Le contexte d'intégration peut accéder au DOM du contenu intégré Oui Non
Attributs observables, tels que name Oui Non
URL (http://example.com) Oui Oui (selon le cas d'utilisation)
Source opaque gérée par le navigateur (urn:uuid) Non Oui (selon le cas d'utilisation)
Accès aux données multisites Non Oui (selon le cas d'utilisation)

Les cadres clôturés sont compatibles avec moins d'options de communication externe pour préserver la confidentialité.

Les frames clôturées remplaceront-elles les iframes ?

En fin de compte, les cadres clôturés ne remplaceront pas les iframes et vous n'aurez pas à les utiliser. Les cadres clôturés sont des cadres plus privés à utiliser lorsque des données provenant de différentes partitions de niveau supérieur doivent être affichées sur la même page.

Les iFrames de même origine (parfois appelés iFrames "amis") sont considérés comme du contenu fiable.

Utiliser des frames cloisonnés

Les cadres clôturés fonctionneront en combinaison avec d'autres API Privacy Sandbox pour afficher des documents provenant de différentes partitions de stockage sur une même page. Les API potentielles sont en cours de discussion.

Voici quelques exemples de combinaisons :

Pour en savoir plus, consultez l'explication des cas d'utilisation des cadres isolés.

Exemples

Pour obtenir un objet config de frame clôturé, vous devez transmettre resolveToConfig: true à l'appel runAdAuction() de l'API Protected Audience ou à l'appel selectURL() de Shared Storage. Si la propriété n'est pas ajoutée (ou est définie sur false), la promesse résultante sera résolue en un URN qui ne peut être utilisé que dans un iFrame.

Obtenir la configuration du frame clôturé à partir de l'enchère de l'API Protected Audience
const frameConfig = await navigator.runAdAuction({
  // ...auction configuration
  resolveToConfig: true
});
Obtenir la configuration du frame cloisonné à partir de la sélection d'URL de stockage partagé
const frameConfig = await sharedStorage.selectURL('operation-name', {
  resolveToConfig: true
});

Une fois la configuration obtenue, vous pouvez l'attribuer à l'attribut config d'un frame clôturé pour que le frame accède à la ressource représentée par la configuration. Les versions antérieures de Chrome ne sont pas compatibles avec la propriété resolveToConfig. Vous devez donc toujours vérifier que la promesse a été résolue en FencedFrameConfig avant de naviguer :

Définir la configuration sur l'attribut de frame cloisonné
if (window.FencedFrameConfig && frameConfig instanceof FencedFrameConfig) {
  const frame = document.createElement('fencedframe');
  frame.config = frameConfig;
}

Pour en savoir plus, consultez les explications sur les cadres clôturés et la configuration des cadres clôturés.

En-têtes

Les navigateurs définiront Sec-Fetch-Dest: fencedframe pour les requêtes effectuées à partir de cadres clôturés et d'iFrames intégrés dans un cadre clôturé.

Sec-Fetch-Dest: fencedframe

Le serveur doit définir l'en-tête de réponse Supports-Loading-Mode: fenced-frame pour qu'un document puisse être chargé dans un cadre clôturé. L'en-tête doit également être présent pour tous les iframes à l'intérieur d'un cadre clôturé.

Supports-Loading-Mode: fenced-frame

Contexte Shared Storage

Vous pouvez utiliser l'agrégation privée pour générer des rapports sur les données au niveau de l'événement dans des cadres clôturés associés à des données contextuelles de l'intégrateur. En utilisant la méthode fencedFrameConfig.setSharedStorageContext(), vous pouvez transmettre des données contextuelles, telles qu'un ID d'événement, de l'intégrateur aux worklets de stockage partagé initiés par l'API Protected Audience.

Dans l'exemple suivant, nous stockons certaines données disponibles sur la page de l'intégrateur et certaines données disponibles dans le cadre cloisonné dans le stockage partagé. Sur la page de l'intégrateur, un ID d'événement fictif est défini comme contexte de stockage partagé. Les données d'événement de frame sont transmises à partir du frame clôturé.

Sur la page de l'intégrateur, vous pouvez définir des données contextuelles comme contexte de stockage partagé :

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;

À partir du frame cloisonné, vous pouvez transmettre des données au niveau de l'événement du frame au worklet de stockage partagé (sans rapport avec les données contextuelles de l'intégrateur ci-dessus) :

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
  },
});

Vous pouvez lire les informations contextuelles de l'intégrateur à partir de sharedStorage.context et les données au niveau de l'événement du frame à partir de l'objet data, puis les signaler via l'agrégation privée :

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);

Pour en savoir plus sur le contexte de l'intégrateur dans un objet de configuration de frame clôturé, consultez l'explication.

Essayer les frames cloisonnés

Utilisez les indicateurs Chrome pour activer l'API Fenced Frame sur chrome://flags/#enable-fenced-frames.

Dans Chrome Experiments, définissez &quot;Enabled&quot; (Activé) pour l&#39;indicateur &quot;Enable the Fenced frame element&quot; (Activer l&#39;élément de frame clôturé).

La boîte de dialogue propose plusieurs choix. Nous vous recommandons vivement de sélectionner *Activer*, ce qui permet à Chrome de passer automatiquement à la nouvelle architecture dès qu'elle est disponible.

Les autres options, Activé avec ShadowDOM et Activé avec une architecture multipage, proposent différentes stratégies d'implémentation qui ne concernent que les ingénieurs de navigateur. Aujourd'hui, Activer fonctionne de la même manière que Activé avec ShadowDOM. À l'avenir, l'option Activer sera associée à Activer avec l'architecture multipage.

Détection des fonctionnalités

Pour déterminer si des cadres clôturés sont définis :

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

Pour déterminer si la configuration des cadres isolés est disponible :

if (window.FencedFrameConfig && frameConfig instanceof FencedFrameConfig) {
   // The fenced frame config is available
}

Prise en charge des navigateurs

Interagir et envoyer des commentaires

Les cadres clôturés font l'objet de discussions actives et sont susceptibles d'être modifiés à l'avenir. Si vous essayez cette API et que vous avez des commentaires, n'hésitez pas à nous les faire parvenir.

En savoir plus