Résumé

  • Dans la version du 22 septembre de Threat Model for the Web, le groupe d’intérêt Sécurité du W3C représente séparément le contexte d’exécution du document, la médiation du navigateur, la demande d’API Web et le résultat renvoyé.
  • La version de la veille réunissait ces fonctions dans un seul processus abstrait d’agent utilisateur. Le nouveau modèle de haut niveau n’est pas un plan des processus réels de Chromium, Gecko ou WebKit.
  • Examiner le code qui appelle une API ne suffit donc pas à constater une permission accordée ou un contrôle effectivement appliqué. Cette conséquence relève de notre analyse, non d’une exigence nouvelle du W3C.

Un service Web peut montrer une interface rassurante et déclencher ensuite une fonction du navigateur. Pour l’observateur qui ne voit que la page, la séquence paraît continue : clic, appel, réponse. Pourtant, trois autorités possibles y sont mêlées. Le site choisit ce qu’il demande, le navigateur arbitre selon ses règles et son état, et l’utilisateur peut intervenir par une interface qui n’appartient pas au site. Une réponse positive ou négative termine l’échange visible sans révéler automatiquement le lieu de l’arbitrage.

Le projet de note du 22 septembre fournit un langage plus net pour cette séparation. Son modèle L0 nomme PO-02 le contexte du document et de l’origine, PO-01 la médiation contrôlée par le navigateur. Le flux DF-05 transporte la demande d’API et ses arguments vers ce dernier ; DF-06 revient sous forme de valeur, de promesse résolue, d’événement, d’état ou d’erreur. La frontière TB-02 couvre de manière abstraite l’isolement des origines et contextes. Le schéma distingue aussi l’utilisateur du service distant.

Dans le texte du 21 septembre, L0 représentait l’agent utilisateur par un seul processus P0, associé à un état géré par le navigateur S0. Réseau, site et système d’exploitation apparaissaient comme éléments externes de ce modèle minimal. Le besoin d’examiner l’architecture interne n’est toutefois pas apparu la veille : le texte précédent indiquait déjà que l’emplacement des décisions, les permissions et l’isolement exigent un modèle plus détaillé. La nouveauté est d’avoir placé l’appel et son retour au premier niveau de lecture.

Ce changement peut améliorer l’examen d’une spécification d’API. Un document chargé depuis une origine exerce des possibilités liées à cette origine ; ce fait ne transforme pas son interface en dialogue fiable du navigateur avec l’utilisateur. Le modèle plus détaillé du même projet décrit une fonction privilégiée de contrôle, des processus de contenu exposés aux ressources non fiables et des voies distinctes vers l’état, le réseau ou le système. Ces rôles guident les questions à poser. Ils ne certifient ni l’architecture ni les paramètres d’une version précise de navigateur.

Il faut aussi respecter la portée institutionnelle du texte. Il s’agit d’un projet de note approuvé par le groupe d’intérêt Sécurité, mais non approuvé par le W3C ou ses membres. La série a commencé en mai 2026 ; le 22 septembre n’est pas sa première publication. Les parties consacrées à l’analyse des menaces et aux contrôles portent encore la mention de travail incomplet. Aucun incident, produit vulnérable ou nouvelle obligation de permission ne peut être déduit de cette révision.

La leçon pratique est de conserver quatre traces distinctes lors d’un examen : la demande du document, la décision du navigateur, le résultat reçu par la page et les éléments démontrant l’application du contrôle dans le produit considéré. Le dessin situe les questions. Les réponses exigent des preuves d’exécution.

Sources