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.
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 :
- À partir de la famille d'API TURTLEDOVE (qui est à la base de l'API Protected Audience), les cadres clôturés pourraient fonctionner avec la mesure de l'impact sur les conversions à l'aide de Shared Storage.
- Une autre option consiste à autoriser les cadres clôturés à être en lecture seule ou à accéder au stockage non partitionné.
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.
const frameConfig = await navigator.runAdAuction({ // ...auction configuration resolveToConfig: true });
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 :
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.
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.
- GitHub : lisez l'explication, posez des questions et suivez la discussion.