Summary

  • Le projet public Feature Policy du W3C, publié en 2019, donnait à une page un moyen de restreindre des fonctions du navigateur comme la géolocalisation, le plein écran, la caméra ou le micro.
  • Le projet Permissions Policy de septembre 2026 répartit la décision entre l’en-tête de réponse de la page, l’attribut allow d’une iframe et les règles héritées par le document invité.

Une page moderne ressemble à une petite salle de spectacle. La maison accueille une carte, un lecteur vidéo et peut-être un module de paiement. Chacun joue dans son cadre. La carte souhaite connaître la position du visiteur ; la vidéo demande le plein écran ; un outil de conférence convoite caméra et microphone. Inviter les artistes sur scène ne devrait pas distribuer à chacun le passe-partout des coulisses.

Le premier projet public Feature Policy, daté d’avril 2019, a donné une feuille de consignes au directeur. L’en-tête HTTP Feature-Policy pouvait désactiver une fonction pour le document et ses descendants ou désigner les origines autorisées. Les exemples du W3C parlent de plein écran et de géolocalisation, puis de caméra et de microphone réservés à une origine intégrée précise. La décision de l’hôte suivait ainsi la réponse qui apportait la page.

Le projet W3C de septembre 2026 porte désormais le nom Permissions Policy et indique explicitement son ancien nom. Son en-tête Permissions-Policy utilise un dictionnaire structuré. fullscreen=(), geolocation=() ferme ces deux fonctions au document et à ses descendants. Il s’agit d’une règle pour la maison entière : même un invité muni d’un joli billet ne franchit pas une porte condamnée.

Pour accueillir une carte, le site peut ensuite inscrire allow="geolocation" sur une iframe donnée. Cette consigne concerne la loge choisie. L’en-tête général peut fixer une liste d’origines admissibles ; l’attribut du cadre sélectionne, parmi elles, l’invité concerné. Le texte de 2026 donne précisément un exemple où une origine invitée figure dans la règle générale puis reçoit l’accès dans son cadre. Le voisin ne récupère pas la clé par simple proximité.

Le mécanisme fonctionne par héritage. Chaque fonction possède une liste d’autorisation par défaut. Le document parent reçoit sa politique déclarée par l’en-tête. Le cadre ajoute sa politique de conteneur. Lorsque son document naît ou change d’adresse, le navigateur calcule l’état hérité à partir du parent et du conteneur. Un enfant commence la représentation avec les portes que ses ancêtres ont laissées ouvertes. Sa propre politique s’exerce ensuite dans cette enceinte.

Voilà pourquoi une iframe seule ne réglait pas la question des pouvoirs. Elle isole un contexte de navigation, tandis que les fonctions du navigateur permettent d’agir sur la localisation, l’image, le son ou l’affichage. Le directeur d’une page composée de plusieurs services doit pouvoir accueillir un module sans lui attribuer automatiquement tous les moyens de la scène principale. Permissions Policy transforme cette décision en règle que le navigateur peut appliquer à chaque invité.

La règle devient aussi observable. Le projet de 2026 décrit document.permissionsPolicy et l’objet correspondant d’une iframe. Un composant peut vérifier si la fonction figure parmi celles disponibles et adapter son interface. Une carte sans géolocalisation peut proposer un champ d’adresse. La politique tranche l’éligibilité de la fonction ; la demande de consentement au visiteur et l’état de son appareil interviennent à d’autres moments.

L’historique de publication du W3C suit une longue série de projets jusqu’en septembre 2026. Le problème, lui, reste très concret : le Web a appris à héberger des morceaux d’autres sites pendant que les API du navigateur gagnaient en portée. Il fallait distinguer la règle générale de la salle et le laissez-passer d’une seule loge.