Utilisation de moteurs de rendu alternatifs au Japon

    Sous iOS 26.2 et versions ultérieures, d’autres moteurs de rendu que WebKit peuvent être utilisés dans deux types d’apps destinées aux utilisateurs au Japon : les apps de navigateur dédiées qui offrent une expérience de navigation web complète et les apps d’entités responsables de l’exploitation d’un moteur de rendu qui proposent des expériences de navigation intégrée par le biais d’un moteur de rendu embarqué.

    Apple fournit aux développeurs autorisés l’accès aux technologies du système qui leur permettent d’exploiter des fonctionnalités essentielles et de proposer des moteurs de rendu modernes et performants. Ces technologies comprennent la compilation juste-à-temps, la prise en charge simultanée de plusieurs processus, et d’autres encore.

    Toutefois, étant donné que les moteurs de rendu sont constamment exposés à des contenus non fiables et potentiellement malveillants et qu’ils ont accès à des données utilisateur sensibles, ils constituent l’un des vecteurs d’attaque les plus courants pour les personnes et entités mal intentionnées. Afin d’assurer la sécurité des utilisateurs en ligne, Apple autorise les développeurs à mettre en œuvre des moteurs de rendu alternatifs uniquement s’ils remplissent des critères spécifiques et s’engagent à respecter plusieurs obligations en matière de confidentialité et de sécurité, y compris la publication de mises à jour de sécurité permettant de faire face aux menaces et aux vulnérabilités émergentes dans les meilleurs délais.

    Droit de moteur de rendu web

    Pour les apps de navigateur

    Le droit de moteur de rendu web vous permet d’utiliser un moteur de rendu alternatif dans votre app de navigateur. Si cette possibilité vous intéresse, consultez les conditions ci-dessous, puis soumettez une demande de droit de moteur de rendu web. Pour obtenir des recommandations techniques, consultez les pages suivantes :

    Exigences

    Pour bénéficier de ce droit, votre app doit :

    • Être distribuée uniquement sous iOS au Japon (à l’exclusion de toute autre juridiction ou plateforme Apple expressément autorisée par Apple dans le contrat Apple Developer, y compris ses addenda, pour laquelle vous avez également obtenu un profil de droit correspondant).
    • Disposer du droit de navigateur par défaut.
    • Répondre aux exigences fonctionnelles suivantes pour garantir qu’elle utilise un moteur de rendu web offrant des fonctionnalités web de base :
      • Réussir un pourcentage minimum de tests disponibles dans les suites de tests standard du secteur :
        • 90 % des Web Platform Tests
          • en pourcentage du plus grand nombre de sous-tests exécutés par n’importe quel navigateur sur la page d’accueil wpt.fyi ; et
          • sur un système d’exploitation compatible avec la suite de tests
        • 80 % de la suite de tests Test262 sur un appareil iOS, un appareil iPadOS ou un Mac avec puce Apple ; et
      • Répondre aux exigences de la suite de tests ci-dessus si la compilation juste-à-temps (JIT) n’est pas disponible (par exemple, si le mode Isolement est activé par l’utilisateur)
    • Vous et votre app devez respecter les exigences de sécurité suivantes :
      • Vous engager à sécuriser les processus de développement, y compris en surveillant la chaîne d’approvisionnement logicielle de votre app pour détecter les vulnérabilités et en suivant les bonnes pratiques en matière de développement logiciel sécurisé (comme la modélisation des menaces sur les nouvelles fonctionnalités en cours de développement).
      • Fournir une URL vers une politique de divulgation des vulnérabilités précisant les coordonnées permettant à des tiers (qui peuvent comprendre Apple) de signaler des vulnérabilités et des problèmes de sécurité, les informations à fournir dans un signalement, ainsi que le délai prévu de réception des informations de suivi.
      • Vous engager à résoudre dans les meilleurs délais les vulnérabilités qui sont exploitées au sein de votre app ou du moteur de rendu web alternatif qu’elle utilise (par exemple, 30 jours pour les catégories de vulnérabilités les plus simples qui sont activement exploitées).
      • Fournir une URL vers une ou plusieurs pages web accessibles publiquement comportant des informations sur les vulnérabilités signalées qui ont été résolues dans des versions spécifiques du moteur de rendu et la version de l’app associée, si elles sont différentes.
      • Si votre moteur de rendu web alternatif utilise un magasin de certificats racine dont l’accès n’est pas géré par l’intermédiaire du SDK iOS, vous devez rendre la politique de certificats racine accessible publiquement, et l’entité responsable de cette politique doit participer au Certification Authority/Browser Forum en tant qu’éditeur de navigateur.
      • Démontrer la prise en charge des protocoles TLS (Transport Layer Security) modernes pour protéger les communications de données en transit lorsque le moteur de rendu est en cours d’utilisation.
    Exigences de sécurité du programme

    Vous devez :

    • Utiliser des langages de programmation « memory-safe », ou des fonctionnalités qui améliorent la sécurité de la mémoire dans d’autres langages, au sein du moteur de rendu web alternatif au minimum pour tout le code qui traite le contenu web.
    • Adopter les dernières mesures d’atténuation des risques de sécurité (par exemple, les codes d’authentification de pointeur) qui éliminent des catégories de vulnérabilités ou compliquent de manière significative le développement d’une chaîne d’exploit. Cette adoption s’applique aux éléments suivants :
      • Les codes d’authentification de pointeur (PAC, Pointer Authentication Codes).
      • Memory Integrity Enforcement (MIE) pour (i) toute allocation gérée par le système dans n’importe quelle extension de contenu et (ii) toute allocation personnalisée ou gérée par le système dans n’importe quel processus ou extension de votre app, y compris vos extensions réseau et de rendu graphique.
    • Suivre les bonnes pratiques en matière de conception et de codage sécurisés.
    • Utiliser la séparation des processus pour limiter les effets de l’exploitation et valider la communication interprocessus (IPC) au sein du moteur de rendu web alternatif.
    • Surveiller les vulnérabilités dans toute dépendance logicielle tierce et la chaîne d’approvisionnement logicielle plus large de votre app, en effectuant une migration vers des versions plus récentes si une vulnérabilité affecte votre app.
    • Vous abstenir d’utiliser des frameworks ou des bibliothèques logicielles qui ne bénéficient plus de mises à jour de sécurité en réponse aux vulnérabilités.
    • Prioriser la résolution des vulnérabilités signalées avec diligence, plutôt que le développement de nouvelles fonctionnalités. Par exemple, lorsque le moteur de rendu web alternatif fait le lien entre les fonctionnalités du SDK de la plateforme et le contenu web pour l’activation d’API web, vous devez, sur demande, supprimer la prise en charge des API web de ce type qui présentent une vulnérabilité identifiée. La plupart des vulnérabilités doivent être résolues sous 30 jours, mais certaines peuvent être plus complexes et nécessiter davantage de temps.
    Exigences de confidentialité du programme

    Vous devez :

    • Bloquer les cookies intersites (c’est-à-dire les cookies tiers) par défaut, sauf si l’utilisateur donne expressément son consentement éclairé pour autoriser ces cookies ou si cela est nécessaire pour la compatibilité dans le cas de fenêtres pop-up qui interagissent avec des cadres dans leur fenêtre d’ouverture.
    • Partitionner tout stockage ou état observable par les sites web par site web de niveau supérieur, ou bloquer l’utilisation et l’observabilité intersites pour ce stockage ou cet état.
    • Vous abstenir de synchroniser tout état (y compris les cookies) entre votre app et toute autre app, même si celle-ci a été créée par le même développeur, sauf si l’utilisateur a explicitement autorisé la synchronisation de l’état, soit en se connectant à la fois à votre app et à l’autre app, soit à l’aide d’un autre procédé permettant de donner son autorisation explicite.
    • Vous abstenir de partager des identifiants d’appareils avec des sites web sans le consentement éclairé et l’activation de l’utilisateur.
    • Étiqueter les connexions réseau à l’aide des API fournies pour générer un Rapport de confidentialité des apps sous iOS (c’est-à-dire partout où votre app est distribuée).
    • Suivre les normes web généralement adoptées spécifiant dans quelles circonstances demander l’activation et/ou le consentement éclairé des utilisateurs, selon le cas pour les API web (par exemple, l’accès au presse-papiers ou au plein écran), y compris celles qui permettent d’accéder à des informations à caractère personnel.

    Droit de moteur de rendu intégré

    Pour la navigation intégrée

    Le droit de moteur de rendu intégré permet d’incorporer un moteur de rendu alternatif à votre app afin que celle-ci offre des fonctionnalités de navigation intégrée. La navigation intégrée correspond à l’affichage dynamique de contenu provenant du Web, normalement accessible et fonctionnel au sein d’une app de navigateur web. Ce contenu ne comprend pas le contenu intégré à l’app ou uniquement accessible par l’intermédiaire de celle-ci.

    L’objectif principal de la mise en œuvre de la navigation intégrée dans votre app doit être de fournir des fonctionnalités de navigation web. Lors de la mise en œuvre de la navigation intégrée, l’interface doit :

    • Occuper la majeure partie de l’écran, à l’exception des commandes pertinentes permettant de contrôler la session de navigation.
    • Contenir un bouton ou un lien d’accès au navigateur par défaut du système permettant de consulter le contenu actuellement affiché dans une app de navigateur dédiée.
    • Afficher le domaine ou l’URL dont le contenu fait l’objet d’un rendu par la navigation intégrée.

    Si vous souhaitez utiliser un moteur de rendu alternatif dans votre app pour proposer des expériences de navigation intégrée, consultez les conditions ci-dessous, puis soumettez une demande de droit de moteur de rendu intégré. Vous devrez fournir des informations sur le moteur que vous souhaitez intégrer afin de vérifier qu’il remplit les exigences demandées, ainsi que sur la façon dont il peut être mis en œuvre dans une app pour offrir une expérience de navigation intégrée. Pour obtenir des recommandations techniques, consultez la section Exemples et ressources.

    Exigences

    Pour bénéficier de ce droit, votre organisation doit être responsable de l’exploitation d’un moteur de rendu, c’est-à-dire est une entité dont la responsabilité principale est l’exploitation d’un moteur de rendu web distinct.

    • « Responsabilité principale » signifie que vous disposez du contrôle opérationnel et que vous êtes responsable en dernier recours de la coordination d’une réponse et de la résolution de toute vulnérabilité affectant la sécurité ou la confidentialité identifiée dans le moteur de rendu web.
    • Un moteur de rendu web distinct est géré par une entité ou organisation non liée à un autre moteur de rendu web, et dispose à la fois d’une architecture et d’une prise en charge d’API web qui sont matériellement distinctes de tout autre moteur. En règle générale, le moteur n’est pas mis à jour pour refléter les modifications apportées à ses forks, mais transmet plutôt ses propres modifications à ses forks.
    Exigences applicables aux apps

    Votre app doit remplir les conditions suivantes :

    • Être distribuée uniquement sous iOS au Japon (à l’exclusion de toute autre juridiction ou plateforme Apple expressément autorisée par Apple dans le contrat Apple Developer, y compris ses addenda, pour laquelle vous avez également obtenu un profil de droit correspondant).
    • Utiliser le droit uniquement pour la navigation intégrée.
    • Ne pas disposer du droit de navigateur par défaut.
    • Répondre aux exigences fonctionnelles suivantes pour garantir qu’elle utilise un moteur de rendu web offrant des fonctionnalités web de base :
      • Réussir un pourcentage minimum de tests disponibles dans les suites de tests standard du secteur :
        • 90 % des Web Platform Tests
          • en pourcentage du plus grand nombre de sous-tests exécutés par n’importe quel navigateur sur la page d’accueil wpt.fyi ; et
          • sur un système d’exploitation compatible avec la suite de tests
        • 80 % de la suite de tests Test262 sur un appareil iOS, un appareil iPadOS ou un Mac avec puce Apple ; et
      • Répondre aux exigences de la suite de tests ci-dessus si la compilation juste-à-temps (JIT) n’est pas disponible (par exemple, si le mode Isolement est activé par l’utilisateur)
    • Respecter les exigences de sécurité suivantes :
      • Vous engager à sécuriser les processus de développement, y compris en surveillant la chaîne d’approvisionnement logicielle de votre application pour détecter les vulnérabilités et en suivant les bonnes pratiques en matière de développement logiciel sécurisé (comme la modélisation des menaces sur les nouvelles fonctionnalités en cours de développement).
      • Fournir une URL vers une politique de divulgation des vulnérabilités précisant les coordonnées permettant à des tiers (qui peuvent comprendre Apple) de signaler des vulnérabilités et des problèmes de sécurité, les informations à fournir dans un signalement, ainsi que le délai prévu de réception des informations de suivi.
      • Vous engager à résoudre dans les meilleurs délais les vulnérabilités qui sont exploitées au sein de votre app ou du moteur de rendu web alternatif (par exemple, 30 jours pour les catégories de vulnérabilités les plus simples qui sont activement exploitées).
      • Fournir une URL vers une ou plusieurs pages web accessibles publiquement comportant des informations sur les vulnérabilités signalées qui ont été résolues dans des versions spécifiques du moteur de rendu et la version de l’app associée, si elles sont différentes.
      • Si le moteur de rendu web alternatif choisi utilise un magasin de certificats racine dont l’accès n’est pas géré par l’intermédiaire du SDK iOS, vous devez rendre la politique de certificats racine accessible publiquement, et l’entité responsable de cette politique doit participer au Certification Authority/Browser Forum en tant qu’autorité de certification.
      • Démontrer la prise en charge des protocoles TLS (Transport Layer Security) modernes pour protéger les communications de données en transit lorsque le moteur de rendu est en cours d’utilisation.
    Exigences de sécurité du programme

    Vous devez :

    • Utiliser des langages de programmation « memory-safe », ou des fonctionnalités qui améliorent la sécurité de la mémoire dans d’autres langages, au sein du moteur de rendu web alternatif au minimum pour tout le code qui traite le contenu web.
    • Adopter les dernières mesures d’atténuation des risques de sécurité qui éliminent des catégories de vulnérabilités ou compliquent de manière significative le développement d’une chaîne d’exploit.
    • Suivre les bonnes pratiques en matière de conception et de codage sécurisés.
    • Surveiller les vulnérabilités dans toute dépendance logicielle tierce et la chaîne d’approvisionnement logicielle plus large de votre app, en effectuant une migration vers des versions plus récentes si une vulnérabilité affecte votre app.
    • Vous abstenir d’utiliser des frameworks ou des bibliothèques logicielles qui ne bénéficient plus de mises à jour de sécurité en réponse aux vulnérabilités.
    • Prioriser la résolution des vulnérabilités signalées avec diligence, plutôt que le développement de nouvelles fonctionnalités. Par exemple, lorsque le moteur de rendu alternatif fait le lien entre les fonctionnalités du SDK de la plateforme et le contenu web pour l’activation d’API web, vous devez, sur demande, supprimer la prise en charge des API web de ce type qui présentent une vulnérabilité identifiée. La plupart des vulnérabilités doivent être résolues sous 30 jours, mais certaines peuvent être plus complexes et nécessiter davantage de temps.
    Exigences de confidentialité du programme

    Vous devez :

    • Bloquer les cookies intersites (c’est-à-dire les cookies tiers) par défaut, sauf si l’utilisateur donne expressément son consentement éclairé pour autoriser ces cookies ou si cela est nécessaire pour la compatibilité dans le cas de fenêtres pop-up qui interagissent avec des cadres dans leur fenêtre d’ouverture.
    • Partitionner tout stockage ou état observable par les sites web par site web de niveau supérieur, ou bloquer l’utilisation et l’observabilité intersites pour ce stockage ou cet état.
    • Vous abstenir de partager des identifiants d’appareils avec des sites web sans le consentement éclairé et l’activation de l’utilisateur.
    • Étiqueter les connexions réseau à l’aide des API fournies pour générer un Rapport de confidentialité des apps sous iOS (c’est-à-dire partout où votre app est distribuée).
    • Suivre les normes web généralement adoptées spécifiant dans quelles circonstances demander l’activation et/ou le consentement éclairé des utilisateurs, selon le cas pour les API web (par exemple, l’accès au presse-papiers ou au plein écran), y compris celles qui permettent d’accéder à des informations à caractère personnel.
    Exigences supplémentaires
    • À chaque soumission d’un fichier binaire, vous devez indiquer le nom et la version du moteur de rendu web alternatif intégré à votre app.
    • Lorsqu’une nouvelle version du moteur de rendu web alternatif intégré à votre app est publiée, vous devez soumettre une mise à jour de votre app avec cette nouvelle version dans un délai de quinze (15) jours calendaires.

    Exemples et ressources

    Cette section contient des ressources supplémentaires et des exemples qui vous aideront à remplir les exigences nécessaires pour utiliser un moteur de rendu alternatif.

    Cycle de développement logiciel sécurisé

    La plupart des exigences que vous devez respecter s’appuient sur le développement d’une approche axée sur la sécurité et la confidentialité pour intégrer de nouvelles fonctionnalités à votre app. Lorsque vous commencez le développement d’une nouvelle fonctionnalité, vous devez d’abord développer un modèle de menace et planifier une méthode permettant de s’assurer que l’architecture et la version publiée de votre app atténuent les risques que vous avez identifiés. Pour cela, il existe un certain nombre de techniques, comme l’audit de code, le fuzzing et l’écriture de tests pour vérifier les propriétés de sécurité que vous avez l’intention d’appliquer. Vous devez considérer tout le contenu web comme non fiable et potentiellement malveillant.

    Ressources

    Atténuation des risques de sécurité et sécurité de la mémoire

    Vous devez également prendre en compte les mesures actuelles d’atténuation des risques de sécurité mises en œuvre par iOS ou iPadOS, telles que les codes d’authentification de pointeur et Memory Integrity Enforcement, ainsi que les langages de programmation (ou les fonctionnalités de langage et de compilateur) disponibles pour atténuer chaque menace que vous identifiez. Par exemple, Swift est par défaut un langage « memory safe » et peut vous aider à éviter un certain nombre de sources courantes de vulnérabilités ainsi que d’autres bogues logiciels liés à la mémoire. Toutefois, les langages non « memory safe » comme le C++ fournissent des fonctionnalités qui offrent des avantages sur le plan de la sécurité mémoire, telles que std::span. En outre, il est possible d’utiliser des options et des outils de compilateur, par exemple -fbounds-safety avec le C, qui permettent d’annoter du code existant afin de réduire les accès mémoire hors limites, sans nécessiter de réécriture systématique des fonctionnalités dans un langage « memory safe » par défaut.

    Ressources

    Gestion des vulnérabilités

    Vous devez partir du principe que les vulnérabilités non découvertes seront toujours présentes dans un moteur de rendu et que toute nouvelle fonctionnalité peut introduire des risques imprévus. En cas de découverte d’une vulnérabilité au sein de votre chaîne d’approvisionnement logicielle, que ce soit par le biais de tests et de procédures internes de contrôle de la sécurité et de la confidentialité ou d’un signalement effectué par un tiers, il est donc essentiel de disposer de processus permettant d’apporter une réponse.

    Lorsque vous fournissez à un tiers (par exemple, un chercheur ou une chercheuse en sécurité) une méthode de signalement des vulnérabilités, vous devez réfléchir aux informations dont vous aurez besoin pour déterminer rapidement la validité et la cause du problème. Vous devez également vous assurer que vous avez mis en place des processus permettant de prioriser l’élaboration d’un correctif pour la vulnérabilité, puis de proposer une mise à jour sans forcément respecter votre planning habituel de publication.

    Il est également important que les utilisateurs puissent déterminer rapidement quelles vulnérabilités publiques associées à une référence CVE sont résolues dans chaque version de votre app (ou d’un moteur de rendu alternatif).

    Ressources

    Sécurité du réseau

    L’utilisation du SDK iOS, en particulier du framework Network et/ou des API SecTrust, réduit la nécessité de prendre en charge l’évaluation de la confiance des certificats web et la maintenance ou l’utilisation d’un magasin de certificats racine de confiance correspondant et d’un programme pour le moteur de rendu alternatif auquel vous avez recours. Si vous gérez un programme, celui-ci doit fournir des informations sur la manière dont une autorité de certification racine (CA) peut y postuler, ainsi que sur la façon dont les incidents (par exemple, l’exposition des informations d’une clé privée d’une autorité de certification racine) peuvent être signalés afin que vous puissiez intervenir.

    Les protocoles utilisés sur le Web évoluent constamment pour s’adapter aux menaces émergentes et mieux protéger la confidentialité et la sécurité des utilisateurs. Les versions TLS modernes actuelles qui devraient être compatibles avec votre moteur de rendu alternatif et dont la prise en charge n’a pas été abandonnée sont TLS 1.2 et 1.3. Toutefois, ces versions sont susceptibles de changer avec le temps. Votre moteur de rendu alternatif peut prendre en charge des protocoles obsolètes, mais vous devez informer les utilisateurs lors de l’accès à un site qui prend uniquement en charge ces protocoles.

    Ressources

    Contrats