Intégrez de manière sécurisée du contenu sur une page sans partager de données intersites.
État de l'implémentation
- Suppression programmée
- Intention de lancement : supprimer l'élément FencedFrame et les API window.fence
- État de la plate-forme Chrome
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.
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 :
- À partir de la famille d'API TURTLEDOVE (qui est la base de l'API Protected Audience), les frames cloisonnés peuvent fonctionner avec la mesure de l'augmentation des conversions à l'aide de Shared Storage.
- Une autre option consiste à autoriser les frames cloisonnés à être en lecture seule ou à accéder au stockage non partitionné.
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.
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 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 :
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.
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.
- GitHub : lisez l’explication, posez des questions et suivez la discussion.