Permissions Policy, capacités du navigateur et vie privée

BotBrowser peut répéter un parcours autorisé avec un contexte déclaré et observer son résultat visible. Il ne rédige ni ne déploie la politique, n'accorde pas de permission, ne crée pas de périphérique et ne prouve pas un enregistrement distant. Permissions Policy limite les capacités qu'un document peut utiliser. La réponse supérieure fixe la limite et allow de l'iframe délègue une fonction à une origine enfant. C'est une limite de capacité, pas une permission utilisateur, une garantie de périphérique ni la preuve d'une opération terminée. Ce guide suit la spécification W3C et MDN.

TL;DR

Choisissez la liste minimale de fonctions et d'origines, vérifiez l'origine finale après redirection, alignez l'en-tête et allow, puis comparez un fixture de contrôle et de candidat. Une frame éligible peut manquer d'API, de contexte sécurisé, d'activation, de permission, de périphérique ou d'accusé applicatif. BotBrowser répète un parcours autorisé et observe son résultat visible; il ne rédige ni ne déploie la politique, n'accorde pas de permission, ne crée pas de périphérique et ne prouve pas un enregistrement distant.

Contents

• Ce que contrôle la politique
• Séparer les étapes de capacité
• Distinguer les politiques
• Utiliser un fixture reproductible
• Conclusion pratique

Ce que contrôle la politique

Permissions-Policy: geolocation=(self "https://widget.example") autorise la page et le widget à tenter la géolocalisation. L'iframe doit aussi avoir allow="geolocation" et chaque ancêtre doit conserver la délégation. Une redirection vers un autre schéma, hôte ou port peut invalider l'origine finale. Les valeurs par défaut dépendent de la fonction.

N'utilisez pas allow="*" par commodité : il délègue la fonction à toute origine qui occupe le conteneur, y compris une redirection inattendue. Gardez une allowlist explicite, nommez le propriétaire de l'en-tête et du markup, et retirez les entrées à la fin de l'intégration. Un enfant ne peut pas récupérer une fonction retirée par un ancêtre.

L'éligibilité de la politique n'est pas l'état de permission. navigator.permissions peut afficher prompt ou granted alors que la frame est bloquée. Un refus, un délai ou un périphérique absent restent possibles. Notez la première étape en échec.

Séparer les étapes de capacité

Étape	Preuve	Ce que cela ne prouve pas
Origine et contexte final	URL, schéma, port, contexte sécurisé	La présence de l'API
Capacité API	Vérification ciblée de l'interface	Une requête autorisée
Permissions Policy	En-tête, allow, ancêtres, origine enfant	Consentement ou périphérique
Décision utilisateur/plateforme	Permission, réglage admin, périphérique	L'acceptation par l'application
Résultat applicatif	État visible ou confirmation bornée	Un enregistrement distant

Demandez à la frame enfant de rapporter sa propre origine et son état via une page de test contrôlée. Utilisez des permissions synthétiques et stables; ne collectez ni coordonnées, ni médias, ni identifiants.

Distinguer les politiques

CSP contrôle scripts, connexions, ressources et frames. COOP organise les contextes de navigation supérieurs. COEP fixe les conditions des ressources cross-origin. Aucun ne délègue caméra ou géolocalisation; Permissions Policy ne crée pas l'isolation cross-origin et ne satisfait pas CORS/CORP.

Vérifiez réseau et CSP, puis origine finale et COOP/COEP si nécessaire, ensuite la chaîne Permissions Policy, et enfin la fonction qui demande une action utilisateur. Une erreur réseau, un blocage de politique, un refus et une erreur applicative ont des responsables différents. Aucun en-tête ne remplace l'autorisation serveur, le consentement, la validation ou le contrôle du périphérique.

Utiliser un fixture reproductible

Exposez /fixtures/permissions-policy/control.html et candidate.html sur un hôte contrôlé. Gardez route, frame, bouton et marqueur identiques; seul le candidat reçoit l'en-tête proposé. Après un clic explicite, l'enfant affiche policy=blocked ou policy=allowed. Ce sont des marqueurs applicatifs, pas une preuve navigateur suffisante : vérifiez aussi le Permissions-Policy livré, allow de l'iframe et l'origine finale de l'enfant.

import { test, expect } from '@playwright/test';
const cases = [
  { name: 'control', url: 'https://qa.example.test/fixtures/permissions-policy/control.html', expected: 'blocked' },
  { name: 'candidate', url: 'https://qa.example.test/fixtures/permissions-policy/candidate.html', expected: 'allowed' },
];
for (const scenario of cases) {
  test(`Permissions Policy ${scenario.name}`, async ({ page }) => {
    let response;
    try {
      response = await page.goto(scenario.url, { waitUntil: 'domcontentloaded', timeout: 8000 });
    } catch (error) {
      throw new Error(`NETWORK_ERROR avant l'assertion : ${error.message}`);
    }
    expect(response?.ok(), `Réponse HTTP de ${scenario.name}`).toBeTruthy();
    await page.getByRole('button', { name: 'Request location' }).click();
    await expect(page.getByTestId('policy-result')).toHaveText(new RegExp(`^${scenario.expected}$`), { timeout: 5000 });
  });
}

Les erreurs DNS, certificat, HTTP et de route restent NETWORK_ERROR, jamais un blocked réussi. Un timeout signifie seulement que le fixture n'a pas produit de preuve dans le délai. Fermez le context et supprimez les données temporaires. Le fixture ne prouve que le navigateur et la route déclarés.

La gestion de la vie privée doit utiliser des permissions synthétiques et des valeurs temporaires, sans coordonnées, médias, cookies ni contenu de compte. Attribuez le premier échec : réseau et en-tête à l'infrastructure, chaîne de politique au propriétaire de l'embed, refus à l'équipe du consentement et erreur après l'API à l'application. Conservez l'ancien en-tête et le markup pour le retour arrière, puis rejouez la même route, les mêmes permissions et la même assertion pour préserver la reproductibilité.

Conclusion pratique

Le contrat d'intégration doit nommer les origines, la fonction, le but, l'action, la solution de repli et le responsable. Rejouez le fixture après un changement d'hôte, de redirection, de navigateur ou de frame imbriquée. Gardez seulement valeurs de politique, origines, version et résultats visibles.

BotBrowser peut répéter un parcours autorisé dans un browser context déclaré. Il ne peut pas changer Permissions-Policy, modifier les origines, accorder des permissions, fournir un périphérique, contourner CSP/COOP/COEP, corriger une réponse fournisseur ni prouver une opération distante. La réponse délivrée et les données du service font foi. Consultez le guide CSP et le guide d'isolation cross-origin.

Sources

• W3C: Permissions Policy
• MDN: Permissions Policy
• MDN: iframe allow
• MDN: CSP
• MDN: COOP
• MDN: COEP
• BotBrowser : fonctions avancées

Équipe BotBrowser