Présentation des Fenced Frames

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

État de l'implémentation

Pourquoi avons-nous besoin de frames cloisonnés ?

Un frame cloisonné (<fencedframe>) est un élément HTML pour le contenu intégré, semblable à un iFrame. Contrairement aux iFrames, un frame cloisonné limite la communication avec son contexte d'intégration pour permettre au frame d'accéder aux données intersites sans les partager avec le contexte d'intégration. Certaines API Privacy Sandbox peuvent nécessiter que certains documents soient rendus dans un frame cloisonné.

De même, toutes les données first party du contexte d'intégration ne peuvent pas être partagées avec le frame cloisonné.

Par exemple, si news.example (le contexte d'intégration) intègre une annonce de shoes.example dans un frame cloisonné, 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é intersites avec le partitionnement du stockage

Lorsque vous naviguez sur le Web, vous avez probablement consulté des produits sur un site, puis vous les avez vus apparaître 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 les sites.

Chrome travaille sur le partitionnement du stockage, qui sépare le stockage sur le navigateur par site. Sans partitionnement, si un iFrame 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 a été partitionné, les iFrames intersites 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é à partir de *.shoes.example et intégré à *.shoes.example, le stockage sur le navigateur sera partagé, car il s'agit du même site.

Comparaison de l'é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 entre le stockage first party seront considérablement réduites.

Utiliser des données intersites

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

  • L'API Protected Audience permet de diffuser des annonces ciblées par centres d'intérêt de manière à protéger la confidentialité.
  • Shared Storage permet d'accéder à des données intersites non partitionnées dans un environnement sécurisé.

Les frames cloisonné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 de centres d'intérêt, ainsi que des annonces susceptibles d'intéresser l'utilisateur. Ensuite, sur un site distinct (appelé "éditeur"), les annonces enregistrées dans les groupes de centres d'intérêt pertinents sont mises aux enchères et l'annonce gagnante s'affiche dans un frame cloisonné.

Si l'éditeur affiche l'annonce gagnante dans un iFrame et que le script peut lire l'attribut src de l'iFrame, l'éditeur 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 afficher une annonce correspondant aux centres d'intérêt du visiteur, mais l'attribut src et le groupe d'intérêt ne seront connus que de l'annonceur dans le frame. L'éditeur ne pourra pas accéder à ces informations.

Comment fonctionnent les frames cloisonnés ?

Les frames cloisonné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 frame cloisonné. Cela diffère d'un iFrame où une URL ou un URN opaque URN 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 lors de la lecture.

Un frame cloisonné ne peut pas utiliser postMessage pour communiquer avec son intégrateur. Toutefois, un frame cloisonné peut utiliser postMessage avec des iFrames à l'intérieur du frame cloisonné.

Les frames cloisonné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 frame cloisonné, et le frame cloisonné 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 frames cloisonnés.

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

Les caractéristiques des frames cloisonnés sont décrites plus en détail dans l' explication.

Comment les frames cloisonnés se comparent-ils aux iFrames ?

Maintenant que vous savez ce que les frames cloisonnés feront et ne feront pas, 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 intersites Non Oui (selon le cas d'utilisation)

Les frames cloisonnés prennent en charge moins d'options de communication externes pour préserver la confidentialité.

Les frames cloisonnés remplaceront-ils les iFrames ?

En fin de compte, les frames cloisonnés ne remplaceront pas les iFrames et vous n'aurez pas à les utiliser. Les frames cloisonnés sont des frames plus privés à utiliser lorsque des données provenant de différentes partitions de premier niveau doivent être affichées sur la même page.

Les iFrames du même site (parfois appelés iFrames conviviaux) sont considérés comme du contenu de confiance.

Utiliser des frames cloisonnés

Les frames cloisonnés fonctionneront en combinaison avec d'autres API Privacy Sandbox pour afficher des documents provenant de différentes partitions de stockage sur une seule page. Les API potentielles sont en cours de discussion.

Les candidats actuels pour cette combinaison incluent les éléments suivants :

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

Exemples

Pour obtenir un objet config de frame cloisonné, 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 cloisonné à partir de la mise aux enchères 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 Shared Storage
const frameConfig = await sharedStorage.selectURL('operation-name', {
  resolveToConfig: true
});

Une fois la configuration obtenue, vous pouvez l'attribuer à l'attribut config d'un frame cloisonné pour accéder au frame à 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 confirmer que la promesse a été résolue en FencedFrameConfig avant de naviguer :

Définir la configuration sur l'attribut du 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 frames cloisonnés et la configuration des frames cloisonnés.

En-têtes

Les navigateurs définissent Sec-Fetch-Dest: fencedframe pour les requêtes effectuées à partir de frames cloisonnés et d'iFrames intégrés dans un frame cloisonné.

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 soit chargé dans un frame cloisonné. L'en-tête doit également être présent pour tous les iFrames à l'intérieur d'un frame cloisonné.

Supports-Loading-Mode: fenced-frame

Contexte de Shared Storage

Vous pouvez utiliser Private Aggregation pour générer des rapports sur les données au niveau de l'événement dans les frames cloisonnés associés aux données contextuelles de l'intégrateur. À l'aide de la méthode fencedFrameConfig.setSharedStorageContext(), vous pouvez transmettre certaines données contextuelles, telles qu'un ID d'événement, de l'intégrateur aux worklets de Shared Storage 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 frame cloisonné dans Shared Storage. À partir de la page de l'intégrateur, un ID d'événement factice est défini comme contexte de Shared Storage. À partir du frame cloisonné, les données d'événement du frame sont transmises.

À partir de la page de l'intégrateur, vous pouvez définir des données contextuelles comme contexte de Shared Storage :

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 Shared Storage (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 Private Aggregation :

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 cloisonné, consultez l'explication.

Essayer les frames cloisonnés

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

Dans Chrome Experiments, définissez le flag &quot;Enable the Fenced frame element&quot; (Activer l'élément Fenced Frame) sur &quot;Enabled&quot; (Activé).

Plusieurs choix s'offrent à vous dans la boîte de dialogue. 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, Activer sera mappé sur Activer avec une architecture multipage.

Détection de fonctionnalités

Pour déterminer si des frames cloisonnés sont définis :

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

Pour déterminer si la configuration du frame cloisonné est disponible :

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

Prise en charge des navigateurs

Participer et envoyer des commentaires

Les frames cloisonnés font l'objet de discussions actives et peuvent être modifiés à l'avenir. Si vous essayez cette API et que vous avez des commentaires, n'hésitez pas à nous en faire part.

En savoir plus