Présentation des Fenced Frames

Intégrez du contenu de façon sécurisée dans une page sans partager de données intersites.

État d'implémentation

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

• The Fenced Frames proposal is now in general availability.
• Chrome Platform Status

Pourquoi avons-nous besoin de cadres cloisonnés ?

Un cadre cloisonné (<fencedframe>) est un élément HTML permettant d'intégrer s'apparente à un iFrame. Contrairement aux iFrames, un cadre cloisonné restreint la communication avec son contexte de représentation vectorielle continue pour permettre à la trame d'accéder à des sans les partager avec le contexte de représentation vectorielle continue. Certaines API Privacy Sandbox peut exiger que certains documents s'affichent dans un cadre cloisonné.

De même, les données first party dans le contexte de l'intégration ne peuvent pas être partagées avec le cadre cloisonné.

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

Renforcez la confidentialité entre les sites grâce au partitionnement du stockage

En naviguant sur le Web, vous avez probablement regardé des produits sur un site, puis vous les avez vu apparaître à nouveau dans une annonce sur un site complètement différent.

Aujourd'hui, cette technique publicitaire repose essentiellement sur le suivi qui utilise des cookies tiers pour partager des informations entre les sites. Ce est une technologie que Chrome s'est engagé à utiliser et les remplacer par des variantes protégeant la confidentialité.

Chrome travaille sur l'espace de stockage le partitionnement, permet de séparer le stockage du navigateur par site. Actuellement, si un iFrame de shoes.example est intégré à news.example, et cet iFrame stocke une valeur dans l'espace de stockage, cette valeur peut alors être lue à partir du site shoes.example. Lorsque l'espace de stockage est arrivé à expiration les iFrames intersites partitionnés ne partageront plus le stockage. 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, l'espace de stockage du navigateur sera partagé, car ces sites sont considérés comme du même site.

Le partitionnement du stockage sera appliqué aux API de stockage standards, y compris LocalStorage, IndexedDB et les cookies. Dans un monde partitionné, l'information les fuites sur le stockage propriétaire seront considérablement réduites.

Travailler avec des données intersites

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

• L'API Protected Audience permet de diffuser des annonces en fonction des centres d'intérêt tout en protégeant la confidentialité.
• Le stockage partagé permet à des données intersites non partitionnées dans un environnement sécurisé.

Voyons comment les cadres cloisonnés pourraient fonctionner avec le API Protected Audience : Avec l'API Protected Audience, les centres d'intérêt des utilisateurs sont inscrits sur le site d'un annonceur dans l'intérêt des groupes d'annonces, ainsi que les 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 cadre cloisonné.

Si l'éditeur affiche l'annonce gagnante dans un iFrame et que le script peut lire le l'attribut src de l'iFrame, l'éditeur peut déduire des informations sur l'attribut à partir de l'URL de cette annonce. Cette approche ne préserve pas la confidentialité.

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

Comment fonctionnent les cadres cloisonnés ?

Les cadres cloisonnés utilisent l'objet FencedFrameConfig pour la navigation. Cet objet peut être renvoyé à partir d'une enchère de l'API Protected Audience ou de l'opération de sélection d'URL de Shared Storage. Ensuite, l'objet de configuration est défini en tant qu'attribut config sur l'élément de frame cloisonné. Cela diffère d'un iFrame dans lequel 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.

Une trame cloisonnée ne peut pas utiliser postMessage pour communiquer avec son intégrateur. Toutefois, un cadre cloisonné peut utiliser postMessage avec des iFrames à l'intérieur de ce cadre cloisonné.

Les cadres cloisonnés seront isolés de l'éditeur d'autres manières. Par exemple, l'éditeur n'a pas accès au DOM à l'intérieur d'un cadre cloisonné, et un cadre cloisonné ne peut pas accéder au DOM de l'éditeur. De plus, des attributs tels que name, qui peut être définie sur n'importe quelle valeur et observée par la ne sont pas disponibles dans les cadres cloisonnés.

Les cadres cloisonnés fonctionnent comme une navigation de premier niveau contexte (un onglet de navigateur, par exemple). Bien qu'un cadre cloisonné dans certains cas d'utilisation (comme opaque-ads) peuvent contenir des données intersites (comme un centre d'intérêt de l'API Protected Audience) ), la trame ne peut pas accéder au stockage non partitionné ni aux cookies. Une opaque-ads frame cloisonné peut accéder à un cookie et à un stockage uniques basés sur des nonce partition.

