Règles de décision du générateur

Le générateur Permissions-Policy propose chaque autorisation selon des règles que vous pouvez vérifier. Les connaître vous indique quand faire confiance à un réglage par défaut et quand passer outre.

D'un report à une autorisation

Le générateur lit deux types de report. Chaque report nomme une fonctionnalité et qui l'a demandée, et le générateur en tire l'autorisation qui la permettrait :

Le générateur accorde des origines, pas des URL complètes. Une iframe chargée depuis https://pay.example.com/checkout?step=2 devient une autorisation pour https://pay.example.com.

Les deux types de report peuvent être forgés par toute personne qui connaît votre endpoint. Un nom de fonctionnalité que la grammaire du header n'admet pas, ou un src d'iframe qui n'est pas une simple origine http ou https, ne devient jamais une ligne, il ne peut donc pas atteindre un header généré.

Iframes et violations potentielles

Une iframe demande une fonctionnalité dans son attribut allow. Le navigateur reporte cette demande comme une violation potentielle, que la page Reports Permissions Policy affiche dans sa vue Potentielles :

<iframe src="https://video.example.com/embed/42" allow="fullscreen; autoplay"></iframe>

Cette iframe produit une ligne sous fullscreen et une sous autoplay, toutes deux pour https://video.example.com. Déléguer une fonctionnalité demande les deux moitiés : le header l'accorde à l'origine de l'iframe, et l'iframe continue de la nommer dans allow. Pour le modèle du header et de l'attribut, consultez l'attribut allow des iframes. Quand vous accordez une fonctionnalité à une origine d'iframe, l'étape de déploiement affiche Les iframes ont aussi besoin de leur attribut allow en guise de rappel.

Scripts tiers

Pour une fonctionnalité utilisée par vos propres pages, les reports nomment le script à l'origine de chaque appel. Le générateur classe chaque script dans l'un de trois groupes : votre propre code (servi depuis l'origine de votre site), le script d'une autre origine, ou une extension de navigateur.

Quand tous les appels venaient du script d'une autre origine ou d'une extension, la ligne self est signalée Script tiers et arrive rejetée. Accorder la fonctionnalité à self la donnerait aussi à ce script, car un script s'exécute avec les permissions de la page qui le charge. Quand au moins un appel venait de votre propre code, la ligne arrive accordée.

Bruit

Le bruit est une ligne reportée dont votre site n'a pas besoin. Le générateur signale une ligne comme bruit dans l'un de ces cas :

• Elle compte moins de 10 reports sur la période.
• Chaque appel derrière elle venait d'une extension de navigateur, qui tourne sur la machine du visiteur, pas sur votre site.

Le panneau de détails signale aussi quand un seul navigateur a reporté une ligne alors que votre site en voit plusieurs, mais ce signal ne suffit jamais à faire d'une ligne du bruit. Seuls les navigateurs Chromium envoient ces reports, la plupart des sites ne voient donc qu'un seul navigateur.

Le bruit arrive rejeté, mais ce n'est qu'un réglage par défaut. Une page rarement utilisée, comme une campagne annuelle, peut reporter une fonctionnalité moins de 10 fois et en avoir quand même besoin. Vérifiez le filtre Bruit avant de déployer.

Préréglages de départ

Les navigateurs ne reportent jamais la Permissions-Policy avec laquelle une page a été servie, le générateur ne peut donc pas détecter la politique que vous envoyez aujourd'hui. Il part de l'une de ces options :

Une autorisation issue de la politique de départ reste accordée, même quand les reports la signalent. La revue ajoute ensuite ce que votre site a utilisé d'après les reports.

Quand vous collez votre propre politique

Le générateur lit la valeur comme une valeur de header Permissions-Policy, sans le nom du header :

• Chaque fonctionnalité qu'elle définit est conservée, y compris les fonctionnalités hors du catalogue.
• Dans chaque allowlist, il conserve self, src, * et les simples origines http ou https, et écarte tout le reste.
• Il écarte les paramètres comme report-to, et ignore un membre qui n'a pas la forme feature=allowlist.
• Une fonctionnalité du catalogue que votre politique ne définit pas garde le comportement par défaut du navigateur, sauf si les reports ou vos décisions l'ajoutent.

Une politique collée n'existe que dans la page ouverte. Après un rechargement, le générateur revient à Refuser toutes les fonctionnalités listées.

Catalogue des fonctionnalités

Le générateur liste 25 fonctionnalités, celles qui sont largement déployées et qu'il est utile de verrouiller. Les préréglages les définissent toutes, le header refuse donc chacune de celles que vous n'accordez pas :

Une fonctionnalité reportée hors du catalogue obtient elle aussi son propre groupe dans le tableau de revue, après les fonctionnalités du catalogue. Elle finit dans le header, soit accordée, soit sous la forme ().

Écriture du header

Le générateur écrit la politique sur une seule ligne, avec des virgules comme séparateurs :

• Les fonctionnalités suivent l'ordre du catalogue, puis toute autre fonctionnalité par ordre alphabétique, pour que le header soit identique quel que soit le point de départ.
• Une fonctionnalité accordée à personne s'écrit (), ce qui la refuse partout, y compris dans les iframes.
• self vient en premier dans une allowlist, puis chaque origine entre guillemets doubles.
• Une fonctionnalité accordée à * s'écrit * seul, quoi qu'elle liste d'autre.
• Aucun paramètre report-to n'est écrit. Les reports partent vers l'endpoint default du header Reporting-Endpoints, que le générateur déclare à côté de centralcsp.

Par exemple, une politique qui accorde payment à vos pages et à une iframe de paiement, et refuse le reste, se lit ainsi, raccourcie ici à cinq fonctionnalités :

Permissions-Policy-Report-Only: accelerometer=(), autoplay=(), browsing-topics=(), camera=(), payment=(self "https://pay.example.com")

Le vrai header liste toutes les fonctionnalités du catalogue. Pour l'exemple complet, consultez Démarrer.

Périodes et limites

Le générateur lit jusqu'aux 30 derniers jours de reports. Un site qui envoie un très gros volume de reports est limité à 7 jours à la fois.

Sur un tel site, l'étape Période affiche Ce site envoie beaucoup de rapports : le générateur ne lit donc que ses 7 derniers jours, et les options 14 jours et 30 jours sont masquées. Si une période contient plus de reports que le générateur ne peut en lire à temps, la page affiche Cette période contient trop de rapports pour être analysée à temps. Choisissez une période plus courte. Choisissez moins de jours et continuez.

L'API applique les mêmes règles. L'endpoint Build a recommended Permissions-Policy porte par défaut sur les 7 derniers jours et couvre jusqu'à 30 jours. Sans politique de départ, il part de Refuser toutes les fonctionnalités listées. Chaque utilisateur peut l'appeler 10 fois par minute. Consultez la référence de l'API.

Étapes suivantes

• Tableau de revue
• Démarrer
• Reports Permissions Policy
• Report de violation Permissions-Policy
• Référence Permissions-Policy