Les caractéristiques des cadres cloisonnés sont plus détaillées dans le .

Quelles sont les différences entre les cadres cloisonnés et les cadres iFrame ?

Maintenant que vous savez ce que les cadres cloisonnés feront et ne feront pas, il est utile de comparer aux fonctionnalités iFrame existantes.

Les cadres cloisonnés acceptent moins d'options de communication externe afin de préserver la confidentialité.

Les cadres cloisonnés remplaceront-ils les iFrames ?

En fin de compte, les cadres cloisonnés ne remplaceront pas les iFrames et vous n'aurez pas à les utiliser. Les trames cloisonnées sont un cadre plus privé à 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 du même site (parfois appelés iFrames conviviaux) sont considérés comme fiables. contenus.

Utiliser des cadres cloisonnés

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

Voici les candidats actuels pour cette combinaison:

• Dans la famille de l'API TURTLEDOVE (qui est sur la base de l'API Protected Audience), les cadres cloisonnés pourraient fonctionner avec le conversion lift Mesures à l'aide du stockage partagé.
• Une autre option consiste à autoriser les cadres cloisonnés lecture seule ou accéder à des données non partitionnées stockage.

Pour en savoir plus, consultez la section Cadres cloisonnés de cas d'utilisation.

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 si elle est définie sur false), la promesse obtenue renvoie un URN qui ne peut être utilisé que dans un iFrame.

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

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

Une fois que vous avez obtenu la configuration, vous pouvez l'affecter à l'attribut config d'un frame cloisonné pour naviguer dans le frame jusqu'à la ressource représentée par la configuration. Les anciennes versions de Chrome ne sont pas compatibles avec la propriété resolveToConfig. Vous devez donc toujours vérifier que la promesse a résolu un FencedFrameConfig avant de lancer la navigation:

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

Pour en savoir plus, consultez les explications concernant le cadre cloisonné et la configuration du cadre cloisonné.

En-têtes

Les navigateurs définiront Sec-Fetch-Dest: fencedframe pour les requêtes effectuées à partir de cadres cloisonnés et d'iFrames cloisonnés intégrés dans un cadre 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 cadre cloisonné. L'en-tête doit également être présent pour tous les iFrames situés à l'intérieur d'un cadre clôturé.

Supports-Loading-Mode: fenced-frame

Contexte du stockage partagé

Vous pouvez utiliser l'agrégation privée pour enregistrer les données au niveau de l'événement dans des cadres cloisonnés associés aux données contextuelles de l'intégrateur. En utilisant 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 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 d'autres disponibles dans le frame cloisonné de l'espace de stockage partagé. Sur la page de l'intégrateur, un ID d'événement fictif est défini comme contexte de stockage partagé. À partir du frame cloisonné, les données d'événement de frame sont transmises.

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 les données au niveau de l'événement de la trame au Worklet de stockage partagé (sans lien 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 cadres cloisonnés

Utiliser Chrome des options pour activer l'API Fenced Frames dans chrome://flags/#enable-fenced-frames.

Plusieurs choix s'offrent à vous dans la boîte de dialogue. Nous vous recommandons vivement de sélectionner *Activer*, qui permet à Chrome de passer automatiquement à la nouvelle architecture dès qu'elles sont disponibles.

Les autres options, Enabled with ShadowDOM, et Enabled with multiple architecture de page, proposent différentes stratégies d'implémentation qui ne sont utiles pour les ingénieurs du navigateur. Aujourd'hui, Activer fonctionne de la même manière que Activé avec ShadowDOM. À l'avenir, Activer sera remplacé par Activer avec architecture sur plusieurs pages.

Détection de caractéristiques

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: js if (window.FencedFrameConfig && frameConfig instanceof FencedFrameConfig) { // The fenced frame config is available }

Prise en charge des navigateurs

L'élément <fencedframe> est toujours en mode expérimental. Il est donc actuellement compatible à partir de Chrome 97. Pour le moment, il n'est pas pris en charge par d'autres navigateurs.

Interagir et partager des commentaires

Les cadres cloisonné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 en faire part.

• GitHub: lisez l'explication. poser des questions et suivre discussion.
• Assistance aux développeurs: posez des questions et participez à des discussions sur le Assistance pour les développeurs de la Privacy Sandbox .

En savoir plus

• État de la plate-forme Chrome
• Cligner l'intention sur Prototypage